Objective-C（iOS開発向け）テストフレームワーク
多いのでメモがわりに随時更新。
Objective-Cはマイナーだから少ないと思ってたけど現時点で多いわっ！
XUnit系
OCUnit(SenTest)
XCodeにはいってる
GHUnit
https://github.com/gabriel/gh-unit
Catch
https://github.com/philsquared/Catch
BDD系(RSpec style)
Kiwi
https://github.com/allending/Kiwi
Cedar
https://github.com/pivotal/cedar
ODCSpec
http://paytonrules.com/OCDSpec/
受け入れテスト系(selenium,cucumber style)
UIAutomation
Xcodeにはいってる
KIF
https://github.com/square/KIF
Frank
http://www.testingwithfrank.com/
Monkey Talk for iOS
http://www.gorillalogic.com/testing-tools/monkeytalk
NativeDriver
http://code.google.com/p/nativedriver/
iCuke
https://github.com/unboxed/icuke
UISpec
http://code.google.com/p/uispec/
Zucchini
http://www.zucchiniframework.org/
Test Studio for iOS
http://www.telerik.com/automated-testing-tools/ios-testing/ios-application-testing.aspx
delight.io
http://delight.io/
Calabash iOS
http://blog.lesspainful.com/2012/03/07/Calabash-iOS/
テストアプリ配布
TestFlight
https://testflightapp.com/
2012年4月28日土曜日
2012年4月23日月曜日
AgileJapan再演に行ってきた
AgileJapan再演 アジャイルな開発からアジャイルな組織へに行って来ました
AgileJapan2012ではものすごい人気で会場から人があふれたほどだったという吉羽さんの講演が横浜で再演してくれるということなので行って来ました。
AgileJapan2012ではものすごい人気で会場から人があふれたほどだったという吉羽さんの講演が横浜で再演してくれるということなので行って来ました。
Agileな開発からAgileな組織へ #aj21 #b2
View more presentations from Ryuzee YOSHIBA
ビジネス環境の変化に対してどう向き合っていくのか。
それに対する銀の弾丸はなく、目的とそれを達成していくための態度が重要というところがポイントだったように思います。
現状に目をつぶらず少しづつでも改善していく態度を意識していきたいと感じました。
以下メモ
ビジネス環境としては、
システムは効率化のためのものから、システム自体が儲かるものとなってきている。（弊社はおもいっきり前者なビジネスモデルだなと感じました・・）
WFとAgileの違いは計画づくりの頻度と計画の粒度。
Agileはリスクマネジメントと言うと上の人に響きやすいかも
プロセスは自分たちで進化させる
ツールやプラクティスは単なる道具にすぎない
WFやったあとに大反省会をしても喉元をすぎているので次にまた同じ失敗をする
Agileは０か１ではなく、度合い。どんだけやっているか。
標準は標準自体が成長するのであればまぁいいけど、標準を守ることが目的となったり、守ってればいいや的になり改善を捨てることにつながりやすい。
技術的負債があるとのちのちコストが大きくなる。同じ投資は同じ対価でないとならない。前半と後半で同じ投資で同じくらいのアウトプットが出せないとお客さんは納得してくれない
高い金を払ってでもやってもらいたいと思えるような成果をあげていないから、今のような価格競争になっている
組織構造が顧客への価値を届けるための分割になっていない。
規則ばかりになると思考停止が起こり、規則の意図が理解されず規則はただの制約になってしまう。
ピーターの法則・・・上の方は使えないやつばかりになる
チームの解体は阻止すべき。一回つくったチームの仕事は早いから。
仕事のかけもちは非効率だしストレスがたまる
結果に対して全力でやることをコミットし、見積にコミットするのではない
常に改善する責任、チームメンバーを育てる責任を持つ。プラクティスを採用するのであれば採用理由をチームに説明する責任がある
育てるインセンティブが必要
外部からのマイクロマネジメントは止める。言われてやるようではだめ。
個人の評価ではなく、チームで評価すべき
会社に目をつけられて一人前。
小規模でうまくいかないものを大規模でいきなりやっても失敗するだけ
抵抗勢力になるような人をいれるくらいなら入れないほうがいい
リファクタリングも全部が全部やるのではなく見極めが必要。投資対効果を考える
品質にはビジネス品質と内部品質がある。
ビジネス環境の変化に対してどう向き合っていくのか。
それに対する銀の弾丸はなく、目的とそれを達成していくための態度が重要というところがポイントだったように思います。
現状に目をつぶらず少しづつでも改善していく態度を意識していきたいと感じました。
以下メモ
ビジネス環境としては、
システムは効率化のためのものから、システム自体が儲かるものとなってきている。（弊社はおもいっきり前者なビジネスモデルだなと感じました・・）
WFとAgileの違いは計画づくりの頻度と計画の粒度。
Agileはリスクマネジメントと言うと上の人に響きやすいかも
プロセスは自分たちで進化させる
ツールやプラクティスは単なる道具にすぎない
WFやったあとに大反省会をしても喉元をすぎているので次にまた同じ失敗をする
Agileは０か１ではなく、度合い。どんだけやっているか。
標準は標準自体が成長するのであればまぁいいけど、標準を守ることが目的となったり、守ってればいいや的になり改善を捨てることにつながりやすい。
技術的負債があるとのちのちコストが大きくなる。同じ投資は同じ対価でないとならない。前半と後半で同じ投資で同じくらいのアウトプットが出せないとお客さんは納得してくれない
高い金を払ってでもやってもらいたいと思えるような成果をあげていないから、今のような価格競争になっている
組織構造が顧客への価値を届けるための分割になっていない。
規則ばかりになると思考停止が起こり、規則の意図が理解されず規則はただの制約になってしまう。
ピーターの法則・・・上の方は使えないやつばかりになる
チームの解体は阻止すべき。一回つくったチームの仕事は早いから。
仕事のかけもちは非効率だしストレスがたまる
結果に対して全力でやることをコミットし、見積にコミットするのではない
常に改善する責任、チームメンバーを育てる責任を持つ。プラクティスを採用するのであれば採用理由をチームに説明する責任がある
育てるインセンティブが必要
外部からのマイクロマネジメントは止める。言われてやるようではだめ。
個人の評価ではなく、チームで評価すべき
会社に目をつけられて一人前。
小規模でうまくいかないものを大規模でいきなりやっても失敗するだけ
抵抗勢力になるような人をいれるくらいなら入れないほうがいい
リファクタリングも全部が全部やるのではなく見極めが必要。投資対効果を考える
品質にはビジネス品質と内部品質がある。
2012年4月22日日曜日
Git道場に参加してきた
Git道場に参加してきました
Gitを使うにあたっての心技体を体で覚えるというまさに道場スタイル。
最初にGitの心得についての講演があり、その後はほぼずっと実習でした。
Gitの使い方とかの説明はほとんどなかったので初心者の方にはつらかったかも。
実習は２段階。
まず最初の実習では１０行のテキストを４〜５人で各自１commitしてはpushするといったものでした。
少ない行数のテキストを編集するのでもちろんコンフリクトの嵐で、誰かがpushしてはpullしてきてコンフリクトが発生して うがー と言いつつコンフリクトを直してcommitしなおすという作業を延々と行いました。
その結果こちらのネットワーク図の前半部分のようにカオスなネットワークができあがりました。
https://github.com/git-dojo/team06/network
これはコンフリクトを解消するたびにマージを繰り返しているのでどんどんぐちゃぐちゃになってしまっています。
これをもっとまっすぐにしたいですよね？
というのが２つ目の実習。
内容はまったく1つ目と同じことをするのですが、pullする際に、単にpullするのではなく、pull --rebaseします。そしてコンフリクトが発生したら修正してaddし、その後これまでのようにcommitするのではなく、rebase --continueすることでマージせずにリベースすることができるのできれいなネットワーク図ができあがるのです。
これまではずっと一人で使っていたのでコンフリクトとかほとんどきにすることがなかったので、こういうことが起こることを全く考えていなかったのでとても役に立ちましたし、嫌になるほどpull --rebaseとrebase --continueしたので体にしみつきました！
以下メモ
git reflogで作業履歴がみれる（ただし90日以内かつgit GCされていないこと）
git GCをとめるには git config --global gc.auto 0
git log --graph --pretty=oneline でネットワーク図が出せる
git commit -> git pull --rebase -> conflict発生 -> 直す -> git add -> git rebase --continue
git rebase --continueせずにcommitしてしまった場合はrebase --skip する
mergeとrebaseはどちらも利点、欠点があるので使い分ける
mergeはどこでミスったかわかりやすい
基本rebaseでブランチはmergeというのがいいかも
最初にGitの心得についての講演があり、その後はほぼずっと実習でした。
Gitの使い方とかの説明はほとんどなかったので初心者の方にはつらかったかも。
実習は２段階。
まず最初の実習では１０行のテキストを４〜５人で各自１commitしてはpushするといったものでした。
少ない行数のテキストを編集するのでもちろんコンフリクトの嵐で、誰かがpushしてはpullしてきてコンフリクトが発生して うがー と言いつつコンフリクトを直してcommitしなおすという作業を延々と行いました。
その結果こちらのネットワーク図の前半部分のようにカオスなネットワークができあがりました。
https://github.com/git-dojo/team06/network
これはコンフリクトを解消するたびにマージを繰り返しているのでどんどんぐちゃぐちゃになってしまっています。
これをもっとまっすぐにしたいですよね？
というのが２つ目の実習。
内容はまったく1つ目と同じことをするのですが、pullする際に、単にpullするのではなく、pull --rebaseします。そしてコンフリクトが発生したら修正してaddし、その後これまでのようにcommitするのではなく、rebase --continueすることでマージせずにリベースすることができるのできれいなネットワーク図ができあがるのです。
これまではずっと一人で使っていたのでコンフリクトとかほとんどきにすることがなかったので、こういうことが起こることを全く考えていなかったのでとても役に立ちましたし、嫌になるほどpull --rebaseとrebase --continueしたので体にしみつきました！
以下メモ
git reflogで作業履歴がみれる（ただし90日以内かつgit GCされていないこと）
git GCをとめるには git config --global gc.auto 0
git log --graph --pretty=oneline でネットワーク図が出せる
git commit -> git pull --rebase -> conflict発生 -> 直す -> git add -> git rebase --continue
git rebase --continueせずにcommitしてしまった場合はrebase --skip する
mergeとrebaseはどちらも利点、欠点があるので使い分ける
mergeはどこでミスったかわかりやすい
基本rebaseでブランチはmergeというのがいいかも
2012年4月7日土曜日
Lean Startup Camp Tokyo Spring 2012に参加してきた
Lean Startup Camp Tokyo Spring 2012に参加してきた
リーン・スタートアップの著者のエリック・リースが来日ということで講演を聞いてきました。
日本で生まれたトヨタ生産方式が海外でスタートアップに適用されて日本に逆輸入という構図が面白く感じましたが、逆に日本では他にうまく活用できなかったことが問題な気がしました。特に日本ではトヨタ生産方式という「方式」や「手法」だけが一人歩きして、本質的なところがいつの間にか抜け落ちてしまっているように感じます。
その本質的なところをしっかりと捉えているのがエリック・リースで無駄をなくし、より科学的なアプローチでしっかりと仮設検証を行なうことで定性的な判断だけでなく、定量的に判断していくという考え方です。
リーン・スタートアップも注目されていますが、これもトヨタ生産方式の二の足を踏んで「手法」だけが一人歩きしなければいいなと思います。
またとても面白かったのがコクヨさんのリーン・スタートアップ的な開発事例でした。
ノートを使わない人に焦点をあて、その人達の痛みを解決するアイデアを少しづつ形にしていき商品にするという過程はまさにリーンスタートアップでした。
エリック・リースの基調講演
不確定なものを作るということは科学的な実験
Frederick Winslow Taylor：仕事を調査効率的にし、計画と予測によるマネージメント手法
→ これは現在では無理
pivot : 戦略をかえるがビジョンを変えない
これを速く回す
いつpivotするかが問題
計画を実行したやり方が悪いのではなく計画自体が間違っている
顧客はだれか？
製品そのものが無駄にならないようにする
人の時間を無駄にするのを止める
Build→Measure→Learnのループをできるだけ速く回す
The Toyota way
長期的な考え方
The Lean Startup way
people
culture
process
Accountability のピラミッド。
数値の仮設をたて検証。pivotするかの判断する会議を予定に入れておく。
投資家は大きな数字がほしい。大きな数字には説明責任が必要
ここから脱出するには投資家を教育しないといけない。
小さな数字で今後どれだけ成長できるか説明する
生産性とはコードをたくさん書くことではなく、たくさん学ぶこと
チーム一体となって新しいやり方を考えないといけない
エンジニアは言われたとおりにやらずに考える。いいわけをなくさせる
コードを書く前にやること
コンシェルジュMVP
少数の顧客にコンシェルジュして気に入られてからつくる。
マニュアルで手が回らなくなってきたら自動化する
BtoBでできるかは課題がある
法人の中にもアーリーアダプターがいるので、ここでやらないといけない
アーリーアダプターは何か問題があるわけでこれを誰よりも早く解決する
何をしたいか聞く→仮設をたてる
コードを減らすのが一番のコスト削減。コードは負債。
Featureも資産でなく負債。Featureは顧客の問題を最低限解決するもの。
ヘビーユーザーをどう増やしていくかが重要
この人達が減ると危険。なぜ使っているのかよく知る必要がある
コクヨのCamiAppの事例
ノートがなくなったらどうする？アナログでこの先大丈夫かという危機意識からスタートして、残業時間に勝手に集まって作った。
全くノートを使わない人にヒアリングしてアイデアを出した。
SHOT NOTEが先に出てしまったので方向修正した。
SHOT NOTEを研究したところ、整理をもっと簡単にする必要があることに気づいた。
整理をするために塗りつぶすだけの枠をつけた。
ITの人だとソフトでやってしまいがちなことをアナログをうまく活用している。
リーン・スタートアップの著者のエリック・リースが来日ということで講演を聞いてきました。
日本で生まれたトヨタ生産方式が海外でスタートアップに適用されて日本に逆輸入という構図が面白く感じましたが、逆に日本では他にうまく活用できなかったことが問題な気がしました。特に日本ではトヨタ生産方式という「方式」や「手法」だけが一人歩きして、本質的なところがいつの間にか抜け落ちてしまっているように感じます。
その本質的なところをしっかりと捉えているのがエリック・リースで無駄をなくし、より科学的なアプローチでしっかりと仮設検証を行なうことで定性的な判断だけでなく、定量的に判断していくという考え方です。
リーン・スタートアップも注目されていますが、これもトヨタ生産方式の二の足を踏んで「手法」だけが一人歩きしなければいいなと思います。
またとても面白かったのがコクヨさんのリーン・スタートアップ的な開発事例でした。
ノートを使わない人に焦点をあて、その人達の痛みを解決するアイデアを少しづつ形にしていき商品にするという過程はまさにリーンスタートアップでした。
エリック・リースの基調講演
不確定なものを作るということは科学的な実験
Frederick Winslow Taylor：仕事を調査効率的にし、計画と予測によるマネージメント手法
→ これは現在では無理
pivot : 戦略をかえるがビジョンを変えない
これを速く回す
いつpivotするかが問題
計画を実行したやり方が悪いのではなく計画自体が間違っている
顧客はだれか？
製品そのものが無駄にならないようにする
人の時間を無駄にするのを止める
Build→Measure→Learnのループをできるだけ速く回す
The Toyota way
長期的な考え方
The Lean Startup way
people
culture
process
Accountability のピラミッド。
数値の仮設をたて検証。pivotするかの判断する会議を予定に入れておく。
投資家は大きな数字がほしい。大きな数字には説明責任が必要
ここから脱出するには投資家を教育しないといけない。
小さな数字で今後どれだけ成長できるか説明する
生産性とはコードをたくさん書くことではなく、たくさん学ぶこと
チーム一体となって新しいやり方を考えないといけない
エンジニアは言われたとおりにやらずに考える。いいわけをなくさせる
コードを書く前にやること
コンシェルジュMVP
少数の顧客にコンシェルジュして気に入られてからつくる。
マニュアルで手が回らなくなってきたら自動化する
BtoBでできるかは課題がある
法人の中にもアーリーアダプターがいるので、ここでやらないといけない
アーリーアダプターは何か問題があるわけでこれを誰よりも早く解決する
何をしたいか聞く→仮設をたてる
コードを減らすのが一番のコスト削減。コードは負債。
Featureも資産でなく負債。Featureは顧客の問題を最低限解決するもの。
ヘビーユーザーをどう増やしていくかが重要
この人達が減ると危険。なぜ使っているのかよく知る必要がある
コクヨのCamiAppの事例
ノートがなくなったらどうする？アナログでこの先大丈夫かという危機意識からスタートして、残業時間に勝手に集まって作った。
全くノートを使わない人にヒアリングしてアイデアを出した。
SHOT NOTEが先に出てしまったので方向修正した。
SHOT NOTEを研究したところ、整理をもっと簡単にする必要があることに気づいた。
整理をするために塗りつぶすだけの枠をつけた。
ITの人だとソフトでやってしまいがちなことをアナログをうまく活用している。
2012年4月1日日曜日
SConsをMac OS X Lionにインストール
SCons 2.1.0 をMac OS X (Lion)にインストールする方法です。
前提条件としてpython の2.4以上がインストールされている必要があります。がMacだとデフォルトで入っていた気がするので大丈夫だと思います。
こちらから Production(2.1.0)のscons-2.1.0.tar.gz をダウンロード
http://www.scons.org/download.php
ダウンロードしたファイルを適当な場所に展開します。（コマンドラインでもダブルクリックでもなんでもよい）
展開したディレクトリにterminalで移動
以下のコマンドを実行
> sudo python setup.py install
> scons を実行。
-bash : scons : command not found
が表示されなければここで完了です。
もし表示されたらパスが通っていないのでちょっと小細工をする必要があります。
やるのは/opt/local/bin にsconsへのリンクを貼ります
> cd /opt/local/bin
> sudo ln -s /opt/local/Library/Frameworks/Python.framework/Versions/2.5/bin/scons scons
これで完了。
前提条件としてpython の2.4以上がインストールされている必要があります。がMacだとデフォルトで入っていた気がするので大丈夫だと思います。
こちらから Production(2.1.0)のscons-2.1.0.tar.gz をダウンロード
http://www.scons.org/download.php
ダウンロードしたファイルを適当な場所に展開します。（コマンドラインでもダブルクリックでもなんでもよい）
展開したディレクトリにterminalで移動
以下のコマンドを実行
> sudo python setup.py install
> scons を実行。
-bash : scons : command not found
が表示されなければここで完了です。
もし表示されたらパスが通っていないのでちょっと小細工をする必要があります。
やるのは/opt/local/bin にsconsへのリンクを貼ります
> cd /opt/local/bin
> sudo ln -s /opt/local/Library/Frameworks/Python.framework/Versions/2.5/bin/scons scons
これで完了。
iOSプログラミング忘備録その1
・StoryboardでNavigationControllerをTabBarControllerなどに埋め込む方法
埋め込みたい画面のViewControllerをstoryboardで選択して
メニューの ”Editor -> Embed In -> Navigation Controller” を選ぶ
・文字列（NSString）の連結方法
NSMutableStringを使う
例： "hoge" と "hoge" を連結
NSMutableString* mutableString = [[[NSMutableString alloc]initWithString:@"hoge"]autorelease];
・NSNotificationCenterを使う場合
・呼び出し側
埋め込みたい画面のViewControllerをstoryboardで選択して
メニューの ”Editor -> Embed In -> Navigation Controller” を選ぶ
・文字列（NSString）の連結方法
NSMutableStringを使う
例： "hoge" と "hoge" を連結
NSMutableString* mutableString = [[[NSMutableString alloc]initWithString:@"hoge"]autorelease];
・NSNotificationCenterを使う場合
・呼び出し側
NSNotification* notification = [NSNotification notificationWithName:@"イベント名" object:呼び出され側に渡すオブジェクト];
[[NSNotificationCenter defaultCenter] postNotification:notification];
・呼び出され側
NSNotificationCenter* notificationCenter = [NSNotificationCenter defaultCenter];
[notificationCenter addObserver:self selector:@selector(呼び出すメソッド名) name:@"イベント名" object:nil];
・delegateの宣言
id の後に< >でdelegateの型を入れる。
@property (nonatomic, assign) id <xxDelegate> delegate;
登録:
投稿 (Atom)