Posts for: #Code Reading

久しぶりにコードリーティングイベントに参加

#event  #code reading  #network  久しぶりにコードリーティングイベントに参加

今日のバドミントン練習はメイビス2で壁当てを15分した。勉強会帰りで疲れていたせいか、夜遅くのせいか、あまりカラダが動かなかった。日付が変わってから 中学校体育館の12月予約 で4つ抽選申し込みをしていたが、すべて落選していた。2ヶ月続けてすべて落選したことからそうそう予約は取れないことがわかってきた。

昼間は昨日の続きで mongodb のトランザクション導入のマージリクエストをレビューしてもらって、テスト環境へデプロイして検証していた。id 連携のシステム間連携において意図した振る舞いにならなくてその調査をしていた。チーム勉強会で mongodb のトランザクション周りのいろいろをメンバーに共有した。17時前にお仕事を終えて定期歯科検診へ行ってきた。前回対応してくれたスタッフさんで「また少し痩せました？」と聞かれた。8月からだとほとんど変わっていないと思うが、今週は普段より多く運動できているのでその影響もあるのかもしれない。30分ほどですんなり終わった。

コードリーティング

歯医者を終えてから KOBE.go #7 - コードリーディング会 へ行ってきた。移転したハックバーへ行くのも初めて。三ノ宮駅から10分ほど歩いた場所の、こじんまりしたバーだった。10人程度入ったらいっぱいかな。おそらく集客や家賃などを考えたら妥当なサイズと立地なのだと推測する。いまは水-日の18-23時、月・火がお休みという営業時間らしい。私が着いたときはカウンターが埋まっていたのでテーブル席で発表を聞きながらコメントしたりしていた。私以外の参加者の大半は学生さん、みんな20代の方ばかりだったと思う。kyoto.go で発表したりしていたせいか、kobe.go のスタッフさんにも名前を覚えてもらえていた。若い人がコミュニティを運営しているのはよいことだと私は考えている。年寄りの役割としてなにかしらコンテンツを提供することで協力できればと思う。

コードリーティングはおくたにさんという方が実装している gomoqt という Media over QUIC (MOQ) のサーバー／クライアントを題材とした。京都大学の学生さんで学生起業しているのかな？音声配信サービスをやりたいから moq ライブラリを開発していると話されていて、プロトコルを勉強して自前でサーバー／クライアントのライブラリを実装しようとするの、すごいなと思って聞いていた。quic のライブラリを使ってサーバー／クライアントを実装しているようにみえた。ソケット (トランスポート層) より上のレイヤーを実装すればよいならそんなに難しくはない。

私が想定するコードリーティングのイベントではなかったものの、参加者は誰も moq プロトコルを知らないので moq の背景や現状、プロトコル仕様を共有するようなイベントになっていた。それはそれで私は知らないことばかりなのでへーと思いながら聞いていた。21時半頃にはイベントも終わり、イベント告知や雑談モードになっていって、若い人たちの中におっさんがいても迷惑かなと22時前には退出した。帰る前にワンドリンク (Go という名前の柑橘系カクテル) の料金として700円を支払う。個人的にお酒を飲みながらの勉強会はあまり好きではない。気分や雰囲気でぐだぐだになる印象があって学ぶときは学び、終わってから飲みに行って雑談するといった切り替えが私は好み。バーで勉強会をするという雰囲気もあまり馴染めない。単純に狭いし暗いし椅子よくないし作業に集中しにくいという所感かな。

echo のミドルウェア関数のスタイル

#go  #design  #code reading 

1時に寝て何度か起きて6時半に起きた。起きてから軽く部屋の掃除をした。

echo のミドルウェア開発

go の api サーバーの開発に echo という定番のフレームワークを使っている。少し前にメンバーに認証の処理をミドルウェアとして実装してもらった。いま認可の仕組みもミドルウェアで実装しようと、いくつかソースコードを読んでいて、echo のフレームワークが提供しているミドルウェアの関数名や config には共通点があることに気付いた。echo middleware によると、20個ぐらいのミドルウェアが提供されている。例えば、適当にそのうちの3つほどを取り出すが XxxWithConfig という命名規則で config を受けとって echo.MiddlewareFunc を返すというインターフェースになっている。

func HTTPSRedirectWithConfig(config RedirectConfig) echo.MiddlewareFunc
func LoggerWithConfig(config LoggerConfig) echo.MiddlewareFunc
func BodyDumpWithConfig(config BodyDumpConfig) echo.MiddlewareFunc

また config の中身をみていると、ミドルウェアの処理に必要な関数を渡すような設計になっている。複数のミドルウェアにとって共通なのは、ミドルウェアの処理を迂回する条件を実装するため middleware.Skipper という型が次のように型で定義されている。

e.Use(middleware.BasicAuthWithConfig(middleware.BasicAuthConfig{
	Skipper: func (c echo.Context) bool {
		// Skipper defines a function to skip middleware.
    },
	Validator: func(string, string, echo.Context) (bool, error) {
		// Validator is a function to validate BasicAuth credentials.
		// Required.
    },
	Realm: "Restricted",
}))

典型的なミドルウェアは次のように実装する。最初に Skipper を呼び出して処理の有無を確認する。

return func(next echo.HandlerFunc) echo.HandlerFunc {
	return func(c echo.Context) error {
		if config.Skipper(c) {
			return next(c)
		}

        // TODO: ミドルウェア本体の処理

		return next(c)
    }
}

認証のミドルウェアを実装してもらったときに、私がここまでみていなかったなということに気付いて、既存のミドルウェアを echo のそれと同じスタイルにあわせるようにリファクタリングした。自分でソースコードを読んでいるとコードレビューで気付かなかったことに気付くことが多い。自分がコードを書いているときと、コードレビューをしているときでなにかしら視点が違う。

コードリーディングの成果

#code reading 

22時に寝て4時に起きて1時間ほどだらだらしていて8時に起きた。生活のリズムが少しズレてきてしまっている。

最後のコードリーディング

先週からコードリーディングの勉強会をやっていて今日が最後。今日の対象のプログラムは windows サーバーで動く c++ のコードなので私はどちらも素人であまりよく分からない。上長の判断で別チームのベテランの開発者に来てもらうとよいとアドバイスを受けてお願いして来てもらった。これは本当によかった。実装されたコードだけではなく、設計を見直した方がよい視点なども指摘してもらって、もう少し時間をかけてこの windows プログラムを改修した方がよいと私は判断した。windows サーバーをクラッシュさせてしまうリスクのあるサービスにフックして実行されるコードを書いているので、windows サーバーの振る舞いや異常系処理の経験がないと潜在的にリスクのあるコードを動かしてしまう。web のアプリケーションなら多少のバグは後で直せばよいけど、os をクラッシュさせてしまうものは慎重にレビューした方がよいように思えた。次回の定例で話題にあげて課題を掘り下げようと思う。結論としてはコードリーディングしてよかったという話し。

今年はしばらく svelte に注目

#java  #frontend  #tech selection  #code reading 

1時に寝て7時に起きた。なんか朝うまく起きれなくなってきた。なんでだろう？

svelte アプリの開発に着手

12月の1週間分ぐらいの工数をかけて行っていた フロントエンドの技術選定 の意志決定をした、というよりはしてもらった。私は調査結果をまとめ、react を選択しても svelte を選択しても開発視点ではどちらも同じという判断を下した。あとはお手伝い先の会社にとってどちらの技術に取り組みたいかという視点しかないなと考えて CTO に最終決断を委ねた。その結果 svelte を採用することに決まった。この調査や意志決定についていずれテックブログに書きたい。私がどのぐらい開発に参加するかはまだ未定だけど、初期のリポジトリの整理ぐらいはしておこうと svelte アプリ開発に着手した。初めて関わる技術はなんにせよおもしろい。お仕事で学びがあれば個人でもなにかしら svelte アプリを作ってみたい。

java の ldap クライアント

昨日のコードリーディングの続き。いま使っているライブラリは Apache Directory LDAP API というものだけど、このライブラリの設計があまりイケてない。古い java の考え方で設計されているライブラリのような印象を受けた。他にも java の ldap クライアントはないのかな？と調べたら so でちょうど議論されていた。

この so によると、UnboundID LDAP SDK for Java がベストアンサーになっている。また機会があれば触ってみようかなと思った。

今週は日銀会合に注目

#event  #economy  #code reading 

2時に寝て7時半に起きた。ちょっと生活が乱れ気味。

コードリーディングの準備

tenntenn さんの コードリーディングをしよう #tennconn のやり方を参考に、コードリーディングの勉強会を行うことにした。ある4つのプログラムがあって実績もあるという話しなので基本的には既存のコードがどのように動いているのかをメンバーみんなで確認しておこうといったもの。その段取りを決めたり、日程のスケジュールを調整したり、基本的にはイベント当日にソースを読むようにして準備の負担を少なくする一方、私が一番既存のコードを知らないので事前にソースを読んでおこうとリポジトリを眺めていた。

インフレ勉強会

エンジニアのためのインフレ研究会 #2 に参加した。この火曜日・水曜日の2日間に渡って開催される日銀会合に注目が集まっているという話題があった。議論に揉めたりしなかったら正午前に会合の結果がすぐ公表されるが、政策変更があるときは発表が遅れる傾向にあって発表時間が早い・遅いでも結果を予測して為替などが動くらしい。後藤さんの記事でも同じようなことが書いてあった。これまで日銀会合なんて気にしたことはなかったけど、政策変更の可能性があるかも？と言われるとへーと思って注目してみようと思う。こういう関心をもつ機会が増えると経済を学ぶきっかけになるかもしれない。

BizPy 再始動

#python  #bizpy  #harassment  #code reading  BizPy 再始動

昨日は晩ご飯食べてからのんびりしていた。寝て起きての繰り返しだったので何時に寝たのかよくわからない。夜、本を読もうと思っていたのにダラダラ過ごしてしまった。朝は7時半に起きた。朝起きたら Python で Unicode 正規化 NFC/NFD の文字列を扱う がはてブでホットエントリ化してた。昨日、書評を書いたからその記事かと期待したけど、なぜか2年ほど前に書いた古い記事だった。なんかがっかり。そして、その理由は全くわからない。1日経って夜の時点ではてブが82個ついている。昔は10個もついたら嬉しかったものだけど、いまは100個ぐらいついてもなんとも思わない。

fin-pyコードリーディング会に発表準備

fin-pyコードリーディング会#4 に参加することにした。過去にオブジェクトストレージの開発に関わっていたからデータストアやストレージに関することは興味がある。たまたまツールの store.py を題材にしていたので読んでしまった。簡単にコードを読んで気になったところをイベントの hackmd に記載した。やっていることの詳細をよくわかっていないので、コードレビューみたいになってしまった。

BizPy のコミュニティ活動を再開

前にやってたお仕事がうまくいかなくて他のことに時間を費やす余裕がなくてお休みしてた。本当はもっと早く再開してもよかったんだけど、新しいことに挑戦しているときにあまり他のことに注意を取られたくないという考えもあって少し保留していた。新しいことへの活動も一段落して方向性や展望もみえてきたので BizPy も再開することにした。ちょうど Slack のインテグレーションを調べようと思ったところだったので弾みを付ける意図でも都合がよい。複数の意味でタイミングがよかった。また参加者が戻ってきてくれると嬉しい。

プロコンの続き

ネットで話題になったせいか、当事者同士で話し合う場が設けられたという公式発表が行われた。

これ以上、外野がとやかく言う必要はないと思うけど、一方で立場の強い人が有利になってしまうため、運営はハラスメント行為を行った審査員へ然るべき措置をすべきといった意見もみられた。一理あるかもしれないが、そこまでするほどの問題かというのは個人的に思う。タイムラインを眺めていると、ハラスメントを問題視する人は、その背景や経緯や意図はすべて横に置いておいてハラスメント的言動や態度を糾弾する。この人たちと背景も考慮して整理しようとする人たちとは全く議論が噛み合わない。ハラスメントは絶対許すまじという社会の変化や誤った人への行き過ぎたキャンセルカルチャーに私はやや圧倒される。

そう思っていると、私のタイムラインでは「まさかりを投げる」という表現そのものや行為のハラスメントの是非の議論も巻き起こっていた。あまり最近はまさかりを投げるという表現は見かけないんだけど、「マウント禁止」というのをちょくちょくみかける。ハラスメントと根っこは同じで悪気の有無に関係なく発信側が責めを負うようになったんだなと感じる。