私が歌川です

@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のルールを無効にするかどうか決めるのも「適応」なんじゃないか。

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

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