転職のお知らせ(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だと問題なく動く

まだ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の講師をしました

@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の場合はそれらの行由来の値を返すことが保証されている(例外あり)

AndroidSQLiteがバックエンドの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では集計関数が MAXMIN の場合には、これら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を前提として使ってもいいんじゃなかろうか。