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

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

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

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文増やしたらやりたいことできた、とか、力技で乗り切った、とかやると、少しずつ世界が歪んで、気づいた時には「どうしてこうなった?」ってなるんですよ。

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

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

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