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

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

ねぎと帆立のパスタミスタ

中途半端に余ったマカロニ的なもの(ファルファーレ、ペンネとか、)があったので、パスタミスタを作ってみた。中途半端な量のフェットチーネも入れた。

レシピ

材料(2人分)

  • にんにく...一欠片くらい、輪切りに
  • 鷹の爪...半分くらい(香り付け用なので輪切りじゃなくても)
  • オリーブオイル...大さじ2~3くらい
  • 長ネギ...20cmくらい、1.5cm幅の輪切りに
  • 帆立の水煮缶...1缶。汁は適当に捨てる
  • パスタ...残り物を適当に180gくらい。大盛りにするなら200gくらいでも。
  • パセリ...なくてもいいが、あると色彩と味の変化があっていい
  • 胡椒...少々。粗挽きじゃない細かいやつ
  • パルメザンチーズ...お好みで。パルミジャーノ・レッジャーノならなお良い

作り方

パスタを茹でる

1Lくらいのお湯に小さじ1くらいの塩で茹でる。パスタは強火で茹でる必要はないので沸騰したら弱火にしてから放り込む。混ざってるので茹で時間は適当。硬すぎて食べられないやつが残らない程度に茹でる。

ソースを作る

フライパンにオリーブオイルを引く。にんにく、鷹の爪を置いて、オイルに香りが移るくらいまで中火で。オイルに香りが移ったらねぎを加える。少し焦げ目がつくまで炒めたら一旦火を止める。

パスタをソースに絡める

パスタが茹で上がったらソースのフライパンを再点火。オイルがふつふつしてきたらパスタの茹で汁をおたま一杯分フライパンへ。フライパンを揺すってオイルと茹で汁が馴染んできたら茹でていたパスタをすくってフライパンへ移す。ここで缶の汁を捨てた帆立を投入、パスタを炒めるような感じでソースと馴染ませる。味が物足りなければ胡椒、塩を加える。水気が減ってきたら完成。お好みでパルメザンチーズをかけて食べる。

不揃いなパスタの食感がなんか良い

食材を漁っていて中途半端な量のパスタがいくつか出てきたので、以前テレビで見たパスタミスタを作ろうと思った。調べたレシピはサルシッチャとズッキーニだったのだけど、どちらもなかったのでツナ缶と冷蔵庫の野菜でなんとかすることにした。これまた中途半端なネギを見つけて、ツナ缶を探していたら帆立の水煮缶を見つけたので、それを使うことにした。

残り物をかき集めて作ったわりに美味しかった。ふにゃふにゃになったマカロニと、まだちょっと固いファルファーレ、アルデンテなペンネ、と、食感が違うパスタが何種類かあるのが食べていてなんか面白い。

ネギは香味野菜じゃなく具にしたかったのでちょっと大きめに切った。焦げ目がつくくらいまで炒めたら甘みが出て、帆立の出汁と良い感じに馴染んだ。ネギもう少し多くてもよかったかも。

残り物で作れるレシピは重宝する

パスタミスタ自体は余り食材で作る家庭料理だと思うが、サルシッチャとかズッキーニは日本の家庭にフツーにはないので、日本の家庭に転がってそうなもので作れるレシピをネットに残しておいたら誰かの役にたつかもなと思って書き残してみた。ツナ缶を使うなら、ツナ缶の調味液はしっかり切って、だしの素とか鶏がらスープとかで味を整えるかも。胡椒はほんのちょっと加えると味がくっきりして、塩分を減らせる気がする。パスタミスタには折れたスパゲティとかも使うみたい。とにかく、何かを作った後で微妙に残ったマカロニをつかいきるのには凄く便利なレシピだと思う。

Nike Air More Moneyの靴底を修理した

スニーカーの靴底の修理

Nike エアモアマネーの靴底がすり減り、Airが露出していることに気づいて、ダメ元で靴の修理屋に相談してみた。

www.rooridge.com

「Airが露出するまで靴底が減ってしまうと、修理中にAirが破裂してしまう可能性がある」と教えてもらったが、このまま履き続けても早晩破裂してしまうのでダメ元で修理を依頼することにした。

仕上がり

破裂することなく無事修理完了。

今回の修理は約二千円。靴底のすり減り具合で値段は変わるかもしれない。アッパーはまだまだ綺麗だったのでまた履けるようになってよかった。

靴底のすり減ったスニーカー、これまでは捨ててしまっていたけど、修理して履き続けるのも良いですね。

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!