コメントの残し方を方向修正した
リポジトリをぼっち*1でメンテしていくにあたって、心強い味方は実装当時の自分自身のコメントだと思う。 それを実装する必要があったのは何故か、実装時に考えたこと、本当はこうしたかったけど制約で出来なかった、実装Bは何故却下したか...など、色々なことを書き残している。GitHubを使っているので、書き残し方法としてはPullRequestのコメントとして入れていた。
しかし、GitHubのblameから簡単に辿れるのはコミットメッセージだけである。 コミットのハッシュ値を検索にかけて過去のPullRequestを発掘してくるという方法もあるが、結構探すときに労力がかかることに最近気づいた。
Web上をうろうろしていた時に見かけた、コメントの残し方に関する意見*2 にも、GitHubに内容を残すリスクとして他サービスに移行した場合に失われてしまうという話があった。とても納得した。 以降は、これまで利用頻度が低かったgit commitをより意識して情報を残していこうと考えている。
今の所、次のようにTPOに応じて適宜使い分ける予定。
- ソースコードのコメント: 実際の仕様の説明
- 超重要な実装上の仕様。メソッドの使い方、引数の意図、などを書く。
- 将来修正されるべきものについてTODOコメントなども書く。
- コミットコメント: 機能単位の変更理由の説明
- 1機能/1commit を守って積み上げ、機能の意図や変更理由を記録する。
- 1PullRequestが複数のcommitで構成されることも当然ある。
- GitHub上のコメント: 特定の問題の解決の瞬間にだけ必要とされたこと
- リリース前後で気になって調べたこと、書き込み当時のサービス状況。
- 考えた結果ボツにした実装案とその理由。
参考
都会と地方の可処分時間
自分は生まれ育ちは石川県で、しばらく北陸で社会人生活をしたのち、東京に出てきた。
北陸の地は生活道路として国道8号線が使われており、車と生活は切っても切れない関係がある。もちろん多くの人が通勤に車を使っている。運転手は当然、運転に集中する必要がある。そのため通勤時間=運転時間となる。
一方東京では、公共交通機関として電車網が発達している。どこへ行くにも電車に乗って最寄駅で降り、しばらく歩けば目的地へ到着できる。駅と駅の間は下手すると歩いてたどり着けるくらい近い場合もある。とにかく地方ではこんな間隔で駅は配置されていない。すごい。そして電車に乗った利用者は、降りる駅に着くまでは暇である。そのため通勤時間=自由時間(可処分時間)となる。
2年ほど勤務地まではてくてく歩く生活をしていた。そそっかしい自分にとって歩きスマホはかなり危険行為なので、徒歩通勤は運転通勤と感覚的にはほぼ一緒だった。
しかし、引っ越して電車利用が始まった。電車に乗っている間は、信号に注意する必要も、飛び出しそうな子供やでかい道路を大胆に横断する高齢者に気を使う必要もない。完全に自由。そして今、殆どの人がそれぞれの手に便利すぎる個人端末を持っている。
それで小説を読むをよし、漫画を読むもよし、ゲームするもよし、勉強するもよし、友達に連絡とるもよし、痴話喧嘩するもよし...。
ふと電車の中で周囲を見たときに、みんな揃って小さな画面を食い入るように見つめている姿が並んでいるので、いつもびっくりしてしまう。そして自分もいつもその一人になっている。
地方に比べて都会では、移動の時間を自由に使うことができる。可処分時間の確保という意味合いでは、都会住まいの方にアドバンテージがある。しかしその可処分時間をどう使うのが一番良いのかはまだ自分もよく分からない。
防災リュックを家に配備した
そこそこ頻繁に発生する地震に思うところがあって、注文しておいた防災リュックが届いた。 注文したのが9月上旬で、届いたのが10月中旬。注文から実際に手元に確保できるまで1ヶ月ほどみておくのが良いようだ。
2人分注文したが、いくつかの品は1人分のみだったので、完全に同じセットを2リュック分作成することはできなかった。 しかし、全部のセットを詰めてもリュックの容量は半分くらい空いている状態となった。ここから必要に応じて追加で詰められるようだ。 電池やポリ袋など元々家にあったもので簡単に手に入るものはすぐ追加、ロープ、持ち歩きできるポリタンクなど、あんまり身近なスーパーに売ってなさそうなものは思い出したら都度追加を考えている。
他に欲しいもの
まだ揃えていないけど、買っておきたいものを考えておく。
水: 月初にAmazonさんに届けてもらうようにしているけど、下旬にはほとんどない。うまいローテーションを考える必要がある。カンパン: スーパーを探したけど売ってなかった。鉄板なので買っておこうかな。井村屋 えいようかん: 噂の5年保存が効く羊羹。普通に食べてみたい。パンの缶詰: まだ食べたことない。食べて見たい。
...食べ物ばっかじゃん！！！ 他の便利グッズなども都度見ていく。
しないさせないショルダーハッキング
先日、電車で隣に着席した人が、慌てた様子で鞄からパソコンを取り出してなんらかの作業をし始めた。自分はスマホを見ていたが、なんせお隣で画面がでかいので、つい視界に画面の端が写ってしまう。開けているのはExcel画面だなと意識しなくても理解できてしまった。それ以上の情報はスマホに注視していたので入ってこなかったが、わずかに罪悪感があった。見えちゃってごめんなさい…。
東京でウロウロしてるとそこら中で画面が見えちゃうシーンに出くわす。ガラス張りのカフェで店外に背を向けて書類を仕上げることに注力している女性。満員電車でお疲れさまですの書き出しから始まるメールを作成中の男性。別に見ようとは思ってないけど、ふとした瞬間に目に入ってしまう。これはショルダーハッキング一歩手前の行為ではないか。すみません。
そういった瞬間に出会うたびに、我が振り直せ、の言葉を思い出して気を引き締めている。2年ほどコワーキングスペースで働いていたので、なおさらそういう気持ちが強いのかもしれない。
「させない」ための対策
自分がそういった行為をしない、ということは当然のことだし、心がければいい。しかし、コワーキングスペースなどのオープンな場で、自分が感じているような「ついうっかり目に入った」ということを「させない」のは利用者自身が気をつける必要がある。
自分は画面にマグネット着脱式のフィルターを貼るようにしている。
[着脱可能なマグネット式] MacBook Pro 15インチ Retina 用 のぞき見防止フィルター 磁石っつく Privaucks 〜プライバックス
本当は閉じる時には外す必要があるが、コワーキング時代に都度取り外しで持ち歩くのが面倒になって、結局ほぼ付けっ放しにしている。macbookの蓋が若干浮くがそのうち気にならなくなった。メンバーと1つの画面を覗いて話をしたいときに、マグネットなのでサッと外せて助かっている。そもそもmacbookの上の方に磁石式のものがくっつくという事実を商品を知って初めて把握した。
フィルター下部には画面としっかり貼り付けるためのシールをつけるのだが、右下のシールは粘着力が無くなってしまった。左下のシールがまだかろうじて生きている。シールがないと画面を閉じようとしたとき、フィルター下部が画面とキーボードの間に垂れ下がってきて、挟んで破損させてしまいそうなのが気になる。左下無くなったらどうしようかなぁ、両面テープで代用できるかなぁ。
フィルターがあってもその気になって見ようと思えば見れるのだが、そういう人は稀だと思うので、目に入っちゃってなんとなく微妙な気持ちになる人が減ればいいなと思う。
風邪のときどうすればいいのかまだ分かってない
風邪を引いた。熱はそんなにないのだが、喉の痛み、咳、頭痛、全身の倦怠感が症状としてある。 朝に喉がおかしいなと感じたのをきっかけに、その日の午後には頭痛と声がひっくり返ったような高音になってしまうようになった。 あんまり急に体調不良になったので、まさかインフルエンザか、とも思ったが高熱もないし医者にかかったところ喉の風邪と診断をもらった。 とにかくしんどいのを改善したいと思って昼間1日中寝込んでみたが、夕方に起きても頭痛と咳は治っていなかった。
わかりやすく発熱があれば、体温を見て良くなった/悪くなったを比較できるのだが、熱はないので何を指標にしていいか分からない。 今しんどいのが風邪のせいでしんどいのか、寝込み過ぎてしんどいのかいまいち判断できない。 自分にあった鉄板の体調不良の治し方みたいなのを確立したい。
今の所の方法メモ
- 初期症状時
- 葛根湯の錠剤を飲む
- ビタミンが得られるような飲食を行う
- 本格的にやばくなった時
- 医者に行って薬をもらう
- 寝こむ
とりあえず薬飲んでもう一晩寝よう...。
OKRの本を読んだら半分は小説だった話
社長はむちゃくちゃ本をたくさん読んでいて、良いと思ったものが時々社員に向けて課題図書として降ってくる。自分の席には既に4冊ほど積まれている*1のだが、先日最優先としてOKRの本を紹介された。結構読みやすくて、kindleで電車の移動時間などでサクサク読み終われた。
OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法
https://www.amazon.co.jp/dp/4822255646/ref=cm_sw_r_tw_dp_U_x_ob-WBbP7PKPHG
OKRとは何ぞや
Objectives and Key Results の頭文字をとって略したもの。Objectivesは`目標`、Key Resultsは`主な結果` と翻訳されている。
原著タイトル 「Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results」が示す通り、OKRは根本的な部分に注目してゴールを達成することを助けてくれるツールであるようだ。
O(目標)は定性的で、人に刺さるような、心に響くものを1個。
対して、KR(主な結果)は数字ではっきりとわかる定量的なもので、達成がすこし難しそうだと思えるものを2~3個用意する。
具体例はぜひ本を参照してください！
どうやって使うか、運用するか
この本にはOKR自体の説明とセットで運用方法の詳しい解説もある。道具を持っていても使い方を間違えていてはうまくいかないので、とても合理的だと思った。
ぱっと書き出してみてもこれだけのエッセンスが詰まっている。
- OKRの決定方法。チームへの意見の出させ方、まとめ方。付箋を使うなど。
- OKR設定の粒度。OKRは全社から個人までそれぞれ適用することができる。
- 4半期のOKRを掲げ、毎週、適切に進んでいるかどうか確認すること。
- 週で設定する「やらなくてはいけないこと」は2~3個。フォーカスせよ。
- 実施した結果、現在、KR達成にどのくらいの自信があるかを評価する。
- OKR達成のためにおろそかにしてはいけないことがちゃんと守れているか確認する。
- 金曜日にチーム全体で出来たことを共有してお祝いする(ウィン・セッション)。
- 全体的に前向きな表現、発言、行動になるようにする。
- 最初は絶対失敗すると思え。
50%は小説仕立て
上記で書いたエッセンスの解説は第2部で行われている。
本の第1部として掲載されているものは、架空のスタートアップ企業「ティービー」が苦しみの後にOKRに救われるという筋書きの小説である。ビジネス書では珍しい構成なのでは。
自分は正直なところビジネス書より物語のほうが好きなので、第1部を楽しく読み、第2部の理解に役立てることができたと思う。
2人のエンジニア
小説には、物語開始時点から主任プログラマーであるエリック、後半にCTOとなるラファエルという2人のエンジニアが登場する。
主任プログラマーエリック
主任プログラマーであるエリックは、ティービーの掲げるビジョンに共感して入社したが、会社が成長のために舵を切っていく方向に不満を持つ。そしてその結果、ソースコードをわざと難しく書き直すという行動にでる。
おいちょっと待て？自分がメンテしてるものを難しくしてくとか自分の首絞めてるだけでは？？ん？？？
立場的に自分はエリックに近いものを感じているが（少人数スタートアップに在籍、プログラマー）、これにはまったく共感できなかった。ソースコードがたとえ難しくなったところで、困るのは自社内のプログラマー達自身であり、サービスを利用しているエンドユーザは使用感さえ変わらなければ気にしないだろう。
とはいえ、長期的に見ると難しいコードは仕様変更に耐えられない、つまりユーザによりよい価値の提供速度が遅れると言えるので、会社にとって間違いなくマイナス要素である。こういう事態をしでかしたエリックがどうなるのかは……お察しください。
CTOラファエル
また、物語の後半から突如登場するラファエルは、一見してギークとわかる雰囲気を持ち、これまでもスタートアップで実績をあげてきていて、Googleに在籍した経験があり、上場直後の会社を退職してきて、投資家経由で紹介されたティービーのビジョンを最高に気に入ってジョインしてくる。もちろんOKRの導入のノウハウを充分に持っている。
なんだそれは！？ウルトラCすぎんだろ！！！そんな人がホイホイでてきてスタートアップにジョインしてくれる？？は？？夢物語か？？
ラファエルが出てきたシーンを読んでひとしきりそう思ったあと、あっこれ小説だったわ、ということを思い出した。
あくまでも解説書
やっぱりあくまでもOKR解説のための小説なので、ラファエルが登場してからの成功体験を駆け上がる感じの場所はご都合感があった。しかし、スタートアップ企業がビジョンと現実の間で苦しむ様子がすごくリアルで、読んでいて自分まで苦々しい思いを体感させられた。
OKR気になっている人、読みやすい一冊なので、ぜひ一読して欲しい。
*1:もうちょっとで1冊目読み終わるから待って!!!
Otemachi.rb#10にLT参加しました
enechange-meetup.connpass.com LT参加しました！メモ魔なので、聞いた話をメモしました。
主催 エネチェンジさん
電力会社、ガス会社を切り替えるならエネチェンジ！
Active Support のコア拡張機能について
- 知ってた！
- Object#blank? #=> 0.blank? == false
- Object#present? #=> 0.present? == true
- Object#try #=> メソッドがなければ nil を返す ぼっち演算子(&.)でも同様のことができる
- Object#try! #=> メソッドがなければ例外を返す
- Object#deep_dup #=> ディープコピーしてくれる
- Moduleの拡張: delegate
- ref: https://railsguides.jp/active_support_core_extensions.html#delegate
- allow_nil: true よくやるぞ
- Railsのこだわり？ String拡張
- "table".pluralize #=> "tables"
- "tables".singularize #=> "table"
- 他, camelize, underscore, titlizem dasherize, demodulize, deconstantize, parameterize, tableize などなど
- to_s(:currency, unit: '£')
- 12345.to_s(:delimited) #=> 12,345
- [1,2,3].sum #=> 6
- .pluck(:name) #=> とてもお世話になっているやつだ
- .merge
- .compact
- 知らなかった！
- x.presence #=> x.present? ? x : nil と同じ
- tryはブロックも渡せる、Ruby2.5 以降の #yield_self 的な使い方もできる
- Object#to_query #=> {c: 3, b: 2}.to_query #=> "b=2&c=3"
- Object#with_options #=> ref: Railsで特定の条件下で走るバリデーションを作りたい
- class_attribute #=> ref: これはMUST！ActiveSupport の Class#class_attribute を使おう！
- cattr_accessor #=> クラス変数のアクセサ
- to_date, to_time, to_datetime #=> Time.zone.parse よりも文字数少なくて便利
- 100.to_s(:percentage, precision: 0) #=> 100% *これ 0.01を1%に直してくれるのないかな？ありそう
- 123.to_s(:human_size) #=> 123 Bytes !!!知らなかった
- .without
- Hash#extract!
- Hash#stringify_keys, symbolize_keys, deep_symbolize_keys #=> キー、シンボルどちらかに寄せる
- サマリ
- ドキュメントを熟読しよう。
- RailsGuide, Ruby on Rails API は必読。
- Q: Rails以外でさくっと使いたい時どうしたらいいですか？
LTx5
Rubyでbrainfxck処理系作ってみた
- 例のアレ => Brainfuck - Wikipedia
- 実用性はゼロだがチューリング完全
- 思わぬところでbrainfxckの仕様を知ってしまったな... (プログラミングかるたで存在は知っていた)
- デバッグしんどそう
- 派生言語がたくさんある、好きに当てはめていいため
CSV出力 Viewからやるか？ 他からやるか？
- CSV出力 - Viewからやるか？ 他からやるか？ / How to output CSV - Speaker Deck
- CSV出力は誰の責務か？ => viewでやった
- Modelに書いてあるけどViewのほうがいいのでは？
views/**/index.csv.rubyなるほど- 既存の整形処理やdecoratorがあったのでViewになった
- CSV化がどう利用されるのかに注意、ほんとはAPI化したい
Rails×Messaging API × Herokuで清宮幸太郎の成績検索BOTを作成したよ
【Otemachi.rb#10】Rails×Messaging API × Herokuで清宮幸太郎の成績検索BOTを作成したよ
- 清宮幸太郎さん: プロ野球選手さん
||=のイディオムを覚えた時の感動を思い出した- モジュール名.メソッド名
::はスコープ演算子request.body.readって何？ => Railsのrequestオブジェクト(自分もよくわかっていないかも...)- 最初の応答が遅いのは寝ているherokuサーバさんが起きるまでの時間？
requestとはなんだ？- Railsはサーバサイド、ブラウザを抽象化したものがrequest、ヘッダを受け取ったら全部を受け取らなくてもIOとして保持してrequestを作る （ んんん自分も不勉強でまだピンときていない... )
ぼっちの開発 3-Step(発表しました!)
- ぼっちの開発 3-Step - Speaker Deck
- 色々試行錯誤した結果、最初入っていたはずの技術要素が消し飛んでエモさで攻める話になりました
- Q: ぼっちなのになんで普通の開発フローを知っているのか？
- A: 昔2人体制の時期があった + 一時期受託業務ですごく良い体制のチームにお邪魔していたことがあったため、その経験が活きています！
- みなさん、あたたかく話聞いてくださって本当にありがとうございました！！
Rubyで始めるAtCoder
- AtCoder 日本で参加しやすいコンテスト
- https://atcoder.jp/?lang=ja
- 面白そう！！
- (ブログネタが枯渇してきたのでやらざるをえないという気持ち)
- Rubyを選んでソースコードを貼って提出する
- まず茶色ランクを目指そう(D)
- 毎週土曜9時から定期開催
まとめ
久しぶりに人前で発表、しかもRails要素0.01くらいのスライドでしたが、みなさん暖かく受け入れてくださってありがとうございました…！！ また今度はちゃんとRubyもしくはRailsネタをもってリベンジしたいです。精進します！
