yashiganiの英傑になるまで死ねない日記

週末はマスターバイクでハイラルを走り回ります

iOSアプリのコードレビューについて話しました #関モバ

関西モバイルアプリ研究会#2で「iOSアプリのコードレビューで最近気になるところ」という発表をしました．

kanmoba.connpass.com

コードレビューでよく指摘するようなことをまとめたのですが，まとめてみるとアプリを設計・実装するときに注意すべきこととほとんど変わらないような気がしました． けどコードレビューって言っておいたほうが意識高そうな感じがするのでコードレビューということにしています．

speakerdeck.com

スライドだけ見てもあんまりわかんないとおもったけど，ブクマ集まってるわりに特に質問とか無いので特に補足はしません． 代わりにコードレビューのコツっぽいのをつけておきます．

コードレビューするときに最近ちょっと気にしてること

ちょっと気にしていることを書いておきます． 筆者の経験に基づくポイントです．

1. 理由を聞く

こうしてください！って指摘するよりは理由を聞くようにしています． スライドの例を使うと，「この値はstoryboardで設定してください！」というよりは「この値もstoryboardで設定できますが，コードで設定している理由はありますか？」みたいな感じです(これはこれで誘導しすぎですけど)．

ピアレビューを続けていると普通相手も自分のレビュー方針みたいなのを自然に学びます． なので，にも関わらずそう実装されているのはなにがしかの理由があるはずですし，だいたいそういうときは悩んだ末の結果なので議論につながるのでより良い実装になることが多いです．

2. ほめる

いいとおもったところはイイネとかポジティブな感想を書いたほうがいいです． 指摘ばかりしてると徐々に精神を病んでしまって，攻撃的になります． 相手のためだけでなく，自分のためにもよいところはほめたほうがいい結果になります．

3. 雑談を書く

雑談とわかるように雑談書いておくのはよくやります． 便利なタグは[雑談]，[感想]，[nit]です．

関モバの次回はWWDCやGoogle I/Oワイワイビールの会になりそうです． 楽しみですね！！！

Cocoa勉強会関西でお役立ちテクニック3連発という発表をしました #cocoa_kansai

先週ですが，毎度開催されている，Cocoa勉強会 #61でお役立ちテクニックを紹介しました． スライドはこちらです．

今回はこれというネタが無くて連発みたいなネタに走ってしまった… 次はなんとかいいネタを用意します．

おもしろかった発表を紹介

熊谷友宏さん「Swiftカジュアルプログラミング（基礎）不変値と可変値」

_ObjectiveCBridgeableを実装してみたという話がおもしろかったです． 例えば，StringとNSStringは暗黙で変換される(Swift 1.2からは少し制限が追加された)秘密とかに迫る感じで非常に興味深い内容でした． スライドも紹介したかったけど見つけられなかった．

matuyuji さん「Visual Format Languageを簡単に書けるSwiftライブラリyavfl」

発表スライドを見るとわかるとおもうんですが，私はAutoLayoutがだいすきなんです． けれども，VFLはちょっと書きにくくてあまり使っていませんでした． それをカスタムオペレータを使った独自の記法で実現するという内容です． 普段使いにくいなーというVFLをプロダクトに取り入れやすくなりそうですし，実装も独自記法をVFLに変換しているだけなのでプロダクトに採用しやすそうなので今後に注目です．

勉強会後のおたのしみ

ウメヨドでApple Watchを試着してきました． とにかく手元に届くのが待ちきれなくなりました． ちなみに予約したのはApple Watch Sport 38mm ホワイトモデルです．

顕在化するmainBundleリスク

iOS

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しております．

参考

Cocoa勉強会関西でSwiftの型について発表しました #cocoa_kansai

Swift

Swiftでコーディングしていると，型について色々と考えることがあります． 型の捉え方は学術的にも色々あるとおもいますが，このスライドは自分の経験から自分なりの捉え方なので，間違っていることや補足などあれば教えて下さい．

スライドの補足

例に出しているResult<T>ですが，Swiftコンパイラの仕様でこのままではコンパイルすることができません． このような型に包んで，Result<Box<T>>型にするか，@autoclosureで包むとコンパイルが可能になります．

class Box<T> {
    let value: T
    init(_ value: T) { self.value = value }
}

反省

最初に大きな声で挨拶したらなんか気持ちがアガってしまって，異様なテンションでプレゼンしてしまった． 完全に傾きすぎた…

反響を紹介します

参考資料

型破りの例としてEither型のデータ構造を紹介しました． これらのSwiftでの実装は以下のプロダクトが参考になります．

また，Either型のデータ構造については，すごいHaskellを楽しく学ぼう！でも詳しく紹介されていますので，詳しく知りたい方はそちらを参照されるのもいいとおもいます．

すごいHaskellたのしく学ぼう!

すごいHaskellたのしく学ぼう!

初めてエンジニア面接をすることになって準備したことと反省

photo by MDGovpics

技術面接を担当する機会があった． 今まで，面接されることはあってもする側になるのは初めて． 短い時間でよい成果を得るため，事前に色々と準備をしてから望むことにした．

最初に

面接といえば質問だ． 逆に言うと質問の集合が面接と言っても差し支えない． そこでなにを質問すべきか考えた．

採用面接の目的は一緒に働く仲間(を増やす|になる)ということだ． つまり，お互いに一緒に働きたいと感じるエンジニアなのかを判断できればパーフェクトコミュニケーションと言えるだろう．

事前準備

会話は3往復くらいさせると深く人となりがわかるらしい． なにも用意しないとそんなのは絶対無理なので，事前に質問を用意しておく．

エンジニアの場合，応募資料はだいたい以下の2つがある．

この2つからエンジニア像を作りつつ，質問したいことを用意した．

ブログやGitHub

ここから掴みたいのは2つ．

  • だいたいのエンジニア像(実力・考え方)
  • 最近どういうことに興味を持っていそうか

興味を持ったエントリがいくつあるかとか，どういうときにハマったかとかを注意深く観察し，どういうエンジニアなのかイメージを作っておく． あと，それとなく興味がありそうなことを掴んでおくと話の節々で盛り上がりそうなのでメモしておく．

職務経歴書

質問はなるだけここに書いてあることから作った． なぜなら，職務経歴書に書くくらいなんだからアピールしたいに決まってる．

そこで，実際のエピソードを詳しく引き出す準備をする． 自分なら聞いてほしいのは以下の3つ．

  • なぜそれをしたのか(why)
  • どうやってやったのか(how)
  • よかったこと/悪かったことや反省点

少なくとも3往復はできそう．助かった．

エピソードについて深く聞くことで，事前資料から作ったエンジニア像を修正していく． 仕事でのエピソードはブログなどで書いてることとも関連があるはずなので，エントリ時点からどういう風に見解が変わったのかも注目したい．

ここまでで聞きたいことリストを作ることができる． あとは，ひとつのトピックについてLTぶんくらい話すと満足できそうなので5分話すとして，自分の持ち時間を考慮しつつ優先順位をつけておいた．

実践

面接を受ける人も自分を見て職場を選んでいることを念頭にコミュニケーションをとる． ここではガチガチに予定通りというわけではなく，できるだけ盛り上がるほうに転がす． そのほうが楽しいし，本音も出そうだからだ． 臨機応変に質問の順番を変えてもいい．

面接後の評価

応募資料と面接とのギャップを元に評価するのがいいと感じた． 最終的に一緒に働きたい度でフィードバックすることにした．

反省

技術的雑談レベルで盛り上がるとまではいかなかったけど，わりと深く話を聞くとこができた． 細かい修正はあれど基本的な技術面接のスキームとして使えそうだとおもったので今後も実践していきたい．

いやいや，もっとこうやったらいいよ！ってのがあればアドバイスください．