いつも忘れるのでメモ
poetry add --group dev flake8 isort black flake8-bugbear flake8-docstrings mypy
setup.cfg はこんな感じに
[flake8] max-line-length = 88 convention = google [mypy] ignore_missing_imports = true show_error_codes = true [isort] include_trailing_comma = true line_length = 88 multi_line_output = 3
Poetry projectをVSCodeで開く場合，project rootに .venv が生成されないので依存ライブラリのコードへの参照をVSCode上で解決できないケースがある．使用しているvirtualenvのpathを手動で指定する必要があるが，毎回やるのは面倒くさい．かといって，機械学習だと3rd party libraryを大量に参照するので直接Code jumpできないとめんどくさいケースが多々ある．
そこで，以下の設定を入れておくことでpoetryはvirtualenvをprojectのroot directory直下の .venv というdirectoryに生成するようになり，この問題を解決できる．
poetry config virtualenvs.in-project true
なお，すでにvirtualenvを作っている場合は適用されないのでその場合はvirtualenvを作り直す必要がある（当たり前だけど）．
参照: Configuration | Documentation | Poetry - Python dependency management and packaging made easy
何番煎じだって話だが備忘録として残しておく．
WSLでLinux環境を作ると，デフォルトではWindowsがインストールされているドライブ上にLinuxのファイル本体が配置されてしまう．別 のドライブにLinuxのファイルを配置したい場合は，一度Windowsがインストールされているドライブ上にLinuxをインストールした後に，ファイル一式をexportして任意の場所にimportする必要がある．めんどくさいね．
Windows 11で動作確認をした．
Windows 10でもWSL自体は動作するのだが，Windows 10の場合WSLのバージョンが古くなってしまうらしく，これが原因で，WSLで構築したUbuntu環境上で nvidia-smi でGPUが確認できない問題が発生した．NVIDIAのサイト によれば，CUDA on WSLにはWSL2が必要で，WSL2はWindows 11以降でのサポートになるとのことだったのでWindows 11にアップデートしてから本記事に書いた手順を実行した．
> wsl --version WSL バージョン: 1.1.3.0 カーネル バージョン: 5.15.90.1 WSLg バージョン: 1.0.49 MSRDC バージョン: 1.2.3770 Direct3D バージョン: 1.608.2-61064218 DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windowsバージョン: 10.0.22621.1413
> wsl --list --online インストールできる有効なディストリビューションの一覧を次に示します。 'wsl.exe --install <Distro>' を使用してインストールします。 NAME FRIENDLY NAME Ubuntu Ubuntu Debian Debian GNU/Linux kali-linux Kali Linux Rolling Ubuntu-18.04 Ubuntu 18.04 LTS Ubuntu-20.04 Ubuntu 20.04 LTS Ubuntu-22.04 Ubuntu 22.04 LTS OracleLinux_8_5 Oracle Linux 8.5 OracleLinux_7_9 Oracle Linux 7.9 SUSE-Linux-Enterprise-Server-15-SP4 SUSE Linux Enterprise Server 15 SP4 openSUSE-Leap-15.4 openSUSE Leap 15.4 openSUSE-Tumbleweed openSUSE Tumbleweed
ここでは Ubuntu-22.04 をinstallする．
> wsl --install -d Ubuntu-22.04
> wsl -l -v NAME STATE VERSION * Ubuntu-22.04 Stopped 2
> wsl uname -r 5.15.90.1-microsoft-standard-WSL2
> wsl --export Ubuntu-22.04 {file_name}.tar
> wsl --unregister Ubuntu-22.04
> wsl --import {distro_name} {import_path} {file_name}.tar
何故かimportするとログインユーザが root に変更される．これが嫌な場合はログインユーザを変更する．
Ubuntu-22.04上で以下のように /etc/wsl.con ファイルを作成して何度かログインし直すと変更される． wsl --shutdown してもすぐには反映されず，一定時間待つ必要があるようだった．謎．
cat << EOF > /etc/wsl.conf [user] default=user-name EOF
３ヶ月ぶりの労働を再開して一ヶ月が経った．最初こそ披露困憊で業務後は何もできなくなっていたものの，徐々に勘を取り戻してきたので余裕が出てきた．
同時に，今後のICとしての昇級についても同時に考えを巡らせる必要が出てきたりしたので*1，よい機会だと思い新しい技術軸として推薦システムについて勉強することにした．
なぜ推薦システムかと言えば以下の理由である．
あまり進捗は出ていない．とりあえず以下の本を頭から読んでいる．
古典的な近傍ベースの推薦システムだけでなくモデルベースの推薦システムについても解説されており，網羅的に勉強するには良さそうだと思って選んだ．また，読むために必要な知識*2についても都度細かく説明してくれているので初心者には読みやすい構成になっている．
まだ3章までしか読んでないので残りを早めに全部読んで全体像を掴むことを最初のマイルストーンとしている．その後は手を動かして実装してみたり，kaggleの推薦システムコンペをやってみようかと思っている．
あと以下の本は実装についても触れているようなので併せて読んでみる予定である．
月に１回ぐらいのペースで学んだことをこのブログで報告していきたいと思う．
もうすぐ3ヶ月間の無職が終わろうとしているので雑感をまとめておく．
2021年10月から2022年2月にかけて転職活動をしていた．
今回の転職ではいつもと違い10社近くのカジュアル面談を受け6社に応募した． また，珍しく採用に関するwebサービスを使用したり，初めてCoding test対策を行ったりもした．その雑感をまとめておく．
続きを読むSWEとして仕事をし始めてから8年目にして初のスクラム開発を経験した．6か月ぐらい経ちその間に2チームでスクラムを経験してきたので所感を述べる．
過去にいたチームでは，世間一般で言われるスクラム開発*1ではなく
の２点だけを採用した開発プロセスだった．チームによって「タスクを誰が決めるか」「機能要件と非機能要件のベロシティのバランスをどう取るか」といった細かい点は異なっていたが，基本的には上記の2点だけは必須で行い，あとは割と自由，という感じの開発プロセスを複数の組織で経験してきた．2013年～2020年ぐらいの話である．
2021年にjoinしたチームは教科書どおりのスクラムをやっていた．自分は上述のような「なんちゃってスクラム」みたいな開発経験しかなく，自主的にもちゃんとしたスクラムを学んだことがなかった．そのため，今の組織にjoinした当初は「ストーリーポイントで相対見積もりをする」とか「すべてタスクの優先順位はチーム全員が合意して決める」みたいなプロセスを見た時に正直面食らった．これまでやっていたなんちゃってスクラム開発の延長ではなく，全く新しい手法としてスクラムの価値観をinputしていく必要があった．
スクラムに関する所感として，まず感じたのは開発経験が浅いメンバーでもチーム活動に参加しやすいという点だった．スクラムではあらゆるプロセスのやり方が明示的に決められているため，「暗黙の了解で何となくやる」ということがなくなる．そのため成果が属人化しにくいと感じた．リファインメント，プラニングといったイベントですらそれぞれに進め方やゴールが決まっている．組織によってどのようなプロセス・ゴールを設定するかは異なると考えられるが，スクラムはとにかくあらゆるプロセスを明示的に定義することを重視していえるように感じた． また，明文化されていることでSWEとしての経験の差を埋めることができる．「経験10年ぐらいのSWEなら大体何となく知っている」暗黙知に依存すること無くチーム活動が出来るため，経験が少ないSWEでも１メンバーとして参加しやすい気がする．これはチーム間の知識の共有という点でも有効だと感じる．
見積についても相対見積を採用している場合は基準となるチケットをもとに見積もれるので，経験が少なくても見積自体はしやすいと感じた．
ただ，チケットを担当して実施するSWEの力量に応じて実際にかかる工数は異なってくる訳だが，そのギャップをどう扱うかはいまだによくわかっていない．
一般的には見積で各チケットに設定したストーリーポイントの合計と実際に消化できたチケットのストーリーポイントの差が大きくならなければとりあえずは良いらしいのだが，この辺のベロシティの評価方法についてはまだ良くわかっていない． また，実際にチケットに着手する人の力量に応じてかかる時間は異なってくる訳だが，この力量の差はストーリーポイントには反映されておらず，ストーリーポイントがそのスプリントのキャパシティを示す指標として機能しているかは謎である．それでもスプリントを重ねることで「1スプリントで大体これぐらいはできる」という目安としてうっすらとキャリブレーションされてきたので，チームのキャパシティを示す基準になりつつはある．もう少し時間が経てば変わってきそうな気がする．
スクラムの原則は「合意していないことはやらない」だと理解している．これまで述べてきた通り，知識の属人化やスキル差を埋めるための知識共有という目的を考えれば理に叶っている．
一方で，「なんでも合意が必要」という成約は，毎回何かアクションを行う度に多大な合計形成コストを払わねばならないということでもある．
例えば，プラニングで合意に至らなかったチケットがそのスプリントで着手されることはない訳だが，自分としてはどうしてもそのチケットがそのスプリントに必要だと確信したとする．実際大したコストもかからないし手持ちのタスクを全部やっても間に合いそうな気がする．でも合意していないからそういうことは出来ない．正しい手続きとしては，ステークホルダーを全員集めて同期的もしくは非同期的に議論して合意を取らなければならない．例えば1 スプリントで終わる軽いリファクタリングについては，今までいた組織では個人の空き時間で自由にやることが比較的許されていたため，個人でスケジュール管理ができていれば何の問題にならなかった*2．しかしスクラムとなると話は別で，すべてが「チーム」で「合意」されている必要がある．しかも実施したタスクはすべて可視化されていなければならない．よって，個人のスケジュールが空いたならチームで合意したバックログの先頭のタスクをやらなければならないし，勝手にベロシティに計上されないタスクをやることは許されない．そしてリファクタリングといった非機能要件系チケットと新たな機能開発といった機能要件系チケットの優先順位を１つの軸で優先度付けるのってすごく難しい訳で，今いるチームだと機能要件が優先される．KRに定量的な「1 Quoterにおけるリファクタリングチケット数の割合」みたいなものが入ってなければそうなるのが当然である*3．
この点についてはどの程度スクラムに準拠するかという程度問題の気がするが，本当に教科書どおりにやるとこういうことになるらしい．スクラムって厳しいのな．
ただ，自分にとってはあまりに厳しすぎると感じたので，自分から提案してベロシティの10%は自由にバックログから取っていいという合意を得た．
スクラムの「何でも明文化」するところは合理的だと感じたし，これまで自分がベストプラクティスだと考えていたものと合致している． 一方で，相対見積における個人の生産性の差の排除やチームの合意形成コストの高さついてはまだ課題を感じている． ただ，少なくとも2021年現在，自社開発をしている日本国内の組織においてはスクラムを採用しているチームが増えていると感じているので*4，今後の開発手法のデファクトスタンダードとしてスクラムは広まっていくだろうと考えられる．そのため今苦しくても苦しんでスクラム開発に慣れていくコストは無駄ではないと考えている．
*1:何が正式なスクラムなのか分かってないが，本記事では「POとScrumMasterがいる」「スクラムイベントを全部やっている」「割り込みは禁止」「チームで合意したこと以外は勝手にやっちゃダメ」「ストリーポイントは相対見積でプランニングポーカーで行われている」「ベロシティを毎週計測する」みたいなスクラムの教科書に書いてある手法に則ったスクラム開発を指す
*2:前職では手が空いている時に限り2週間までは好きにやれ，2週間を超えそうな場合はちゃんとDesignDocを書いてチームを説得せよ，というルールだった
*3:逆にこれをKRに入れてみるのは案外アリな気がしている
*4:同業者の知人との会話などからそう感じた
