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 speakerde
iOSシミュレーター・Androidエミュレーターにアプリをインストールだけする（起動までしない）方法 - いけだや技術ノート
なぜ アプリの初回起動時専用の特別な処理や画面遷移を行うケースで、そのデバッグ実行・動作確認をするため。 iOS まずインストールするためのアプリは Build For Running でビルドしておく。次にシミュレーターを起動しておいて xcrun simctl install booted <~~.appのパス> のコマンドを実行する。 もしくは、シミュレーターのウィンドウに ~~.app をFinderからドラッグ＆ドロップする。 Xcodeのスキーム設定の Wait for the executable to be launched が使えるのでは、と一瞬考える。しかしこれはシミュレーターにインストール済みのアプリには使えるのだが、まだインストールされていないアプリの場合は、アプリのインストールまではやってくれないので、ただ待つだけ（何も起きない）状態になる。ので、別途自分でインス
GraphQLスキーマをサーバーサイドからクライアントサイドに自動同期し、変更履歴も確認したい - いけだや技術ノート
似たような話が先日ありましたね。 こちらはGraphQLではなくてOpenAPI、かつサーバーサイド側のリポジトリからクライアントサイド側のリポジトリにプッシュする方式でした。 今関わっているプロダクトでは、1つのGraphQLスキーマが複数のリポジトリから必要とされていたり、それぞれで同期タイミングを制御できたらいいかなということもあったりで、クライアントサイドからGitHub Actionsの定期実行でプルする方式で更新をしています。 イメージは次のとおり: name: Update GraphQL Schema on: schedule: - cron: "0 0 * * 1-5" # JSTで月曜〜金曜の9時、これは適当です workflow_dispatch: jobs: UpdateGraphQLSchema: runs-on: ubuntu-latest steps: - u
期間の扱い方とその名前 - いけだや技術ノート
とあるAPIのスキーマの叩き台をクライアントサイドとして検討している際に、コンテンツの公開期間やイベントの開催期間のような期間について議論が少し盛り上がった。 要件としては、期間の開始と終了の日時をそれぞれ取得できたい。 期間を考える時、開始と終了がそれぞれinclusiveなのかexclusiveなのかをまず考慮すべきであるが、開始日時の重複や終了日時に隙間を発生させないためには、開始はinclusive、終了はexclusive、つまり半開区間（左閉右開）にするのが望ましいだろう。 終了をexclusiveにすると、例えば8月の1ヶ月間、つまり8月1日0時0分〜9月1日0時0分という期間の場合、ユーザー向けの表示としては終了日時は「8月31日23時59分まで」と表示したくはなるが、これはプレゼンテーションロジックとしてクライアントサイドの責務としてやる。基本的には-1秒してからフォーマ
SwiftUI.ViewとUIHostingControllerの初期化順序の調整 - いけだや技術ノート
UIHostingControllerを使ってSwiftUI.Viewを表示する時に、Viewの引数に渡すクロージャーの中でViewControllerを使いたいことが稀によくある（本当に？）。 素直に考えるとこうなる。 // 順序的にvcを使えない let view = FooView(onTap: { // vcで何かしたい }) let vc = UIHostingController(rootView: view) 少し頭を捻るとこうなる。 let view = FooView() let vc = UIHostingController(rootView: view) vc.rootView.onTap = { [weak vc] in ... } UIHostingController.rootView は public var rootView: Content なので、ro
potatotips #77で「RenovateによるiOSライブラリーの自動更新」という発表をしました＆いくつかの補足 - いけだや技術ノート
発表資料はこちらです 👇 発表の中では時間の都合で触れられなかったところをいくつか補足しようと思います。 CocoaPodsでRealmを使っているとPodfile.lockが更新できない件 CocoaPodsとXcodeGenを併用しているとPodfile.lockが更新できない件 おわりに CocoaPodsでRealmを使っているとPodfile.lockが更新できない件 github.com Renovateの実行環境はDockerコンテナの中のUbuntuです。Renovateは Podfile を書き換えた後に pod install を実行してPodfile.lock を更新します。CocoaPodsはLinuxで動くのか？と思われるかもしれませんが、pod gem（や依存の xcodeproj）もLinuxで問題なく動作するようです。ほとんどのライブラリーは問題ないのです
actions/checkoutのアップデートで、gitのsafe.directoryの件が対策されていました - いけだや技術ノート
先週盛り上がっていた、gitのCVE-2022-24765に対する修正でreviewdogなど一部のGitHub Actions（Dockerコンテナのアクション）が動かなくなっていた問題ですが Git security vulnerability announced | The GitHub Blog 一部の reviewdog が `exit status 128` で落ちる件について actions/checkout側でチェックアウトしたディレクトリをsafe.directoryにセットしてくれる対策が入っていました。 Issue: https://github.com/actions/checkout/issues/760 https://github.com/actions/checkout/issues/766 リリース: 3.x https://github.com/acti
チームでのスマホアプリエンジニア採用のために求人票について考えていた - いけだや技術ノート
こんにちは。近頃はSwiftUIでの新機能開発に勤しんでいる id:ikesyo です。 そんなこんなで自分が所属しているはてなのマンガアプリチームでは最近、iOSエンジニア・Androidエンジニアを積極採用しようと動き出しています。その中でまず求人票の内容を検討していました。これまでしたことがなかったけれど求人票を考えるのは意外と面白くて、 要件の洗い出しを通じて、これは現在のチームメンバーも含めたスキルマップについて考えているのだなと思ったり、 チームの様子を伝えようとチームのカルチャーについて考えたり、 このチーム・はてなで働くメリットはなんだろうと考えたり、 日々のタスクに向かい合っているだけだと忘れがちなことに目を向ける良い機会になっています。 この新たな求人票・採用ポジションはそのうちお目見えするはずですが、SwiftUI・Jetpack ComposeとGraphQLをガシ
SwiftOnTap: SwiftUIの用例集付きAPIドキュメント - いけだや技術ノート
SwiftUIを使い始めて、フレームワークが提供する既存のViewに何があって、どういう表示になるのかがまだピンとこない。そんな状況の手助けになるのがSwiftOnTapというサイトです。 swiftontap.com 各ViewやModifierなどの説明にサンプルコードとその実行結果のキャプチャーが付いていて非常にわかりやすい。 サンプルコードと実行結果のキャプチャー このサイトのコンテンツ自体もGitHubでオープンソースとして公開されているので、プルリクエストを出して用例を追加することも可能です。面白いのは、全てのコンテンツは SwiftUI.swift という1ファイルに集約されて /// のドキュメンテーションコメントとして記載されていることですね。ファイルサイズが2MBを超えていてすごい。 2MB超のswiftファイル
uber/mockoloのclassモック生成のバグを修正した - いけだや技術ノート
uber/mockoloとは Uberが開発するSwift用のモック自動生成ツールで、ここ1〜2年で採用が増えていそうな雰囲気 2019年のSwiftモック事情 - いけだや技術ノート でも紹介しました logmi.jp というものです。 mockoloはv1.1.3からprotocolだけでなくclassのモック生成もできるようになったのだけど、これを実際に使おうとしてみると生成されたコードがコンパイルエラーになった。 具体的には、次のようなデフォルト値ありのpropertyを持つclassで問題が発生していた。 // Foo.swift /// @mockable class Foo { var foo: Int = 0 } // Mocks.swift class FooMock: Foo { private(set) var fooSetCallCount = 0 override
2019年のSwiftモック事情 - いけだや技術ノート
こんにちは、id:ikesyoです。これは はてなエンジニア Advent Calendar 2019 17日目のエントリーです。 昨日12月16日（月）に行われた 年末だよ Android/iOS Test Night - 2019 にて、『2019年のSwiftモック事情』という発表をしました。 Swiftでテストのためのモックを用意するとなると、リフレクションでめちゃくちゃするということができないので、素朴に手で書くか、コード生成をすることになります。今回の発表ではコード生成に主眼を置き、以下の4つの選択肢を紹介しました。 SourceryのAutoMockable SwiftyMocky Cuckoo Mockolo それぞれの機能や違いなど詳しい内容は、ぜひ発表のスライドを見てみてください。 Swiftでのモック事情については、今年4月の Mobile Act KYOTO #1
swift-llvmがLLVM 6.0に追従した模様 - いけだや技術ノート
これでSwiftのWebAssembly対応もちょっと捗るのかもしれない？ swift-llvmがLLVM 6.0に追従したっぽい？ https://t.co/SlBrAqYSFE— いけしょー@本書きました (@ikesyo) 2018年3月10日 元々stable-nextっていうブランチで追従してたのをstableブランチにmergeしたのか https://t.co/GvmdKFBIVq— いけしょー@本書きました (@ikesyo) 2018年3月10日 参考: https://github.com/kripken/emscripten/issues/2427#issuecomment-372025515
SwiftのSDK overlayとswift-corelibs-foundation - いけだや技術ノート
SDK overlay SwiftのSDK overlayというものを耳にしたことはあるでしょうか？これはSwiftのOSSプロジェクトであるapple/swiftの開発において、FoundationやAppKit、UIKitなどのObjective-Cで書かれたシステムフレームワークに対し、SwiftらしいAPIを提供するための拡張レイヤーです。 https://github.com/apple/swift/tree/master/stdlib/public/SDK Swift 3で、NSDateに対するDate、NSURLに対するURLなど、参照型と対応する複数の値型がFoundationに追加された*1のを覚えている人も多いかと思います。これらの値型はもちろんSwiftで実装されているわけですが、これも実はSDK overlayの一部です（この場合はFoundationのoverla
Himotoki 1.5.0をリリースしました - いけだや技術ノート
このブログでは昨年末の振り返りエントリー位でしか触れていませんでしたが、SwiftでJSONのデコードを簡単かつ型安全に行うことができるHimotokiというライブラリーを昨年の5月から開発しています。 github.com ikesyo.hatenablog.com 先々週にはなりますが、その最新バージョンの1.5.0をリリースしました。 Release 1.5.0 · ikesyo/Himotoki · GitHub このバージョンには以下のような変更が含まれています。 Linuxでのビルドをサポート（Swift Package Managerは1.4.0でサポート済み） build関数をカリー化関数からクロージャーを返す関数に変更（Xcode 7.3/Swift 2.2からの警告に対応） build関数を非推奨に変更（Swift 2からは特に使う必要がない） Extractor.va
Carthageのコミッター(Collaborator)になりました - いけだや技術ノート
先月の2015年6月に、CarthageというCocoaプラットフォーム(iOS/OS X/watchOS)用の依存性管理ツールのコミッター(Collaborator)になりました。 このプロジェクトは元々ReactiveCocoa 3.0のAPIを洗練させるためのショーケースとして始まったという側面もあり、ReactiveCocoaのCollaboratorとしては当然注目していました。Carthage v0.6.5からv0.7へのバージョンアップ時に、Swift 1.1から1.2への移行、それに伴うReactiveCocoaのアップデートがあったんですが、そこでRACのAPI/設計が大きく変わったことで結構なバグが発生してしまっていました。それらのバグなどを調査・修正して色々とcontributeしている内にinviteしてもらった、という次第です。 RAC 3に慣れていないとなかなか
Carthage 0.12をリリースしました - いけだや技術ノート
昨年のエントリーに書いたように、Carthageのコミッターをしているid:ikesyoです。もう3日前になりますが、最新バージョンの 0.12: All Your Frameworks Are Belong To Usがリリースされました！🎉 今回のリリースで大きなトピックだと個人的に思う以下の3つを紹介します。 Carthage will now build all frameworks from all the projects in the repository https://github.com/Carthage/Carthage/pull/892 https://github.com/Carthage/Carthage/pull/1035 これまでCarthageでは、Dynamic frameworkのShared schemeを含む、ディレクトリ階層で最初に見つかった.
VTAcknowledgementsViewControllerのStoryboardサポートを改善した - いけだや技術ノート
Pull requestしたらローカライズ依頼された - [yashigani days] などで知ったVTAcknowledgementsViewControllerというライブラリがあります。CocoaPodsが自動生成してくれる各ライブラリのライセンス表記をまとめたファイルをうまいことアプリ内で画面表示してくれる便利ライブラリです。 CocoaPodsが生成するファイル名は通常、Pods-acknowledgements.plistですが、Podfileで下記のようにターゲットを明示的に指定している場合、 # Podfile target "TargetName" do pod 'VTAcknowledgementsViewController' end 生成されるファイル名がPods-TargetName-acknowledgements.plistというように変わります。 ライブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
