転職のお知らせ（LINEヤフー株式会社に入社しました）

雑記
from:
株式会社はてな（マンガアプリチーム）
to:
LINEヤフー株式会社

2024年9月1日付でLINEヤフー株式会社に入社しました。LINEアプリのMDX（モバイル・ディベロッパーエクスペリエンス開発チーム）というチームで、LINEアプリのクライアントサイドの開発基盤・開発者体験の改善をやっていきます。

↓旧LINE時代のチームについての記事

今後もiOS・モバイル界隈の方々はどうぞよろしくお願いします🙏

38歳になりました&はてな退職のお知らせ

雑記

本日7月29日で38歳になりました。アラフォーですね。

直近では「少年ジャンプ＋」アプリのリニューアルを担当していたのが大きなトピックでした。

そんな現職の株式会社はてなを2024年8月31日付で退職します。最終出社日は8月2日です。転職先は入社日以降にお知らせするかと思います。

2016年1月からの8年半の在籍中、とても多くの方々にお世話になりました。本当にありがとうございました。

ウィッシュリストはこちら

xcprettyだとXCTestExpectationのタイムアウトエラーやXCTSkipが結果に反映されず、xcbeautifyだと問題なく動く

iOS Testing

まだxcprettyを使っていませんか？今こそxcbeautifyに置き換えよう！ by ikesyo | プロポーザル | iOSDC Japan 2024 #iosdc - fortee.jp で想定していた内容の一部の供養です（落選）。

社内のとあるプロジェクトで、XCTestExpectationがタイムアウトしているケースでもテストが成功扱いになっていたり、XCTSkipを使ったテストケースがログに出力されていないということがあった。CIでのテスト実行にはfastlaneを使っていたので、fastlaneの実行ログからxcodebuildの出力のフォーマッターを確認してみると、xcprettyが使われていた。

fastlane 2.201.0から scan, gym, snapshot に xcodebuild_formatter というオプションが増えていて、そのデフォルトは xcbeautify になっているのだが、これはシステム（PATH？）にxcbeautifyが存在する時だけで、xcbeautifyが存在しない環境ではxcprettyにフォールバックするようになっている。

はてなではiOSアプリのCI/CD環境としてCircleCIを使用している（2024年6月現在）が、CircleCIのMacインスタンスではxcbeautifyはインストールされておらず、xcprettyにフォールバックしていたのだった。

そこでCIのステップとして brew install xcbeautify を先に実行してxcbeautifyをインストールするようにしたところ、XCTestExpectationのタイムアウトも、XCTSkipも正常に拾われるようになってめでたしめでたし。

xcbeautifyがREADMEで次のように謳っているとおり、

  • [x] Supports the new build system's output.
  • [x] Supports Xcode's parallel testing output.
  • [x] Supports formatting Swift Package Manager output.

現代のXcodeやSwiftPM相手にはxcbeautifyを使っていくべきだということを実感した。

ちなみにGitHub ActionsのMacインスタンスについては macos-12 以降のイメージではxcbeautifyがプリインストールされているので安心していい。

その他のCIプロバイダー、例えばBitriseやCodemagicでのxcbeautifyのインストール状況を知っている方がいたらぜひ教えてください。

追記

情報・メディアの生存期間の長さを意識する

雑記

数年前に社内でとあるプルリクエストのレビュー中に考えたことを放流したのを外向けにも書き溜めておく。

（フロー情報とストック情報とも近いような違うような感じなのだけれど）ある情報（を書いたメディア）の生存期間の長さはよく意識している。ざっくりいうと今は自分たちのチームではタスク管理にAsanaを使っているけれど、Asanaはいつ契約を終了して、そこにあった情報にアクセスできなくなるかはわからない。ので、情報（現在の状態であったり意思決定の記録であったり）のトレーサビリティを考えた時に、Asanaに記録された情報は将来的に追えなくなる可能性が（比較的）高い。将来に渡って情報を追えるためには、AsanaよりもGitHubの方が確かだし、（現状のドキュメンテーションツールとしては）Scrapboxにもログがあることが大事だと思う。

（チケット・プロジェクトの進捗状態などは別として）Asanaにしかない情報というのはなるべく避けたい。Asanaタスクに細かく色々書くよりも、別の場所に書いたことへのポインターを置いていく方が適切だと思う。

現在はどちらかというと逆にSlackやScrapboxで会話しすぎずにできるだけAsanaでやり取りしていく状況になっていっているのは少し面白い。Asanaを簡単には捨てないだろうという位には使うようになったり、多職種の人が使うにはGitHubのIssueやPR上で議論するよりもAsanaの方が触りやすかったりはするとかもあるだろう。新しいGitHub Projectsをガッツリ使い込めばまた見え方が違ってくるのかもしれないが。

try! Swift Tokyo 2024でOpen Source Swift Workshopの講師をしました

Swift

@giginetさん、@kitasukeさんと自分の3人でワークショップ講師をさせていただきました。自分はswift-corelibs-foundationのコミッターとして、FoundationやApple公式のライブラリ群についての概観や現状を紹介しました。

speakerdeck.com

ワークショップ全体についてはgiginetさんが素晴らしいレポートを書いてくれているので、詳しい内容や成果についてはそちらをどうぞ。

techblog.lycorp.co.jp

時間も短い中で想像以上に多くの成果が出て、多くの方々がSwiftにコントリビュートするきっかけの一助となれてよかったなぁと思います。

try! Swift Tokyoでこのワークショップ講師をするのは2018年と2019年に続いて3回目でした。

2018

developer.hatenastaff.com speakerdeck.com

2019

speakerdeck.com

本当は2020年にも今回の3人で講師をやらせてもらう予定だったけれど、COVID-19でキャンセルになってしまったので、その時のリベンジでした。久しぶりのカンファレンスの開催、そしてそこに参加してワークショップ講師としても関わらせてもらうことができて、とても楽しく有意義な3日間でした！また今年はこれまで以上に多くの有識者にチューターとしてワークショップに参加してもらったので、来年はその中から新しい講師が生まれるかもしれませんね？どういう形になるかは想像できませんが、また来年も会場でお会いしましょう👋

SQLiteでは集計とグルーピングの対象外のカラムでも、集計関数がMAXとMINの場合はそれらの行由来の値を返すことが保証されている（例外あり）

Android SQL

AndroidでSQLiteがバックエンドのJetpack Roomを使っていた時の話題。

SELECT column_a, column_b, column_c, MAX(column_d)
FROM foo
GROUP BY column_a

このようなSQLにおいて　GROUP BY に使われる column_a と、集計関数（この場合は MAX ）に使われる column_d 以外の column_b, column_c の2つのカラムは bare columns と呼ばれる。SQLiteでは集計関数が MAX か MIN の場合には、これらbare columnsの値が、その集計関数で返される行に由来することが保証されている（いくつかの例外はある）。

Special processing occurs when the aggregate function is either min() or max(). Example:

SELECT a, b, max(c) FROM tab1 GROUP BY a;

If there is exactly one min() or max() aggregate in the query, then all bare columns in the result set take values from an input row which also contains the minimum or maximum. So in the query above, the value of the "b" column in the output will be the value of the "b" column in the input row that has the largest "c" value. There are limitations on this special behavior of min() and max():

1. If the same minimum or maximum value occurs on two or more rows, then bare values might be selected from any of those rows. The choice is arbitrary. There is no way to predict from which row the bare values will be choosen. The choice might be different for different bare columns within the same query.
2. If there are two or more min() or max() aggregates in the query, then bare column values will be taken from one of the rows on which one of the aggregates has their minimum or maximum value. The choice of which min() or max() aggregate determines the selection of bare column values is arbitrary. The choice might be different for different bare columns within the same query.
3. This special processing for min() or max() aggregates only works for the built-in implementation of those aggregates. If an application overrides the built-in min() or max() aggregates with application-defined alternatives, then the values selected for bare columns will be taken from an arbitrary row.

SQLite以外のRDBではこのような動作は保証されないのでポータブルではなく避けた方がよさそうではあるが、AndroidのRoomの場合はSQLiteを前提として使ってもいいんじゃなかろうか。

GitHub Actionsのサードパーティーマネージドランナーの紹介

GitHub Actions CI

この記事は はてなエンジニア Advent Calendar 2023 の 2024年1月4日 の記事です。

GitHub Actionsの実行環境であるランナーには、GitHubが提供するGitHub ホステッド ランナーと、自分でランナーを用意・管理するセルフホステッド ランナーの大きく二種類があります。

最近はGitHub ホステッド ランナーにもラージランナーが用意されるようになり、ある程度ランナーのスペックを選べるようにもなりましたが、他のCIサービスと比べてもスペックの割にコストが高めである感じは否めません。一方でセルフホステッド ランナーにはスペックを自分で調整できる自由度がありつつも、管理する手間とコストが掛かってきます。

こうした隙間を突くように、サードパーティーによるマネージドなセルフホステッド ランナーを提供するサービスが増えつつあります。基本的には runs-on: に各サービスが提供するランナーの名前を指定するだけで、その名前に応じた環境（CPUアーキテクチャーやスペック、OS）を選べる、という形になっています。

自分が見かけたり調べたり実際に使ってみたものをいくつか紹介してみようと思います。

BuildJet

  • コストがGitHub ホステッド ランナーの半額
    • 同じvCPU数なら半額、同じコストならvCPU数が倍、というモデル
  • ただしvCPU数に上限があり、並列で起動できるジョブ数に制限がある
    • そのvCPU数上限を上げるのに別途課金が必要
  • シングルコアパフォーマンスがGitHub ホステッド ランナーよりも高い
  • x86_64だけでなくARMランナーも提供している
  • 以前はAppleシリコンのMacランナーも提供する意思を見せていたが、GitHub ホステッド ランナーもAppleシリコンに対応したので、やらないことにしたようである
  • actions/cache の代替として buildjet/cache を用意している

はてなでも昨年から一部のチームで使用していて、CI/CDの速度向上の恩恵を受けています。管理画面はあまりいけていなくて、vCPU数上限がある割にはどれだけ消費されているかのリアルタイムの数値やグラフでの確認ができなかったりするので、キャパシティプランニングが難しいですね（上限に引っ掛かるとジョブの起動待ち状態になるので、悲鳴ベースで対処していくしかない）。

BuildJetのPricing

Namespace

  • 単なるGitHub Actionsのマネージドランナーというだけではなくて、Dockerイメージのリモートビルダーや、開発環境としてのKubernetesクラスターの作成もできたりする
    • Webアプリケーションのプレビュー環境機能なども
  • キャッシュのアップロード・ダウンロードではなく、キャッシュ用のボリュームをアタッチすることでの高速化が最近サポートされたようでとても良さそう
  • Pricingはプラン毎にシート数やコミコミのリソースが決まっている（超過分は別途）、という形なので若干複雑

NamespaceのPricing

GitRunners

  • 雰囲気としてはBuildJetに近そう
  • コスト的にはGitHub ホステッド ランナーとBuildJetの中間
    • 並列数の制限はなさそうなので、BuildJetのvCPU上限の拡張に課金するよりもいいケースもありそう
  • 1vCPUを選べるのが特徴的（GitHub ホステッド ランナーやBuildJetは最低2vCPU）
  • 個人で少し触ってみた程度だが、管理画面はBuildJetよりもいけていそう
  • Upcoming featuresのアピールが気になる

    • Persistent storage for all ephemeral runners and flamegraph visualizations to analize workflows runtimes.

    • 前者はNamespaceのCache Volumesに相当するものっぽい
    • 後者はボトルネックを見つけるのに便利そうで、やはり管理系の機能には力を入れていそう

GitRunnersのPricing

WarpBuild

  • Argonautというクラウドサービスのデプロイツールからピボットしたサービスらしい
  • こちらもBuildJetと近しい雰囲気
    • CPUパフォーマンスがいい
    • x86_64ã‚‚ARMもサポート
  • 並列数の制限もなし！
  • SSHでデバッグ可能というのは面白そう・便利そう
    • この時の課金がどうなるのかは気になる
  • Pricingã‚‚GitHub ホステッド ランナーの半額なので、BuildJetと同様
    • vCPUの選択肢が2X、4X、16Xとなっていて、8Xがないのが悩ましいかもしれない
  • Coming soonにも期待したい
    1. Faster distributed caching
    2. Windows and MacOS runners
    3. Custom runner images ... and more!

WarpBuildのPricing

Cirrus Runners

  • Cirrus CIというCIサービスの提供元のCirrus Labsが出している、AppleシリコンのMacランナー
    • AppleシリコンはM1ではなくM2
  • 1ランナーあたり$150/月という固定費で使い放題なのが特徴
    • MacランナーはどのCIサービスでも高い（時間単価がLinuxの10倍くらいする）ので、用途によってはめちゃくちゃ安く使える
    • タイムゾーンをまたがって使うことで稼働率を高められるとコスト効率がいいということ
    • New dashboard with insights into performance of Cirrus Runners - Tart
  • TartとOrchardという仮想化基盤を自社で開発・公開していて、それを使って運用されているのも興味深い

まとめ

ということで、自分の知る範囲でざっくりとGitHub Actionsのマネージドランナーについて紹介してみました。改めて調べてみると、新サービスが増えたり、各サービスで機能追加の予定も出ていたりして楽しみが増えました。逆にBuildJetは最近あまりアナウンスやブログの投稿がなかったりするのは気がかりですね。他にも同種のサービスをご存知の方がいたらぜひ教えてください！