Rails Developers Meetup 2018 感想
Day 1
安全かつ高速に進めるマイクロサービス化
トレジャーデータ社でも無茶な作りのシステムで苦労したりすることあるんだなーというのが新鮮だった。超人集団だからソフトウェアも完全無欠な印象がある。(自分の中で、日本のWeb系エンジニア界隈における超人集団の会社は、10年前がはてな社、5年前がクックパッド社、現在がトレジャーデータ社という風に移ろっている)
明け方まで自分のスライド作りをしてて寝不足だったので細かいところを意識が飛んでて聞き漏らしたので、動画が公開されたら見直したい。
学校をより良くするために、エンジニアができるたった一つのこと
事業ドメインが同じというか競合なのでいろいろ事情が似てるなーと思った。
発表後にささたつさんと少し話して自分の発表内容の話もして(マイクロサービス化)、「同じ問題を抱えているのに結論が逆なのは面白いですね(クラッシー社は一旦一つに統合する戦略)」、という話をしたが、実は発表では割愛したけどクイッパー社はマイクロサービス化に合わせて monorepo 化も進めており、サービスは細分化していくがデプロイなどはむしろ単純にしていく戦略をとっている(k8s のクラスタ?を常にまるごとデプロイする、みたいな感じらしい。そのプロジェクトにあまり関わっていないので詳しいところを説明できるほどには理解していない)
365日24時間稼働必須サービスの完全無停止DB移行 〜MongoDB to Amazon Aurora〜
データ移行の戦略が全体的に「ソフトウェア・エンジニアリング」って感じでかっこよかった。フラグごとのポリシーの設定の仕方とか、 DB アクセスをプロキシする層をかませそびれてないかどうかをチェックする方法が「mongo driver にパッチ当てて警告ログ出すようにして production デプロイして数日ログを眺める」とか、実践的。「jruby 使うことになるだろうなーと思いながら最初から jruby でも動くように作った」とか、その勘もわかるしすごい。「最終的に別のプログラミング言語のディレクトリが爆誕」とあったのでてっきり go か rust でも出てくるのかと思った。7億ドキュメントの持ち主は何者だったのか、7億ドキュメントが平均的なユーザーと比べてどの程度異常だったのか気になる。
Microservices Maturity Model on Rails
「マイクロサービス化の意義は、各サービスがそれぞれのタイミングでリリースできるので、ビジネスの速度を早められる」みたいなことをたしか言っていて、「それだけじゃないよなー」と思いつつも、ビジネス側の人に意義を理解してもらうには一番効く説明方法になるだろうなと思った。
Day 2
Observability, Service Meshes and Microservices
マイクロサービスまだ不勉強なので内容を理解できたとは言い難いが、クックパッド社は相変わらずすげーなーと思った。
余談だけど、個人的にここ数年の「Web系エンジニア界隈ノリ」が苦手で(LGTM 画像とか、アニメとアイドルの話をスライドに盛り込むとか、ウェーイとか)、なぜかクックパッド社の人たちのプレゼンは、独特のノリが盛り込まれていつつもあまり苦手に感じなくて、社風というか文化みたいなものなのかなーと思った(なんとなく柔らかい・優しい感じ。「サービスメッシュ自作勢」とか、「○○勢」っていう言い回しも、近年の若手Webエンジニア界隈の用語だと認識していて、基本的にこの言い回しを使う人を見かけると「あっ、こいつとは気が合わない」と感じてしまうのだが、今日は不思議とそうは感じなかった)
冴えてるRailsエンジニアの育て方
選考において気にしてるポイントはほぼ同じだった。というか、俺が気にしてるポイントは全て押さえられていて、プラスアルファについて学びがあった、が正しい。
- コード試験の課題を課すとき、予実(完成までの見積もり作業時間と、実際にかかった時間)を出してもらう、というのは考えもしなかった
- スキルとゲームプレイのヒアリングシートを記入してもらって面接時の質問ネタにする、というアイデアは素晴らしいと思った
Railsと非Railsの間
default_scope の活用例について、 Day 1 の wovn.io の人のアプローチが使えるんじゃないかな、と思った(どっちもアリなのかな、と思いつつ、フレームワークの機能で暗黙に動作するよりも、自分のコントロール配下におけるもののほうが制御しやすくて信頼できそうな気もする)
バス因子が自分でバス因子を脱するための方法
私的ベストトーク。なんだけど、途中で心を揺さぶられるような内容があって、それ以後の話が頭に入ってこなかった。
それは「自分が他の誰よりもはやく誰かの『困りごと』に対応するのが正義だと思ってやってきたが、『なんでも知っててなんでもできるあなたが誰よりもはやく対応し続けると、他のひとから機会を奪っている。だから対応してはダメ」という話で、もちろん実際にはこんな強い言い方ではなくてもっと優しさのあるコミュニケーションだったのだろうと思うし、結果的に挑戦・学習する機会を奪っているのも事実なわけでもっともな意見だと思うのだが、「自分が最速で対応するのが正義」は 100% 正しい。正しいのに、自分が正しいと思うことをやっていたらいつの間にかそれが他者や組織にとっての悪になってしまい、自分が正しいと信じることが「やってはいけないこと」になってしまった、というのは、悲しすぎる。悲劇だ。正直、「いや、他の奴らが対応遅いのが悪いだろ。速く対応してるのは偉いじゃん。なのになんで『やってはいけない』になっちゃうんだよ」と思ってしまった。
スタートアップの立ち上げ時期から働いてて、「なんでも自分でやるのが当たり前」という意識でいるひとと、そうでないひとの間のギャップ、みたいなのもあるのだろう(発表でも触れられていたような気がする)。たぶん、こういう出来事がターニングポイントになる気がしていて、自分の信念を貫きたいという想いが勝るなら「自分が最速で対応することが正義でいられる場所」を他に探すのだろうし、自分の信念を曲げてでも「今ここでやっていること(事業とかサービスとか)」に意義がある・価値を置くなら、自分を変えるのだろう。
Qall - Docker で作る Quipper の開発環境
同僚の話だし会社でいくらでも聞けるから聞かなくてもいいかなぁと思ったりもしたけど、 Qall そのものの話以外の部分が良かったので、発表を見に行って正解だった。
RubyKaigi 2017 のときにも感じた記憶があるが、彼の発表は問題意識の視座が高いのがすごいと思う。近年、技術カンファレンスなどで発表されることは、「ある人・組織などにおいて、特定の背景・文脈・ユースケースにおいて云々」という風にスコープが狭められているものが多い(自分の発表からして、もろにそういうものだ)。それはそれで勉強になるし、コンテキストを共有できる範囲に固定しないと見当違いの反論をされたりして困るので予防的になってきたという面も否めないのだが、「Docker を開発環境に使う、ということにまつわる諸問題について皆と議論したい」という彼の問題意識・問いかけは、「届ける人間・コミュニティの範囲」という点でスコープをある意味まったく狭めようとしない。こういうスケールで物事を考えられるのはすごいことだと思う。
たぶん全然関係なくて誰にも理解も共感もされないと思うけど、 Text::Xslate という Perl のテンプレートエンジンライブラリがあって、これは高速さが売りなのだが、「テンプレートエンジンというソフトウェアの特性(文字列操作が多い)を考慮して、文字列操作を高速に処理できるバーチャルマシンを実装するアプローチを採用して高速化した」という作者談があり、これを思い出した。ふつうは「自分・自社のユースケースだとこういう事情で既存のテンプレートエンジンでは速度が問題だったので、高速化した(そのテクニックとして VM 云々)」という話で終わってしまうと思うのだが、これを一段抽象化して「そもそもテンプレートエンジンとは何がどうで」という話ができるというのは、やはり思考の段階として数段高くなければできないことだと思う。
「社内ツール作成サークル」活動記録
「ソフトウェアエンジニアとして、使い方がわからないツールなど無い、常に『こんなこともあろうかと』ってできたい」という話が心に染み入った。他、いろいろ全体的に良かった。ノウハウ的な部分もいろいろためになった。
一日目の昼間は昼前の発表からランチの時間帯まで、スライドを作ったりマチマチ社の藤村さん(元同僚)と近況報告でお喋りしたりしてた。たぶん数年ぶりに再会したけど、いろいろ背景を共有できてる人と話すのは安心感あるなーと思った。
Rails Developers Meetup 2018: Day 1 で『Quipperにおける「関心の分離」の歴史』という発表をしました
発表で使ったスライドはこちらからどうぞ。発表前にスライドを公開しようとして、エクスポートした PDF / .pptx を Speaker Deck と SlideShare にアップロードしたら変換エラーになってしまい、苦肉の策で GitHub リポジトリに置いたりしてみたのですが、 Google スライドで作ってるんだから単にリンクを共有するだけで良かった。とはいえ変換エラーは気になるので、解決方法を知っている方がいたら教えてください。
ご視聴いただいた皆さま、ありがとうございました。持ち時間を使い切ってしまい、質疑応答の時間が無くなってしまいました。すいません。しばらくの間 ama をチェックしようと思っていますので、質問があればコメントください。 @kyanny に直接質問いただいても構いません。
主催・スタッフの皆さま、ありがとうございました。今回が Railsdm 初参加だったのですが、事前のメールでのやりとりのタイミング・内容、当日の会場の運営・進行などなど、これまで参加してきたイベント・カンファレンスの中でも指折りの手際の良さで、感心しました。パーティーとか余興の成分が少なめで「トークを観る・聴くことが目的」という硬派な雰囲気も、昔の技術系勉強会を彷彿とさせて良かったです。
例によって直前まで発表の準備をする体たらくで、練習不足のまま本番を迎えてしまったのでどうなることやらと内心ハラハラしていたのですが、奇跡的にうまくやれてよかったです。イベント全体の「空気感」みたいなものがフォーマルすぎずカジュアルすぎずというか、リラックスできる雰囲気だったのに助けられました。
Google Trips すごい
出張の予定が入ったので、前から少し気になっていた旅程管理サービス TripIt のアプリを入れたら、関連アプリに Google Trips というのもあり、試してみたら素晴らしく良かった。
TripIt はフライトやホテルの予約メールを転送すると旅程を整理してくれるもののようで、おそらく Google アカウントと連携してメールボックスをスキャンして自動的に旅程を作ってくれたりもするのだと思うが、 Google Trips はアカウント作成も連携も全く不要なのがいい。 Google アカウントでサインアップ、何回か「ok」をタップする、以上。見慣れたマテリアルデザインで使い方に迷わないし、スキャンされたフライト情報も誤差なし、必要な機能はしっかり備えた上で観光ガイド的な情報も充実してる(たぶん)。現地ガイドのデータなどをダウンロードしてオフラインでも利用できる。
使い始めて数秒で、「あ、もうこれでいいや、これで十分」と満足し、メールアドレスの認証を終えたばかりの TripIt は旅程の情報を読み込ませることなくアプリを削除してしまった。 Google に囲われすぎかなぁという考えがチラッと脳裏をよぎったが、まぁ Google になら管理されてもいいかな。
Google カレンダーに旅程を登録する機能があったりするとさらに嬉しいのだけど、整理された旅程を見ながらであればカレンダー入力くらいは自分でやっても大した手間ではない。フライトも宿泊先も、予約完了メールの中から必要な情報を拾い読みするのが面倒くさいので、そこをコンピュータがやってくれるのはたいへんありがたい。
def ppp(o); pp o.as_json; nil; end
link-edge(prod)> ppp st1.answer_usages.first {"answer_attempt"=> {"_type"=>"MultipleChoiceAttempt", "choices"=>[BSON::ObjectId('57984b7c9c1cfd59cf00002c')], "correct"=>true, "id"=>BSON::ObjectId('5963fe1e0e056d709b002235')}, "correct"=>true, "created_at"=>Mon, 10 Jul 2017 22:22:22 UTC +00:00, "id"=>BSON::ObjectId('5963fe1e0e056d709b002234'), "last_use"=>Mon, 10 Jul 2017 22:22:22 UTC +00:00, "nth_attempt"=>1, "question_id"=>BSON::ObjectId('57984b439c1cfd7d1f000034'), "question_position"=>0, "question_usage_id"=>BSON::ObjectId('5963fe1e0e056d709b002233'), "session_key"=>"5963761923215765b600004e_578dd6f89c1cfd00200002e0_1", "student_id"=>BSON::ObjectId('592eaadcbc62225786004aec'), "updated_at"=>Mon, 10 Jul 2017 22:22:22 UTC +00:00} => nil