清竜人25 解散について思うこと
清竜人のコンセプト oriented な作曲の裏にある深い音楽的知識によって、真新しくそれでいて音の運びに説得力のあるメロディーが生まれる。初めて聞いた時には、女性陣いらないのではとおもったのだが、声がセクシーで女たらしっぽい曲が最高に似合うので、一夫多妻制設定で美少女をはべらすことで女性にだらしないことへの説得力が自動的に生まれてとても良いユニットだっただけに解散が残念である。 個人的にはサザンオールスターズ路線で行ってほしい。
PV が youtube にありフルで聴けるのでどうぞ。
気づいたら解散ライブに申し込んでいた。物語の終わりを見届けねば。。。
Xcode のデバッガで console に UIKit を読み込む方法
備忘録として
(lldb) po @import UIKit
とすると読み込めます。
(lldb) po [[NSString alloc] initWithData:userInfo[@"com.alamofire.networking.complete.finish.responsedata"] encoding:NSUTF8StringEncoding]
こういうときに使えます!
社内で達人プログラマーを読む会やったら良かった話
達人プログラマーが新装版で発売されたことを機に、社内でお昼に希望者で達人プログラマーを少しずつ読んでディスカッションする会を行っています。
良かった所
- 本に書いてある課題がディスカッションができる
- お互いに思っていた課題を共有できる
- 達人プログラマーを読んでいる辛さを軽減できる
本に書いてある課題がディスカッションができる
章ごとに「チャレンジ」ということで課題がのっているのですが、一人だと読み飛ばしがちなこういう箇所だと思います。その課題についてディスカッションすることで、他の方の考えやさらに関連する話題に触れられてとても勉強になります。
お互いに思っていた課題を共有できる
割れ窓理論の頁で、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
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つあります。
- reuse Identifiers を追加する
- Prototype table cells じゃなくする
reuse Identifiers を追加する
Storyboard とコードを組み合わせて、動的にセルの中身を変えたいならこちらです。
tableViewCell を選択し、右ペインの↓から Identifier を追加します。
するとワーニングが消えます。
あとはコード上で cellForRowAtIndexPath で dequeueReusableCell(withIdentifier identifier: String) の identifier に 先程指定した Identifer 与えることで、 cell を取得できます。
Prototype table cells じゃなくする
Storyboard 上で完結するタイプのテーブルビューならこちらで良いでしょう。
Storyboard 上で tableView
を選択し、右ペインの↓から
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 の場合でも機能するための方法を書いております。
考えられる原因
- ライブラリが i386 の architecture に対応していない
- Target が Test である BuildPhase がきちんと設定されてない
ライブラリが architecture に対応していない
- simulator と iPhone などの実機とでは CPU が違うため、同じコードでもコンパイルの結果が違います
- そのため、project を run することはできても、テスト用に build することはできません
対応していないか確認する方法
スクリーンショットのように、Carthage/Build/iOS/{framework}/modules/{module}/ 以下に、該当する CPU のビルドがあるかチェックでkます。
ないようならライブラリのページでその CPU のビルドを配布しているかみてみると良いです。
Target が Test である BuildPhase がきちんと設定されてない
おそらくこれで大多数の人はどうにかなるはずです。
画像の箇所を、テストでない方の target と同様の 設定すればオッケーです。 script の内容は環境によって違うと思うので、画像の通りが必ずしも良いとは限りません。
ついでに
あとは、テスト内で利用するクラスで、Target Membership の HogeTests にチェックを入れれば動くはずです。
最後に
自分の脳の想定よりテストの方が信じられるので、積極的にテストを書いていきたい気持ちです。