開発チームの振り返りタイミングのパターン

考えることがあったので雑にメモ。

1. 毎週末（木曜日or金曜日）

• 最も一般的なパターン。木曜日ないし金曜日にその1週間を振り返る。
  • 1スプリントを1weekと置いていれば毎週何らかの成果物があるはずなので、それに対する振り返りがこの時間にあたる。
• 毎週30分-1時間近くの時間を毎週ブロックすることになる。
• 振り返りで出てきたトライを翌日からすぐに始められない（土日に入ってしまう）ため、トライ実施のモチベーションに懸念が残る。
  • 週明けにトライの内容を再確認するなどの工夫で解決できる可能性がある。

2. 毎週明け（月曜日or火曜日）

• 1の問題点であったトライ実施のモチベーションが改善され、翌日からモチベーション高くトライを意識できる。
• 一方で、振り返る内容は先週のものになるためメンバの振り返りに対するモチベーションが低くなる懸念がある。
  • 振り返りに対するモチベーションの低下すごく致命的で、これが起きてしまうとそもそも振り返りの時間そのものが遊んでしまう。
  • 開発過程での課題を記録しておいてもらうなどの方法も考えられるが、基本的に人間は「忘れずになにかをやる」というのは不可能であると考えたほうがよいため、あまりまともなアイデアではない。

3. 開発アイテム終了後

• 定期での振り返りを実施しないかわりに、開発アイテム単位で振り返りを実施する。これによって毎週1時間を必ずブロックされることがなくなる。
• 少なくとも毎週定期で振り返りをするよりも凝縮されたものにはなるが、一方で開発期間が長いアイテムの場合には開発中に発生した課題を誰かが記録していないとすぐに情報が失われてしまうため、振り返りのタイミングで「なにも覚えてない」の状態になる懸念がある。
• 「振り返りをするアイテム」と「振り返りをしないアイテム」の定義も必要になる。
  • 開発メンバ全員、開発メンバ個々人、リーダー／マネージャで見えている風景が異なるため、振り返りのモチベーションに対する合意をとるコストが発生する場合もある。この意思決定をナアナアにしたり無視したりすると今度は振り返りに対するモチベーションに影響がでる。

4. 振り返りを不定期実施にする

• 朝会のタイミングで問題定期をしてもらうなど、不定期的になんらかの問題が起きたタイミングで開発プロセスに対する改善を加える。
• 一方で、集団で話しながら振り返りをするということがなくなり視点が個々人に閉じるため、振り返りの対象が近視眼的なものになる懸念がある。
• メンバーのモチベーションにもよるが「場がなければ行動を起こせない」という性質のチームであると基本的に自主的な改善は発生しない。

振り返りのROI

「振り返り」はチームの中で気づいた改善点や強みを共有しあうことで改善のサイクルを回し、より効率のよい開発を行えるようにするための重要なプロセスのひとつである。

一方で我々の時間は有限であり、週あたりの労働時間において「振り返り」が占める時間と、その「振り返り」から生まれる結果に対して、振り返りを実施する人間は気を配る必要がある。振り返りをしたからと言って必ずしもチームのアウトプットの質が改善されるわけではなし、振り返りをしなくても自律的に改善が行われるチームもある。振り返りをしなくても自動的にチームが良くなるような高ROIなチームなら、敢えて時間をとる必要もない。

そのようなチームはいわゆる自己組織化されたチームと呼ばれるものであるが、そのようなチームにおいてはルール化／フレームワーク化された仕組みはただ単に形骸化するどころか逆にチームのパフォーマンスの足かせにもなるため、注意が必要だと言える。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

shelm: 脱法Elmパッケージマネージャー

elm/core などのカーネルモジュールにバグがあるとき、公式のバグ修正を待っていられないことがある。物によってはアプリケーションの動作に大きな影響があったりして早急な修正が必要になる場合もある。

そのような場合にはshelmを使うことで、自分たちで野良フィックスを取り込んだカスタムの elm/core が使えるようになる。

github.com

原理としてはelm-git-installと近い。

Elmアプリケーションのビルド時に使用されるelm-stuff配下のデータを先に作ってしまい、キャッシュされていることにしてpackage.elm-lang.orgからダウンロードできるものと置き換えている。

使い方

例えば、カーネルモジュールであるelm/timeを自分たちでカスタムしたもので置き換えたい場合には、次のようにlocationsフィールドをelm.jsonの中に新しく作り、オーバーライドする手段を指定する。

"dependencies": {
    "direct": {
        ...
        "elm/time": "1.0.0"
    },
    "locations": {
        "elm/time": {
            "method": "github",
            "name": "IzumiSy/elm-time"
        }
    }
}

methodのセクションにはgithubだけではなくfileも指定できる。

    ...
    "locations": {
        "elm/time": {
            "method": "file",
            "name": "../my-pkg/time"
        }
    }

あとはshelmでfetchを叩くことでelm-stuff配下にローカルパッケージのキャッシュデータを作らせることができる。

$ ./shelm fetch

あとはいつもどおりelm makeすればよい。

ほかにもいくつか機能があるが、それに関してはREADMEを読むか実際のコードを読むことで理解できると思う。shelm自体は1ファイルのシンプルなシェルスクリプトであるため、とくに複雑なものでもない。

余談: shelmはなぜ脱法か

このshelmの存在は、ElmlangのSlackワークスペースで「カーネルパッケージにあるバグを一時的に治したい場合にはどうすればよいか」という質問への回答として得られたものであるが、基本的にはElmのコミュニティにおいては脱法である。

shelmのREADMEにも"Note: Best not talk about this on the offical Elm channels unless you're trolling."（Elmの公式チャンネルでshelmについて話さないこと）と書かれていることからもそれが分かる。

Elmのカーネルモジュールにはポートを使わずにJSとのデータをやりとりできる基盤が存在しているため、容易に実行時例外を発生させるコードを書くことができてしまう。しかし公式はElmのことを「実行時エラーの存在しないAltJSである」と謳っていることから、カーネルモジュールに対する機能追加には非常に慎重である。また、Elmを使う人達の体験を損なわないためにも、shelmのようなElmの概念を揺るがす存在には厳しく目を光らせている。

いずれにせよ、実行時エラーのない言語としてElmを使うのであれば、自己責任のうえでshelmの利用は如何ともし難いカーネルモジュールのバグ修正程度に留めるべきだ。

Fitbit Charge 4でSpotifyアプリ連携がインストールできない場合の対処法

Fitbit Charge 4を買った

Fitbit Charge4 GPS搭載フィットネストラッカー Black/Black L/Sサイズ [日本正規品] FB417BKBK-FRCJK

Spotify連携が利用できない

Charge 4には、Bluetoothで接続している端末と連携してSpotifyをコントロールできる機能がある。

しかし、買った直後その機能が有効にできないトラブルに遭遇した。

有効にしようとFitbitアプリからSpotifyアプリを選択しても、デバイスのバージョンが古いなどと言われSpotify連携がインストールできない。

インストールできない

解決策: アップデートを待つ

身も蓋もない解決策だが、大体24時間ほど待つと唐突に新しいアップデートが利用できるようになり、これをインストールするとSpotify連携が有効になる。

新しいアップデート

上記のファームウェアアップデートのインストールが完了すると、以下のようにめでたくSpotify連携が利用できるようになる

Spotify連携が利用できる旨が表示される

自分はCharge 4のセットアップ時に、すでにデバイスのアップデートを1度実行している。

しかし、どうやら初回時点のデバイスアップデートとは別のアップデートを受け取らないとSpotify連携を有効にすることができないらしい。

nvmやrbenvを遅延ロードさせる

nodeとかrubyとか特定のコマンドを使うときまでバージョンマネージャのローディングが遅延できたらなー思って調べてみたら、alias/unaliasを用いて遅延ロードっぽいことをやるテクニックを知った。

例えばnvmは以下のようにnodeやnpmなどのようなコマンドが呼び出されたときに初めてロードさせられる。

export NVM_DIR="$HOME/.nvm"
if [ -e "$NVM_DIR/nvm.sh" ]; then
  alias nvm='unalias nvm node npm && . "$NVM_DIR"/nvm.sh && nvm'
  alias node='unalias nvm node npm && . "$NVM_DIR"/nvm.sh && node'
  alias npm='unalias nvm node npm && . "$NVM_DIR"/nvm.sh && npm'
fi

やっていることはシンプルで、nvmが必要なコマンドにaliasを貼っておき、コマンドが必要になったときにはじめてnvmが初期化されるようになっている。

一度呼び出されたらunaliasするので、次回以降はnvmの初期化は行われない。

同じくrbenvもやれる

export PATH="$HOME/.rbenv/bin:$PATH"
if [ -e "$HOME/.rbenv" ]; then
  alias ruby='unalias ruby bundle gem && eval "$(rbenv init -)" && ruby'
  alias bundle='unalias ruby bundle gem && eval "$(rbenv init -)" && bundle'
  alias gem='unalias ruby bundle gem && eval "$(rbenv init -)" && gem'
fi

なお、元ネタは以下のツイートの記事。

Love this technique to achieve lazy loading of nvm and rbenv! They are too slow to run at terminal startup😂 https://t.co/OOBRtFF0ep

— IzumiSy™ (@sy_izumi) 2020年5月23日

Intellij IDEAのVMオプションとVSCodeの設定をイジってフリーズを減らす

去年末にお金をケチって買ったiMac 2019(Core i3 3.6 GHz, 8GB)でIntellij IDEAとVSCodeを起動していると、文字の入力もできないくらいレインボークルクルが頻発して仕事どころじゃないことがここの所よくあった。

数年前に買ったThinkCentreで動かしているUbuntuのほうがまだ快適という謎もあり「さすがにコレはどうにかしたい」という強い意思からいろいろ調べてみた。

結果、どうやらアプリケーションが使うメモリサイズが大きすぎて、GCによるストップ・ザ・ワールドが頻繁に起こっているっぽいということが分かってきた。CPUをケチったせいでGCを捌ききれず、結局8GBもメモリを積んでいても無駄になるとは悲しい...

Intellij IDEAの設定

ということで、最大メモリサイズを1Gまで減らしみると、見違えるほどフリーズ時間が減った。

あとから気がついたが、実はUbuntuで動かしていたIntellijは元から最大メモリサイズが少なめの設定になっていた。こりゃどうりでサクサクなわけだよ。

-Xms128M
-Xmx986M
-XX:+UseConcMarkSweepGC
...

なお、G1GCみたいなメモリがたくさん使えること前提のGCアルゴリズムを選択するのもたぶん良くないだろうとということで、とりあえずConcurrent Mark Sweep GCを代わりに指定しておくことにした。

VSCodeの設定

また、VSCodeもそこそこ大きいGoアプリケーションを開くとレインボークルクルの頻発につながっていて非常に鬱陶しかったので、ファイルで使う最大メモリをデフォルト4GBとなってたところ1GBまで落とした。

加えてwatcherExcludeに.gitディレクトリ配下を追加してみた。

{
    "files.maxMemoryForLargeFilesMB": 1024,

    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/node_modules/**": true
    }
}

これだけでめちゃくちゃいい感じになった。今までのストレスはなんだったのか。

メモリがたくさんあるからといって全部使えるとは限らない好例だったと思う。たくさんメモリを使うには、性能のいいCPUも必要ということが分かる。作業マシンへの投資をケチってはいけない。

ガベージコレクション

gcloudコマンドでGAEアプリケーションデプロイ時に指定できるバージョン名には使える文字種に制限がある。

gcloud app deploy コマンドを使ってGAEアプリケーションをデプロイする際には--versionというオプションを使うことでバージョン名を自分で指定できるので、ブランチ名とかIDとかをバージョンとして出したくなる。

しかし、試しにブランチ名を含めてバージョンに指定してみたら以下のエラーが出た。

May only contain lowercase letters, digits, and hyphens. 
Must begin and end with a letter or digit. Must not exceed 63 characters.

つまり、バージョン名には小文字、数字、ハイフンしか含められないとのこと。

なので、もしブランチ名をバージョンに含めようとすると fix_123 みたいなブランチ名のアプリケーションだけデプロイできないことになる。 あと、ブランチ名が長いのもNGだし、大文字が入っている場合もNG。

なので、結局コミットIDだけ含めることにした。正直もうちょっと使える文字種の制限を緩めて欲しい...

Elmのモジュール分割における区分軸の観点

Elmアプリケーションにおいてモジュールを作る際に、モジュールへ機能をどう凝集させるかに関して。

機能による区分

かつてElmにおいて一般的だった分割方針。グレーの部分がひとつのモジュールを表している。

ModelとUpdate, Viewなどをすべて別のモジュールへ分割し、Userなどのネームスペース配下に配置する形で、Railsなどのフルスタックフレームワークのディレクトリ分けと非常に近い。

機能による区分

この分割方針の大きな欠点は、モジュールを不必要な単位で分けすぎていることで結局すべてのデータをモジュールから公開しなければならなくなっている点にある。

ViewモジュールやUpdateモジュールは、実装のためにModelモジュールの内部実装を知る必要がある。その結果、公開された内部実装へ知る必要のない他のモジュールが依存する可能性がでてしまう。

Elmにおいてモジュールを作る理由というのは公開したいものと公開したくないものを分けることであり、他モジュールからの依存をコントロールし変更に強い「インターフェースに対する依存」を生み出すこと。Opaque Typeのような手法も、まさにこれが理由になる。

モジュールの分け方が不適切な単位で小さすぎると、実装のためにモジュール内部をすべてexposingしないといけなくなってしまいモジュールの機能が存在意義を失ってしまう。このような「機能による区分」が持つ問題への反省を踏まえて、現在のElmにおいては以下の「ドメインによる区分」の方針でモジュール分割が行われる。

ドメインによる区分

「機能による区分」で行われていた分割とは異なり、モジュールはUser, Article, Commentのようなアプリケーションにおけるドメインの単位のみで作られる。

最も卑近な例では、リチャード・フェルドマンによるrtfeldman/elm-spa-exampleがモジュール分割にこの区分を採用している。

ドメインによる区分

このモジュール分割が行われるのは、例えば「画面」がそうである。Elmアプリケーションにおいて、User画面、Article画面、Comment画面はそれぞれがひとつづつモジュール化される。

画面をモジュール化する理由は、画面を利用するMainなどのモジュールは各画面の実装詳細を知る必要がないからだ。これらのモジュールを利用するMainモジュールは、各画面モジュールが提供する関数を用いてモデルの更新をしたりHTMLを作ればよいだけであり、画面モジュール内部の実装詳細を知る必要はない。以上の理由から、画面単位のモジュールが作られる。

このような単位でモジュールを作ることで、「機能による区分」では過剰に公開されていたModelやUpdateの詳細が外部から適切にカプセル化され、意図しない依存が生まれにくい状態になっている。

余談: 共通化によって生まれる孤児モジュール

プログラミングをしている人間であればおなじみのDRY（共通化）は一般的には「機能による区分」で行われる事が多く、上記の「ドメインによる区分」の軸とはモジュールの設計の観点で直行することになる。

例えば「すべての画面モジュールにおいて"View"や"Update"の軸で共通化した実装を用意したい」などのケースがこれに当たる。

このような区分軸の直行が起こるケースでは、各ドメインを横断して仕様の分析を行い、その共通化が単なる「コード上の共通化」なのかそれとも「概念としての抽象化」なのかを見極める必要が出てくる。

しかしながら、実際の事実としてもっとも起きがちなのは、このようなタイミングでcommonやutil, helperなどの「どこにも属さない概念」が爆誕することである。彼らはコードとしては共通化されたが、概念上の所属の観点からは考えることを放棄された孤児モジュールである。

彼ら孤児モジュールは、ある意味「所属待ち」を行っている状態でもあるため、継続的にリファクタリングなどのタイミングでどこかのドメインに所属させたり、新しい抽象概念に昇格させたりしていくことが必要である。孤児モジュールがコードベースにおけるマジョリティーになってしまうと、アプリケーションにおけるドメインの概念が揺らいでしまう。

rbenvの初期化が遅いのをどうにかする

rbenvの初期化がすげー遅いときがある

eval "$(rbenv init -)"

探してみると、ちょっと昔の記事だけどこんなのが出てきた。

mattgreensmith.net

つまりrehashとかいうのが遅いらしいので、それをbackgroundで処理させるといい感じになるらしい。こんな感じで。

eval "$(rbenv init --no-rehash -)"
(rbenv rehash &) 2> /dev/null

たしかに体感早くなったような気がする。