読者です 読者をやめる 読者になる 読者になる

Carthage 0.12をリリースしました

Carthage Cocoa Swift iOS OS X

昨年のエントリーに書いたように、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

これまでCarthageでは、Dynamic frameworkのShared schemeを含む、ディレクトリ階層で最初に見つかった.xcodeproj/.xcworkspaceのプロジェクト1つだけをビルドの対象としていました。https://github.com/ankurp/Dollar.swiftのような複数.xcodeprojによって複数のframeworkを提供するようなリポジトリとは相性が悪かったのですが、0.12ではDynamic frameworkのShared schemeを含んでさえいれば、全てのプロジェクトがビルド対象になるよう変更、改善されました。

archive now accepts multiple framework names and will archive all the frameworks from the current repository if no names are given

archiveコマンドはCarthage/Build以下にあるframeworkをまとめたzipファイルを生成するコマンドです。生成したzipファイルをGitHub Releaseに添付することで、Carthageがビルド済みバイナリーとしてそのframeworkを利用することができるようになっています。

これまでこのコマンドはcarthage archive Himotokiのように、アーカイブ対象のframework名を必ず1つだけ指定する必要がありました。それが0.12からはcarthage archive Cent Dollarのように複数のframework名を指定することができるようになりました。

またcarthage archiveとパラメーターを指定しないと、現在のプロジェクトのframeworkを全てアーカイブする(依存先のframeworkは含まない)、という使い方もできるようになっています。この場合の対象はcarthage build --no-skip-currentとしてビルドされるようになるものと同一です。1つ目の変更と合わせて使いやすくなったのではないかと思っています。😀

この変更は私が実装したものになります 💪

build, checkout, and update now take an optional list of dependencies

最後の1つです。今まではcarthage updateとして全ての依存ライブラリーをアップデートすることしかできませんでしたが、これも0.12からarchiveコマンドと同様に、carthage update Alamofire ReactiveCocoaのようにアップデート対象を指定することができるようになりました。

build, checkoutコマンドもこの改善をしていて、carthage build Alamofireのように特定のfraemworkのみを再ビルドすることもできます。これらはかなり以前から要望されていたものだったので、実装、リリースすることができてとても嬉しいですね。

この変更も私が実装しました 💪


すでに幾つかバグが報告されているため、近々0.12.1もリリースされると思います。Carthageユーザーの皆様におかれましてはバグ報告や要望など何かあれば、リポジトリのissueだけでなく、Twitterなどでも連絡いただければ確認しますのでお気軽に!

株式会社はてなに入社しました

関モバ はてな

新年明けましておめでとうございます。年末のエントリーaikoの年越しライブ直前と言っていたid:ikesyoです。結局ライブが終わったのは2時過ぎ、帰宅したのは4時過ぎでした。そんな私ですが、今年もよろしくお願いいたします。

2016年1月1日付けで株式会社はてなに入社しました。昨日1月4日が初出社でした。id:takuji31とは同期入社になりますね。

blog.takuji31.jp

Why

大学時代からはてなへの興味はありましたが、その時点ではエンジニアとしての技術力はなく、そこに挑戦することは現実的ではありませんでした。東京でSIer/システムコンサルに就職して、関西に戻ってきて、フリーランスとして4年半程過ごして、フリューさんでのお仕事の機会をいただいて、と紆余曲折の末にご縁があって入社となりました。久し振りに正社員に復帰です。大体関モバのせい。

What

アプリケーションエンジニアとして、引き続きiOSアプリの開発をメインに行なっていくことになります。仕事とOSS活動の両輪を上手く回してもいきたいところです。そして対外活動面でも、まず大きなところではtry! Swiftでの発表や参加者との交流、他の登壇者の発表内容を吸収してチーム・社内に持ち帰ってシェアしていくことを頑張ることになりそうです。

技術偏重にならずにユーザーにちゃんと価値を届けるぞ!!

Want

恒例の。よろしくお願いいたします。m(__)m

www.amazon.co.jp

Conclusion

初日から有志の方々による非公式歓迎会で飲んでいた。飲み過ぎないように気を付けるぞ!!

2015年を振り返ってみる

iOS ReactiveCocoa library Carthage

2015年も残すところあと数時間。aikoの年越しライブ Love Like Pop 18に向かっている途中/開演待ちに書いています。

色んなところで振り返りエントリーが流れているので、自分も振り返ってみようかと書いてみます。

フリュー

昨年10月から業務委託としてフリュー株式会社のとある部署・チームに参画し、Swift/ReactiveCocoaをベースにiOSアプリの開発をしていました。Swiftのバージョンアップへの追従、非同期処理周りをBoltsからReactiveCocoaに置き換えるなどはかなり気合いで進めました。後述しますが、自作のHimotokiというライブラリーもこのアプリで本番投入しています。また環境面ではGitHubでPRベースでのレビュー体制やSlackをそれなりに働きかけて導入してもらったり、4KディスプレイやMBPのスタンドを用意してもらったり、チームメンバーも含めて非常にいい環境で仕事をさせてもらうことができました。

こちらについては去る12月25日が最終出社日でした。1月からの活動には乞うご期待。

関西モバイルアプリ研究会

今年はここへの参加がかなり大きなトピックでした。記念すべき第1回に id:yashigani_w さんから声をかけてもらってLT参加し、以来12月の第9回まで皆勤で参加させてもらっています。これまでTwitterでは知っていたiOS開発者の方々、交流のなかったAndroid界隈の方々と絡む機会ができたのもこの会のお陰です。来年の関モバにも期待していきましょう!

Himotoki

SwiftJSONデコード用のHimotokiというライブラリーを開発、5月に公開しました。それなりの規模のライブラリーを公開したのはこれが初めてで、現時点で300を超えるスターが付いているのはなかなか頑張れたかな、と思っています。関モバでも布教LTをしたり、国内で色んな所で使ってもらえているような話を聞くので、今後もちゃんとメンテナンス、Swiftのバージョンアップ追従を頑張っていく所存です。

ちなみにこれを作るまではObjectMapperというのを使っていたんですが、以下のやり取りで自分で作ってみようと思い立つことができました。@_ishkawa さんに感謝🙏

Carthage/ReactiveCocoa

昨年後半に登場し、今年1年でかなり普及した感のあるCarthageですが、PRを幾つか重ねている内にコミッターになりました。今年6月のことです。

最近のリリースでは結構多くの貢献を自分がしている状態だったりします。今後も開発者のための効率向上を目指してコミッター業をしっかりやっていくつもりなので、バグレポートや分からないところがあればお問い合わせいただければと。

またCarthageにも使われているReactiveCocoaのコミッター業も細々と続けています。元々CarthageはSwift版のRAC 3.0のショーケース/実践投入によるAPI洗練のためでもあったので、RAC側のバグ修正をすることもしばしばありました。RxSwiftだけでなく、RACもぜひぜひ試してほしいですね。

来年

先かと思っていたらあと2ヶ月程度になってしまいました。来る3月2日(水)〜4日(金)に東京・渋谷で行われるtry! Swiftカンファレンスに登壇します!!それも初日のトップバッターというとても緊張する発表順になりました。

国内では初めての大規模なSwiftに関するカンファレンス、それも海外からの多数の登壇者やオープンソース化後初めてのカンファレンスということもあり、非常にエキサイティングな3日間が過ごせるのではととてもワクワクしています。😄

スーパーSwift早割は終わってしまっていますが、まだSwift早割のチケット、また1日チケットも用意されているので、沢山の参加者にお会いできることを楽しみにしています。🙇🏻

まとめ

年越しライブ楽しんでくるぞ!!

関西モバイルアプリ研究会 #5 でCarthageの話をしてきました #関モバ

Carthage Cocoa iOS library 関モバ Swift

毎月恒例の関西モバイルアプリ研究会 #5で今回も発表させていただきました。会場と🍻に軽食を提供してくださるはてなさんに多謝 🙏

今回の資料はこちら。

CocoaPodsと並ぶ依存性管理ツールとして普及が進みつつあるCarthageですが、READMEにあまり情報がないCLIのコマンドのオプションや次期バージョンに入る予定の最新動向などについて紹介しました。

以前のエントリーでお話したように、今はCarthageのコミッターとして活動していることもあって現時点で46個ほどのPRを出していました。

今回の発表で知ってもらいたかったことの1つがGitHub Enterpriseのサポートです。

github "https://enterprise.local/ghe/desktop/git-error-translations"

という書き方でgithub.com上のリポジトリと同様にビルド済みバイナリーのダウンロードなどが機能するようになっています。現在 0.8: Llama Calculus が最新リリースですが、こちらは次期リリースに入るはずなのでGitHub Enterpriseを利用しているエンジニア・企業の方々は乞うご期待。

その他皆さんの発表資料などは以下からどうぞ!

kanmoba.connpass.com

おまけ

fabricの発表をしてくださったTwitterの中の方々からスピーカー特典としてスピーカーをいただきました!ありがとうございました!! ✨

関西モバイルアプリ研究会 #4 でLTしてきました #関モバ

Cocoa iOS library CocoaPods Carthage Swift 関モバ

第1回から参加させていただいている関西モバイルアプリ研究会 #4でLTをしてきました。なんだかんだでGoogle I/OWWDC 特別会だった#3以外の3回全てで発表できていて嬉しい限りです! 💖

以下が発表スライドです。

OS Xでは以前から使えたものの、iOSではiOS 8からやっと使えるようになったDynamic FrameworkをどうやってXcodeプロジェクトに導入するのか、という選択肢・手順についてまとめてみました。

またiOS 7ではDynamic Frameworkが使えず、そのままではSwift製のライブラリを導入するのが結構辛いのですが、その辺を簡単に導入してくれるCocoaSeedsというツールについても少しだけ触れてみました(まだあんまり知られてない)。

発表後にFrameworkのコード署名周りの話を @griffin_stewie さんとしていたんですが、Frameworkをアプリターゲットに導入する際に“Embed Frameworks”ビルドフェーズの各リスト項目で“Code Sign On Copy”というチェックボックスをオンにしておけば、アプリ用のコード署名設定でFrameworkが再署名されるので、Framework自体のコード署名はiPhone Developerの適当なものでも構わない、という知見を共有することもできたので、発表した甲斐がありました! 😄

次回の関モバ #5は2015/8/26(水)開催とのことでした 🚀

その他皆さんの発表資料などは以下からどうぞ!

kanmoba.connpass.com

itok.jp

usami-k.hatenablog.com

yashigani.hatenablog.com

Carthageのコミッター(Collaborator)になりました

iOS ReactiveCocoa Swift Cocoa library OS X

先月の2015年6月に、CarthageというCocoaプラットフォーム(iOS/OS X/watchOS)用の依存性管理ツールコミッター(Collaborator)になりました

このプロジェクトは元々ReactiveCocoa 3.0APIを洗練させるためのショーケースとして始まったという側面もあり、ReactiveCocoaのCollaboratorとしては当然注目していました。Carthage v0.6.5からv0.7へのバージョンアップ時に、Swift 1.1から1.2への移行、それに伴うReactiveCocoaのアップデートがあったんですが、そこでRACAPI/設計が大きく変わったことで結構なバグが発生してしまっていました。それらのバグなどを調査・修正して色々とcontributeしている内にinviteしてもらった、という次第です。

RAC 3に慣れていないとなかなか修正し辛いコードベースなのは確かだと思うので、RACのCollaboratorでもあることを活かして貢献していくつもりです。Carthageユーザーで何かお困りの方はこのブログや@ikesyo経由で是非フィードバックをいただければと思っています。

Swiftでジェネリックなメソッドの特殊化を行う方法

Swift iOS

今日色々とやり取りをしながら、Swiftでのジェネリックメソッドについてある知見を得たのでまとめておきます。

以下のようなSwiftの型・ジェネリックメソッドがある時、このままでは型指定(特殊化)が面倒になってしまいます。

class Hoge {
    class func genericMethod<T: Request>(callback: T -> Bool) {
        ...
    }
}

// 呼ぶ時
Hoge.genericMethod { (x: SomeRequest) in true }

上記のような場合、型情報のヒントが与えられないのでクロージャでパラメータの型を明示しないといけません。引数にTインスタンス・値を渡す場合は型推論が効くし、以下のように型自体がジェネリックな場合は初期化時に明示的に特殊化が出来るのですが。。

class Generic<T> {}

let generic = Generic<String>()

このようなケースでは、メソッドのパラメータとして型自体を渡させるようにするとそれが型のヒントとなりクロージャで型指定を行う必要がなくなります。

class Hoge {
    class func genericMethod<T: Request>(type: T.Type, callback: T -> Bool) {
        ...
    }
}

// 呼ぶ時
Hoge.genericMethod(SomeRequest.self) { x in true }

振り返ってみればObjective-CではこのようにClassをパラメータで渡すことも多かった気がしますね。

このパターンを使うと、例えばUITableViewCellのdequeueが以下のように出来、キャストが不要になります。

extension UITableView {
    func registerNibForClass<T: UITableViewCell>(type: T.Type) -> UINib {
        let nib = UINib(nibName: type.nibName(), bundle: nil)
        registerNib(nib, forCellReuseIdentifier: type.reuseIdentifier())
        return nib
    }

    func dequeueCell<T: UITableViewCell>(type: T.Type, forIndexPath indexPath: NSIndexPath) -> T {
        return dequeueReusableCellWithIdentifier(type.reuseIdentifier(), forIndexPath: indexPath) as T
    }
}

extension UITableViewCell {
    class func simpleClassName() -> String {
        return NSStringFromClass(self).componentsSeparatedByString(".").last!
    }

    class func nibName() -> String { return simpleClassName() }

    class func reuseIdentifier() -> String { return simpleClassName() }
}

let cell = tableView.dequeueCell(HogeCell.self, forIndexPath: indexPath)

Javaとかでは出来たような気がしますが Hoge.genericMethod<SomeRequest> { x in true } みたいにメソッドコール時に明示的に特殊化が出来ればいいんですけどね。