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

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

Google re:Workを読む会に参加した

Google re:Workを読んでみるワークショップ

友人がGoogle re:Workの日本語訳を読むワークショップをやろう、と誘ってくれたので、会場提供などのお手伝いをさせてもらいました。

rework.withgoogle.com

Google re:Workは

データ分析を基に考えられた人事施策について、Google(グーグル)が他の組織と一緒に共有し推進しようとする取り組みです。

 というコンセプトの取り組みのよう。Googleが自身の研究成果をまとめてくれたものがこのページにあるので、今回は「効果的なチームとは何かを知る」というページを読みながら意見交換をしました。以下、当日出た感想などを書き連ねておきます。

メンバーの行動基準てないの?

マネージャーの10個の行動基準が紹介されていたことに対する疑問として出たもの。確かに、良いマネージャーにうまくマネージされるためのinterfaceをマネージされる側も持っておくというのは大事な気がする。

ワークグループとチームの違い

相互依存性の有無で「ワークグループ」と「チーム」という定義を分けているのが面白かった。相互依存性を作れればチームにできるのでは?と観点が出て、「joinしたメンバーをランチに連れまわすようにしている」という話が出た。なんとなく人を誘ってランチに行くのもいいけど、「チームになって欲しい人と相互依存性を作るための手段として一緒に飯を食う機会を作っているんだよ」っていう目的を念頭に置いてランチに行くと、ちょっと良い効果があるかも。

タックマンモデル

この文章に出てきた言葉ではないけど、意見交換の中で「タックマンモデル」というのを紹介してもらった。チームの形成は以下の5つの段階を経る、という話。

形成>>混乱>>統一>>機能>>散開

 機能するチームになるために、今チームがどの段階にあるのか、次に行くにはどうしたら良いのか、ということを考える上でとても役に立ちそう。言ってしまえば当たり前のことしか書いてないのだけど、これをチーム全員が知っていれば「お互いの価値観を知らないと混乱期にも行けないから統一もされない」とか「統一に向かわなきゃ機能しない、統一するためにはどうしたら良いんだろう」ということを考えることができるので、体系として知っているのと知らないのとでは全然違うなと思った。

心理的安全性の確保

ワークショップの中で出た「私はチームのことをすごく気にかけてたつもりなのだけど、上司から、君はチームに対する挨拶が足りなくて、チームとしてよくない、ということを言われた」というエピソードがすごく面白かった。

挨拶がチーム形成に大事、というのは、感覚的にはわかる。ただ、もし仮にチームとリーダーが本当に良い状態を築けていたとしても、上司一人が「挨拶がないことで心理的安全性が保たれていない」と感じたとしたら、上司にとっては心理的安全性が保たれていないチームであるということになってしまうということ。それって結局「何をどう感じるかはその人によりけり」ということになってしまう。

それに対して「チームが大切にすべき価値観をいくつか、毎週のふりかえりで確認すると良い」という話を伺った。「これが保たれていれば私の心理的安全性は保たれる」という価値観をみんなで確認するということ。もし仮に「毎朝の挨拶がないと疎外感を感じる」という人がいれば、「毎朝挨拶してほしい」というのをチームが大切にすべき価値観に加えれば良い、ということ。

チームとして何を重視するかはチームに集まった人によって変わってしまうから、チームみんなが気持ち良くいられるように話し合いをしよう、という、当たり前だけど気付きづらいことに気づけた気がした。

情報共有について

「メンバーに与える情報はできるだけ絞る」というのがよくある考え方なのだけど、そうすると情報格差が生まれて、それによってヒエラルキーができちゃう。なので最近はできるだけ情報をオープンにしようという会社が多いと思う。

ただ、「与える情報を絞る」という行為を「ありったけの情報全て与えると混乱するだろうから絞っとくね」というある種の好意とか効率性を考慮して行ってるケースがあるような気もする。別に情報格差によるヒエラルキーを作ることを目的としてなくて、単に過去のリーダーがそうしてたからそれが良いことだと思ってやってる、的な感じで。

実際にやるべきことは、「情報は可能な限りオープンにしておく、ただ、多すぎると必要な情報を掴むのが大変だと思うから、大事なところだけまとめて伝えるね」というキュレーションなんじゃない?という話が出ていて、興味深かった。「フィルター」するんじゃなくて「キュレーション」すれば良いのだ。メンバーからすれば「これだけ見ておいてくれれば良いよ」という情報の量は変わらないので特に混乱はしないけど、アクセス可能な情報は増える。

個人的には自分でフィルタリングできるからできる限り多くの情報をそのまま流して欲しいと思う。フィルターされてると感じた時にその意図を勘ぐったり、隠されてる事を暴くためにいらぬ情報収集に時間を費やしたりする必要が出てくるのでやましいことがないなら全部投げてくれよと思う。

雑感

お互いの期待値をコントロールするためにしっかり話し合いをするとか、状況を把握して共通認識を作っておくとか、無駄に考えなくて良いようにrequest-responseのプロトコルを揃えておこうぜ、とか、言ってしまえばそれだけなのに、なかなかそういう普通のことができてないので非効率とか悲劇が起こるのだなと改めて感じた。

こういうチームビルディングにかかる時間は直接的に何かを生産するわけではないから、人によっては無駄と捉えてしまうようなのだけど、何のためにやってるコミュニケーションなのかしっかりと定義しながらやっていけば理解も得やすくなるかもしれないなと思った。

このワークショップ自体も、「この言葉の定義は何なのだろう」とか、「ワークグループとチームをわざわざ定義してるということはこの違いは重要なんだろう」とか、一つ一つ丁寧に共通認識を作りながら読み進めていた。読み進められる量は少ないけど、得た物はとても多かったと思う。

mac book pro mid 2012にまだ頑張ってもらう

mac book pro mid 2012

エンジニアになった時に購入したマシン。もう6年落ちだけどまだ頑張ってます。

結構良いマシンだなと思ってます。

リンゴが光るのが良い

最近のmacはリンゴのバックライトなくなってしまったので残念です。それだけです。光るリンゴと大きな黒いシールの組み合わせ可愛いですよね。

キーボードが良い

最近のペチペチキーボードは軽く触れる感じで打鍵しないと底付きして気持ち悪いのです。あれで慣れた後、別のマシンで普通のキーボード打ってしまうと慣れるまですごく気持ち悪い。とはいえキーボード持ち歩くのもダルいと思ってしまう私にとってはmid 2012のキーボードは程よい打鍵感が好印象です。

自分で拡張できるのが良い

最近のMBPはメモリやドライブの増設ができないものばかりですが、mid 2012は割と拡張できます。

メモリは8G*2枚の16Gまで増やせますし、ストレージは、2.5インチのものを2個まで搭載できます。私のMBPは購入時点で光学ディスクドライブ外してHDD + SSDに換装してあり、mid2012のくせにメインドライブがSSDといういい感じの仕上がりでした。メモリは最初2G*2の4Gだったので、8G*2枚をamazonで購入して自分で刺しました。

ただ、裏蓋を外すときは星型のネジを回せるドライバーが必要なので、用意しておきましょう。あと、当然ですがmacの保証外になるので、一度開けたら最後まで自分で面倒見る覚悟で。

自分で修理できる

先日メインのSSDが逝きました。

私のmid 2012は中古でxxオクで購入したもので、購入時点から改造されておりました。よってgeniusの力を借りることはできなさそうなので、amazonでSSDをポチって自力で修理しました。

 

裏蓋開けて繋いでcmd + r でメニュー出して初期化してOSクリーンインストールしてはいOK

のはずだったのですが、どこかで何かやらかしたらしく、ドライブ1個しか認識してくれなくなってしまいました。。。

まあいいか。まだ使えるし、HDD外したから軽くなったし。

ちなみに

裏蓋開けれる仕様になってるmid 2012はxxオクとかでたまに格安で購入できます。私は4年前くらいに約七万円くらいで購入しました。

故障してもGeniusは助けてくれないと思うので、多少なりともPCいじりができる人でないと辛いと思いますが、外出時に使う適当なスペックのノートが適当な値段で欲しい人にとっては割とアリな選択肢かなと思います。

さいごに

復旧したのはいいのですが、バックアップを一切取っていなかったのでまっさらになってしまいました。。。いい機会なのでBrewfile作っていくようにしようかな

Step-to-Rails-Expert.rb#20に参加してVue.jsにちょっと触った

Step-to-Rails-Expert.rb#20

もくもく会となった今回は大盛況でキャンセル待ち出てたほど。

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

私は引き続きTODOアプリをいじってました。今回はRailsはちょっとお休みして下のQiitaを参考にVue.jsを動かしてみることにしました。

qiita.com

フロント周り疎いので、改めてYarnて何ですか?どうやって扱うんですか?というあたりからドキュメント漁ってたらHello Vue出来たところでタイムアウトとなりました。

Yarnは「紡いだ糸」的な意味だと思ってたのですが、ドキュメント猫だらけですね。何でかわからないけど可愛いですね。

yarnpkg.com

YarnてRubyでいうbundlerだと思ってるのですが、npmとかもありましたよね。フロントエンド界隈って、一つのツールが進化するのではなく、ツールが出ては消えていく印象です。なんか不思議ですね。

机囲んでのもくもく会、いいですね

Step-to-Rails-Expert.rbはいつも机をくっつけて囲んで座るので、わいわい会話しながらコーディングできるのでなんか楽しいです。発表を聞く勉強会も勉強になりますが、参加者同士の情報交換が一番楽しくて勉強になるなあ、と最近思います。

次回もまたよろしくお願いします。

UIT#3 The “Backends for Frontends” sharingに行ってきた

UIT#3 The “Backends for Frontends” sharing

フロントエンドエンジニアの勉強会で、BFFについて色んな話が聞けるということで参加してみました。

uit.connpass.com

雑感

加筆修正していこうと思いつつ、一旦備忘録として書き出していきます。

全然違う世界にわくわくした

普段参加するRuby系の勉強会と参加者層が違いました。改めてwebの世界は広いな、という当たり前のことを思いました。なかなかフロントエンド技術まで手が回らないですが、概念とか、主要技術くらいはキャッチアップしていきたいですね

BFFは使う人が得意な技術スタックで作ればいい

「Node.js使ってjs系の技術スタックで実現してるからフロントエンドチームで作れる」みたいな話や「ios/Androidエンジニアが作れるようにKotlinにした」みたいな話があって、BFFはサーバーサイドエンジニアが作るものと思いこんでいた自分には目から鱗でした。これはとても良さそうですね

RESTじゃなくてもいい

サービス群はRESTだけどBFFはgRPCにしました、という話があり、確かにRESTに縛られる必要もないな、って思いました。サービス分けると技術選定が少し自由になるのはいい事ですよね

BFF誰が持つの問題

BFF上にアプリケーション作るのはBFF使う人、っていうところはだいたいみなさん同意見だったように思いましたが、運用をどうするか?は割れていたのかも。マイクロサービス的な思想からすると使う人が運用できるのがいいような気もするのですが、フロントエンドエンジニアの職掌からするとインフラ運用やってね、っていうのはなかなか辛いですよね。

LINEさんの規模感

フロントエンドエンジニア約100人、という規模感に度肝を抜かれました。

あとLINEってがっちりネイティブだと思ってのでwebな部分が結構あるというのも驚きでした。ネイティブって思うくらい違和感がなくて気づいてない、とかなのでしょうか。。。凄い

あと今回の会場はLINEさんでした。写真撮って来なかったのが惜しまれるのですが、社内の会議室というより完全にお金払って借りるクオリティのイベントスペースでした。これが本当のIT企業か。。。

しかも勉強会なのにビールがサーバーからサーブされるのですよ。なんというホスピタリティ。

 

発表スライド

メモ取りながら聞いてたので、そのうちそれぞれのスライドについての感想を加筆するかも。十人十色と言いますか、BFFというテーマだけど技術スタックも違えば困っていることも違ったりしてかなり興味深いイベントでした。

FiNC @qsonaさん

speakerdeck.com

 

FOLIO @Quramyさん

speakerdeck.com

 

メルペイ @1000chさん

docs.google.com

 

Wantedly Kento Moriwakiさん

speakerdeck.com

 

LINE Junさん

speakerdeck.com

 

@yosuke_furukawa さん

speakerdeck.com

RubyKaigi2018でHelperをやってきた

スタッフ(Helper)としてRubyKaigi2018に参加してまいりました。

非常に楽しかったので、Helperやってみたいと思っている人のために感想を書き残しておきます。

HelperとしてRubyKaigiに参加してみた

どうやってなったのか

Helperは公募制でした。RubyKaigi公式Twitterに募集の告知が出てたので、そこから応募しました。

 

5月頭に連絡が来て、正式にRubyKaigi2018のHelperとなりました。

Team - RubyKaigi 2018

来年も多分、開催一ヶ月前くらいに告知出るんじゃないかな。

なぜなったのか

RubyKaigi2017に参加したことがきっかけです。
去年初めてRubyKaigiに参加し、会期3日にわたる大規模なTechカンファレンスなのにRuby界の大御所の方達が当日運営で奔走されているのを見てびっくりしてしまいました。何に例えるのが適切かわかりませんが、フジロックの運営を去年のヘッドライナーのバンドがやってる、みたいな感じでしょうか。自分にはかなり衝撃的でした。
私は、イベントごとは多少経験があるので、自分が少しでも役に立てればと思い、「次は絶対にHelperをやろう」と決め、応募しました。

ただ、この「少しでも役に立てれば」というのは今となっては杞憂だったのかな、と思っています。多分、恐らく、Organizerの皆さんはRubyKaigiの運営を本当に楽しんでいました。人手が増えたら助かるのは間違いなさそうですが、人手が足りないから頑張っている、というわけではなさそうだな、と感じてちょっとほっとしました。

何をやったのか

運営部隊はOrganizerチーム、Staffチーム、Helperチームとプロの方達(イベント運営、会場側スタッフ、同時通訳etc...)の混成チームとなっていました。
Helperは受付担当、同時通訳レシーバーの貸出/管理、セッション会場の諸々サポート等々を受け持っており、私はセッション会場のサポートをやってました。
セッション会場のサポートは、いわゆるAD的な役回りですが、各会場にはOrganizerチームやプロの方がいて、その上での"Helper"なのでごっついタスクが降って来てテンパる、みたいなことはなかったです。

ちなみにHelperは会期以前の拘束は特になく、事前にあったことといえば、開催して頂いた顔あわせの会に参加したことくらいです。

Helperやってみて良かった事、良くなかった事

去年はただの参加者として、今年はHelperとして参加して、今年の方がRubyKaigiを楽しめた実感があります。

ただ、何事もメリット、デメリットあるのが世の中なので、自分の感じたHelperで参加して良かった事、よくなかった事を書いておこうと思います。

良かったこと

イベントを作る楽しみをつまみ食いできる

当日スタッフって、イベントの一番楽しいところを堪能できる良い役回りだと思います。参加者の楽しんでいる姿を自分の目で見て、楽しめるようお手伝いをして、感謝されて、RubyKaigiを作った一員として紹介してもらえて、至れり尽くせりだなあ、という気分です。

私は過去大小様々なイベントに携わった経験がありますが、当日までの準備って地味なことの積み重ねだと思います。Organizerのみなさま本当にお疲れ様でした。 

RubyKaigiの熱狂をより強く感じられる

ほんの少しでも自分が関わってるという感覚からか、会期を通じて起こる色んなことに感動してしまいした。会場が沸いているとなんか嬉しい。楽しそうに歩いてる人達を見るのがなんか楽しい。いきなり野良ペアプロ始まってて凄い。とか。

Closingのスピーチ、何回か感極まってしまいました。 去年はここまでの感覚はなかったなあ。

Rubyistネットワークが広がる

これは東京に関して言えば毎週あちこちで色んなイベントがあるので日本人と話す分にはRubyKaigiじゃなくちゃ、ということはないかも。ただ海外の人と直接話せる機会はなかなかないですね。しかし話すためには英語力をもっとつけないと。。。

良くなかったこと

足腰が辛い

日頃座りっぱなしの一日に慣れてる身としては、長時間立ってたり、走り回ったりというのは思ったより足腰に来るものです。

ただ、2日目以降はコツが掴めたので、ちょこちょこ座って休みをとるようにしたところ、そこまで辛くはなくなりました。うまいこと休憩するの大事です。

早起きが辛い

会期中は8:30に会場集合でした。普段の起床時間にすでに活動開始してないといけないという辛さ。

思いっきり飲めない

これは単に自分のアルコール耐性の問題だったりしますが、明日のことを気にせずに飲める、って感じにはできなかったです。かなり遅くまで飲んでた方もいたみたいなので、単に鍛錬の問題か、ウコンで殴れば良かったのか。。。

Helperやろうと思った人に伝えておきたいこと

スマホを充電できる用意をしておいたほうがいい

普段一日中オフィスにいるので忘れがちですが、一日外にいると充電切れます。今回はGitHubさんのブースで充電できましたが結構ヒヤヒヤしました。モバイルバッテリー持っておいたほうがいいかもしれないです。

身の回りのものを持ち歩けるようにしたほうがいい

スマホと貴重品とモバイルバッテリーとかを持ち歩こうと思うとポケットパンパンになっちゃうので、ボディバッグとかポシェットみたいなものを持っておいた方がいいかもしれないです。

やってみたい、と思ったらやるべき

「Helperやってみたい」って少しでも思うくらいRubyKaigiが好きなら、やってみて損はないと思います。

個人的な反省点

ここからはHelperとはあまり関係なく、個人的にRubyKaigiに対する意気込みが足りてなかったな、という反省です。

会期を見誤った

RubyKaigiってMay 31st - Jun 2ndって書いてあるじゃないですか。会期3日間だと思いますよね。私は5/30の深夜に仙台入りして6/2の夜に帰路についたのですが、これはダメですね。前夜祭で予習して、アフターパーティを楽しみ尽くすためには最低5日間の予定を組むべきですね。

体調管理が甘かった

直近のお仕事が割とエグくて体力/気力共に弱り気味でした。2日目終わった後懇親会に参加する体力/気力が出ず、ホテルに戻ってちょっとコード書いて寝てしまいました。今思えば本当に勿体無い。

ケチって失敗した

5/30の宿をケチってカプセルホテルにしたところ、起きたら体がバキバキで肩凝りが。。。ナインアワーズというコンセプチュアルで小綺麗な良い感じのカプセルホテルだったのですが、弱ってる時に宿代ケチると全回復しないのですね。ウィザードリィみたいだ。

さいごに:来年はもっとコミットしたい

ロックバンドのライブ見て帰ってくるとやたらギター弾きたくなる、みたいなもので、RubyKaigiから帰ってきた今、RubyKaigiで見た色んなものを試してみたくてうずうずしてます。そしてあの熱狂が恋しいです。まだno ideaですが、来年はもっと深くコミットしていけるようにやっていきたいです。

Just Write Code and See you at the Next Kaigi!

Dockerと仲良くなりたい

使っては忘れるDockerをちゃんと使いたい

Docker、仕事では使っておらず、趣味の開発もローカルでやってしまうので覚えては忘れてを繰り返してました。

kubernetesをやってみたくて「kubernetes入門」を買ったのですが、Dockerすっかり忘れていることに気付きまして。まずはDockerだな、ということで、今度こそはちゃんと使っていくつもりで再入門です。

どのドキュメントを参考にすべきか悩む

QiitaでDockerでRails動かすための記事を探すと山程出てくるのですが、どれを参考にするのが良いか正直分からず、今回はDocker公式のドキュメントを参考にしました。 

クイックスタート・ガイド:Docker Compose と Rails — Docker-docs-ja 17.06.Beta ドキュメント

おや、、、?このRails古くない?

webのコンテナ起動するところでwebrickが立ち上がってて、おや?って思ってコピペしてたDockerfileとGemfileみて気づいたのですが、結構RubyとRailsのバージョンが古いんですね。

.comの方もRails5.0なのでやや古めですね

docs.docker.com

Ruby2.5/Rails5.2でもQuickStartできたので、せっかくなので本家の方にPR送っておきました。英語苦手なのでタイトルとかメッセージは雰囲気で書いております。伝わるだろうか。。。

github.com

ドキュメントの右肩のedit this pageを押したらGitHubのリポジトリに飛んだので、forkしてシュッとPR送っておきました。

github.com

 本家のPR通ったら日本語版にもPR送ろうかな

github.com

 

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