2時に寝て7時に起きた。深夜に葬送のフリーレン10巻を読んでからなんとなく眠れなくて夜更かししてた。木曜日は会議がなくて自分のために時間を使える。機能開発に集中して実装していた。

go の学び直し

Gopher塾 #4 - 私も解説できるポインタ - DAY1 に参加した。

今日のテーマはポインタ。tenntenn さんが話すのだから深い内部実装の話しなどもあるのかな？と期待していたけれど、これは基本的な go のポインタの扱いを学ぶ講義だった。私にとっては9割は知っていることだった。それでも1割は知らないことがあったので参加して勉強にはなった。この歳になると本やイベントから1-2割学べたら十分だと思う。go は内部的にすべて値渡しで何でもコピーするするといった振る舞いをする。ポインタを渡すと、ポインタの値であるアドレスをコピーすることでプログラムが動く。コピーなので大きな構造体をそのまま渡すとその分のメモリのオーバーヘッドがあって遅くなったりする。ポインタならアドレスだけのコピーで済む。

go には参照の概念はないという説明があって、ポインタと参照は別の概念なんだと今更ながらに気付いた。gpt-4 にポインタと参照の違いを尋ねたりしていた。参照は初期化後に変更できなかったり、null を参照できなかったり、ポインタ演算のようなことができなかったりすることで安全にプログラミングするための言語機能と言える。一般的には参照はポインタを使って実装される。ポインタの方が低レイヤで制約が少ないと言える。参照はポインタの一部の機能を安全にプログラマーに提供していると言える。

次に go のポインタの特徴をまとめる。

• 型付け
  • ポインタは型付けされていて、特定の型の変数のアドレスだけがその型のポインタに割り当てられる
• アドレス演算子とデリファレンス演算子
  • これらを単項演算子と呼ぶ
  • アドレス演算子 (&) で変数のアドレスを取得してポインタを作成する
  • デリファレンス演算子 (*) でポインタが指すアドレスに格納されている値にアクセスする
• ポインタ演算制限
• ポインタ演算は許可されていない、メモリアクセスの誤りやセキュリティ上の問題が軽減される
• new と make 関数
  • new 関数を使うと指定された型の新しい変数を作成してそのアドレスを返す
  • make 関数は、スライス、マップ、チャネルなどの複合データ構造を作成および初期化して、それらへのポインタを返す
• ポインタの nil 値
  • ポインタは、無効なアドレスを表す特別な値である nil をもてる
  • nil ポインタにアクセスしようとすると、実行時に panic が発生する
• メソッドレシーバとしてのポインタ
  • メソッドレシーバとしてポインタを使うとメソッド内でレシーバオブジェクトの変更ができる
    • 値レシーバは意図せぬ不具合を招く可能性があるから基本的にはポインタレシーバを使う方がよいのではないかといった話しもあった

0時に寝て夜中に吐き気がして2回ほど起きて3時と5時に起きて8時に起きた。なかなか苦しい寝方をした。

ヤフートラベルと一休.comのシステム統合

アーカイブ公開されたらみようと思いつつ忘れてたので見返した。

雑なめも。また機をみて見返すこともあるかも。

• バックエンドは完全に一休側に寄せるという大きな意志決定を2016年に行った
  • この意志決定はフロントエンド統合にも大きな影響を与えた
  • ふじもんさんの意志決定がよかった？
• 今日の話しはマルチブランドデザインシステム統合がメイン
  • 開発者が50-60人程度で半年ぐらいで launch できた
  • nuxt/vuejs で開発している
  • スタイルは tailwindcss を使っている
  • 実は launch した後にこのシステムが必要だとわかった
    • 開発者とデザイナー間の細かい意思疎通が困難
    • 外部からデザインシステムに詳しい人にも来てもらっていろんな議論をした
    • ガイドラインを言語化するところから始め、最終的にソースコードの共有ができるようになった
  • 終わってからデザインシステムそのものは重要ではないと気付いた
    • この過程で開発者とデザイナー間のどのように共通化するか、あるいはしないかと議論を繰り返し行ったことが重要だったと当事者がインタビューで語っていた
    • デザインシステムの開発を通じてデザインの共通認識をもてたことがよかった
• 波及効果
  • 同じソースコードから少し異なる体験の開発のノウハウができた
  • ふるさと納税に特化した宿泊予約サイトを作った
• 統合は終わりではない、lauch したところが始まり
  • 統合後にいろいろな施策をすることで課題がみえてくることがある
• 全国旅行支援は1つの開発で2つの体験をつくることができた
• Q. デザイナーと開発者はわりと仲が悪いのでは？価値観や考え方が異なるのですり合わせるのは難しいのでは？
  • 過去の一休でも起きていた
  • 一休のチームはデザイナーと PM と開発者で構成されている
    • このチームが一緒に働いていてチームでなるべく意志決定している
    • 普段から一緒に働いていると仲が悪いということはなかった
    • とはいえ、仕事のプロセスが異なるので課題はあった
      • 地道に丁寧にすり合わせを行った
      • 外部から講師を読んで中立的な立場でワークショップを何度も行った
  • デザイナーと開発者を別の組織にしているとコミュニケーションの壁ができてしまうかもしれない

go の学び直し

テストの学び直し に引き続き、Gopher塾 #2 - Goらしいコードの書き方 - DAY 1 に参加した。

テストの次のプログラミングの話しだったので内容そのものは難しくはなかったけど、改めて重要な項目を選抜しているのだと考えると学びはあったと思う。参考になったことをいくつか覚えている範囲でまとめる。名前の付け方について感覚的に理解していたし、実際に私はそうしているけど、コードレビューしていて自然になっていないコードを指摘する機会も多いので一定の習熟を要するのかもしれない。いま毎週勉強会をやっていて私が講師として話している。ネタがなくなってきたり大変になったきたら準備の少ないコードリーディング会もやってみたいと思った。

• google Go Style
• derrors.Wrap
• 名前に文脈を与えるという概念
  • 相対的な名前をつける
• 準備の少ないコードリーディング会
  • お題（読むパッケージ）を決める
  • 選んだお題に期待することを当日話す
  • 時間を決めてみんなでそれぞれ読む（20分とか）
  • 読みながらSlackのスレッドにメモをしていく
  • 残りの時間で気になったところを議論する
  • 自分が気づけなかった点を知ることができる

0時に寝て5時に起きた。夜中に目覚めたかどうかはわからないぐらいにはたぶん寝てたと思う。

go の http フレームワークの選定

net/http で実装していた web api サーバーにフレームワーク導入しようかと考えている。いままでは認証・認可を外部で行う想定だったが、やっぱり api サーバーに実装した方がよいだろうと要件を再確認したので routing と middleware を再利用できるフレームワークを使うメリットが出てくる。net/http 上で直接 routing, middleware を実装するのは別に難しくないから自分で実装すればよいという考え方がある。一方で誰が実装しても大して変わらないものを車輪の再発明する必要があるのかというところに私は懸念に感じる。また context があとから標準ライブラリに追加されたため、net/http の HandlerFunc は context をシグネチャにもっていない。リクエストコンテキストをもっていないのが net/http の欠点だと私は考えていた。しかし、調べてたら NewRequestWithContext が追加されていてハンドラーではなくリクエストからリクエストコンテキストを扱えるようになっていた。これは私の勘違いだった。

フレームワークを使おうと決めて難しいのはなにを選ぶか。最近の流行り廃りや動向を私は知らないので基準がない。たまたましぶかわさんの記事をみつけて読んでいた。

• Goのおすすめのフレームワークはnet/http

この中で紹介されている chi か echo のどちらかにしようと直観で決めた。echo は以前 go の勉強会をしたときにいけうちさんが採用していたのでよく覚えている。そのときの話しを聞いていてもよさそうにみえた。たまたま echo のサイトをみたら Shiguredo さんのロゴがあって驚いた。スポンサーをされているらしい。chi はまったく知らない。どちらも十分によく使われていて middleware も揃っているフレームワークにみえる。本質的にはどちらを選んでも構わない。一方でマネージャーとしてどういう調査をして、どういう根拠で、どの技術を選定するのか。メンバーに対して説明責任を果たすためにこの2つのフレームワークの調査をすることに決めた。私自身がどちらもフレームワークも使ったことがないので軽くコードも書いてみてどんな雰囲気なのか感触を掴みつつ、フレームワークのソースコードも読んでみようと思う。

2時に寝て6時に起きて2度寝したら8時だった。生活リズムがおかしい。

Go Code Review Comments の学び直し

私の周りでは Go Code Review Comments というドキュメントが引用されているのをよくみかける。google 社での go のコードレビューのときによくある指摘をまとめたものである。pr/mr を送る前にこれぐらいは自分でチェックしようといったガイドになる。私自身、過去に何度か読んでいるとは思うが、久しぶりに go 開発をするので学び直しも兼ねて読み直すことにした。うちのチームは java 開発者が多いせいか、go のコードで go っぽくないところがいくつか散見されていた。チームメンバーにも共有する意図も含めて2回にわけて勉強会をしてみんなで読み合わせをする。その下調べとして既存のコードでこのガイドに準拠していないコードがあればそれはわかりやすい事例になるので探したりしていた。

23時に寝て2時に起きてその後どうしていたかあまり覚えていないが気付いたら8時だった。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。今週も全然ストレッチできなかったのになぜか数値はよくなっていた。ストレッチを受けていて調子の悪さも感じなかったので気候が過ごしやすくなってきて体調がよくなった結果として普段の生活における活動量や新陳代謝などにも影響を与えているのかもしれない。トレーナーさんからは涼しくなったのだから運動をしてくださいと言われた。ほんとその通り。

知識と経験

• You’re Not a Senior Software Engineer

たまたま目を通した medium のおすすめ記事に出ていて、タイトルにひかれて斜め読みしたらおもしろかったので後で deepl を使って精読した。最近は英語の記事を deepl で訳して読んでいる。まず deepl で全訳した後に文脈から訳文の意味をとれなかったり、明らかにおかしいところだけを手直しする。著作権的に機械翻訳を公開はできないため、その翻訳内容は課題管理システムのイシューで管理している。この記事だと手直し数回ぐらいで大意を読める。普段、英語の記事を日本語アカウントで紹介することはないんだけど、これは素晴らしい内容だったのでそのまま共有することにした。軽く所感も書いてあるが、課題管理システムのイシューにはさらに詳細な分析やコメントも残している。

知識とはやり方を知っていることで、経験とはやってはいけないことを知っていること。素晴らしい記事だった。 / You’re Not a Senior Software Engineer by @repsofsunshine https://t.co/3qitFOFTJp

— Tetsuya Morimoto (@t2y) September 10, 2022

多くの若いチームでは課題管理の重要性を理解していない。その無理解の原因の1つとして、ものごとを検討したり判断したりした時点では正しかったことが未来のある時点で誤りになってしまう可能性を想像できないからだと私は考えている。記憶と忘却の仕組みから前日のことですら半分以上忘れてしまうので数ヶ月前の詳細など、ほとんどの人は覚えていない。にも関わらず、日々の小さい判断の積み重ねや意思決定の履歴を記録として残さないのはなぜだろうか？それはその詳細があとで重要になるかどうか、多くのケースでその発生時点ではわからないからだ。例えば、システムのアーキテクチャに関して言えば Architectural Decision Records (ADRs) というドキュメントが提唱されている。アーキテクチャのような大きなものでさえ、明示的に残さないと経緯がわからなくなるのに、もっと小さい粒度である日々の開発や運用の誤りを、一般の (普通の) 開発者がその発生時点から数ヶ月や数年経ってふりかえって見直すことができるだろうか？いやできないというのが、多くのチームやメンバーをみてきた私の所感だ。多くのメンバーは過去のある時点の見逃しや判断ミスをなかったことにしようとする。それは無意識にしろ意識的にしろ起きやすい。客観的に詳細を確認できればなかったことになってしまうのは仕方のないことでもある。

私は課題管理システムのコメントに、こういう状況からこう判断したとか、誰それと相談してこういう事情でそうしたとか、自身の感覚からとくに意味もなく決めたとか、常々なぜに相当する内容を残している。そして、あるとき過去の経緯を見返して、そのときの判断は適切だったか、過去のある時点で気付けたはずのことを見逃してなかったか、見逃していたとすればどうすればその時に気付きを得られたか、というふりかえりを日常的なチケット整理の一環として実践している。件の medium の記事にはなぜそれが重要なのかの概念を書いてあるように私には受け取れた。課題管理 + 情報共有の需要な概念の1つだと認識して寝かせておこうと思う。