Google Web Toolkit

Google Developer Day 2008 Japan - Google Web Toolkit と AJAX

普段使っているJava IDEで開発、デバッグ、UnitTest可能。

デバッガの理論と実装

デバッガってどうやって動いているの？と聞かれて正しく答えられなかったので。

デバッガの理論と実装 (ASCII SOFTWARE SCIENCE Language) Jonathan B. Rosenberg 吉川 邦夫 アスキー 1998-02 売り上げランキング : 59943 Amazonで詳しく見る by G-Tools

琴線にふれたところ。

ソースコードが直接実行されているかのような錯覚を与えることにある。そうするためのトリックは、ソースコードに関して、また、それがどのように機械語命令にマップされているかについて、コンパイラに徹底したデバッグ情報を提供させることである。

Microsoftなどのベンダーは、デバイスドライバ開発者のために、OSを2種類提供している。その1つは市販のバージョンで、完全に最適化され、デバッグ用のシンボル情報を持たない。もう1つは、Microsoftが「チェックされた」ビルドと呼んでいるもので、最適化を外すかそのレベルを下げるかした、完全なデバッグシンボル付きのビルドであり、デバッグ中に詳細なスタックトレースや主要な変数の調査ができるようになっている。

ハードウェアによるデバッグサポート

• ブレークポイント
• シングルステップ実行
• 例外の検出
• ウォッチポイント
• マルチスレッドの制御
• マルチプロセッサの制御

シングルステップ実行

デバッガは、現在のプロラムカウンタの位置にある命令をデコードし、正確にその次の命令の位置にブレークポイントを設定し、デバッギを通常どおりに実行させることによって、シングルステップをシミュレートすることができる。

ウォッチポイント

プロセッサにベースとリミットのレジスタを持たせ、それらで開始アドレスと範囲を指定する方法である。こうすればプロセッサ自身が、このアドレス領域内でのデータの書き換えをストップし、その書込みが行われる前に実行を停止することができる。

Win32のデバッグAPI
フラグを立ててCreateProcess()または、既存プロセスにDebugActiveProcess()
各スレッドのレジスタ値はGetThreadContext()、状態変更はSetThreadContext()
ブレークポイントやコードのパッチはReadProcessMemory()、WriteProcessMemory()
デバッギの状態変化をWaitForDebugEvent()で待つ。

Adding a Google Translation Shortcut to Firefox

http://blogoscoped.com/archive/2008-12-09-n59.html

If you often translate bits and pieces using Google Translator, here’s one way to quickly access it:

英語→日本語の場合は
http://translate.google.com/translate_t#en%7Cja%7C%s
でよさそう。

Eric Sink on the Business of Software

Geek向けの起業指南本。

Eric Sink on the Business of Software (Expert's Voice) Eric Sink Apress 2006-03-27 売り上げランキング : 19952 Amazonで詳しく見る by G-Tools

訳本はこれみたい。

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方 青木 靖 翔泳社 2008-09-11 売り上げランキング : 3946 おすすめ平均 Amazonで詳しく見る by G-Tools

内容は著者のMSDNの連載をまとめたもので、著者のブログも引用されていました。
http://www.ericsink.com/
WHINING BY A BARREL OF ROCKS > The Importance of Barrel Research

業界をよく表現している。

Software niches are a bit different from traditional markets. Software generally does not respect geographic limitations, especially now that the Internet is everywhere. Products like concrete and lumber tend to be extremely regional, but a software niche might be global.

STARTING YOUR OWN COMPANY > Know Thyself

Myers-Briggs Type Indicator (MBTI)が紹介されていた。

One way to increase your self-awareness is to take a standard personality test. There are several such tests, but my favorite is the Myers-Briggs Type Indicator (MBTI).

http://www32.ocn.ne.jp/~emina/
私は「ＥＮＦＰ型：余計な苦労をかってでる」でした。
http://www32.ocn.ne.jp/~emina/typebox/enfp.html

コミュニケーションスキル
1.聞き手上手。80%は聞き役にまわる
2.e-mailを出す前に読み直す
3.e-mailは感情的になりやすいので落ち着いて書く

STARTING YOUR OWN COMPANY > Choose Your Product

ソフトウェア産業は成熟産業。horizontal marketsには大企業がいて勝負にならないから、vertical marketsで勝負せよ。(表計算が"industry leaders in bowling software,"で、「"industry leaders in bowling software,"」が"industry leaders in bowling software,")

STARTING YOUR OWN COMPANY > Make the Numbers Add Up

ISVのはじめ方。社員に40時間アルバイトさせて残りの40時間で本来の製品を開発する。

実際に、自分でISV立ち上げの実験してみた記録が興味深い。(Winnable Solitaire experiment)

Joel on Software

ジョエルテストが有名。今の開発現場では当たり前かもしれません

ジョエルテスト
1.ソース管理してる？
2.ワンステップでビルドできる？
3.デイリービルドしてる？
4.バグデータベースはある？
5.新しいコードを書く前にバグを直してる？
6.アップデートされているスケジュールがある？
7.仕様書はある？
8.プログラマは静かな環境で作業している？
9.手に入る最高のツールを使っている？
10.テスタはいる？
11.採用面接のときにコードを欠かせてる？
12.ユーザビリティテストはしてる？

9.やさしいソフトウェアスケジュール

5.タスクの粒度を細かくすること

タスクは、日単位ではなく、時間単位で計測すべきである。

面倒くさがって大きな塊のタスクを選択した場合、何をすることになるのか実際には考えていないだろう。

9.スケジュールにデバッグの時間を入れる！

たぶん、最初にコードを書くのにかかった時間の100%から200%の時間をデバッグで使ったことだろう。

データを収集する
短くて要点をついた自動クラッシュレポートダイアログを表示させる。
私たちが自動的に収集しているデータ
*製品の正確なバージョン
*OSのバージョンとInternet Explorerのバージョン
*クラッシュが起きたコードのファイルと行番号
*エラーメッセージの文字列
*そのタイプのエラーに固有の数値コード
*ユーザが何をしていたかについてのユーザの記述
*ユーザのe-mailアドレス

Win32 APIの構造化例外処理(UnhandledExceptionFilter)

ソフトウェア見積り

!!第1章　見積もりとは
!見積もり、ターゲット、コミットメント(p4)
見積もりとコミットメントは同じではない。
:見積もり:プロジェクトにかかる期間やコストを予測すること
:ターゲット:実現したいビジネス上の目標を明文化したもの
:コミットメント:定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束

!確率論としての見積もり(p7)
""

パーセント角度とシングルポイントの見積もりの値とを併用して、「24週間のスケジュールで完了する確度は90%のように用いる

!「良い」見積もりの実務的な定義(p15)
""

良い見積もりとは、プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な視点を提供する見積もりである。

!!第3章　正確な見積もりの価値

!パーキンソンの法則(p24)
作業は使用可能な時間を使い尽くすまで拡大する

!過大見積りと過小見積もり(p27)
過大見積りはパーキンソンの法則に起因する直線的な不利益（工数、コスト、スケジュール増）だが、過小見積もりの不利益は直接的でなく限界がないので深刻。

!ソフトウェア業界の構造的な問題(p30)
業界のデータから、ソフトウェア業界には過小見積もりの問題がある。

!正確な見積もりの利点(p31)
*状況の可視化が進む
*品質が向上する
*ソフトウェア以外の業務部門との連携が良くなる
*予算が良くなる
*開発チームに対する信頼が向上する
*早期にリスク情報が得られる

!予測可能性の価値(p33)
経営陣はコスト、スケジュール、機能を知りたい。
実現する機能を数パターン検討してコミットできるスケジュールのばらつきを比較できるように図示することで、ばらつきの少ない選択肢を承認してもらいやすい。

!!第4章見積もり誤差はなぜ起きる？

!不確実性のコーン(p40)
プロジェクトスコープ（工数、コスト、機能）の見積もりにおけるばらつき（最大見積もりと最小見積もりの区間）は、初期コンセプト、製品定義の承認、要求の完了、ユーザーインターフェース設計の完了、詳細設計の完了、ソフトウェアの完了と時期でばらつきが狭まってコーンの形を作る。

プロジェクトからバラつきの原因を取り除いてコーンを狭くしよう。

!不確実性のコーンとコミットメントの関係(p45)
見積もり誤差が２０％以内であればプロジェクトを完了に向けてナビゲートできる。コーンが初期の広い部分では、有意義なコミットメントは不可能。コーンを狭くする作業を終えるまでコミットメントを遅らせる。

!不安定な要求(p47)
要求が安定しない場合は不確実性のコーンは狭くならない。要求変更はトラッキングされないことが多く、再見積もりすべきなのにされない。要求が安定できない状況では反復型、スクラム、XP、DSDMなどの開発手法を検討する。

!アクティビティの見落とし(p49)
*セットアップ/インストールプログラム
*データ変換ユーティリティ
*サードパーティやオープンソースソフトウェアを使うためのグルーコード
*ヘルプシステム
*配置モード
*外部システムとのインターフェース

!!第6章　見積もり技法入門

!プロジェクトの規模(p85)
:小規模:5人以下。実際に作業を行うここのメンバーが作成する見積もりを元にプロジェクトの見積もりを作成するボトムアップ技法が最適。
:大規模:半年から一年以上継続する25人以上。初期はトップダウン技法、中期以降は組み合わせ。
:中規模:5人から25人。

!!第7章　数えて、計算して、判断する
見積もりの基本は数えること。数えられない場合は計算する。それもできないときのみ判断する。

!何を数えるか？(p91)
p93表7-1に以下の数えたデータの使用例がある。この表のデータを収集することで、過去のデータとして工数の見積もりなどの計算に使うことができる。
*初期
**マーケティング要求
**機能
**ユースケース
**ストーリー
*中期
**エンジニアリング要求
**ファンクションポイント
**変更要求
**Webページ
**レポート
**ダイアログボックス
**スクリーン
**データベーステーブル
*後期
**書きあがったコード
**欠陥指摘数
**クラス
**クラスタ

*見積もり対象のソフトウェアの規模と関連性が高いものを探す
*開発サイクルの早い時期に手に入るものを探す
*統計的に意味のある（数が大きいもの）平均値を出せるものを探す
*何を数えているのか理解する
*最小の労力で数えられるものを探す

!!第8章　補正と過去のデータ

!収集するデータ(p101)
*規模（コード行数など）
*工数（人月）
*時間（カレンダー月）
*欠陥（重要度によって分類されたもの）

!規模の測定方法を決める必要がある
*コードの数え方（リリースコードだけかどうかなど
*再利用コードの扱い
*ブランク行、コメント行
*クラスインターフェイスを数えるか
*データ宣言

!工数の測定方法を決める必要がある
*時間の単位
*1日何時間か？
*サービス残業を数えるか
*休日、休暇、ミーティング
*どんな種類の工数を数えるのか（要求、設計、調査、
*複数のプロジェクトの数え方
*過去のリリースのサポート時間
*展示会などのサポート時間
*移動時間
*下準備のあいまいな時間、

!プロジェクトが終わったらできるだけ早くプロジェクトの過去のデータを収集する
進行中にも収集する。規模と工数と欠陥について１～２週間ごとにデータを収集すると有益。

イノベーションと競争優位

「優れた産業技術を開発し、それを装備した製品をいち早く市場に出しても、イノベーターの競争優位と利益の獲得につながらない、あるいは獲得したはずの利益が継続しないことが多い。」
この問題について薄型テレビ、DVDプレイヤー、HDD、携帯電話、デジカメなどのデジタル機器の競争と戦略を議論している。


本書の目的は、「イノベーションを利益に結びつけ企業成長につなげるという課題解決のための方策を明らかにする」こと。

原因は、（１）経済全体のグローバル化、（２）製品アーキテクチャが摺り合わせ型からモジュラー型への変化、（３）企業ドメインが日本企業の統合型ドメインからデルのような特化型ドメインのように多様化していることによる。

それらにより、製品がコモディティ化して価値獲得に失敗している。

!!付加価値創造(p16)
ものづくりを付加価値や利益に結びつけるには、価値創造と価値獲得の視点が必要。

!価値創造
技術的イノベーションで顧客価値の高い商品を創造。
価値創造プロセスで高品質、低コスト、スピードを実現する。

!!製品アーキテクチャ
デジタル商品がモジュラー化して過当競争が起きている。
自動車は、日本企業が得意なインテグラル型で摺り合わせに高い技術が必要なため強い。
一方、PCやDVDなどは製品アーキテクチャがモジュラー化されているため他国企業に勝てない。要因としては、コスト、グローバルな仕組みづくり、プラットフォームリーダーになれないこと。

!!コモディティ化(p24)
コモディティ化の定義「参入企業が増加し、商品の差別化が困難になり、価格競争の結果、企業が利益を上げられないほどに価格低下すること」
モジュラー化はコモディティ化を促進する。

!!日本企業の価値獲得戦略

モジュールでの価値獲得とは部品やモジュールでもうけること。継続して利益を得るにはプラットフォームリーダーになることが重要。

アセンブルでの価値獲得は、中国で製造してもコスト優位性で競争するのは難しい。
デルはグローバルサプライデマンドチェーンを構築して成功しているが日本企業の成功例はない。
機能的価値でなく意味的価値により大きな付加価値を有む。iPodなど。

よって、モジュールとアッセンブルの組み合わせが有力。独自性の高いモジュールを高度に摺り合わせて付加価値の高い製品を創出。

商品ライフサイクルの最初は摺り合わせ戦略が有効だが、モジュラー化していき利益やシェアが減っていく。

!!統合型企業のジレンマ
完成品メーカーがキーデバイスを重視しそれを内製化するのは勝利の方程式だが、部品生産の利益を上げると社内需要の規模を上回るため、外販する必要があり、モジュラー化、コモディティ化するというジレンマがある。

!!松下のPDP
垂直統合型。グローバルウィナーを目指す戦略。価格競争にも勝つ。

!!デルのBTO
デルはコモディティ化を積極活用している。SGA（原価以外の費用）は１０％以下。日本企業は３０％程度。また、キャッシュフローを重視。部品コストの低下をリアルタイムに取り込んで製品価格を下げる。利益が大きくなりすぎたら価格を下げてコモディティ化を促進。

!!光ディスク
技術流出でなく、積極的に技術移転を行って自らコントロールして協業する。

!!中国やアジア地域の海外投資
低賃金労働力の利用ではなく、本国では到達できない量産規模を海外で達成させ、確実にスケールメリットを獲得すること。

!!サムスン、LG
日本の技術を後追いして投資競争で勝ったわけでなく、学会発表件数などで逆転していた。