新年明けたので、何か新しいことを始める

というわけで、ウクレレ始めました。ギター弾いてるしまあなんとなくで弾けるやろという感じで触ってますが、とりあえずなんとかなっています。

やり始めた理由は単純にRam on弾きたいなと思ったので。

Ram On

Ram On

  • Paul & Linda McCartney
  • ロック
  • Â¥255


www.youtube.com

今はコード進行もどこかに転がってるし(信用できるかは別にしても)、サッと始められるのは嬉しいわね。

ついでにジョージハリスンがSomethingもよくウクレレで弾かれてたという話があるので、合わせてトライ中。ギターだとフォームすぐわかるけど、ウクレレだとまだコードチェンジが辿々しい感じになる。ここは要練習。


www.youtube.com

今年も終わる

今年は年始からあんまり調子が良くない感じで、年末も同じような感じでございます。

そういや書いてなかったのだけど、また9月ごろに転職……というか出戻りしました。今流行りのアルムナイとか言われてるやつですね。とはいえ、1年以上も離れてるとやはり色々勝手が違ったりする部分もあったり、全然変化のないところもあったりと、まあ腕をぶん回すところもあるかなという感じで4ヶ月ほど仕事をやっております。

冒頭にも書いたけど、まあちょっとあまり調子良くないところも含めて年を跨ぐことになってしまったので、この辺は来年に期待という感じでしょうかね。外のイベントごとにもあまり参加しない感じになってしまったので、そこら辺も用心しつつ外には出て行きたいなぁと思っております。

今まで使っていたCloudflare warpが突然DNS Proxy Failureで動かなくなったので、原因を探る

最近あんまり文章書いてないので、ちょっとリハビリ的にメモを書いてみる。

one.one.one.one

しばらく前からmac用のCloudflare warpアプリを使用しているのだが、ある日突然DNS Proxy Failureを発生するようになったのでその原因を探ってみた。

自分の環境下での原因

結論から書くと、Docker Desktopがport 53を握っていたためCloudflare warp側で上記エラーが発生していた。この内容はCloudfalreのコミュニティでも報告されている内容であった。

community.cloudflare.com

調査

ちょうどOSアップデートのタイミングとかぶっていたため、同様にCloudflare warpを導入してるMacbook Proでも同じ現象が起きるかOSアップデートを実施してみたとこ、Cloudflare warpが使用できていたため、一つの端末の問題であることを確認した。

次にエラー内容で単純にググってみると(便利なことに、Cloudflare warpのエラー内容はちゃんとコピーできるようなUIになっている)、上記の内容や下記のようなコミュニティの投稿が出てきた。

community.cloudflare.com

DNS proxy failureそのものに着目してる投稿では回避するための設定など書かれているが、別端末では問題ないためDocker Desktopを一度落としてCloudflare warpを有効にすると接続が問題なく開始された。ちなみにその後Docker Desktopを立ち上げても問題なく動いている。

その後再起動などしても問題なく動いているため、Docker DesktopとCloudflare warpの起動順序によって問題が発生するんじゃなかろうかと推察している。

なんとなく落ちるなと思う瞬間

何度か転職活動してると、面接を受けている最中には「落ちるな」と思う瞬間がある。

だいたいそういうときは相手との話が噛み合ってないなと感じたり、向こうの想定する回答ができてないんだろうなという深掘りが入ったりすることがある。こちらとしてもあまりうまく受け答えできてないと思ってるので丁寧に回答してみるもののなんとなく会話の歯車が回ってない感触が常にあるので、「これは落ちるなー」と面接が終わる。こういうのは経験上、2次面接あたりのちょっと上の層の方々とお話しするタイミングで起きているように思えるので、そこで会社と自分と肌が合う合わないがあるんだろうなーと思っている。

逆に面接でえらい勢いで話が進んでいったりすることもあるので、ここは自分の課題感と同じものがあるんじゃろなとか、多分気が合うんじゃなかろうか、と思っているうちにオファーが出たりする。

まあそんなもんですよね。

対話型ファシリテーションの手ほどき を読了

数年前から1on1を担当するとか、ファシリテーターとしてミーティングに参加することも増えてきたこともあるが、何かしら質問を投げかけるときに元々「なぜ」とか聞いてもあまり実りのあるものにならないなという感触自体はあったのだけど、この本で自分が感じていたことを体系立てて述べられているなと思った。

「なぜ」「どうして」を含む質問では相手の考え自体は聞けたりするが、もっと奥深い気づきには到達していないというところでグイグイと引き込まれ、全部で119ページほど、読むところだけを考えると110ページほどなのでサクッと読み終わった。NPOでの実際の経験などの例が出てきて、その中で「なぜ」「どうして」を含む質問をして失敗したパターンや「いつ」「だれが」「どこで」を含む事実を知るための質問を重ねていくことによって相手の記憶を辿らせて気づかせていくパターン、はたまた「なぜ」「どうして」で相手の考えを聞き出した後、事実を深掘りしていった結果本来の問題と考えがどれほどずれていたのか、など興味深く自分でもそういったファシリテーションをやっていきたいなと思うほどであった。

こういったスキルは単純にファシリテーションや1on1の場だけでなく、ソフトウェア開発における問題を炙り出す際にも有用だなと感じた。それこそ「いつ」「だれが」「どこで」という質問ってイベントを炙り出す質問なので、コトに向かうものでありEvent stormingで考慮している内容にも近いものがあるなぁと感じた。

本当にいい本だったので、おすすめ。

ラディカル・プロダクト・シンキング を読み終わった

どこかで本の内容を見かけて興味深かったので購入してサクッと読了。

ここ最近、開発に関わらず全体のビジョンが必要だと思うことが多々あり、そういった意味でも自分の考え方を補強するような内容だった。

自分自身、アジャイル開発の信奉者という側面があって、短いイテレーションで必要なものを必要なだけ作るという点になんの異論はないのだけど、世にやれているスクラムでの開発などに参加していると、実はその場その場の局所最適解に陥っていてプロダクトとしては全く嬉しいものになっていないのではないか、と感じることがあるのだ。

往々にしてそういった場面で足りてないと思うのが、全体的な見通しというか、もっと洒落た言葉で書くのであれば「ビジョン」になるのかもしれない。

そういった面で、本書はイテレーティブなアプローチのみでは方向性が定まらないという問題にたいして、必要なのは「ビジョン」であるということを主張している本である。

おそらく本書で主張している内容はそれほど目新しいものではないと思う。第2章のプロダクト病についてはよく言われる話ではあるし、第7章における文化の話、いわゆる心理的安全性や燃え尽き症候群に至るような消耗の話はこれまででも記述され問われてきたものだと思う。ただこれらの内容をまとめてソフトウェアサービスを作っていくに際してまとめて知るために最適な本はなかったように感じる。

強いて目新しい部分をというならば、第3部の内容は面白かった。ソフトウェアサービスの社会的意義という点や倫理という面をしっかりと書き記しているのは大事だと思うし、この論点については自分も同意できる。

そういえば久々にfukabori.fmのテスト駆動開発とは何かの回を聴いて、テスト駆動開発のRED/GREEN/REFACTRORINGの前にそのコードで達成したいと思っているそのときのテストリストが必要である、という話がなされていた。

fukabori.fm

自分の解釈で言い換えると、そのときのテストリストとは目的や方針というニュアンスになるのかなと思うが、これはまさしくビジョンなのではないかと思う。

今年ももう終わり

というところで、簡単に何やってたか書く。

  • 転職
  • Scalaを書く
  • Rustを書く
  • Terraformを書く
  • Helmfileを書く
  • あんまり遊んだ記憶がない

転職してもやってることはあまり変わらないが、環境が激変してその辺がいまいち乗り切れなかったところがあるので、来年はもうちょっと波に乗れるといいなと思う。