2014年9月18日-20日に開催された、RubyKaigi2014に参加することができました。
RubyKaigi 2011以来の参加。
参加することができて本当に良かった。
もうあれから4ヶ月も（！）経ってしまっていますが、あの時の気持ちを残しておきたいのです。
といっても、時間が経ってしまい新鮮な気持ちは薄れてしまっているのも事実。
でも、今になっても濃く印象に残っていることがいくつかある。それをちゃんと書いておこう。
- 日本語で発表する外国人、英語で発表する日本人、チャレンジする力・実現できている力、すごい。
- 登壇者がみんな生き生きとしていた。
- 女性の発表者が堂々としていてかっこよくて魅力的だった。
- Rubyは決してRubyで完結していなくて、いろんな技術と混ざり合っている。
- Kaigiでしか会えない人が私にもいた。
- 時々は北海道から出て、こういうところに来たいなあ。
- 北海道に住んでいない人と仕事をしてみたい気持ち。
- Rubyistのみなさんあたたかかった。
- 技術を深めるための話を聞きに来たというより、人の話を聞きに来たんだなあ。
- 「深く掘り下げる」作業が自分には足りていない。
- 自分がコミットできることは何なのか。
こうやって書いてみると、いろいろな思いがまだ自分の中に渦巻いている。
この気持ちたちを2015年、うまく消化していきたいと思う。
最後にスタッフの皆様。私たちに幸せな時間をくれて本当にありがとうございました。
「やる」と決断することも、準備をするのも、当日を運営するのも、とても大変だったと思います。
並大抵の気持ちでできることではない。
あのような場を用意してくれたことに感謝します。
以下は私が聴いたセッションとその自分用メモのまとめ。（出張報告用に書いたものを拡張..なので一部表現が堅苦しい）
どのセッションもわりと鮮明に状況を思い出すことができたのにちょっと驚いている。
====
DAY1(2014/09/18)
CRuby Committers Who’s Who in 2014／[JA] Tomoyuki Chikanaga
CRuby Committersの紹介、最新Ruby開発について
* RubyKaigiのイントロダクションとして、今回のRubyKaigiに参加しているCRuby Committersとその功績の紹介。やはり日本人が多いが、外国人も一定数参加していた。
* Committerの方々が誰かを知っていても、その人達が何を作っているのか、どのような人なのかはよく知らなかった。いつも本当にありがとうございます。
Building the Ruby interpreter — What is easy and what is difficult?／ [JA] Koichi Sasada
Ruby VM開発を通して学んだ開発手法・トレードオフ・テストについて
* 品質と期間のトレードオフについて、プロダクトの軸、方針を決定しておくことが重要。Developerとして重要なのは「勉強する→考える→議論する→発表する→実装する→評価する」というサイクルを繰り返すこと。
* Developerとしてのサイクルを着実に回しているささださんを尊敬。
* 私に「発表する」ほど議論したり考えたりできていることがあるか。
Controller Testing: You’re Doing It Wrong ／[EN] Jonathan Mukai-Heidt
Ruby on Rails(MVCモデル）コントローラ部における適切なテスト手法について
* MVCモデルにおけるコントローラのテストは肥大化しがち。重要な部分を簡潔にテストする必要がある。簡潔なテストがかけない場合は、コントローラの設計に問題がある（モデルの肥大化を防ぐためにコントローラに書くという設計はたいてい誤りである）。これらの思想は全てのMVCモデルに通じる。
* Railsのコントローラーのテストってうまく書けないんだよなあ、良いテストの書き方を知りたい、思って行ったのだけど、「テストが描きにくいのは設計がまずいからだ」という話だった。
* 今回1回目の英語セッション。慣れておらず、聞き取れない単語が多かった。
* 以後3日間、サブスクリーンの翻訳に感謝しつづけることになる。
Continuous Delivery at GitHub ／[EN] Robert Sanheim
サービスの継続的デリバリーの手法
* GitHubの運用者によるセッション。2日目のCookPad社もそうだが、大規模Webサービスを運用している会社は「自動デプロイ」「毎日デプロイ」できる仕組みを確立している。GitHub社でのRailsバージョンアップはブランチを切らずに環境変数での切替で乗り切ったという点に、技術力の高さを感じた。
* 自動デプロイできるようになっていれば、問題が発生した時（heartbreatなど）すぐに対応できる、安全も確保できている。
* マーケティングの速度に対応するためだけじゃないんだなあ。
* Railsのバージョンアップの方法が面白かった（ブランチを切らずに環境変数で切り替えられるようにしていた）。
What’s wrong with your app? ／[EN] Keiko Oda
Heroku上のアプリの障害解決策について
* Herokuのカスタマーサポートの観点から、よくある問い合わせとその対応方法について紹介。後半では、Heroku上のアプリケーションをモニタリングするためのツールを紹介していた。これらのツールはHeroku上開発では導入していきたい。
* 発表が素晴らしかった。笑顔でハキハキしていて、魅力的な人だった。
* Herokuのモニタリングツールのことが知れたのよかった。
Non-Linear Pattern Matching against Unfree Data Types in Ruby (Egison Pattern Matching in Ruby)／ [JA] Satoshi Egi
“Egison”という研究開発中のパターンマッチング言語の紹介
* パターンマッチを表現するためのプログラミング言語。確かに、直感的な記述だが、実務で活かせるポイントがあるかは難しいところ。
* 麻雀の点数計算ってロジカルに考えるとすごく難しいんだなあ
* 作者が江木さんだからEgison
Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails [JA] Toru Kawamura
Webサービスにおいて、Web APIを疎結合にするための手法 “Hypermedia”について
* APIをRestfulにするかは要件次第。別のアプローチとしてHypermediaを紹介。Hypermediaはワークフローを含むAPI設計で設計時にSchemaと状態遷を考慮する。今までの設計とは全く異なる思考なので理解して切り替えるのが難しいと感じた。
* 一つ一つはそうだなあと思って話を聞いていたのだけど総合的に理解するまでに至らなかった。
* 今後のWebアプリの設計手法の一つとなっていくのだろうか。
Gem of this Week – building culture and making gem／ [JA] Takumi Miura
社内の開発環境改善手法、社内ナレッジベース、社内ツールの活用ノウハウの紹介
* ドリコム社内での複数プロジェクトでのビジネスロジック共通化について。社内用Gemの開発や利用を推進するための取り組みを紹介。どの社員も尻込みせず普通のこととして参加できるノウハウは自社でも実践したい。
* 「がんがんいこうぜ」タイプの技術者がチームをうまく引っ張っている感じ。
* 同僚も多数セッションを聞きに来ていて、ドリコム楽しそうな会社だなあ。
* 現ドリコムの元同僚に会えて良かった。
DAY2(2014/09/19)
Coming soon…／[JA] Yukihiro “Matz” Matsumoto
Ruby創始者による次期バージョンのRubyの構想
* Ruby3.0として「Concurrency」「JIT(LLVM)」「Static typing」の構想があるとのこと。静的型付け言語については、Rubyの良さであるダイナミックなコード記述を阻害する可能性があるので、サブセットの言語として導入する方針とのこと。
* 朝からちゃんと行って良かった。
* OSS開発は泳ぎ続かなくては死んでしまう・そろそろ燃料を投下すべき時期・未来について考えるときがきた
* これからも進化していくRuby
* Rubyらしさと良い言語とが融合した未来が楽しみになった – 制限を導入するのはRubyじゃなくなっちゃう
Extreme Makeover: Rubygems Edition ／[EN] André Arko
古くから存在するサービス（rubygems.org）の障害対応、バージョンアップ、次期バージョンの構想について
* rubygems.orgが（bundlerによって）大量アクセスされるようになったことを受けて、rubygems.orgを再構築した。更に、Bundlerの次期バージョンでは高速化対応を予定しているとのこと。Rubyによる開発では、bundlerは必須なので高速化による開発速度向上が期待できる。
* issues,issues,issues…. fixed,fixed,fixed….Released!の流れ
* 英語セッションだったけれど現場の感じが伝わってきた。
Deep down fixtures ／[EN] Prathamesh Sonpatki
テストデータのメンテナンス手法、メンテナンスされ続けるテストデータの作成ポイント
* 今回、テストデータが肥大化するという問題をテーマにしたセッションが複数あった。どこの現場でも問題になっていることが伺える。このセッションではFixtureを使った場合に、メンテナンスしやすくなるコーディング方法を紹介していた。
* Fixturesを使うことは少ないけれど、テストデータをどう整理していくかの考え方が役に立った。
* どのトピックもテストを作るときに悩んだことがあるものだった。
<%= link_to "bundle", "update" %> – Make “bundle update” more fun to review／ [EN] Kensuke Nagae
Budlerが出力するバージョン管理ファイル（Gemfile.lock）の差分を可視化するライブラリの開発について
* compare_linker
* Gemfile.lockの差分を人間にわかりやすく表示するためのライブラリ。機能としては完璧ではない（いくつか既知の問題点がある）とのこと。単純な使い方であればPullRequestの時にGemfileの差分がわかるようになるので便利だと思う。
* gemを開発するモチベーションの話が響いた。「アイディアが一番重要だと思っていたけれど、アイディア→ アイディアからものを作る → 改善していく という順に難しくなっていく」「継続と改善が一番難しい」
RailsGirls: Not Only For Girls [EN] Haruka Iwao
プログラマ、IT企業におけるGenderの話。女性がプログラマとして活躍する場を作るための取り組みについて
* 提示されたデータによると、日本だけでなく、外国でも女性プログラマはとても少ない（多くても社内全体の20%といったところ）。Rubyのコミュニティとして女性プログラマが交流できるようRailsGirlsがある（札幌でも開催したことがある）。今自分がどのような取り組みができるのか、考えるきっかけになった。
* こういう話が聴けると思っていなかった。
* 女性を過剰に特別扱いすると自分が生きづらくならないかなあと思ったりもした
* でも、女性のプログラマがふつうになるといいな。できることはなんだろう。
* 「アファーマティブ・アクション」
The Twelve-factor Ruby 「Ruby を良くするための12のポイント」／[JA] Hiroshi SHIBATA
オープンソースコミュニティへの貢献方法、採用されやすいバグレポートの記載方法について
* CRubyをはじめとする数々のオープンソースでコミッターととして活躍する話者が、オープンソースコミュニティへ貢献する方法を紹介。取り入れやすい報告書の書き方や、調査しやすいバグレポートの書き方（再現する最小のコードを添付する、等）日常に役立つポイントが多かった。
* バグレポートを受ける側の生の声「matzにどう “いい” と言わせるか が大事」
* いろいろなオープンソースコミュニティーを技術の面でサポートする@hsbtさんの実行力。
* 「思っている」だけと「やっている」ことの大きな違い。
Scalable deployments – How we deploy Rails app to 100+ hosts in a minute／[JA] Shota Fukumori (sora_h)
Cookpad社での自動デプロイの仕組みと、最近行ったデプロイ速度高速化の取り組みの紹介
* CookPad社では「業務時間内であれば開発者はだれでも本番環境へデプロイできる」ルールとなっているというのにまず驚いた。しかしデプロイ速度が遅いことが開発の妨げになっており、専用の新しいツールを作成し、オープンソース化されている
* mamiya
* 遅い・早くならない → 作ろう！ これがエンジニアなんだな。
Write ruby code to change ruby code／[EN] Richard Huang
AST(抽象構文木）を利用することで、ソースコードを抽象化し自動変換を行うライブラリ、Synvertの紹介
* Synvert
* 今回、最もインパクトのあったライブラリ。Railsのバージョンアップなど避けて通れない問題をなるだけ自動化することのできるライブラリ。現在の業務にすぐに活かすことができそうである。
* 解決したい具体的な現実の問題にマッチするgemだ。
* 導入しやすいようにSandboxなどが整備されているところが素晴らしい思った。
7 years of Ruby & Rails with the same web site／[EN] Zev Blut, Kevin Griffin
iKnow!というRuby on Rails製アプリケーションを7年以上運用している軌跡
* 「同じコードベースで3つのサイトがある」「モンキーパッチの山」「プログラマが現場を離れたため分からない仕様」「未使用コードによるプロダクトコードの肥大化」など、開発者であれば胃の痛くなるような状況からコードを改善していった話。古いコードを思い切って捨てることをはじめ、レガシーなプロダクトへの対応方法を学べた。
* 胃が痛くなるような話がずっと続いていた…日本も海外もつらみは同じだ。
* 改革に取り組んだ、その実行力。
* (せっかくクーポンコードをもらったのに、英語の勉強しないまま無料期間がおわった…)
Power Assert in Ruby／[JA] Kazuki Tsujimoto
Ruby版、Power Assertについて
* プログラムのテストを実行した際の実行結果をわかりやすく表示するPower AssertのRuby版の開発について。Synvertもそうであったが、通常使用するソースコードよりも1つ深い層を使ったプロダクトの紹介が多かった。。
* PowerP(pの拡張で使える) – これはべんりだねえ
* Assertがここまで見やすくなるとテストも捗るなあ。
* 実装は”黒魔術”多い（tracepoint Ripper)
LT
* ドラボーイ！（Eric!!!)
DAY3(2014/09/20)
Speeding up Rails 4.2／[JA] Aaron Patterson
Ruby on Rails 4に向けてフレームワーク本体の速度改善を行ったその手法について
* Ruby on Rails 本体の速度改善の際に使用したベンチマークツールの紹介。速度を改善するのに最も重要な事は正しく計測して把握すること。地道な計測の重要性を再確認した。
* たこ焼き仮面！
* 日本語のダジャレがパワーアップしていた。
* Measure! Measure! Measure!
* 何かを改善するためには、改善する対象がどうなっているのか測ることを怠ってはいけない。
Practical meta-programming in Application／[JA] Kyosuke MOROHASHI
Rubyのメタプログラミングの活用方法について
* 実業務で敬遠されがちなRubyのメタプログラミングだが、適材適所で使用することで大きな効果をあげられる場合がある。メタプログラミングを設計する場合は、問題領域をメタな観点で捉え直してからシンプルに実装しようとすること。具体例として、センサーシステム（写真投稿サービスの投稿内容監視）でのメタプログラミング導入事例について紹介があった。
* 「メタプログラミングは難しいものではなく身近なものだと感じてほしい」
* メタプログラミングに対する先入観は確かにある。
* 今回の具体例はどれもわかりやすく、少しだけ先入観を減らせたかもしれない。
* 「よく知らないから難しいものだと諦めている」面があるなあという気づき。
Everything is Broken: A Story of Hope／[JA] Jonan Scheffler
DNSによる名前解決の仕組みと公開鍵方式について
* 一通り理解している内容であったが、公開鍵と秘密鍵の仕組みを色で表現する例えが大変わかり易かった。今までは南京錠による錠前と鍵の組み合わせの例示が一番良いと思っていたが、それ以上に視覚的にも理解しやすく、良い例示だった。
* 外国人スピーカーによる日本語発表。ほんとうにすごいなあ。
* 登場人物がまた絶妙。
* わかりやすく説明するということ、どんな例で・どんな切り口で話すかのアプローチについて考える。
8bit Game Development With Ruby／[EN] Kei Sawada
RubyのDSLを使用して8bitゲームを作るライブラリ、burnの紹介
* burn
* 友人が出てるよ！という緊張感。
* 8bitゲームをRubyで作るという発想が斬新。おもしろい。
* 「なんじゃこれすごい」←残っていたメモ書き
* 札幌で一緒にBBQした人が壇上に立っていて大盛況で、なんだか感動した。
* 兄弟愛感じた。プロダクトの後ろにはストーリがある。
The role of ruby in the single page app.／[EN] Matthew Werner
Ruby on Railsを使用して SPA(Single Page Application)を作成する場合の最適解について
* 最近のWebサービスの主流である、SPAで、Ruby on Railsを使用する場合、やはりRailsはバックエンドとして使うのが良いようだ。SPAでリクエスト数が大量にならないよう、APIの設計とcacheにより通信回数を減らすプラクティスが紹介された。バックエンドとフロントエンド、どちらで処理をするか設計するところが一番重要なポイントとなるようだ。
* 適材適所の選択眼。
* スライドに使われていた弾丸とコーヒー豆この写真はどうやってとったんだろう。
Walking around ruby forest more deeply／[JA] YUKI TORII
Rubyの言語の奥へ潜り込んでみる。Rubyのソースコードを読んでみる。Rubyがどのように書かれているのかを知る。
* Rubyの森へ散歩に出かけよう。
* Rubyで繋がるご夫婦のやりとり。
* パートナーが良い影響を与え合っている。
* 札幌組とホール前廊下で地べたに座りながらモニターでセッションを見た思い出。
tending the ruby ecosystem／[JA] zzak
Ruby on Railsに完全に依存するライブラリへの警鐘、対応策について
* Ruby on Railsというフレームワークが強すぎるため、Ruby on Railsのバージョンに依存しているgemが大量にある。そのことにより他のgemへ良くない影響を与えることもある。そのようなgemをメンテナンスし続けている話者が携わったプロジェクトと、メンテナンスのモチベーションについて。
* 長く生き残るためにはメンテナンスをする人が必要、メンテナンスをされていなければ引き継いでしまう（開発者にコンタクトをとる）
* 「gemは私たちを助けてくれる、だからgemを助けてあげなきゃいけない。なぜならRubyという言語が好きだからです」しびれる。
Three Ruby usages – High-level interface, Glue and Embedding – Inside Droonga／[JA] Kouhei Sutou
Rubyによる分散検索エンジンについて
* Rroonga(http://ranguba.org/ja/#about-rroonga)開発において重要となった「High Level Interface」「Glue言語」「Embed」について。このセッションでも計測の重要性について語られた。
* すとうさんが話すことを聞きに来た
* High Level Interface：下層レイヤーの機能を高いレイヤーに使いやすく提供する
* Glue言語：Rubyと他言語で作られたライブラリを結ぶ
* Embed：言語をアプリケーションに埋め込む
## 帰りの飛行機の都合で、最後のKeyNoteとClosingは聞くことができず。
====
次のKaigiが開催される時、自分はどうなっているだろう。
そして、何を思っているのだろう。
One comment: