ラベル イベント の投稿を表示しています。 すべての投稿を表示
ラベル イベント の投稿を表示しています。 すべての投稿を表示

2012年9月16日日曜日

XP祭り2012に参加してきた

XP祭り2012に参加してきました。

去年は参加だけだったので、今回はアウトプットをしようということで
LTで登壇してきました。


Xp祭り2012 lt leanstartup from Yasuharu Yanamura

これはUT Startup gymという半年間でアイデアをローンチまでするというプログラムの一プロジェクトとして僕が体験したことを簡単にお話しました。

実際のところ僕らのサービスは、まだローンチまでには至っていないので「やった」とはいいきれないし、
リーンスタートアップを教科書通りにやったわけではなく、考え方などを参考にしてやった程度なので、いろいろつっこみどころはあるとは思いますが、それでも実際にやってみたことで思ったとおりにはいかないことはたくさんあったので、「ひとつの失敗事例」としては他の人にも価値があるのではないかと考え発表させていただきました。

リーンスタートアップもアジャイルもこれといった答えはなく、あくまで「考え方」や「姿勢」のフレームワークだと僕は思っているので、この発表でお話した、「こうすればよかった」や「こうすべき」という意見は、あくまで「この家計簿プロジェクトに限る話」なので、全てに通じるわけでは全くないと思っています。

ソフトウェア開発と同様にスタートアップにも銀の弾丸はないので、試行錯誤してやっていくしかない。なので「超早く回す」ってことが一番重要だと思いますので、実際リーンスタートアップなことをやる場合はそうしたほうがいいのではないかと思います。

2012年8月25日土曜日

iphone_dev_jp東京 mac/iphone Hackathonに参加してきた

使えるライブラリを作ろう!というハッカソンに参加してきました。

個人的に家計簿アプリを作っていてNSDateがかなりいけていない(面倒なのが多い)のでそれを楽にするものを作りました。

https://github.com/yanamura3/NSDateHelper

実装自体は自分のソースコードからライブラリ化したいものをひっぱってくるだけだったのでほぼ一瞬で終わってしまい、大半はKiwi使ってテスト書いてました。

できたものはライブラリというかカテゴリになってしまいましたが。

問題はカテゴリを組み込むのにgitsubmoduleやcocoapodsだと2つファイル読みこめばいいだけなのに無駄にプロジェクトファイル毎取り込まなければいけないのがなんだなぁと。この辺りもなにかうまいやりかたを考えていく必要がありそうです。

結構時間があまったのでOCMockitoというモックライブラリで足りない機能があったので追加してみました。

https://github.com/yanamura3/OCMockito

追加したのはスタブのメソッドが呼ばれた際に指定したblocksを呼ぶことができるようにする拡張で、

[given([mock somemethod]) answer:^{ /** 処理 */ } ]

と書けば somemethodが呼ばれるとanswerに渡したblocksが実行されます。

NSProxyのforwardInvocationの勉強にもなったので結構役に立ちました。


最後は発表があったのですが、あまりにもやったことが地味すぎたので
今度ハッカソンに参加するときはもうちょい見た目にインパクトあるものを考えて参加しようと思いました・・・


Togetter
http://togetter.com/li/361912

2012年8月5日日曜日

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の改善などが課題としてあるみたいです。

2012年7月5日木曜日

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

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

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

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

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

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

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

2012年6月22日金曜日

OnLab Data Conferenceに参加してきた

Onlab Data Conferenceに参加してきました。

データ分析に使えるサービスはよく知らなかったのでとても勉強になりました。
リーン・スタートアップでも言われていますが、検証するためにはデータが非常に重要で、それを行うためには、何を分析するのかという目的が必要で、さらには分析するためのデータが必要です。そのデータを集めるにはサービスをローンチする際にあらかじめそういった仕掛けを埋め込んでおかなければならないわけで、速くサービスを出すにはこういったデータ解析サービスをうまく活用していくことは必須だと思いました。
データをものすごく見ることも重要ですが、それをやりすぎると局所解に陥ってしまうというところのさじ加減も肝心だなと。
サービスの序盤のようにユーザーが少ないときは、母数も少ないのでデータ解析に頼るよりはユーザー一人ひとりにフォーカスをあてて話をするといったアナログなやり方のほうがいいという意見にはすごく同意でした。

予測分析 Peter Skomoroch(LinkedIn)

予測から戦略を立てるという例で映画シャーロック・ホームズをあげていました。
ストリートファイトでシャーロック・ホームズは予測から戦略を立てて戦っていて、戦い方は日頃から練習でつちかっている。
ビジネスでもストリートファイトのように考える。
データをしっかり見て分析する(例:ヤギと男と男と壁と)
データを壊すくらいデータをみる。
John Rauserのプレゼンを見るといい
平均は見ても意味が無い。大事な特徴的なデータが平滑化されてしまう。
データと直感だけではだめ、アルゴリズムに基づいている必要がある

・データはどのように反映している?
・意思決定へのサジェスチョンに使っている。ある特定のユーザーをとりあげて分析したり、A/Bテストを少数のユーザーに対して行う

データは適切な場所に保存することが重要、これには最初から準備しておく必要がある。
何かを消すときも消さずに消したことを保存しておいたほうがいい。
オートコンプリートを用意しておくことで最初からデータを整形できてデータ整理にもいいし、ユーザーにとてもよい。
一つひとつの数字を深掘りしていくことが重要
まずはユーザを集めてからデータを解析したほうがいい。(母数が小さいと統計が難しい
・データサイエンティストにはどんなひとがむいてる?
・ある程度のコーディングスキルと科学のバックグラウンド

アナリティクス・アクセス解析・KPI設定 Hiten Shah(KISSmetrics)

アクションができるメトリクスにフォーカスする。
GoogleAnalyticsでとれるようなデータはVanity Metricsだ。
例えばPage Viewとか。trafficが多いからといって必ずしもビジネスには役に立たない。
web analyticsでなくcustomer analyticsでないといけない。
すべての経験(ユーザー行動)をトラックする。
データを個々のユーザとひもづけることによって匿名状態でも個人の行動を解析することが可能。
ユーザーは複数のチャネルから来るので、カスタマーベースでトラッキングする必要がある。だれが価値のあるユーザーか(そのユーザーはどこからきてるか)みつけるのに役立つ。
重要なアクションをしたのはなぜか、など全体のカスタマーライフサイクルをトラッキングする。
速く学ぶ必要がある。他より速く学ぶのが勝つ方法。
・生涯価値を予測するには?
・単純な計算でもいいので予測をたてること。すでにあるサービスをモデルにする。
・仮設を立てるところから始め、どういったリスクが伴うのか知っておく

・プロダクトが市場にフィットするか?
・この製品がなくなったらどう思うか考えてみる。

・ユーザーが少ない時は?
・個々の人に落としこむ

HowToListenToYourUsers Pete Koomen (Optimezely)

これが正しいと思ってやるのはナンセンス。
必ずしもうまくいくとは限らない。

最初のサービスは4ヶ月かけてつくったが誰もやらなかったし、お金は全く儲からなかった。
次のサービスは1ヶ月で初歩的なのをつくったがだめだったのでやめた。
OptimizelyはA/Bテストを簡単にできるサービス。

・作る前に10人くらいのユーザの重要な問題にフォーカスする。
モックをつくる。仮設をつくるための情報を集める
・ユーザーと話す。人々は改善への貢献はそんなに嫌がらない。
そして売ることが大切(金を払う価値のあるものをつくる)
中古車屋のセールスマンみたいなのはつかってはだめ
近道するのも重要(例えば、期間毎にライセンス料を変えていたけど、実はライセンスが切れたときの実装は入れていなかったけどだれも気にしなかった)
スケーリングは気にしなくていい
ユーザーが利用をやめたときが分析するいいタイミング。
キャンセルボタンを消して、メールを送らないとキャンセルできないようにして、その時にユーザーになんでやめたのかを聞いたりした。
Flurry,Kontagent,KISSmetricsとかで分析する。
アクションがとれるデータとしてはA/Bテストがある。ただし十分なトラフィックが必要。
ただしRefinement = design decision ではない。

・テスト期間はどれくらい必要?
・最低2週間(トラフィックがある場合)。統計上必要な量で決まる。

QualitativeData and UX  Chrix Palmeiri (AQ)

・UX どう感じ、どう使い、どう説明するのか
 ユーザーテストは対象は知り合いでもいいからやったほうがあいい

・質問票
 ユーザーテストをやるタイミングはユーザーのニーズとギャップがあるとき
 何にわくわくしているかわからないとき
 例えば、サインアップのときになぜ、何に期待してサインアップしたのか簡単な質問をしてプロダクトのフォーカスを決めた

・ユーザービリティテスト
 大きな質問を2,3する。
 スクリプトを作る。
 オープンエンドな質問とクローズタスク
  1.目的を説明
  2.タスクごとにコンテキストを設定する
  3.すべて声に出す(だまったら質問する)
  4.できるだけメモをとる
 以上を短時間でとにかく多くやる

・カードソーティング
 ラベルやカテゴリを決める前にやるといい(初期でやること)

メール配信と分析 Taylor Wakefield (MailGun)

今でもe-mailの利用は圧倒的に多い。だけど90%はスパム。
e-mailの内容はhtmlのみはだめで、画像はデフォルトで消される場合が多い
textは短すぎてもだめで、ストーリー性が必要。
トラフィックが集中しすぎるとスパム判定されるので注意が必要。

パネルディスカッション

データだけでは局所的な最適解になってしまう。
もちろんクリエイティビティが必要。

2012年4月23日月曜日

AgileJapan再演に行ってきた

AgileJapan再演 アジャイルな開発からアジャイルな組織へに行って来ました

AgileJapan2012ではものすごい人気で会場から人があふれたほどだったという吉羽さんの講演が横浜で再演してくれるということなので行って来ました。
Agileな開発からAgileな組織へ #aj21 #b2
View more presentations from Ryuzee YOSHIBA

ビジネス環境の変化に対してどう向き合っていくのか。
それに対する銀の弾丸はなく、目的とそれを達成していくための態度が重要というところがポイントだったように思います。

現状に目をつぶらず少しづつでも改善していく態度を意識していきたいと感じました。


以下メモ

ビジネス環境としては、
システムは効率化のためのものから、システム自体が儲かるものとなってきている。(弊社はおもいっきり前者なビジネスモデルだなと感じました・・)

WFとAgileの違いは計画づくりの頻度と計画の粒度。
Agileはリスクマネジメントと言うと上の人に響きやすいかも

プロセスは自分たちで進化させる

ツールやプラクティスは単なる道具にすぎない

WFやったあとに大反省会をしても喉元をすぎているので次にまた同じ失敗をする

Agileは0か1ではなく、度合い。どんだけやっているか。

標準は標準自体が成長するのであればまぁいいけど、標準を守ることが目的となったり、守ってればいいや的になり改善を捨てることにつながりやすい。

技術的負債があるとのちのちコストが大きくなる。同じ投資は同じ対価でないとならない。前半と後半で同じ投資で同じくらいのアウトプットが出せないとお客さんは納得してくれない

高い金を払ってでもやってもらいたいと思えるような成果をあげていないから、今のような価格競争になっている

組織構造が顧客への価値を届けるための分割になっていない。

規則ばかりになると思考停止が起こり、規則の意図が理解されず規則はただの制約になってしまう。

ピーターの法則・・・上の方は使えないやつばかりになる

チームの解体は阻止すべき。一回つくったチームの仕事は早いから。

仕事のかけもちは非効率だしストレスがたまる

結果に対して全力でやることをコミットし、見積にコミットするのではない

常に改善する責任、チームメンバーを育てる責任を持つ。プラクティスを採用するのであれば採用理由をチームに説明する責任がある

育てるインセンティブが必要

外部からのマイクロマネジメントは止める。言われてやるようではだめ。

個人の評価ではなく、チームで評価すべき

会社に目をつけられて一人前。

小規模でうまくいかないものを大規模でいきなりやっても失敗するだけ

抵抗勢力になるような人をいれるくらいなら入れないほうがいい

リファクタリングも全部が全部やるのではなく見極めが必要。投資対効果を考える

品質にはビジネス品質と内部品質がある。

2012年4月22日日曜日

Git道場に参加してきた

Git道場に参加してきました Gitを使うにあたっての心技体を体で覚えるというまさに道場スタイル。

最初にGitの心得についての講演があり、その後はほぼずっと実習でした。

Gitの使い方とかの説明はほとんどなかったので初心者の方にはつらかったかも。

実習は2段階。

まず最初の実習では10行のテキストを4〜5人で各自1commitしてはpushするといったものでした。
少ない行数のテキストを編集するのでもちろんコンフリクトの嵐で、誰かがpushしてはpullしてきてコンフリクトが発生して うがー と言いつつコンフリクトを直してcommitしなおすという作業を延々と行いました。

その結果こちらのネットワーク図の前半部分のようにカオスなネットワークができあがりました。
https://github.com/git-dojo/team06/network

これはコンフリクトを解消するたびにマージを繰り返しているのでどんどんぐちゃぐちゃになってしまっています。

これをもっとまっすぐにしたいですよね?

というのが2つ目の実習。

内容はまったく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年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年2月23日木曜日

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

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

前回にひきつづき参戦。

前回はワールドカフェ方式でしたが、今回は輪読方式でした。
1章の始めから5分ほど輪読したあと15分ワールドカフェ方式でディスカッションするというのを何セットかやる というやり方でした。

5分でかつ声に出して読むということでそれほどたくさん読めないので、ディスカッションするところがかなり絞られて、ディスカッションとしてはやりやすかったように思えました。

また、私のテーブルではSIerの方が比較的多く、業界によっての悩みどころの違いなんかもわかってきました。特にSIerだとやはりお客さんとの関係が問題で、最初に仕様、予算、納期を求められるところが悩みどころのようです。
個人的にはアジャイルと日本のSIerのようなビジネスモデルは相性が悪いというか、真っ向から否定しているような関係にあるように思っていたのですが、結構SIerさんの参加も多いのでみなさん現状に危機感を持っている方が多いのかなとも思いました。

こういった読書会は本の理解を深めるだけでなく、他の業界や会社での悩み事なども共有できたりするよい機会でもあるので今後も参加していきたいです。

また、今回の読書会のやり方は結構よかった気がするので今後自分がやることがあれば参考にしたいと思いました。


2012年2月22日水曜日

第五回 Jenkins勉強会に参加してきた

第五回 Jenkins勉強会に参加してきました。

なかでもmixiの加藤さんの発表が非常に参考になりました。
特にテスト時間の短縮のためによい環境を用意するだけでなく
いろいろと独自に工夫されていたり、よく考えているなという印象でした。
やはりCIをする上ではビルドとユニットテストの時間は重要ですね。

How we use Jenkins at mixi
http://alpha.mixi.co.jp/blog/?p=5768


Dev@cloudの実装川口さんのJenkinsのクラウドサービスの実装の話。
CIのビルドテストはスケールアウトに適しているのでクラウドとは相性がいいと思うので今後広がっていくといいと思いますが、特に日本の大手とかだと外に出したくないとかあるんでしょうけどね・・
Dev@cloudの実装
View more PowerPoint from Kohsuke Kawaguchi

楽天でのContinuousDelivery読書会について
楽天といえば勉強会は活発そうなイメージでしたが
読書会をはじめるまでからの生々しいお話を聞いて、やっぱり簡単にはいかないし、やってみないとわからないよなと。とても参考になりました。

ビアバッシュ
ビアバッシュはいろんな人とお話できよかったのですが、
LTが2つとその分少なくなったのがちょっと勉強会としては物足りない感じがしました。

2012年1月19日木曜日

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

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

アジャイルサムライ読書会他流試合以来二度目の読書会の参加です。

方式は同じでワールドカフェ方式で、お題に対してディスカッションを行いました。
投票で3つのお題を決め、20分×3回のディスカッションを行いました。

お題は、アジャイルの導入、自己組織化、アジャイル導入時の問題 でした。

業界とか違う人達が集まっていたのでいろんな話が聞けて参考になったし面白かったです。
社外の勉強会はこういう点がいいですよね。

次回はワークショップのようなのでどんなことをするのか楽しみ。

2011年12月13日火曜日

shibuya_sp勉強会vol.1に行ってきた

shibuya_sp勉強会vol.1に参加してきました。
http://atnd.org/events/22758

iPhone,Androidといったモバイルアプリのごった煮勉強会です。

iOSアプリのUnitTest
iOSアプリケーションの Unit Test
View more presentations from Katsumi Kishikawa

iOS App Development Workflow Guideをまず読むのがおすすめ。
日本語版もでてます。
http://developer.apple.com/jp/devcenter/ios/library/documentation/Xcode/Conceptual/ios_development_workflow/#000-Introduction/introduction.html

UnitTestツールでは、OCUnitとGHUnitがあるが、GHUnitのほうがおすすめ。
OCUnitはXcodeに組み込まれているというメリットはありますが、GHUnitのほうが機能的に優れていてOCUnitで作ったテストケースも動かすことができるため、導入が少々面倒でも最初だけセッティングすればよいのでGHUnitのほうがおすすめとのことでした。

UI Automationについては使ってないということで、やはりUIはころころ変わるのでテストの自動化は難しいようです。

つりポンアプリ開発について
Tsuripon 20111213
View more presentations from Yusuke Kawabata

cocos2dを使った開発についてと高速化、最適化手法についての発表でした。

OCTOBAから見た人気Androidアプリの動向

Octoba presen 20111213_public

View more presentations from Yusuke Kawabata

OCTOBA.netでは評価時にアプリのパーミッションを見て安全性をまずチェックしているようです。Androidはいろいろできてしまうのでここのチェックは重要ですね。
人気のジャンルとしては、電話帳、時計、メールといった検索が多いようで、ユーザーは基本的な機能に満足していないみたいですね・・

2011年11月1日火曜日

GoogleDeveloperDay2011に参加してきた

去年のリベンジを果たしディベロッパーズクイズを無事突破して
GoogleDeveloperDay2011東京に参加してきました。

今年は、Android、HTML5、Google+の3本柱でした。
中でもHTML5のセッションは立ち見が出るなどかなり盛況でしたね。
HTML5のデモを見ているとそのうちほとんどのアプリはWebアプリ化するんじゃないかなと現実的に感じさせるほどにまでなってきているという印象を受けました。

AndroidはICS(Ice Cream Sandwich) はすごく進歩したなという印象です。
デザイン面ではるかにiPhoneに劣っていたのがかなり追いつくと共に
デザインのガイドラインもできつつあり、次第にUIの一貫性もでてくるのではないかと思います。逆に視覚障害者への対応や顔認証などAndroidのほうが先に行っているところなどもありiPhone VS Androidは面白くなってきています。


Googleの最新技術の紹介ということで知っている人は結構知っている一般的な内容も多く
技術的にはそれほど新たな知見はなかったですが、熱気はすごいです。
LTのレベルが異常に高かった・・


GoogleDeveloperDayではTシャツ、缶バッチ、ネックストラップなどいろいろもらえました!
3Dメガネの使い所はなんだったのだろう・・

また弁当や水、最後はビールやチューハイも配られるなどGoogleさん太っ腹。

基調講演の様子はこんな感じ

締めはGoogleの方やスタッフの人が集まって記念写真で終了


2011年10月29日土曜日

GTUG Boot Camp 2011に参加してきた

GTUG Boot Camp 2011

Fragmentを使ってみよう
ハンドセット向けのレイアウトとロジックを流用したり
Fragmentを使うと動的にActivityを追加削除入れ替えできる
つまりFragment使うと部品として再利用しやすくなる

ハンドセット向けでFragmentを使う意味はある?
ある。
各コンポーネントをFragment化することで、それぞれ使いまわせる
Activityのコードがすっきりする
例:iosched

縦横でレイアウトを変える場合にもつかえる。

同じActivityでレイアウトを変える場合(例:chrome to phone)
setCOntentViewだと前のViewの状態を保存されない
→Fragmentを使って置き換えて、Fragmentをバックスタックに保存すればいい

TabHostは3.2以降でduplicateになったのでFragmentにせざるを得ない

・Fragmentのいまいちなところ
完全修飾名でレイアウトXMLファイルに書かないといけない
グラフィカルエディタで表示できなかったり
Typoミスが発生する

・Fragment、View、Activityの使い分け
View カスタムView
描画とそのための最低限のロジック

Fragment 
View+そのViewに関連するロジック(Viewの操作やViewに表示するデータの処理)

Activity
それ以外。ActivityとFragment間のデータの受け渡しなど

Handson WebView

HoneyCombのシミュレータは重くて使い物にはならんがICS(IceCreamSandwitch)はまだ使える。。

・ICS
ハードキー(メニューキーがきえた)がなくなった。
アプリのターゲットSDKが10以下だと、右のほうにソフトキーでメニューキーが増える。
HoneyComb以降はアクションバーのメニューを使う
GPUをつかってかなりなめらかな動きになっている
ホーム画面が使いやすくなった。(アプリをフォルダにまとめたりできる)
デバイスデフォルトのテーマを使って開発すべき。

API Demos(デフォルトでシミュレータにはいってるやつ)ででもが見れる

・WebView
標準ブラウザのソースオードを見ると参考になる

JavaとJavascriptを連携させるようなアプリだとICSで動かなくなる可能性がある。

・Handson 資料
https://docs.google.com/document/pub?id=1_T9PiCJCgMs1QdXPpdYcp7orOnRr1UU6qA5do_zsR2A

ノートPCをちゃんとセットアップしてなかったので、普通にeclipseのAndroidのビルドではまってしまって、ハンズオンどころではなかったりして、感想もくそもないのですが。
準備はちゃんとやっとけってことです。

はまったところ:eclipseのコンパイラの設定を1.5にする

Google+ APIの体験とHangoutsの紹介

説明資料
https://docs.google.com/presentation/d/1oDkvwodZmkBMeeInhkzDYbHKj7Ss2CoXvnU6OwpzcMQ/edit#slide=id.p

以下のAPIの仕様のリンクを見れば簡単にできそう。
https://developers.google.com/+/api/

一般公開されているのだけAPIで取得することができる。(取得のみ。postできない)

APIを使うにはまず登録が必要
https://code.google.com/apis/console/

Oauthの設定で気をつけるところ
Create an Oauth でunexpected error が出た場合はリロードすると治るっぽい。
2個ClientIDが作成された場合は長い方を必ず使う。

つかいやすいAPIでしたが、問題はやはり「取得」しかできす、しかも「一般公開」しているものというのが大きなネックです。

・Hangout

HangoutはGoogle+のビデオチャットの拡張ができるAPIで
今回のHandsonではあらかじめ用意されたアプリと連携させるというもので
ビデオにドロイド君の絵がオーバーレイされて、
自分がしゃべるとドロイド君の口がパクパクするというもので、
他にもいろいろ使えそうな感じがしました。
ただまだ開発者のみしか使えないもので、2人以上いないと動かなかったり
設定が面倒だったりとまだまだといったところもあり

2011年10月22日土曜日

Scrum Gathering Tokyo2011に参加してきた

Scrum Gathering Tokyo2011(Day2)に参加してきました。

といっても丸一日ScrumBootCampに参加したので他のセッションは全然見れませんでしたが。

Scrum Boot Camp

丸一日かけてScrumとはなんぞやという座学と実際にワークショップを体験して学ぶといったものでした。
4人〜5人のチームにわかれてワークショップは行いました。

・スプリント体験(チーム)
 まず午前の部では トランプを使ったもので、ものすごく短いスプリントを繰り返してゴールを達成する過程を体験するといったもので、これをやることにより気づいたことは非常に多く、今回やった中で一番よかったです。
会社でもすぐにできそうなので是非やってみたいエクササイズでした。

・プロダクトバックログの作成(個人)
家の掃除を題材にプロダクトバックログをつくるエクササイズ。
順序付けとどこまで必須なのかよく理解できました。

・見積もり(個人)
紙飛行機の作成、こよりの作成、トランプの並び替えの時間を見積もって、そして実際やってみるというエクササイズ。
全然見積とはあいません。

・見積もり(チーム)
今度は似たようなことをチームで見積もり。
個人でやるよりも安心感や確かさがあがる気がしました。

・見積もり(チーム)
今度はポイントを使って相対的な見積もりをするといったエクササイズ。
こちらは実際にせーのでポイントを各自がカードで出すことで楽しく見積もりができるだけでなく、ポイントが違った場合に、なぜそう見積もったのかということをチーム全体で共有することができ、これまでの見積もりよりも、より全員がゴールのための品質や手順などの共通認識がとれたように思えました。これもかなりよかった。

・スプリントの過ごし方(チーム)
ひらがなの表を手書きでメンバーの数×2個作成するという協業作業のエクササイズで、数名利き手と逆の手で書くという制約があり、余裕のあるメンバーが手助けしてこなすといった内容でした。

どれも座学だけでなく、実際にやってみることで気づいたり、納得したりすることが多く、やっぱり何事もやってみることが重要だと感じました。
アジャイルで開発を始める前に是非やっておくべき内容だと思います。

以下当日のスライド
Summary of Scrum Guide

2011年10月15日土曜日

第四回 Jenkins勉強会に参加してきた

第四回Jenkins勉強会に参加してきました。
今回はC++,C#ということで自分も使っていることもありかなりタイムリーネタでした。

マルチ構成プロジェクト

クロスコンパイルなどを使って複数の環境向けにデプロイする場合に使える
失敗したときに全部やり直すとものすごい時間がかかるので、MatrixReloadedプラグインを使うと失敗したものだけ再実行することができる。

Jenkins+αで開発環境がみるみるよくなる Visual C++ 編
・MSBuild
MSBuildを使う場合は、MSBuild自体は.NET frameworkないに入っているのでビルドマシンにVisual Studioをインストールする必要はない。

・WarningPlugin
WarningPluginは結構便利。途中から始める場合はすべての警告に対応するというよりも新たに発生したものを潰すために使ったほうがいいかも。設定もいろいろできる。

・UIの自動テスト
起動〜終了だけでもやると効果がある
UI操作自動化ツールとしては、AutoItやSikuliというのがある

・静的解析
Cppcheck Pluginくらい。C++だと無料なのはあまりいいのはない

・実装漏れ検知
Task Scanner Plugin。ソースコード内のto do などの文字列を発見してくれる。

・コーディングルールチェック
cpplint。google C++ Guidelineに沿ったチェックをしてくれる
violations PluginでJenkinsで実行できる。

・メトリクス
CCCC。使ってみたけどあまり使いものにはならなかった(誰も見ない)
Sonar。(C,C#はPluginで対応している)

・ドキュメント
Doxgen

・コラボレーションツール
Jenkinsからチケットを発行
コミット→条件判定(Python)→チケット発行 というようにしてやってる

輪るビングドラム.NET
・Role Strategy Plugin

・すべてのビルドをひとつのビルドマシンでやるのはよくない
・何も無いところ(クリーンな環境)からビルドすべき。でも毎回は時間かかりすぎてできないのでデイリービルドのみでやるとかする
・TFSよりJenkinsのほうが設定は楽。全部VisualStudioで完結させたいならTFS

Jenkins実装入門目次チラ見せしちゃいます
・おすすめのPlugin = Job Config History Plugin
だれがいつ設定をいじったのかHistoryでわかる

Jenkinsの使い方だけでなくtips的なものも載っているようで
初心者からよく使っている人まで使えそうな本みたいです。

参考資料
CI超入門:Jenkinsのすすめ

Video streaming by Ustream


C# 大阪Jenkins勉強会のC#の資料
Jenkins The Definitive Guide
http://www.wakaleo.com/download-jenkins-the-definitive-guide

2011年9月3日土曜日

XP祭りに参加してきた

XP祭りに初参加してきました。
http://xpjug.com/xpx/

いろいろと参加型のワークショップがあり、当日に紙に名前を書いて参加というかたちでした。
午後からなので余裕だと思っていたら遅刻してしまい、ワークショップはひとつだけ参加でしたorz

scrumはじめの一歩というワークショップに参加しました。

折り紙を使って紙ヒコーキをできるだけ多くつくるという作業を
10分×4回のスプリントでやるといったものでした。
scrumの講義だけでなく、実際に短い時間で体感できてとても面白かったです。
会社とかでもすぐにできそうなものなので、試してみたいなーと思います。

資料は以下です。
2011年 XP祭り Scrumはじめの一歩 #xpjug
View more presentations from Ryuzee YOSHIBA

講師の@ryuzeeさんのブログ
http://www.ryuzee.com/contents/blog/4225

よく見たら自分もちらっと写ってた!

2011年8月28日日曜日

実践的UserExperienceワークショップに行ってきた

Lean UXの一日ワークショップに参加してきました。
http://peatix.com/event/760

お値段は22,000円と自腹としては結構しましたが、あのJanice Fraser氏のワークショップを日本で受けれると考えるとむしろ超お得。
Ux for lean startups london
View more presentations from Janice Fraser

↓日本語資料
Tokyo 1 day (日本語)
View more presentations from Janice Fraser


LeanStartupとは商品開発におけるアジャイルといった印象を受けました。
最小限のチーム編成(プロダクトマネージャー、デザイナー、エンジニア)を1チームとして、アイデアの発想、開発、検証を短いサイクルで回してユーザーとともに製品をつくりあげるという過程はまさにアジャイルで、ソフトウェア開発から産まれた手法が、顧客開発に応用されているところがおもしろいと感じました。

これまでの製品開発は企画が決めたものをウォーターフォールで作るものが主流ですが、こういった開発が主流となってくるかもしれないですね。そうなると日本的な稟議書書いて下請けがつくるといったITゼネコン的なところは壊滅するでしょうね・・

とはいっても、LeanUX的な開発は定性的な評価が多く、いかにユーザーに質問するかや、どのような人に対して評価するかなどかなり経験を積んで行かないと難しいと思われるところも非常に多いため、どの企業でもすぐにできるというものではないと思います。
早く取り入れ、ユーザーに対する姿勢を正し、多くの経験を積み重ねたところがよいユーザーエクスペリエンスを産み出していくのではと思います。