デブサミ2012 Day1 2012/02/16 メモ

デブサミ2012 Day1 2012/02/16 メモ

行ってきました。目一杯セッションを選ぶと消化不良を起こしますね。
全体俯瞰はこちらが便利。
デブサミ2012 参加セッション一覧 http://bit.ly/A9kjcL

【16-E-1】
2015年のアーキテクチャ、マーケティングシステムを題材にして
熊澤 公平 氏
http://togetter.com/li/257811

現在主流なBigDataとBigProcessingがやがて融合されると説いてらっしゃいました。
購買の際、計画をたてていながら、その場の情報により予定外の購入をしていることはよくあることです。これをツカミに「モノと一緒にコトを見る」アプローチについての説明は大変刺激的でした。これは購買支援だけでなく、意思決定支援にも展開されるのではとワクワクしながら聞いていました。

【16-E-2】
ペイパル最新決済ソリューション
水野 博商 氏 / 植野 稔之 氏
http://togetter.com/li/257826

PayPalの説明でした。今後決済可能な手段として広く流通していくことを期待します。
例えば百貨店とかコンビニエンスストアとかね。
紹介していたビデオに描かれていた未来予想図はなかなか楽しめました。


【16-B-3】
教科書と現場のあいだ　～学びを活かすために～
和智 右桂 氏
http://togetter.com/li/257696

自分が価値があると思うことを相手に伝える技術は大切だと説いていらっしゃいました。
説得とか説明というのは自分にとって苦手な部分です。ちょっと反省。

【16-E-5】
デザインの最前線
田川 欣哉 氏
http://togetter.com/li/257704

takramの田川さんによるMUJI NOTEBOOK制作を題材にしたデザイン設計についてのお話。
MUJIとiPadのベン図の交わる部分がMUJI NOTEBOOKという説明はわかりやすかったです。

企業相手のシステムでは機能優先や導入技術に偏ったデザインになり失敗することが多いのですが、
コンシューマー相手ではエンジニアリング（機能）部分とデザイン（操作性、見た目）の両方が重要になります。
このため早い段階からお客さんにプロトタイプを見せることで、お客の理解度が上がり、共感を呼び、アイデアが出てくるとのこと。

企業相手のシステム開発では、設計書という仮説だけで詳細化が進み、不必要な仕様が付け加えられることがあるのですが、プロトタイプの利点は、具体と抽象の両面から製品開発にアプローチできることです。

シミュレーションで動かしても有効な結果は得られないので実機で確認する、というお話は継続的インテグレーションあるいは継続的デリバリーに通じるものを感じました。

まとめ
1 demo is more informative than 100 sketches.
Animation for not only screen.
Test the application with a right setting.

ユーザに残る体験の作り方としてヒントを教えていただきました。
製品の中に強いコントラストをつける
できるだけ複数の感覚を同時に刺激する
（挙げていただいた具体例を失念してしまいました）

お客との間で感覚を共有するのは大事なことだと思います。
企業向けの場合、やたらと機能とか新しい技術にこだわったデザインとなり、
失敗することが多いので気をつけたいと思います。
また、早い段階から実物を見せられるよう、日頃の練習（？）が必要ですね。


【16-B-7】
デブサミオフィシャルコミュニティから選出のLT大会2012
よしおか ひろたか 氏 / ショウジ ユウコ 氏 / 16コミュニティ参加
http://togetter.com/li/257878

Hack For JapanのOikawaさんのLTが印象的でした。

特許庁情報システム開発中断備忘録

特許庁情報システム開発中断についての備忘録です。

特許庁の発表は次の四点。

1. 作ろうとしていたもの
2005/7 「特許庁業務・システム最適化計画」(改訂版)について http://bit.ly/AmQPeI

2. 収賄事件の調査報告書（開発状況へのダメだし含む）
2010/8/20「特許庁情報システムに関する調査委員会」からの調査報告書の提出について http://bit.ly/xZHjJI

3. ダメだしが改善されていないのでヒアリング
2011/9 - 2011/12 特許庁情報システムに関する技術検証委員会 http://bit.ly/yzTy31

4. 開発中断報告
2012/1/24 特許庁情報システムの技術検証結果について bit.ly/yl0F3m

違和感を感じたのは2010/8の報告書の内容。三つある。
報告書の六割が「再発防止」を理由に開発状況の技術検証となっていること。
報告書第二部の収賄事件の背景にて、「業務要件確認書」が開発会社TSOLから納められていない事実があるとし、開発の停滞原因がTSOLだけにあるかのように書かれていること。
なぜTSOLが「業務要件確認書」を納品できなかったかの真因分析がなされていないこと。
上記三点から考えられるのは、この報告書はTSOLに分が悪く書かれており、TSOLによる開発をやめたかったのではないかということ。ひょっとすると最初から内部でTSOLの開発に反対の声があり、収賄事件を機に開発をやめさせる方向に動いたのかもしれない。

特許庁が提示した最適化計画を見ると、非常に複雑な印象を受けるが、人間が担う作業と、システムに対する操作と同列に書かれていたり、適切な業務分析がなされたかは疑問だ。本来RFPとしてユーザー側が開発するシステムに対して明確なビジョンや方針を作成すると思うが、それがなされていなかったのではないだろうか。

確かにTSOLは設計をスケジュール通りに終わらせられなかったかもしれないけど、その真因は報告書でも明らかにされておらず、依然として不明なまま。開発中断は正しい選択だとは思うけど、また同じことが起こる気がする。


参考
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い http://bit.ly/y6GbjM

特許庁の情報システムについて - myatsumoto blog http://bit.ly/wXHYbb

特許庁の情報システムについて - 技術検証委員会の議事録 - myatsumoto blog http://bit.ly/xD1iN4

2011 振り返り

2011年 KPT的振り返り

2011年をKPT的に振り返ってみます。KPTふりかえりについてはこちら。
http://www.slideshare.net/esmsec/kpt-5469874

Theme
ITに関すること

Keep
IT系イベント参加
- Agile Japan 2011 4/8 http://www.agilejapan.org/event/2011/
- JJUG Cross Community Conference 2011 Fall 10/12 http://www.java-users.jp/contents/events/ccc2011fall/
- Yapc::Asia 2011 10/14-10/15 http://yapcasia.org/2011/
- Scrum Gathering Tokyo 2011 10/19, 10/22 http://www.scrumgatheringtokyo.org/sgt2011/index.php?id=7

IT系勉強会参加および発表
- nseg #11 01/15, #18 08/27 http://nseg.jp
- jggug #15 2/24, #17 7/29 http://www.jggug.org

発表はnseg #11 Selenium RCの紹介
http://www.slideshare.net/sano66/selenium-rc-web-application-testing-tool

IT系イベントや勉強会は刺激を得られますね。
自身の発表する機会を得られたことが一番の収穫でした。
Selenium-RC使っていてよかった。

Problem
アウトプット不足
もう少しいろいろつくったり、発表できたと思います。
時間が足りないというのは言い訳ですね。
原因はなんだろう。モチベーションが足りないのかな。
IT勉強会やイベントで得る刺激が多すぎて目移りする、というのはありますね。
参加対象を十分に選択しなければいけないかもしれません。
もともと自分の許容量は小さいですし。

プレゼン技量不足
もっと場数をこなさないといかんなぁ。

プレゼンテーションzen

posted with amazlet at 12.01.01

Garr Reynolds ガー・レイノルズ
ピアソン桐原
売り上げランキング: 1138

Amazon.co.jp で詳細を見る

Try
Selenium 2.x の習得
Seleniumもバージョンがあがりました。
理解を深めまた発表する機会に備えたいと思います。
http://seleniumhq.org/

Project Euler挑戦
twitter経由で知ったProject Eulerですが数学の復習のようで楽しいです。
現在Javaで解いているのですが、これをRubyやGroovyなどの異なる言語で
挑戦することで言語の勉強に生かしたいと思います。
http://projecteuler.net/
http://github.com/sano66/projecteuler/

Yammer関連のアウトプット
yammerはドメインに閉じたマイクロブログサービスです。
APIがそこそこ充実しているのでなんか作ってみたいと思います。
http://yammer.com

読書時間の確保
じっくり本を読む時間を増やしたいと思います。


KPT的ふりかえりはこんな感じでいいのかな？ちょっと違う気もするけど、まぁいいや。
今年もよろしくお願いします。

HIP_343660280.189695

HIP_343660280.189695, a photo by Atsushi Sano on Flickr.

昨日ライブに行ってきた。
渋谷慶一郎 / ATAK Dance Hall set：Keiichiro Shibuya+evala
WWW 1st Anniversary 『分解☆渋谷慶一郎』

http://www-shibuya.jp/schedule/1111/001017.html

久しぶりに楽しい時間を過ごした気がする。やや興奮気味。

Scrum Gathering Tokyo 2011 Day2に行ってきた

10/22(Sat)に早稲田大学理工学部にて開催されたScrum Gathering Tokyo 2011 Day2が行われました。私はスクラムについての知識よりも実際の作業を体験したかったのでBoot Campに参加しました。

Boot Campでは「アジャイルサムライ」の監訳者でもある西村直人さんが講師となり、実習も交えながら一日がかりのScrum研修です。書籍や講演などで知識としてScrumを知っていても実際に何から始めればいいか迷っている私にとっては大変意義のある内容でした。

実践するにあたってのヒントをいくつか得ることができました。私にとってのヒントは以下のとおりです。

1. スプリントの完了条件を明確にすること



2. 技術的なスキル( TDD / CI / CD / リファクタリング )が必要であること



3. 問題点だけでなくチームの気分も透明にすること



4. 約束したことを守り続けること



5. テストできること、つまり実現を確認できること



6. 見積もりをチームでやること



7. 見積もりができる、すなわち扱えるということ

大変貴重な時間になりました。西村さんをはじめ、スタッフの方々ありがとうございました。

参考URL

Scrum Boot Camp

塹壕より Scrum と XP

"アジャイルサムライ−達人開発者への道−" (Jonathan Rasmusson)



追伸当日、TDD BC 長野 0.1 が長野市で行われていました。アジャイル開発においてはTDDは必要なので次回は参加したいと思います。

iPhoneから投稿テスト

googleサイトをマルチアカウントで利用できるiPhoneアプリを探していたところ、google作成のbloggerという名前のアプリを発見した。
どんなものかと思い、只今テスト中。

NSEG #18に行ってきた

第18回長野県ソフトウェア技術者グループ勉強会に行ってきました。
カレーの大原屋さん、幹事の方ありがとうございました。
充実した時間と、適度な刺激をいただきました。感謝です。
あと、遠方から参加された方々、夜三時までおつきあいくださりありがとうございました。

以下、自分のためのメモ

１　NSEGの紹介
今までのNSEGの活動を簡単に紹介
コンスタントに継続していることに改めて驚きを覚える。
主催者の勉強会への強い思いと、敷居が低さの現れなんだと思う。
これは私見なんだけど、勉強会は心療内科のグループカウンセリングに近いところがあると思う。
参加者が集まり、各自が思いを吐露するところがよく似ているような気がします。

２　カレーとプログラミング
@kagamiwariさんによるCurry言語の紹介とCurrey-Howard 対応についての説明
書籍紹介　論理の哲学

知の教科書　論理の哲学 (講談社選書メチエ)

posted with amazlet at 11.08.29

講談社
売り上げランキング: 400664

Amazon.co.jp で詳細を見る

"Curry-Howard correspondence"は初めて耳にした。
日曜日にネットを漁ってみたけれど理解に至らず。残念。

３　カレーと勉強会
カレーの大原屋ご主人小沢さんのプレゼン。
ソーシャルメディアを用いたお店の宣伝活動について語っていただいた。
書籍紹介　アイデアの作り方

アイデアのつくり方

posted with amazlet at 11.08.29

ジェームス W.ヤング
阪急コミュニケーションズ
売り上げランキング: 394

Amazon.co.jp で詳細を見る

刺さった言葉
"全てのアイデアは既存物の結びつきでしかない"
"情報収集のつもりが情報発信になっていた"
"それまでGoogle Mapのサテライト写真がなかったが、ウェブで紹介されてからサテライト写真が乗るようになった。Google すごいぜ!"

ソーシャルメディアで大切にしていることは、
レスポンスをタイムリーに返す、そのために情報導線を作った。（レジのとなりにPCを持ってきた）
ネガティブなことは言わない
とのこと。なるほど。
オヤジギャグをつぶやくとフォロワーが増えるとは知らなんだ。

４　PHPerによるEclipseプラグインの作り方
@zoolooskiさんによるプレゼン
PHPerと書いて"ペチパー"と読む

刺さった言葉
"きっかけは前々回山田さんのプレゼン"
"触りだしたら作りたくなった"
これ大事だと思う。
勉強会での刺激が、次の勉強会の刺激を生むいい例だと思います。

５　カレーとFirefox

@hATrayfloodさんによるFirefoxプラグインの作り方紹介
Mozilla関係者にはカレー好きが多いらしい。
「辛くて辛い」ときたから「禿びで禿げ」と返したかったのだがそれは自虐的なのでやめておいた。
以前に比べずいぶんとプラグイン作成が容易になったようだ。
デモはカレーの大原屋へのリンクアイコンをステータスバーに表示するプラグイン作成
なるほど記述も直感的だし、敷居が低くなった気がする。

６　ギネスブック申請と10兆桁の計算（途中経過）

近藤さんによるギネスブック申請の顛末
ギネスブックの始まりは「世界一はやい鳥は何か」をギネスビールの取締役が言い出したから。
ギネスブック申請は最初考えていなかった。周りから言われる度合いが高くなってきたので申請した。
ギネスブック申請は全て英語。日本語ガイド付きは有料。
円周率計算結果5兆桁をハードディスク４台に入れて送付（返却されない）
東京の大学の先生には証明が足りないと言われた。でもギネス申請受理された。
現在10兆桁に挑戦中。
7月の停電時にはあきらめたが、UPSが持ってくれてことなきを得た。
（昔、書籍に載っているプログラムを打ち込んでいる最中に、ブレーカーが落ちたときのことを思い出しました。）

学習要項には３で教えろとは一言も書いていない。「円周率を3でいい」とした報道がおかしい。
円周率教育について、3桁の計算を教える前に円周率3.14を教えるのがよくない。
「だいたい3とちょっと」から始めて、紐で測ったりして、精緻な数字にたどり着いていた。

ハードディスクにアクセスするとOSが邪魔する。からの、ファイルシステム談義
OSがWindowsだからじゃないか? Linuxならどうかしら?
Windowsだとドライブレターが24しか使えない
Linuxだとext4ファイルシステムの制限がある　zfsファイルシステムならどうかしら?
円周率の計算はハードディスクの耐久テストみたいだよね
日本人は儲からないと相手にしてくれない
円周率計算挑戦のきっかけはフランスの方の世界記録更新を聞いたから。


７　Rabbitの紹介
@tmtmsさんによるプレゼンテーションツールRabbitの紹介
Rabbitと高橋メソッドによるRabbitと高橋メソッドの紹介
Rabbitと高橋メソッドは相性がいい
高橋メソッドはLT向き
うさぎと亀により制限時間と進捗度が視覚的に表示されるところが優位

書籍紹介

MySQL徹底入門 第3版 ～5.5新機能対応～

posted with amazlet at 11.08.29

遠藤 俊裕 坂井 恵 館山 聖司 鶴長 鎮一 とみた まさひろ 班石 悦夫 松信 嘉範
翔泳社
売り上げランキング: 5483

Amazon.co.jp で詳細を見る

高橋メソッドはインパクトを与える、わかりやすいという点ですぐれたメソッドですね。
近藤さんが感心されていたのが印象的でした。

８　git超入門
@yamada_ken1さんのgitの入門
というよりこのプレゼンテーションを元にしたgit談義
参加者の半分ほどがsvn、三分の一ぐらいがgit、数名がmercurialな感じ。

書籍紹介

入門Git

posted with amazlet at 11.08.29

濱野 純(Junio C Hamano)
秀和システム
売り上げランキング: 9404

Amazon.co.jp で詳細を見る

入門git

posted with amazlet at 11.08.29

Travis Swicegood
オーム社
売り上げランキング: 14987

Amazon.co.jp で詳細を見る

JGGUG #17 G*ワークショップ に参加した

JGGUG #17 G*ワークショップ

品川NTTソフトウェアでの開催。
今日のお題は、次の二本。
▶「1.4.0.M1 !? 2.0.0.M1 -更新メモ-」 by 山本剛(ニューキャスト)(tyama)
▶「うさみみとJenkinsとG*な開発環境」 by きょんさん(kyon_mm)

内容が私には難しく、理解ができていません。消化不良気味です。
とはいえ、プログラミングGroovyも出たことですし、勉強をするきっかけにはなったかと思います。多分。
以下はメモです。推測や思い違いも入っています。

▶「1.4.0.M1 !? 2.0.0.M1 -更新メモ-」 by 山本剛(ニューキャスト)(tyama)
"プログラミングGroovy"によれば"GrailsはGroovyの言語特性とDSLを徹底的に駆使したWebアプリケーションフレームワークです。"
もともとはRuby On RailsのJava実装だったが、JavaによるRailsライクなフレームワークに実装方針が変更されてきている。
コンポーネントのバージョンは次のとおり
Groovy 1.8
Sprng 3.1
Servlet 3.0
Tomcat 7
Hibernate 3.6
jQuery
ソースコードはGraidleの使い方の勉強にもなる。一度読んでおくといいらしい。
山本さんの会社では100%Grailsで実装とのこと。
2.0からバイナリプラグインの提供が可能になった。

▶「うさみみとJenkinsとG*な開発環境」 by きょんさん(kyon_mm)
きょんさんの開発環境は
Jenkinsを中心に、いくつかのシステムを組み合わせている。
バグトラッキングシステムにRedmine
バージョン管理システムにMercurial
ビルドするのにGradle
テストコードを書くのにGroovy
テスト対象はJava

Groovyを使うようになったきっかけは三つ
Groovyを「やってみたかった」
自動テストを「やってみたかった」
AntとかMavenわからない

きょんさん曰く「GroovyはJavaというUnix哲学の言語をモダンにラップした言語」
人に便利さを説明する場合に5分かかっていてはだめ、3秒でできることが大事。
Groovyは学習コストが低く、機能を満たすコード量が少ないので、書くのに時間はかからない。

適用範囲はテストコードに限定して使っている。
テストコードをJavaを使って30秒かけて書くよりも、Groovyを使って7秒で書くことが大事。
dump()メソッドは便利
PowerAssert使うときれいな表示でわかりやすい。
テストコードのパッケージングをTDD用、ユニットテスト用、システムテスト用に分ける。
Jenkinsでどうなるかが判断基準。おそらくJenkinsの動作に負担を強いるような構成はとっていないと思われる。

RedmineはBacklogsのために入れているとのこと。
入力項目の多いバグトラッキングシステムは「ゆとり」だから使えない、と仰っていたがおこれは同意できる。必要最低限でいいと思う。SIerは意味のわからないメトリクス値を要求するとのこと。これは確かに閉口だ。

きょんさんはうさみみつけてた。びっくりした。

おまけリンク
20110729_第17回 G*ワークショップ(#jggug )
RedmineのBacklogsプラグインを入れてみた

JJUG 基礎セミナー HTML5&API入門へ行ってきた

JJUG 基礎セミナー HTML5&API入門へ行ってきました。講師は白石俊平さん。内容は初心者向けのHTML5入門といったところ。
HTML5についてはほとんど知らないのでちょうどいい内容でした。
HTML5&APIを使ったウェブページの表現力の豊かさに圧倒されてきました。
明らかにデスクトップアプリケーションとウェブアプリケーションの距離は縮んでいます。

以下は簡単なメモ。思い込みやうろ覚えも含んでいます。

それまでは文書のプラットフォームであったHTMLは、HTML5によりアプリケーションプラットフォームへと進化した。
狭義にはHTML5はHTML文法とDOMに関する仕様のアップデート
広義ではHTML5にJavaScript, CSS3も含められる場合がある
HTML5には3つの意義がある。

１つ目セマンティックWebとアクセシビリティ
"More Readable for Everyone"
健常者だけでなく全ての人に。
HTML4ではセマンティックの表現が乏しくdiv要素とスタイルシートのクラスで表現していた。
HTML5ではheader要素、footer要素、section要素など文書内の文の意味の表現が可能

２つ目互換性の追求
ブラウザの挙動、表現を同じに。
"Pave the Cowpaths"
HTML4で仕様が無かったり曖昧な部分の実装がブラウザ毎に異なっていた。
HTML5では既存のブラウザの実装から仕様を取り込んだ。
"Write at once, Run any Browser"
IE9の提供は評価できる。これでIE6, IE7, IE8とも決別できる。
Microsoft曰く、"IE6は9年前の腐った牛乳だ"

３つ目Rich Internet Application
canvas要素による表現力の強化
起動時に必要とするリソースを全てダウンロードしておくことで、オフラインでも稼働可能に。これにはローカルのデータベースIndexedDBを使う。
参考サイト Sticky Notes
デバイス固有の機能にアクセス可能。これはスマートフォンを意識した仕様。ただしセキュリティには気を使っている。ユーザの許諾無しにアクセスは不可。
例 GPS、マルチメディアファイル、アドレス帳、バッテリー、マシンの傾き、メール送信
これによりネイティブアプリとの機能差が縮小する。
WebSocketを使った高度なネットワーキング
ゲーム業界が注目　HTTPでシェイクハンド!?
ファイアウォールを超えられる
video要素によりマルチメディアの再生が容易
WebWorkersを使って、バックグラウンドでJavaScriptの処理させることが可能になった

まとめ
HTML5でウェブアプリケーションはバージョンアップする。
セマンティックウェブ、リッチインターネットアプリケーション
HTML5ではオープン標準を利用している(W3C, ECMA, など)ので仕様の互換性が保証される。
ベンダーロックインは無い。
CSS3を策定した人（名前は失念）が策定作業を活版印刷技術になぞらえて、「この先500年使われる技術仕様策定に関われて幸せだ」と言っている。

おまけ（質疑応答から）
ウェブアプリケーションの作り方は変わる。
それまではサーバーサイドで処理させていたが、できることはブラウザ側にやらせるようになる。
プログレッシブエンハンスメントというアプローチ
これは、ターゲットを新しいブラウザに置き、古いブラウザでは最低限の動作を提供する、という考え方
以前はどのブラウザでも同じに見えなきゃだめ、だった。
やっちゃいけないのはUSER_AGENTを使った判定処理。Modernizrを使ってブラウザの実装機能を判定するのがいいらしい。
HTML5によりクロスオリジンリソースシェアリングが可能になった。
それまでもJSONPを使ったハックがあったがあまりいいやり方ではない。

PerlでHTMLをエスケープ

perl -MHTML::Entities -p -e 'encode_entities($_);' file

Syntaxhighlighter

Syntaxhighlighterを使ってみる。

GoogleのPrettyPrintよりもよさそうだ。

こんな感じ

sub text2hello {
   my $arg = (@_);
  print $arg;
}

クラウドコンピューティングについて思うこと

クラウドコンピューティングってIT業界の潮流なので、エンドユーザの要件充足とは切り離して考えなきゃいけないと思うんだ。
手段であって目的じゃないよね。

GAE

Google App Engine for Javaを使ってみよう！　（1）Google Plugin for Eclipse（1/5）：CodeZine

GAEでごにょごにょ。
Spring ROOを使うため。

インドのIT産業は世界品質、片や日本は？ JBpress(日本ビジネスプレス)

以下の点からすると、これを取得しているからといって
インドのIT産業を世界品質というのはただのあおりでしかない。

CMMIのレベルを保証する機関がないこと
自己申告であること
基準達成は会社単位ではなく部署単位であること
できあがりのシステムを保証するものではないこと

インドのIT産業は世界品質、片や日本は？ 　JBpress(日本ビジネスプレス)

インドでは、徹底して欧米のシステム開発技法・方法論などを実践し、ソフトウエア品質を確保している。ソフト開発の実力を計る世界標準基準「SEI-CMM」の最高レベル「レベル5」を取得している世界の企業の半分以上は、インドの会社である。インドはいまや世界先端のシステム開発受託国となった。

　このままでは日本がどんどん置いていかれる一方になる。そう感じたインド訪問であった。

Test from blog write

テスト

>>楽譜は設計、演奏は実装

うまい例えだと思う。

余計な記述のある楽譜（設計書）の多いこと多いこと
楽器の構え方とかバルブの押さえ方も書いているから、
音楽（システム）として成り立たない。


楽譜は設計、演奏は実装 - Zopeジャンキー日記

しかしこの結果、「楽譜という設計」と「演奏という実装」が分離し、以下のようなメリットが生じた。

・作曲者は作曲（設計）に、演奏者は演奏（実装）に集中できる
・楽譜（設計書）のレベルで、管理や流通、保存ができる
・クラシック愛好者が、曲と演奏者の両方の基準で選択できる

そして決定的なのは、この仕組みによって、「いい曲が残る」ということだと思う。

成功するベンチャーと失敗するベンチャーの違い

このサイクルを可能にするようなアーキテクチャが求められると思うのだ。
つまりシステムのアーキテクチャのみならず、開発のアーキテクチャも構築するのが
アーキテクトの仕事なのではないのか？

成功するベンチャーと失敗するベンチャーの違い | きらら2号

ユーザに価値のある機能かどうかなんていくら会議しても正解は分からないのだから、結局は「作って、リリースして、フィードバック」のサイクルをしなければいけません。
そしてそのサイクルを出来るだけ短い期間でやることが重要になってくるのです。

2010年でやりたいこと

とりあえずあげておく
いくつできるか一年後が楽しみ

・「モジュール化」の読破と理解と応用
・ウェブデザイン勉強会開催
・selenium勉強会開催
・iPhone購入とアプリ作成
・iαppli作成
・香港旅行
・二胡レッスン始める
・タップダンスレッスン始める
・jpetstore-hacks再開

なぜ、日本のIT産業は世界で勝てないのか

世界で勝負しているIT産業がどれほどいるかわからないけど、
レベルの低いユーザをサポートできないぐらいIT企業のレベルが低いと思う。
これは技術力というよりはプレゼンテーション能力だったり、議論（ディベート）の能力かと思う。
自戒も込めて。

なぜ、日本のIT産業は世界で勝てないのか？ - 記者の眼：ITpro

かなり以前のことだが、日本のあるITコンサルティング会社の経営トップにこう聞かれた。私が答えに窮していると、その経営トップはズバリ言った。「ユーザー企業のレベルが低いからです」

macbook pro 13inch来た。

アップル - ノートパソコン - MacBook Pro - 新しいMacBook Proファミリーの登場です。

なかなか楽しい。