よもやま話β版

よもやま話を書きます。内容はぺらぺら。自由に書く。

超細かい作業ログをとっている話

1ヶ月で終わると見込んでいた仕事が終わらなかったのを機に、いったい自分は仕事として8時間をどんな風に使っているのかを考え直すことにした。 本当はいい感じのツールでかっこよく整理できたらよかったのだが、自分が求めるものにジャストフィットするものが見つからなかったため、Spreadsheetに頼った。

求めていた機能として、

  • 突発的に発生したタスクを書き留めることができる
  • タスクに何時間かかったのかを振り返りできる
  • タスクの順序をいつでも入れ替えることができる

というのがあるが、うまくSpreadsheet でカバーできてしまったので、ここ1ヶ月はこのまま運用している。

決まったことを決まったようにこなせる日はなかなか無い。都度、新しく発生した問題やら何やらを片付けつつメインの開発に取り組むという形で進めている。何時間で終わらせるぞ!という目標のあるものは見積もり時間項目に値が入るが、想定できないものや突発的タスクについては入っていない。 記録をつけたことで、自分としては次のような見直しができた。

  • 平均して毎日3時間は雑務をこなしている。
  • 月に3~5日はまったくコードが書けない日が発生する。
  • ...ということを見越して、機能の完成時期を予想する。

あとログを書き込むようになって、作業に詰まったときにどれくらい時間を使ってしまったのかを時間単位で把握できるようになった。結果、諦めたり方針を変えたりするきっかけ作りとしても効いていると思う。

GitHubのソースコード参照リンクを残すときはmasterを避ける

tl;dr

GitHub参考URLをmasterを参照したものにしていると数年後に見直したときに泣くぞ!気をつけろ!(経験談)

こんなときあるよね

GitHubを使っているときなど、ソースコードへの参照URLを残したい場合がある。 このとき、リポジトリからそのまま素直に目的のコードを探しにいき、特定の行番号をクリックすると次のようなURLとなる。 (pluckが好きなのでその部分の実装のリンクを貼ってみる。) https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/enumerable.rb#L124

しかしこのURLには問題がある。 ソースコードは生き物みたいなものなので、masterは日々更新されてしまう。 数ヶ月経った後のこのファイルの124行目は果たしてpluckの実装を指しているのだろうか? これを誰かが読んでいるときは、すでに全く別の行だか空行だかを指しているかもしれない。 せっかく参考にと残したURLが別の場所を指していては意味がない。

手段1: tagの指定

f:id:beta_chelsea:20181027181249p:plain:w500

将来的にも確実に意図した指定を残す方法として、branchやtagを指定してから行番号リンクを獲得するようにしている。 自分としてはどちらかというとtagのほうがバージョン指定がURLに入るのでわかりやすいかなと感じている。 (あっ、v5.2.1の時点ではpluckは114行目なんですね...) https://github.com/rails/rails/blob/v5.2.1/activesupport/lib/active_support/core_ext/enumerable.rb#L114

手段2: Copy permalink

f:id:beta_chelsea:20181027181211p:plain:w500

特にバージョン指定も関係ない場合、行を選んだ時の左側の「…」を押すと手っ取り早くCopy permalinkができる。 このときURLは次のようになる。 https://github.com/rails/rails/blob/5431e17733366da1fd10f2cd3039d66a56012683/activesupport/lib/active_support/core_ext/enumerable.rb#L124

おまけ

1行選択したあと、Shiftを押しながら別の行を選ぶと、範囲指定ができる。URLとしては L数字- で繋げればよい。 https://github.com/rails/rails/blob/v5.2.1/activesupport/lib/active_support/core_ext/enumerable.rb#L107-L121

f:id:beta_chelsea:20181027181936p:plain:w500

英語のcommitメッセージをそれっぽくするためにやっていること

自分がいま管理しているリポジトリは引き継ぎしたものだ。 元々commitメッセージを英語で書く方針で始まったようなので、自分もそれを拙いながらも継続している。 とはいえ母国語でないので時々怪しい文章を書いてしまうし、レビューしてくれるひともいない*1。 そんな状況でもどうにか将来 git log を叩いた人へ何が起こっていたのか伝わるように頑張っている。 現時点で、少しでもマシな英語のcommitメッセージを生成するためには何をしているのかを書いてみる。

動詞で始める

Update ~Remove ~ とか動詞から始める。 これは色んなところで良く言われるコツらしいので鉄板なのではないだろうか。

Git でより良いコミットメッセージを書く方法 - yu8mada
gitにおけるコミットログ/メッセージ例文集100
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ

Google翻訳に意味が通じるか聞いてみる

それっぽく書いてみたら、とりあえずGoogle翻訳にぶち込んで英->日翻訳で意味が通じるかどうかチェックする。 変な意味になってしまっていたら再考する。

f:id:beta_chelsea:20181025131211p:plain:w500

Grammarlyに文法チェックを頼む

ただ、Google翻訳は優しすぎて、適当な文法でもそれらしく翻訳してくれてしまう。 文法がおかしいかどうか、Grammarlyにぺッと貼ってチェックしてもらっている。

Grammarly: Free Writing Assistant 英語の文法チェックに!秀逸な英文校正ツール「Grammarly(グラマリー)」の使い方 - Life is colourful.

f:id:beta_chelsea:20181025131624p:plain:w500

課金するともっと良い表現などを教えてくれるようだが、無料範囲でも文法上まずいところを指摘してくれる機能がある。 GoogleChrome向けのアドオンもある。アドオンを入れておくと閲覧中のページで英文を入力したときにすぐチェックしてくれる。 Google翻訳上でもアドオンが有効になっているとすぐさま指摘を入れてくれる。

f:id:beta_chelsea:20181025132219p:plain:w500 f:id:beta_chelsea:20181025132226p:plain:w500

冠詞の aan かとか The とか複数形にすべきかどうかとか三人称単数とか、英文において気にするべきところは色々あるが、Grammarlyがまるっと面倒をみてくれるのでとても助かっている。

ちなみに

ちなみに、個人プロジェクトだったら、自分は速度/理解度優先で日本語でcommitメッセージ書くと思う。 特に強いこだわりがないとき、これまでの例に倣っていくのが最適かなぁと思っている。

*1:ぼっちエンジニアなので。メンバー鋭意捜索中。

午後のカフェオレの習慣

毎朝、出勤前にコンビニでカフェオレを買っている。

www.glico.com

午後3時前くらいに、ほんのり眠たい気分がやってくるので、そのタイミングで冷蔵庫からカフェオレを取り出してきて飲んでいる。 飲むと、なんとなく頭がすっきりして、体感としては集中力を保って仕事を続けることができる。

社会人なりたての時に、仕事中にコーヒーを3杯飲んだことがある。その日の夜、ひどい吐き気とめまいに襲われて大変な思いをした。その体験から、特に検査とかで測ったことはないが、自分はあんまりカフェインに強くないんだろうという自覚を持っている。

カフェオレ300mlくらいで元気になっている自分のケースについてはプラシーボ効果なのかもしれないけど、なぜカフェインを摂取すると集中できると言われているのかのメカニズムを知らないことに気づいた。 今の世はちょっとした「何故?」にはGoogle先生がさっと答えをくれる。 SEOが強いページをいくつか適当に斜め読みしたら次のことがわかった。

  • 眠気を促す「アデノシン」を受け付けないように防いでいる
  • コーヒー100ml につき 60mg 含まれる
  • (カフェオレ300mlの半分がコーヒーだとすると、自分はいつもカフェイン90mg摂っている?)
  • 適量は1日300mgくらい(もちろん人による)
  • 作用は30分後から4~6時間続く
  • 飲み続けていると耐性がつく

斜め読み結果を見るに、意外と午後のカフェオレ習慣はそれなりに理に適っているのではないかなと思えてきた。

ところで「街」の雨宮桂馬をふと思い出して雪印コーヒー牛乳を買う日もたまにある*1のだが、カフェオレはコーヒーと牛乳が1:1、コーヒー牛乳は主体が牛乳でコーヒーはちょっとだけ入っている、と言う違いがあるらしい。自分の仕事の供にはカフェオレのほうがちょうど良いようだ。 けふも元気だカフェオレがうまい。

参考URL

*1:コンビニにあるラインナップのなかで、サイズ感とお値段的にグリコのカフェオレが一番リーズナブルだった

オフィスってすごいからホントマジで

コワーキングスペースを仕事場として利用する生活を約2年ほど続けていたのですが、2ヶ月ほど前のある日、とうとうオフィスが爆誕してメンバー全員がそこに通うようになりました。コワーキングスペースでも、スタッフの方々が大変よくしてくださり、快適に過ごせていました。しかしやはりオフィスがあるということの優位性は揺るぎないということをしみじみと感じております。 この感動が新鮮なうちに、コワーキングスペースとオフィスの違いを書き留めておこうと思います。

コワーキングスペース

メリット

  • 受付の人にお客さんの一次受けをしてもらえる
  • いろんな人のいろんな取り組みを目端に知ることができる
  • 気分で座る場所を変更できる(フリーアドレス
  • 掃除が行き届いていて快適
  • 観葉植物が元気
  • 基本的な文房具類を借りることができた、朱肉とか。
  • とにかくリーズナブル

デメリット

  • 社外の人が常にいる空間なので社外秘事項の取り扱いに余計注意が必要
  • サブディスプレイを置いておけない(ギリギリロッカーに入るサイズのものを都度出し入れして使う人もいる)
  • コップなど私物を置いておけない
  • 会社の物品も置いておけない
  • ミーティングスペースが争奪戦、追加料金が必要な場合もある
  • ホワイトボードも争奪戦

オフィス

メリット

  • 身内しかいないので喋る内容や画面表示に神経を尖らせなくてもよい
  • サブディスプレイを置きっぱなしでよい
  • 充電器(私物)を置いていってよい
  • ケーブル類(私物)を置いていってよい
  • 自分で選んだ良さげな椅子に座れる
  • お土産のおやつを堂々と置いておける
  • ミーティングをする机に困らない
  • ホワイトボードを消したくなければしばらくそのままにしておける
  • 好きなBGMを流してよい

デメリット

  • いきなり飛び込み営業(?)の人がやってくる
  • ひきこもると外界交流を忘れがち*1
  • 掃除は自分たちでする必要がある(ルンバが導入された)
  • 観葉植物も自分たちでお世話する必要がある
  • こまごまとした棚、文房具は自分たちで揃える必要がある
  • 維持費めっっっちゃ高価

まとめ

会社には当然オフィスがあって、オフィスにはいろんな設備があるのが当然だと思っていた時代が自分にもあった気がします。 自分はいま、自社サービスを生かしていくために日々キーボードをカタカタいわせていますが、同時に社内メンバーだけで占有できているこの快適なオフィスという空間を維持するためにも頑張らねばという気持ちもあります。 オフィスってすごい。

*1:これは個人的な性質なので治していきたい、勉強会行ったりとか

コメントの残し方を方向修正した

リポジトリをぼっち*1でメンテしていくにあたって、心強い味方は実装当時の自分自身のコメントだと思う。 それを実装する必要があったのは何故か、実装時に考えたこと、本当はこうしたかったけど制約で出来なかった、実装Bは何故却下したか...など、色々なことを書き残している。GitHubを使っているので、書き残し方法としてはPullRequestのコメントとして入れていた。

しかし、GitHubのblameから簡単に辿れるのはコミットメッセージだけである。 コミットのハッシュ値を検索にかけて過去のPullRequestを発掘してくるという方法もあるが、結構探すときに労力がかかることに最近気づいた。

Web上をうろうろしていた時に見かけた、コメントの残し方に関する意見*2 にも、GitHubに内容を残すリスクとして他サービスに移行した場合に失われてしまうという話があった。とても納得した。 以降は、これまで利用頻度が低かったgit commitをより意識して情報を残していこうと考えている。

今の所、次のようにTPOに応じて適宜使い分ける予定。

  • ソースコードのコメント: 実際の仕様の説明
    • 超重要な実装上の仕様。メソッドの使い方、引数の意図、などを書く。
    • 将来修正されるべきものについてTODOコメントなども書く。
  • コミットコメント: 機能単位の変更理由の説明
    • 1機能/1commit を守って積み上げ、機能の意図や変更理由を記録する。
    • 1PullRequestが複数のcommitで構成されることも当然ある。
  • GitHub上のコメント: 特定の問題の解決の瞬間にだけ必要とされたこと
    • リリース前後で気になって調べたこと、書き込み当時のサービス状況。
    • 考えた結果ボツにした実装案とその理由。

参考

*1:2018年秋時点でエンジニアチームは1名で運用されている

*2:url失念...発見次第貼ります!