もう3日も経っちゃいましたが、3/24, 25の土日でRails Developers Meetup 2018に参加してきました。
1日開催だった前回からさらに豪華になって今回は2日間2トラックでの開催でした。
日本在住のRailsコミッター3名をはじめ、登壇者も有名な方ばかり。お弁当も懇親会も無料でしたが、むしろ金を払わせてくれという感じでした。
所感
2日間で46セッションあったうちの24セッションを聞きましたが、その中でいくつか抜粋して所感を書きます。
全体的に、初日はマイクロサービスの話、2日目は組織マネジメントの話が多かったように思います。
スライドへのリンクを張っていますが、さすがに埋め込みははばかられたのでリンク先にてご覧ください。
ノンデザイナーのためのコンセプト&ロゴ作り実践講座 feat. savanna.io
ノンデザイナーのためのコンセプト & ロゴ作り実践講座 feat. savanna.io // Speaker Deck
esa LLCのデザイナー、赤塚さん(@ken_c_lo)の発表です。
新しいサービスを考えるにあたっての「良いコンセプト」と「イカしたロゴ」の作り方講座でした。
特にコンセプトの話がお気に入りです。
いわく、「当事者と時代背景が出会う場所がそのプロダクトが世の中において発揮できる価値になる」とのこと。
つまり、「問題を抱えているユーザの内側と外側で擦り合ってない部分を上手く見つける」のがコンセプトを見つける鍵になるんですね。
いまアイデアを練っているサービスについても再考してみようと思いました。
他にも名言連発で、内容がスライドでも丁寧に解説されているのでぜひともご覧ください。
内容は言語問わず、というか、エンジニア以外にも刺さる話だと思います。
惜しむらくは、時間切れで終盤のお話を聞けなかったことですかねー。
Railsアプリの育て方
フリーランスの神速(@sinsoku_listy)さんの発表です。
今回のイベントで一番よかった発表をあえて選ぶならこれです。内容は「技術的負債のたまったプロジェクトでの戦い方」でした。
BtoBのサービスを作っている人間としては身に染みるような発表でした。
というのも、BtoBのサービスには負債が溜まりやすいんですね。理由をざっと挙げると
- 月額課金型のサービスではなく、単発案件ベースでのサービス提供になりやすい
- 「サービスを運用しているだけで飯が食える」状態になりにくい
- コードベースの整理に手が回りにくい
- 納期が厳守であることが多い
- 負債を作ってでも間に合わせなくてはならない状況が起こりやすい
- お客さんも仕事で使うので、多少UXが悪くても我慢して使ってくれる
- パフォーマンス改善のインセンティブが低い
このような感じです。
toCの現場は経験したことがありませんが、パフォーマンスの高さやバグフィックスへの対応の速さが売上に直結するので、コードを綺麗に保っておくインセンティブが高いのではないでしょうか。
発表では、PJ初期にやっておくべきことと負債の溜まったPJとの戦い方を説いておられました。
はっきり言ってどこからまとめたものか(切れる内容がない)のですが、強引に一言でまとめるとするならば「謙虚だが抜け目なく、ときには大胆な態度が求められる」ってことでしょうか。本多正信か黒田官兵衛か、百戦錬磨の古狸ですねこれ。
準備の段階できちんと知見を身につけておくこと、CI/CDなど品質保持の仕組みを自動化しておくこと、機能追加にリファクタを混ぜて行うこと、要らないモノはバッサリ切ること、などなど。
あと、実践的な知見というと、
- 基本7つのアクションから外れそうになったら別のリソースとして捉えて切り直す
- TODOコメントの代わりに時間切れになったら例外を挙げる仕組みにしておく
ですかね。
後者は目からウロコでした。気をつけるのはコードレビューの段階で相手を納得させないといけないことでしょうか。
自分の感想はこの一言に尽きます。
— expa / Shu OGAWARA (@expajp) March 24, 2018
テストがないRailsアプリをリファクタした話
テストのないレガシーなRailsアプリをリファクタした話 // Speaker Deck
株式会社スタディストさんのスポンサーセッションです。
個人的にイベント最大の名言がここで出たと思います。
質疑応答にて、スピーカーのErdos氏いわく、
私が外国人としてよく言われるのが「文化の違いですね」というセリフなんですが……
そんなのは知ったこっちゃないんですよね。
(動画公開がまだなので記憶をもとにニュアンスだけ)
だそうです。
質問は
テストコードを書く文化が無いと、それを受け入れてもらうのも大変なんじゃないかなぁと思っているのですが、 同意してもらうために工夫したこと等もしあれば教えて欲しいです。
というもの。
おっしゃる通りで、文化がどうあれ、良いと思った行動をしていくべきですね。NO 忖度。
わかっちゃいるけど難しい。特にこの日本では。
Active Recordデータ処理アンチパターン
ActiveRecordデータ処理アンチパターン / active-record-anti-patterns // Speaker Deck
Gunosyの榎本(@toshimaru_e)さんの発表です。
すぐ業務に使っていける度がナンバーワンの発表でした。
このプレゼンのなにが良かったかといえば、アンチパターンに名前をつけたことだと思います。
「ボヤッとした概念に名前をつけることで爆発的に広まる」ってことってありますよね。
ネット流行語に多いのですが、例えば
などなど。名前を与えることで認識可能になるのです。
なぜ名前を「つけた」と分かるかというと、
アンチパターン名の出典を教えてください
と質問したところ、「名前の出典は僕です」と返ってきたからです。かっけえ。
また、具体的なコード例(あからさまに酷いやつから中級者もやりがちなミスまで)を出して話されていたのも非常に良かったです。変化の過程が分かりやすかったですし、話が自然にストーリー仕立てになるのでスッと入れました。
さらには、ベンチマークしてきちんと定量的な結果をスライドに入れるという徹底ぶりです。
有名塾講師の授業のような、お手本のような発表でした。見習いたい。
他にも印象に残ったセッションはたくさんありましたし、Twitterでずーっと実況を見てると「裏番組面白そう」ってなったことも結構ありました。
体が2つほしかった……!
動画公開も近々されるそうですが、さしあたり資料をまとめて下さった方がいるので、みなさんぜひともどうぞ!
全体の感想
刺激的な2日間でした。
実践的な講義から、技術者としての考えを本気でぶつけに来た方、体験を楽しく語る方、さまざまでしたがどの話も面白かった。
Railsは覚えることが多いため知識と経験の量がモノを言います。ですから、はじめて1年未満・仕事にして半年未満の自分はついていけない話も多かったのですが、「楽しかった」と言えるのはやっぱりRubyコミュニティの懐の深さでしょうか。
話を聞きながら思ったのは、「技術プレゼンは手を動かしてナンボ」ってことでしょうか。
知識を伝えるプレゼンなら、
- 勉強する
- まとめる
だけで良いんですが、技術プレゼンだと
- 勉強する
- 勉強した内容を使ってみる
- 共有すべき事柄やオリジナルの知見、考察が生まれる
- まとめる
という過程を踏まなくてはならないのです。
「もっと手を動かさないと」と思いましたね。
今年の目標は大雑把に言えば「アウトプット」で外部発表に積極的に行っているのですが、最近ネタ切れ気味だった理由がわかりました。
勉強したことをそのまま話すだけだと縮小再生産ですが、実際に手を動かすことで自分なりの知見が生まれてくるんですね。
しかし、これだけ大規模なイベントの運営は本当に大変だったと思います。
主催者およびスタッフの皆様、本当にありがとうございました。
12月にも計画されているそうなので、参加できたらいいなあ。
1月末に合唱の本番があるので忙しい頃と思いますが、練習とかぶらないことを祈ります。
おまけ
最後におまけ。2日目はドリコム社での開催だったのですが、帰り道で撮れた夜桜の写真がとても綺麗でした。
ではでは。