How Does Swift Concurrency Prevents Thread Explosions? 最近読んだもの8 - Swift Concurrency、 Swifty CLI などでも挙げた Swift Concurrency における thread explosion についての詳細 Thread Explosion とは CPU core 数に対して16倍以上のスレッドが走っている状態 GCD 自体は Thread explosion を抑制する機能はないので簡単に引き起こすことができる Swift Concurrency で Task.init(priority:operation:) で同様のことをする priority は .userInitiated .utility .background の3種類で優先度順 .userInitiated だと CPU コア数分の thread を作成している、それぞれ “com.apple.root.user-initiated-qos.cooperative“ という queue に対して上限 thread 数を設けている .utility .background は .userInitiated の Task が実行されている場合は1つまでしか thread が実行されないなど色々なテストがされていた Five ways to break Swift Concurrency @MainActor が backgroud thread など他の thread から呼ばれる可能性があるコードのまとめ selector や notification 経由など SwiftUI だと DateFormatter がなくても Text のみで日付のフォーマットを変えられるという tweet Swift 5.8 から closure 内で weakify した self を unwrap したら、その後は暗黙的に扱えるようになったという tweet Task Groups in Swift explained with code examples Task Group のユースケースごとの紹介 DispatchGroup のモダンな形くらいの認識しかなかったのでありがたい UIViewConroller.viewIfLoaded というメソッド iOS9 からあるよという tweet

Mimicking a Holographic Effect for Mercard アプリ上のメルカードで使われているジャイロスコープを使ったホログラム効果の解説記事 ジャイロからリアルタイムで端末の傾きがとれるのでそれを用いてホログラムを更新する その際に色の表現は HSB Model が適していた init(hue:saturation:brightness:alpha:) 余計な電力消費などが出ないように注意した data collection を 60fps に制限した Low Power Mode の時はホログラムを disable にした payment tab が active かつ visible なときのみ効果を適用 QA も色々な端末で行った Using complex gestures in a SwiftUI ScrollView SwiftUI で ScrollView 上で複雑な gesture を扱う方法 Swift Enum With Labeled Associated Values Enum の assoc values はラベルが付けられるという記事 iOS In-App Subscription Tutorial with StoreKit 2 and Swift StoreKit 2 を使った IAP 実装チュートリアル 5年くらい前に実装した時と比較してセットアップ周りがだいぶ変わったなという印象 StoreKit configuration file は良さそう AppStore Connect も REST API ができたようなので、reneweal や restore の処理なども起動時に行わなくてよくなったのかな？ The Future of Foundation Foundation framework が Swift で書き直され OSS 化される 今までは Swift は OSS だったが、そこで使われる Foundation は以前からある C で実装されたものをラップして扱っていた

Secret Management on iOS iOS アプリで情報を秘匿した場合に取りうる方法とその pros/cons まとめ 結構昔の記事だけどまた news letter で流れてきたので改めて読んだ コード内に直接埋め込む、 .xcconfig など外部ファイルに入れる、 GYB を使ってコード生成する、などが挙げられている When .animation animates more (or less) than it’s supposed to .animation() modifier が nest されている場合に、コントロールが難しいという記事 並列で並ぶ分には期待通りになるが nest されていると難しいらしい 宣言的に書くアニメーションは確かにまた違った難易度 Introduction to SwiftUI Modularisation with SPM SPM のパッケージ単位でモジュール分割する方法 Combining opaque return types with primary associated types Swift 5.7 で導入された primary associated type の説明 AnyPublisher を some Publisher に書き換えた時に生じる問題を例に挙げていてわかりやすかった some をつけながらも指定されている assoc type を指定することができるようになった Pin a view to the bottom of safe area in SwiftUI テキスト入力フィールドなどで、safe area の bottom に張り付いているような view をどのように作ればいいか safeAreaInset(edge:alignment:spacing:content:) modifier を使うと、使われた view に対して紐づいてくれる How Xcode 14 unintentionally increases app size Xcode 14 から Bitcode の設定がデフォルトでOFFになった Bitcodeが元々ONだったプロジェクトの場合は問題なさそう？だが、OFFのプロジェクトの場合は strip の設定が正しくされていないとアプリサイズが増えてしまう問題がある How I made my app 73% lighter 大きい画像を pdf で xcasset に追加していると、Xcode はそれを @1x として @2x @3x 向けの png を生成するのでアプリサイズが大きくなってしまう

The Art of the Awkward 1:1 1:1 は気まずいものでないと意味がないという記事 やや釣りタイトルではあるものの、納得感あった 1:1 は双方が複雑で不確実なもの（感情、希望、恐れなど）を扱うのに適した場 逆に議論が必要ないものを話す場としては最悪 よくある 1:1 での無駄 軽いアップデート、軽いフィードバック、軽い不満など 確かに価値はあるが、貴重な1:1な時間を使う必要がない その時に自分自身に「この会話はハードだったか？」と聞くべき 言いたいことを言う時に不安だったり確信がなかったりしたか？気まずかったか？ 気まずくなかったら本当のことは話せていない 例えばバーンアウト気味だとか、転職考えてるとか、思った通りに成長できていないとか 良くある例として、馬鹿っぽくなるから良くないことを言わなくなりがち 1:1 の全ての時間を気まずくする必要はない ただ1回のMTGで一定量の気まずさは持って行くべき これが繰り返し起こる問題やサイクルを断ち切る ガードを緩めて本当の信頼につながる 変化や成長はいつも気まずいもの 以前は伝染病のように気まずい会話を嫌っていた 非常に重要な 1:1 の時間を失っていることに徐々に気づいていった 気まずい 1:1 のためのルール 1: オープンな場で議論できるトピックは何も話さない 2: 毎回の 1:1 で気まずいことを一つ話すことにコミットする、相手も 事前にお互いで合意しておくのがいい コミットするとピアプレッシャーも効いてうまく行く 気まずい話題の例 メタ・感情 フィードバック アドバイス Awkward 1:1s: How To Get Honest Feedback ^の続編、フィードバックのもらい方について 「フィードバックください」と言ってもなかなかすぐにもらえるわけではない 信頼関係を作るのがまず大事というアドバイスはよくあるけどあまり助けにはならないよね フィードバックの会話そのものを通して信頼関係を作るといい 人から真実を引き出したいときは会話を自分ではなく彼らが快適な方向で進めるのがいい 信頼関係がない状態でフィードバックを与えるのってリスクを感じるのでそれを減らす How Make it safe Make it easy Make it reward

Check localizable strings with the accented pseudolanguage in Xcode SwiftUI での文言ローカライズについて SwiftUI ではいくつかローカライズ文言用のキー定義の方法がある まず Text() に渡す string literal は 暗黙的に LocalizedStringKey になっているのでローカライズされる また String も String(localized:) で initialize すればそのローカライズされる Xcode の scheme 設定で App Language に Accented PseudoLanguage という選択肢がある これを設定するとローカライズされていない文言が分かりやすくなる（ローカライズされている文言は架空の文字列になる） Should we manually call @StateObject initializer @StateObject を初期値ではなく、 StateObject(wrappedValue:) を使って初期化するのは大丈夫なのか？という記事 例えば初期化時に何かパラメータが必要なものなど動的にしたいなど 結論 initializer の中でなら問題ないが副作用に注意らしい Animated Launch Screen in SwiftUI Splash screen と TOP 画面でどのように画面遷移を自動（通信完了と同時に dimiss）させるか @EnvironmentObject を使って app top で持っている @StateObject を inject しているのが勉強になった When does a SwiftUI Environment get retained? SwiftUI の EnvironmentObject がどのようにメモリ上で持たれているかの記事 leak している view に .environmentObject() するとそれに引きずられて leak するという話 Running Code Only Once in SwiftUI 画面表示時など、一度だけ実行させたいコードがある状況は良く出てくる 例えば .onAppear だと画面が push/pop すると再度呼ばれてしまう この記事では .onFirstAppear という extension を作って、その内部で FirstAppear という ViewModifier を用意しそこで flag 管理することで解決していた How to check for network connection and present an alert in SwiftUI NWPathMonitor を使った ObservableObject を作り、それを @EnvironmentObject として application の最上位から inject する方法 子 View に関しては @EnvironmentObject すれば該当のオブジェクトを取得できるので便利 Share files between your iOS app, Widget and WatchKit extensions iOS の sandboxed な環境下で App Extension 間でどのようにファイルを共有するか WatchKit Extension だと session という概念を通じてやりとりするのは知らなかった Improve App Launch Time 2022 Edition 環境変数 DYLD_PRINT_STATISTICS は動かなくなった 代わりに Instruments の App Launch テンプレートで計測できるようになった Debug ではなく Release ターゲットで計測するようにする Test 用の Target テンプレートである UI Testing Bundle を使うと起動時間を計測するテストが予め含まれている Xcode Organizer にある Launch Time metrics も有効

Presenting Sheets: Item, or a Boolean Binding? List 内のコンテンツを sheet などで表示する場合、sheet(isPresented:onDismiss:content:) よりも sheet(item:onDismiss:content:) の方が管理する State が減るので良いという話 Create a Card with an Image Outside its Bounds in SwiftUI ある View の中の View を一部はみ出させて表示したい場合 SwiftUI でどうやるのかの話 UIKit であれば bounds ベースでレイアウトを組んで実現できた SwiftUI だと以下の2つの方法が主に挙げられていた ZStack でラップする この content 内で padding をうまいこと指定する overlay(alignment:content:) modifier を使う overlay modifier の content 内ではみ出させる View を扱う Swift Concurrency – Things They Don’t Tell You async await などを使った Concurrency を扱うときによくハマる問題がまとめられていた async await すればいいだけと言われてるけどそんなに単純じゃないよ 自分がハマったり勘違いしていた点も入っていたのでかなり有用 例えば async な function を await した後の thread は、する前の処理 thread と同じにはならない可能性がある。など 解決策としては async な function が main thread で走ることを保証したい場合は常に @MainActor で annotate する それが難しい場合、 function 内部で main thread で走ってほしい処理を await MainActor.run {} する actor の Actor Reentrancy などもとても参考になった Task {} についても勉強になった Task {} で引数になる closure は user-initiated な concurrent queue に dispatch される Swift Concurrency は CPU core 数を超えないように queue 毎の thread 数を制限しているので、それを超えてしまうと Task が suspend する Creating a Swifty Command-Line Tool With ArgumentParser swift-argument-parser を使って簡単に CLI ツールを Swift で作る方法 argument や flag などに property wrapper が使われていたりとモダンに手軽に書けそうだなと思った

Asynchronous Communication is the Great Leveler in Engineering Shopify のエンジニアによるリモートワーク環境下における非同期コミュニケーションについての記事 コミュニケーションのタイプによって同期・非永続的と非同期・永続的で分けられてる図が面白かった チャットが同期的な方に入ってるのは確かに、と思った ある程度送る側が読まれることを期待していて、さらに返信がリーズナブルな期間で返ってくると思っている 非同期コミュニケーションはリモートワークを効率的にするだけではなく色々なものが永続的になっていくので、適切に行えばどんどんレバレッジがかかっていく 全社ではなくチーム内でリモートワークでの標準を決めるのもいいなと思った Mobile Developer Experience at Slack Developer pain をリストアップして、それぞれにかかる時間と時給から年間コスト出すのがとても良い そしてこれはチームサイズが大きければ大きいほどコスト増になっていく アプローチ方法で興味深かったもの　feature チームのmobile engineer と partner になって一緒に開発し、何が大変なのか観察する NPS など mobile engineer 向けにサーベイを行う ペインポイントを解決する前に metrics を集める Developer pain iOS での CI のビルド時間 最初 iOS は Bluepill を使ってテストの並列化を行った それで一時期は20分くらいまで減ったが、再度50分近くまで増えた 次のアプローチとして Bazel で cache layer を作る方法をとった bazel-diff を使って、2 revison 間に bazel cache の差分があるかどうかの検知もできる これによって平均9分、最小だと4.5分のTTM(Time to merge) まで下げることができた Android での Test 関連の失敗 Automated なブラックボックステストを入れていたが、テストが増えるにつれてより flaky になった 一度失敗すると修正するために Automation Engineer に連絡しないといけず、 TTM が増加する傾向があった 詳細はこちら Handling Flaky Tests at Scale: Auto Detection & Suppression iOS での merge conflict XcodeGen を導入して対応 Bazel 導入により、動的に XcodeGen 用の YAML ファイルを生成している Aviator を使って merge queue の管理と自動化を実現している

What are Sendable and @Sendable closures in Swift? 以前よりは Sendable に関する理解が高くなった actor はデフォルトで Sendable closure に @Sendable をつけると、その中で capture された値が Sendable でない場合は warning になる（設定が必要） struct は暗黙的に Sendable になっている（ただしプロパティ全てが Sendable なら） 同様に class でもそれが final なら Sendable Conditional layouts in SwiftUI iOS 16 から Layout protocol が導入された conditional に layout を変えたい場合、 AnyLayout を使ってより綺麗に書けるようになった Structural identity in SwiftUI conditional body の場合、 some View は _ConditionalContent<LoggedUser, AnonymousUserView> などになる 予期せぬ recreation や animation が発生することがある inline modifier などで structure identity を保持するのがいい Pitfall of Nested ObservableObject nest された ObservableObject だと変更が通知されないので、マニュアルで発火させないといけない onTapGesture(count:coordinateSpace:perform:) iOS 16 から SwiftUI でも tap gesture を SwiftUI.View 単位につけることができるようになった Mastering NavigationStack in SwiftUI. Navigator Pattern. NavigationView は deprecated になり、iOS 16 から NavgationStack が登場した navigationDestination(for:destination:) で遷移先を統一的に書けるように Mastering NavigationStack in SwiftUI. NavigationPath. Three Ways to Refactor Massive SwiftUI Views SwiftUI の View が大きくなった時の分割、リファクタリングの方法

【推薦書リスト】世界史独学のための100冊 前置き 最近世界史にと興味が出てきて、高校時代に読んだ詳説世界史BやCOTEN RADIO を読んだり聴いたりして、一通り浅いなりに全体像が見えた気になってきた 歴史シミュレーションゲームをやる中で特定の時代や人物（今回の場合だと古代ローマ）をもっと知りたいと思い関連書籍を調べる中で興亡の世界史という本が良さそうとなった レビューをまず読みたいと思い出会ったのがこの記事 書籍の難易度に対する分類が分かりやすかった 難易度は「固有名詞の量」と、「前提とするレベル」の2軸で分けられている 固有名詞の量についてはある程度の専門書を読んで挫折した人なら誰でも経験があるなと思った 一定の語句を暗記する(「既知」を蓄える、という言葉がストレートに分かりやすかった)ステップをまず踏むのが世界史だけでなく役に立つのは個人的にも理解できる 膨大な引用されてる書籍があるので、これを軸に色々つまみ食いしていけると良い Team Topoligies 前から気になってはいたが、 74. PMFしているスタートアップがスケールする上での組織課題と解法 w/ kameike fukabori.fm を聞いて今更読み始めた まだ絶賛読み途中なので、読み終わったら別でまとめたい 以前読んだ An Elegant Puzzle: 2 Organizations のメモ でも出てきたような話もあり、つながりを感じてとても面白い ジョナサン・ハイトが解き明かす「アメリカ社会がこの10年で桁外れにバカになった理由」 成功した民主主義国家を集団的に統一するものとして、社会学者は少なくとも3つの主要な力を特定してきた。社会関係資本（高水準の信頼に基づく広範囲の社会的ネットワーク）、強固な諸制度、そして共有される物語だ。 ソーシャルメディアは、これら3つすべてを弱体化した。 一部有料会員限定なので、全ては読めてないけどこの一文はとても印象的だった