読者です 読者をやめる 読者になる 読者になる

DockerについてLTした内容と細かい話

speakerdeck.com

ホスティング事業部内のホスtechMTG#3にてDockerについてLTしました
資料に入り切らなかった小ネタなどをここでは紹介。

LT資料の言い回しついての補足

specコンテナ:
コンテナ内でRSpecを実行してコードをテストするためのコンテナ

dbコンテナ:
RSpec実行コンテナと接続しているMySQLが起動されたコンテナ

参考資料

最近だとこの辺がDockerについて特集記事がありました
Software Design 2017年2月号
WEB+DB PRESS Vol.98

実際に使ったコマンド

資料では若干オプションなど省いてたので完全版

  • specコンテナ側の起動時
    • $ docker run -dit -v $(pwd)/spec/features:/tmp/muu/spec/features --link db spec bash
    • E2Eテストだけ外から変えられるように-vでホストPC側の一部をマウント
  • exit後にもっかい入る時
    • $docker run -it spec bash
    • -dでコンテナを起動している
    • exitした後、再度コンテナに入りたい時に

.dockerignore

コンテナ間通信についての資料とかは探せばたくさんあるけれども

最終的にはやっぱり公式っしょ
- Docker Engine ユーザガイド - コンテナ通信の理解

spec->dbコンテナのDB接続のため

Railsのconfig/database.ymlでは環境変数で与えられたhost名を使って接続するようにしているので、
specコンテナのDockerfile内でdbコンテナのipを環境変数(TEST_MYSQL_HOST)として与えておくことでちょっと楽した気分を味わいました。
docker-composeを使えばそういうことせずにspecコンテナ側のlocalhost:3306をdbコンテナ側の3306としてPort Forwardingの設定ができそうな気はしました。
あと、drone.ioの.drone.ymlはdocker-composeのsupersetのようなのでdocker-compose.ymlには使いまわせるのかな?というところまでで。 drone.io - Getting Startd

# Dockerfile
...
ENV TEST_MYSQL_HOST 172.17.0.2
# config/database.yml
common: &common
  adapter:   mysql2
  reconnect: false
  pool:      5
  strict:    false
  database: dbdbdb

...

test:
  <<: *common
  host: <%= ENV['TEST_MYSQL_HOST'] %>
  username: <%= ENV['TEST_MYSQL_USER'] %>
  password: <%= ENV['TEST_MYSQL_PASSWORD'] %>

JSON Schemaの書き方がわからないので調べた件について

現在RailsAPIサーバを開発しております。
WebでAPI開発について色々調べた結果、API開発にあたりJSON Schemaと言うものを設計しておくと色々捗るようなのですが、
初見では書き方・読み方がいまいちわからなかったので少しは読み書きできる程度に調べてみました。
なおyamljsonと混在してますが、僕はyamlで書く予定のためそうなってます。あしからず。

また、自分なりの解釈のため間違っている箇所が多々あると思いますが、やんわり教えてもらえると助かります。

公式 json-schema.org


- 最初に書くヘッダ的な数行 - idはこのリソースのURI

id: http://some.site.somewhere/entry-schema#
"$schema": http://json-schema.org/draft-04/hyper-schema
title: Product
description: A product from Acme's catalog
type: object
properties:


- typeがarrayの場合、次にitemsが続く

type: array
items:
  type: string


- itemsは下記のような要素を持てる(ここで全て網羅してません)

title:
type:
properties:


- typeがobjectの場合、次にpropertiesが続く

dimesions:
  type: object
    properties:
      length:
        type: number


- propertiesの後は任意の変数名が続く
- properties内はtypeがほぼ必須
- description:で説明が追加できる
- minimum: 0などの制約が追加できる

properties:
  options:
    description: about this option
    type: array
    minItems: 1
    items:
      type: string
    uniqueItems: true


- $ref:schema内の該当箇所を参照する
- required:で必須プロパティを指定できる
- oneOf: スキーマの配列であり、インスタンスはこれらのスキーマのうちの1つに対して有効である場合にのみ有効
- definitions: スキーマで使用されるインラインサブスキーマを定義できる標準化されたプレースホルダ

{
    "id": "http://some.site.somewhere/entry-schema#",
    "$schema": "http://json-schema.org/draft-04/schema#",
    "description": "schema for an fstab entry",
    "type": "object",
    "required": [ "storage" ],
    "properties": {
        "storage": {
            "type": "object",
            "oneOf": [
                { "$ref": "#/definitions/diskDevice" },
                { "$ref": "#/definitions/diskUUID" },
                { "$ref": "#/definitions/nfs" },
                { "$ref": "#/definitions/tmpfs" }
            ]
        }
    },
    "definitions": {
        "diskDevice": {},
        "diskUUID": {},
        "nfs": {},
        "tmpfs": {}
    }
}

ここ3ヶ月間のコードレビューでついたコメント集(PHP編)

なんとWeb業界に転職してはや5ヶ月目突入しました。
今回はサービスに配属されてからこの3ヶ月間のうちに自分が出したPRのコードへのコメントをまとめてみました。 タイトルの通り内容はPHPの書き方に絞っています。

  • nullの判定
    • $foo['bar'] === nullではなくempty($foo['bar']) または isset($foo['bar'])を使う
  • nullだったら代入させたいパターン
    • ついついif (empty($now)) {と書いちゃいがちだが、if使わなくても1 sentenseでいけるよってパターン
    • nullでない時は$nowの値がそのままとなる
>>> $now || $now = date('Ymd')
>>> $now
=> "20170202"
  • 文字列判定
    • strpos()よりpreg_match()
    • 正規表現を使うことになるが、より細かい判定基準で文字列一致を判定できる
  • 戻り値をbooleanで返す時
    • ついついif ($bar === '何か文字列') {とかで判定した結果をreturnしがちだけど 1 sentenseでいけるよってパタン2
    function foo() {
        return ($bar === '何か文字列');
    }
  • ヒアドキュメントを使う
  • __DIR__を使う
    • require __DIR__.'/../../Example.php'


一応前職でCをかじっていたいので基本中の基本では突っ込まれることはなく、
PHP特有の標準関数を使うことや、こういう書き方まで書いてOKみたいなラインについて理解が進んできました。
とはいってもまだまだなので日進月歩で学んでいきます。

ではまた何ヶ月か後にPHPRails編で。

Retry [Ruby on Rails Tutorial] with RSpecした時のメモ1

RSpecにて 名前の長さのvalidationテスト書くとき
modelでこう書いてる時に

 validates :name, presence: true, length: {maximum: 50}


user.errorsのname部分のエラーは

:name=>["is too long (maximum is 50 characters)"]

となってるので、includeでエラーの一部と一致させたいときは

    expect(user.errors[:name][0]).to include("too long")

こう([:name][0])書かないとsuccessされなかった

Macのショートカットキー翻訳スクリプト

Mac使ってますがショートカット記号の対応キーが全然覚えれないので ショートカット記号をキーボードのキー名に翻訳するスクリプトRubyで書いてみました。

gist.github.com

実行結果

$ruby coubou.rb
 ⌘:1, ⌃:2, ⌥:3, ⇧:4, ⇪:5, ⎋:6,
 Please input corresponding number & enter.
 Exit: ^c

# 数字キー(1〜6)を入力すると対応するショートカット記号を表示する。
# 例えば以下のような入力をしてEnter実行すると
 ⇧⇪⌥⌃K
# キー名にして出力される
 Shift + Caps Lock + Option + Control + K

最近はPHPばかり書いてたので、 RubyのSymbolに数値が使えないとかでハマったりしながらも、Rubyっぽい書き方で少しは書けたかなーと思います。 ただ、改行のためにやたらputs ''をたくさん書いてしまったけれど他に上手い書き方がありそうだ…。

参考

Macの特殊キー記号を覚えてしまおう! « TORQUES LABS

コードポイントから文字に変換するには (chr) | hydroculのメモ

Rubyでバッファリングなしのキー入力を試す - Programmer's Diary

2016年の振り返りと2017年に向けて

自分の2016年を振り返るとすると、

「転職した」ということが8割を占めるといってよいでしょう。

 

2月中旬: ペパボ主催イベント参加

6月末 : ペパボへの応募

7月末 : ペパボへ内定

10月 : ペパボに入社

11月 : 現在のチームへ配属

 

半年前にはこうなることはまだ予想できていませんでした。しかし、入社のためにできることは全力で取り組んできたと思っており、その結果が出たことは素直に嬉しく感じています。

 

ここまで至った想いについては、先日入社2ヶ月な自分が発表するというものすごい機会をいただいた際に作成したスライドで色々書いております。

litencatt.hatenablog.com

 

それをベースとして既に社内的に下記に示す2017年上期の目標を立てました。

 

・担当サービスのエンジニアとしての自立

・担当サービスの進化・改善

・新たな技術の学習

 

入社後はあっという間に3ヶ月が過ぎ、振り返ると日々周囲にいる異能エンジニアたちから様々な刺激を受けつつ、そうした環境の中で自分の技術力のなさに打ちひしがれていました。

そうした焦りや悔しさと目の前に立ちはだかる壁を見ながら色々思うことはありますが、自分の目指すエンジニアへ全力で向かっていくために2017年は引き続き入社後の精神的なブースト状態を維持しつつ、まずここで一気に最初の坂を登りきるために日々精進していきます。

 

まずは手を動かして、アウトプットする。

そして目標に向かって突き進んでいく。

そのためにここに来た。

Amazon MWS Reports APIの理解

ここ10日ほどAmazon MWS Reports APIについて調査していました。

その説明の前にまず、Amazonは「Amazonログイン&ペイメント」という、Amazonアカウントを持っているユーザーが他サービスにおいてAmazonアカウントでログインでき、さらに登録しているクレジットカードで支払いができるというサービスを提供しています。

そして、Amazon MWS Repots APIとはこのサービスを導入した管理者側がAmazonペイメントで取引きされた内容に関するレポートを要求するためのAPIです。

詳細は以下のリンク参照。

https://docs.developer.amazonservices.com/ja_JP/reports/Reports_Overview.html

 

今となってはこのAPIはそんなに大したことない量でした。

しかし調査に時間がかかった理由として、基本的にはAPIを実行してレスポンス値を見ていたのですが、

1.スロットル制限がある

(実行後、60秒以上間を開けないと再実行できないといった制限)

2.ReportId、ReportRequestId、RequestReportListなど似た単語が多い

3.APIは標準時(GMT)に変換されて実行される

といった点があり、取得レポートの確認に時間がかかりました。

 

でも今となってはこのAPIに関しては通常利用する分には問題ない程度に理解したので、今後はログインや支払い部分についても理解をしていこうと思っています。