まさか私がエンジニアになるなんて

調べてわからなかったこととつまらない日常をまとめる

清竜人25 解散について思うこと

清竜人のコンセプト oriented な作曲の裏にある深い音楽的知識によって、真新しくそれでいて音の運びに説得力のあるメロディーが生まれる。初めて聞いた時には、女性陣いらないのではとおもったのだが、声がセクシーで女たらしっぽい曲が最高に似合うので、一夫多妻制設定で美少女をはべらすことで女性にだらしないことへの説得力が自動的に生まれてとても良いユニットだっただけに解散が残念である。 個人的にはサザンオールスターズ路線で行ってほしい。

PV が youtube にありフルで聴けるのでどうぞ。

気づいたら解散ライブに申し込んでいた。物語の終わりを見届けねば。。。

社内で達人プログラマーを読む会やったら良かった話

達人プログラマーが新装版で発売されたことを機に、社内でお昼に希望者で達人プログラマーを少しずつ読んでディスカッションする会を行っています。

良かった所

  • 本に書いてある課題がディスカッションができる
  • お互いに思っていた課題を共有できる
  • 達人プログラマーを読んでいる辛さを軽減できる

本に書いてある課題がディスカッションができる

章ごとに「チャレンジ」ということで課題がのっているのですが、一人だと読み飛ばしがちなこういう箇所だと思います。その課題についてディスカッションすることで、他の方の考えやさらに関連する話題に触れられてとても勉強になります。

お互いに思っていた課題を共有できる

割れ窓理論の頁で、warning が放置されがちなのが悲しいという課題に対して、朝lint(朝早く来て一人で少しずつリファクタリングする) という習慣を取り入れたら良いよ、といったように課題の共有から、それに対する解決策が得られました。 本を題材にして密なコミュニケーションができるため、とても有意義な時間を過ごせました。

達人プログラマーを読んでいる辛さを軽減できる

優しい口調でさらっと恐ろしい理想論(しかも正論だから厄介)を押し付けてくる本なのですが、それを読んで、いやーやっぱりこの考え方は厳しいよね、という感想を共有できます。 一人で読んでると正直、うるせぇっ!ってなりそうな内容なのですが、みんなで読むため辛さがだいぶ軽減されます。 とは言え名著ですし、全員がこれを読んだ上でじゃあどうすべきか、ということが大事だと思うので、私個人としてはきちんと読める良い機会ができてとてもうれしいです。

終わりに

というわけで週に一回ほんとに少しずつ読み進めて行くことになりますが、これからも続けていきたいと思いました。

最後に、これは一人で読むには辛く、また、一人で読むにはもったいない本だと思います。 輪講の課題としてとても良いと思うので、複数人で読むことをおすすめしたいです。

似て非なる objectForKey, valueForKey, valueForKeyPath

objectForKey

Dictionary, NSDictionary, またそれを継承するクラスの固有のメソッド。 key を引数に与えることで、それに相当する object を返してくれる

valueForKey

KVC (key-value coding) に則って、 key から value を返してくれるメソッド。 Dictionary, NSDictionary にかぎらず、 NSArray などでも使える。

objective-c において気をつけてほしいのは、key にアクセスする際に @"" のように @ を使用すること。 @ をつけないと、

If key does not start with “@”, invokes objectForKey:. If key does start with “@”, strips the “@” and invokes [super valueForKey:] with the rest of the key.

のように、super クラスのメソッドを読んでしまい、意図せぬ値にアクセスしてしまう。

参考

https://developer.apple.com/reference/foundation/nsdictionary http://blog.kishikawakatsumi.com/entry/20100319/1268946432

valueForKeyPath

department.manager.name のように、. でアクセスする方法。 例として、json の返り値のように Dictionary の入れ子になっているものにアクセスする際に使える。

参考 https://developer.apple.com/jp/documentation/KeyValueCoding.pdf

Bool? の判定を1行で書くには

Bool? の ture, false 判定 を1行で書きたいときってありますよね。 hoge が Bool? だったとき、

hoge == true と hoge == false, hoge == nil のときとで分岐を分けたいときは

var hoge: Bool?

// hoge = false

if hoge ?? false {
    print("true")
} else {
    print("false or nil")
}

以下のように書けます。

warning : Unsupported Configuration: Prototype table cells must have reuse identifiers の解決法

UITableView を Storyboard を利用して作るときによく出るこの warning

Unsupported Configuration: Prototype table cells must have reuse identifiers

要は、 Prototype table cells なのに reuse identifiers が無いということです。

この解決方法は2つあります。

  1. reuse Identifiers を追加する
  2. Prototype table cells じゃなくする

reuse Identifiers を追加する

Storyboard とコードを組み合わせて、動的にセルの中身を変えたいならこちらです。

tableViewCell を選択し、右ペインの↓から Identifier を追加します。

f:id:nano-041214:20161005112541p:plain

するとワーニングが消えます。

あとはコード上で cellForRowAtIndexPath で dequeueReusableCell(withIdentifier identifier: String) の identifier に 先程指定した Identifer 与えることで、 cell を取得できます。

Prototype table cells じゃなくする

Storyboard 上で完結するタイプのテーブルビューならこちらで良いでしょう。

Storyboard 上で tableView を選択し、右ペインの↓から

f:id:nano-041214:20161005112221p:plain

Content > Dynamic Prototypes を Static Cells に変更します。

Symbol(s) not found for architecture i386 エラーと戦う

Carthage x swift x unitTest の始め方。

Carthage のライブラリを用いて iOS のテストを Swift で書いてみよう! と、思いたち、 UnitTest を書いてみました。 しかし、simulator で run は問題なく動くのに、 test を実行すると import しているライブラリが引っ張ってこれず build が成功しないということで数時間詰まっておりました。

test を実行した際のエラー文がこちら

Undefined symbols for architecture i386:
ld: symbol(s) not found for architecture i386
{library_name}: ld returned 1 exit status

スクリーンショットが豊富なまとめがなかなかなかったので、自分なりにまとめてみました。

環境

Xcode 7.3.1, Swift 2.2, Carthage 0.18 このまとめでは、 Carthage で入れたライブラリが Target が test の場合でも機能するための方法を書いております。

考えられる原因

  1. ライブラリが i386 の architecture に対応していない
  2. Target が Test である BuildPhase がきちんと設定されてない

ライブラリが architecture に対応していない

  • simulator と iPhone などの実機とでは CPU が違うため、同じコードでもコンパイルの結果が違います
  • そのため、project を run することはできても、テスト用に build することはできません

対応していないか確認する方法

f:id:nano-041214:20160923185015p:plain

スクリーンショットのように、Carthage/Build/iOS/{framework}/modules/{module}/ 以下に、該当する CPU のビルドがあるかチェックでkます。

ないようならライブラリのページでその CPU のビルドを配布しているかみてみると良いです。

Target が Test である BuildPhase がきちんと設定されてない

おそらくこれで大多数の人はどうにかなるはずです。

画像の箇所を、テストでない方の target と同様の 設定すればオッケーです。 script の内容は環境によって違うと思うので、画像の通りが必ずしも良いとは限りません。

f:id:nano-041214:20160923185018p:plain

ついでに

あとは、テスト内で利用するクラスで、Target Membership の HogeTests にチェックを入れれば動くはずです。

f:id:nano-041214:20160923185019p:plain

最後に

自分の脳の想定よりテストの方が信じられるので、積極的にテストを書いていきたい気持ちです。