Yokohama.rb Monthly Meetup #82に参加した

2017-07-08（土）のYokohama.rb Monthly Meetup #82参加メモです。

Yokohama.rb Monthly Meetup #82 yokohamarb.doorkeeper.jp

2017-07-08（土）17:30 - 20:30 Yokohama.rbは、横浜周辺のRuby技術者たちが集まってRubyに関する何かをする地域Rubyistコミュニティです。 概要 発起人: @dan5ya twitter: https://twitter.com/yokohamarb togetter: http://togetter.com/t/yokohamarb facebook group: https://www.facebook.com/groups/259874337401606/ coderwall: https://coderwall.com/team...

Rubyレシピブック

レシピ257から260まででした¹。259, 260についてメモ。

259: リモートホストが稼働していることを確認する

リモートホストが動いているかを確認するためにTCP接続を試みるメソッドについてのレシピです。

本文中では、TCPの7番ポートで受け付けるechoサービスに対して、TCPで接続を試みることでリモートホストが動いているかを確認しています。とはいえ、実際にやってみると、TCP7番を開けているサーバはほとんどなさそうでした。

コード例では timeout ライブラリによって導入される Kernel#timeout を使っています。このメソッドはRuby2.3からdeprecatedになっており、使うと次のメッセージが表示されます。実際には Timeout#timeout へのエイリアスになっているようです²。

Object#timeout is deprecated, use Timeout.timeout instead.

メッセージのとおり、現在は明示的にモジュール関数 Timeout.#timeout を使うのが望ましいでしょう。

Timeout.timeout do
  TCPSocket.open(host, service) do
    # pass
  end
end

260: 別プロセスのRubyオブジェクトにアクセスする

dRubyを使った分散オブジェクトの操作についてのレシピです。dRubyを実際に動かしてみたのは初めてだったのでおもしろかったです。次のようなことを話していました。

• リモートのオブジェクトに対して呼び出したメソッドはサーバ側で実行される
  • クライアント／サーバ間ではMarshalを使ってやり取りしているが、ブロック内のコード（要はProc）はMarshalでシリアライズできないので、クライアント側で実行される
• 2,3文字ぐらいの文字列を1000万要素ぐらい入れた配列をクライアントからサーバに送ろうとすると、なぜかクライアントが死ぬ…
• dRubyを使ってカードゲームのUNOを作ると楽しそう

その他

以前書いた「DockerでRailsの開発環境を作る」ブログ記事を@miyohideさんが読んでいたということで、あらためて何をやったか紹介しました。

次のようなコメントをもらいました。

• たとえばDBへの接続のためにIPアドレスは必要？
  • docker-compose.yml でつけたサービス名をそのまま使える
• 本番環境はコンテナではない？
  • 今は開発環境だけ
    • エンジニアとデザイナの環境を統一して、うまく動かないときの原因切り分けを楽にしたかったのが最初のモチベーションのため
• ホストからコンテナへのファイルコピーが遅くなってくるのでrsyncを使っている
  • 現状そこをネックに感じるレベルには達してなかった
• コンテナが溜まってくるのはどうしてる？
  • コマンド実行は --rm をつけてやってもらう
  • こんな方法もあるそうです

docker system prune
で掃除できるのか。 #yokohamarb

— ゆーいち@雑魚豪鬼 (@u1tnk) 2017年7月8日

また、@takeshyさんからDDD（ドメイン駆動設計）に基づいてRailsを使ったAPIサーバを作り直した事例について共有していただきました。

DDDを使ってRailsアプリをリファクタリング - Qiita qiita.com

経緯 casyというインターネットを使って手軽に家事代行を頼むことができるサービスのプログラマをしています。 Webだけでなく、スマホアプリも出すことにあたり、Webアプリサーバ(Rails)から機能を切り出し、APIサーバ(Rails)を別途作成し、Webアプリの場合は...

次のようなお話が聞けました。

• ドメイン層は純粋なドメインロジックのコードだけになるのでわかりやすい
• リポジトリ層はActive Recordを使わずに生SQLを書くことが多い
• いかにimmutableな値オブジェクトに寄せるかがキモ
• ルートエンティティ経由でドメインロジックを呼び出す
• コントローラ層は params の処理ぐらいだけやってアプリケーション層に委譲
• アプリケーション層はコントローラ層のアクションと一対一対応している
• ドメインの処理を終わった時などにイベントを飛ばして、それを監視しているサブシステムが通知処理などを実行する
  • メインのドメインに通知処理などが入らない
  • ユーザ作成など、実行した処理がすべてイベントとして記録されるので、ログ活用やデバッグが楽になる

懇親会

次の結論に達した気がします。

特定のパラダイム（言語、フレームワーク）一本足打法は危険なので知見を広めましょう、が今日のまとめだろうか？ #yokohamarb

— katsunori kawaguchi (@hamakn) 2017年7月8日

次回はまだ未定のようですが、普段どおりであれば8月の第2土曜日に開催されると思います。