一開発者としてコードを書く日々

2024-08-07 (Wed.)
#programming 

目次

久しぶりに実装に集中した翌日

昨日に引き続き、日中コードを書いて、晩ごはんを食べた後にまたコードを書き始めて、翌1時半ぐらいまで書いていた。昼間はどうしても他メンバーの進捗をみたり、質問を受けたりするから割り込みで作業を中断されがち。夜は割り込みが入らないことがわかっているからコードを書くことに集中さえできれば区切りのよいところまで一気に書ける。いままで夜に運動していた時間をしばらくはコードを書くことに割く。いま私がボトルネックになりそうな課題を抱えているのでそこを早めに解消しておきたい。

一開発者としてコードを書く

2024-08-06 (Tue.)
#programming 

目次

久しぶりに実装に集中

8時半から20時半までコードを書いて、気分転換に買いものへ行ってきて、22時から仕様変更した内容に関するドキュメントを書いて24時までお仕事をしていた。プロジェクトマネージャーを移行 して開発者に戻ったことにより、心理的にコードを書くことに集中しやすくなった。1年半ほど開発者から離れていたことの、勘どころのようなものも徐々に取り戻していく。運動と一緒でコードを集中して書いていると嫌なことを忘れられてよい。コードを書くことも私にとっては瞑想に近いものになっている。

サーバーの拡張とフックポイント

2024-08-05 (Mon.)
#go  #design  #economy  #investing 

目次

今日は東京株式市場の歴史的な急落もあっていろいろ経済ニュースを読んでいた。

echo の Custom Binding

echo で開発していて気に入っているところの1つに、サーバーサイドの、ここをカスタマイズしたいという箇所にちゃんと拡張するためのフックが用意されているというのがある。例えば、リクエストデータとサーバー内部で使う構造体を紐付ける bind 処理もデフォルトの仕組みを拡張する Custom Binding が提供されている。

Echo 構造体の値に Binder というフィールドがあり、カスタマイズしたい処理を実装した Binder インターフェースの値をセットする。

e := echo.New()
e.Binder = binder.New()

Binder はリクエスト構造体の値と echo.Context の値を受け取る Bind() メソッドを実装する。基本的には echo.DefaultBinder を適用した後にカスタマイズしたい bind 処理を実装すればよいと思う。

type Binder struct{}

func (b *Binder) Bind(i any, c echo.Context) error {
	defaultBinder := new(echo.DefaultBinder)
	if err := defaultBinder.Bind(i, c); err != nil {
		return err
	}
	switch req := i.(type) {
	case *myRequest:
		if err := req.BindSomething(c); err != nil {
			return err
		}
	}
	return nil
}

func New() *Binder {
	return &Binder{}
}

bind 処理をどう実装するかはいろいろやり方があると思うが、echo.Context の値を渡せるので request 構造体にその実装を隠蔽するというのもいいんじゃないかと思う。

type myRequest struct {
}

func (r *myRequest) UnmarshalJSON(data []byte) error {
	type Alias myRequest 
	if err := json.Unmarshal(data, (*Alias)(r)); err != nil {
		return fmt.Errorf("failed to unmarshal ids request: %s", data)
	}
    // implement custom validation
	return nil
}

func (r *myRequest) BindSomething(c echo.Context) error {
    // implement custom binding
    return nil
}

日経平均株価の歴史的な急落

金曜日から2日連続 で株価指数が 5% 超も下落するのは世界的にも珍しいらしい。

金曜日に史上2番目の下落幅という見出しでメディアでは煽られていて、下落幅と下落率は違うからそんな不安に感じなくてよいと楽観していたら、今日は史上2番目の下落率 (-12.40%) となった。さらにストップ安になっている銘柄が相次いでいるから実体はもっと悪いと考えられるとのこと。一方でリーマンショックのような、金融機関が破綻しているような状況でもなく、実体経済が傷んでないのに売りが売りを呼ぶ急落になっているので今後どうなるのかはよく分からない。明日も下がるのか、反発するのか、誰にもわからない (素人はしばらく何もしない方がよい) 。注目していた任天堂の株価も -16.53% と日経平均株価以上に急落している。これだけ落ちると、信用取引の追証が2営業日以内となるため、任天堂は明後日「投げ売り」されてもう少し下がる可能性もあるかもしれない。いずれにしても、私は今週いっぱいぐらいかけて空売りの返済をしていく。買うときも売るときも一度に行うのではなく、タイミングや数量を分割してならしていく。

株価の急落について私の記憶にあるのは、2016年の米大統領選挙でトランプ氏が初当選したとき、2020年にコロナが流行り始めたときを思い出した。たまたまだけど、4年に1回は急落がやってきている。2016年も2020年もとくになにもせず私は見守っていただけだった。しかし、今回は事前にポートフォリオを見直したり、空売りでリスクヘッジしていたりと急落の場面にも対応できた。以前よりは経済の背景を学んで資産運用の行動に反映できるようになってきた。これは経営においてもよいことだと思う。

モルックというマイナーなスポーツ

2024-08-04 (Sun.)
#community  #communication 

目次

今日は運動というほど動いていないけど、モルックへ出掛けて日向で十分に汗をかいた感じ。

モルック談義

line のオープンチャット で仲良くなった方から磯上公園で モルック をやるのでよかったらどうぞとお誘いをいただいた。日曜日のお昼で暑そうだから少し躊躇したものの、モルックというスポーツ自体を知らなかったので関心があって参加してきた。結果的にはこの予定がなかったらだらだらしていたなと思うと外へ出るきっかけを作ってくれたのでよかったかもしれない。参加者は私を含めて5人。うち2人はバドミントンに来られた方で知っていて、もう2人は初めて会う方だった。地元の知り合いを増やしていくことは長い目でみてよいことかもしれない。12時半に集まって16時前に解散した。モルックをやっていたのは正味1時間程度かな？どちらかといえば雑談していた時間の方が多かったと思う。ちょっとだらだら雑談し過ぎた感はあった。以前のオフ会 に参加したときも思ったが、お互いによく知らない人たちの集まりをするときは終わりの時間を最初に決めておくというのは大事だと思う。雑談時間を設けることはよいが、いつになったら終わるのか (帰れるのか) わからない空気感はよくない。今回も雑談時間に1人だけずっと喋り続ける人がいる。よく知らない人たちの中でファシリテーションして、みんなが話せるように調整すると喜ばれるかもしれない。

モルックを初めてやってみた所感。モルックのルール を一読して2-3回ゲームをやればすぐ覚えられる。投げる木の棒 (モルック) と倒す木の棒 (スキットル) と得点ボードがあればできる。DIY で自作してもよいかもしれない。特定のピンを狙って木の棒を投げるのが意外と難しかったのと、得点の積み上げに戦略性や投げる順番も関わってくるのでゲーム要素としてもおもしろかった。狙ってピンに当てるコントロールが大事なのはそうだけど、初心者でも十分に楽しめる要素はある。場所は 10m 四方程のスペースがあればよい。体力はいらないから老若男女でも楽しめる。運動にはあまりならない。1ゲームを5人でやって15分程度で終わるのでキャンプやバーベキューの隙間時間などにやるのもよさそうに思えた。なにかの機会でまた試してみるかもしれない。

mongodb も一応は外部結合できる

2024-08-03 (Sat.)
#mongodb  #design  #health 

目次

今日は出張中にたまっていた日記をまとめて書いていた。昨日筋トレしたから運動はおやすみ。

mongodb における外部結合

出張中のふりかえりやプロジェクトマネジメントの合間に mongodb の $lookup (aggregation) 機能を調査していた。一言で言えば、rdbms で言うところの外部結合 (join) を mongodb で実現する機能と言える。しかし、aggregation の機能として実装されていることから rdbms の外部結合とはパフォーマンスの側面で大きく違うのでは？と推測する。mongodb のような kvs では基本的に外部結合のようなことは行わず、結合済みのコレクションを定義するやり方がプラクティスとされる。一方で整合性を保証するには外部結合は有効なデザインパターンの1つなので使いたい場面があってもおかしくない。実際に mongodb に $lookup が実装されているのだから、そのニーズは大きいのだと思われる。

ちょうどいまやっている開発でその要件があったので mongo-go-driver の次のチュートリアルをみながら実装してみた。

例えば、次のような2つのコレクションがある。

type Group struct {
	ID          string      `bson:"_id"`
	Name        string      `bson:"name"`
	UpdatedAt   time.Time   `bson:"updatedAt"`
}

type MyData struct {
	ID           string    `bson:"_id"`
	GroupID      string    `bson:"groupID"`
	RegisteredAt time.Time `bson:"registeredAt"`
}

MyData の GroupID フィールドが Group コレクションの ID を保持して外部参照している。MyData コレクションに対する aggregate に渡すパラメーターとして pipeline を渡す。

myPipeline = mongo.Pipeline{
	{{
		Key: "$lookup", Value: bson.D{
			{Key: "from", Value: "group"},
			{Key: "localField", Value: "groupID"},
			{Key: "foreignField", Value: "_id"},
			{Key: "as", Value: "foreignGroup"},
		},
	}},
	{{
		Key: "$unwind", Value: bson.D{
			{Key: "path", Value: "$foreignGroup"},
			{Key: "preserveNullAndEmptyArrays", Value: false},
		},
	}},
}

$lookup の操作の後に $unwind で配列を flatten する処理がセットになる。result set にマッピングするためには flatten が必要になるのだと推測する。aggregate() を呼び出すと cursor が返ってきて、その cursor に外部結合される値の配列を渡すことで result set を取得できる。デバッグはややこしいし、コード上もちょっとわかりにくいけど、これは mongodb のお作法だと割り切ってユーティリティ化してしまえばよいものだと思う。

type joinedMyData struct {
	ID           string    `bson:"_id"`
	Group        Group     `bson:"foreignGroup"`
	RegisteredAt time.Time `bson:"registeredAt"`
}
...

cursor, err := collection.Aggregate(ctx, myPipeline)
if err != nil {
	return nil, err
}
var joined []joinedMember
if err = cursor.All(ctx, &joined); err != nil {
	return nil, err
}

また時間があるときにある程度のデータ量でどのぐらいの負荷に対してパフォーマンスが出るのかを測ってみたい。

ストレッチ

昨日1週間ぶりに筋トレをしたせいか、今朝から筋肉痛になっていてカラダが痛い。その影響もあって今日の開脚幅は開始前146cmで、ストレッチ後152cmとカラダが硬かった。足も腰も肩周りも全身にわたって軽い筋肉痛だった。それだけよい感じの負荷をかけて筋トレができていたと言えるのかもしれない。あちこち筋肉痛はあったものの、ストレッチを受けていての辛さのようなものは感じなかった。ちょうどよい感じにほぐされているような印象を受けた。もしかしたらトレーナーさんが気を遣っていつもよりは弱めにストレッチしてくれたのかもしれない。トレーナーさんが立候補していた店長選挙は落選してしまったらしい。もし店長になったらよそのお店へ転勤になって担当者が変わってしまうのかなとも思っていた。トレーナーさんは私が通っているお店の副店長を務める方向で調整しているらしい。待遇をあげていくにはキャリアアップをしていかないといけないといった背景もあるようにみえる。

自分を騙す言い訳

2024-08-02 (Fri.)
#founding  #postmortem  #motivation  #exercise  #economy  #investing 

目次

今日の運動はジム筋トレ,縄跳び(両足跳),散歩,ジョギング,ハンドグリップ,ダンベルをした。統計を 運動の記録 と 筋トレの記録 にまとめる。ジョギングの後に 右股関節の改善体操 をした。どこかのタイミングで今月からは運動を監視するのをやめて別のことへ移行していく。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

  • お手伝い先のプロジェクト近況

今週の出張でお手伝い先でのふりかえりや進捗報告の要旨などを共有しつつ、うちの会社の課題管理ビジネスへの取り組みについて雑談したりした。ここ2-3ヶ月は私がバテてしまい、休日もオフィスへ足を運んでいるものの、運動したり日記を書いたり趣味の調べものをしたりと、のんびり過ごしていることが多い。課題管理ビジネスへの集中力が途切れてしまった。はらさんも上半期は自分のプロダクト開発などをやろうと考えていたものの、あまり想定したように進捗せず、下半期は他社のお仕事のお手伝いで忙しくなってくるらしい。はらさんは よりひろいフロントエンド を作ったり、最近は Apple Vision Pro のアプリ開発をされている。私と似たような状況だなと話しを聞いていて次のようなことを話された。

歳をとると自分を騙すのがうまくなる。うまくいっていない言い訳を、もっともらしく、自分で受けいられるように作ってしまう。
危機感をもたなくなる。うまくいっていないことや結果が出ていないことを直視しないといけない

まさに私にも当てはまることでこの2-3ヶ月の自分をみているみたいだ。私自身、今年はほとんど休まず会社のことばかりやってきたから、たまにはだらだらする時期があってもいいのかな程度に自分への言い訳をしていた。はらさんとは隔週で雑談する機会を設けている。こういう話しをするだけでもこの雑談には意味がある。これが自分ひとりだと、自分への言い訳をして、何もしないままどんどん時が過ぎ去っていくだけだったと思う。誰だって自分のネガティブな側面を直視するのはつらいから無意識に目を背けてしまう。信頼できる人たちからそういうことを指摘してもらって自身を省みるきっかけになればと思う。

いそがみの筋トレ

前回の所感 。19時過ぎから出掛けて、トレーニング器機の待ち時間などもあって21時前まで筋トレしてきた。出張中ずっと運動していなかったので行く前はやや面倒に感じていたが、やりきったら達成感があって行ってよかったと思えた。週2-3日のペースで筋トレや運動を継続していくのが心身ともによさそう。慣れてきたモノへのやる気はやり始めてから出てくる。なによりも大事なのはやり始めること。

体育館のトレーニングルーム通いも気付いたら5回目になった。少しずつ成果は出ていて、器機によっては重りをあげたり回数を増やしたりできるようになったのもある。そして終わってから外で縄跳びをして、ハンドグリップをしながら帰ってきた。これも筋トレした後だとややカラダがだるいのもあるけど、跳び始めてしまえば出来てしまう。毎日の運動は時間を取られて他のことが疎かになってしまった現状があるため、今後は週2-3日の筋トレの機会に集中して運動していくよう、日々の生活を変えていく。

日経平均株価の急落

fin-py という金融関係者向けのコミュニティがあり、数年前から参加している。何人か仲のよいメンバーもいるし うちの会社の顧問税理士さん もそのメンバーの1人でもある。老後の心配が出てくるのか、日々の生活が安定すると将来の生活に目を向ける余裕が出てくるのか、人生においてお金の話しは歳をとってから関心が出てくる話題の1つだと思う。

下落幅は1987年のブラックマンデー以来、史上2番目らしい。一方で下落率でいうと 5.81% で史上30番目になる。2008年のリーマンショックでは下落率が11.41%と、この倍以上であったことからそこまで不安を煽る状況でもないが、メディアは不安を煽った方がニュースバリューになるからこういう見出しになるのは仕方ないらしい。米国の経済事情だったり、為替の円高転換などの要因で日本株が急落している。fin-py で時事のニュースなどをやり取りしていたのもあり、為替の円高転換は Exclusive: BOJ to weigh rate hike next week, detail plan to halve bond buying, sources say の記事が出た7月24日ぐらいから注目していた。私の投資のポートフォリオも徐々に含み益の保有株を売ったりして、円高になって株価が下がってもよいように準備していた。今日の急落にも備えていたから投資資金の50%ほどは含み益の状態で売却できた。今日の取引終了後も為替は円高に進んでいるし、日経平均先物も悪化しているので月曜日もさらに下がりそうにみえる。これでしばらく為替は円高へ進んでいくのかな。その状況を確認しながら追加でポートフォリオを変更してもよいかもしれない。しばらく為替や株価の変動が大きいだろうから落ち着くまで見守ろうと思う。fin-py で日々の経済のニュースなどを見聞きしているうちにその先の展望を推測して対策を講じたり準備したりできるようになってきた。これまでは起こった状況で気付いて含み損になってしまって何もしていなかった。急な変動が起こりそうな気配や背景を知っていると、準備ができていて、ポートフォリオを機動的に変える決断を早くできる。

たまたまこんな日に 任天堂 2025年3⽉期第1四半期 決算発表 があった。もともと2025年3月期の通期の業績は前期よりも悪くなることが以前からわかっていたのになぜか株価は高止まりしていた。今回の為替の急な円高 (任天堂は海外の売上比率の方が大きいため、円高になると為替差益が減る) と、第1四半期の業績も市場予測よりも悪かった？せいか、月曜日は株価が急落するようにみえる。以前から株価が高過ぎるのと、どこかで為替の円高転換もあるだろうと、2月頃から少しずつ空売りしていた。最悪の時期は任天堂の空売金額が-10%ほどの含み損になっていたものの、(想定したよりも過激な円高がやってきて) 今日の時点で3%ほどの含み益になっている。おそらく月曜日から任天堂の株価は急落すると推測される。

以前 オプトラン という会社について書いた。ここも半導体産業、且つ為替で業績に影響を受ける会社になる。ずっと観察してきたし、ボラティリティが高いのでポートフォリオに入れたり出したりする定番の会社になっている。今日の時点では、おそらく思惑？だけで1711円と株価が急落している。過去の最安値が1420円、年初来最安値が1561円になる。1500-1600円台まで株価が落ちれば2-3年後のために投資していくのによいんじゃないかと注目している。

次開発は開発者として専念

2024-08-01 (Thu.)
#project management  #issue management 

目次

今日も出張戻りで運動はおやすみ。帰ってから運動をする余裕もあったけれど、日銀の追加利上げ決定から為替が円高に動いて、日経平均先物が急落しているのをみかけて、帰りの新幹線内から経済系の関連記事を読んだりしていた。景気が悪化すると経営に影響するから、こういった転換点に敏感になった。

5次開発の要件打ち合わせ

前回の所感 。これまでは2時間をとって要件の発散会議をしてきた。今回は残課題の issue が溜まっていて、まずはそれらを fix してから最低限の機能開発をするといった段取りで進めることを出席者に共有した。そのため、要件を発散させるような話しはほとんどしなかった。主には残課題の共有をしながら、11月頃から最初のお客さん導入を想定して、それまでにやらないといけない要件の機能の再確認を行った。ちょうど2時間ぐらいでおさまった。優先順位なども改めて確認する必要もなさそうに考えている。お手伝い先のプロダクト開発において課題管理が普通になってきたので、特別な確認や打ち合わせをしなくてもどの課題をやらないといけないかは明示されるようになった。これはこれで課題管理の方法論の成果でもある。一方でメンバーからはどの issue を担当すればよいか、開発始めの段階は担当者を割り当ててほしいという意見もあったので、私がいくつか残課題をそれぞれのメンバーに割り振っていった。これも開発が進むうちに、自分が関心のある issue を取ったり、やらないといけないものを自分で割り当てるようになっていけば自律的な開発へ向けてさらに進展していく。

これまでは機能開発を3ヶ月、QA を1ヶ月としてきた。今回は機能開発を2ヶ月、テスト／QA 期間を2ヶ月とる。自動テストや QA 工数の削減のための取り組みに時間を割いて、人間が QA 検証する工数を削減していく。私自身やらないといけない残課題がいくつかあるので早め早めに fix していって集中力をもって取り組む必要がある。今回はマネージャー業をメンバーに移行した分、久しぶりに開発に専念してコードを書ければいいなとも思う。どうなるかな。

プロジェクトマネージャーの引き継ぎ

2024-07-31 (Wed.)
#project management 

目次

今日は出張中で夕方から突発的な嵐がきてホテルに籠もっていた。21時半には過ぎ去ってそれから運動することもできたけど、なんとなく気がのらなくて晩ごはんがてら飲み歩いてた。

プロジェクトの進捗報告

出張したときの月例報告の18回目。前回の進捗報告はこちら 。今回は4次開発のふりかえりを淡々として、うまくいかなかったところなどもそのまま報告した。あまり経営陣からはこれといって責任を追及する指摘などはなかった。まだお客さん先へ提供していないからそれほど深刻な状況でもないのだと推測する。あとはずっと開発をやってきたから私に対する信頼度も上がっているのかもしれない。今回の開発期間において計画通りに進まなかったという失敗をしたが、この失敗を引きずるつもりもない。次の開発へ向けて名誉挽回の取り組みはしていく。

それと同時に次の開発は、うちのチームのメンバーにプロジェクトマネージャーを移行することを提案して了承してもらった。私はまた開発者の立場でチームに貢献する。これもいずれはお手伝い先の社員さんがプロダクト開発をリードしていく必要があるし、チームにおいて機動的にマネージャーという役割を変えることもよいことだと私は考えている。私が関わっている状態で徐々に移行していくのが、チームの混乱もなくてよいと思う。もしかしたらフルタイムで私がこのプロダクト開発に取り組むのは次の4ヶ月が最後になるかもしれない。開発がマンネリ化してきた雰囲気もあったので、新しいマネージャーで少し新鮮な気持ちが出てくればいいなとも思う。

プロジェクトマネージャーを移行して、今後は進捗報告も新しいマネージャーから行うのであれば、私が東京出張しなくてもよい (お手伝い先からみたら経費削減) のではないか？と考えて、その是非も聞いてみた。予想に反して、もうしばらくは私に進捗報告してほしいとのこと。新しいマネージャーにも一緒に参加してもらうのもいいかもしれないとのこと。他のプロジェクトは進捗報告をしていない？らしく、月に1回ぐらいプロジェクトの状況を知れるのは先方の役に立っているといった話しもあって、それはそれで私も嬉しかった。最低もう4ヶ月は毎月の東京出張が続く。

落ち着いた開発とふりかえり

2024-07-30 (Tue.)
#issue management  #project management  #postmortem  #drinking 

目次

今日は出張中で飲み会があったので運動はおやすみした。

4次開発の大きなふりかえり

前回の大きなふりかえり 。約4ヶ月の開発フェーズが終わってからの大きなふりかえり。もう4回目なのでメンバーも慣れてきたし、過去の知見もたまってきた。そして、私がいまあまり調子がよくないのもあってなにか目新しさがなくなってきたところでもある。今回の開発は2つの大きな失敗があった。

  • 想定していた開発機能を1つ落とした
  • QA 検証を網羅的に進めることができなかった

これらは私のマネジメントの失敗になる。これまでうまく進み過ぎていたと言えるのかもしれない。プロジェクトマネジメントは毎回うまくいくとは限らない。スクラムガイドにもある見積もりより経験主義の重要性を認識する開発期間でもあった。これまでの順調な進捗に、私自身マネジメントの驕りがあったのだとも思う。次の開発フェーズでまた気を引き締めてプロダクトの品質を担保していく。

いつも通り gitlab の統計情報を眺めながら定例イベントのふりかえりなどもやっていった。UI 周りのふりかえりを口頭での報告や文章で表現するのが難しくなってきたという意見があった。UI は画面の操作をみないと本当の意味で理解するのは難しい。テックブログを読む会も、自分が読みたい記事をすぐにみつけるのが難しいから事前に読みたい記事を探しておくといった「準備」をするメンバーもいる。実は私もたまにその準備をしているのでその気持ちはわかる。記事を探すという作業には一定の時間を取られるという事実がわかってきた。

記事を読んだ後に軽く雑談する時間があってもよいのではないかという意見もあった。これはこれであってもよいとは思う。ふりかえりは隔週でもよいが、メンバー間での確認事項は毎週やった方がよいのではないか？という意見も出た。これは話す必要があるときにハドルすればいいでしょうというところで一旦は見送った。みんなで集まる会議時間はコストが大きいので慎重に判断する。1on1 の隔週30分もそろそろ調整や見直しがあるかな？とも考えていたけど、逆にメンバーからはなんやかんやで30分話すことはあるからこのまま継続した方がよいといった意見も出ていた。

開発のやり方がだいぶ定着してきて、大きなふりかえりも1つの型ができて落ち着いてきた感じはある。よくもわるくも。

同期との飲み会

たまたま新卒で入った会社の同期から連絡がきて、関西で働いている同期が2年ほど単身赴任で東京出張になるらしく、久しぶりなので飲みにいこうという話しになった。本当は4人で飲む予定だったのが、1人がお仕事でドタキャンになって3人で飲んできた。10年以上会っていなかった同期だから近況を話すだけでもおもしろかった。今日会った3人に見た目は昔とあまり変わってなかった。私は体脂肪コントロールした後でよかった。ある同期は課長になっていて、単身赴任である省庁へ出向になった。外からみたら国家公務員やね。本当は話したらダメなんだろうけど、同期というよしみもあって飲みながらいろいろと話しを聞いてた。ここには書けないが、おもしろかった。飲み過ぎた。

私は最初の会社を3年でやめたものの、飲んだ同期たちはもう20年以上、1つの会社で働いているわけで価値観もだいぶ違うだろうと思う。同期って本当によいもので、価値観が違っても会社が違っても未だに仲良く気軽に話しができる。私はたまたま新卒で入った会社が大企業のグループ企業だったから100人ほど同期がいて、5つのクラスに分かれて30人ぐらいのクラスで4ヶ月ほど研修を受けた。いまとなってはその頃の同期とはほとんど会わないし、みんながいま何をしているのかも知らない。おそらく半分以上はその会社をやめてしまっていると推測する。やめた同期とも会う機会があれば楽しく話せるとは思う。

api ドキュメント保守の考察

2024-07-29 (Mon.)
#document  #openapi  #ci/cd  #biztrip 

目次

今晩から東京出張なので運動はおやすみ。縄跳びだけもっていく。

api ドキュメントを継続的に保守することへの考察

お手伝い先のプロダクトを1年半以上、継続している。web api の機能もどんどん増えてきて50は超えていると思う。api ドキュメントをビルドするために redocly cli というツールを使っている。次のスクリプトは .gitlab-ci.yml の設定だけど、このぐらいの手間で openapi.yml から1つの html ドキュメントを生成してくれる。この index.html を api サーバーに同梱している。

  before_script:
    - node --version
    - npm --version
    - npm install @redocly/cli@latest
    - npx redocly --version
  script:
    - |+
      npx redocly build-docs schema/openapi.yml \
        --output index.html \
        --theme.openapi.schemaExpansionLevel=10 \
        --theme.openapi.expandResponses=all \
        --theme.openapi.requiredPropsFirst=true \
        --theme.openapi.jsonSampleExpandLevel=10 \
        --theme.openapi.hideLoading=true \
        --theme.openapi.pathInMiddlePanel=true      
    - mkdir -p public
    - mv index.html public/

web api の機能数が少ないときはこれで十分だった。しかし、50を超えてくると yml で api ドキュメントを保守するのが辛くなってくる。xml/yml/json を問わず、サイズの大きいこれらのファイルを保守するのはつらい。人間の能は複数種別の情報を同時処理できるが、一定量を超えた情報量をうまく処理できない。もちろん機能別にファイル分割して管理しているのだけど、それでも openapi.yml のエンドポイントの定義はどんどん増えていく。それがだんだん辛くなってきたのが現状になる。

以前 静的サイトジェネレーター勉強会の手伝い をしたときに slate という markdown で記述できる api ドキュメントツールがあることを教えてもらった。これはいいなとそのとき思ったのだけど、コミット履歴などをみているともう保守モードで活発に開発されていない。oss あるある話しで継続的に開発されていないツールはすぐに廃れるのでいまから採用するには躊躇してしまう。

postman という api プラットフォームがある。昔から api クライアントとして使う開発者も多かったのでツール自体は知っていた。この機会に私も実際に使ってみて評価した。既存の openapi.yml + redocly cli を使っているドキュメント管理と postman との比較をした。

  • postman はドキュメントのバージョン管理ができる
  • postman アプリを api ドキュメントのエディターとして使える
    • テキストの説明欄に markdown を記述できる
    • エクスポートすると json データになる
      • ドキュメントのデータとして yml と大きな違いはないが、エディターで隠蔽されるからドキュメントの保守はやりやすくなる
        • 但し、エディターは postman アプリに依存する
  • postman はリクエスト CLI とレスポンスの対応関係をセットで管理できる
  • ドキュメントの構造や見た目はあまり変わらない

postman そのものは悪くないけど、うちらのいまの開発のワークフローにすぐに適用できる状況でもない。postman の機能を有効に活用できるように開発のやり方を変えないといけない。そうしないと、ドキュメント管理だけに使うには外部サービス依存が大きくて学習コストも高くなってしまう。

別のアプローチとして openapi.yml の編集をテキストファイルで行うのではなく、人間にとって操作しやすいエディター上で行えるようにしたものが stoplight studio になる。ググると評判もよいし、私も実際に使ってみて機能はまさに探していたツールではある。しかし、このツールの先行きも怪しい。これまでデスクトップ版のエディターは無償で提供されていて、いまもアカウント登録すれば無償で使える。しかし、昨年あたりに SmartBear 社 (swagger を作ってた会社ね) に買収されている。おそらく swagger editor の移行先を探していてちょうど都合がよいのだと思う。SmartBear 社は過去の openapi 移行時のゴダゴダがあって印象がよくないし、ビジネス寄りの会社になるので将来的に stoplight studio を無償で使い続けられるかどうかにも懸念がある。

今回は調査したどのツールにも懸念があって採用を見送ることにした。api ドキュメントを書くツールを探すのは難しい。

寝台特急

久しぶりの寝台特急。11時25分頃に乗車券を使って JR 三ノ宮駅の改札を通過しようとするとエラーになった。30日から有効とは書いてあるものの、以前は通過できていた気がしたので駅員さんに聞いたら30分前から通れるはずとの。その後11時38分には改札を通れた。これまで改札でエラーになったことがなかったのは11時30分をまわってからだったんだと初めて気付いた。運が悪いことに0時11分発の予定が32分遅延した。調子の悪いときはこんなもので段取りもうまくいかない。最終的に東京駅には15分ほど遅れになった。

今日は普通のB寝台シングルを予約した。下側の狭い部屋でゆっくり寝ることにした。乗車後10分ほどして車掌さんが切符確認にきた。これもわかっているから扉を開けて切符も用意して待ってた。寝台特急は薄い布団しかついていないから冬はちょっと寒い。逆に夏はエアコンが効いているし薄い布団で問題ない。寝台特急は暖かい時期に乗るのがよさそうだということもわかってきた。

休日のオフィス工事

2024-07-28 (Sun.)
#writing  #founding 

目次

今日の運動は腹筋ローラー,腕立てをした。統計を 運動の記録 にまとめる。

日記と筋トレ／運動についての考察

お正月にたまたまみた番組をきっかけに筋トレや運動を始めて半年ほどで 24kg ほど体重を削減できた。日記に書くことで継続を促し、継続することでこれほど成果が出るとは、書き始めたときには想定していなかった。

日記はほぼ毎日書くのでここに筋トレのやった回数を書いていくのがやらないといけない強制力が働いてよいような気がしてきた。試しに明日からやってみようと思う。

2024-01-01 すぐやる筋トレ

一方でもう十分に体脂肪コントロールができていて筋トレ／運動も習慣化できたと思う。そして、もう毎日やらなくてもよいし、意図的に週2-3日の頻度におとしていく。7月いっぱいで運動の記録を日記に書くのはやめて新しい取り組みに変えようと考えている。私の生活の中で日記を書いているリソースはもはや無視できない割合を占めている。少なくないリソースを費やしているから継続性を保証できているともみなせる。したがって、そのときに継続したい、集中したい対象を日記に書くようにして目的を果たすツールにするのがよいと思うようになってきた。

いま一番、私がどうにかしたいことは住居のリビングの部屋づくりになる。日々の生活は寝室とダイニングさえあれば事足りるからリビングが荷物置き場になってしまっている。片付けが単純に面倒くさいのと、優先度が低いから引っ越してからほとんど放置している。せっかくリビングがあるのにもったいない。リビングに人を呼べる状態にして、知人や友だちを誘って、コミュニティやコワーキングの研究、または居場所づくりのなにかにつなげたい。

line のオープンチャット 経由でバドミントンに来てくれた外部の方が2名になった。これはこれで非 IT のコミュニティをひろげていく取り組みになっている。これまで私は IT 系の勉強会やコミュニティにしか行っていなかったら話す人たちの情報が偏っている。同じ業界の人じゃない人たちの考え方や情報に疎いからバランスを取る上でもいいのかもしれないという気持ちと、単純に面倒という気持ちの両方がある。これから課題管理のプロダクト開発をしてマーケティングしていかないといけないが、当然 IT 業界のみを相手にするよりも、もっと幅広い業界を対象にした方がビジネスとして成功する確率は高くなる。そういった展望の1つにもなるかもしれない。

排煙設備工事

シェアオフィスのフロアの排煙設備がうちの会社が借りている部屋のスペース内にあった (添付画像を参照) 。この状態が消防法違反になっていたらしい。うちのオフィススペース内に排煙設備があるということは、私が不在で入口に鍵をかけていれば、有事の際に排煙設備を利用できないのだから当然と言える。そこでこの排煙設備をうちのオフィススペースから共用廊下へ出すための工事を本日行った。そのためにオフィスを開けないといけないため、私も立ち会いすることになった。とは言っても、だいたい土日もオフィスにいるので休日に排煙設備工事をすること自体はまったく構わないと管理会社へ了承していた。平日にされる方が業務に支障が出るから休日にしてくれるのはむしろありがたい。

8時半頃にオフィスへ行ったらすでに工事業者さんは来られて準備していた。それから近くで様子を伺いながら1時ぐらいまで作業をしていた。なかなか工事が終わらなくて2時間ほど家に帰ってお昼ご飯を食べてから15時前に戻ってきたら終わっていた。