この間の関西モバイルアプリ研究会#4でLazy stored propertyについて発表しました．
Lazy stored propertyについて大まかな使いドコロと，テスタブルな設計をする際にこいつを使うと依存の注入に使いやすいのではないか，というアイディアについて話しました．
簡単にまとめると，Lazy stored propertyを使えば，初めてアクセスするときまでインスタンスの生成が遅延されるので，それまでにテストの準備ができるよねということです．
lazy は最もすきなキーワードなのでめっちゃオススメです！
Twitterで@starfruits_jさんと@matuyujiさんにimplicitly unwrapped optionalなpropertyをlazyにしたときにnilを代入することで再度初期化処理が走ることを教えていただきました．
こういうかんじです．
optionalの場合は再度初期化されることはありません．
ドキュメントにもこういう動作するという記載は特に見つからないので，実装の都合で動作を騙せるのかもしれません．
関西モバイルアプリ研究会#2で「iOSアプリのコードレビューで最近気になるところ」という発表をしました．
コードレビューでよく指摘するようなことをまとめたのですが，まとめてみるとアプリを設計・実装するときに注意すべきこととほとんど変わらないような気がしました． けどコードレビューって言っておいたほうが意識高そうな感じがするのでコードレビューということにしています．
スライドだけ見てもあんまりわかんないとおもったけど，ブクマ集まってるわりに特に質問とか無いので特に補足はしません． 代わりにコードレビューのコツっぽいのをつけておきます．
ちょっと気にしていることを書いておきます． 筆者の経験に基づくポイントです．
こうしてください！って指摘するよりは理由を聞くようにしています． スライドの例を使うと，「この値はstoryboardで設定してください！」というよりは「この値もstoryboardで設定できますが，コードで設定している理由はありますか？」みたいな感じです(これはこれで誘導しすぎですけど)．
ピアレビューを続けていると普通相手も自分のレビュー方針みたいなのを自然に学びます． なので，にも関わらずそう実装されているのはなにがしかの理由があるはずですし，だいたいそういうときは悩んだ末の結果なので議論につながるのでより良い実装になることが多いです．
いいとおもったところはイイネとかポジティブな感想を書いたほうがいいです． 指摘ばかりしてると徐々に精神を病んでしまって，攻撃的になります． 相手のためだけでなく，自分のためにもよいところはほめたほうがいい結果になります．
雑談とわかるように雑談書いておくのはよくやります．
便利なタグは[雑談]，[感想]，[nit]です．
関モバの次回はWWDCやGoogle I/Oワイワイビールの会になりそうです． 楽しみですね！！！
先週ですが，毎度開催されている，Cocoa勉強会 #61でお役立ちテクニックを紹介しました． スライドはこちらです．
今回はこれというネタが無くて連発みたいなネタに走ってしまった… 次はなんとかいいネタを用意します．
_ObjectiveCBridgeableを実装してみたという話がおもしろかったです． 例えば，StringとNSStringは暗黙で変換される(Swift 1.2からは少し制限が追加された)秘密とかに迫る感じで非常に興味深い内容でした． スライドも紹介したかったけど見つけられなかった．
発表スライドを見るとわかるとおもうんですが，私はAutoLayoutがだいすきなんです． けれども，VFLはちょっと書きにくくてあまり使っていませんでした． それをカスタムオペレータを使った独自の記法で実現するという内容です． 普段使いにくいなーというVFLをプロダクトに取り入れやすくなりそうですし，実装も独自記法をVFLに変換しているだけなのでプロダクトに採用しやすそうなので今後に注目です．
ウメヨドでApple Watchを試着してきました． とにかく手元に届くのが待ちきれなくなりました． ちなみに予約したのはApple Watch Sport 38mm ホワイトモデルです．
iOS向けのアプリケーションやライブラリで画像やローカライズファイルなどのリソースを使うとき，bundleという仕組みを利用します．
bundleはアプリケーションやライブラリに組み込まれ，実行時に各リソースファイルとの橋渡しをします．
例えば，ローカライズに使うNSLocalizedStringマクロはこのように定義されています．
#define NSLocalizedString(key, comment) \ [[NSBundle mainBundle] localizedStringForKey:(key) value:@"" table:nil]
[NSBundle mainBundle]は実行中のアプリケーションbundleを返します．
tableが実際に使用されるローカライズファイルですが，nilだとデフォルトのLocalizable.stringsが利用されます．
NSLocalizedStringsはここから定義された文字列を探し，返すというわけです．
ここからはリソースにアクセスするためにbundleの仕組みが利用されていることがよくわかります．
[NSBundle mainBundle]リスク長らくiOSアプリではライブラリの組み込みにリンクでは無く，アプリケーションへ直接組み込むことが標準的な手法でした． しかし，WWDC2014においてiOSにもdynamic frameworkが解放されました． それに伴いCocoaPodsやCarthageなどの構成管理ツールもdynamic frameworkへの対応が進められています．
さて，先ほどのbundleですが，dynamic frameworkに対応するとどうなるのでしょうか？ frameworkを使うと，bundleはアプリケーションではなくそのframeworkそのものにbundleされます． つまり，frameworkを使った際はbundleからデータをロードする際，frameworkのbundleからリソースをロードするためにこのメソッドを使うことができません．
そこで，ライブラリ側でのbundleのロードについては，[NSBundle bundleForClass:]を利用することでうまくいきます．
let bundle = NSBundle(forClass: TheLibrary.self)
ライブラリで使っているクラスからbundleを特定することでframeworkのbundleにアクセスできます．
従来の方式でもbundleもろともアプリケーションに直接埋め込んでいたのですから，当然動作します([NSBundle mainBundle]と同じものが返ってくる)．
ローカライズや独自のリソースを使っているライブラリの多くは[NSBundle mainBundle]を使っているでしょう．
これは完全にcontributeチャンスですので，心当たりがあればすかさずcontributeいたしましょう．
筆者も既に2つのプロダクトにcontributeしております．
Swiftでコーディングしていると，型について色々と考えることがあります． 型の捉え方は学術的にも色々あるとおもいますが，このスライドは自分の経験から自分なりの捉え方なので，間違っていることや補足などあれば教えて下さい．
例に出しているResult<T>ですが，Swiftコンパイラの仕様でこのままではコンパイルすることができません．
このような型に包んで，Result<Box<T>>型にするか，@autoclosureで包むとコンパイルが可能になります．
class Box<T> { let value: T init(_ value: T) { self.value = value } }
最初に大きな声で挨拶したらなんか気持ちがアガってしまって，異様なテンションでプレゼンしてしまった． 完全に傾きすぎた…
次の発表「型」とかタイトルがカッコイイ。テーマもすごく興味深い。 #cocoa_kansai
— 熊谷 友宏 (@es_kumagai) 2015, 2月 28「なぜ型が必要なのか」。熱い。 #cocoa_kansai
— haranicle (@haranicle) 2015, 2月 28yashiganiさんめっちゃ盛り上がっててすごい #cocoa_kansai
— Hiroki Kato (@cockscomb) 2015, 2月 28禅みたいなものを感じる #cocoa_kansai
— Shin Ise (@iseebi) 2015, 2月 28(なんで怒ってるんだろうこの人..) #cocoa_kansai
— haranicle (@haranicle) 2015, 2月 28メモリ管理のための型は邪魔だったけど、プログラマのための型は嬉しいわけだな。 #cocoa_kansai
— KANEUCHI Tetsuya (@kaniza) 2015, 2月 28Objective-Cプログラマのための最高のSwift入門だった気がする #cocoa_kansai
— Hiroki Kato (@cockscomb) 2015, 2月 28型破りの例としてEither型のデータ構造を紹介しました．
これらのSwiftでの実装は以下のプロダクトが参考になります．
また，Either型のデータ構造については，すごいHaskellを楽しく学ぼう！でも詳しく紹介されていますので，詳しく知りたい方はそちらを参照されるのもいいとおもいます．
