seri::diary

日常

Poetryでproject rootに.venv directoryを作って欲しい場合の設定

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環境を構築してから任意のドライブに引っ越すまでの手順

何番煎じだって話だが備忘録として残しておく.

はじめに

WSLでLinux環境を作ると,デフォルトではWindowsがインストールされているドライブ上にLinuxのファイル本体が配置されてしまう.別 のドライブにLinuxのファイルを配置したい場合は,一度Windowsがインストールされているドライブ上にLinuxをインストールした後に,ファイル一式をexportして任意の場所にimportする必要がある.めんどくさいね.

前提条件

Windows 11で動作確認をした.

Windows 10でもWSL自体は動作するのだが,Windows 10の場合WSLのバージョンが古くなってしまうらしく,これが原因で,WSLで構築したUbuntu環境上で nvidia-smiGPUが確認できない問題が発生した.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

手順

1. 管理者としてTerminalを開く

2. インストールできるディストリビューションの一覧を確認する

> 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

3. 任意のDistributionをInstall

ここでは Ubuntu-22.04 をinstallする.

> wsl --install -d Ubuntu-22.04

4. installできたことを確認

> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Stopped         2
> wsl uname -r
5.15.90.1-microsoft-standard-WSL2

5. 任意のDriveにexportする

> wsl --export Ubuntu-22.04 {file_name}.tar

6. 一度installしたUbuntu-22.04をuninstallする

> wsl --unregister Ubuntu-22.04

7. 任意のPathにimportする

> wsl --import {distro_name} {import_path} {file_name}.tar

8. (Optional) ログインユーザを変更する

何故かimportするとログインユーザが root に変更される.これが嫌な場合はログインユーザを変更する.

Ubuntu-22.04上で以下のように /etc/wsl.con ファイルを作成して何度かログインし直すと変更される. wsl --shutdown してもすぐには反映されず,一定時間待つ必要があるようだった.謎.

cat << EOF > /etc/wsl.conf
[user]
default=user-name
EOF

推薦システムを勉強し始めた

はじめに

3ヶ月ぶりの労働を再開して一ヶ月が経った.最初こそ披露困憊で業務後は何もできなくなっていたものの,徐々に勘を取り戻してきたので余裕が出てきた.

同時に,今後のICとしての昇級についても同時に考えを巡らせる必要が出てきたりしたので*1,よい機会だと思い新しい技術軸として推薦システムについて勉強することにした.

なぜ推薦システムかと言えば以下の理由である.

  1. 現職で作っているものがフリーマーケットサイトなので推薦システムを内製しているチームがあり,そのチームと今後協業する必要が出てくる可能性がある
  2. 推薦システムは以前勉強した機械学習と関連している部分があり,ある程度使える共通基礎知識がある
  3. 絶対的な解がない分野なので研究対象としてもまだ伸びしろがある
  4. 推薦システムは何かしかのコンテンツをユーザに提供しているサービスでは常に重要であり,今後10年スパンぐらいで見ても需要は減らないだろうと思った

今やってること

あまり進捗は出ていない.とりあえず以下の本を頭から読んでいる.

古典的な近傍ベースの推薦システムだけでなくモデルベースの推薦システムについても解説されており,網羅的に勉強するには良さそうだと思って選んだ.また,読むために必要な知識*2についても都度細かく説明してくれているので初心者には読みやすい構成になっている.

今後の予定

まだ3章までしか読んでないので残りを早めに全部読んで全体像を掴むことを最初のマイルストーンとしている.その後は手を動かして実装してみたり,kaggleの推薦システムコンペをやってみようかと思っている.

あと以下の本は実装についても触れているようなので併せて読んでみる予定である.

月に1回ぐらいのペースで学んだことをこのブログで報告していきたいと思う.

*1:要するにreport lineと「器用貧乏なのでICとしては頭打ちだけどこっからどうやって給料上げるの」的な議論をした訳である

*2:主成分分析や勾配降下法など

3ヶ月無職期間した雑感

  • tl; dr
  • はじめに
  • やったこと
    • 国内旅行
      • 出雲 2022年4月25日 - 26日
      • 長崎 2022年5月12日 - 13日
      • 伊豆・伊勢 2022年5月23日 - 24日
        • 伊豆
        • 伊勢
      • 沖縄本島 2022年6月14日 - 18日
    • 登山
    • 手術
  • 雑感
    • 敢えていつもと違う過ごし方をしたのは正解だった
    • ヤマノススメ
  • おわりに

もうすぐ3ヶ月間の無職が終わろうとしているので雑感をまとめておく.

tl; dr

  • 元々は無職期間を勉強時間にしようと思ったが勉強は仕事しながらでもできるので敢えて止めてみた
  • 登山を始めたことで生きる活力が復活した
  • たまには普段と違うことに注力する時間も人生においては重要だと実感した
続きを読む

今回の転職活動の雑感

  • はじめに
  • 転職活動の結果
  • 希望したポジション
  • 転職のために使用した採用媒体
    • 転職ドラフト
    • YOURTRUST
  • 今回の転職活動での気付き
    • Coding testは対策が必須である
    • System design interviewも準備しておいた方がいいが業務経験があればそこまでビビる必要はない
    • 6社同時に受けると毎日のように面接がある
    • 希望年収は自分に嘘をつかずに伝えた方が良い
    • マネージャーやリーダーの経験がないと判断されるとマイナス評価につながる会社が存在する
    • 自分の評価は企業によって差が大きい
  • おわりに

はじめに

2021年10月から2022年2月にかけて転職活動をしていた.

今回の転職ではいつもと違い10社近くのカジュアル面談を受け6社に応募した. また,珍しく採用に関するwebサービスを使用したり,初めてCoding test対策を行ったりもした.その雑感をまとめておく.

続きを読む

SWE歴8年目にして初めてスクラムを経験したのでその所感を述べる

はじめに

SWEとして仕事をし始めてから8年目にして初のスクラム開発を経験した.6か月ぐらい経ちその間に2チームでスクラムを経験してきたので所感を述べる.

自分が経験してきた開発手法

過去にいたチームでは,世間一般で言われるスクラム開発*1ではなく

  • 毎日チーム内で進捗を確認(いわゆる朝会の運用)
  • チケットはカンバンで管理

の2点だけを採用した開発プロセスだった.チームによって「タスクを誰が決めるか」「機能要件と非機能要件のベロシティのバランスをどう取るか」といった細かい点は異なっていたが,基本的には上記の2点だけは必須で行い,あとは割と自由,という感じの開発プロセスを複数の組織で経験してきた.2013年~2020年ぐらいの話である.

今のチーム

2021年にjoinしたチームは教科書どおりのスクラムをやっていた.自分は上述のような「なんちゃってスクラム」みたいな開発経験しかなく,自主的にもちゃんとしたスクラムを学んだことがなかった.そのため,今の組織にjoinした当初は「ストーリーポイントで相対見積もりをする」とか「すべてタスクの優先順位はチーム全員が合意して決める」みたいなプロセスを見た時に正直面食らった.これまでやっていたなんちゃってスクラム開発の延長ではなく,全く新しい手法としてスクラムの価値観をinputしていく必要があった.

スクラムやってみた所感

あらゆることが明文化されている

スクラムに関する所感として,まず感じたのは開発経験が浅いメンバーでもチーム活動に参加しやすいという点だった.スクラムではあらゆるプロセスのやり方が明示的に決められているため,「暗黙の了解で何となくやる」ということがなくなる.そのため成果が属人化しにくいと感じた.リファインメント,プラニングといったイベントですらそれぞれに進め方やゴールが決まっている.組織によってどのようなプロセス・ゴールを設定するかは異なると考えられるが,スクラムはとにかくあらゆるプロセスを明示的に定義することを重視していえるように感じた. また,明文化されていることでSWEとしての経験の差を埋めることができる.「経験10年ぐらいのSWEなら大体何となく知っている」暗黙知に依存すること無くチーム活動が出来るため,経験が少ないSWEでも1メンバーとして参加しやすい気がする.これはチーム間の知識の共有という点でも有効だと感じる.

ストーリーポイントによる相対見積についてはちょっと疑問がある

見積についても相対見積を採用している場合は基準となるチケットをもとに見積もれるので,経験が少なくても見積自体はしやすいと感じた.

ただ,チケットを担当して実施するSWEの力量に応じて実際にかかる工数は異なってくる訳だが,そのギャップをどう扱うかはいまだによくわかっていない.

一般的には見積で各チケットに設定したストーリーポイントの合計と実際に消化できたチケットのストーリーポイントの差が大きくならなければとりあえずは良いらしいのだが,この辺のベロシティの評価方法についてはまだ良くわかっていない. また,実際にチケットに着手する人の力量に応じてかかる時間は異なってくる訳だが,この力量の差はストーリーポイントには反映されておらず,ストーリーポイントがそのスプリントのキャパシティを示す指標として機能しているかは謎である.それでもスプリントを重ねることで「1スプリントで大体これぐらいはできる」という目安としてうっすらとキャリブレーションされてきたので,チームのキャパシティを示す基準になりつつはある.もう少し時間が経てば変わってきそうな気がする.

合意を取らないと何もできないので何でも人と話す必要がある

スクラムの原則は「合意していないことはやらない」だと理解している.これまで述べてきた通り,知識の属人化やスキル差を埋めるための知識共有という目的を考えれば理に叶っている.

一方で,「なんでも合意が必要」という成約は,毎回何かアクションを行う度に多大な合計形成コストを払わねばならないということでもある.

例えば,プラニングで合意に至らなかったチケットがそのスプリントで着手されることはない訳だが,自分としてはどうしてもそのチケットがそのスプリントに必要だと確信したとする.実際大したコストもかからないし手持ちのタスクを全部やっても間に合いそうな気がする.でも合意していないからそういうことは出来ない.正しい手続きとしては,ステークホルダーを全員集めて同期的もしくは非同期的に議論して合意を取らなければならない.例えば1 スプリントで終わる軽いリファクタリングについては,今までいた組織では個人の空き時間で自由にやることが比較的許されていたため,個人でスケジュール管理ができていれば何の問題にならなかった*2.しかしスクラムとなると話は別で,すべてが「チーム」で「合意」されている必要がある.しかも実施したタスクはすべて可視化されていなければならない.よって,個人のスケジュールが空いたならチームで合意したバックログの先頭のタスクをやらなければならないし,勝手にベロシティに計上されないタスクをやることは許されない.そしてリファクタリングといった非機能要件系チケットと新たな機能開発といった機能要件系チケットの優先順位を1つの軸で優先度付けるのってすごく難しい訳で,今いるチームだと機能要件が優先される.KRに定量的な「1 Quoterにおけるリファクタリングチケット数の割合」みたいなものが入ってなければそうなるのが当然である*3

この点についてはどの程度スクラムに準拠するかという程度問題の気がするが,本当に教科書どおりにやるとこういうことになるらしい.スクラムって厳しいのな.

ただ,自分にとってはあまりに厳しすぎると感じたので,自分から提案してベロシティの10%は自由にバックログから取っていいという合意を得た.

おわりに

スクラムの「何でも明文化」するところは合理的だと感じたし,これまで自分がベストプラクティスだと考えていたものと合致している. 一方で,相対見積における個人の生産性の差の排除やチームの合意形成コストの高さついてはまだ課題を感じている. ただ,少なくとも2021年現在,自社開発をしている日本国内の組織においてはスクラムを採用しているチームが増えていると感じているので*4,今後の開発手法のデファクトスタンダードとしてスクラムは広まっていくだろうと考えられる.そのため今苦しくても苦しんでスクラム開発に慣れていくコストは無駄ではないと考えている.

*1:何が正式なスクラムなのか分かってないが,本記事では「POとScrumMasterがいる」「スクラムイベントを全部やっている」「割り込みは禁止」「チームで合意したこと以外は勝手にやっちゃダメ」「ストリーポイントは相対見積でプランニングポーカーで行われている」「ベロシティを毎週計測する」みたいなスクラムの教科書に書いてある手法に則ったスクラム開発を指す

*2:前職では手が空いている時に限り2週間までは好きにやれ,2週間を超えそうな場合はちゃんとDesignDocを書いてチームを説得せよ,というルールだった

*3:逆にこれをKRに入れてみるのは案外アリな気がしている

*4:同業者の知人との会話などからそう感じた