カテゴリ:読書記録( 67 )
【感想】ガベージコレクションのアルゴリズムと実装 (アルゴリズム編)
日本語で書かれたものとしては初めての「ガベージコレクション (GC)」の本だそうです。
「アルゴリズム編」と「実装編」に分かれているうち、とりあえずアルゴリズム編まで読み終わったので、その感想。

GC の基本が一通り説明されていて、僕みたいな GC 素人でも、すんなりと読むことができた。それぞれのアルゴリズムや手法のメリットとデメリットも明記されていて、初心者にもやさしいつくり。

一方で、ちょっと不満だったのが、全体の構成、というか章立て。
第1章 GCを学ぶ前に
第2章 マークスイープGC(Mark Sweep GC)
第3章 参照カウント(Reference Counting)
第4章 コピーGC(Copying GC)
第5章 マークコンパクトGC(Mark Compact GC)
第6章 保守的GC(Conservative GC)
第7章 世代別GC(Generational GC)
第8章 インクリメンタルGC(Incremental GC)
という構成になってるんだけど、これだと基本的なアルゴリズム (マークスイープ、参照カウント、コピー GC) と、それに直交する概念 (保守的GC / 正確なGC、世代別 GC、インクリメンタル GC) が並記されてしまって、お互いの関係がちょっと分かりにくかった。他にも、「第6章 保守的 GC」 の中に、保守的 GC と正確な GC の説明が入っていたりするような細かい不満点もちらほら。GC Wiki はきちんとした構成になってるのに、本はなんでこんな構成になっているのかが疑問 (著者は一緒なのに、ねぇ)。

というわけで、次は実装編なわけですが、こっちは難易度が少し高めな感じ。読むのは少し時間がかかりそう。

ガベージコレクションのアルゴリズムと実装

ガベージコレクションのアルゴリズムと実装

関連ページ:
ガベージコレクションのアルゴリズムと実装|サポート|秀和システム
[PR]
by fkmn | 2010-04-30 23:55 | 読書記録
【感想】Web を支える技術
Webを支える技術 -HTTP、URI、HTML、そしてREST

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)


 Web に関わる技術が、基本的なところから実践的に解説されている本。特に、HTTP、URI、HTML といった要素技術のそれぞれの関連が明確になっているところが、この本の良いところだと思う。「リンク」にこだわる筆者の面目躍如といったところだろうか。

 今まで何となくで済ませてきた内容を改めて知ることができたし、断片的だった知識が頭の中で整理されて、本書を読んで勉強する事はとても多かった。例えば、REST というアーキテクチャスタイルについて、繰り返し実践的な形で語られるので、読み終わった頃には REST の考え方が自然に受け止められるようになった。単純に知識的な点で言うと、Atom 周りは全然知らない話ばかりだったので新鮮に読むことができた。

 今後、Web に関わる人であれば、読んでおいて損はない、というか、読んでおかなければいけない本だと思う。


関連ページ:
Webを支える技術サポートWiki - qwik.jp/webtechbook
Togetter - まとめ「『Webを支える技術』編集後記+α」
[PR]
by fkmn | 2010-04-18 22:58 | 読書記録
「入門Git」は噂通りの神本だった

入門Git
4798023809


 既に各所で絶賛されている「入門Git」を読み終わった。これは、噂に違わぬかなりの良書。読んだ後に何とも言えない充足感まで感じてしまった。

 書いてある内容については、他で語られているとおりなんだけど、角谷さんのスライドの中 (84p) ですごく良くまとめられているのを見つけたので、失礼ながら勝手に引用。
“The Git Way”の白眉
  • ワークフローのためにツールがある
    • “Linus君の究極のコンテンツトラッキング”
    • パッチベースのワークフロー
  • 目にみえる手段の背後にある考えかたの重要性
Making Software Development Agile With Ruby
* もっとも、「The Git Way」とかいう別題は、著者の濱野さんにとってはイマイチみたいだけど

 とにかく、Git を使う人だけではなく、何かしらの VCS を使う人だけではなく、ソフトウェア開発に関わる人みんなに読んでもらいたい。技術書とはかくあるべき。

リンク:

[PR]
by fkmn | 2009-11-19 23:55 | 読書記録
【感想】Java並行処理プログラミング —その「基盤」と「最新API」を究める—
 ひげぽんさんのエントリを読んで、図書館で貸し出し予約をして、実際に手元に届くまで半年。大人気です。

 前半の第一部では、マルチスレッドプログラミングおける注意点やコツについて、後半の第二部では、Java の並行処理用の各種部品について、最後の16章では、Java のメモリモデルについてまで解説されている。

 Java の本だけど、他言語メインの人も、第一部だけ読んで、(Javaに限らない) マルチスレッドプログラミングの肝を掴むとか、第二部を読んで、Java がマルチスレッドプログラミングのために工夫している部分について学ぶとかいった使い方ができると思う。

 扱っている内容が実践的なので、ぜひとも手元に置いておきたい本なんだけど、絶版になってしまっているのが残念。
 復刊ドットコムでの交渉がはじまっているみたいなので、そちらに期待。


Java並行処理プログラミング ―その「基盤」と「最新API」を究める―

4797337206
ソフトバンククリエイティブ 2006-11-22
売り上げランキング : 169096
おすすめ平均 star

Amazonで詳しく見る
by G-Tools


以下、読書メモ。


1章 はじめに

- NPTL スレッドパッケージ (Linux2.6以降、カーネルのデフォルトのスレッド機能)


2章 スレッドセーフ

2-1 スレッドセーフって何?
- クラスは複数のスレッドからアクセスされたときに
正しく動作するならスレッドセーフである。

- ステートレスなオブジェクトはつねにスレッドセーフ

- 複合アクション
- リード・モディファイ・ライト
- チェック・ゼン・アクト
- 遅延初期化

- java.concurrent.atomic パッケージ


3章 オブジェクトを共有する

- メモリの可視性

3-1 可視性
- volatile を宣言されていない64ビットの数値 (double と long)
=> JVM は 64 ビットのリードとライトが
二つの32ビット操作である事を許している。

- 揮発性変数 (volatile):
そのリードはつねに、あるスレッドが書き込んだ最新の値を返す

- ロック => 可視性とアトミック性の両方を保証
揮発性変数 => 可視性だけを保証

3-2 公開と逸出
- NGなコード
- private なフィールドが外部から変更可能になる例
class UnsafeStates {
private String[] states = new String[] { "AK", "AL" };

public String[] getStates() { return this.states; }
}

- this参照の逸出

- スレッド拘束
- java.lang.ThreadLocal

- スタック拘束

3-4 不可変性
- Arrays.copyOf (Java6から)

3-5 安全な公開
- オブジェクトの利用と共有のためのポリシー
- スレッド拘束
- リードオンリーの共有
- スレッドセーフな共有
- ガード

4章 オブジェクトを組み立てる

4-1 スレッドセーフなクラスを設計する
- スレッドセーフなクラスの設計
- オブジェクトのステートを構成する変数 (ステート変数) を同定する
- ステート変数の値などを制約する不変更を同定する
- オブジェクトのステートへの並行アクセスを管理するためのポリシーを確立する

4-3 スレッドセーフを委譲する
- java.util.Collections.unmodifiableMap メソッド

- java.util.concurrent.CopyOnWriteArrayList

4-5 同期化ポリシーをドキュメントする
- ドキュメンテーションはスレッドセーフ性を管理するための
最高に強力なツールの一つ


5章 並行処理の構築部材

5-3 プロデューサ・コンシューマパターン

5-5 シンクロナイザ
シンクロナイザ: 自分のステートを使ってスレッドのコントロールフローを調停するオブジェクト
セマフォ、バリヤ、ラッチ など。

java.util.Conccurent
- CountDownLatch
- FutureTask (implements Future)
- Semaphore
- CyclicBarrier
- Exchanger

5-6
メモ化をスレッドセーフにする。


6章 タスクの実行

6-2 Executor フレームワーク
- java.util.conccurent
- Executor
- ExecutorService

- タスクの依頼と実行を分離する事で、
実行ポリシー (タスク実行の "what, whre, when, how") を簡単に指定できる。

- NG: java.util.Timer
OK: java.util.concurrent.ScheduledThreadPoolExecutor

6-3
- java.util.concurrent.CompletionService

- Future.get の時間指定付き呼び出し

- ExecutorService.invokeAll


7章 キャンセルとシャットダウン

Thread.stop と suspend には深刻な欠点があり、使うべきではない。

7-1. タスクのキャンセル
- volatile フィールドを使った協力的キャンセル

- スレッドは、インタラプションポリシーを持つべき

- インタラプションポリシーが分かっていないスレッドを
インタラプトしてはいけない

- java.util.concurrent.ThreadPoolExecutor の newTaskForフック

7-2. スレッドを使っているサービスを停止する
- スレッドを所有するサービスに、スレッドのシャットダウンの仕組みを持たせる

- プロデューサ・コンシューマ型のサービスのシャットダウン
- 毒薬 ("これをもらったら停止せよ" を意味するオブジェクト)

- java.lang.Thread.UncaughtExceptionHandler インタフェース


8章 スレッドプールを利用する

8-1 タスクと実行ポリシーの暗黙の結合
- Executor フレームワークではタスクの依頼と実行を切り離しきれない
タスクのタイプ
- 依存性のあるタスク
- スレッド拘束を利用しているタスク
- 応答時間に敏感なタスク
- ThreadLocal を使うタスク

8-3 ThreadPoolExecutor
- java.util.concurrent.ThreadPoolExecutor

- ThreadPoolExecutor のコンストラクタに渡すオプションのほとんどは、
コンストラクションの後でセッターメソッドを使って変更できる。

8-4 ThreadPoolExecutor を拡張する
- ThreadPoolExecutor は、拡張される前提で設計されている


9章 GUIアプリケーション

9-3
- SwingWorker クラス
長時間のタスクをバックグラウンドのスレッドで動かして、
GUIの応答性を維持するためのフレームワーク


10章 生存自己を防ぐ

10-1 デッドロック
- ロックの順序を固定する。

- 引数の順序で、ロック順が変化する場合は、
Sysytem.identityHashCode でロック順を誘導。

- 引き分けロック (第3のロック)

- ロックを保持した状態で、別のロックを保持するよそ者メソッドを呼び出すと、
デッドロックの可能性が高まる (しかも、分析が難しい)。
できるだけオープンコールを使うようにする。
オープンコール: ロックを保有しないでメソッドを呼び出す事


10-2 デッドロックの防止と診断
- Lock クラスの tryLock メソッド (時間制限付きのロック)

- スレッドダンプの出力
- Unix
- SIGQUITシグナル (kill -3)
- Ctrl-\
- Windows
- Ctrl-Break

10-3 そのほかの生存事故
- 飢餓状態
- シグナル喪失
- ライブロック


11章 実行性能とスケーラビリティ

11-2 アムダールの法則
ー 並列化できる部分と直列の部分の比率が重要。

11-3 スレッドがもたらす費用
- コンテキストスイッチ
- コンテキストスイッチの回数とそのために消費された時間の表示
- Unix : vmstat
- Windows: perfmon

- メモリの同期化

- ブロッキング

11-4 ロックの争奪を減らす
- 排他的ロックに代わる並行的フレンドリーな方法
- 並行コレクション
- リードライトロック
- 不可変オブジェクト
- アトミックオブジェクト
- etc.

- 通常は、オブジェクトを新たに作る方が、
既存のオブジェクトを同期化して使うよりもチープ


12章 平行プログラムを試験する

12-1 正しさを試験する
- スケジューリングのランダムさの確保
ループの中でスレッドをスタートさせると、スレッドは直列っぽく走る
(スレッドの作成とスタートは、程々に重い操作なので)
- 対応として、CountDownLatch や CyclicBarrier を使う

- 並列に動くスレッドの混じり具合をより多様にするために、
テストをマルチプロセッサのシステムで動かすべき。
さらに、アクティブなスレッドの数をCPUの数より多くする。

12-2 実行性能を試験する
- 複数のアルゴリズムを比較する

- 応答性を計測する

12-3 試験の落とし穴を避ける
- ガーベッジコレクション

- 動的コンパイル
- HotSpot は、-XX:+PrintCompilation で
動的コンパイル時にメッセージを出力する

- 処理系によるデッドコード (意味の無いコード) の排除


13章 明示的なロック

13-1 Lock と ReentrantLock
- java.util.concurrent.locks.ReentrantLock
- 固有のロックが持つ制約(*)を受けないロックの仕組み
* ロックの入手を待ってブロックしているスレッドにインタラプトできない
ロックを入手したコードブロックと同じブロックの中で解放する必要がある

- Lock.lockInterruptibly メソッドを使うと、
インタラプションへの応答性を維持したままロックの取得をトライできる

13-3 公平性 (fairness)
- 不公平なロックの良好な実行性能が、キューの公平性よりも重視される
(ロックの獲得にはコストがかかるので)

13-4 synchronized と ReentrantLock の使い分け
- ReentrantLock
- 時間制限付きのロック待機
- インタラプトできるロック待機
- コードブロックに縛られないロック
=> ReentrantLock は synchronized よりも明らかに危険なツール

13-5 リードライトロック
- ReadWriteLock インタフェース


14章 カスタムシンクロナイザを構築する

自作のシンクロナイザの作り方とその利用方法、メリットとデメリットについて。
固有の条件キュー

14-3 明示的な条件オブジェクト
- java.util.concurrent.locks.Condition インタフェース

14-5 AbstractQueuedSynchronizer
ロックとシンクロナイザを構築するためのフレームワーク


15章 アトミック変数とノンブロッキング同期化

15-2 ハードウェアの並行性サポート
- ほとんどの現代的なプロセッサに、
何らかの形のアトミックなリード・モディファイ・ライト命令がある

- compare and swap
- IA32 や Sparc など

15-3 アトミック変数
- ハードウェアの並行性サポートを直接使う
- 全12クラス
- 4つのグループ
- スカラー
- フィールドアップデータ
- 配列
- 複合変数

15-4 ノンブロッキングアルゴリズム
- 値を投機的に更新し、更新に失敗したらリトライする
# エラー忘却型コンピューティングに通じる考え方?


16章 Java のメモリモデル
- 半順序

- 排他性と可視性

[PR]
by fkmn | 2009-10-25 12:59 | 読書記録
「Rubyソースコード完全解説」を入手した
a0057891_214926.jpg


 Amazon の中古商品予約で 1万円 で購入。注文してから入手まで、だいたい半年くらいかかった。

 パラパラと中身を眺めてみたけど、コードの説明が結構詳細で、読めばそれなりに分かりそうな雰囲気。

 でも、今は パタヘネ でいっぱいいっぱいなので、読む暇はないなぁ。読み始めは来年当たりになりそう。「RHG の逆襲」にもそのうち参加したいなぁ。
[PR]
by fkmn | 2008-11-05 23:55 | 読書記録
【感想】達人プログラマー ― システム開発の職人から名匠への道
達人プログラマー―システム開発の職人から名匠への道
達人プログラマー―システム開発の職人から名匠への道

 Code Complete とほぼ同じような内容。ただ、こっちの方がすっきりとまとまっている。Code Complete を読んだ後だと、あまり新鮮味が無いかもしれない。それから、微妙に内容が古くなっているのも気になるところ。まぁ、内容が古くなっているところは、適宜、今風に読み替えれば良いだけなんだけれど (例えば RCS/CVS -> SVN等)。

 それから、Code Complete と違って、ソフトウェア開発を建築というメタファーで語ることに反対しているところに好感。ここが、Code Complete で一番納得できないところだったので。

 以下、気になったところの個人的な読書メモ (まとめ)。

知識への投資は利息がついてくる。
ただし、そういった資産は残念ながら有効期限付き。
金融商品と同じように知識についてもポートフォリオを考えるべき。
 そのためのガイドラインは以下の通り。
 ・定期的に投資を行う
 ・多角化
 ・リスク管理
 ・安く買い、高く売る
 ・見直しと再配分
p.13-14

DRY原則は、達人プログラマーの道具箱の中にある道具のうちでも、
最も重要なものの一つ
p.27

「プレイン・テキストの威力」
知識を永続的に格納するためのフォーマットで
最も適しているものがプレインテキスト。
プレイン・テキストを使えば、
 ・透明性が保証され
 ・さまざまな活用ができるようになり
 ・テストが容易になる
p.71-77

「ストレート・ジャケット効果」
コーディング担当者に解釈の余地を与えない設計というものは、
スキルや技芸といったプログラミング努力を奪い去ってしまう。
p.221

[PR]
by fkmn | 2008-11-03 23:55 | 読書記録
【感想】ゲノムを支配する者は誰か / ザ・ゲノム・ビジネス
ゲノムを支配する者は誰か―クレイグ・ベンターとヒトゲノム解読競争  ザ・ゲノム・ビジネス―DNAを金に変えた男たち

ゲノムを支配する者は誰か―クレイグ・ベンターとヒトゲノム解読競争
ザ・ゲノム・ビジネス―DNAを金に変えた男たち

 ゲノムプロジェクトについての顛末を描いた2冊。「ゲノムを支配するものは誰か」は、記述がなるべく "科学的" になるように気を使っていて、背景となる科学技術にもキチンと紙幅を咲いているのに対して、「ザ・ゲノム・ビジネス」は、ひたすら人間模様 (特にベンター) を描くことに注力している。

 ゲノムプロジェクトの科学的意義について知りたいのであれば前者の方がおすすめだけど、読み物としては後者の方が圧倒的に面白い。「ザ・ゲノム・ビジネス」の原著者は、本書のために、セレラに2年間通い詰めて取材したとのことで、ディテールの描写がとても細かく、まるで自分がその場に居合わせているような気にすらなる。この本のドラマ化とか映画化とかは企画されてないのかなぁ?もし実現したら、結構ヒットするんじゃないかと思うんだけど。
[PR]
by fkmn | 2008-11-01 23:55 | 読書記録
【感想】Unix/Linuxプログラミング 理論と実践
Unix/Linuxプログラミング理論と実践
Unix/Linuxプログラミング理論と実践

 勢いで買ってみたものの、C言語がよくわからなくて K&R から始めたりするなどの紆余曲折を経て、やっと読了。長かった・・・。振り返ってみると 6月初めにこの本を買った って昔の僕が言ってるので、かれこれ半年ほどの付き合いだったらしい (まぁ、ずっとこの本読んでたわけではなくて、途中でいろいろ浮気してたので、これだけかかったってのもあるけど)。

 読み終わってみると、プロとして Unix/Linux と付き合うにあたって、最低限この本に書いてあることぐらいは把握するべきだと思う。書こうと思えば、ls とか who とかのコマンドにかぎらず、シェルまで書ける、という感覚は結構重要。

Unix プログラミングはあなたが思うほど難しくはないが、最初に想像したほど優しくもない
p. 49
まさにこのとおり。
[PR]
by fkmn | 2008-10-28 23:55 | 読書記録
「サイエンス・ビジネスの挑戦 バイオ産業の失敗の本質を検証する」の読書メモ
サイエンス・ビジネスの挑戦 バイオ産業の失敗の本質を検証する
Amazon.co.jp: サイエンス・ビジネスの挑戦 バイオ産業の失敗の本質を検証する: ゲイリー・P・ピサノ, 池村 千秋: 本

きちんと読み込む必要が発生したので、内容をメモ。

著者について
- ゲイリー・P・ピサノ (Gary P Pisano)
- バーバード・ビジネススクール教授

はじめに
・研究の動機 (研究開始は、20年以上前)
バイオテクノロジー (BT) 産業の以下の特徴に惹かれた
1. 研究開発と組織の仕方に関する新しい実験とイノベーションの舞台になっていた
2. 民間企業が基礎研究にかなり携わっていた
3. バイオテクノロジー産業に関わっている人たちが、とても楽観的だった

・この本の底流をなす大テーマ
「ビジネスとサイエンスの関係」
従来:ビジネスとサイエンスは別の領域
(大学 => サイエンス、営利企業 => ビジネス)
BT産業:2つの世界の混ざり合い

*具体的な調査対象 => 製薬・バイオテクノロジー産業


「序章 サイエンス・ビジネスという新しい実験」
・サイエンスに基礎をおくビジネスとは?
=> サイエンスを生み出し、その成果から利益を得ることを目指す企業 (ないし産業)

・BT産業の業績の真実 (図 序-1)
=> 売り上げは飛躍的に伸びているのに、売り上げは一貫してゼロもしくはマイナス

・BTのビジネス面での課題は、サイエンス面での3つの特質に根ざしている
~~~~~~~~~~~~~~~~~~~~~~~~~ => 本書で一貫して主張される3つの特質
1. BTというサイエンスに重度の不確実性がついて回るため
リスクを管理し、引き受けたリスクに応じて利益を分配するメカニズムが必要
2. ビジネスの基礎となる化学的知識の複雑性・学際性が極めて高く
学問分野や専門分野の垣根を越えた「擦り合わせ」が欠かせないこと
3. サイエンスの進歩のペースが速く、学習の積み重ねが不可欠なこと


本書の構成 (図 序-2 から作成)
+----------------------+ +----------------+ +-------------------+
| サイエンス世界の特徴 | -> | 解決すべき課題 | <-> | 産業の「生体構造」 |
+----------------------+ +----------------+ +-------------------+
|<------------------ 第1部 ------------------->| |<------ 第2部 ------>|
|
V
「第3部 あるべき企業戦略、ビジネスモデル、資金調達」


*議論の対象は、製薬研究開発に限定


「第1部 不確実性、複雑性・学際性、変化の速さ」
「第1章 サイエンス世界の地図」
・それぞれの時代でキーになった技術
- 遺伝子組み換え
- モノクローナル抗体
- コンビナトリアル化学
組み合わせ論に基づいて列挙し設計された一連のケミカルライブラリを
系統的な合成経路で効率的に多品種合成するための実験手法
広義の意味では、in silico でのシミュレーション評価も含む
(コンビナトリアルケミストリー - Wikipedia)
- ゲノミクス
- プロテオミクス
- RNAi
- システム生物学
- 合理的薬品設計
- ハイスループットスクリーニング (HTS)

「第3章 製薬研究開発の特異性と課題」
・CPU開発との比較により明らかになる製薬研究開発の特異性
1. 不確実性 (<= 人間の生物学的システムとプロセスについての知識不足が原因)
CPUの開発 => CPUとしての機能を満たすものは確実に完成する
新薬の開発 => 大多数が失敗に終わる

2. 「すりあわせ型」という性格
デスクトップPC => 高度にモジュール化されている「組み合わせ型 (= モジュラー型)」
新薬研究開発 => プロセスを構成する活動の相互依存的性格がきわめて強い
*サイエンスの進歩により、
「知っている」ということよりも「知らない」ということが浮き彫りになった

*新薬開発のサイエンスの特性
=> 結果が出るまでに時間がかかる
<=> サイエンスの進歩のスピードとの齟齬


・問題解決に必要なメカニズム
1. リスク管理
- 情報を作成・発信するメカニズム
- 資金調達、投資への見返りのメカニズム
2. すり合わせ
- 専門分野の垣根を越えて人材、スキル、能力を統合するメカニズム
3. 学習
- 経験を通じた学習を実践・促進するメカニズム


「第2部 バイオテクノロジー産業の「生体構造」を解剖する」
「第4章 バイオテクノロジー・ビジネスの変遷」
・図4-2 中核技術別に見た新規参入企業の数
1. 新規参入企業の数には、いくつかの波がある
2. テクノロジーの種類が非常に多い
(「バイオテクノロジー」という1つのテクノロジーがあるわけではない)
3. 新規参入の波ごとに、原動力になった技術戦略が異なる

・図4-3 臨床試験の申請数 (1986-2004年)
申請数はほぼ横ばい
=> テクノロジーの進歩は、化合物の「質」を高めはしなかったようだ
* 2002年の時点で、コンビナトリアル化学の手法で
FDAの承認を受けた新薬は1つもない

・ノウハウの市場
新興BT企業と大手製薬企業の提携や協力が重要な役割を果たすようになってきた


「第5章 バイオテクノロジー産業、三〇年目の成績表」
・図5-2 バイオテクノロジー産業の収益と利益の推移
- 収益は増えているが利益は横ばい
- ほとんどの期間を通じて、利益はゼロもしくはマイナス
* 上場企業のみのデータ (未上場企業の大多数は赤字)
=> 産業の実態は、もっとひどいはず
- 総利益の53%は、アムジェンとジェネンテックの2社で稼いでいる
- 大多数のBT企業は、黒字だったことが一度も無い


「第6章 知的財産権の「収益化」のメカニズム」
・BT産業を動かす3つの要素について
1. 新しい企業の設立という形での大学から産業界への技術の移転
2. 資本調達市場 (ベンチャーキャピタルと株式市場)
3. ノウハウの市場: 新興企業が既存企業と提携し、知的財産と引き換えに資金を獲得する市場

・知的財産収益化のメカニズム
大学がサイエンスを生み出し、その中から研究者が新しい企業を設立する
^
| + ベンチャーキャピタリスト
+- 資金 -+ 株式市場
+ 既存企業との提携による資金提供

・リスク管理の達成度
- リスク管理に必要なもの
1. 幅広い選択肢と実験 => OK (多くの新企業、ノウハウの市場)
2. 必要な情報の流通 => NG
3. リスクへの見返り => OK (起業家、ベンチャーキャピタリスト)

・ソフトウェア産業、半導体産業はなぜうまくいっているか? (すり合せの評価)
1. モジュール化 +
2. テクノロジーが形式知 + <=> BT産業と対照的
3. 強力な知的財産保護の仕組み + => すり合せを実現させるのが困難

・組織学習
3つのチャネル
1. 創造的破壊 (新しい技術が既存のものを淘汰する)
=> 実現していない
2. 模倣
3. 経験からの学習
=> BT企業の多くが新企業 => 経験不足


[PR]
by fkmn | 2008-10-06 23:55 | 読書記録
【感想】Rubyist Magazine 出張版 正しい Ruby コードの書き方講座
Rubyist Magazine 出張版 正しいRubyコードの書き方講座―RubyistのRubyistによる、Rubyistとそうでない人のための
Amazon.co.jp: Rubyist Magazine 出張版 正しいRubyコードの書き方講座
サポートサイト

 Rubyist Magazine (るびま) で連載されていた記事の書籍化版。Web で読める分に加えて、書き下ろしの章が一章追加されている。るびまの記事は、一つ一つが結構長くてモニタ上で読むのは結構疲れるので、こういう紙の形で読めるのはうれしい。

 内容の方はというと、結構マニアック。String#slice なんてのは、この本を読んで初めて知った。リフレクションを使った添削も結構多いので、慣れてない人にはちょっと大変かも。

 著者の青木さんの文体が、若干トゲトゲしているのが気になった。添削で指摘されている内容に、個人的には賛成できるものの、何となく反発心のようなものを感じてしまうのは多分文体のせい。特に、前半の1-2章に、文体のトゲを強く感じた。

 全体として、添削という形態は、読み物としては面白いけれど、リファレンスとしての実用性には若干欠ける印象だった。この本で指摘されている内容をまとめ直した、Ruby Best Practices みたいな本が欲しいかも。
[PR]
by fkmn | 2008-08-09 23:55 | 読書記録


とあるWebアプリケーションエンジニアの日記
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
カテゴリ
以前の記事
ブログパーツ
リンク
検索
タグ
最新のトラックバック
プログラミングが「出来る..
from とりあえず9JP?
Genographic ..
from ナンジャモンジャ
ジュセリーノ
from ありの出来事
くちこみブログ集(ライフ..
from くちこみブログ集(ライフ)(..
以降、丁寧語で行こう!
from エッセイ的な何か
人気ジャンル
ファン
記事ランキング
ブログジャンル
画像一覧

fkmnの最近読んだ本 フィードメーター - フッ君の日常 あわせて読みたい AX