2012年8月5日日曜日

Xcode : #pragma markで見出しをつける

プログラム上でたまに見かける #pragma mark ***  の使い方です。(参考)

#pragma mark を使うことでコードをXcodeで見やすくすることができます。
C#知ってる人はC#のpragma regionと似たような感じに使うことができます。(begin-endはいらない)

・書き方
*** のところに何か文字列を記載します。

#pragma mark ***

例:hogeとつけてみる



"control + 6" でメソッド一覧を表示すると
図のようにpragma markでつけたhogeという文字列が一覧に表示されるようになります。



追記:

#pragma mark - ***

とハイフンをつけることで区切り線を出すことができるので更に見やすくすることができます。

たくさんメソッドがある場合などに探しやすくするのによいと思います。



LL Decade に参加してきた

毎年行われているLLのイベント LL Decadeに参加してきました。

昨年も参加しましたが、昨年はJavascript一色な感じでしたが、今年はバランスがよかったです。

スピーカー陣は@miyagawa,@matzはじめ日本のそうそうたるメンバーが一同に介しとても豪華でした。

特に印象に残ったのが@miyagawaさんの基調講演で、WSGIなど他言語で実装されたよいものをそれ以外の言語にポーティングして取り込むという言語間での交流が増えてきていているというところで、確かにObj-CをやっていてもRubyなどのやり方を取り込んだりしているものがよく見られるのでなるほどと感じるとともに、そういうところはOSSとしてはじめるにはとっつきやすいところなのかなと。
複数の言語が使える人をpolyglotというらしいです、複数の言語を使うことで他言語のよいところや悪いところを知るのによいきっかけができるので、2年に一つくらいは新しい言語に挑戦したほうがよさそうです。

@matzさんの講演ではruby2.0がいよいよruby生誕20周年にあわせてリリースされる予定だそうです。(20年だからだしちゃおうかくらいのノリのようです)
キーワード引数が使えるようになるらしいので楽しみです。
mrubyという組み込み向けのrubyも開発が着々と進められているようで、元組み込みエンジニアとしてはどうなのか結構気になるところです。
まだフットプリントが600kくらいあるそうなのとソフトリアルタイムを実現するためのGCの改善などが課題としてあるみたいです。

Underscore.m

_.m

javascriptのライブラリのUnderscore.jsをObjective-Cへポーティングしたもの。

CocoaControl

CocoaControl

いろいろなカスタムUIコントローラの部品が登録されていて便利そう。

2012年7月5日木曜日

アジャイルサムライ横浜道場「ユーザーストーリーを集める」に参加してきた

アジャイルサムライ横浜道場「ユーザーストーリを集める」に参加してきました。

仕事で抜けられなくて約二ヶ月ぶりの参

流れはいつものように5分の音読+10分議論の4セット+まとめ発表5分。
今回?はまとめ発表が各グループ1分+質疑4分でした。

今回の読書会の内容は第6章「ユーザーストーリーを集める」でした。

文書化は、よく文書化しろとか言われますが、すべて文書で伝えるのは無理で、文書は誤解を与えやすく、コードと同じで完璧な文書というのはありえないです。
網羅しているのか?という質問をされるというお話を聞きましたが、網羅しているかどうかなんて、網羅していることを証明するなんて、スコープをかなり限定しない限り無理ですよね。
ただかと言って、アジャイルでは文書は書かなくていいとかいう勘違いも間違っていて、文書は全く無くてもいいわけでもないです。だったらどれくらい書くのかというと、「場合による」ので自分たちでなにが最適なのか考えないとだめだなわけです。なので思考停止して文書をつくるのが一番やってはいけないことで、何が必要で何が不要なのか考えて書くということが大切だと思います。

今回覚えたのがINVESTという言葉で、
一人で読んでいた時にはあんまり気にしていなかったのですが、
INVESTはソフトウェア開発に似ているという意見にとても同意しました。
独立性、テスタビリティ、見積もれるなど、ソフトウェア開発の手法をユーザーストーリーの抽出に適応させると考えるとけっこうしっくりくるものがありました。

2012年7月1日日曜日

could not locate an NSManagedObjectModel for entity name

"could not locate an NSManagedObjectModel for entity name" というエラーがCoreDataで出た場合の対処方法。

以下のようなコードで、色のついたコードの箇所で止まってしまう場合です。
entity nameはあっているはずなのに・・・と悩んだわけですが、
self.managedObjectContextにちゃんとセットしていないとこのようなエラーがでてしまいます。(エラーの内容が紛らわしい・・)


- (NSFetchedResultsController *)fetchedResultsController
{
    if (__fetchedResultsController != nil) {
        return __fetchedResultsController;
    }
    
    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    // Edit the entity name as appropriate.
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Spending" inManagedObjectContext:self.managedObjectContext];
    [fetchRequest setEntity:entity];


gitによる開発フロー

・設定

エディタをviからemacsに変更
git config --global core.editor 'emacs'

・開発フロー
A successful git branching model をベースに開発を行う場合の手順。
http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html

・管理者
gitリポジトリをまずつくる
git init

touch README

git add README

git commit -m "initial commit"

git remote add origin http://xxxxxx/xxx.git

git push origin master

developブランチをつくる
git checkout -b develop

developブランチをremoteリポジトリにpush
git push origin develop

・開発者
develop ブランチをブランチしてfeature1を開発する場合

remoteのdevelopブランチをチェックアウト
git checkout origin/develop -b feature1

commitする
git commit -m ""

commitをまとめる
git rebase -i HEAD~5

developの変更を取り込む
git pull --rebase origin develop

競合の解決をする

競合を解決したファイルをadd
git add

rebaseを完了させる
git rebase --continue

pushする
git push origin feature1