2012年3月27日火曜日

Objective-Cのif文の判定 : if(self) VS if(self = [super init])

ちょっと前から気になっていたことがあるので確認してみた

appleのドキュメント内のイニシャライザの書き方で

self = [super init];
if (self){
}

のパターンと

if (self = [super init]){
}

のパターンがあり、後者になんか違和感があったので、ほんとにちゃんと動くのか確認してみた。
というのもC/C++ではif文内に代入文を書くのは結構よく禁じられており、これって代入文だと常に非0になるからなんだっけ?それとも単に書き間違えが発見しづらいだけだったっけということもあり、この際ちゃんと調べてみたわけです。

結論から言うと上のはどちらも正解です。

SuperTestClass.m
#import "SuperTestClass.h"

@implementation SuperTestClass
- (id)init{
    return nil;
}
@end

TestClass.h
#import "SuperTestClass.h"

@interface TestClass : SuperTestClass

@end

TestClass.m
#import "TestClass.h"

@implementation TestClass

- (id)init{
    self = [super init];
    if (self) {
       NSLog(@"instance created 1");
    }
    if (self = [super init]){
        NSLog(@"instance created 2");
    }
    int i;
    if ( i = 0 ) {
        NSLog(@"instance created 3");
    }
    if ( i = 1 ) {
        NSLog(@"instance created 4");
    }
    return self;
}

@end

これをTestClass をalloc,initすると結果は
instance created 4 だけ出力されます。

if文の中で代入すると、代入した結果が評価されるということになります。
ちなみに、.mでなく.cでCで書いてみましたが同じ結果でした。


結果的にはこうですが、
個人的にはif文の中での代入は紛らわしい以外の何者でもないのでやめたほうがいいと思います。
一行で済むから構わん!という意見もありそうですが、Appleのドキュメントやソースでもバラバラなのはこの辺の宗教戦争が勃発しているのでしょうか・・

2012年3月24日土曜日

Agile Samurai Gathering Tokyo 2012に参加してきた

前回にひきつづきAgile Samurai Dojo Gatheringに参加してきました。

今回はスケールアップしただけでなく、アジャイルサムライの筆者であるジョナサンも来日と、とても一つの本の集まりとは思えないほどで、この本の与えた影響の大きさが感じられました。

本の発売から結構月日は流れましたが、ムーブメントはとても大きく、今もなお各地で読書会が多数実施されていて、私も以前は無所属でしたが今は横浜道場に通ってます。
企業でもアジャイルを取り入れ始めているところもたくさんあるようで、これまでのアジャイルでは小さいチームなどからボトムアップ的に勧められていたのが、組織として導入するといったアプローチでやられるところも結構でてきているなど状況も日々変化してきていることを感じました。

しかし周りが変化したからといって自分が変わるわけではないので、自分を変えていき、そして周りも変えていくといったことを肝に命じて日々なにか改善していきたいですね


基調講演
資料
これまでのアジャイルを理解するのに7冊読む必要があったのをこれをひとつにまとめたかった。
7つの本はXPプログラミング入門シリーズ3冊、リファクタリング、TDD本、UserStoryApplied、アジャイルな見積りと計画づくり

あとインセプションデッキについて書いた本がなかった。
本を書くにはspaceとtimeが必要。spaceは割り込みをなくす場所、timeは集中するためのまとまった時間のこと。

3つのステップを意識する。
1.トピック
2.何ができるか
3.何が重要か

アジャイルサムライはだいたいこのように書かれている

Agileをはじめる前にまずは自動化を目指す。
TDD、リファクタリング、CI、UnitTestの4つはAgileをやる上での最低条件
Testは最初からフルスタックフレームワークを使ったほうがいい
ペアプロは向き不向きがある。

クロージング

アジャイルサムライになるためには、経験が必要。本だけではだめ。
行動に移すのが怖い⇒自分を変えるしかない

2012年3月19日月曜日

Agile do ITに参加してきた

Agile do IT! に参加してきました

Agile Japanには残念ながら業務優先で行けなかったので、こちらに参加。

Agile in a Nutshell
アジャイルサムライの筆者のジョナサンの講演。
タイトルの通りアジャイルの概要でアジャイルサムライの第一章の内容ほぼそのまんまだったので正直読んだ人にとってはあんまり役にはたたなかったんですが(失礼)、本人のお話聞けてよかったです!

ジョナサンのおすすめなアジャイル開発の進め方としては
まずXPのエンジニアリングプロセスを導入してみて、次にScrumとXPを組み合わせたものをやってみて、最終的にLeanの考え方を導入して改善していく方法がいいんでない?と言ってました。

また3つの重要なこととして

  1. 価値を毎週届けること
  2. UnitTest、Refactoring、TDD、CI は少なくともやる
  3. 3つの真実
    1. 全ての要求をかなえるのは不可能
    2. 要求は必ず変化する
    3. 時間と金は必ず予定を超過する
というところを最後にあげていました。

質問では、マネージャを説得するにはどうしたらいいんだという質問があり、回答としてはロジカルに説明するという方法と、顧客にどっちのやり方がいいか聞いたら顧客は毎週価値を届けてくれる方を選ぶと思うよといってました。

もう一つの質問では、チームがアジャイルを抵抗したらどうするんだという質問で、ジョナサンはアジャイル開発を強いるのは好きではなく、自分からはじめていくのがいいと思うと言っていました。

スクエニのプロジェクトマネジメント事例
スクエニのCTOの橋本さんの講演。
とてもよくアジャイルを理解しておられて、それをうまく工夫して自社開発に落とし込まれているなと思いました。(今回の中で一番参考になりました)

プロジェクトの予想はできないが制御は可能、予測できないことを受け止めなければならない。
事前対策と事後対策のバランスが重要。WFでは事前対策を重視しすぎて、なんちゃってアジャイルでは事後対策しかしていなかったりするから失敗するみたいです。

スクエニでは2点見積もりをしている。最小見積もりと最大見積もり(最小見積もり+バッファ)で見積もって、さらに見積もり精度を指標として用いるなど、かなり厳密な測り方をしていて、納期に対する姿勢がとても感じられました。それぞれの見積もりにはプランニングポーカー的なやり方を導入しているそうです。

だいたい比率は 準備:実装:仕上げ=1:1:1 になることが経験上得られているそうです。

橋本さんが強調しておられたのは、そのやり方をなぜ行うのか?ということを常に考え改善し続けることが最も重要であり、思考停止してはいけないというところでした。このあたりはまさにアジャイルの精神だなと感じます。

Yahooの事例
Yahooでは「標準」としてアジャイル(Scrum)が取り入れられているというのが驚きでした。どんな内容なのか詳細にはわからなかったのですが、狙いとしては、アジャイル開発を導入する際の導入コストの低減だそうです。「標準」とアジャイルというのはかなり相反する存在だと思っているのですが、そのあたりのバランスをどうコントロールしているのか今回は聞けなかったですが、今度是非聞いてみたいところです。

Scrumやってよかったことはコミュニケーションが円滑になったこと。
Scrumの準備としては、チームメンバーにスクラムガイドは読んでもらうことと、インセプションデッキはやったほうがいい。効果の定量的な評価は難しいが、導入前後の定性的な評価は行なっているそうです。

DeNAの事例
DeNAではプラットフォームのところでScrumを導入しているそうです。
40人くらいの人数なのでScrum of Scrumといった構成になっていました。
プロダクトオーナーは各チームにサブプロダクトオーナーを置いていました。
管理はJIRAを使ってプロダクトバックログ、スプリントバックログバーンダウンチャートなどを出しているそうです。

思ったことは、こういったソーシャルゲームといった業界ではかなりアジャイル開発をしているのかと思っていましたが意外とまだそこまで浸透していないということと、最初はスクラムのチームをエンジニア、デザイナーなどそれぞれで分けていたなどと、まぁどこでも組織というか職種の壁は存在するのだな・・と思いました。

パネルディスカッション

  • チームにはスペシャリスト(CIなど)を置かないほうが、各自が勉強するのでよい
  • ユーザーストーリーについて
    • だれが作ってもいいけど優先度はPOがつけて責任をとる
    • 割り込みタスク用に10%〜20%ほど余分にアロケートしておく手もある
    • 非機能はどうしてる?
      • スプリントの完了の定義に入れる
      • 非機能対応用のタイムボックスを作ってそこでやる
  • プロダクトバックログの大事なところ
    • 優先度、背景はなにか、数が多くなりすぎないようにメンテすること
    • 技術的なリスクを考慮する
    • 納期に対してどれだけリソースをさけるか
    • 準備できているか
  • スクラムマスターとして意思決定に関わるときのコツ
    • 振り返りの時に話題を投げかける
    • 最初にガイドなどをつかって手本を示す
    • 一人一人話しを聞いて人によってアプローチを変える
    • BootCampをする。アジャイルはこういうものというのを紹介する
    • メンバーのもつ不安を解消する。反論するチャンスを与える
    • どのテクノロジー(TDD,CI)をやるかではなく、将来的にどの方向に向かいたいのかを決めておくのが必要。
  • スクラムマスターに必要なスキル
    • 空気を読まない事、忍耐力
    • 最終的にチームから必要なくなる人になること


雑感
タイトルが"Agile do IT!"ですが、"Be Agile!"のほうがいいというか正しい気がしています。
というのもアジャイルは”する”ものではないというところがアジャイル開発において難しいところなのではないかと思っています。
確かに導入としてはTDDやCI、朝会、振り返りなどを”する”というのは大いにありですが、それによって万事解決するわけではなく、それをベースとして”自分たちにあった形に改善し続けていく”というところがアジャイルの本質的な部分ではないかと個人的には思っています。
そこをどう全体に広めていくかといったところにみなさん苦労なさっているという印象を受けました。むろん私もですが・・・

結構以外だったのが、DeNAなどのWeb系やソーシャル系のところではかなりTDD,CI,自動化などが進んでいて当たり前のようにやられているのかと思っていましたが、実際にはそういうところもあるが、テストの全くないレガシーコードも大量にあるのが実情ということで、まだそれほど差はないなということがわかった点でした。

2012年3月18日日曜日

iOS勉強会議 #1に参加してきた

iOS勉強会議#1に参加してきました。

@amachang氏主催でiOSの勉強会をするということで
最近iOS側についていききれていなかったこともあり勉強しなおすためにいってきました。

この勉強会では輪になって座って各自Appleのドキュメントを読んでわからないところがあったら質問して誰かが答える(そして一人必ず一回は発言する)という方式です。

#1では以下の3つのドキュメントについて3時間くらいかけて読む&質疑応答しました。
結構今回はよく知っている方が数名おられたのでだいたい的確な回答が得られていました。

ただiOSをよく知っている人にとってはあまり役にたたない可能性もありますが、賞味半年程度やっている身としては、Appleのドキュメントは結構読みましたが、自分としてはあまり関係なさそうなところはスルーしているところもあり、今回改めて読み直したり他の人の質問を聞くことで、新たな知識を得ることができたりと結構実りのあるものでした。

宿題の量は多いですが、ある程度わかる人であればサラッと読んできて、わからないところや気になるところをメモっておく程度でもよいかと思いますが、逆に何も読まずに来た初心者の方だとなんのことやらわからずに終わってしまう可能性があるので、全くアプリをつくったことのない方は一度しっかり読んで写経してきたほうがいいと思います。

  1. 初めての iOSアプリケーション
  2. 2つ目のiOSアプリケーション:ストーリーボード
  3. iOSアプリケーションプログラミングガイド


また、この勉強会の目的はATNDのほうにも書かれていますが、他のいわゆる勉強会とは異なり、学習自体が目的ではなく、一人で読んでもよくわからないところを知っている人に聞いて効率的に解決していくことで、早く実践的なコードが書けるようにすることが目的となっていますのでご注意ください。


最後にこの勉強会でよいところは@amachangも言っていましたが、iOSのアプリ開発においてもっともまともなドキュメントはAppleの公式ドキュメントであり、これをちゃんと読んでいこうよというところだと思います。
iOSだけでなくAndroidもそうですが、日本語で書籍はいっぱいでていますが、プラットフォーム側の変化がとてつもなく早いので良書であってもすぐに陳腐化してしまうため、正直ほとんど役に立ちません、特に訳本はだめですね。よってAppleの公式ドキュメントを読むことになるわけですが、結構日本語がクソなことが多くわかりにくい話が余計にわかりにくくなっていたりするので、英語版を読むかこのような勉強会をうまく利用して消化していくのが効率的な勉強法だと思います。


以下メモ

  • ARCはファイル単位で指定できるから全部ARCでなくても大丈夫
  • CoreDataはスキーマのバージョンアップとかにも一応対応してくれるみたい
  • CoreDataだとデータはSQLiteのファイルに保存される
  • willterminateはほんとに呼ばれるのか怪しいのであまり信用してはいけない
  • inactiveかenterbackgroundのタイミングで保存とかしたりしてる
  • 無音の音楽とかを使えば長時間動かすことができるかも
  • ユーザのアクションがないとアプリを起動することができない

2012年3月8日木曜日

アジャイルサムライ読書会 横浜道場 第三回に参加してきた

アジャイルサムライ読書会 横浜道場 第三回に参加してきました。

私としては第一回、第二回と連続参加になります。

今回は前回と引き続き、5分の輪読+10分のディスカッションを何セットか行い、最後に書くテーブルでまとめを言うという形式でした。

各テーブルはスタッフ+4〜5名で構成され、4テーブルにて行いました。

今回は第二章の始めから開始しました。


第二章は個人的にはアジャイルサムライの中でも最も重要なところの一つと思っている「自己組織化」について触れている章であります。

ここではアジャイルチームとしては職能横断であることや同じ職場で働くことなどが必要であるとあげられていますが、なぜそういったことが必要なのかといったことを議論していくうちに少しわかってきました。

チーム内でお互いをよく知るには同じ職場にいることが近道だし、職能横断であることでお互いに助けあったり、更に深く知ることもでき、それらの積み重ねによりチーム内での信頼が生まれ自己組織化に繋がるのではないかと感じました。
アジャイルなチームの構築には地味ですけどこうした継続的な努力が必要ですね、アジャイル全般に言えることでもあるかもしれませんが。


横浜道場は今回も初参加というかたもたくさんおられましたし、
だれでもウェルカムな雰囲気なので是非興味のあるかたは一度来られてみるといいと思います。

第三回では2章は終わらなかったので次回は2章の途中からになると思われます。

2012年3月4日日曜日

JenkinsでXcodeで作ったプロジェクトのコンパイラの警告の集計と静的解析を表示

JenkinsでXcode4.2で作ったプロジェクトのコンパイラの警告の集計と静的解析をする方法についてです。
(ちなみに静的解析のほうはできていません。情報まで)

コンパイラの警告の集計
警告をグラフで表示するにはWarnings Pluginを使います。

設定は簡単で”コンパイラの警告の集計”にチェックをいれて、”コンソールログをスキャンする”の"GNU compiler(gcc)"を選択すればよいです。

静的解析
静的解析にはOCLintがあります。

OCLintのドキュメントに書いてあるようにシェルスクリプトを記載します。
そしてそれを実行すればよいです。

が、ドキュメントにも書いてあるように、これは対象のファイルとかを手動で編集しなければいけないイケてないやり方で、現在プロジェクトファイル側を解析して自動でなんとかできないかやっているみたいです。

出力もtextかhtmlのみで、violations Pluginで読み込めるフォーマット(xml)に変更する必要があったりと、ちょちょいといれられるもんではないです。

OCLintで検出できる内容については、Rulesに書いてある内容の解析ができますが、正直それほどクリティカルな問題が見つかるわけではないので、超がんばって使えるようにする必要があるかというと疑問です。

JenkinsでXcodeで作ったプロジェクトのビルドとテスト

JenkinsでXcodeで作ったプロジェクトのビルドとテスト(OCUnit, SenTestKit)を自動実行させる際の設定です。

SCMからソースコードを取得するところは他と同じなので割愛し、Xcode独自のところに絞ります。

まずはXcode Plugin を入れます。他にもSICCI Xcode pluginがあるみたいですが、私が試したかぎりでは動かすことさえできなかったです。(Jenkins 1.424.1)

設定すべきところは以下です。

ビルドの手順の追加でXcodeを選択し、以下の3つを設定します。
Target,SDK,Configuration。

SDKには必ずsimulatorのどれかを選択しないとテスト結果が出力されません。
注)Xcode4.3からXcodeのインストールディレクトリが/Developerから/Applicationsに変わりました。
SDKの指定は以下のように変更する必要があります。
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.1.sdk

残りはJUnit結果の集計にチェックを入れ、
テスト結果XML のところに test-reports/*.xml を入力しておけばよいです。

これでビルドを実行すればOKです。

設定直後だとテスト結果のグラフがでないことがありますが、その時はもう一回保存しなおせば出たりします。(C#でやったときもそうだったのでJenkinsのバグ?)