HappyGoLucky

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

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だからって何かすごいやり方とか想像もつかないコミュニケーションがされているというわけではないんだなー、と勝手に親近感を持ったり安心したりした。

hub を install するだけの orb を作った

hub を CircleCI で使うための orb を作った。

github.com

こんな感じで使える。

version: 2.1

orbs:
  hub: yasuhiroki/hub@v0.0.1

jobs:
 install:
    docker:
      - image: circleci/node:latest
    steps:
      - hub/install
      - run: hub --version

workflows:
  test:
    jobs:
      - install

当初は hub/release とか hub/create-pr とか作って、 hub を使った command をいくつか用意しようと思ったんだけど、私はシェルでゴリゴリした結果をもとに release を作ったり pull request を作ったりしたいのだと気づいて、ただ hub をインストールするだけの orb になった。
結果、 circleci/aws-cli orb と似たような感じになった。

ちなみに hub を使いたい理由は、私がふだんから hub を使っているから。
CircleCI で GitHub のあれこれを自動化するために GitHubAPI を調べてスクリプトを書くのも手間だし 1 hub の使い方を知っていればCIで何してるのかも分かる、という統一感があって嬉しい。


  1. 作ろうとした けど hub でいいじゃん…という気持ちになって止まってる

2019年を振り返って

2019年も振り返っていくぞ。

2019年の習慣

2019年はEvernoteに個人的な週報をつけてみた。
仕事のことも家庭のことも思いつきもイベント事もつらつらと書き続けた。

f:id:yasuhiroki:20200101154848p:plain
週報の一覧

我ながらよく続いたなと思う。
毎週必ず書くのしんどいかなーと思ったけど、仕事では 1週間区切りの sprint なので weekly scrum で何かしら書くことあるし、育児ネタも湧いてくるのであまり苦労しなかった。もし毎日書いてたらしんどかっただろうけど。
あと自分のことをあまり書きすぎないようにしたのも良かった。
昔、4行日記を書いてたことがあるんだけど、ほぼ自分の失敗と反省ばかりで辛くなって続かなかった。まあ社会人2年目~3年目の頃なので、そういう時期だっただけかもしれない。

ちなみにペン字も始めたんだけど、こちらは続かなかった。
成果を実感しづらいと習慣化は難しいなーと思いましたまる。


では月別振り返り。

1月

家族全員インフルエンザ。きつかった。
朝活をしようと思って早起きしてたんだけど、私が早起きすると物音のせいか子どもも早起きするので結局時間が取れなくてやめた。

1/30の 第1回CircleCI ユーザーコミュニティミートアップ 後に CircleCI Japan User Group の Community Leader になった。

業務では OKR を試し始めた。タスクの優先順位が明確になって良い仕組みだと思う。

2月

背中の痛みに悩み始めた。後日病院にも行ったけど改善されず、今もたまにジリジリした痛みを感じる。
同僚に筋トレのせいではと言われて背筋の筋トレをやめて少し楽になったけど、根本的な痛みの原因だろう我が子は日に日に体重が増えるので、これはもうずっと付き合う痛みと思うことにした。

OKRの自信度を0~100%だと尺度が広すぎてこまかい数値の上下が気になっちゃうから5段階くらいで良いのでは〜という意見を持った。

3月

大きな新機能をリリースして、それなりに結果も出たのでホッとした月だった。
新機能にどれほどの効果があるのか未知数な上にかなり工数がかかっている状態だとストレスだった。個人的にもストレスだったけど、それ以上にチームとしてもストレスがある...ように感じてしまうのがしんどかった。

イチローの引退会見を何度も見てた。

4月

担当大臣制というものを試し始めた。
OKR で決めた KR 達成を目指して各施策を打つんだけど、その施策の取りまとめ役を担当大臣と呼んだ。仕様決め・施策内容の検討・優先度の決定などの実行権限を与えられて、自分がすべきことに集中できるのは良くて当初はいい仕組みだと思ったんだけど、自分の担当外への関心が下がってしまう弊害もあった。アイデア段階で意見しなくなったせいか、ほぼ実装が終わった後に「これで良いのかなー」という反応をしたりされたりして手戻り作業を増やしてしまう。
たぶん、チーム内の相互理解が相当進んでないと効率的に進まないシステムのような気がする。それこそ公安9課みたいな。

この時期はMTGが泥沼化する傾向があって頭痛の種だった。他の文章にしづらいイベントや育児ストレスも相まって、2019年で一番体調が優れない時期だったと思う。悪夢を見て叫びながら目が覚めるという初めての経験をした。

5月

文章にしづらいイベントをきっかけに MISSION / VISION / VALUE / CREDO / HABIT を決め直したり新しく決めたり。
とても時間がかかったけど、自社を自分の言葉で説明できるようになって良かった。自社サービスしか説明できなかったもんなー。

体調が回復した。今思うと、やっぱ私のストレスの原因はアレだったんじゃないかと思う。そう思うと、次また似たようなストレスを感じたり、その予兆があったらすぐに対処しようと思う。具体的には自分のストレスを言葉にすること。

あと副業の検討を始めた。

6月

育児サポートのためリモートワークが増え始めた。
ただ、リモートワークを前提とした開発フローではないので、リアルタイムにオフィス内で決まったことが伝わらずに効率がよくない。特に、何をするのか決まったことは書いてても、なぜそうなったかが分からなくて、すでに議論済みのことをコメントして聞き返したり、違う解釈をしてズレた実装をしたりして効率が悪い(という感覚を持っていた)。
とはいえリモートワーク前提の組織にするのもコストだし、今はあくまでもリモートワークはオプションだと思っているので、この辺はリモートワーク側が自分の作業効率のために努力する部分だと思っている。議論済みかもしれなくても自分の解釈が正しいか確認すべきだし、ツールは何でも良いので電話して直接会話することを積極的にすべき。

妻と子どもが1週間半帰省した結果、私の顔を忘れられてしまってめっちゃショックだった。
だからリモートワークを増やしたのは内緒。

7月

Androidの開発タスクが増えてきたんだけど、AACとかKotlinとかRetrofitとか自分の知らない技術への勉強時間が足りてなくて追いつかない。
同僚がどんどん新しいのを取り入れるのでプルリクベースで追いかけるのがやっとという感じ。業務中に勉強できないと時間が取れない生活をして片手間で開発してると、まー時間が確保できない。RubyAWSのキャッチアップも続けたいので、結局、薄く広くな知識になっていく。本気で勉強したいなら絞ったほうが良いんだろうけど、どうするかはまだ悩み中。

もっと仕様を整理した開発をするにはどうしたらいいんだろ、と思ってエリック・エヴァンスのドメイン駆動設計を読み始める(まだ読み終わってない)

8月

体調が芳しくなく熱を出した。
2018年の8月も同じような感じだったらしい。周期的なものなのか...。

circleci.vim を作った。

9月

情報共有不足(する側もされる側も不足している)から手戻りが発生してかなりもやっとした気持ちになった。
計画的にそうしてるんだと思ってたので口を挟まなかったんだけど、蓋を開いてみたらただの認識違いだった。オフィス内で決まったことを共有しきれてないせいなんだけど、GitHubへの記述が間に合ってなかったり、そもそも当初から開発の進め方の足並みが揃ってなかったり、工数と実際の成果物が出る日数にズレがあったりと、マネージャーが存在しないことによるデメリットが噴出した月だった。
今でもマネジメントは必要だと思っているけど、デメリットが見えてるならある程度は仕組みで解決できるんじゃないかとも思っている。気をつけるとか注意するとか、そういうのは嫌いなので、自然と情報共有するしキャッチアップするような仕組みを考えたい。まだ考え中。というかこれ習慣の話なので、何とかできないと何のサービスやってんだという感じもする。

10月

テスト漏れの不具合があって、CIの仕組みにまだまだ改善の余地があると実感した。実装した箇所のカバレッジがなかったら怒られるような仕組みが欲しい。そういうのSaaSでありそうだけど。

実家に1週間くらい帰って完全に技術から遠のいて、いざ仕事に戻ると辛いのなんの。毎日少しでもエンジニアモードにはなった方がいいなーと思った。

11月

個々人の開発の進め方の違いに悶々とした出来事があった。後日この辺の話をすると、経験してきた開発フローが違いすぎるのがベースにあるようだった。この辺は整備しないと、いつまで経っても噛み合わないので考えたいところ。

私の作業ミスがチラホラ増えてしまって気を引き締め直した。ミスのうちいくつかはCIで自動検出できるようにしたり、レビュー漏れがないか確認するためのチェックリストを用意した。また、 # TODO: あとで直す はあとで直さないので、わざと落ちる実装にしておいてエラーを起こすようなスタイルに変えた。

12月

入社後最大のビッグイベントを経験し、やはり私はデバッグ作業が好きなのだと改めて自覚した。
最終日に社員エンジニア飲み会が開かれて、かなり話し込んだ上にまだ話し足りないので、もっとこういう時間が必要なのではと思えた。
副業募集を公言した。


まとめ

2019年は、個人の課題というよりチームの課題を意識した年だった。
そのチームの課題の文言化と解決策の実施・振り返りができる 2020年にしたい。
個人の課題はたぶん副業の方でボロボロと出てくるので粛々とやっていく。

相変わらずアウトプットは少ないので(勉強会でLTしないとまずアウトプットしない)このブログをもうちょい使おう。

副業はじめます

TL;DR

  • 副業を探しています
  • ライフスタイルを崩したくはないので月10~20時間程度の副業を探しています
  • Jenkins認定エンジニアを持っていたり CircleCI User Community Leader をしていたりと CI/CD に強いです
  • 開発チームはビジネス要件に集中して開発効率化は誰かに任せたい、先人が残したCIが死んでて困っている、といったニッチでスポット的なお仕事が最適です
  • AWS / Rails / Android の開発をお手伝いすることもできます
  • 何かお手伝いできることがあればご連絡ください

あなたは誰?

@yasuhiroki (twitter@duck_yasuhiroki) というアカウントで活動しているエンジニア歴8年目の男です。
現在は恵比寿にあるベンチャー企業AWS : Rails : Android を 5 : 3 : 2 くらいの割合で触ってるエンジニアをしています。最近 Android 率が高まりつつあります。

Jenkins認定エンジニアという資格を持っていたり CircleCI User Community の運営に関わっていたりと CI/CD まわりが好きです。
前職では新規事業開発、現職はベンチャーということから 1人N役な開発経験が多く、0→1 や 1->10 くらいのフェーズに馴染み深いです。

できること

  • CI / CD の構築・メンテナンス
    • CI/CD の導入
      • 初期設定, Test, Deploy, Release 一通り何度もやってきたので得意なところです
    • Jenkinsに困っている(=使いこなせていない)という状況ならお力になれると思います
      • 死にかけのJenkinsさんの介護に困っているならご相談ください
      • とはいうものの、ここ2年は知識を更新していないので、たとえば Jenkins X についてのノウハウはないです
    • CircleCI
      • 現職では CircleCI をメインに使ってるのでノウハウが溜まっています
    • GitHub Actions
      • 趣味程度ですが enjoy しているので程度知見があります
    • Google Apps Script
      • CI/CD とは少し逸れますが、業務改善というくくりだと GAS は中々便利で優秀なツールだと感じています
      • 現職では CS 対応の管理用ツールを GAS で作って GitHub と連携して自動化したりしています
  • AWS 開発
    • 5年くらい経験があり、現職での本業はここです
    • VPC設計 / Security設計 / システム設計 は一通りできます
    • CloudFormation チョットできます -> Qiita
  • Rails 開発
    • 2年ほどの開発経験があります
    • Rails 4.2 から 5.0 へのアップグレードをしたり Fat Controller な実装を Model に移したりとリファクタしたり
    • 最近は RuboCop のカスタム Cop を作ってコードレビュー効率化図ったりしています
  • Android 開発
    • トータルで1年ちょいくらいの開発経験があるので多少はできますが AWSRails に比べるとレベルが落ちます
    • 具体的には AAC を勉強中で使いこなせていない、という感じです

できないこと

  • Windows / iOS アプリ開発の経験はありません
  • JavaScript は GAS や AWS Lambda + Node.js の経験がほとんどなのでフロントエンドのお手伝いは難しいです

趣向や性質

ストレングスファインダー によると↓の性質を持っているようです。

  1. 最上思考
  2. 学習欲
  3. 達成欲
  4. 調和性
  5. 収集心

バグは絶好の学習材料という認識を持っているので楽しく調査します。
解決できた時は最高に嬉しいですが、時間の都合で取り急ぎワークアラウンドで回避する時もそれはそれで楽しいと感じます。
結局は、目の前に分かりやすい問題があると何かしら解決したくなる性分なのだと思います。

連絡先

TwitterのDMが一番繋がりやすいです。
何かお手伝いできることがあればご連絡いただけると嬉しいです。

Ebisu.rb #26 に参加しました

ebisurb.connpass.com

Ebisu.rb はこれで5回目くらいで、前回の参加が #23 の 5月なので 半年ぶりになる。

今回は参加者の層が Rubyガチ勢と ゆるふわRuby勢と 未経験者勢 とで何となく分かれていた気がする。Rubyガチ勢とゆるふわRuby勢の境界は自分でも良くわからない。少なくとも私はゆるふわRuby勢。
そんな中で GitHub Actions について喋ったんだけど、気になる層とそうでない層が真っ二つに分かれるのは予想していたので、もう少し広い範囲で興味を持ってもらえそうな git の alias を使ったライフハックも紹介した。懇親会では GitHub Actions の話もライフハックの話もできて楽しかった。

他の方の発表も多種多様で、そうそう Ebisu.rb ってこんなだったわー、という気持ちになった。GitHub Actinos の話をしてる私が浮いていないくらいなのですごい。

個人的には、書き捨てコードの話とRspec高速化の話が刺さった。

書き捨てコードを見たり解読するのが好きだということもあるけど、書き捨てコードがあるということはプログラムで何かを解決しようとしているわけで、それがプログラマーの仕事の仕方だよねーというのを実践してる人が目の前にいることが刺激になった。そういうの最近できてないなー。VimIDE開いて愚直に手作業してた面倒な繰り返し作業も、もうちょっとスクリプト組んで効率的にできたんじゃないかと思えてやる気出てきた。

Rspec の高速化の話は、こりゃもう知ったからにはやらなきゃと思ってスライド見ながら手を動かしてたら、そもそもうちの factories たちが trait で余計な関連レコードたくさん作ってるのを整理しなきゃいけないと気付かされて、でもまあやるっきゃ無いかとふんばってる。そのやる気が出てきたのはあの LT のおかげなので、いやもーありがとうございます。

RSpecの実行時間を1/5にした話 - Speaker Deck

帰宅してからは reline の rvm の CI が落ちる問題を調べてた。目の前にバグがあったらちょっかいかけたくなるよね。
rvm がメソッド追加してる Bundler と実際に動いてる Bundler が別なので動かないというのが分かったものの、どう解決するのが適切なのか分からず寝たら、次の日に bundle exec して直してるのを見て、その発想が出なかったのがちょっと悔しかった。bundle install してるんだからそりゃそうじゃんか...。でもスッキリしたので良かった。

Fix to failed CI. by osyo-manga · Pull Request #71 · ruby/reline · GitHub

今年もアドベントカレンダー書く予定なので、文章を書くリハビリがてら久々にブログ書いた。