https://t.co/zjsOmpBksl これで知ったけどCirrus CIというのが出てきてたんですね https://t.co/WooquNGmWc https://t.co/vYIIg0DhYr
— いけしょー@本書きました (@ikesyo) 2018年2月14日
OSSプロジェクトなら無料で使える https://t.co/9cGE7mz11y
— いけしょー@本書きました (@ikesyo) 2018年2月14日
https://t.co/zjsOmpBksl これで知ったけどCirrus CIというのが出てきてたんですね https://t.co/WooquNGmWc https://t.co/vYIIg0DhYr
— いけしょー@本書きました (@ikesyo) 2018年2月14日
OSSプロジェクトなら無料で使える https://t.co/9cGE7mz11y
— いけしょー@本書きました (@ikesyo) 2018年2月14日
SwiftLint 0.22で追加された multiple_closures_with_trailing_closure
というルールをご存知でしょうか。これは次のような複数のクロージャを引数に取るAPIを使用する時に、最後の引数のクロージャをTrailing Closureとして渡すことを警告するというルールです。
func fetch(id: Int, success: () -> Void, failure: (Error) -> Void) { ... } // NG fetch( id: 12345, success: { print("success") } ) { error in print("error: \(error)" } // OK fetch( id: 12345, success: { print("success") }, failure: { error in print("error: \(error)")} )
こうしたAPIでは最後のクロージャだけ引数ラベルが落ちてしまうと、各引数の間の対称性がなくなってしまってコードが読みにくくなってしまいそうです。普段よく使うであろうAPIとしては UIView.animate(withDuration:animations:completion:)
が挙げられると思います。
// With trailing closure UIView.animate( withDuration: 0.3, animations: { ... } ) { finished in ... } // Without trailing closure UIView.animate( withDuration: 0.3, animations: { ... }, completion: { finished in ... } )
さて、Lintで利用者側がこうした使用方法を警告・禁止できるとしても、ライブラリの提供者側で禁止することはできないでしょうか。以下に1つのアイデアを示してみようと思います。
func fetch(id: Int, success: () -> Void, failure: (Error) -> Void, _ tcDisabler: () = ()) { ... }
考え方としては単純で、クロージャが最後の引数にならないようにしてあげるだけですね。意味のない値をデフォルト引数として設定しておくことで、利用者サイドは特に気にせずに利用できるはずです。引数名や値に考える余地はありそうですが、他にもいい手段がないか、ご意見お待ちしています。
Xcodeのブレークポイントでは音を鳴らすことができて、これは結構便利です。例えばシミュレーターの動作を目で確認する一方で、ブレークポイントを通過したかどうかは耳で確認することができます。シミュレーターの画面を見ながらコンソールのログを追うのは大変ですからね。
また "Automatically continue after evaluating actions" という実行を停止させないオプションと組み合わせるとさらによいですね。ちなみに僕は "Frog" の音が好きです。
これは便利なので仕事中にもたまに使うことがありますが、その時には当然Macのミュートを解除する必要があります。そうすると今度はデバッグの最中にメールやSlackの通知音がオフィスに鳴り響いたりしてちょっとやりづらい。なのでデバッグを始めようとすると、いそいそとイヤホンをMacにつなぎ出すようになっているここ最近です*1。
AirPodsでも買ったらいいんでしょうか。
Apple AirPods 完全ワイヤレスイヤホン Bluetooth対応 マイク付き MMEF2J/A
*1:仕事中に音楽は聞かないタイプです
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のoverlay)。こう聞くと、SDK overlayが少しは身近に感じられないでしょうか。
ここで話は変わります。Swiftの標準ライブラリに次ぐコアライブラリであるFoundationはObjective-Cで実装されているため、そのままではLinuxなどのDarwin以外のプラットフォームでは使用できません。これではせっかくSwift自体がLinuxに対応しても、種々の機能不足に悩まされたり、クロスプラットフォームのライブラリの開発に支障をきたしてしまいます。
この状態を解消するために、SwiftのOSS化と共に公開されたのがswift-corelibs-foundationです。このリポジトリは、FoundationのベースとなっているCoreFoundationというC実装のフレームワークを使い、FoundationをSwiftで再実装するというものです。
さて、Foundationの再実装と聞いて気になった人はいないでしょうか?Objective-C版のFoundationへの追加レイヤーであったoverlayはどうなるのでしょうか。答えは、Foundation overlayはswift-corelibs-foundationの側でも実装される必要があるのです*2。
こうして、apple/swiftとswift-corelibs-foundationの間でFoundation overlayの実装を同期する必要が出てきます。例えばNSStringAPI.swift
のコメントに書かれているように、一方を更新したらもう一方を更新するのを忘れないようにしなければなりません。実際、一方にプルリクエストを出すと、もう一方にもプルリクエストを出してくれとレビュワーからも依頼されることがあります。
とはいえ人間忘れてしまうもので、どうしても内容の乖離は発生しています。しかしこれは見方を変えればコントリビューションチャンスですね!?
2つのリポジトリ間での差分を見つけて、より新しい方の内容をもう一方に反映することは、SwiftのOSSプロジェクトに参加する一歩目としては比較的とっかかりやすいと思います。Foundationに興味があるあなた、まずはここから始めてみませんか?
この記事を機に、Swiftで開発するだけでなく、Swiftを開発することに興味を持つ、取り組んでくれる人が増えれば幸いです。数少ない日本のSwiftコミッターからは以上です。
この記事ははてなエンジニア Advent Calendar 2017の9日目の記事です。
昨日8日目はid:aerealさんの大コンテナ時代を生きのこるためのJSON Schemaでした。
明日10日目はid:nanto_viさんの担当です!
*1:SE-0069: Mutability and Foundation Value Types
*2:後者においては実装の一部となるため、overlayとは呼ばないのですが。
技術書クラウドファンディングのPEAKSのプロジェクトとして成立した『iOS 11 Programming』に、執筆陣の一人として参加させていただき、先日完成を迎えることができました。また本日からクラウドファンディング参加者に限らない一般販売が開始されました。
個人的には昨年の『WEB+DB PRESS Vol.96』の特集に続き、二度目の執筆活動となりました。この時は特集約30ページを一人で書き上げるのにかなり苦労した思い出があります。今回は一冊の技術書ですが、1・2章程度の粒度で分担して書くのは、単著を書くよりもかなりハードルが低く、また他の著者陣が書き上げていくのに刺激されて自分もやらなければ!という気持ちにさせてくれるので、とてもいいやり方だなぁと感じました。
これを読んだ皆さんも応募フォームから書いてみたい、読んでみたい、といったリクエストをどんどん投げつけてみましょう!
僕は「第4章 Swift 4の新機能とアップデート」を担当しました。Codable
では実装の自動生成が大きなポイントの1つですが、仮にもSwiftコミッターなので、コンパイラーの自動生成部分のコードも読み込みながら挙動を把握し、丁寧に解説しようとしました。自動生成と手動実装を下手に混ぜると危ういといった注意点も書きたかったことの1つですね。
またSmart KeyPathsについては、基本的な使い方はそんなに困らないだろうという前提で、より掘り下げたクラス階層やジェネリクス的な視点、read-onlyかread-writeか、といった点に着目しています。
すでにSwift 4に移行済みの人も少なくないとは思いますが、これらの機能はSwift 3.2モードでも使用可能です。なのでSwift 4に移行前でもどんどん使っていって、皆で色んな知見を溜めていけるといいですね。
どうぞお買い求めください 🙏
普段は京都や大阪で開催されている関モバが東京に上陸した!ということで発表してきました。
UISearchBar
/ UISearchController
は結構カスタマイズしにくかったり、iOS 10とiOS 11で見た目が大きく変わり得たり、iOS 11で追加された UINavigationItem.searchController
によるナビゲーションバーとの統合も実運用で困る箇所があったりと、皆さんどうですか?という話をしたかったのです。会場での結論としては、カスタマイズする必要があれば、これらを使うのを諦めて UITextField
をそのまま使って自分でカスタマイズする方がいいですね、という話に落ち着いてよかったよかった 😇
他の発表内容はこちらからどうぞ 👇
WWDC会場のSan Jose McEnery Convention CenterからHimotoki 3.1.0をお届けします。
このリリースではパフォーマンス改善と、Xcode 9への対応(テストコード)が主になります。
Xcode 9で使用できるSwift 3.2 / Swift 4.0では、SE-0166により追加された Foundation.Decodable
が Himotokiの Decodable
とそのままでは衝突してしまうようになったため、今後は常に Himotoki.Decodable
と記述することを推奨します。
Himotoki、Decodableが衝突するのでどうしたものか
— Syo Ikeda / いけしょー (@ikesyo) 2017年6月6日
一旦Himotoki.Decodableに書き換えて対応しました https://t.co/xFpZsFjXj8
— かっくん (@fromkk) 2017年6月6日