いつからかAmazonの紹介料ががくんと伸びなくなったのでみんな慣れて効果が薄れたのかなと思っていましたが、単にアソシエイトIDを間違えて設定しているだけでした。いつから間違えていたのか調べる気も起きませんが、PCをMacに差し替えたあたりが怪しいので1年近く間違えていたことになります。なんともったいない。
WordPressに貼っつけたものがほとんどなのでSearch Regexを使って一括置換で対応出来ました。もっと速くに気づくべきでしたね。まぁ便利なWordPress Pluginを見つけられたのでよしとします。
フジテレビの深夜放送を追いかけ続け、ようやく見終わりました。録画に失敗した回は全部で2回、うち1回は巨人の優勝による放送時間の変更だったのでかなりの確率で録画できたんじゃないかと。もっとも録画の成功は妻によるところが大きいのですが・・・シーズン8はぜひ1週間の集中放映に戻して欲しいのですが、どうなるのでしょうか。
内容的には結局いつも通りなのかなという感想です。舞台がワシントンDCに代わって、所属する組織がFBIに変わってもストーリーの作り方がどことなく既視感を覚えます。シーズン8で終わってしまうのは寂しい気もしますが丁度いいところなんじゃないですかね。
![モンスターズ・インク [DVD]](http://ecx.images-amazon.com/images/I/51kdmy0EEXL._SL160_.jpg)
「今まで見てなかったの？」というぐらい遅れていますがようやく見ました。Pixarの映画の中でもピカイチで面白かったと思います。設定も面白く、ラストも綺麗な終わり方でした。
娘がもうちょっと大きくなったらぜひ一緒に見たいと思います。娘が気に入ったらDVDも買ってあげないとな。文句なしに5ツ星です。
少しずつ難しい話も増えてきたかな? 第３章です。
「第３章 正当性の検証と性能測定」
◯第３章で学ぶ内容
◯Ben-Ariの4つの並行実行一般化
どんなプログラムも最小の実行単位に分けられる。並行処理は”最小の実行単位”が様々な組み合わせで実行される。実装されるアルゴリズム/プログラムはいかなる組み合わせでも正しく実行されなければならない。正しく実行するとは特定の処理が意味もなく除外されないことも含む…ということだと理解しました。
◯クリティカルセクション問題を例にBen-Ariの性質を学ぶ
共有変数を参照/更新するソースコード部分”クリティカルセクション”の実現の方法を通して、Ben-Ariの性質を学ぶ。本では5つの段階を追って解説していますが、ここでは割愛。問題にしたポイントは以下のとおりです。
ということで、スレッドプログラミングでよく陥りそうな問題が満載です。最終的に第５段階として紹介されているのがデッカーのアルゴリズム – Wikipediaです。でもこのアルゴリズムだと2つのスレッドしか排他制御出来ないので、ランポートのパン屋のアルゴリズム – Wikipediaやピーターソンのアルゴリズム – Wikipediaが実用にはいいそうです。でもこの節で学ぶべきは使うアルゴリズムの選択じゃなくて、どういう所に着目して問題を見つけるのかというやり方なので、きちんと学んだことがなければ本を当たった方がいいと思います。
◯デッドロックを発生させる4つの条件
4つの条件はANDで発生する。どれか1つでも成立しなければデッドロックには成り得ない。
デッドロックを避けるにはどれか1つでも起きないようにすればいいらしいけど、複数リソースのロックとか危ういものは出来るだけ避けた方がいいと思う。
◯並行化によってどれぐらい性能が上がったか?
高速化率はどう伝えるべきか? 筆者いわく倍数がいいとのこと。 105%の高速化率と言っても元より5%速くなっただけかもしれないし、205%の高速かもしれない。2倍といったら受けてが迷うこと無いよね とのこと。確かにその通りかも。
逐次処理を並行処理に置き換えた際にどれぐらい高速化出来るかの見積はアムダールの法則 – Wikipediaやグスタフソンの法則 – Wikipediaで出来る。グラフを書いてみると一目瞭然だけど、並行化出来ない処理がたとえ25％でも含まれていると、どんなにコア数を増やしても3倍までしか速くならない。
何でこれまでやってなかったのかと言うと、うちの社内から社外のSubversionリポジトリにアクセス出来なかったからです。アクセス制限がかけれられているわけではなくて、間に挟まったプロキシがSubversionが独自に拡張したHTTP命令を解釈できないようなのです。
ということで、githubでホストされているedavis10's redmine at master – GitHubを見つけて、これをcloneして使うようにしました。masterからインストールサーバ用にカスタマイズして使いましたが、タグやリリースブランチもきちんと切ってくれているのでgitさえわかれば好きに改変して使えますね。tar.gzでダウンロードしたものを使うよりもずっと便利です。
本体をgit管理にすると、プラグインもgit管理で最新版に追従したいところなんですが、ソースの置き場所がgithubにあったり、Google Codeにあったり、RedmineのSubversionにあったり統一感が無い感じです。個人的にはgithubで統一して欲しいのですが、それぞれ事情があるのでしょうね。このあたり、ブラウザから選択してインストール出来るHudsonはよく出来ているなと感心します。
あと今日公開された日本語環境で読みやすいRedmine用テーマ「farend basic」公開 | Redmine.JP Blogも使ってみて気に入ったのでデフォルトのテーマにしました。これまで本家にあったAlternativeを使っていたのですが、メイリオの効果かfarend basicの方が文字周りが綺麗に感じます。Redmineユーザの方は一度試してみることをおすすめします。
翻訳の質が低くて残念
言いたいことは全てAmazonに投稿されている書評で言ってもらった気がします。
翻訳の質が低くて残念です。
すでにgitについてある程度の知識を持っている人でないと、そういったミスリーディングな翻訳文から真の意味をつかむのは難しいと思います。
「入門git」と「入門Git」を制覇して次のステップを目指す人が、翻訳のまずさを自力で補う覚悟のうえで買うのなら、よい本です。
駄目な本かというとそうではなくて、Gitについてこの本より詳しく記述された文章はネットでもないので貴重だと思います。個人的にもgit-svnの使い方が大変勉強になりました。そこだけで3000円ぐらい払っても惜しくないぐらいです。たまに出てくる意味が取りにくい訳がなければ星4つ、O’reilly独特の言い回しが邦訳で取り払われていれば星5つだったと思います。
Gitのオブジェクト管理についてはWEB DB Press Vol.50でも、入門Gitでも紹介されていますが、この本が一番詳しく、説明が丁寧で、わかりやすかったです。Gitをじっくり学びたい人におすすめです。使いたいだけなら入門Gitでいいでしょう。
前に考えていた開発プロセスの変更を色々試行錯誤してみてある程度固まってきました。過去の記事は以下からどうぞ。
ネットワークが切り離された外部チームとのやりとりは結局git bundleにしました。外部チームからはパッチでもらい、レビューした後に適用する。ある程度開発が進んだらgit bundleでリポジトリをコピーして外部チームに送付。外部チームはbundleファイルをそれぞれcloneして開発を行い、適宜git fetch/git pullしながら更新に追従します。タスクの粒度が1タスク1人だったこと、外部チームで別途central repositoryを設けることによるメリットが読めなかったのでこの形を取りました。開発メンバのGitレベルが上がればまたちがった使い方があるのかもしれません。チームの大半が入門Gitを読んだ程度だとこれぐらいから始めるのが混乱が少ないようです。
「masterだけ送ればいいから % git bundle create reponame.bundle master」でOKと思ってbundleファイルを作ったところclone出来ない問題が起きて半日ほどハマることがありました。「% git bundle create reponame.bundle master HEAD」じゃないと駄目みたいです。リポジトリ全部のコピーを送るなら「% git bundle create reponame.bundle –all」でもいけます。
以前はgitリポジトリの変更をSubversionに自動で書き戻すことを考えていましたが、GitとSubversionを共存させる » tune webで書いたようにSubversionに登録されたソースが削除されてしまうことがあり、結局手動にしました。週に1回ぐらい書き戻すことを想定しています。それに合わせてRedmineやHudsonが参照するリポジトリもgitに変更しました。
Hudsonのgitプラグインでポーリングする設定をしてみたのですが、ポーリングのログを書き込むところでたまにエラーが起きて止まってしまうため、gitのフックスクリプト(post-receive)でHudsonのジョブをcurlでキックするようにしました。ジョブはWindowsとLinuxとあるのですが、Windowsが苦戦しました。まずWindowsのジョブを実行するPCにmsysGitを入れて、コマンドプロンプトからgitコマンドが叩けるようにします。次にHudsonのgitプラグインでは認証を入力することが出来ないので、gitリポジトリをhttpで読めるようWebサーバの設定を行いました。gitのhttp公開は単にリポジトリのフォルダにアクセス出来るようすれば良いだけなので簡単です。あとはhooks/post-updateに”git update-server-info”を追加すればOKです(参考：git update-server-info)。
Hudsonのgitプラグインはテスト対象をワイルドカードを含むブランチ名で指定できるので、少し時間をかければpre-test commitも出来そうです。前は良く分からないなんて書いてしまいましたが、少しgitプラグインを使ってみれば感触がつかめるのではないかと思います。近々に必要な機能ではないので、また時間がある時に試してみようと思っています。
Redmineでgitを参照するにはRedmineと同じサーバにbareリポジトリを置く必要があります。別サーバで動かしているなら中央リポジトリからRedmine用のリポジトリに自動でpushする設定をすればいいでしょう。Redmineの昔のバージョンではリポジトリビューワが遅かったらしいのですが、0.9以降で試した限りでは気になるほどではありません。Subversionの頃よりも見やすくなった気さえします。trunkとbranchを切り替えて表示するのがSubversionより楽だと思います。リポジトリビューワがあまりに見やすいのでgit-webのインストールをやめたほどです。ソースレビューにgerritを検討しましたが、LDAP認証の設定をするところでうまく動かず断念してしまいました。最もr-labs – Code Review – Redmineが最近のバージョンアップでどんどん良くなっているので不要かもしれません。Redmineがより使われるようDoxygenで自動生成している内部仕様書もRedmineのRedmine – PluginEmbedded – Redmineですぐ見れるようにしてみました。
gitのフックスクリプトはhooks/post-receiveでメールを流す設定だけ有効にしています。コミットメッセージに Issue ID を含むことを強制させる Git のフックスクリプトを書きました｜SNS構築の手嶋屋を参考にhooks/updateをつくってみたのですが、gitで自動生成されるコメント(マージとか)はRedmineのコミットIDを含まないのが問題になり結局止めています。この辺はまた時間をとってフックスクリプトを見直す必要がありそうです。
時間もかなり費やしましたが、昨年までよりも開発に専念出来る体制がようやくできました。Joel先生も分散バージョン管理で間違いないって、ベイビーと言ってるほどなので分散バージョン管理に移行しましょう!
![トランスフォーマー スペシャル・コレクターズ・エディション [DVD]](http://ecx.images-amazon.com/images/I/51b8%2Bm6RccL._SL160_.jpg)
映像だけが取り柄のB級大作映画。長いくせに前半がグダグダなのでそこで見限らないように注意が必要。
ロボットがかっこいいんだけど何度も変身してると飽きてくるし、敵か見方か一見してわかりにくいのもマイナスだと思う。
吹き替え版で見たんだけど、主役級ロボットのオプティマスプライムの口調がおかしくて仕方がなかった。子供の頃は大好きだったはずなんだけど…
![デトロイト・メタル・シティ スタンダード・エディション [DVD]](http://ecx.images-amazon.com/images/I/61fhXeYBxKL._SL160_.jpg)
GO TO DMC! GO TO DMC!! GO TO DMC!!!
ということで、原作を読んでいた自分ですが、割と忠実に映像化してくれていて楽しむことが出来ました。Amazonのレビューの焼き増しになってしまいますが序盤急ぎ足でエピソードが消化不良なのと、オリジナルのラストがイマイチだった以外は登場キャラが皆ハマリ役だったと思います．
勉強会の2回目があったのでメモ、1回目は下のリンクからどうぞ。
「第2章 並行か非並行か？それが問題だ」
◯大前提
全ての処理を並列化することは出来ない。世の中には並列化が不可能な処理があり、何がそうなのか知っておく必要がある。並行化できないアルゴリズムは以下が代表例。
◯並行アルゴリズムの設計モデル
順序に依存しない処理を並行に実行する「タスク分解」と、大量のデータの個別の部分を並行して処理する「データ分解」がある。
どちらを選んでも基本のフレームワークは変わらない。タスクを準備し、スレッドへ処理を割り当て、次の処理へ進む前に全てのタスクが完了したことを確認する。
◯タスク分解
スレッドに割り当てるタスクを抽出する難易度はソースコードや処理内容に対する理解に反比例する。良く知っていればタスクの抽出も容易になる。タスクを簡単に見つけ出す裏技はないが、処理時間を多く占めるホットスポットにおいて、ループに着目するとそこがタスク抽出に適していることが多い。数値計算もタスク抽出のポイントとしておすすめ。
抽出したタスクの数にもポイントが有る。まずタスクの数はスレッド数(≒コア数)と同じ数以上にする。これはアイドルスレッドを避けるためである。次にタスクの粒度は出来るだけ大きい方が良い。これは並列化によるオーバーヘッドが生じることが影響している。タスクが大きい方がメモリキャッシュが効くなど性能面で有利な点がある。
タスク同士の間には2種類の依存性がある。1つ目は順序の依存で、あるタスクが他のタスクの処理結果に基づいて実行される場合が該当する。2つ目はデータ依存で、変数の使い方で問題が生じることがある。
タスクの割り当ては最初に決めてしまう静的割り当てと、動的にタスクを決める動的割り当てがある。タスクの処理時間が固定の時は静的割り当てが簡単でオーバーヘッドもなくてよい。処理時間にばらつきがある場合は動的にタスクを割り当てる必要がある。
◯データ分解
基本ルールはタスク分解と同じ。分割する数はスレッド数よりも多くする、細かすぎると並列化によるオーバーヘッドが問題になるので大きい粒度で。処理対象となる分割されたデータ領域をチャンクと呼ぶ。チャンク分割はタスクの粒度と境界長の比率が最大になるように分割すると良い。
チャンクの境界において、別チャンクのデータを参照する必要があると工夫がいる。簡単なのは境界部分を予めスレッドごとにコピーしておく方法がある(ゴーストセル)。そうでなければ処理時に必要に応じて参照させる方法があるが、参照対象のデータが未処理の場合、参照処理をまたしておく必要がある。どちらも一長一短がある。
© 2012 tune web · Proudly powered by WordPress & Green Park 2 by Cordobo.
Valid XHTML 1.0 Transitional | Valid CSS 3
