HappyGoLucky

Web系サーバーサイド寄りの自動化大好きエンジニアの徒然なるブログ

2021年を振り返って

振り返る時期がやってきました。

2021年の習慣

今年も個人的週報を続けられました。

f:id:yasuhiroki:20220108181204p:plain

2019年から初めたので丸3年間の記録が残っている。ああーあの頃はこんなこと考えてたよなぁ、などと懐かしい気持ちに浸れる程度の過去を思い返すことができる。

2021年のチャレンジ

2020年の振り返りには↓を書いていた。

2021年はもう少しワイルドに挑戦したいところ。(中略) あとはストレス発散が下手すぎるので新しい趣味か何か見つけたいところ。

業務上ではあまりワイルドな挑戦はできなかった。自分の技術的好奇心と課題解決意欲と何でもできる気がする勘違いの促すがままに多種多様な業務の効率化や自動化を推し進めていきたい気持ちがあるものの、自分程度の理解度では効率化された仕組みは作れないという冷静な気持ちもあって、自分が直接作業をする範囲外に手を出すことができなかった。自分の作業範囲程度なら、オレオレツールを作ったり (自分にとって)メンテしやすいデータ構造に変更したり serverless + AWS EventBridge でクローン的な処理を作るなどしてきたけど、ワイルドな挑戦かというと、まあ @yasuhiroki ならそれくらいはするよねって感じがする。
最近は自分が直接業務を担当する範囲外にもっと目を向けるようにしていて、時には話を聞いたりもして、もっと効率的に解決できそうな課題が転がっていないか観察している。

新しい趣味を探す旅はまた続いている。意識的に、今までやったことがないことに手を出してみるようにしていて、例えばお菓子を作るようになった。
料理は慣れてくると面白いもので、この感覚はプログラミングに言い換えることができる。新しい言語やフレームワークを覚え始めた頃に近くて、思った通りのものが作れたり、ドキュメントが何言ってるのか理解できるようになって、まさに完全に理解した状態になっている。ここからさらにスキルを身に着けようとすると大変なのだろうけど、家族が喜ぶ程度のもので良ければ極める必要もなく、どこかで見かけた料理を検索してレシピ通りに作ってそこそこ美味しくできればOKだと思っているので気楽でよい。

一方で続かなかったものもあった。電子工作と裁縫と競技プログラミングである。振り返ってみるとどれも集中する時間が必要というところが難点で、その時間を家庭内で確保することが難しかった。その点、料理は集中する時間そのものは限定的で、オーブンで焼いたり鍋で煮詰めたりする時間は娘とレゴブロックで遊んでてもそんなに支障はなかった。
電子工作は典型的な何を作りたいか分からない問題に陥っていて、XX みたいなやつ作りたいと思った 2秒後には XX を買えばええやん、という気持ちになってしまって続かなかった。
裁縫はソーイング・ビー を見て影響されて始めたものの、どうやったら作れるのか何もかも分からない状態から抜け出せずにいる。...と書いてみると、電子工作にせよ裁縫にせよ道具や材料を準備するのが面倒くさいだけなのでは、と思えてきた。 競技プログラミングは復習する時間が楽しくもあり難しくもあるもので、解説を読んでも理解できない問題が気になりすぎて日々のちょっとした時間に少しずつ考えて考えてようやく解けたのが 3週間後とかで、あまりに時間がかかりすぎて気が滅入ってしまった。

続かないものもあったけど、経験したことがないものに挑戦するというのはそれだけで楽しいもので、なんだか 2021年は充実した趣味時間を過ごせたような気がする。

会社

実は弊社、2020/01 の時と比べて社員が倍増している。たぶん。
社員数が倍になれば会社の環境にも変化が出てくるわけで、この変化を楽しみたいというのが、前述の "自分が直接業務を担当する範囲外にもっと目を向けるようにしていて、時には話を聞いたりもして〜" という話にもつながる。
特に他業種、他業務を行なうチームがすぐ隣にいたり直接関わったりするというのは、今の規模だからこそできる経験なので今のうちに多くの考え方や仕事の進め方というものを知りたいと思う。知らないことがあるというのを知ることが楽しい。

そういえばオフィスが移転した。

社外活動

DroidKaigi にプルリクを出した。

github.com

ステータスバーのカラーを動的に切り替えるというやつで、仕様を勘違いしてプルリクを作り直すことになった。分からない時は素直に分からないって言えば良かったのだ...。とても反省している。

久々にLTもした。オンラインイベントのLTを自宅でとなると、自宅の部屋数の都合上により当日に参加できなくなるリスクがあって難しい...。

脱・Evernote 計画 (諦)

地味に時間をかけたこととして、脱・Evernote 計画がある。
私は子どもの育児日記のようなものを Evernote に書いており、それがそれなりの文量になってきたせいか AndroidEvernote で書こうとすると1文字ごとに 3秒以上待たされるようになってしまったので、脱・Evernote を計画した。
Notion、Inkdrop、UpNote をそれぞれ試してみて、Editor としての機能はどれも良い体験だったのだけど、そもそも何で Evernote 使ってるんだっけ...そうだそうだ画像やPDFも含めて検索できるところが良いんだよな、と気づいて結局 Evernote に戻ってきた。
ちなみに子どもの育児日記が書きづらい問題は、ノートを小分けにすることで解決された。

まとめ

2021年は個人的には色々と新しいことに取り組んだり経験をして充実していたように思う。
引き続き、今までやったことがないことに挑戦していきたい。

初めて自社がエンジニア向けイベントのスポンサーになることに何を思うか

弊社ことエーテンラボは iOSDC 2021 のスポンサーをしています。

www.wantedly.com

これが個人的に感慨深いのですが、どうして感慨深いのかを言語化するのが難しかったので、整理してみました。


私にとって、大規模なイベント、特にコミュニティドリブンで規模の大きなイベントの存在は転機であり、あるテーマに関心のある人々が一同に集まって知見と感覚を共有し合うあの空間はとても居心地が良く、自分がその空間の一部であることがとても好きです。

私が初めて500人とか1000人といった規模のイベントに参加したのは YAPC::Asia Tokyo 2015 です。開始早々から衝撃を受けました。「なぜ私は指輪物語の説明を聞いていて、なぜそれがこんなにも楽しいのだろう」と思ったことを今でも覚えています。なんだか特別な時間を過ごしているような気分で、内容は全く覚えていないのですが、なぜだか Perl6 がとても魅力的に感じました。1
どのセッションもLTもワクワクするものばかりで、この時間が永遠に続けばいいのにと心底思ったものです。ソフトウェアの技術を貪欲に学ぶようになったきっかけの一つで、この時の高揚感がなければ私は違うエンジニア人生を送っていたことでしょう。2

私にとってエンジニア向けのイベントは、研鑽を積む場であり交流の場であり一種の娯楽でもあり、あるいは帰るべき場所と言ってもいいような、そんな特別な感覚があります。

そのようなイベントに自社がスポンサーしているというのは、もちろん経営戦略上なの目的があるでしょうし、私もその目的に同意するものですが、それはそれとして、個人ではなく所属する組織が開発者コミュニティを支援しているということが、何とも形容しがたい気持ちにさせてくるのです。

社員3人目としてジョインしてから4年が経ち、ようやくスポンサーができるまで会社が成長したという達成感もあるし、自社がスポンサーになっているという誇らしさもありますが、それらが全てというわけでもなく...なんだか安心したような気分があるのです。

これはどういう感情なのか何日も考えて捻り出したのは、あの頃の自分のように、エンジニア観が変わるような体験が得られるかもしれない時間へ微力ながら支援できる組織に属することができて良かった、という表現です。

これが今のところ一番具体的で適当なんじゃないかと思います。

同じような状況になった先人の方はどのような気持ちになったのか聞いてみたいです。


  1. 同じ空間のどこかにいた人とたまに勉強会で出会うことがありますが、この keynote の話をすると必ず盛り上がるのがとても好きです。大抵、あの時の同時通訳はすごかった、という話になります。

  2. 興奮したまま社内(当時は前職にいた)の週次ミーティングで参加レポートを共有したのを温かい目で見守られました(悪い意味じゃないです)

自分にできる自動化の手段を整理して弱点を直視する

はじめに

なんでも自動化するエンジニアを名乗ってから4年が経った。
ようするに今の会社に転職してから4年が経ったということで、別に区切りが良いわけでもないけど、これまでの経験を踏まえて自分にできる自動化って何だろう、というのを整理してみる。

私にとっての自動化

整理する前に、私にとっての自動化とはなにかを定義する。

シンプルに Wikipedia1 を引用すると、

自動(じどう)とは、機械装置が人間などの他の力を必要としないで、能動的に作動することをいう。

とのこと。特に反論はない。

ところで先日、 自動化大好きエンジニアLT会-vol.3 というイベントで久々にLTをしてきた。その中で、自動化を習慣化するには自動化のハードルを下げる ≒ 自分の中で自動化の定義をゆるゆるにしよう、という話をした。

これは本当にそう思っていて、塵も積もれば千里の道もということで、オレオレ alias を追加するでもよし、vim のキーマップを新しく覚えるでもよし、なんなら Android StudioGitHub のプルリクエストを操作する方法を調べるでもよい。

つまり、自動化が達成されるまでの調査や検証といった行為も含めて自動化と呼んで、俺は毎日自動化しているぞ、という気持ちでやっていこうという話である。

f:id:yasuhiroki:20210905001728p:plain

私にできる自動化の手段

まずは自分がよくする自動化の手段を洗い出してみる。

あとは、使っているサービスの機能を使ってどうにかすることもある。

洗い出してみると、逆に私が苦手な手段も見えてくる。

基本的にGUIで解決することを苦手にしている。

今後の方針

GUI で解決することが苦手というのは弱点である。
私の自動化にはGUIを伴わないということは、GUIがなくても扱える人としか共有できないということである。言ってしまえば、私の自動化はせいぜいエンジニアとしか共有できない。

そもそも私は、GUI を利用する時点で自動化できる範囲が最大化されないと考えていた。GUI があるということは、人間がそこで何か操作することが前提になる。人間の操作が必須となる設計をする時点でそのシステムは半自動化が限界になる。自分から全自動化の夢を諦めるなんてナンセンスである、と考えていた。

なので GUI を作るモチベーションはゼロだったのだけど、最近になってというか今更になってというか、解決したい問題によっては GUI を用いるのが最適なものもあると思うようになった。

複数の操作をまとめてやってくれるCLIツールとGUIツールのどちらの方が活用できる人が多いかといえば、そりゃあGUIツールの方が多いわけである。解決したい問題に関わる人が多いところでは、GUIでもって自動化した方が便利なわけである。

ということで重い腰をあげて、苦手意識のある JavaScriptCSS と デザイン(を楽にそれっぽくできる方法)の勉強をやっていこうかなぁ、と思う今日このごろでした。

Refined GitHub の初期設定覚書

Refined GitHub というブラウザ拡張機能を試してみた。
いろいろ設定をいじって自分好みにしたのでその覚書。

もともとはGitHub上で文章添削したいなーと思って、なにか既存のものがないか調べてたら GitHub の topics chrome-extension · GitHub Topics · GitHub に流れ着いて Refined GitHub を見つけた。
基本的に GitHub をブラウザで使わないようにするのがポリシーで、そうすれば自然と CLIGitHub を操作するようになって自動化が捗るからなんだけど、とはいえ最近は会社に人が増えて GitHub 上でのコミュニケーションも増えてブラウザで見る時間が長くなってきたので、ここは一つ試してみることにした。

Refined GitHub は2016年からあって今も活発に、というか最近の方が活発に更新されている。1

f:id:yasuhiroki:20210829022810p:plain

2021/08/29時点では 213 の機能があり、それぞれ有効・無効を切り替えることができる。機能は絞り込み検索できる。

f:id:yasuhiroki:20210829024006p:plain

機能は大きく分けると、

  • UI をシンプルにする
  • 表示される情報を追加する
  • ショートカットを追加する
  • あるあるな操作ミスを防止する

の 4つに分けられる。
まず私は基本的には GitHub がベストと思って提供しているだろう今の UI に身を委ねたいので、表示を大きく変えたり挙動を変えるような機能は無効にした。ただ、リアクションしたアカウントのアイコンを表示したり、プルリクが最初に含まれた tag を表示する機能は有効にした。リアクションをマウスオーバーしなくて済むし、release の list から調べなくても済む。これは便利。
ショートカットは、 Hot key の追加という方法と、ボタンを表示してワンクリックで機能が使えるようにする方法とで提供されていて、この辺は今まで通り CLI でやる癖をつけたいのでほとんど無効にした。 そんな感じで 213 機能すべてに目を通して有効・無効をチェックして、最終的に有効にしたのは 29 だった。

この設定値を export して管理したいのだけど、そういう機能は Refined GitHub そのものにはないらしく、プルリク募集中とのことだった。2
ただ、拡張機能の設定値は chrome だと chrome.storage で保存・取得・共有ができるらしく3、Refined GitHub もこれを使っている。なので chrome.storage から get して set する方法がある。たぶん Refined GitHub に設定した GitHub の personal token も含まれてるので get したデータの扱いには注意が必要だけど、私は personal token が必要な機能は無効にしててそもそも設定してないので(たぶん)そんなに気にしなくていい。

ということで、未来の自分が Refined GitHub をどう活用しているのかに期待。

2020年を振り返って

振り返る時期がやってきました。

2020年の習慣

今年も個人的週報を続けられました。

f:id:yasuhiroki:20210104015313j:plain

週によっては2行の時もあったけど、毎週欠かさずに書き続けている。
最近は、作業時に思ってることや試したことをなるべくメモに残す場所として週報を使っていて、内容がとても充実している。
メモ駆動開発と自分では呼んでいる。きっかけは自分が作ったバグのデバッグをしている時で、バグの原因調査と修正方法が適切であったことを未来の自分に証明するためにメモを残しておこうと思い、そういえば rebuild.fm で higepon さんがメモ駆動開発の話をしていたような気がするな...と思い出して試してみたらしっくりきたので続けている。メモ駆動開発も rebuild.fm で聞いたんだっけ...。肝心なところをメモしてなくて分からない。

あと体調を崩すことが多かったので、何かパターンがあるんじゃないかと思って体調のメモを残すようにしている。
毎日のように検温と体調のメモを残しているのだけど、今のところこれといって発見はない。データが足りないのではと思っていて、気圧計や湿度計の設置を検討中。


今回も月別振り返りをしようと思ったのだけど、いざ書いてみるとあまりトピックがなかった。
月別に振り返るよりも、2020年はこんな年だったな〜 というほうがまとめやすそうだ。

Android開発

2月からAndroidの主担当になった。
今までもAndroidアプリの開発に手を出してはきたけど、自分が主軸となると話は別で、既存の実装や設計を把握できていないことからスケジュール感が読めず、優先度順に実装できたものからリリースしていく感じだった。 当初は ViewPager の layout_height が wrap_content をサポートしていないことに気づかず時間を溶かしたり、既存の実装を活かすべきなのか作り直すべきかのかの判断に悩んで時間を溶かしたりと、自分の生産性がなかなか上がらずに悶々としていた。
やがて ConstraintLayout を完全に理解した、という気持ちになれたので layout は余裕で実装できるようになった。そのせいか xml で完結できるものはなるべく xml に寄せる癖がついているような気もする。

不慣れながらも成果物は出さねばならぬ、とアウトプットを優先したので、既存の実装のリファクタは控えめにした。2021年はテストコードをもっと書いて積極的にリファクタをしていきたい。共通化すべき・すべきでないドメインロジックを明確化し、それがソースコード上で表現されている状態にしたい。
あと、リリーススピードをコントロールする面ではうまくいったけれど、いろいろ不具合も出してしまったので、アプリの安定性もコントロールできるようにしたい。
リファクタにせよ安定性にせよテストコードが重要だと考えている。

チーム開発

私はAndroid開発に集中させてもらったこともあって、2020年はあまりチームの状態が気にならない一年だった。振り返ってみると自分のことについて考えさせられる1年だった。
2019年の振り返りブログでは、「チームの課題の文言化と解決策の実施・振り返りができる 2020年」にしたいなどと書いていたけど、蓋を開けてみれば「今の私にできる範囲でチームに貢献する2020年」になっていた。そこには緊急事態宣言後の育児x仕事の両立が激ムズだったことが大きい。

育児とストレス

緊急事態宣言が出されていた時期は子どもを見ながら仕事をすることになったのだけど、これがかなり無理ゲーだった。
1日で私が集中できる時間は13:00~16:00と22:00~25:00で、時間だけみると6時間あるので仕事できそうな気がするけど、8:00から22:00まで14時間勤務した後にさらに3時間仕事するような気分だったので夜はまるで捗らなかった。稀に捗る日もあるけど、それを継続させるのは私にはできなかった。

最終的に深夜に家を出てコンビニでお菓子を買って河原で食べるという謎ムーブをかますことになった。 ストレス発散が下手すぎる。

副業

ブログで告知を出した数秒後に知人から連絡があって、トントン拍子に契約が決まった。
知人経由ということもあってコミュニーケーションは全く不安なかったのだけど、今まで触ったことがないインフラプラットフォームが業務内容だったのでとても苦労した。家で長時間集中するのは難しいので、土日のどちらかはマクドナルドやカフェにこもっていた。自分の部屋がある家に住みたい。

まとめ

2020年はAndroidにせよ副業にせよ育児と仕事の両立にせよ、色々と経験を下積みした年になった。最高を求め続けると無理がくるので最善を尽くし続けるようにした1年だった。 2021年はもう少しワイルドに挑戦したいところ。具体的な目標を立てるのはやめておく。業務や状況が変わると全く機能しないと分かったので。今まで具体的すぎたんだろうなぁ。 あとはストレス発散が下手すぎるので新しい趣味か何か見つけたいところ。

個人ではタスク管理ツールを使うのやめてみた話

最近 Todoist にカンバン機能が追加されたと知った。

blog.doist.com

最近の Productivity Tool は ClickUp のような All in One が流行っている気がしていて(根拠はない) Todoist もその時流にのってきたのか...と思って使ってみようと思ったけど、そもそも最近、タスク管理ツールを使うのやめたんだよな、と思って、その経緯や意図をまとめてみた。

タスク管理ツールと私

Todoist にせよ Trello にせよなんにせよ、私にとってタスク管理ツールを使う理由は、そこにタスクを書いておけば安心して忘れていられるという点にある。
言い換えると「何をすべきか忘れている気がする...」という不安から解放されるために使っていた。
しかしタスクを忘れたくない、という気持ちからどんどん追加するので、常に 追加 > 消費 の状態となってしまう。定期的に整理をするというTODOを作って取り組んだこともあるが、整理が少しでも滞るとすぐに溜まるのでやがて嫌になってきて、最終的にすべてを忘れるためにサービスを乗り換えていく。

Evernote -> Google Keep -> Any.do -> Google タスク -> Trello -> ZenKit -> Todoist -> ClickUp

と乗り換えてきて、さすがに同じことの繰り返しすぎてアホでは...という気持ちになってきた。

タスクとアイデアを区別する

大量に積まれていくタスクを眺めて見ると、おおよそ3パターンに分類できた。

  1. 「新しく習慣にしたい定期的なタスク」
  2. 「仕事や約束といった実行しなければならないタスク」
  3. 「こういうのできたらいいな、という思いつきのタスク」

こうしてみると、タスクが増える一方なのは 3. の思いつきタスクのせいだ。 xxx というツールを使ってみる、とか、yyy ソースコードを読むとか、zzz の本を読むとかがこれで、たいてい、タスクを追加した時のモチベーションは失っているので、永遠に実行されない。
もはやタスクではなく、思いついたアイデアをメモしているだけである。もっといえば、実行しないアイデアというのは、それを思いついたことをどこかに残して「あ、これ前からしようと思ってたんだよ」と言うための証拠を作ることが目的のようなもので、私の自己満足でしかない。

ということで、3. のアイデア的なタスクは TwitterEvernote を使うことで、タスク管理ツールに入力しなくて済むようになった。

定期的なタスクはいずれ、すでに完了したのに残ってしまう状態になる

残るは、

  1. 「新しく習慣にしたい定期的なタスク」
  2. 「仕事や約束といった実行しなければならないタスク」

を整理する。

まずは 1. の定期的なタスクについて考えてみると、これは習慣が身につくまで忘れずにいるために、タスク管理ツールを見れば必ず目に入る、という状況を作っておくことが目的だった。これは私にはとても有効で、毎日サーバーやアプリのモニタリングをチェックすることや、毎週個人用の週報をつけたり、毎月サーバーの費用を確認する習慣が身についた。今のところ、新しく習慣化したいものはないため、タスク管理ツールを頼る必要はない。
こうなってくると、タスク管理ツールを見るまでもなく「すでに完了した」状態になる。
ツール上では「未完了」のタスクが残ってしまい、整理を怠ると、タスクが溜まる要因の一つになる。

とはいえ、習慣を身につけるために有効であることに間違いはない。

仕事や約束といったタスクはそれを実行する環境上で管理するのが良いというポリシー

  1. の「仕事や約束」のタスクについて考えてみる。

また、タスク管理ツールを見れば必ず目に入るという状況を作るには、タスク管理ツールを見る習慣がある前提が必要になる。
そのためには、 2. の「仕事や約束」のタスクが全て同じタスク管理ツールに書かれているかどうか、が鍵になる。仕事上必ずそのタスク管理ツールを見る必要があれば、自然と習慣化したいタスクも目に入る。しかし、私はダブルメンテが嫌いなので、仕事のタスクとプライベートのタスクが、それぞれすでに適切な場所で記載されている場合は、それを自分のタスク管理ツールにコピーしたくない。

仕事のタスクは GitHub, esa.io, Slack で、それぞれの粒度で管理されている。GitHubアサインされている Issue が私のタスクだし、 esa.io で進捗状況が報告されているのでそれを見て自分のタスクの優先度を調整し、Slack でたまにちょっとした作業を依頼されたりしている。それぞれのツールを使うことが業務の一部だし、それぞれのツールで自分のタスクを管理すればチームへ情報共有となり貢献となる。自分のタスクを自分だけのツールで管理することは別に悪いことではないが、そのタスクが個人に閉じてしまうことで、チームへの貢献チャンスを逃している可能性がある。

プライベートのタスクは、個人的なものはタスク管理ツールが使えるが、家族単位のタスクだと TimeTree を使っているし、書類や家計といったデータを残しておくことに価値のある場合は Evernote や SpreadSheet を使うこともある。プライベートにおいて、必ず実行が必要なタスクというのはほぼ家族が関係するものだし、それなら TimeTree でタスクにしておいた方が進捗や完了を共有するのも簡単で効率的だ。

何らかのグループが関係するタスクは、そのグループで使用しているツールや仕組みを使って管理するのが良い、というポリシーに則ると、残されるのは「個人的なタスク」のみである。

つまり、私がタスク管理ツールを活用できるのは「新しく習慣にしたい定期的なタスク」と「個人的なタスク」の 2つに絞られる。

忘れないために書き残すことで熱意を失う

「個人的なタスク」は私の場合、XX本を読むとか YYの記事を見るとか ZZリポジトリソースコードを読む、などが多い。どれも、その時は「これは忘れずに読まねば!」と意気込んでタスク管理ツールに追加している。しかし「忘れずに読まねば」のうち「忘れずに」という問題は解決できるが「読まねば」という熱意が維持されるかどうかは本人依存となる。そして私はほとんどの場合、タスクを追加した当時の熱意を思い出すことができず、そのタスクを見なかったことになる。
見なかったことなる回数が多くなると、タスク管理ツール自体を見なかったことにする回数も増えてくる。 すると、「タスク管理ツールを見れば必ず目に入るという状況を作っておくこと」で習慣化させようとしていたタスクも、見なかったことになる。

必要なのはタスク管理ツールではないと気づいた

そもそも、私は自分が忘れっぽいからタスク管理ツールを使おうとしているが、忘れっぽいというのは気が変わりやすいということだ。
タスク管理ツールは、心変わりを止めるツールではない。
むしろ、これと決めたゴールに向けてまっすぐ取り組むための計画をサポートするためのものだ。

私に必要なものは、自分のタスクを管理するツールではなくて、何のためのタスクを管理したいのかを明確化させることだと気づいた。

て、思い切って何も使わないことにした。

使わなくなった結果

無限に増えていくタスクに飽き飽きしたり、何も終わらせられない自分に呆れたり、ツールの使い方や新機能の把握に時間を取られることがなくなり、思いのほか楽になった。 ツールに残さないことで逆に「忘れるから今やってしまおう」という気持ちになるので、なんだかんだタスクを忘れることも(ほぼ)ない。

一方で、自分が過去に追加したタスクを見るというのは、ある意味で自分との対話になっていたのだとも気づいた。
追加されたタスクから、その時に何に興味を持っていたか、何を課題に感じていたかを思い出すことができ、今と比べることで自分の変化や成長を感じることができる。
その時自分がすべきと思ったもの一覧、というのは Twitterや日報からではノイズが多くて見るのが難しいので、タスク管理ツールではなくとも何かしら形にできると面白いんじゃないかな、という気がした。

hub で Issue や PullRequest を修正できるようになった

↓がマージされてできるようになった。

github.com

個人的に、あればいいな(なかったら別の手段でやるけど...)と思っていた機能が hub に入った。

hub issue update 16 --edit

などと実行すれば、id: 16 の Issue もしくは Pull Request の既存の title と body がエディターに展開される。

f:id:yasuhiroki:20200202150602p:plain

あとはそれを好きなように更新すればOK。

プルリクを見ると分かるけど、最初は hub issue edit というサブコマンドだった。
だけど hub issue edit --edit というのちょっと分かりづらいよね、という意見から hub issue update という名前に変わった。
他にもラベルを付けたり消したりするオプションの仕様と名前をどうしようかー、という議論もされてて、こういうの普段自分たちが業務でやってることと同じなので、OSSだからって何かすごいやり方とか想像もつかないコミュニケーションがされているというわけではないんだなー、と勝手に親近感を持ったり安心したりした。