DDD ディストーション駆動開発

ギターと音楽とRubyを愛するエンジニアのblog

Rails Girls Tokyo 9thにコーチとして参加した

Rails Girls Tokyo 9th

Railsを学んでみたい女性のためのワークショップ、Rails Girls Tokyo 9thに、Railsを教えるコーチとして参加しました。

Rails Girlsを知りたい人、コーチやってみようと思っている方のために感想など書いてみます。

コーチから見たRails Girls

ガイドがしっかりしている

インストール、ワークショップは以下のガイドに従って進めます。

Rails Girls - Japanese

これに従ってRailsのインストールを行い、Rails newして課題を進め、Herokuでアプリを公開できたらあとは参加者の興味に合わせてカスタマイズしていく、というような進行を取っていました。

なので、何を教えたらいいのか分からない、とか、いきなり凄く難しいアプリを作りたい、って言われてコーチがあわあわするということはないようになっています。

ガイド見てると、あっという間に全ての課題を終えてしまいそうな気がしますが、実際のところDevise使うところまで進むことはあんまりなさそうな感じでした。

コーチとGirlsが同数

参加者(Railsを学ぶGirls)が約20名で、コーチも約20名、とマンツーマンでした。エンジニア経験のない参加者が多いので、進み方や興味を持つ点、知りたいことも人それぞれなので、マンツーマンでサポートできたことで参加者の満足度が高まったんじゃないかという気がしました。

ただ、完全にマンツーマンで見るわけではなく、4人〜6人のチームに対し経験豊富なコーチリーダーを含む4人〜6人のコーチがついて、みんながやりやすいようにいい感じに進める、という感じになっています。

そんなわけで、私のような初めてのコーチもコーチリーダーや他のコーチに色々聞きながらなんとかコーチ役をこなすことができました。

コーチの役目は当日以外にもある

コーチはワークショップ当日以外に、「素振り」「インストールデイ」に参加します。

ガイドがしっかりしているのは、実はコーチ達がイベント前に一通りガイドを通してみて、確認して、ガイドを更新しているからだったりします。手順通りに進めてちゃんとインストールできるか、とか、Railsのバージョンが上がってガイドの内容と変わってないかとかを確認し、何かあればガイドに対してプルリクを投げて修正します。

これをコーチの「素振り」と言います。

「インストールデイ」はワークショップの前日の夜実施します。

文字通りRailsのインストールを行うのですが、参加者はwin/mac様々なPCを持って来られるので、なにげに高度な対応を求められることがあるようです。

エディタはAtom縛り

これはコーチ同士の無駄な争いを避け、コーチの趣味を参加者に押し付けてしまうことがないようにという配慮です。Atomは便利なエディタなのであまり困ることはないですが、インストールしたての「素」の状態であり、コーチが普段使ってるような便利ツールが入ってないことにはちょっと注意が必要かなと思いました。

例えば全角スペースがうっかり混入する、書いたけどファイルを保存してない、とかがメジャーなトラブルかも。

コーチ陣が凄い

私のようなエンジニアもいますが、色んなイベントで登壇している方やCTO、技術顧問の方や本書いている方などがコーチで参加しています。周りのコーチの方を見てると私が教えて欲しいくらいです。

コーチも結構楽しい

無料のイベントなので参加者はメリットだらけなのですが、ボランティアで来ているコーチにとっても結構楽しいイベントでした。

スタッフTシャツを頂ける

今回はGMOペパボさんのsuzuriによるご提供でした。スタッフ全員同じものを着るとなんかお祭りみたいでテンションが上がりますね。 

ちなみに会場提供はSpeeeさんでした。ほんと素敵なラウンジですね。

学びがある

普段の仕事でscaffold使う機会って相当少ないので、お手本的なRailsのコードを久しぶりにたっぷり眺めた気がします。あれだけ書くだけで動くコードが出来上がるって改めて見ると衝撃的ですね。

あと、人に教えるために自分の知識を取り出して、教えている人の理解度に合わせて説明しようとすることで、自分の頭の中が整理されていくような感覚がありました。画面に流れるログを追いながら「今起きてるのはこういうことなんですよ」って口で説明しながら自分自身でも「ああ!そうそう、そうだった!」って再認識したりしてました。

様々なおもてなし

当日の様子がTwitterで見られるのですが、おやつ、お弁当(金兵衛!)が出る他、ケータリングと、美味しいお酒とともにコーチたちのLTを楽しむ時間がありました。

#railsgirlstokyo - Twitter検索

 お酒好きなだけ飲みながらLT眺めるなんてTokyuRubyKaigiのようですね。

 

アフターアフターパーティー

会場でケータリングとLTを楽しんだ後はお疲れ様会的なアフターアフターパーティーが待っていました。一日中喋り疲れた喉をいやすビールと、他のチームのコーチや参加者の方との色んな話に花が咲きます。

すばらしい話

松田さんによるすばらしい話が聞けました。

ここだけ見ると出オチみたいに見えますが、素敵な話でした。

 今日の参加者の方達がこれから先Railsを学んでいく中で、「あれ、この、松田明って人もしかして。。。」っていう瞬間が訪れた時に本当にすばらしい話を聞いたんだな、って思うのだろうな。

まとめ

コーチ応募迷ってやめてしまった人はもったいないから次回は速攻申し込んだ方がいいです。まずはRails Girls TokyoのTwitterをフォロー!

Rails Girls Tokyo(@railsgirlstokyo)さん | Twitter

railsgirls.com

Shinjuku.rb #59 Hanamiの面白さを再認識した

Shinjuku.rb #59 Hanami

もう先月の話ですが、Ruby製のWebApplicationFramework Hanamiがテーマだったので、久々にShinjuku.rbに参加しました。

shinjukurb.connpass.com

Hanamiはやっぱり気になる

最近Hanamiのgetting started見ながら個人アプリ作っていたので

主催のtrebyさんとitkrt2yさんのテーマトークの間で、 前に使ったLTの資料と、Hanami

触ってみた感想を交えてLTさせて頂きました。

RailsのつらみとHanami

なんかめんどくさいなあ、というのが正直な気持ち

getting started見つつHanamiしてみた感想は、Railsと比べて圧倒的に「めんどくさい」ということです。

action作るたびに新しいファイル作って、include Web::Action書いて。viewもテンプレートとロジック用のファイルを用意して。あっちこっちファイル開いてちょこっとだけ書いて、というのを繰り返していく、というのが、Railsに慣れた頭には「めんどくさい」と感じました。

小規模なアプリならRailsでさっさと作ったほうが楽だし早くて、きっとHanamiは大規模なアプリ向けなのだと思うのですが、ただこのお作法で大規模なアプリを作った時に、このファイル数に頭がついていけるのだろうか、、、というのが私の感想でした。

HanamiはSimpleだけどEasyじゃない

そんな自分の感想を予想していたかのようなitkrt2yさんが、LTの中で紹介してくれた「Simple is not easy」、素晴らしい内容でした。

 

ohbarye.hatenablog.jp

 

 RailsがEasyに寄せていて、HanamiがSimpleに寄せている、というのはとても納得です。

Hanamiはモノリスファースト

こちらもitkrt2yさんが紹介してくれた話です。

Hanamiは「apps」ディレクトリがあり、複数のアプリを相乗りさせる前提で作られています。

RailsでもEngineをマウントすることで同じような構成にすることはできますが、appsにそのまま置けばいいHanamiの方が随分簡単に実現できるような気はします。

 新しいものを作る時に、いきなりマイクロサービスで始めるのはYAGNI的な考え方からすると、やりすぎになっていることが多いのかもですね。

Hanamiをもっと使い込んでみたい

もっと色々面白い話があったのですが、一ヶ月経ってすっかり忘れてしまいました。。。

Hanamiについて学んだことで、Rails以外のWAFを見たことで、巨大Railsアプリのつらみの解決策が少し見えてきた気がします。引き続きHanamiをwatchし続けていきます。

 

Rails Developers Meetup 2018 なぜかコミュニケーションの問題に行き着く不思議

Rails Developers Meetup 2018

↓のエントリではマイクロサービス系のセッションについての感想をまとめたので、今回は別のセッションについて。

Rails Developers Meetup 2018 世はまさに大マイクロサービス時代 - DDD ディストーション駆動開発

 神速さんの発表は私的ベストセッション

神速さんのセッションは、Railsやってる全ての人に教えたい、と思うくらい素敵でした。月曜日早速社内で共有しました。

私がRails始めたばっかりの時にこのセッション聞いてたら、あんなクソコードは書かなかったし、それがコピペされることもなかったのに、、、本当に耳の痛いセッションでした。

sinsoku.hatenablog.com

scaffoldで生成されるコードを読む

Rails始めたばかりの時「業務でscaffoldなんか使えねーよ」って思い込み、最近に到るまでscaffold忘れていましたが、本当にもったいないことしたと思っています。

scaffoldのコードはRails謹製のお手本な訳で、既存のコードがこれと似ても似つかない作りだったら、既存のコードの作りが悪いのだと思うのですよね。

Rails始めてから4年間、自分なりに色々考えた結果、「Railsっぽくないやり方を選ぶ」というのは大概間違いの始まりである、と気づきました。だって自分がDHHさんより頭いいわけないからね。

(すぐRailから外れたがる人のことを心の中で「CrazyTrain野郎」と呼んでいます。)

少しづつ弱体化させる

リファクタリング、っていうと「がっつりリファクタリングの時間が必要だ!」みたいになりがちですが、そんな時間取れるわけないです。「最終形としてはこうしたいけど、一気にそれをやる時間はないから、今回はここだけ最終形に近づけておく」みたいなことを繰り返して行くしかないと思うのです。

ただ、「最終形はこうだよ」が共通認識になって「みんなでここを目指そう」という状態を作るのって難しいですよね。。。

がんばっていくしかない。

五十六メソッドとペアプロ

やってみて

言って聞かせて

させてみて

褒めてやらねば

人は動かじ

 冴えてるRailsエンジニアの育て方 // Speaker Deck

Aimingさんでは上記のような観点からペアプロを実践しているそうです。

私もこの言葉好きなので、ちょっと嬉しくなっちゃいました。多分これって、

  • 言った本人がそれを体現していること...説得力が違う
  • やったことを褒められること...見てもらえたこと、行動が正しかったことがわかる

っていうのがとても大事なんですよね。そういう意味だと、ペアプロやった後も、これがいいよと伝えた内容が実践されていたら、コードレビューなりで褒めるの大事だと思います。

自分はKPT使ったふりかえりの「K」で「このPRのここのコードすごく良かった。こういうもの書くときはこれを真似てほしい」というのを伝えるようにしています。

(そのために、ふりかえりに参加するメンバーのPRは休憩時間とかにめっちゃ目を通してます)

概念を掴み取る力と、それを伝える力

設計とは

・概念に名前をつけること

・地図を描くこと

・境界を決め、それを守ること

Realworld Domain Model on Rails // Speaker Deck

 joker1007さんのこの言葉。設計に必要なことが、端的に表現されていて本当に凄いです。しかも言葉選びがカッコイイですね。

設計レビューするときに知りたいのは「どのClassにどのメソッドを、、、このメソッドは、、、」とかいうものではなくて「この機能のためにこういうことをするClass達を作る」っていうものなんだよ、、、コードは.rbに書いてくれ、っていつも思います。

機能を実現するのに必要な概念が出揃ってて、それぞれ命名が適切なら、だいたい大丈夫だと思うのですよ。

ただその、「これはこういうことだよね」っていうのを掴み取ることと、掴んだものを適切な言葉に置き換えていくことって難しいですよね。

描いた地図の共有が最も難しい

人が作った機能を改修する時は、作った人が描いてた世界に思いを馳せて、それを壊さないように、そっとやりたいことを乗せて行って欲しいのですよ。それっぽい箇所にそっとif文増やしたらやりたいことできた、とか、力技で乗り切った、とかやると、少しずつ世界が歪んで、気づいた時には「どうしてこうなった?」ってなるんですよ。

まとめ:コミュニケーションの問題に行き着く不思議

みんなで共通認識を作るの難しいね、とか、やって見せて褒めよう、とか、掴んだ概念をうまく言葉に落としこもう、とか、なんかエンジニアリングの話なのにコミュニケーション能力求められている不思議。

フレームワーク使った開発、チーム開発って結局それが全てなんですね。

Rails Developers Meetup 2018 世はまさに大マイクロサービス時代

Rails Developers Meetup 2018

これ、イベントページ立った瞬間申し込んだのですが、気づけば大量のキャンセル待ち行列。正直「土日潰れるのはなあ、、、」と思ったけど申し込んでよかった。凄く濃い2日間でした。

マイクロサービスとシステム分割の話

セッションの1/3くらいは何かしらマイクロサービスがらみの話をしていたように思います。個人的にマイクロサービスに興味があり、今回はマイクロサービスの話を中心に聞いていました。

高橋さんがこんなTweeetをされていたのが印象的でした

「マイクロサービス」って単語は以下2つの文脈で語られているような気がします。

小さなサービスうじゃうじゃ

私は「マイクロサービス」と聞くと、前者のNetflix的な、本当にマイクロなサービスがうじゃうじゃいるのを最初に想像します。なんかこの記事のタイトルによるとNetflixには数千(!!)のマイクロサービスで成り立ってるらしいのですが、、、(全く別種のサービスが数千種類いるわけじゃなくて、インスタンス数的なことですよね?記事最後まで読みたい。。。)

tech.nikkeibp.co.jp

私が聞いたセッションだと、Cookpadさんはこちら寄りなのですかね

Observability, Service Mesh and Microservices // Speaker Deck

なんというか、「サービスが小さいことのメリットを享受したいから積極的に小さくしていく」という姿勢なのかな、という気がしました。

モノリシックアプリの分割

一方後者は、「システム分割にマイクロサービスアーキテクチャを取り入れるぞ」という話。

私が聞いたセッションだと、TresureDataさんがこちら寄りなのかな、 

安全かつ高速に進めるマイクロサービス化 / railsdm2018 // Speaker Deck

私の勝手な印象なので語弊があると申し訳ないのですが「くっついてるせいで困ったことが起きているから分けようぜ」という姿勢に感じました。

小さいことはいいことなのか?

個人的には、これから新規サービス作るならぜひAWSでk8sでマイクロサービスで〜というのをやってみたいとは思いますが、余程大きなwebサービスでもなければ、名前を覚えられないほどの個数のサービス数になるのはなんか違うかなーという気がしないでもないです。

最高の解決策:

みんなで一つのチームになり

全員が全てをメンテできるようになり

そもそもマイクロサービス化を不要にする

安全かつ高速に進めるマイクロサービス化 / railsdm2018 // Speaker Deck

 @k0kubunさんのスライドの引用です。

全員が全てをメンテできる状態なら、分断されたたくさんサービスよりも、モノリシックアプリの方が開発も運用も簡単だと思うので、小さくしたいの、って、大きすぎると人の脳みそのスペックがついていかないから、ってことなのかなと。

きっと、モノリシックアプリの分割においては、「こいつは明らかに切り取れるな」っていうもの以外は、「サービス境界を見極めて細かく分けていく」というよりは「人間の脳みそがついていく範囲でざっくり切り取るか」みたいな感じの手段を取るのがいいのかな、、、と思いました。

できるなら綺麗に分けるのがいいのかもしれませんが、いまくっついちゃってて、明らかに切り取れる空気がないものに対して境界線引くの、エンジニアリングというより政治力の問題に発展しそうですし。

マイクロサービスと組織論

出典がわからないのですが

「日本におけるマイクロサービスは組織に合わせたサービス分割の話になりがち、欧米はNetflixのような機能別サービスになってて面白いなあ」

 

という話を、どこかで聞いたか読んだかした覚えがあります。

今日になって感じたのは、それって、欧米がとか日本がということではなくて、紹介される事例は「模範解答」だから「クラウドで、k8sで、DDDで、、、」だけど、普通にモノリシックアプリを分割しようと思うと大概

「このチームが詳しいところを切り出すぞ、っていうところに落ち着く」とか、

「いまくっついてるものを切るのに政治的境界が収まりがいい」

というだけのことなんじゃないかという気がしてきました。

結論

「マイクロサービスアーキテクチャ的マイクロサービス」と「マイクロサービスアーキテクチャを参考にしたシステム分割」は持ってる楽器はちょっと似てるけど、音楽性はちょっと違う、って感じがしました。

どっちもトランペットだけどブラスバンドとスカバンド違うよね、どっちもストラトだけどイングヴェイ・マルムスティーンとエリック・クラプトン、違うよね、みたいな?

 

あと、モノリシックアプリか、マイクロサービスかの選択も、どっちがいい、ってもんではなくて、どっちのデメリットを愛せるか?という音楽性の違いなだけな気がしました。 

音楽性は大事です。

Rails Dcevelopers Meetup 2018 凄く良かったです

他のセッションも凄く良かったのにマイクロサービスについて書いてただけで結構な文字数になってしまいました。他のセッションについては追ってまた。。。

railsdm.github.io

OSS Gate東京ミートアップ for Red Data Toolsでapache-arrow-glibのformulaのPRを出した

OSS Gate東京ミートアップ for Red Data Tools

先月に続いて参加。この日もSpeeeさん。

speee.connpass.com

Speeeさんは色んなイベントを開催してくださるので、仕事上の関わりは全くないのに週一ペースで出入りしていて、私完全に頻度がおかしい。

homebrew-coreにPRを出したのだけど。。。

先月からhomebrewにapache-arrow-glibのformulaを追加する、ということに取り組ませて頂いています。

www.hizumizm.com

homebrewはRuby製で、formulaもRubyで書けるのですが、DSL的というか、ある種のフレームワーク開発的なところがあります。

formula作成用ジェネレータコマンドを叩くと、テンプレートが吐かれて、そこにインストールしたいライブラリのインストール方法をHomebrewのライブラリが提供しているメソッドを使って表現していく、というような感じです。

formulaファイルちょっと面白くて、installメソッドの真下にそのformulaのtestを書かせるんです。プロダクションコードとテストコードが同一ファイルに同居してるもの、って他にもあるのでしょうか?

Homebrewのformula開発はこんな雰囲気

Homebrewにformula関連PRを送る手順はここに記載されています

How To Open a Homebrew Pull Request (and get it merged) — Homebrew Documentation

上記の手順に沿って進めて、ここに書いてある手順で brew create すると、

Formula Cookbook — Homebrew Documentation

cloneしてきたリポジトリではなくTapsというディレクトリにファイルが吐かれます。

吐かれたファイルに、他のformulaや下のドキュメントを参考にしながら、ライブラリのインストール方法を依存ライブラリの定義やinstallメソッドを使って書いていきます。

Class: Formula — Documentation for Homebrew/brew (master)

最初見た時、formluaの中身、何が書いてあるのかさっぱりわかりませんでしたが

  • 依存ライブラリがあればhomebrewでインストールする
  • インストールしたいライブラリのインストール(configure->make->make install)

ということをHomebrewの提供してるメソッドで書いてるだけなのですね。

Tapsでいい感じに作れたら、ドキュメントに書いてあるテストを通るようにして、cloneしてきたリポジトリのFormulaの下に持ってきて、pushしてPR出す、という感じです。

PR出してみたものの

この日は、「PR出したぞー、次のことやろう!」という意気込みで参加したのですが、PR出したところで、古いOSではテストがコケてしまうとCIに怒られてしまいました。

(しかもこの時に、インデントの崩れを直す前の状態でPR出したことに気づく)

PRのレビュアーの方がテストの修正方針を教えてくれたので、それを見つつ修正しております。

「brew install hoge、って叩けばhoge入れてくれるんだフーン」くらいに思ってましたが、これ、善意の誰かがformula作ったりメンテしたり、チェックしてマージしてくれないとできないことだったんですよね。とても感慨深いです。

さて、がんばろ。

 

 

Step-to-Rails-Expert.rb#17

Step-to-Rails-Expert.rb#17

先月行けなかったのですが、やっとLevel1の実装が終わったので、今回はアプリ持ち込みで参加しました。(でも実はレビューに出せない状態だった。。。)

step-to-rails-expert-rb.connpass.com

大盛況だった

今回は約10人くらいでした。前に参加した時よりも人多かったです。人が多いと色んな人のレビューが聞けるので参考になりました。

どんなレビューが飛び交っていたかは、本家リポジトリをforkしてる人のリポジトリのプルリクを見るとわかります。

GitHub - Step-to-Rails-Expert-rb/expert-todo: Todoアプリレビュー企画の親リポジトリ

皆さんRails力高いので色々参考になるのですが、特に記憶に残ってるのはDB関係の話です

pgとかmysqlとかはGemfileの中でも上の方に書いておくのが良い

postgresなのかmysqlなのかで挙動が変わるgemがあるから、先に書いておくのが良いそうです。なんか結構危険な香りがする話ですが、「コアなgemは上に書く」くらいの解決策しかないのですかね。。。怖いですよね

開発と本番でDB違うのはやっぱダメ

初めてHeroku使った時、developはsqliteでproductionはpostgresって構成でやったことありました。何かのチュートリアルとかで言われた通りに作って、Herokuデプロイ時にpostgresしか使えないからproductionだけpg入れたのだと思います。ですがdevelopがsqliteだと、sqliteの仕様上外部キーがintegerになるらしく。趣味のアプリなら問題にならないでしょうし、仕事なら開発と本番でDB違う状態にしないとは思うのですが、そういう理由もあるから絶対DB揃えた方が良いですね。

やっぱエンジニアは楽しい(小並感)

今回はちゃんと実装して持って行ったのですが、なぜかherokuにpushできず、更にはmasterブランチに実装しちゃってることに気付き、レビュー希望者多数でレビュー回って来ずむしろ助かってしまいました。次回こそは。。。

しかしTODOは奥が深いですね。仕様を文字で見るとすごくシンプルなので、「え、こんなのそんなに実装パターンあるかな?」と思ってしまったのですが、実際皆さんが持ってきたアプリを見ると本当に色んなパターンの実装があって面白いです。

アプリがどう成長していくか?って、特に仕事の場合本当に予測がつかないので、どのパターンが後々効果的なのか、ってわからないですよね。「どう転んでも作り変えやすいように」というのは考えたりはしますが、それが正解かどうかは時が経って初めてわかりますし。

エンジニアは非常に楽しい職業ですね。

 

 

OSS Gate東京ミートアップ for Red Data Tools

OSS Gate東京ミートアップ for Red Data Tools

コードを書く題材がないとなかなか業務外でコードを書かないので、コード書くためのお題が転がっていたら、とにかくやってみることにしてます。

www.hizumizm.com

www.hizumizm.com

草を生やしたい、という邪な動機

家でコード書く機会が増えるにつれ、プライベートのGitHubアカウントを眺める時間が増えました。

徐々に、この真っ白な空間に草を生やしたい、と思うわけです。

f:id:iTume:20180221073250p:plain

そんなわけで、新たなお題を求めてOSS Gateの門をノックしました。

speee.connpass.com

Red Data Toolsプロジェクトで、homebrewのformulaを作る

Red Data Toolsプロジェクトは「Rubyでデータ処理できるようにしようぜ!」というプロジェクトです。普段Railsばかりやってる私にとっては、Railsでもwebでもないコードを書くいい機会となりそうです。

「GitHubに草を生やしたいと知人に漏らしたら、良い題材があるよ、と教えてもらって、Rubyなら書けるし、なんか楽しそうなので来ちゃいました」と、包み隠さず邪な動機を伝えたところ、Red Data Toolsの概要と、心構えを伝えていただいた後、いくらかの題材を提示して頂けたので、データ処理に必要なライブラリをインストールするためのhomebrewのformulaを完成させる、というのを最初の題材とさせて頂きました。

有名OSSはドキュメントの充実っぷりが凄い

homebrewといえば、brew install叩くくらいはやったことありますが、その中身について想いを馳せたことはなかったので、そもそもRubyでできてたのか、というところに新鮮な驚きがありました。

さらに、OSS初心者の自分は、わかりやすいドキュメントがあることにもまたびっくりしました。「formula追加のPRってどうやって出すの?」「このsha256ってどうやって入れてるの?」「これテストどうやってやるんだろう」等々、読んでいけばわかる状態になっていて凄いなと思いました。

docs.brew.sh

 

↓「バグってるとかいう前にbrew update二回叩いて、brew doctorの中身読んで、チェックリスト見て、既存のissueないか確認してね」

Report a bug

  • Run brew update (twice).
  • Run and read brew doctor.
  • Read the Troubleshooting Checklist.
  • Open an issue on the formula's repository or on Homebrew/brew if it's not a formula-specific issue.

 

こういうの見ると、苦労が絶えないんだな、、、というのもなんかわかります。

OSSに触れると、良いドキュメントに必要なことが何なのか、というのも掴めそうですね。

brew/CONTRIBUTING.md at master · Homebrew/brew · GitHub

まとめ

ポエムよりコードを書く。隙間時間に少しづつでも進められるように頑張ります。