Rails Developer Meetup 2018 の esa LTで話してきた
先日上げたエントリの内容を喋ってきた。
すごい緊張したんだけどそういえばイベントで人前で喋るのって初めてだったかもしれない。
esaの中の人たちの前でesa最高です!って伝えられたし、取り組みの元となった @suin さんのアイディアにも触れられて満足。
cなんとかeさん! #railsdm #rdm2018b pic.twitter.com/mFyXaBzFy2
— 斥候 (@ken_c_lo) 2018年3月25日
あとは角谷さんにいい使い方だって褒めていただけたのもほんと嬉しい。
backlinkの活用の仕方がいいですね https://t.co/1YeisLGeip
— Kakutani Shintaro (@kakutani) 2018年3月25日
LTしませんか?ってお声がけ頂いた @yoshi_hirano さん、ならびに運営のみなさんもありがとうございました。 イベントはほんと内容が充実していてとても楽しかったです。
プロダクトに対するなぜをesaで集める
サービスは運用していくうちに、トレードオフをした結果だったり歴史的経緯だったり外部要因によったりで一見不思議な仕様が生まれたりする。
そういうものを途中から入った人が、頭ごなしに否定するのは幸せとはいえない。
ということでesaに↓みたいなテンプレートを作ってみた。
疑問に思ったことを書いて経緯をしってる人が答えるみたいな運用を期待している。
また回答がない記事を一覧表示できるよう、解答待ちリスト用リストを出すための記事を用意してテンプレートでそこにリンクを張るという工夫をしている。
どの機能/サービス? --- 疑問に思ったこと --- ソースコード --- (場所がわかれば。なおGitHubのリンクを貼るときは y を押してSHA1を指定してもらえると後々ズレが出なくてうれしいです) 理由 --- (可能であればコンフル/Slack/Backlogなどのパーマネントリンクも添えてください [解答待ちリスト用リンク](/posts/1000))
合わせて記事を収集するカテゴリに以下のようなREADMEも用意した。
ここは? === ○○を触っていて疑問に思ったことがあったら、この下に記事を作成してみてください。 疑問の原因、 **何故** そうなっているのかを残して後から参照しやすくしたいなと思います 書いて欲しいこと === (テンプレートにあるやつ) どの機能/サービスか --- リポジトリ名でもいいし、口頭で言われるサービス名でも可だし、「ほげほげ機能」とかでもOK とにかく他の人が見てわかるようにしてください 疑問に思ったこと --- ここが一番大事 「なぜ〜は〜〜なのか」みたいな文章になってるとよいと思う。 合わせて「普通だったら〜だと思うんだけど」的文章があるとなぜ?と思った理由がわかってよい。 たとえば 「なぜ○○は××なのか?」て書くより「なぜ○○は△△ではなく××なのか?」って書いたほうが、疑問に思った理由が伝わりそう。 ソースコード --- わかればでいいです。 GitHubのリンクを貼るときはショートカットキーの y を押してSHA-1形式のURLにして欲しい。 具体的にこの行ってのがあれば行指定もしてくれると。 理由 --- なぜそうなっているか?を書くところ 自分でわからないときは空欄にしておくなり文章を WIP にしておくなりしておくのがよさそう
ちょっとでも自分たちが触っているサービスのなぜを減らせるようにがんばりたい。
怠惰に料理をする
K&A みじん切り器 ぶんぶんチョッパーDX デラックス 大きめサイズ 700ml
- 出版社/メーカー: ケイ・アンド・エー
- 発売日: 2017/01/16
- メディア: ホーム&キッチン
- この商品を含むブログを見る
これでコールスローを作って食べてる。
キュウリとキャベツ何枚か放りこんで数秒ぶんぶんしたらいい感じのみじん切りになってるので、後は塩揉みして水気切って酢とマヨネーズで味付けするだけ。
3分ぐらいで出来ちゃうから最高に捗る。となりのコンビニに買いにいくよりよっぽど早い。
みんな大好きanovaによる低温調理。
放置しておくだけで勝手に肉が上手くなる夢のような機械。
処理時間はかかるけど出掛ける前、寝る前にセットしておけばいいだけなのでとても楽。
手持ちの鍋が小さすぎたのでニトリの寸胴鍋を購入。
2000円いかないのマジかよ。
もっと金の力で楽をしていていきたいので、何か知見があったらこっそり教えて欲しい。
age++
37歳です。
今年もいろいろありました。
💻
RailsにContributeするという長年の夢を達成することができました、わいわい
といってもまだ1コミットだけなので、これからもコントリビュートできるようにがんばります
⚾️
連覇達成しましたね、めでたい
RubyKaigiと被ってたのにいろいろあって広島にいれなかったのは痛恨の極み…
個人としては札幌ドームとKoboパーク宮城での観戦ができたので。東側はコンプリート
残りはナゴド、大阪ドーム、甲子園、福岡ドームかな
🏇
出資馬の海外遠征の実績を解除しました(2着)
……その後の海外遠征してレースにも出ず帰ってくるなんて実績は解除したくなかった
ちょっと調子崩しちゃってるので来年はしっかり立て直し欲しい
🏠
まぁ、いろいろありまして大学生時代以来の一人暮らしを始めています
経緯が経緯だけに手放しに喜べる感じでもないのですが、一人暮らし自体は楽しいです
秋口からいろいろありすぎていろいろ忘れちゃってる感じではありますが、来年もがんばっていきたいと思います
例のやつ です
ドラム式洗濯機の日々の掃除について
前回のエントリ で書いたがドラム式洗濯機はライフチェンジングな便利家電だ。
ただし1点面倒なことがある。
それは乾燥機能を使うたびに毎回必要な埃の掃除だ。
たとえば↓ここのゴムの上だったり
↓この裏のほうにも埃がすっごい溜る
加えて乾燥フィルターからも埃を取らないといけない。
ここらへんを怠ると乾燥が弱くなったり、空気が通るダクトが埃でつまったりして故障の原因になる。
なによりゴムの部分の掃除をしないと取り出しの際に埃がついて再度洗う羽目になって大変である。
というわけで↓のようなものを買ってみた。
これを使うとこんな風に手を入れてなでるだけで埃が取れて便利。
終わったら埃を取って、そのままドラムの中にポイッ!!
おすすめなので是非試して欲しい。
一人暮らしにこそドラム式洗濯機が必要なのでは
(正確にいうとドラム式というよりは乾燥機付き洗濯機)
先日↓のドラム式洗濯機を買った。
台数限定販売だったらしく最終的には125,000円と価格コムの過去最安値より安く買えたのは運がよかった。
日立 ドラム式洗濯乾燥機 ビッグドラム 左開き 11kg ホワイト BD-SV110AL W
- 出版社/メーカー: HITACHI(日立)
- メディア: ホーム&キッチン
- この商品を含むブログを見る
最初は一人暮らしにドラム式はオーバースペックでは?と思っていたのだが、一人暮らしこそ買ったほうがいいのでは?と思えたのでここにメモとして書いておく。
時間が節約できる
これはどこでも言われていることだと思うけど、洗濯を開始して出勤して帰ってきたら洗濯物が乾いているのはとても楽でいい。
乾燥まで一通りやってくれるということは、「干す」という工程の時間だけではなく洗濯&脱水が終わるまでの待ち時間もなくなるということなので時間の余裕が大分増えた感じがある。
スペース&物が節約できる
何気に大きいのがこれ。
さきほどのように洗濯→乾燥までに必要な時間が減ったので、洗濯の頻度を上げられるようになった。
これにより、タオルなどを必要以上にストックしておく必要がなくなった。
以前はある程度まとめて洗う習慣になっていたので、途中で雨に降られる可能性などを考えると数日分の余裕を持っていないといけなったが、今は1日2日分持っておいて使用後すぐ洗えば困ることがなくなった。
その結果、買うべき物の量も減ったし収納スペースも必要以上に使う必要がなくなった。
結論
時間&物&スペースの分を考えたら逆に安いので、みんなドラム式をぜひ買ってみよう
1秒でも早くプルリクをマージしたい
最近プルリクを作ったり見るときに考えてること。
前提
- プルリクはマージされてシップするまで顧客に対して価値を産んでいない
- 1秒でも早くマージしてシップすることが何より大切
- もちろん質をおろそかにしていいわけではない
この2つをレビュアーとレビュイーが共有する必要がある
どうやったら早くマージできるか
これは単純で
- プルリクの意図/価値を共有しておく
- やり取りの回数を減らす
- 指摘→修正→指摘→修正みたいなのはさける
- 読むべき量を減らす
だけでOK
レビュイーとして
- プルリクの意図を必ず書く
- 「なぜ」これが必要なのか
- 想定した問題やそれに対する考えなどがあったなら書く(パーマネントリンクを添えると最高)
- 想定した結果、あえて選択しなかった手段/方法とかもあるなら書いておいたほうがいい
- 余計な変更は入れない
- コードスタイルの変更などは読むときのノイズになる
- 伝わりづらい/自分でもわかりづらいと思うときはコードコメント or 行コメントを残しておく
- 確認しておきたい/見て欲しい箇所があるなら最初から書いておく
- プルリクのサイズを小さく
- 大きくなるなら実装途中とかで段階的にプルリクを見てもらう
- 設計レベルの差し戻しがあったときにも有効
- 大きくなるなら実装途中とかで段階的にプルリクを見てもらう
- コードの差分では伝わりづらいものに気をつける
- クエリ改善なら変更前後で発行されるSQLだったりEXPLAINの変化だったり
- 画面ならスクショだったり
レビュアーとして
- 細部にこだわりすぎない
- 気になるとこがあっても好みの問題だったり後で直せるレベルというならコメントだけ残しておくけど別に直さなくていいですとか書く
- コメントは後から見て気になったとこを思い出すためにも大事
- 気になるとこがあっても好みの問題だったり後で直せるレベルというならコメントだけ残しておくけど別に直さなくていいですとか書く
- どうやったらマージできるかを書く
- 指摘するだけじゃなくて、どうなったらうれしいかを書く
- 質問とか書いたとき、自分の理解を書いて合ってればマージしていいですと書いておく
後は
- 人が指摘しなくていいものは機械にやってもらいたい
元々は
kamipoさんと飲み会で話したときのに強く影響されています
最近のコードレビューは平和苑でkamipoさんに聞いた精神でやってる
— yak shaver (@chiastolite) 2017年5月30日
社内のサービスは早くマージすることが価値に繋がるのでどうしたらマージできるかを軸にして、OSS(というかRails)の場合は変なコードがマージされると大変なことになるので極力(変なもの不要なものを)マージをしない、させないみたいな話でした
— yak shaver (@chiastolite) 2017年5月31日
レビューのとき細部にこだわりすぎてしまうことがあるので、そういうときにあの話とわさびカルビを思い出すようにしてます!
— yak shaver (@chiastolite) 2017年5月31日