私が歌川です

@utgwkk が書いている

ふつうの連休

5時までDJを見ていたので、そのまま泥のように爆睡し、14時ごろに起きた。

弘で焼肉コース。すいませんいきなりですが肉を見てください。

オオミヤでレモンサワーに溺れることなく無事に帰宅。雨が降っていたのでやや濡れという感じ。

総じて、とくに有休を入れて連休を伸ばすこともなく、遠出するわけでもなく、ふつうの連休って感じだった。まあこれぐらいでいいと思う。連休だからどこかに出かけなきゃいけない、なんて法も道理もなくて、タイミングが合ったらどこかに行くぐらいでいい。

おたくスタンプラリーを終わらせにかかる。壬生寺と嵐山を回収し、四条河原町のエディオンで引き換えた。

クリアファイルはなくなっていたので缶バッジのみ。限界修学旅行を最後までやる人のほうが少なかったということ?

夜はメトロにDJを見にいった。

www.metro.ne.jp

3時を過ぎたあたりから眠気がすごくなって、5時過ぎに抜け出し、うどんを食べて帰宅して気絶する。

QRコードをかざすだけであらゆるものが手に入る世界、それがスパワールド

ほんのり二日酔いで目覚める。心当たりしかない。動けないほどでもない、風呂、とにかく巨大な風呂……ということでスパワールドに行くことになったのであった。阪急と大阪メトロ堺筋線が直通しているので、思ったよりもスパワールドとかあのあたりが近い。

スパワールド、それはQRコードをかざすだけであらゆるものが手に入る世界。以前はリストバンドだったと思うけど、防水ギグバンドみたいなやつに変わっていた。

風呂で自律神経をキメたあとはマルフクでホルモンとビールを堪能する。なんか価格が破壊されているのでは、というぐらいに安くておいしくてすごいな。

天王寺あたりで見かけられる、「闊達」とでもいうべき雰囲気が恋しくなることがある。混沌としているような感じ。けど家のすぐ近くに欲しいかというとそれはまた話が変わってくるな。

帰宅してからは発表資料を作っていた。40分の発表だとちゃんとストーリーを作りながら話す必要があるだろうけど、今のところは取り上げたいトピックをとにかく列挙している。ここからどのように道を作るのか?

Kyoto.go #50 に参加した&LTした #kyotogo

kyotogo.connpass.com

参加して、LTしました。

speakerdeck.com

Webアプリケーションを運用する立場からは、多少パフォーマンスが犠牲になるよりもエラーの発生元を容易に特定できるほうがよいに決まっているだろう、となるとやっぱりスタックトレースが欲しくなるじゃん? というLTでした。

LTのテーマを決めたあとに、Findyさんのイベントの存在を知って参加したので、直前で内容をちょっとブラッシュアップするなどの活動が発生しています。 Goのエラーハンドリングに対する関心の高まりが伺えますね。

findy.connpass.com

組み込みGoの話や、自作ライブラリの話などいろいろ聞けてよかったです。普段あまり気にかけない分野の話を聞けるのがいいですね。fuzzingテストの継続的インテグレーションについては考えたことがなかったし面白い気がする。

二次会の店を予約するのもやりました。周辺に10人ぐらいで転がり込める店があるのは便利ですな。けっこう飲んだような気がするけど今のところ元気です。

前にKyoto.goに参加したときも似たようなことを感じたのですが、自己紹介タイムや休憩・雑談タイムなど、交流を促す仕組みに対して注意が払われているのがよく伝わってきますね。よくわからないことでもとりあえず話を聞いて、輪に入ってうなずいているだけでもいいので、「発表を聞く」よりも先の持ち帰りを提供するような、そういう気配りがされていそう、と思いました。運営の皆様ありがとうございました。

そろそろGo Conference 2024の準備するか……。

「SCRUM BOOT CAMP THE BOOK スクラムチームではじめるアジャイル開発」を読んだ

普段からスクラムチームの一員として開発をやっているのだけど、自分にスクラムの語彙や前提知識が足りていないんじゃないか、何が基礎概念でどこがアレンジされている部分なのか、などいろいろ思っていたので買って読んだ。

要点を新人スクラムマスターの「ボクくん」が各所でまとめてくれているし、文章も難しくないのですらすら読み進めることができた。入門書としてはよさそうな雰囲気がする。もっと言うと基礎編だけ読むぐらいでも早いうちにやるとよかったですね。

「適応」の話はけっこう身に覚えがあるかもしれない。決まっているものが不可解でも決まっているからと従うのではなく、それを変えていけないか、という議論はよくあるだろう。もうちょっと具体的な実装の話に踏み込むと、linterのルールを無効にするかどうか決めるのも「適応」なんじゃないか。

ようは先の見通しを立てやすくするのと、対話・問題発見に重きを置いている、という話だと理解している。ベロシティがどんどん上がっていけばよいのではなく、安定しているほうがよいのは、見通しを立てられるし、ベロシティが安定しないことを通じてチームの問題の予兆に気づけるから、ということなのか。

ここでようやく前提知識が見えてきたという段階なので、アレンジされている部分についてはチーム側と話していくことになるだろう。この文章は業務連絡を兼ねています。

reflectパッケージでstructのunexportedなフィールドにアクセスするイディオムの正当性を (一部) 確かめる

生きてるといろいろなことがあり、リフレクションでstructのunexportedなフィールドに値を書き込みたくて調べていたら、以下のStackoverflowの回答が見つかった。

stackoverflow.com

以下のようなイディオムでstructのunexportedなフィールドにアクセスできる*1

type S struct {
    a int
    b int
}

s := S{}
rv := reflect.ValueOf(&s).Elem()
for i := 0; i < rv.NumField(); i++ {
    field := rv.Field(i)
    field = reflect.NewAt(field.Type(), unsafe.Pointer(field.UnsafeAddr())).Elem()
    field.SetInt(1000)
}
fmt.Printf("%#v\n", s)

このイディオムでunexportedなフィールドの値を読み書きできるようになる原理は goでreflectを使ってunexported fieldの値を見る - podhmo's diary で解説されているけど、ここで unsafe.Pointer を使ってよい理由がパッと分からなかった。

元のStackoverflowの回答には以下のように書いてあるので、根拠を確かめることにする。

This use of unsafe.Pointer is valid according to the documentation and running go vet returns no errors.

unsafe.Pointer のドキュメントには、以下のパターンで unsafe.Pointer を使うのはvalidである、と書いてある。

  1. Conversion of a *T1 to Pointer to *T2.
  2. Conversion of a Pointer to a uintptr (but not back to Pointer).
  3. Conversion of a Pointer to a uintptr and back, with arithmetic.
  4. Conversion of a Pointer to a uintptr when calling syscall.Syscall.
  5. Conversion of the result of reflect.Value.Pointer or reflect.Value.UnsafeAddr from uintptr to Pointer.
  6. Conversion of a reflect.SliceHeader or reflect.StringHeader Data field to or from Pointer.

このうちreflectパッケージが関係するのは 5. だけなので、5. の条件を満たすことを確認する。

unsafe.Pointer を使っている部分だけに着目すると、以下のような式になっていることが分かる。

unsafe.Pointer(field.UnsafeAddr())

この式では、 reflect.Value 型の UnsafeAddr() メソッドを呼んで得られた uintptrunsafe.Pointer に変換している。なので、確かに 5. の条件を満たす。

以降のreflectパッケージを使った処理の動作原理については、先述したブログ記事で解説されているので、そちらを参照してほしい。しかしunsafeっていう言葉が出てくると身が引き締まりますね。

*1:完全なコードは https://go.dev/play/p/Fn48VJfNO9a にある