人生が整うマウンティング大全

発売前から「マウントフルネス」「マウンティングエクスペリエンス」などキャッチーなフレーズでSNS上で話題を集めていたマウンティング大全、Kindleで買おうかと思っていたのですが、自宅近くのさほど大きくない書店でもビジネス書の新刊コーナーに積まれていたので購入して読んでみました。

…読んでみたのですが、うーん…。個人的にはネタ本の域を出ないかなという感想でした。確かにフフッとなってしまう部分もあり、笑って読むには良いかもしれませんが、ネタ本ならネタ本でもっと思いっきりネタに走っても…という気もしました。

個人的に内容に期待していたのでちょっと残念な気持ちです。事前情報があまりにキャッチーだったので期待しすぎてしまった部分もあるかもしれません。

systemdの思想と機能 Linuxを支えるシステム管理のためのソフトウェアスイート

systemd普段使っているけど何もわからん状態なので近所の書店のポイント2倍デーで購入して冬休みに読んでみました。

タイトルはもとより前書きにも書かれている通り、systemdの具体的な使い方というよりは普段Linuxを使っている人が体系的にsystemdを理解するための本という感じで、対象としてはニッチだとは思うのですが、読者層の設定から内容までコンセプトが明確で、著者の方(Software Designでsystemdの連載をされていたそう)の知見や情熱に裏打ちされた良書だと思います。

systemdの基本的な概念や機能の概要を知ることができたのはもちろんですが、Linuxの様々な機能が今はsystemdで処理されているんだなーということもわかってよかったです。

2023年の振り返り

仕事関係

昨年末から春先まで3ヶ月ほど仕事が超絶忙しく、どうにか区切りがついたと思ったら下半期になって突然ボスがいなくなってしまったり、トラブルが続いたりと、なんだかんだ一年を通じて消耗が激しかったです。

命を削った甲斐もあってか現職4年目にして初めてプロモーションなるものを経験させていただいたり、新たに接点ができた方もいたり、英語での採用面接の機会が増えたりと悪いことばかりでもなかったものの、もう歳なので無理すると再起不能になりかねないので働き方について少し考え直さなくてはと思ったりしました。

また、春頃の話なのですが、スタッフエンジニアの書籍でインタビューを受けさせていただいたりしました。こちらも自分のキャリアを振り返る良い機会になりました。

takezoe.hatenablog.com

あとは3月に米国本社のお偉いさん方、12月には新ボスや海外の同僚が東京オフィスに来ていたので自分も久しぶりにオフィスに顔を出したりしていました。

OSS活動

特に前半は仕事が酷い状態だったのと、その後もモチベーションが上がらずあまりOSS活動はできなかったですが、Trinoにいくつか改善やバグ修正のパッチを投げたり、GitBucketの機能追加をしたりと地道に活動しています。また、Jacksonに初めてPRを出して取り込んでもらえたのも嬉しかったです。

takezoe.hatenablog.com

新しいところではIntelliJプラグインを作ったりもしていました。自分で使う用に作ったものですが、こういうちょっとしたものでも自分で作れるとなかなか便利です。UIのあるものも作れるようになると楽しそうですが、Eclipseプラグインをゴリゴリ作っていた頃の気力はもうないですね…。

takezoe.hatenablog.com

Scalatraについてはついに3.0を正式にリリースすることができました。Scala 3とJakartaに対応したのが目玉でフレームワークの機能的には変わっていませんが、ドキュメントやサンプルを直すのが大変でした。SPAが普及してサーバーサイドはAPIのみというケースが多い昨今、JSON周りはもう少しなんとかしたい気持ちもあるのですが、互換性を持たせつつ改善するのはなかなか難しそうなので非互換でもAPI開発用の新機能を入れてもいいかなという気持ちがあります。

takezoe.hatenablog.com

アーセナル

昨年のシーズン序盤から首位を走り続け、19年ぶりの優勝か!?と期待されたアーセナルでしたが終盤の急失速で結局2位でフィニッシュ、CL出場権は取り戻したものの無念極まりないシーズンになってしまいました…。ベンゲル時代に見慣れたこの光景に「また次のチャンスは10年後かも…」とネガティブ思考になってしまうアーセナルファンはきっと自分だけではなかったはずです。

夏にはハヴァーツ、ライス、ティンバー、ラヤとさらなる大型補強で弱点だった層の薄さを解消し、新シーズンは万全の体制でCLとリーグ優勝に挑むと思いきや、開幕から全然機能しない新システムにトライした挙句ティンバーとパーティーの怪我で早々に頓挫、厚くなったようで実はあまり変わっていない選手層と上位はキープしているものの前半戦から四苦八苦している状況ですので、あまり期待しすぎずに応援したいと思います。

しかしこれまでもサッカー雑誌でアーセナル特集が組まれることは多かったのですが、ここ10年以上は自虐ネタっぽい特集ばかりでしたが、昨シーズンの躍進で強豪っぽい特集記事がたくさん出たのは嬉しかったです。

その他

仕事で疲弊していたので読書もあまりできなかったのですが、System Design InterviewやGrokking Functional Programmingは面白かったです。

takezoe.hatenablog.com

takezoe.hatenablog.com

引っ越してから自宅の作業環境を着々と整備してきたのですが、今年はついに最後に残っていた椅子を買い替えました。10年以上前に買ったバロンチェアを使い続けていたのですが、あちこち崩壊してきたのでエルゴヒューマンに買い替えました。オフィスチェアも値上がりしていてなかなか厳しい世の中ですが、これで作業環境はほぼ完璧になりました。あとは最近老眼が来ているのか細かい文字が見えにくくなってきたのでディスプレイはもう少し大きいものにしてもいいかも。

また、健康診断の結果がめちゃくちゃ悪かったり、腰痛がさらに悪化したりなど健康問題が多発してしまい、定期的に体を動かさないと…ということで毎日20-30分ウォーキングを数ヶ月続けていたのですが、少し仕事が忙しくなった時期に途切れてしまい、その後再開できていません。

今年は全体的に色々とストレスフルな感じで良くない出来事も多かったので、来年は良いことがあるといいなぁと思っています。

Presto/Trinoのサブクエリ重複実行問題について

Presto/Trinoは分散クエリを高速に実行するためにストリーミング型のアーキテクチャを採用しているのですが、このためクエリ内に重複箇所があっても複数回並列に実行されてしまうという問題があります。わかりやすい例だと、CTEで定義したクエリを複数回参照した場合、参照した回数分そのクエリの処理が実行されてしまいます。複数回実行されるクエリが重く、参照回数が多い場合、このコストはかなり厳しいものになります。

調べてみたところ、Presto由来のクエリエンジンでいくつかの対策が行われていたのでまとめてみました。

openLookeng

openLookengというのはHUAWEIオープンソースで開発しているビッグデータプラットフォームのようなのですが、クエリエンジンはPrestoをベースとしているようです。こちらではCTEに専用のオペレータを導入し、複数のコンシューマのキューにデータをプッシュできるようになっています。

gitee.com

CTE専用オペレータが導入されていることからCTE以外の共通部分には適用できないのではないかと思いますが、直感的なわかりやすさはあると思います。

PrestoDB

PrestoDBではRaptorXというキャッシュ活用プロジェクトの一環としてクエリフラグメントの出力をワーカーのディスク上にキャッシュするという機能が実装されていました。同一のスプリットが同一のワーカーにアサインされた場合にキャッシュが利用されるというもののようです。

github.com

クエリをまたいでキャッシュを共有できるというのはメリットだと思いますが、実際のワークロードでのキャッシュヒット率がどのくらいか気になるところです。ディスクの消費も激しくなると思うのでユースケースによっては使いづらいのではないかと思いますが、インハウスのデータウェアハウスなど、テーブル数やデータ量がある程度限定されており、ワークロードが予測可能な環境であれば有効かもしれません。

Amazon Athena

AmazonのAthenaではクエリの共通部分をリライトすることでマージしてしまうクエリフュージョンという最適化が実装されているようです。

www.amazon.science

www.amazon.science

この方法は対応可能なケースに制限はあるものの、他の方法と違ってクエリのリライトのみで実現できるためアーキテクチャ非依存であるという利点があります。実際AthenaだけでなくRedshiftなどでも同様の最適化が実装されているようです。Trinoにプルリクエストが出されているのですが、まだマージされていません。実際に動かしてみたのですが、ペーパーで書かれている機能がすべて実装されているというわけではなさそうです。

github.com

ベンチマークだと逆に遅くなってしまうケースもあるようですが、オプションで有効・無効を切り替えられるようになっているので入ってくれると嬉しいですね。

まとめ

問題意識としては同じだと思うのですが、Pretso一族の中でも対策は様々でした。このあたりは各プロダクトが想定するユースケースにもよるところもありそうです。その中でもAthenaのクエリフュージョンはクエリのリライトのみで対応できるので副作用も小さそうですし、比較的気軽に試すことができそうです。

また、Athenaのペーパーにはクエリフュージョンだけでなくスプーリングもロードマップにあると書かれています。それなりに大きな変更になりそうですが、実現の暁にはコミュニティにもなんらかの形でフィードバックされるといいですね。

今年のTrinoへのコントリビューションをまとめてみた

前半は仕事が忙しすぎてOSS活動どころではなかったのですが、後半から少し余裕ができたのでTrinoにも細かい改善やバグ修正などいくつかPRを送って取り込んでもらうことができたので記録のためにまとめてみました。

年末までにまだ増えるかもしれないので増えたら追記します。

GitBucket 4.40.0をリリースしました

Scalaで実装されたオープンソースのGitサーバ、GitBucket 4.40.0をリリースしました。

https://github.com/takezoe/gitbucket/releases/tag/4.40.0

このバージョンでの大きな変更および新機能は以下の通りです。

デフォルトブランチが変更可能に

これまでmaster固定だったデフォルトブランチ名ですが、設定で変更可能になりました。デフォルトは引き続きmasterのままですが、将来のバージョンでmainへの変更を検討したいと思います。

イシュー/プルリクエスト検索でカスタムフィールドをサポート

イシューやプルリクエストをカスタムフィールドで検索できるようになりました。

検索ボックスでfield_name=valuefield_name<valueといった検索条件を指定できます。

フォークしたリポジトリのデフォルトブランチからプルリクエストを作成可能に

これまでフォークしたリポジトリのデフォルトブランチからはプルリクエストを作成できなかったのですが、これが可能になりました。

ニュースフィードで参照可能な全リポジトリのアクティビティを表示

これまでダッシュボードのニュースフィードでは自身が管理者として所有しているリポジトリのアクティビティのみ表示されていましたが、参照権のあるすべてのリポジトリのアクティビティを表示するようになりました。

これによってこれまでは表示されていなかったコラボレーターとして登録されているリポジトリのアクティビティもニュースフィードに表示されるようになりました。

Java 8サポートの廃止

GitBucketの実行環境としてJava 8はサポートされなくなりました。もしGitBucketをJava 8環境でお使いの場合、Java 11以降へのアップグレードをお願いいたします。

git pushのパフォーマンス改善

git pushのパフォーマンスを改善しました。巨大なリポジトリではこの改善では不十分な可能性がありますが、引き続き改善策を模索していきます。

今回のバージョンではこの他にもWeb APIを中心に様々なバグフィックスを行っています。詳細についてはIssueの一覧をご覧ください。

Scalatra 3.0.0をリリースしました

サーブレットベースのScala用WebフレームワークでScalatra 3.0.0をリリースしました。

github.com

機能面では2.x系と基本的に変更はなく(非推奨になっていたモジュールを削除したりはしています)Scala 3とJakartaへの対応がメインとなっています。Jakarta対応に伴って各モジュールのアーティファクト名に-javaxまたは-jakartaというサフィックスが付くようになっていますのでご注意ください。

// for javax
libraryDependencies += "org.scalatra" %% "scalatra-javax" % "3.0.0"

// for jakarta
libraryDependencies += "org.scalatra" %% "scalatra-jakarta" % "3.0.0"

周辺ライブラリのScala 3対応待ちもあり、最初にマイルストーンビルドを出してから1年以上経ってしまいましたが、先日最後のブロッカーだったTwirl 1.6.0が無事リリースされたのでScalatraも正式にリリースすることができました。サンプルやドキュメントなどがまだ更新できていないのですが、量がかなりあるので少しずつ修正していきたいと思います。

今後についてですが、Scalatraは新規に使い始めるユーザさんより既存のアプリケーションで使用していてアップグレードしたいというケースの方が圧倒的に多いと思うので互換性を維持しつつ最新のScalaやライブラリに対応していくだけで十分かなとは思うものの、SPA以前のWebフレームワークなのでAPI開発には使いにくいと感じる部分もあり、そのあたりは強化してもよいかもしれないなぁと感じています。