FROM ruby:2.6.3

RUN apt-get update -qq \
  && apt-get install -y postgresql-client \
  && apt-get clean \
  && rm -rf /var/lib/apt/lists/*

ENV LANG=C.UTF-8 \
  TZ=Asia/Tokyo \
  APP_HOME=/usr/src/app

WORKDIR $APP_HOME
COPY Gemfile* $APP_HOME/
RUN bundle install
COPY . $APP_HOME/

RUN命令でDockerfileのImageに対してコマンドを実行する。

 RUN apt-get update -qq \ 
  && apt-get install -y  postgresql-client \
  && apt-get clean

apt-get updateの -qq オプションはエラー以外を出力しないもの。
postgresqlもDocker Imageで用意するけど、Railsアプリ自体に接続するためのクライアントが入っていないので、apt-get install -y postgresql-client でインストール
最後に apt-get cleanで一時ファイルなどを削除する

ENV命令は環境変数を設定できる。今回は文字コード、タイムゾーン、アプリケーションのルートディレクトリを設定した。

WORKDIR命令はアプリケーションの作業ディレクトリを設定できる。設定したディレクトリが存在しない場合は自動で作成される。 Dockerfile リファレンス — Docker-docs-ja 17.06.Beta ドキュメント

COPY命令はローカルファイルをコンテナファイルにコピーする。ローカルのカレントディレクトリのGemfile*をコピーしてbundle installを実行後、残りのディレクトリをごそっとコピーするようにした。Quick guildeでは /myappとかルートディレクトリからディレクトリを生やしていたので、とりあえずusr/src/で作業するようにした。

これでカレントディレクトリのRailsアプリケーションを実行するためのコンテナの作成はOK

docker-compose.ymlを作る

Railsのプロセスが動くコンテナはできたので、docker-composeでその他のコンテナを集めて、実行環境を作っていく。

version: '3'

services:
  db:
    image: postgres:11.2
    environment:
      POSTGRES_PASSWORD: postgres
    ports:
      - '5432:5432'
    volumes:
      - postgres-data:/var/lib/postgresql/data
  app: &app_base
    build: .
    command: /bin/sh -c "rm -f ./tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    ports:
      - '3000:3000'
    volumes:
      - .:/usr/src/app
    environment:
      RAILS_ENV: development
    depends_on:
      - db
  spring:
    <<: *app_base
    command: bin/spring server
    ports: []

volumes:
  postgres-data:

postgresと上で作成した、Appコンテナ、springサーバーを起動するためのサービスを定義する。

db Service

PostgreSQLのコンテナpostgres:11.2 は POSTGRES_PASSWORD環境変数でデータベースパスワードを設定できる。そのまま、5432番ポートでつながるようにマッピング。

postgres-dataというボリュームをファイルの下の volumes:で定義しているので、postgresのデータをそのままボリュームに指定する。/var/lib/postgresql/dataがデータを保存するディレクトリだということはDocker Hubのページから確認できる。

app Service

docker-compose buildコマンドでDockerfileの内容でbuildされる。

起動時には bundle exec railsの前に rm -f ./tmp/pids/server.pidを実行している。これはdocker-compose killを実行したときにファイルが残って、次回起動時にエラーになっちゃうから。

spring Service

docker-compose upしたあとにappコンテナ内でRailsのコマンドを効率的よく実行したいので、springをdocker-compose execコマンドで呼べるようにしている。

高速に開発できる Docker + Rails開発環境のテンプレートを作った - Qiita ここ眺めて、<<がdocker-compose.ymlの記法に見当たらないと思ってさまよっていたんだけど、YAMLの記法だった。&fooでハッシュに名前をつけれて、<<: *fooでその内容をそのまま展開できる。これで同じコンテナで違うcommandを持つserviceが作成できる。

database.ymlの設定を変える

config/database.ymlの内容をdockerのpostgresで使えるように設定する。 - hostにはdocker-compose.ymlに記載したサービスdbを指定する - user、passwordには postgresを設定する。 - userはpostgresコンテナのデフォルト、passwordはdocker-compose.ymlで指定した環境変数POSTGRES_PASSWORDを設定する。

ここまで書けば、

docker-compose build
docker-compose up

でRailsのアプリケーションがDockerコンテナで実行できる。

改善

読み返すと甘いところもあって

/vendor/bundleをvolumeに外出しできそう
nodeをインストールするのがだるくて、mini-racerをインストールしてたりするけどどっちがいいのか迷ってる
そもそもAPPコンテナの容量が1.2Gとかあるので、削減できそう

などなど改善できそうなので、やっていこうと思う。

2019-06-12

Rails Developpers Meetup 2019へ行った

今更の話だけど、3/22 , 3/23に外苑前の日本オラクルで行われたRails Developers Meetup 2019に参加した。エレベーターのボタンの押し心地が良かった。

印象にのこった発表

万葉のRails新人研修のコードレビューコメントを分析してみました

Railsそのものよりも、RSpecやコーディングスタイルなど、お作法に関する対話が多くなる
- 「必要のない自動作成されたファイルがPRにまぎれている場合はあなたが削除しなければいけませんよ」という認識をもたせる
- コーディングスタイルは「linter入れれば」という話もあるけど、まずは「そういった細かいスタイルに気を配れる人」になってほしい
レビュイーは動くまでの関心が強く、レビュアーは動いたあとの関心が強くなる
レビュアーも背景、意図が伝わっていないレビューコメントを残していしまうことがあるので、背景、意図は積極的に伝えるようにする良い
4つの価値観を大切にしたい
- わかりすくする
- 品質の向上
- 開発時の行動
- 変更に強くする

新人研修のやりとりで発生したレビューを分析するというとても手間がかかっていそうな発表だった。レビューの発話者の立場で一番多いのがレビュアー、レビュイー以外の一般社員というのがとても素敵だと思った。

Clean Test Code Revised

可読性の高いテストコードとは
- 脳に負担をかけないテストコードのこと
- 以下のことがシンプルに記載されていること
  - テストの概要
  - 事前条件
  - 手続き
  - 期待する結果
脳に負担をかける要素とは
- テストの概要について
  - describe、context、itなどのグルーピングメソッドの説明が雑
- 事前条件について
  - 事前条件で使われる変数のスコープが曖昧
  - スコープが散らばっていて、テストの全体を把握するのにコード、ファイルの行き来が必要
- 依存性について
  - factory_botのデフォルト値に依存していると危険
  - factory_botのafter: createを使うと可読性が下がる
    - traitを使う
- shared_contextを使う
- shared_exampleを使う

途中からプロジェクトに参戦して、shared_contextの内容を把握するのに一苦労したので、新規に作るときはshared_contextをできるだけ使わないようにする決意をした。

2019-05-25

未来大×企業エンジニア春のLT大会でしゃべってきた

未来大×企業エンジニア春のLT大会で喋ってきた。学生若すぎて心が破滅した。

内容

キーボードはIIZEって話と、開発環境に凝りすぎないようにする天秤の話が8:2みたいな発表をした。 https://speakerdeck.com/uvb_76/kai-fa-huan-jing-wu-li-wozuo-ru

雰囲気

大講義室ほぼ満員
- 休みの日にこれだけの人数が大学まで登山してくるのすごい
人数に驚いたけど、学生の笑いの沸点が低くてすごく話しやすかった。

学生の様子

低学年の参加率、モチベーションが非常に高くて驚かされた。
- 1年生が「ChromeOS最高」とか言ったり、「C#最高」とか言ったりしてて良い。
上級生へののっていきが出来ているんだと思った。

他の方の発表

「これだけは伝えたい技術」ってテーマについて、周りの企業の方々も結構苦慮していた感があった。

ココらへんがよかったなあー

エンジニアからマネージャーになるってどういうことよ
動かして理解するGitの内側
構造化思考法(スライドみつからなかった)
Insert an Example of Software Engineer Here - Speaker Deck
最強のChrome OS - Google スライド
よわよわPCによる姿勢推定 -PoseNet-

知ったこと

地元函館の学生はほとんど居なくて、札幌や青森の学生が多いとのこと。もっと地元の人いると思っていた。
- 遠くからだと奈良や岐阜も多いって聞いた。

感想

若い学生に向けたのでまあまあウケは良かったと思う。しかし、アウトプットに対する影響目標を指定せずにノリで資料を作ってしまったのは反省。今回キーボードに全振りするのなら、例えば「発表を見た学生がキーボードを作った報告」を定量的目標として設定できたはずで、最初にこのゴール設定ができていなかった。今回は「その道具にこだわる上で時間は有限なので、その取捨選択をしましょう」という話をどちらかというとしたくて、それが中途半端になってしまった。話すテーマ自体もいろいろ作っている間に二転三転してしまって、あまり資料の質を上げることができなかった。結局自分に「これだけは伝えたい技術」として自身を持って話せる技術がなかったということなんだと思う。これはこれからの課題として残った。今までのツケだ。

「学内に学生が自由に使える(?) 工房の存在を知ったー」みたいな話もあったので、学生の興味の幅を広げることができた、という意味では今回のLTは無駄ではなかったと思う。みんな電子工作としてキーボード作ろう。

HHKB(おまけ)

2017/12/11 HHKB買った - 鳥人雑技団なんて地元にはない HHKBは軸にo-ringをはめると静かになるのでおすすめです。

2019-04-18

RubyKaigi 2019のセッションメモ

RubyKaigi 2019へ参加することになって、飛行機の中でこれ書いてます。どのセッションが面白そうか@hsbtさんと雑談したときのメモを残していたので、ここにもまとめておこうと思います。URLに付随するコメントはhsbtさんと自分が雑談していたときのメモです。自分の個人の感想が混じっているので、ご了承ください。

RubyKaigiここは見に行っとけ情報を手に入れた 16 replies

https://rubykaigi.org/2019/presentations/giosakti.html#apr18 コンテナオーケスティングをRubyで書いたよ、って感じのやつ。

https://rubykaigi.org/2019/presentations/ioquatix.html#apr18 FiberっていうThreadよりも細かい非同期処理のシステムを使いこなして超早い分散処理書いたよってやつ。

RMagick, migrate to ImageMagick 7 - RubyKaigi 2019 RMagickっていうImageMagickのラッパーがあるんだけど、それを7に対応させるために泥臭いことしたよっていうやつ。

Pattern matching - New feature in Ruby 2.7 - RubyKaigi 2019 ruby 2.7でパターンマッチ(正規表現とかはまた異なる。Rustとかでは実装されている)をじっそうするよ?っていうやつ。

How RSpec works - RubyKaigi 2019 RSpecの人。単純にすごい。

Practical mruby/c firmware development with CRuby - RubyKaigi 2019 mruby/cじゃん。

Better CSV processing with Ruby 2.6 - RubyKaigi 2019 2.6以降のときにCSVのいろいろ踏んだので単純に見に行きたい枠。

Actionable Code Coverage - RubyKaigi 2019 このパンダはすごいひと。 https://github.com/grosser/parallel とかいう超簡単に並列処理するくんを作った人。この人がシンプルなカバレッジツールを作ったのでその宣伝をするみたい。

Building a game for the Nintendo Switch using Ruby - RubyKaigi 2019 Nintendo Switchにはmrubyが使われているよ、じゃなくて、 ~~Nintendo Switchにmrubyを入れたよ。というやつっぽい。スポンサーに喧嘩打っていくスタイルのやつ。~~ 普通に間違っていた。 A Dark Room for Nintendo Switch - Nintendo Game DetailsというゲームをmRubyで書いたよっていう話だった。

Cleaning up a huge ruby application - RubyKaigi 2019 クックパッドのひとがコード消すためにやったことを並べていくやつ。

Fuzzing native Ruby code with Kisaten - RubyKaigi 2019 Fuzzingっていう問題になりそうなデータをたくさん食わせてバグを見つける手法をRubyで実現する？やつ。

The challenges behind Ruby type checking - RubyKaigi 2019 型チェックをRubyにいれてみたやつ。

Reducing ActiveRecord memory consumption using Apache Arrow - RubyKaigi 2019 むらけんさんだ。Apache Arrowっていう言語を超えてメモリデータをやり取りするソフトウェアの話。

Performance Optimization Techniques of MessagePack-Ruby - RubyKaigi 2019 FluentdとかEmbulkとかつくったすごいひと。

それでは3日間頑張りましょう。