私の2024年を振り返る🔍
はじめに
この記事は著者の 2024 年の活動を振り返って、その年の技術的なトピックだったり自分の活動履歴等を振り返るための備忘録です。(昨年も振り返りしています)
自己紹介
- ゲーム業界に身を置くサーバーサイドエンジニア
- Kotlin/Go/Swift/PHP
- サービス開発が大好きで趣味
- 作るものに合わせて技術を学ぶスタイル
- SNS が大好きで X (Twitter) クライアントを作っていた
- TheWorld, SocialHub
本年についての注意
やや言い訳になってしまう部分なのですが、今年は私的なライブイベントが多く、技術的なトピックについて、あまり活動ができない年でした。以下のブログにて纏めています。
今年の活動
Kotlin Multiplatform Library
今年は ScoialHub の Kotlin Multiplatform 対応をゴリゴリ進めていた年でした。Kotlin Multiplatform は個人的にかなりホットな技術 で、去年からずっとその動向を追っており、自分のマルチ SNS クライアントライブラリである、SocialHub を Kotlin Mutiplatform で再実装したいと考えていました。今年はその実装を一歩前に進ませることができました。
Kotlin Multiplatform といえば、iOS と Android アプリを同時に作ることができる最近流行りのマルチプラットフォームフレームワークです。しかし、自分の思想の一つとして「手で触れる部分は Native で実装すべき」というものがあります。現状 Kotlin Mutiplatform や Flutter、React Native など類似フレームワークは完成度は高くなってきているとはいえ、ネイティブの動きから考えると UI/UX の体験が落ちてしまう問題があり、業務アプリのような工数をかけられないものに対してのみ真に有効であると考えています。
Kotlin Multiplatform ではマルチプラットフォーム対応したライブラリを作成することが、比較的簡単に可能であり、自分はそこに魅力を感じています。もっぱら SNS のクライアントライブラリを Kotlin Multiplatform 対応するのが最近のライフワークになっており、Bluesky をはじめ、Misskey や Mastodon、Tumblr の対応がひとまず完了し、現在は Slack に手を付けています。
それらの SNS の Kotlin Multiplatform ライブラリを使用して、透過的に複数の SNS を扱うことができるクライアントライブラリである PlanetLink も同時に開発中で、これが SocialHub ライブラリを置き換える存在になる予定です。まだ完成には時間がかかる見込みで、SocialHub ユーザーにはお待たせしてしまって申し訳ないですが、大型アップデートまではもうしばらくお待ちいただくことになると思います。
OSS 活動
今年も X (Twitter) でいろいろ騒動があり、他の SNS に引っ越す需要が高まりました。その中で、Bluesky が有力な候補として挙げられ、そこから 自分の OSS ライブラリである kbsky (前述の Kotlin Mutiplatform 対応をした Bluesky のクライアントライブラリ) が徐々に使われはじめました。
このライブラリは自分と、ZonePane さんに向けたものという側面が強く、あまり一般ユースを考えていなかったので、パッケージのデプロイ先も適当で、分かる人だけ使えれば良いやという側面がありました。しかし、それでは駄目になってきたので、重い腰を上げて Java/Kotlin エンジニアとして初めて Maven Central にパッケージをアップロードしました。
kbsky は Bluesky の先進的な OAuth の仕組み (DPoP, PKCE) にも対応したりなど、自分として技術的なチャレンジを多く含むライブラリであり、今年の成果の一つであると言えます。また、issue や pull request も複数の方から頂いており、使われているんだなと実感するとともに、自分のライブラリとして初めてコミュニティに貢献できていることを感じています。
BDD 推薦活動
昨今風当たりの強い E2E テストですが、 自分は E2E テストをいかにしっかり書いて、シナリオベースでプロダクトの回帰テストをすることに非常にモチベーションが高いです。 関わっているプロジェクトの幾つかで BDD を導入して、今年はそれを育てつつちゃんとワークするかを確認していました。
上記で説明している BDD は、かなりツールやその使い方に特化した説明になっているので、こんな説明 BDD を何も説明していないのと同じだ！ と思うかもしれませんが、その感情は間違いではなくあくまでツールとしての導入のところから出発点にしています。
個人的にツールとしての BDD フレームワークを推すかというと、それがドメインを説明するための仕様書になったり、コミュニケーション手段として上位工程に対する資料になるからです。本来は上位工程自体が BDD に入って実践していく必要があるんですが、「じゃあ BDD ってどうするの？」という時に BDD フレームワークから得られる自然言語でのテストは非常にわかりやすい武器になります。
こんな形でユーザーストーリーを書いていけば、それが仕様書になる。という世界観なので、上位工程はわかりやすくコンセンサスを取りやすくなります。自分が開発の現場レベルでの E2E としての BDD を進めるのにはそこに利点があると感じています。上位工程が理解しはじめたタイミングで改めてテストのあり方を考え直す、その道筋が BDD で作ることができると考えています。
キャッチアップと交流
今年は AI エージェントによる AI プロダクトの増加にともなう、技術トレンドの動向には目を光らせています。生成 AI は技術者としては無視はできない存在で、どのように他社で活用しているのかというのは、大事な研究材料の一つです。
今年は、Google Cloud Next Tokyo '24 など、幾つかのイベントを見て回り、インフラ的なサービスの構成の話と生成 AI の実運用の事例について聞きに行きました。個人的な感想ベースでいえば、業務支援系の生成 AI の事例はたんまりあるけど、何かの在り方を変えるようなプロダクトはまだなかなか登場していないという印象。
toC のビジネスを展開する時に、ユーザーのリクエスト毎に生成 AI を動かせるほどの計算能力、または資金がネックになっていると思う。例えば、SNS で言えば、ユーザーの投稿一つ一つについて生成 AI で何らかの分析とかはできると思うけど、結局それに見合うバリューって何が出せるの？ みたいな話で詰まっている。自分はそこが一つのターニングポイントだと考えているので、そこがいつ来るのかを今後も注視したい。
おわりに
今年はまず、この一年を無事に終えることができたことが自分での何よりの成果です。が、技術的なアウトプットが少ないと感じる年でもありました。毎年同じ締めになりますが、 今年も様々なエンジニアさんのアウトプットに支えられてエンジニア活動が出来たと感じています。 本当にありがとうございます。
Discussion