Posts Tagged ‘本’

並行コンピューティング技法 第1章

3月 3rd, 2010

「業務が組み込みメインでもそろそろ並行処理も避けて通れないよね」という雰囲気を年初から職場で醸し出し、勉強会を開くことにこぎつけました。内容は並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミングの輪講です、The Art of Concurrencyの邦訳ですね。

「職場の1人ができてもしょうがなくて、みんなの基礎がある程度揃ってないと話もかみ合わなくなるだろう」という思いが勉強会を選んだ理由の1つ。もう1つの理由は「勉強会ならサボらず最後まで読まざるをえないよね」という自分へのハッパがあります。今は他にも実用Gitを読んでいて、実は昨年の夏からレガシーコード改善ガイド (Object Oriented SELECTION)を積読にしたままです。3冊平行に読むのが良いとは思えませんが、読んだ記録をそれぞれつけて行こうと思います。

前置きが長くなりましたが、まずは第1章「速くしたい人、手を挙げて!」です。

◯並列と並行の違い
・並行:複数の動作を同時に実行状態に保てる機能を備えていること。
・並列:複数の動作を同時に実行できること。
スレッドライブラリを使ってマルチスレッドプログラミングを実装し、シングルコア(Pentiumとか)でプログラムを実行した→並行処理
スレッドを使ったプログラムをCore i7で実行した→並列処理
ということですね。並列処理は並行処理に完全に包含される関係があります。

◯効率的な並行アルゴリズム
コア数に応じて処理時間が短くなる(2コアで1/2、4コアで1/4) が理想だけど、処理の一部は逐次処理が不可避な場合がほとんどで理想的な性能を得られることは殆どない。
特定のコア数を念頭においたアルゴリズムではなく、今後新しく発売されるCPU(16コアとか、32コアとか…)に応じて望ましい性能がそのまま発揮出来るように実装するのが目標。

◯スレッド化のステップ
通常の開発が1.仕様定義、2.設計、3.実装、4.テスト、5.チューニング、6.保守の流れを取るのに対し、スレッド化のステップは以下をとる。

  1. 分析:どこが並列可能かを見極める。並列化によりオーバーヘッドが生じるので重い処理を選ぶ。
  2. 設計と実装
  3. 正当性の検証:不完全なスレッドの実装により起きる問題の対応
  4. 性能チューニング:同期・競合・メモリキャッシュなどの問題への対応

逐次処理のソースで動く実装を固めるのが第1、いきなり並行処理アルゴリズムを実装すると元々の問題か、平行化に起因する問題か切り分けが必要になる。

◯歴史的な話
古くは複数の機器を組み合わせて処理を平行化する分散メモリプログラミングが主流だった。最近はCPUのマルチコア化が進んでいるので共有メモリプログラミングに移っている(本にはこんな記述無いんだけど理解があってるかな?)。

◯これから学んでいくこと

  • 処理の分割の仕方。処理を並列化するのか、処理対象のデータを並列化するのか。
  • 処理の分担をどう決めるか。最初に決めてしまうのか、ロードバランシングを考慮して動的に決めるのか。
  • ロック、排他制御の定石 など
並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミング
Clay Breshears
オライリージャパン
売り上げランキング: 11030

日本「半導体」敗戦

2月 11th, 2010
日本「半導体」敗戦 (光文社ペーパーバックス)
湯之上 隆
光文社
売り上げランキング: 1455

本屋で見かけたらどうにも気になってしまい購入して読みました。最初にこの本の存在を知ったのは日本半導体・敗戦から復興へ JBpress(日本ビジネスプレス)だったかな? この本の主張は前半部に固まっており、Webで読むことができるし、Amazonの書評を見ても大体わかるようになってます。

本書だと図やグラフ、実際のデータも使って説明されていますがざっくりまとめると

  • 日本の半導体企業は過剰品質でものづくりしてしまう傾向があり、各工程で個別最適化されてしまっている。
  • 全体最適でないため利益率が低く、不況の度に赤字体質が表面化してしまう。
  • 自社の「技術力は高い」と判断する評価軸が間違っている。安くモノを作るのも技術のうち

サラッと読めるので、興味があれば立ち読みしてみることをおすすめします。半導体に限らず他の業種でも同じような現象は少なからず起きているのではないかと。

あとはこの本がお勧めできない理由です。

  • 後半に行くほど無駄が多い。筆者の世界1周珍道中なんてバッサリ削るべき。
  • 筆者が「半導体産業を知らない学者が半導体業界を評論している」と批判しているのに、最後は「自動車」とか「テレビ」とか他産業の現状を叩いている。
  • 光文社バックスの4重表記が読みにくい。「(例)これまでに類を見ない大規模なリストラmassive lay-offsを敢行した。」とか英単語が突然文中に入る形式を読みやすいという人が居るのかな?

ソフトウェアアーキテクトが知るべき97のこと

1月 30th, 2010
ソフトウェアアーキテクトが知るべき97のこと
オライリージャパン
売り上げランキング: 6647

この本の正しい使い方。

  1. ソフトウェアアーキテクチャに興味を持った人が数人集まる。
  2. 適当に1章選んでみんなで読む
  3. 理解できる/理解できない/何が言いたいのか分からない/昔こんなことがあったなど議論を交わす。
  4. 飽きたら辞める。

97個も話があると似たような話があります。もうちょっと整理してくれたら30個ぐらいにできたのに。
息抜きに読むとたまにヒントが得られる本だと思います。もっと砕けた感じが良ければアドレナリンジャンキーがおすすめです。

・・・

以下は自分が良いなと思ったエッセイです。
◯03 最大の問題は、多分技術的なことではない
相手を人として尊重し、憶測で非難しないこと。話しあうこと

◯08 すべてのものは、かならずエラーを起こす
エラーの影響を緩和するために何かを導入する度に、それが新しいエラーを増やしていく。

◯18 一般性よりも単純性、再利用よりもまず最初に使えること
推測による汎用性よりも、経験を通じた単純性の方が役に立つ。
単に汎用的であることを目標として設計された多くのものは、良く考えられていても何の役にも立たない。

◯37 ソフトウェア・アーキテクチャが倫理的な意味を持つことを考えよ
必須フィールドは特に害が無いように見えるかもしれないけど、設計者の都合をユーザに押し付けてしまっている。
設計者が楽をするためにわずかずつであっても他人の生活を不便にすることは倫理的ではない。

◯54 あなたの知識と経験を共有しよう
経験は1つだけど、そこから出来るだけ大きな知恵を引き出すためには経験に合理的な説明を加えなければならない。
簡単に説明出来るようになるまでは、対象を完全に理解しているとは言えない。

◯61 データがすべて
データはコードよりも概念として小さく、複雑度もかなり低い。

◯72 優れたコンテンツは優れたシステムを作る
新しくシステムを設計するときには、開発プロセスの一部を既存コンテンツの評価に当てるべき。

◯82 本当の顧客は目の前の顧客ではない
本当の顧客はあなたの顧客の顧客。
あなたの顧客の顧客が成功すれば、あなたの顧客が成功する。そうすればあなたも成功する。

◯日06 手段的な技術と陳腐化しない本質的な技術
ノウハウ的な知識ばかりが増えても背景にある理論を理解しないと作れないソフトが有る。
作業の90%はノウハウの積み重ねでソフトウェアの魅力が高められる。しかし残り10%で本質的な知識が要求される。そしてそこでソフトウェアの革新性が決定される。

0さい~4さいこどもずかん

1月 26th, 2010
0さい~4さいこどもずかん 英語つき
デイブ テルキ
学習研究社
売り上げランキング: 3200

本が好きな娘のために購入しました。

たまたま時間つぶしに入った本屋で見つけた本ですが、いろいろな絵が可愛く書いてあり、大人が子供と一緒に眺めるのも楽しいと思います。装丁も頑丈で、ページも耳がついているため、子どもでもめくりやすくなっています。片仮名での英語の発音表記はなくても良い気がしますが、この辺は人それぞれなんでしょうか。

全4巻らしいので、飽きたタイミングを見計らって少しずつ買い増そうかと思っています。

今日Amazonで注文した本 3冊

12月 29th, 2009

読む量より買う量の方が上回っている気がしますが・・・

アート・オブ・プロジェクトマネジメント —マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE) (単行本(ソフトカバー))
4873112990
アートオブアジャイルデベロップメントを買おうと思って本屋に行ったら見つけた本。パラパラと中身をみて今の自分に必要そうだと思ったのですが、Amazonの書評をみて決めようと思ってその場では買わなかったものです。自分が知らなかっただけで結構評判の良い本のようなので買うことにしました。
アートオブアジャイルデベロップメントの方はまたの機会に。

発想する会社! — 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法 (単行本)
415208426X
前から欲しかったんだけど買う機会がなくてずるずるウィッシュリストの上位にあった本です。技術書だけだと飽きるので、合間に読もうかなと。メイキングオブピクサーと悩んだのですがこれもネット上の評判を信じてこっちにしてみました。というかネット上の評判に左右される買い物が多いですね、自分。

Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala) (単行本)
4844327453
今年はふつうのHaskellプログラミングを読んで、Haskellに触れてみましたが、来年も何か新しい言語を勉強して見識を広めようかとScala本も購入。高いのがネクですね。
Haskellの知識も怪しいところが盛り沢山なのでまた来年再入門しようかしら。

V字回復の経営—2年で会社を変えられますか

12月 20th, 2009

V字回復の経営—2年で会社を変えられますか (日経ビジネス人文庫) (文庫)
4532193427

TABLOG:ダメ会社の不振事業によく見られる50の症状 @V字回復の経営【書評】 – livedoor Blog(ブログ)でおすすめされていたのを見て知り、先日ようやく読み終わりました。毎年赤字を垂れ流し続ける事業部を2年で立て直すためのやり方と、実際に起こるであろう事象が小説風に書かれています。少し前に流行ったザ・ゴールみたいな本 といえばわかる方もいるかも知れません。Amazonの書評も概ね高評価で、読み終わってみて確かに楽しめる本でした。そして組織の上部にいるほど有用な本だと思います。

この本に書かれている改革の流れを一般職の社員ができるかといえば無理でしょう。強力なスポンサー/後ろ盾もいるし、手の届く範囲も限られています。自分から下、手の届く範囲をこの本の手法で変えていけるか であれば可能かもしれません。この本で2年の時間軸で語られている内容は新しい仕事のやり方を導入する際にも変わらないと筆者も明記しており、自分もそのとおりかもしれないと思っています。会社の中でも誰か限られて人が読むよりも、上から下までまんべんなくこの本を手にとり、上はどう考えて施策をうったのか、下はそれをどう受け取るべきかを考えて行動できればV字回復がいらないぐらいの業績が達成できるのかもしれません。

3箇所ほど気になった箇所がありましたが、あとは満足です。

  • 気になった箇所1: 「コンサルタントは日夜血のにじむような思いで仕事に取り組んでいて、本書の登場人物たちの仕事ぶりなんか素人の真似事」なんてことを筆者が言ってること。真実かも知れないけどそんなこと本に書かなくてもいいのに。
  • 気になった箇所2: 業務管理アプリケーションを「パソコンオタクの社員を探してきて仕事を命じれば簡単に作ってしまう」なんて言ってること。Excel帳票を作る程度の話なのかもしれないけどナメすぎ。
  • 気になった箇所3: 業績がうまく回っていれば残業も休日出勤も厭わず社員が働くようになり、それが望ましい状態であるかのようにそこかしこで書いてあること。会社が消滅するのは問題だけど、社畜化してしまったらまた違う問題が生じるだけ。

アドレナリンジャンキー

12月 17th, 2009

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン (単行本)
4822284018

トム・デマルコのファンというわけではないのですが、Jolt Awards受賞の文句につられて購入しました。中身は面白いものの、受け取り方は様々かもしれません。これを教訓として組織やチームのあり方に思いを巡らせる人もいれば、「こういう話よくあるよね」って笑い話にしたい人もいるかも知れません。自分はどちらかというと後者かも。
いい話と悪い話があるんですが、タイトルだけ見て見分けがつかないのが問題かも。

自分は以下の話が面白かったです。気になった方は手にとって読んでみてください。

15. 「どうしてミケランジェロになれないんだ?」
マネージャーは、チームの能力が向上することをひそかに期待しながらツールを調達する。

19.映画評論家
映像評論家とは、プロジェクトにとって自分の価値は過去や今後の間違いを指摘してやることだと思っていて、間違いを正すためには何もしないメンバーや傍観者のことである。

21.ソビエト式
完成した製品は、顧客が要求した機能は備えているが、嫌われてすぐに捨てられる。

30.ちびた鉛筆
コストの削減の波が続くと、組織にはプロジェクトを完了する能力もなくなってくる。

34.エセ品質ゲート
プロジェクトの品質保証担当は、本当の品質向上には役に立たない形式チェックにとらわれている。

67.十字穴付きネジ
あきらかに優れたアイデアは、意外なことに、すぐには受け入れられない。

入門Git

11月 10th, 2009

入門Git (単行本)
4798023809

少し流行からは遅れましたが、ようやく読み終わりました。既に各所で絶賛されていますが、自分もなかなかの名著だと思います。Gitの表面的な使い方だけでなく、その設計指針や、背後にある思想などGitのエッセンスを余すこと無く、”日本語で”学ぶことができるのがすばらしいと思います。

Chapter8まではWEB DB Pressの特集の焼き直しで、残りが本書で書き下ろされた内容かと思います。自分はWEB DB Pressの特集を事前に読んでいたので前半は復習がてら読めましたが、分散バージョン管理の本を初めて読む人には1度で理解するのが難しいかもしれません。でもゆっくり読めば分かるのではないかと思います、たとえ話も上手ですし。

Chapter10以降は急に趣が変わって、辞書的な内容が強い気がします。Gitを日頃から使ってないと使い方のイメージがわかず、所々引っかかってしまうのではないかと思いました。自分もその口です。Amazonの批評にある難しいという印象はこの章以降が影響しているのではないかと個人的には思っています。

自分が仕事でGitを本格的に使い始めてまだ半年も経っていませんが、最近Subversionの時代遅れ感を強く感じます。作業途中のファイルを気軽にコミットしたり、コミットの歴史を書き換えたり、機能追加のためのブランチ(本書ではトピックブランチと言ってます)を気軽に作ってマージしたり、どれもSubversionでは日常的に運用できないことばかりです。

自分がバージョン管理を使い始めたのはCVSからSubversionの変わり目、Subversionの1.0が登場する半年ぐらい前だったのですが、バージョン管理システムはこれで完成系だろうとCVSとSubversionを学んで思っていました。大間違いでした。Subversionで満足してしまっている人こそ本書を読むべきだと思います、強く強くお勧めします。Subversionはまだ主流かもしれませんが来年、再来年は分かりません。今Gitの存在を知ったときに勉強を始めるべきです。

とりあえず周りのチームに広めるところから自分は始めます。WindowsもTortoiseGitがあって、普通に使えてますよ。

パターン、Wiki、XP ~時を超えた創造の原則

9月 27th, 2009

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ) (単行本(ソフトカバー))
4774138975

旬を過ぎてしまいましたが、遅まきながら読み終わりました。デザインパターン、XP、Wikiに通じるより良い成果物を作り込むための思想の歴史が詳しく紹介されています。どれも断片的には学んだことがある物ばかりですが、ここまで整理された歴史を分かりやすく読める本は他に類書がないのではないかと思います。

この本を読んだからといって、すぐに明日からの仕事が改善できるということはありませんが、素養として時間のあるときに読んでみるとソフトウェア開発に従事している人以外も楽しめるんじゃないかと思いました。

クリーンコード一人読書(3) 第5章〜第7章

6月 18th, 2009

例によって括弧書きはコメント

○第5章 書式化
チームで仕事をしているなら1つの書式ルールで合意をとり、すべてのメンバーはそれに従うべき。
(当たり前のことだけどできてないことが多いコードが多い。ルールを文書化しておくと規約に沿ってないコードを書いたときも指摘しやすい。静的解析ツールのルール定義をしておくのもありかなと思う。)

コードの書式化は宗教戦争の引き金ではなく、長期にわたって保守容易性と拡張性を提供してくれるもの。

大きなファイルよりも小さなファイルの方が理解しやすい、当たり前のこと。
ソースファイル中の記述は抽象レベルが高いものが上、実装詳細が下にあることが望ましい。新聞と同じ構造。

縦方向で書式化に関連するのは空行の入れ方。パッケージ宣言、インポート文、各関数など別の概念のものは空行を挟むと良い。
逆に一続きの処理の間に空行がはいると読みにくくなる。関連するコードは空行を挟まず、物理的に近い位置に記述できることが望ましい。
変数宣言は使用位置に近いところで、ループ変数はループの中で宣言する。

横方向の書式化はインデントや空白、1行の文字数がある。
文字数はモニタに入りきるぐらいで、120文字ぐらいがいいのではないか。
空白をうまく挟むことで処理を強調できる。代入の左右に置くと変数名が読みやすくなるし、計算式の途中に入れると演算子の優先順位が読みやすくなる。
タブを使った変数の位置合わせは意味が無い。位置あわせしないと読みづらいような宣言はそもそも何かおかしい(関数/クラスが大きすぎる とか)。

○第6章 オブジェクトとデータ構造
すべてのメンバにゲッタとセッタを用意するのはアホのすること、最悪。
目指すべきは「抽象インターフェースを公開することで、データの実装を知らせること無しに利用者に対してデータの本質を操作することを可能とする。」

データ/オブジェクトには非対称性があり、状況に応じて使い分けることが大事。

データ構造(structとか)を使用するコードは新たな関数を既存のデータ構造に影響を与えずに追加することが可能。オブジェクト指向の場合、既存の関数を帰ること無く新たなクラスを追加することが可能。

言い換えると

データ構造を使用するコードは、新たなデータ構造を追加する場合、既存関数全てに手を入れる必要がある。オブジェクト指向の場合、新たな関数を追加する場合、既存クラス全てに手を入れる必要がある(interfaceを使った場合ね)。

○第7章 エラー処理
エラー処理は重要だが、エラー処理のせいでロジックが不明瞭になっているとしたらそれは間違っている。

例外が使えるなら戻り値によるエラー情報でなく、例外を積極的に活用する。
3rd partyのライブラリなど多数の例外に対応する必要がある場合はラッパを作って、不要な例外処理をロジック側に書かなくてもよくする工夫も有効。

nullは返さない、nullを渡さない。
nullを返す実装を作ると呼び出し側でチェックが必要になり、記述が複雑になる。空のリストを返すとか工夫をすることで、nullを返すのと同じ効果を得ることが可能なはず。
nullを渡すコードを原則禁止にしてしまえば、nullが渡って来た場合、誤りであるとすぐに気づくことができる。

Clean Code アジャイルソフトウェア達人の技 (大型本)
4048676881