github actions のビルドキャッシュ運用

2021-12-04 (Sat.)
#life  #github 

目次

23時に寝て5時に起きてちょっと作業してまた寝て7時に起きた。お仕事も働き始めて1ヶ月が経過して、だいぶチームの雰囲気や業務に慣れてきたところ。稼働日の18日間で作成した pr が16件。入ったときに割当てられた3つの課題から10数件の issue を派生させてちょうどすべて fix した。来週から新しい課題に取り組む。

ストレッチ

今週もお仕事に注力してたらストレッチは2日/週とあまりできなかった。ウォーキングもやってない。今日の開脚幅は開始前165cmで、ストレッチ後167cmだった。さぼってたせいか、数値が悪くなってしまった。右股関節の関節の可動域がよくないところは少しずつまがるようになってきてよくなってきている実感がある。一方で右太ももの後ろの筋が張りが大きいことに気付いた。トレーナーさんに聞くと、この筋は椅子に座っていると張りやすいという話しなので、最近はお仕事に注力して椅子に座っている時間が以前より伸びているせいだと思う。あと会議に出席している時間も増えているため、その時間は椅子に座っておかないといけないという制約も増えている。

actions/cache の exclude 設定

github actions でビルドキャッシュを扱う方法は Caching dependencies to speed up workflows に書いてあって、それは actions/cache という github actions がキャッシュ機能を提供している。ここでドキュメントにはキャッシュの除外設定については何も書かれていないが、リポジトリに含まれる examples.md には次のような説明と設定例が出てくる。

Depending on the environment, huge packages might be pre-installed in the global cache folder. With actions/cache@v2 you can now exclude unwanted packages with exclude pattern

https://github.com/actions/cache/blob/main/examples.md#c---nuget

- uses: actions/cache@v2
  with:
    path: |
      ~/.nuget/packages
      !~/.nuget/packages/unwanted      
    key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
    restore-keys: |
      ${{ runner.os }}-nuget-

! を入れるだけかと思って検証してみたらどうも意図した振る舞いにならない。実はこの設定はバグっていて実際には動かない。なぜ動かないかを追いかけてないけど、issue にも登録されている。path の記述方法によって動いたり動かなかったりするというのが現状の振る舞いになるらしい。

ちなみに正しい動く設定は次になる。ワイルドカードを使わないといけないらしい。ドキュメントに除外設定について書いていないのはバグってて中途半端な振る舞いをしているからかもしれない。

- uses: actions/cache@v2
  with:
    path: |
      ~/.nuget/packages/*
      !~/.nuget/packages/unwanted      
    key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
    restore-keys: |
      ${{ runner.os }}-nuget-

あとビルドキャッシュのキーにパッケージ管理のファイルのハッシュ値を取るようになっている。この背景も github actions がキャッシュをクリアする機能を提供していないからであろう。Clear cache #2 でも議論されているが、キャッシュをクリアできないため、同じキーにパッケージが溜まり続けるような運用は開発者にとっても github 社にとってもリソースを浪費するので好ましくない。いまは7日以上アクセスされていないキャッシュを削除する運用になっているため、なるべくフレッシュなキャッシュが生成されるような運用となるよう、ハッシュ値を取得するようなキーの運用が行われているように推測される。

チームごっこ

2021-12-03 (Fri.)
#morning activity  #book 

目次

0時に寝て6時に起きた。

朝活: アジャイル開発とスクラム 第2版

第7章の残りと第8章を読んだ。事例紹介なので軽く読み流した感じ。インタビュー記事のタイトルが気になった。

「合宿で、「仕事での同僚」から「チームの仲間」になれました

このタイトルと内容に私は違和感があるので反論としてそれを書いていく。

心理的安全性のつくりかた に書いてあったが、MIT のオスターマン教授によると、チームという概念は比較的新しいものらしい。

職場における、チームという概念は1980年以降、最も広まったイノベーションのひとつだ。

「心理的安全性のつくりかた」ではチームとグループの違いは次になる。

  • チームは共通の目標に向かってともに問題解決やアイディアを出す集団
  • グループはそうなっていない、ただの寄せ集めの集団

共通の目標に対して互いに対話や協働することでチームになっていく。この考え方は私の経験則とも合致するし支持している。実際の業務や作業を通してチームは築かれていくと私は考える。しかし、コミュニケーションの活性化や親睦を深めればチームになると誤解している人もいるように思う。

件のインタビュー記事では、次の内容があった。

合宿の最大の成果は、何だったのでしょう？

「仕事での同僚」から「チームの仲間」になれたことだと思います。昨今、ハラスメントやプライバシーの観点からなかなか個人の深い話ができないことが多いと思いますが、お互いを信頼した上で自分の生い立ちや経験から「私がなぜここにいるのか」を深掘りできたことが大きいと思います。

具体的には、誰とも話さず、自分を見つめる時間として三浦海岸の浜辺に全員を１時間放置しました（笑）。その時間で自分の今までをふりかえり、再集合したときに１人ずつ語り、お互いのことを尊重し受け入れることで心理的安全性が一気に高まったと思います。

私だったら転職を考えますね。浜辺に放置されて再集合して生い立ちとか語れとか言われて、そんな上司だと懸念を抱くと思う。その場で抗議はしなかったとしても。仕事を通して結果的に信頼関係が深くなって、同じ行動をするなら理解できるが、そうじゃない状態で職位の高い人がメンバーに合宿を半強制参加させてプライベートの内容を話させるのはハラスメントと紙一重かもしれない。おそらくこれはたまたまうまくいったケースだというだけで再現性のあるプラクティスにはまったく思えない。厳しい言い方をすると、偉い人の自己満足によるチームごっこではないかと思う。

本番リリース作業

今日は非稼働日なんだけど、インフラ周りの修正をしていたので本番リリースの作業を見守っていた。ハドルで画面共有しながらみんなでわいわいできるので、これはこれでリリース作業の雰囲気を学ぶ機会にもなる。私が本番リリースすることはないだろうけど、担当者がどういった作業でリリースしているかを知っておく方が運用に役に立つ仕組みも導入できるかもしれない。音声通話と画面共有さえあればフルリモートワークでもなにも困ることはない。よい世の中になったと思う。RabbitMQ と Dapr 周りで私が懸念に思っていたことを本番リリースを通して検証したり振る舞いを観察できたので新たな知見を得た。

スクラムイベントにもの思い

2021-12-02 (Thu.)
#scrum 

目次

23時に寝て6時半に起きた。昨日は疲労困憊だったのでなんもせずすぐ寝た。

スクラムイベント

お仕事のスクラム開発で木曜日はスプリントレビューとプロダクトバックログリファインメントを行う。主にステークホルダーとプロジェクトオーナーがプロダクトバックログアイテムの優先度を議論したり、タスクに細分化されていない課題をタスクにしていくための作業に当てたりしている。本当はタスク化されたイシューをさらにリファイメントするイベントなのだろうだけど、まだそこまで業務やチームの体制が成熟していないため、タスクの細分化のための時間になっていたりしている。

これらのイベントで開発者がイニシアティブをとることはないけど、プロダクトオーナーやその業務チームにいるメンバーたちがどうやって業務をタスク化しているかのやり取りもみえたりする。開発者にとってそのやり取りをみていることに意味があるかどうかはまだ私にはわからないが、業務チームのメンバーがどういった働き方をしているかを知るきっかけにはなる。業務チームは miro を使ってメンバーみんなで同時編集しながら課題を付箋代わりのメモに落としていく。その個々のメモがタスクに近いものになるのだろうけど、私からみたら業務すべてを知っている人がまとめて細分化してドキュメントに書き記して2-3回みんなでレビューすれば終わるようなものを、みんなで付箋紙に書いていって整合性が取れているのかどうかわからないメモの固まりを作っているようにみえる。この作業はみんなでやらないと進捗しないので1週間に1回とかになる。

  • チームが扱うすべての業務を知っているメンバーはいない
  • 業務に必要な機能の優先順位や優先度を決める権限をもっていない
  • 情報が足りないと思ったときにメンバーが自律的に動いて補う体制が整っていない

あとステークホルダーが話す要件や仕様に関わってくる話の大半が口頭で行われていてドキュメントや課題管理に文章として書き記されていない。だから同じ話しを何度も繰り返し聞くようなケースも発生する。わからないことを聞くことも、繰り返し聞くことも問題ではないが、議事録以外にそこで話す内容がドキュメント化されないのはどうしてだろう？という気もした。もっともっと文章を書かないと情報共有やノウハウをためることにはつながっていかないだろうということも垣間みえる。

総括すれば、どんな開発方法論を使っても、リーダーやマネージャークラスが圧倒的に文章を書けないと、その配下のメンバーは自律的に行動できないというだけの話しでしかないが、どうやったら解消できるか？はまだまだこれからの私の課題でもある。

師走入り

2021-12-01 (Wed.)
#morning activity  #dapr  #bizpy 

目次

1時から1時間ほど仮眠をとって2時から4時過ぎまで作業して帰ってお風呂に入ってそのまま6時から 【三宮.dev オンライン】リモート朝活もくもく会 の朝活に参加した。30分ほど雑談して眠くなって7時過ぎから9時前まで寝てた。

dapr の pubsub の dead letter サポート

お仕事で dapr を触っている。pubsub で dead letter queue の仕組みを導入しようとしているが、PubSub’s DeadLetter Topic #2217 によると v1.6 (2022年1月20日リリース予定) のマイルストーンになっている。本当にその予定ならそろそろベータ版が実装されていて、開発ブランチあったらテストしようかと考えていた。調べてたら rabbitmq はすでに v1.5 で dead letter のサポートがマージされているのを発見した。

たまたま、いま使っている pubsub も rabbitmq だった。ドキュメントをみたら確かにその設定が追加されている。

dapr RabbitMQ

FieldRequiredDetailsExample
enableDeadLetterNEnable forwarding Messages that cannot be handled to a dead-letter topic. Defaults to “false”“true”, “false”
maxLenNThe maximum number of messages of a queue and its dead letter queue (if dead letter enabled). If both maxLen and maxLenBytes are set then both will apply; whichever limit is hit first will be enforced. Defaults to no limit.“1000”
maxLenBytesNMaximum length in bytes of a queue and its dead letter queue (if dead letter enabled). If both maxLen and maxLenBytes are set then both will apply; whichever limit is hit first will be enforced. Defaults to no limit.“1048576”

enableDeadLetter=true に設定して、適当にエラーが発生しそうなリクエストを作って dead letter にメッセージが入るかどうかを検証してた。ひとまず dead letter にメッセージが入ること自体は確認できた。

bizpy 勉強会

Python で Slack のインテグレーションをやってみる勉強会 #3 を開催した。月曜日から2時間もあればできる資料作成をだらだら先送りしていて夜中に作った。なんか体調を崩しているのかもしれない。たまたま勉強会の前にせらさんから激励のコメントをいただいて嬉しかった。

今日の分も含めコンテンツ拝見しましたが、素晴らしいですね

私見だけど、slack インテグレーションで調べものをしているとせらさんの記事や issue のやり取りをみかけることが多い。twitter で slack インテグレーションに関してつぶやくと100%せらさんからレスポンスがある (個人の経験談) 。過去に私は外資の ISV で働きたいと思って活動したこともあったけど、せらさんをみていて自分のレベルでは無理だったなと得心がいった。なにがすごいって、bizpy の勉強会のようなところにもわざわざやってきて、講師にコメントしたりアドバイスしてくれるんだからね。

2ヶ月に渡り、slack インテグレーションのチュートリアルレベルの記事を実際に設定してみて、サンプルコード書いてみて、動かしてみて、slack でどんなことができそうかの理解を深めることができた。今回の内容はビジネスパーソン向けではなかったのでちょっと敷居が高かったかもしれないが、全3回でやり切ることができてよかった。終わってから運営に新たにわたなべさんが加わったことを参加者に紹介しつつ、次回の企画について雑談していた。次回はわたなべさんから機械学習入門のような勉強会をしてもらうことに決まった。

66日目

2021-11-30 (Tue.)
#life  #writing 

目次

23時に寝て3時過ぎに起きて作業しようと思ったものの、やっぱりそのまま寝てしまって7時に起きた。前々日にあまり寝てなかったせいか、睡眠不足を解消したとポジティブに考えとく。

習慣化のための平均66日

前に GIG MINDSET ギグ・マインドセット を読んだときにロンドン大学が行った研究で習慣になるには平均して66日かかるというのをみかけた。「平均して」というのが曖昧なところで、直観的に理解できるけど、対象の難易度によって習慣化に要する日数が異なる。簡単なことはすぐ習慣化できるし、難しいことには時間がかかる。それらをいくつも試してみて平均したら66日だったという話し。66日仮説 でも言及されているようにこの手の研究はあまり鵜呑みにするのもよくない。とはいえ、何らかの基準や目安があること自体は悪いことではないので一般論として参考にするのはよいと私は考えている。日記を書くというのは比較的簡単なことだと私は捉えるが、66日続いたので習慣と化したとみなしていいだろう。

書くこと

日記に関連して「書くこと」そのものを研究対象としている。自分でも日記を書き続けて何が起こるのかを理解するために実践しているという意図もある。

日記だけではなく、私は業務の過程で普通の開発者より、平均的な文章量よりも大量に書く。課題管理システムに私以上にコメントを書く開発者を、この10年で1人もみたことがない。私以上に課題管理システムを使いこなす開発者もこの10年みたことがない。課題管理システムの使い方や応用をメンバーにアドバイスするし、メンバーも私の使い方をみて真似してくれることもあった。これまでそういった行動は無意識にやっていたことだけど、それを意識化して形式知として体系化したいという狙いもある。

書くことは メタ認知を活用して学びのスキルを磨く 手法の1つとして優れていると私は考えている。これを開発者にとって日常的な課題管理 (システム) に取り入れられないかというのが、私の持論であり今後の研究課題である。たまたま、はらさんとそういった話題で話す機会があり、共感してもらえて嬉しかった。

辞めるときの余裕

2021-11-29 (Mon.)
#career  #event 

目次

2時半に寝て6時半に起きた。なぜか眠れなくて鬼滅の刃をみてた。本当は夜に bizpy の資料作りをしようと思っていたけど、前日にあまり寝てなかったせいかバテてそのまま寝てしまった。

お仕事の辞め方

たまたまお手伝いしているところである開発メンバーが今月いっぱいで辞めますという連絡があった。その方は今日お休みだったので明日で辞めますみたいな急な連絡となった。もちろん上司や関係者には前々から話しは伝わっていて、引き止めや調整をしていたのだろうけど、チームとして働くにおいてメンバーはショックを受けるというか驚くというのが普通の感覚だろう。私も少なからず組織を退職してきた。私の場合、有給休暇が余っていたので辞めると言い出すのは実際に辞める3ヶ月ぐらい前で、有給消化が1ヶ月、引き継ぎに1ヶ月、引き止めや調整に2週間、2週間ぐらいはバッファみたいな感じで辞めてきた気がする。組織の規模によるけど、大きい組織は順番に引き止めの打ち合わせがくるので時間がかかる。組織にもよるけど、私の場合は3-4ぐらい、上長、課長、部長、その上の偉い人みたいな感じか。少なくともメンバーが退職を知ってから1ヶ月以内に辞めるということはない。私は過程の記録が課題管理システムに残っているし、ドキュメントも普段からそこそこ書く方なので辞めるときにドタバタすることはほぼない。ドキュメントなくても課題管理システムにやったことはすべて残ってますからと説明できる。上長からも引き継ぎに困るという心配をされたこともない。

辞め方というのはその人の信義を表すように私は思っていて、どういう背景や事情があるにしろ、ひどい辞め方をするのは本人にとって百害あって一利なしだと思う。余裕のない辞め方というのはあまり推奨しない。

忘年会

【初参加大歓迎】三宮.dev＆bizpy 合同忘年会 の日程を12月10日に決定した。オミクロン株の不安などが出てきたところだけど、水際対策をがんばっているのでまだ大丈夫かなといましかできない飲み会をこのまま行うことにする。言うても参加してくれるメンバーは限定的なのでいつも人たちで労をねぎらうみたいな飲み会になりそう。

slack ペイロードの response_url にはまった

2021-11-28 (Sun.)
#bizpy 

目次

1時に寝て8時に起きた。昨日は喋り倒して疲れてよく眠れた。午前中は溜まった日記を書き殴って、お仕事でやっているカスタム github actions で気になったコードを修正して、午後から bizpy の勉強会の準備を始めた。なんか気乗りせずにだらだらやって最終的には出来上がった。たいていだらだらやるときは頭の中ではもう出来上がってて集中したら2-3時間でできるのを脳が把握していて、まだ時間に余裕があるから怠けるみたいなときがある。そういうときは作業やめて散歩に出掛けるようにしている。

bizpy 勉強会の資料作り

次の Python で Slack のインテグレーションをやってみる勉強会 #3 のサンプルコードの実装をしていた。内容はだいたい次の通り。あとは資料をまとめるだけ。

  • slash command の設定と実装
  • ephemeral メッセージ (本人だけみえるメッセージ) の実装
  • block kit でモーダルダイアログに入力した情報を使ってチャットに書き込む

たまたまモーダルダイアログを取り上げただけなんだけど、モーダルダイアログを submit したときにチャットに書き込むのは、そのままではできなくて、なんらかの特別な処理が必要になって、そこにはまってた。response_url の扱いはわりとややこしいみたい。

まる一日喋り続けた日

2021-11-27 (Sat.)
#life  #event  #writing 

目次

0時に寝て6時半に起きた。

ストレッチ

先週に引き続き、今週もお仕事でバテてストレッチは2日/週とあまりできなかった。ウォーキングもほとんどできなかった。とはいえ、先週の土日に観光案内でいつもよりかなり歩いたのでその休息と考えればそれほど悲観的にならなくてもよいかもしれない。ウォーキングしなかった背景は寒くなってきて21時頃に帰ってきて、また外に出掛けるのが億劫になってしまった。お仕事を早めに切り上げて早めに帰って来た方がよいかもしれない。

今日の開脚幅は開始前168cmで、ストレッチ後170.5cmだった。また170cmを超えるようになったのでよいサイクルに入ってきた。2週間に渡った中殿筋の張りはおさまった気がする。代わりに腰の筋肉に張りがあって、トレーナーさんも念入りにそこをストレッチしてくれた。生活していると、そのときどきで調子の悪い箇所は移動していて、ストレッチするとそのことに気付くので体調管理を意識する意図でもストレッチは役に立っている。

もくもく会

【三宮.dev】もくもく会 に参加した。今回はオフラインのもくもく会だった。私は bizpy の勉強会の資料作成の準備をしていた。ここ数回は主催者と私の2人だけしかオフラインに来ないといったことが多かったのだけど、今回は8人も参加していて、その8人中5人が勉強会コミュニティに主催者だったりしてちょっとおもしろかった。

コミュニティの主催者は、コミュニティ運営の苦労がわかるから他のコミュニティのよき参加者になり得る。私は 三宮.dev の運営には関わっていないが、コミュニティを盛り上げることに寄与する振る舞いはしていて、それは自分のコミュニティでもこういったやり取りが増えるといいなという願望を他のコミュニティで参加者としてやっていたりする。今回のオフラインの参加者が多かったのも、他の勉強会コミュニティでもオフラインでやりたいよねと思う人たちが集ったのではないかとか考えたりしていた。

ぷち飲み会

終わってからわたなべさんと立ち飲みに行ってきた。最近あまり行ってない はんなりPythonの会 の勉強会で (オンラインで) なんどか話したことがある方で、ずっと京都に住んでいると思っていた方がめっちゃご近所さんだった。わたなべさんは私より1つ学年が上で、世代における価値観に共感するところは多く、自身もマイクロ法人を営んでいた。研究者としてキャリアを積み重ねてこられて昨年、独立したようだ。はんなりPythonの会の運営にも最近入ったそうで、ついでというわけではないが、話していて気が合うなと思ったので bizpy の運営に入ってくれません？と尋ねたら快く了承してくれた。

bizpy の最大の懸念は運営が私1人で、私がお仕事で忙しくなったら休業してしまうという問題があった。なかなか勉強会のコミュニティの運営をできそうなメンバー (スキル、価値観、時間的余裕) をみつけるのは難しいので了承してくれてとても嬉しかった。わたなべさんは博士で研究者のキャリアをもっていて、いまは機械学習などに取り組んでいるのかな？私のキャリアとは全く重なりがないのでお互いに学ぶところがあってよい関係を築けるのではないかと思う。ビジネスパーソン向け機械学習入門みたいな勉強会をしてもよいと思う。

リーンキャンバスレビュー (後半)

前回 の続き。残りの半分を進めるのかなと考えていたけど、前回のおさらいから始めて、私の意図するプロダクトの価値やサービスの特徴の話しをしていたら、このサービスはすぐに顧客に価値が伝わるものでもなければ、急成長するようなビジネスでもないということが伝わって、リーンキャンバスをやる意味はあまりないねという話しで後半戦をやらずに終わったw。どうも新規事業=急成長やスケールするビジネスという考えでリーンキャンバスを持ち出したところがあって、私は最初からそんなことは一言も言ってないし、私が作った資料にもそういった懸念や展望は書いてあったんだけど、リーンキャンバスを通して話しているうちにその意図を理解してもらえたといった様子だった。

そういう意味でリーンキャンバスは急成長やスケールするビジネスを取り扱うときに投資家や顧客にわかりやすく訴求するためのフレームワークと言えるのかもしれない。仮にビジネスがうまくいったとしても、合同会社は投資を受けるのが難しいのでそのときは株式会社を別途作ってやるのかなぁみたいな、取らぬ狸の皮算用みたいな話も知った。

朝から晩まで多忙な一日

2021-11-26 (Fri.)
#morning activity  #book  #github 

目次

0時に寝て5時に起きた。昨日 slack で質問していた内容に5時頃に返信があるのをたまたまみかけた。この時間に起きているんだと思って返信にコメントしてたら別のメンバーからもコメントが書き込まれて、早起きは三文の得みたいな感じで朝5時から slack でやり取りしてた。いま私はだいたい8時から始業している。開発チームの半分ぐらいのメンバーはそのぐらいから始業しているのが課題管理システムや git のコミットログからわかる。このチームは朝早い人たちが多いなと感心した。

朝活: アジャイル開発とスクラム 第2版

2021-11-26 AM 6 金曜朝6時開催のもくもく会 で第6章と第7章を読んだ。第2部は企業において実際にスクラムを導入していったときの四方山話が出てくる。私はあまり他社の事例に興味はないが、対談の過程で本質的に大事なことや難しいことなどがあぶり出されることもあるので、実務を通しての話題も参考になる場合があることは理解できる。大半の事例は実業務で使われているという結論がわかるだけでも十分だと思う。とくに大企業は様々な厳しい制約や要件の中で採用していると推測されるので、それだけで大きなメッセージをもつ。斜め読みでざっと読み進めながら興味のある話題があれば精読するといった程度で読んでた。

大企業あるあるな話しでスクラムイベントを通してお互いの距離感が縮まってうまくいったといった内容があった。開発者からすると距離感の遠近に関係なく、必要なら適切な相手を探し出してコミュニケーションを取るのが普通だけど、みんながみんなそうではないだろうし、(同じ会社の社員でも)よく知らない人とは話さないといった考え方をもつ人もいるだろう。ある人はこれを単純接触効果で説明していたけど、業務ではなく人間の側面からみてスクラムイベントが多いことにも意義があるのかもしれない。

顧問さんと雑談

隔週で打ち合わせをしている。最近はお手伝いのお仕事が忙しいので今回は雑談になってしまったが、近況としてリーンキャンバス、スクラム実践の話題などを話していた。わりと盛り上がって1時間で切り上げるつもりが1時間半に伸びてしまって、別のお仕事の時間を圧迫したけど、それはそれで意義のある雑談になったので収穫はあった。

ある組織で新規事業を行う上で AARRR (あー) モデル をすごく重視しているといった話題が出た。バケツみたいなイメージがあって、そこに現実の数字を当てはめていってプロジェクト/プロダクトの改善やふりかえりなどに活かしているという。サービスのグロースに責任をもつ人には重要な概念だという。うちのプロダクトはグロースしなくてもよいけど、なんらかのフレームワークに当てはめて抜け・漏れがないかをチェックすることにも使えるかもしれない。世の中でよく使われているフレームワークを調査しておいて損はないと思う。私はビジネスに全く疎いのでリーンキャンバスを通じて、AARRR モデルの話題になって、それがどういった用途で使われているかというお話しは興味深かった。

具体的には AARRR モデルの他に、スクラムの話題からは野中郁次郎氏のオリジナルの論文、大規模アジャイルの方法論などが盛り上がっていくつかキーワードが出た。そういった雑談の中で感性に従って気になったことを深堀りしていくとおもしろい調査や知見になったりすることを経験的に実感しつつある。今後もそういう機会や内容を大事にしていきたい。

カスタム GitHub Actions の開発

先日 調査していたものをベースに、普通にやる方法と カスタム GitHub Actions の compoiste action で実装する場合の検討資料などを作って、カスタム GitHub Actions を実装してよいといった許可をもらった。企業における唯一の懸念は (原則) public リポジトリで運用するところで、CI のような処理に社外秘は含まれないが、public そのものに審査や承認を必要とするような組織では腰が重くなるようなこともあるかもしれない。ロードマップにも private リポジトリでカスタム GitHub Actoins を動かせるようにしようという課題は作成されている。

コーディングスタイルの共通化

2021-11-25 (Thu.)
#java  #ide 

目次

1時半に寝て6時に起きた

ソースコードのフォーマッター

go 言語の gofmt が成功をおさめたことからどんなプログラミング言語でもコーディングスタイルはツールで自動整形するのがよいという雰囲気が醸成され、とくに業務の開発においては統一すべしというルールを設けている組織が多いと思う。java はこの領域では後塵を拝していると言ってよいと思う。歴史的に java の言語仕様と ide は相性がよかったため、ide がコーディングスタイルを自動整形していた結果、ide ごとに互換性のない異なるコーディングスタイルが使われるようになってしまった。私がアリエルで開発していた頃、開発者はみんな eclipse しか使ってなかったので問題にならなかった。しかし、いまや私が知っている ide だけでも次のものがある。

この問題を解決するツールとして最もメジャーなのは google-java-format で、当初はこのツールを導入しようと考えていた。しかし、開発チームのテックリードから google-java-format のコーディングスタイルはひどい、一番優れているのは intellij idea だというお気持ちを表明された。導入を止めろと言われたわけではないが、チームに入ったばかりの私はテックリードのお気持ちに忖度して google-java-format の導入を断念した。代わりに intellij idea のデフォルトフォーマットをどうやって他の ide を共有するかを調べたところ、Manage code style on a directory level with EditorConfig で EditorConfig の設定 (.editorconfig) を intellij idea で再利用できることがわかった。

うちの開発チームのメンバーは intellij idea と vscode しか使っていないため、現状はこれで解決できるように思えた。intellij idea にはデフォルトで EditorConfig プラグインがバンドルされていて有効になっている。リポジトリのルートディレクトリに .editorconfig があれば自動的にそれを読み込んでくれる。そこで intellij idea のデフォルト設定を .editorconfig 形式でエクスポートして、それをリポジトリのルートディレクトリに配置することでコーディングスタイルのフォーマッターを共通化できた。

eLTAX 触ってみた

2021-11-24 (Wed.)
#scrum  #tax  #eltax 

目次

0時半に寝て6時半に起きた。水曜日は朝活の日だったけど、申し込み忘れてカレンダーに入ってなかったから忘れてた。カレンダーの予定に従って生活していることがわかる。

ふりかえり

今日はお仕事でスクラムイベントのレトロスペクティブがあった。最近は日本語でそのまま「ふりかえり」と呼ぶみたいやね。他の用語が英語なのであわせて英語で読んでたけど、ふりかえりの方が日本人的にはしっくりくるのでそれでいいと思う。

開発の情報共有のやり取りが活発になったという意見が出た。私は11月から働き始めてまだ3週間ほどなので以前がどうだったのかわからない。2週間前に本格的にスクラム開発に移行して、POや開発者のリーダーが新任したり、開発者に新規メンバー (私のこと) が追加したりと、いろんな状況が変わっている。なにか特別なことをしたというわけではないけど、自然にコミュニケーションがよい方に改善されているなら全体としてよい傾向に思える。私はまだ業務のことが全くわからないのでインフラやテストなどの非機能要件のタスクをやっているだけ。開発者からみて負債というほど大きなものではないが、やった方がよい技術的な残タスクのようなものを私がどんどん fix しているので開発環境がよくなっている気がするといったコメントを名指しでいただいた。スクラムマスターによると、ふりかえりでは、個人名で問題を指摘するのはよくないが、個人名で感謝を伝えるのはよいという。なので、よいことには個人名が前面に出る。褒められて悪い気がする人はそうそういないので、このプラクティスはチームの雰囲気をよくすることに寄与するのだろうと思えた。

続: 年末調整と住民税の納付

昨日 の続き。eLTAX のソフト版をダウンロードして年末調整の給与支払報告書の申請、住民税の特別徴収の納付も行った。アプリケーションの操作方法と手続きのドキュメントは懇切丁寧な内容なので、アプリケーションそのものの使い勝手はいまいちだけど、とくに手続きに迷うこともなく、順番に操作していけば問題なく申請や納付を完了できた。この2つの手続きは、昨年は紙で申請したり納付したりしていたのが、今年は電子申告になったのでちょっとクラスチェンジしたような感覚で気分がよかった。定期的な行政手続きを毎年やりながら少しずつやり方を洗練させていったり、異なる手続きに挑戦してみたり、制度の仕組みを理解したり、そういう少しずつ改善して学びを深めていくことそのものに幸せ感がある。人に依るんだろうけど、わりと私はマイクロ法人の行政手続きを楽しんでいる。