つまらなくはないけど普通かも。
大ヒットした原作の割にはイマイチに感じたからおそらく原作の面白さを伝えきれてないんだろうなと予想します。

あまり話題にもならなかった気がするし、そこそこな映画かなと思っていたのですがかなり楽しめました。実際のANAの現場があんなにドタバタしているのかは分かりませんが、色々な人が協力しあって飛行機をスケジュール通りに飛ばすのは大変なんだなと裏側を見せられて感じました。

見ていると飛行機に乗って旅に行きたくなる気分になります。おすすめです。

• Developers Summit 2010 Preso – Atlassianウェブサイト – アトラシアン ウィキ
• Developers Summit 2010 参加メモ » tune web

中でも98日間隔(14週間、約3ヶ月ですね)でリリースを繰り返すイテレーションの仕組みはもっと注目を集めても良いと思います。自分で眺めて考えてみた結果を以下にまとめてみます。

◯図のイテレーションはどうして9週目始まり?
開発の最後のイテレーション(Iteration5)と次期バージョンの仕様を決める時期が重なっているからですね。開発者は12週目から14週目の作業が少なくなっていますが、ここで自由裁量な開発期間(Googleの20%ルールみたいの)を割り当ててる人が多いと講演で言ってた気がします。

◯PMMの仕事
PMがProject ManagerならPMMは誰なんでしょう? パッと見でPMより偉い人みたいですが。PMM:Product Marketing Managerとのことです。気になったのはPMMが実施するレビューの順番です。

• 1週目：マーケットと競合他社のレビュー
• 2週目：Messagingレビュー(製品の打ち出し方 とかなのかな?)
• 3週目：製品ローンチのゴールをレビュー

競合分析と最終ゴールの確認は大事ですよね。

◯PM:Product Managerの仕事
この辺は一般的? リリース基準を事前に策定するのは大事だよね。

• 1週目：時期製品ターゲット層の検討
• 2週目：6ヶ月先までのロードマップを更新(これより長期の計画は無いのかな? それとも別途作成?)
• 3週目：リリース基準の策定
• 4週目：詳細なストーリー作成(製品が使われるユースケースのことでいいのかな?)

◯デザイナの仕事
PMM/PMが製品コンセプトを固めている段階からデザイナの仕事が振ってあります。初期段階はPMと一緒に動き、開発が始まったらプログラマと協業するんですかね。

◯イテレーション
全5回、うち実質的に開発に振り分けられるのは最初の3週間。4週目は”Polishing”とある、機能追加を止めてパフォーマンスや使い勝手を作り上げていくフェーズなのかな? 5週目はリリースにあたっての準備期間の模様。
あと各イテレーションでコード書きはもちろん、バックログの整理や自動化されたテストも準備しているみたい。
社内でドッグフードを食べ始めるのはBETA1からかな?ドッグフードはイテレーションの1回目から食べ始めるそうです。デブサミの講演では「体感として1日1回は落ちる(Confluenceだったかな?)」と話されていましたが、開発直後の状態ならそれぐらい落ちても不思議ではないですね。

◯各フェーズでの確認事項
下部に書いてるのは各フェーズでの確認事項だと考えました。「顧客が求めているか、お金を払ってくれるか」「長期計画に沿っているか」「リリース出来るほど安定しているか」などなど。当たり前だけど大事なことですよね。

ということで、画像から読み取れることを自分なりに書いてみました。これぐらい短くリリース出来ると開発に緊張感が出て良いですね。どれぐらい短い間隔でリリース出来るのかという課題は突き詰めて考えてみると今のムダも見えて結構良いかもしれません。

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

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

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

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

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

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

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

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

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

• 処理の分割の仕方。処理を並列化するのか、処理対象のデータを並列化するのか。
• 処理の分担をどう決めるか。最初に決めてしまうのか、ロードバランシングを考慮して動的に決めるのか。
• ロック、排他制御の定石　など

並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミング

posted with amazlet at 10.03.03

Clay Breshears
オライリージャパン
売り上げランキング: 11030

Amazon.co.jp で詳細を見る

実用Gitの16章に定石が載っていると聞き、さっそく買って読んでみました。他の章を飛ばして16章だけ読んだせいもあるのか自分の中ではまだうまく消化出来ていません。とりあえず手順だけ書いておきます。

◯前提条件
git svnを行う窓口は1箇所にする。git svnのオプションを変えたり、とってくるリビジョンを変えただけでもコミットオブジェクトは変わってしまう。

◯前準備
git svnを使ってSubversionリポジトリのcloneを作る

% mkdir example-svn.git
% git svn clone –stdlayout –prefix=svn/ http://example.jp/svn-repos/

git bareリポジトリを作る

% mkdir example.git
% cd example.git
% git init –bare –shared=true

git svnリポジトリからmasterとSubversionのブランチをgitのセントラルリポジトリにpushする。

% cd ../example-svn.git
% git push –all ../example.git
% git push ../example.git ‘refs/remotes/svn/*:refs/heads/svn/*’

◯Subversionにマージを書き戻す

% git checkout svn/trunk
% git merge –no-ff new-feature
% git svn dcommit

何度も実用Gitの解説を読んでいるのですが、マージを書き戻すところだけどうにも謎です。多分きちんとリモート追跡を理解できてないのでしょう。この休みにまた時間をとって勉強することにします。

実際にやってみて出来ることは確認したのですが、

1. Subversionへの書き戻しを手動でやらないといけない
2. Subversionのログに残るメッセージがgit mergeで生成されたものになってしまい、何の変更をしたのかSubversionからはさっぱりわからない

という問題があることも分かりました。

そこで上記でいうexample-svn.gitのフックスクリプトを作成し、example-svn.gitのmasterに変更がpushされたらSubversionに書き戻す処理を自動化してみました。動く気はしているのですが、理解が足りてないせいで、思わぬ問題を引き起こすかもしれませんのでご注意ください。

#!/bin/sh

# checkout svn/trunk
git checkout svn/trunk

# Store git log before merge
log=$(git log last-merged..master --pretty=format:"%h %s" --reverse)

# merge master to svn/trunk, don't commit
git merge --no-ff --no-commit master

# commit with git log message
git commit -a -m "$log"

# push back to svn repository
git svn dcommit

# tag last merged
git tag -d last-merged
git tag last-merged master

◯2010年3月3日追記
テスト環境ではうまく行ったのですが、本番環境でgit->Subversionの自動同期をしてみたところ、ソースファイルが削除される問題が起きてしまいました。
git push, git mergeとかのどこかでうまくいってないのにsvn dcommitまで行われたのが直接の原因ですが、なぜこうなったのかログを見ても原因が分からなかったので自動同期は止めました。

◯2010年3月4日追記
よくよく考えたらsvnのゲートウェイとなるリポジトリのmasterとsvn/trunkは別個の歴史を辿るんですね。なので前にマージされてからの差分を求めるにはsvn/trunk..masterでは駄目ですね。上のスクリプトはなんとなく書き換えてみましたが、gitの理解が足りてないですね。

Subversion, Git, Redmine, Hudson – 今考えている連携 » tune webでいただいたコメント、実際にやってみて出来なかったことを反映してアップデートしてみました。

前回からの差分がいくつかあります。

• git svnの窓口となるリポジトリとgit開発時のcentralとなるリポジトリを分けた。
• 内部設計書としてソースからDoxygenで生成したものを使っていたことを思い出したので追記
• 外部との作業項目のやりとりにRedmineからチケット一覧をExcelをエクスポートして使っているのを追記
• お互いにパッチを送り合うのをやめて、パッチをもらったらgit-bundle(1)で作成したファイルを送るようにした。これなら物理的に離れていても同じリポジトリを使って作業出来る。

gitとSubversionの橋渡しにかなり悩んだのですが、実用Gitによると、窓口を1つにして、いくらか気をつけなければならない点があるそうです。これはまた別のエントリで。

上記構成が出来そうな目処はついてきたんですが、余力があればgerrit、Overview — Sphinx v0.6.4 documentation、TestLinkをうまく組み合わせたいですね。

◯2010年3月3日追記
離れた箇所にリポジトリをコピーするのにはgit bundleは便利だけど、差分を渡し続けるのは無理がある気がしてきた。
masterを両者で同期を取るとなると、git bundleで貰う側はローカルのmasterにpushしちゃうとbundleからpullするのが面倒になる。ローカルでmasterにコミットするなというのは結構な制限を課している気がする。branchを切って、branchを同期するようにすると、branchからcherry-pickするような運用になるのだろうか? じっくり同期を取れる気がするけど、そこまでして同期をとらなきゃいけないものでは無い気がする。

そこまでしてリポジトリの同期を取るよりも、素直にパッチを送り合う方がいい気がしてきた。リポジトリ構成さえあっていれば最初のbundle送付すらいらないかも。
前にコメントをくれたmootohさんも、よくよく読んでみると「bundleを最初に送付して、あとはパッチを”送り合ってる”」てなってるし。

何か思い違いをしているかもしれません。おかしな点に気づかれた方は遠慮なくツッコミください。

最初はハンズオンか〜なんて思ってましたが、やっぱり手を動かさないと分からないことって多いですね。Pythonを使えない私が感じたのはこんな感想です。

• 会場はPythonユーザー多し、Pythonプログラマって周りのツールもPythonで固める傾向ありますよね(偏見?)
• SphinxはreST(reStructured Text)というフォーマットで書くのですが、書き方が良く分からず。
• スペースが要るとか、改行がいるとか、スタイル関連の注意事項が結構あって「適当にかけば適当に変換される」ものではない
• HTML以外(具体的にはPDF)の出力口もあるけどつまづきポイントもあるよ。
• Pythonユーザが使うには敷居が低いかも。そうでないなら習熟に時間もかかる。
• TeXよりはマシ、RDよりは表現力がある。でも、もうちょっと何とかならないかというのが正直な感想。

翻訳とか、Web上に置くドキュメントを置くには良いかもしれません。仕事で使う〇〇書をSphinxで書くのはちょっと時期尚早かもという印象を受けました。

第2部としてRailsとDjangoのWebフレームワーク談義もあったんですが、Webプログラマーじゃない自分には門外漢な話なので割愛します。

次回はHudsonだそうです。仕事で使っているけど新たに学べることがあるかなと思って迷います。

1番のポイントはバージョン管理システムとしてGitを中心に据えました。社内はSubversionで統一するという規則があるので残すとして、開発チーム内ではgit svnを使ってGit化し、Subversionを直接触らないようにします。協力会社はSubversion縛りが無いのでGitで統一してもらいます。これまでは差分ファイルを送り合っていましたが、Gitを使えばパッチをうまく作り、修正単位でパッチファイルをやり取りすることが出来るでしょう。これまでは複数の修正がまとめて送られてきてましたが、パッチ単位ならレビューもやりやすく、「こうした方がいい」とか「こうして欲しい」というやりとりもやりやすくなります。

リポジトリがプロジェクト専用になるので、フックスクリプトも仕掛けやすくなります。現状は「空メッセージのコミットは禁止」程度の緩めのものですが、コミットメッセージに Issue ID を含むことを強制させる Git のフックスクリプトを書きました｜SNS構築の手嶋屋を参考にすればRedmineのチケットが無いコミットは禁止できます。これで闇コミットがなくなるはず。

さらにGitを使えば「歴史を書き換えて」テストが通らないコミットをなかった事にも出来るはずです。コミット前にテストをする機能がTeamCityにはありますが、Hudsonにはありません。[#HUDSON-1682] Pre-tested commit feature – Hudson JIRAとして要望が挙げられていますが実現はまだ先になるでしょう。HudsonのGit Pluginのページにpushされた変更をテストして、成功したらmaster/stableにマージする設定手順がありましたが、リリースブランチを持ったときにも同じように出来るかは不明です。

というのをtwitterにつぶやいていたところ、@bleisさんと@masanobuimaiさんから情報をもらえました。Gitのフックスクリプトですが

1. pre-receiveでpush前の状態をタグ付けする設定を追加
2. post-receiveでHudsonの複数ジョブをキックして起動。
   1. テスト結果を取得して全て成功したらタグを消してgit svn dcommitを実行
   2. 1つでも失敗していたらpre-receiveでタグ付けしたバージョンに戻してpushをなかった事にする。

とすることでいけそうです。Hudsonのジョブ実行結果を知る方法は複数あると@masanobuimaiさんに教えてもらったのがPlugins – hudson – Hudson Wikiのページです。プラグイン無しでもリモートAPIを使っても出来るのかもしれません。
自前でフックスクリプトを用意する必要がありますが、出来ないことはなさそうです。
post-receiveでのテストに多少の時間がかかることを踏まえ、Redmineで参照するリポジトリはGitではなくSubversionにするのが良さそうです。

あとはRedmineのメール経由のチケット登録機能を有効にして、HudsonのナイトリーテストでこけたらカスタマイズしたメールをRedmine指定のアドレスに送ればOKですね。上の絵には「静的解析とメトリクス集計」が入ってますが、これは内製ツールです。リポジトリを集中管理してもらえるとこういうこともやってもらいやすくなりますね。

上記構成に3月中に取り組む予定です。うまく行くといいんだけど。

開発しているものは画像処理ライブラリで、言語はC言語。プラットフォームはWindowsとLinux両方に対応していて、32bitと64bitどちらでも動くようにしたいのが前提。ほとんどのソースは共用出来るようにしています。開発者はWindowsを使ってVisualStudioで開発し、自動テストやリリース時はLinuxでMakefileを使ってビルドします。

バージョン管理は課で管理しているSubversionを使い、他のプロジェクトともリポジトリを共用しています。他に使っているツールはテスト自動化にHudsonとタスク管理と障害管理でRedmineがあります。Hudsonは2種類のテストを管理していて、コミットの度に動くビルドのテストとCUnitを使った単体テストと、毎晩複数枚の画像入力を処理するストレステストの実行を制御しています。Redmineはチケット駆動開発(TiDD)を意識し、コミットはチケットに関連付けるようにしています。あとは開発者の1人(自分です)がgit svnを使ってローカル開発をgitにしているぐらいです。

開発メンバは社内に2人、あとは社外の協力会社に手伝ってもらっています。両者の間にはネットワーク的に「超えられない壁」があり、リポジトリを参照させることができません。ということで双方でSubversionリポジトリを持ち、同期は定期的(1〜2週間おき)に差分ソースを送り合って手動で実行しています。

ここまでが現状の紹介、以下は上記フローによる問題点です。
問題１　双方でのソースの同期を取るのが大変
一週間から二週間に一度差分ファイルを送り合ってるけど、マージに時間がかかる上、複数の変更がごっちゃになっておくられてくるためレビューしたくても途中で断念してしまう。

問題2　単体テストが通らないコミットが履歴に残り消せない
ちょっとしたミスがあってビルドに失敗してもsvnの履歴が消せない。Windows上での単体テストはコミット前に確認するけどLinuxで毎回やるのが面倒になったり、32bitと64bitを全組み合わせでやるのは面倒だったりする。動くだろうと思ってコミットすると壊れていたりとか。
あとはgccでは警告をエラー扱いしているので、使われてない変数があるとかその程度のことでエラー扱いされてしまう。

問題3 闇コミット
RedmineでTiDDに近いことをしているが、闇コミットが結構ある。スタイル直しただけとか、変数名リファクタリングしたとか。複数プロジェクトでリポジトリを共用してるからチケットIDが無いコミットを弾くのが難しい

問題4 Redmine上でチケットとコミットの関連付けを直せない
テストで問題が見つかってもRedmineのチケットとコミットの関係を直すことが出来ない。間違ってるfixesが残ってしまい、何とも出来ない

問題5 HudsonでビルドにコケてもRedmineのチケットに自動登録されない
Hudsonでコミットごとの単体テストとは別にストレステストを含むナイトリーテストを設定しているが、テストに失敗した時にRedmineのチケットが自動登録されない

問題6 TortoiseSVNのパッチ機能が腐ってる
外注からパッチで差分を送ってもらうことも考えたが、TortoiseSVNの文字コード認識がおかしく、一度エディタで開いて文字コードを保存し直す必要があった。（ちなみにソースはUTF-8）

問題7 機能ブランチの管理が大変。
一度切るとなかなか戻ってこない。戻すにも準備がかなり必要になる。試しに作ったけどいらなかったブランチも扱いに困る。

問題だけ見ると「何でこんなフローにしたんだ」と自分でも思ってしまうけど、少しずつプラクティスを取り入れた結果うまく連携できてない現状になってしまった。近々Subversionのリポジトリを課管理から本部管理に移行するお仕事があるのでこれを機にこれまでの問題点を解消しようと思っています。

詳細は後半で → Subversion, Git, Redmine, Hudson – 今考えている連携 » tune web

【18-B-3】Google 的分散コンピューティング
Gregor Horpe氏によるGoogleの分散コンピューティング技術の紹介と、その背景にある思想の話。

○Google内で使われている分散コンピューティング技術
GFS, Bigtable, MapReduce, Sawzallの紹介、Googleを支える技術 ~巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)が詳しいです。
Sawzallの発音が”ざうざーる”と言っているようでした、これまで”さうざーる”だと思い込んでた。

○Googleの分散システムの背景にある思想
8つに分けて、事例を交えて紹介してくれました。

1. Shading
2. Less is More
3. Expect Failure
4. Autonomy
5. Enpower the Runtime
6. Favor Stateless
7. Separate Stateless from Stateful
8. Precision vs Speed

1. Shading
分割して統治する。役割を分ける、機能を分ける、抽象化する。
例として挙げていたのはユーザアカウント管理に中小レイヤをかぶせるやつだった・・・かな? メモがなくスライドもまだ見れないのでうろ覚えです。

2. Less is More
機能を絞って特徴を引き出す。
Bigtableはトランザクションを始めとしたRDBMSの機能が無いが、その分スケールするように作ることができた。

3. Expect Failure
「エラーが起きるかどうか」ではなく「エラーはいつ起きるか」を考える。ifではなくwhen。
GFSもMapReduceもベースにエラー処理がきちんと組み込まれている。
GFSなら自動でマスタが切り替わる仕組みとか、MapReduceなら失敗したタスクの再スケジューリングとか処理対象からの除外とか。

4. Autonomy
とにかく自動化、人では介さない。
例として挙げられていたのはGFSのMaster/Slave構成。
Masterに障害が発生するとSlave同士が投票しあって次のMasterを決めるようになっている。

5. Enpower the Runtime
言いたかった事がうまく受け取れなかった。「役割を明確に決めないで柔軟にやってね」ってことだと理解しました。

6. Favor Statelessと7. Separate from Stateless from Stateful
状態を持たない。なぜなら状態を持つと途端にスケールしなくなるから。
状態を持つにしても、スケールする部分をきちんと切り分けておくことが大事。

8. Precision vs Speed
ソフトウェアではfaster is better。正確性を期するよりも、高速で大体の精度の予測で動く。
Googleのクラウドで正確な負荷とか測れても意味がない。大体の傾向がつかめればOK。

【18-C-4】ドッグフーディングとアジャイル開発
アトラシアン社の営業さんによる会社の紹介と、社内で行っているアジャイル開発の紹介。
アトラシアンはエンタープライズWiki(Confluence)や障害管理システム(JIRA)を主力商品としており、国内外で多くのユーザを抱えている。日本国内では今回が初めての公演ということで会場は超満員でした。

アトラシアン社は2002年にオーストラリアで設立された。3つの方針を掲げ、OSSの世界をはじめ多くのユーザを抱えている。

• いい製品を手ごろな価格で
• 伝統的な営業マンを持たない(電話をかけまくったり、会社訪問しまくる営業マン無し)
• エコシステムの構築に尽力(製品にプラグイン構成を持たせるなど)

アトラシアンの製品はショートリリースを基本としている。それはユーザからのフィードバックを得やすいからであって、サブスクリプションユーザに価値を提供するためでもある。またチームメンバの緊張感を適度に保ち、バグ修正に時間を割いて使うようにもなるメリットが有る。リリース期間が短いことから必然的にアジャイル開発の形態をとっており、社内で開発版を試す「ドッグフーディング」の文化も根付いている。会社設立時メンバが2人しか居らず、早急に事業を立ち上げるためアジャイル開発をとらざるを得なかったことも今の会社に影響しているかも知れないとのこと。

ドッグフード中のシステムは不安定で、Wikiなどはマイルストーンリリース時は1日1回ぐらい落ちるらしい。社員は不便を感じるが、それが客先で障害として発生するよりかはましという考え方をしている。バグ以外にフィードバックも社員から得られることもある。バグ情報やリクエストは社外に公開した障害管理システムで受け付けているとのこと。

最近ショートリリースのタイミングをさらに狭めたらしく、98日でイテレーションを回しているとのこと。98日のスケジュール詳細はDevelopers Summit 2010 Preso – Sean Osawa – アトラシアン ウィキから詳しく見ることができます。Googleの20%ルールに近い制度がアトラシアンにもあるらしく、開発者はイテレーション中の時間がある期間(Week 12 〜 Week 14あたりだったかな?)に直接の業務と関係が無いことも取り組んでいるらしい。

社内ではレビューを多用している。レビューには早期修正できるコスト削減効果や、開発者の教育効果がある。駄目なレビューでは単なるプレゼンになっていたり、熟練による支配が起きてしまう。

アトラシアン社員のレビューTIPSとして以下が挙げられてました。

1. レビュー前にコードに関する課題、タスクに目を通す
2. 変更構成を読む
3. 機能が動いているかを確認する(確かに年に何回か動かない機能のコミットがある)
4. 自分が変更するならどういう方針を取るかを考えてみる
5. レビュー終了後に提案リストを優先順位をつけてまとめて送る

レビューのタイミングとしては頻繁に行うこと。朝でも昼でも、帰る前でも、まとめて行い、開発に割く時間をうまく確保するのもコツ。
見てもらうのは同僚が一番、同僚がだめならTech Lead(技術面の開発リーダかな?)がいいとのこと。ごもっとも。

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

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

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

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

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

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

再現コードはこれでOK、C++編（標準ライブラリ）　第７章　priority_queueを参考にさせて頂きました。

#include
#include
using namespace std;

int main()
{
    priority_queue qu;

    // 要素を追加
    for(int i=0; i<100000; i++){
        qu.push( i );
    }

    // 先頭要素を取り出して出力
    cout << qu.top() << endl;

    return 0;
}

VisualStudio2005で試したところDebugモードだと動いてはいるのですが、とにかく時間がかかります。途中で処理を止めたところpushに時間がかかっているようです。そこでpushの先を追って行くと下記のようなコードが見つかります。

_Vector_iterator()
       {       // construct with null vector pointer
       }

#if _HAS_ITERATOR_DEBUGGING
_Vector_iterator(pointer _Ptr, const _Container_base *_Pvector)
       : _Mybase(_Ptr, _Pvector)
       {       // construct with pointer _Ptr
       }

#elif _SECURE_SCL
_Vector_iterator(pointer _Ptr, const _Container_base *_Pvector)
       : _Mybase(_Ptr, _Pvector)
       {       // construct with pointer _Ptr
       }

#else
_Vector_iterator(pointer _Ptr)
       : _Mybase(_Ptr)
       {       // construct with pointer _Ptr
       }
#endif /* _HAS_ITERATOR_DEBUGGING */

これを見るとdefineの定義状況によって、毎回値の妥当性チェックが呼ばれているようです。
これが過度にパフォーマンスが落ちていた原因でしょう。

_HAS_ITERATOR_DEBUGGINGはデバッグビルドでのみ有効になるようですが、_SECURE_SCLはリリースビルドでも残るようです。何用の定義なのかは軽くググッた限りではわかりませんでした。2007-07-04 – 新言語 Xtalを作る日記が見つかったぐらいです。

回避策としては両defineを0に設定すれば動かなくなり、通常のRelease/Debugの時間差で収まるようになります。

ラベリング処理は1970年代から知られている処理ですが、高速なアルゴリズムが意外と知られていません。ネットで検索すると大学の授業での説明資料が見つかる程度で、文献をあたっても解説があまりにも少なく多くは役に立ちません。

古い本でラベリング処理のアルゴリズムが詳しく説明されたものを見つけたので多くの人に有用と思い、ここに書いておきます。参考にした本は近代科学社発行の長尾真さんによる「デジタル画像処理」で、1978年に発行されています。ラベリング処理の紹介は360ページ〜361ページに有ります。

１：値を隣接する画素に伝搬させる

Sの成分をラベル付けする簡単な手続きは、探索と”伝搬”からなるものである。1が見つかるまでSを走査し、その値をまだ使われてない最初のラベルの値、たとえばvに変える。そしてvを1に向けて繰り返し(必要なら並列に)伝搬させる。すなわち、vを近傍として持つ1をvに変える。もはや変化の可能性がなくなったとき、明らかに最初のvに連結した1は全てvになっている。ここでさらに走査を続ける。別の1が見つかれば、これはv成分には属してないので、新しいラベルを付けて同じ手続を繰り返す。

Sが処理対象の画像、ラベル付けする対象が1、割り振るラベル値がvです。
この手法は「この手続は簡単ではあるが、非常に時間がかかる。各々の伝搬の過程は、たとえ並列に処理しても、図形の面積の次数だけの反復を要するからである。」と紹介されています。最初に紹介したMSのサイトで使われているのがまさにこれです。おすすめできません。

２：境界線を抽出し、輪郭内部に同一の値を割り振る

成分のラベル付けの別な方法としては、9.1.2節で述べた境界を見つける手法を、いくつかの外側境界(すなわち、Sの成分でこれを囲むS^の成分に隣接している境界。演習9参照)を別々にマークを付けるよう修正し、各成分の外側境界に異なったラベルを用いる。これが済むと、必要に応じて外側境界のラベルを成分の内側へ”伝搬”させることができる。これを並列に行うなら、たかだか図形の半径に等しい反復数を要する。

手当たりしだいに伝搬させるのではなく、まずは領域の輪郭にユニークなラベル番号を付与し、必要であれば内側に値をコピーする。1番よりは効率的ですが、「外側境界のラベル付けの手続きは時間がかかる
」処理であり、図形の面積につれて増加する多数のステップを有します。

３：行毎に横のつながり(ラン)を求め、上下の対照表をもとにつなげて行く

たいていの目的には、境界よりむしろ1のランを追跡してラベル付けをする次の手法が最良策である。図形の第１行目において、各ランに異なったラベルを与える。第２(とそれ以下の)行では、１のランを調べて前行のランと位置を比べる。ランρが前行のどのランとも隣接していなければρに新しいラベルを付ける。ρが前行のちょうど１つのランに隣接しているなら、そのランのラベルを付ける。ρが前行の２つ以上のランに隣接しているなら、ρにはこれらのらべるの(たとえば)最小値を付けるが、これらのラベルはすべて同一成分に属することも控えておく。図形がこのようにしてすべて走査されたとき、控えを分類して等しいラベルの集まりを決定できる。必要なら、図形を再走査し各ラベルを、たとえば等価な最小の値のラベルに置き換えることが出来る。

ということで、3番目がおすすめです。処理時間が画像サイズに依存して決まるし、ラスタ走査のみなのでメモリ上のキャッシュも有効に動いてくれるでしょう。

上の説明文を素直に実装すれば効率のよいラベリング処理を実現出来るでしょう。

• ディジタル画像処理 (1978年)

最初は物理的な共有、svnやgitなどのツールの活用がこれに当たります。
次は知識の共有、ペアプロやレビュー、TDDなどの取り組みがこれに当たります。
最後が責任の共有、リファクタリングの実施やCIがこれに当たります。

単にコードを共有しましょうというよりも段階を見せて、効果を説得しないと駄目ですね。社内で使わせていただきます。

◯オフショアで成功するコツ
工程ではなく、機能で委託する。機能単位で責任を持ってもらうことが出来る。
例えばテスト工程だけオフショアに出すと、高い確率でレベルが低い人材が割り当てられる。

アメリカではオフショアをかなりやめているらしい。5割から6割を国内に戻したらしい。結論としては「オフショアはうまく行かない。」という認識が広まっている。(ハーバードビジネスレビューで見たとか?)
オフショアするのは企業が重要視してないところ、テストをオフショアする企業は結局「テストを軽視している」ということ。

あとは人が辞めてしまうので、仕組みにノウハウがたまるようにしないとだめだとNEC誉田さんからコメント。
品質の期待値をきちんと伝えるのも効果があるらしい。

◯オフショア開発におけるテスト改善
事例発表でTISの鈴木三紀夫さんが「890個のテスト観点リストと745個の不具合推測リスト」を作成したと話していた。こんなにたくさんのリストを見きれるのかという疑問がすぐ頭をよぎるが、全部読むことが重要ではなく「作業者に頭を使わせることが大事」とのこと。数が膨大だと作業者がコピペで済ませることができなくなり、担当者なりに頭を使う必要が必ず生じる。

・・・

基調講演と招待講演は大変タメになりましが、その他のセッションは役に立ちそうなものと、役に立たなそうなものと結構はっきり分かれました。
参加費は2日間で8000円ぐらいでしたが、値段的にはこんなものでしょう。学会の延長線上と思えば。
でも来月同じ雅叙園で開かれるデブサミを考えるとデブサミのほうがおすすめかも知れません。

来年は誰か他の人に行ってもらおうかな。

・・・

誉田さんが考える「王道を行く」とは本質を理解した上で、決意を持ち達成に向けて行動すること。
手段ではなく目的、手抜きではなく効率化、新たな気持も大事だけど先人の知恵に学ぶ。
品質のみを追求している訳ではないが、品質を追求すればコストも納期も改善出来ると誉田さんは考えている。

＜事例１＞
自社が関連する単体テスト実施状況を調査したところ、単体テストをきちんと実施しているプロジェクト(限界値とか、テストの組み合わせを考慮して普通にやる)は単体テストで手抜きをしている or 単体テストをしていないプロジェクトと比較して出荷後のバグが38%少なかった。きちんとテストを実施すれば62%も取り除けたのに(きちんと単体テストをしても38%も残るのかという見方もできるけど・・・これは私の主観)

＜事例２＞
オフショアの品質を改善するために、海外子会社をかなりの労力をかけて教育した。具体的には数値目標を立て、プロセス・基礎開発技術・マネジメント・日本語語学力に国内同等レベルを求めた。結果として現地管理職の認識も代わり、改善が進むようになった。(最も、事例としてあげた中国の工場は管理者が転職してしまったらしいんだけど・・・)

＜事例３＞
開発案件や組織力が似ている組織Aと組織Bからいろいろなデータを取ってみた。Aを100%としたとき、Bの全工数は106%程度、ただしレビューやテストは50%前後だった。1000行あたりのバグ件数はBはAの80%。全バグ数に対する上流工程までのバグ摘出率はAとBはほぼ同じ。Bのテスト項目数はAの約半分だった。

組織Bは「プロセスを改善すれば工数やバグ数は減るはず」と解釈し、そのように取り組んでいた。だからテスト工数がAより少なくなり、そのような統計結果も出た。でも市場で出たバグを見るとBの方が品質が悪かった(数は変わらなくても、Bの方が長期間にわたってバグが出続けた!)。結果としてBのほうがAより2倍以上品質が悪いという調査結果が出た。

データを分析すると組織の取り組み方の違いが現れた。Bの組織は目標の達成が主眼となってしまい、数値目標を達成したらテストを終えてしまっていた。本当はプロジェクトごとに差が出るものなのにそれがなかった。基準値順守が「形骸化」してしまった。社内のベストプラクティスを組織Aと組織Bに適用しても組織Bでは効果が得られなかった。結局組織Bはルールだから実施していた、テスト時に担当者が頭を使っていなかった。

誉田さんがまとめのスライドに載せていたのは「何のためのプロセスかを常に考える土壌作り」が必要とのこと。形だけを真似ても成果は得られない。

・・・

目から鱗でしたね。ソフトウェアの状態をツールやメトリクスを使って見える化し、データをノウハウとして蓄え、組織として横展開できれば品質は今より良くなるはずだと思っていましたから。まさに組織Bの人間です。
プロジェクトごとに性格や条件が違うことに気づき、もっと頭を使わないと駄目ですね。自社の品質改善を考えていくに当たり、大きな宿題をもらった講演でした。

開発者が行う改善は55%だが、マネージャーは65%の改善に貢献出来る。目的を持って人をまとめるのがマネージャーの仕事、開発に集中出来る椅子とかを揃える以外にに良い人間関係を築くことが大事。

効率的なマネージメントのやり方を17の法則としてまとめた。以下原文ママ。

1. Know What They Pay You Do
2. Plan the Work: Portfolio Management
3. Accept Only One #1 Priority at at Tme
4. Commit to Projects After Asking Your Staff
5. Hire the Best People for the Job
6. Preserve Good Teams
7. Avoid Micromanaging or Inflicting Help
8. Treat People Individually and With Respect
9. Meet Weekly with Each Person
10. Plan Training Time in the Workweek (Plan Training Time Each Week for Yourself)
11. Give Credit Freely
12. Fire People Who Can’t Do the Work
13. Emphasize Results, Not Time
14. Admit Your Mistakes
15. Recognize and Reward Good Work
16. Take a Vacation
17. Manage Yourself

以下Rothmanさんの発言メモ、一部意訳があるかも。

1. 業務上の肩書きと実際の職務内容、使命があっているか確認すること。
3. 優先度1のタスクは常に1つしか無いはず。複数あるのは何かがおかしい予兆。
4. タスクはチームで決めよう。
5. 雇うべきはgreatな人材、それは必ずしもチームに今いる人材とは違う。タイプ(性格/個性)の異なる人を集め、アイデアを生む。
6. 良いチームは残そう、解散するとチームが備えていた力が失われる。
9. 信頼できる関係を築くなら1対1がいい。直接のフィードバックもし易い。
13. 作業時間に比例して作業内容も増える。1週間40時間で仕事を終えられるよう作業を組むのもマネージャーの仕事。

Pragmatic Programmerシリーズの1冊を書いているだけあって実用的で、口先だけの話をしている人ではないのだなと聞いていて感じました。

この本の正しい使い方。

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

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

・・・

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

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

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

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

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

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

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

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

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

「今日はもう帰りたいんだけど、あと1時間ぐらいしたらデータ取りが終わるから1時間半後にこのプログラム回しておきたいんだけど」というニッチな悩みをしていたところ、Linuxで一定時間後にプログラムを起動する方法を見つけました。
一定の時間後にプログラムを実行するには

例えば1分後にprocess_dataコマンドを実行するなら

% sleep 60; ./process_data

とやっておけばいいそうです。sleepコマンドを使うとターミナルの応答が返ってこなくなりますが、GNU screenと合わせれば問題なしですね。

さらにatコマンドを使って指定時間にプログラムを起動する技もあるそうです。

% at now + 1 hour
at> ls
at> date
at> （［Ctrl］＋［D］キーを押す）
warning: commands will be executed using /bin/sh
job 8 at 2001-02-09 14:38

探せば便利な技があるんですね。

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

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

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

フレーベル館【えほんとおもちゃのお店】 via kwout

先週末の話ですが、妻に買い物を頼まれてフレーベル館に行ってきました。アンパンマンで有名なフレーベル館ですね。まだうちの娘はアンパンマンにはまる年齢ではないのですが、最近シールに凝っていて、ごほうびシールにここでしか売ってないキラキラアンパンマンシールがいいとのことでお使いにいってきた次第です。

アンパンマンミュージアムの方が品揃えはすごいのかもしれませんが、隠れ家的な店内はところ狭しとこどものおもちゃが並べられていてなかなか良いお店だなと思いました。お店の目の前は六義園なので、もう少し暖かくなってきたら家族連れで行くのも良いかもしれません。

お店の中にはおむつがえコーナーや、赤ちゃん休憩スペースもあった気がします。次は我が家も子連れで行ってきます。

ソフトウェアの構成管理をするのは今時当たり前ですが、構成管理システム(バージョン管理システム)の使い方は千差万別です。今でもローカルフォルダに置いてあるとか、ネットワーク上の共有フォルダに置いてあるとか、外注先のローカルフォルダに置いてあるとか、ひどい例を探していくといくらでも考えられます。うちの一昨年の新人曰く「フォルダを作ってフルバージョンを残しておくこと」なんて新人犬種で教わってきたらしいので、ひどい世の中です。

新しい順に分類すると

• 分散型バージョン管理：Git / Mercurial / Bazaar
• 集中型バージョン管理：Subversion / Perforce
• 集中型の旧世代：CVS / Visual Source Safe
• 古代：フォルダを分ける、共有フォルダに置くとか。

といった形でしょうか。

そして、どうしていつまでも古いやり方を踏襲する人がいるのかという話です。勉強する時間が無いとか、やり方が分からないとか、組織で決められているとかいろいろ理由があるとおもうのですが、「使っている構成管理ツールにあわせて作業手順を決めているから、より優れたツールがもたらすメリットを説明されても何を問題としているのかわからない」という発想がふと浮かびました。

フォルダ管理の人は、一人でしか開発してないから複数人で共有する時の話をしてもピンとこない。もしくは構成管理も含めて外注しているからたまに来る納品物を共有フォルダに置いておくだけで十分なんでしょう。

CVSの人はソフトウェアのバージョンは1.X.Yみたいに増えていくものと信じ込んでいて、複数ファイルをまとめて管理するなんて発想はないんでしょう。VSSの人はファイルをいじるときは一人が長期間ロックするものだという前提があるんでしょう。

Subversionの人はブランチは大きな機能を追加するときにたまに使うものだと思ってるんでしょう。

構成管理ツールと言うのは単に機能を提供するだけではなくて、ソフトウェアの手順を暗黙的に決めてしまいます。逆に考えると、新しいツールを使うときは新しいやり方を最大限活かせるように作業手順を作りなおさないとダメでしょうね。

入門Gitを読んでいて感じたことが、ようやく自分の中で咀嚼できた気がします。

会社の作業環境ではTortoiseSVNとTortoiseGitをインストールしていたのですが、いつからか両方のオーバーレイが表示されなくなってしまいました。てっきり両者が競合でもしてるか、TortoiseGitが悪さでもしているのだろうと思っていたのですが、調べてみるとWindowsの仕様で表示されなくなっていました。

Windowsではオーバーレイさせるアイコンをレジストリで記憶していますが、最大で15個という制限があるそうです。それ以上もレジストリに登録できるのですが、最初に登録されたものから無効になってしまうそうです。自分の場合、あとからインストールしたOffice2010(Microsoft Ofiice Groove?)が原因だったようです。

対処法としてはレジストリをチェックして15個以上登録されてないか確認し、不要なものをアンインストールするか、レジストリの不要項目を削除すればOKです。チェックするレジストリは”HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Explorer\ShellIconOverlayIdentifiers”です。

以下のブログを参考にさせていただきました。

• TortoiseSVNのアイコンオーバーレイが表示されない – espresso3389の日記
• TortoiseSVN のオーバーレイアイコンが表示されない

Googleするとすぐ見つかる情報ですが、おすすめのExtensionは重要度別におすすめするGoogle Chromeのエクステンション：945分の50選でみつけました。あとChromeのDevチャンネルはEarly Access Release Channels (The Chromium Projects)で見つかります。

・・・

そんな便利なGoogle Chromeですが、Livedoor Readerのピンを開くのに問題があってポップアップブロックをブロックしてしまうため、ピンを開くことができません。Chromeを引数付きで起動すれば回避できるらしいのですが、Macのアプリケーションでやる方法がわからなかったのでGoogle Readerに乗り換えてしまいました。これでfeedly: a magazine-like start pageも試せますし。

ということでよりGoogle依存が進んだ作業環境の紹介でした。

連続ドラマは全部見ました、原作は読んでいません。その程度のガリレオファンの感想です。

ガリレオ・・・では無いよね? 雰囲気が違いすぎて。
原作はこんな感じなのかしら?

科学に基づいた湯川先生の痛快な謎解きは見られません、あしからず。

アート・オブ・プロジェクトマネジメント —マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE) (単行本（ソフトカバー）)

アートオブアジャイルデベロップメントを買おうと思って本屋に行ったら見つけた本。パラパラと中身をみて今の自分に必要そうだと思ったのですが、Amazonの書評をみて決めようと思ってその場では買わなかったものです。自分が知らなかっただけで結構評判の良い本のようなので買うことにしました。
アートオブアジャイルデベロップメントの方はまたの機会に。

発想する会社! — 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法 (単行本)

前から欲しかったんだけど買う機会がなくてずるずるウィッシュリストの上位にあった本です。技術書だけだと飽きるので、合間に読もうかなと。メイキングオブピクサーと悩んだのですがこれもネット上の評判を信じてこっちにしてみました。というかネット上の評判に左右される買い物が多いですね、自分。

Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala) (単行本)

今年はふつうのHaskellプログラミングを読んで、Haskellに触れてみましたが、来年も何か新しい言語を勉強して見識を広めようかとScala本も購入。高いのがネクですね。
Haskellの知識も怪しいところが盛り沢山なのでまた来年再入門しようかしら。

“劇場で見ないと”という声に押されて見てきました。この前”This is it”を見ようとしてチケットが買えなかった川崎のIMAXシアターでみることができました。字幕の3D上映です、国内だとこれより良い視聴環境はおそらく無いのかな? その代わり料金は2200円なり。

映画は評判通りよく作りこまれていて、長い上映時間も気になりませんでした。今年の冬映画の中心はやっぱりAvatarなのでしょう。「アカデミー賞を取れるような名作か」と言われるとそれは無い気がします。Avatarに関するよくある批評に”〇〇の映画にストーリーが似ている”というのがありますが確かにそうかも知れません。ストーリーよりも映像表現で話題になる映画かと思います。ジュラシック・パークやマトリックスのように映像表現の新時代を告げてくれる映画なんだと思います。Avatarに触発されてジョージ・ルーカスがスターウォーズの7・8・9をフルCGで作りなおすという噂もありましたが、ぜひ取り組んで欲しいと思います。
『スター・ウォーズ』の新3部作、3Dで制作か | エンタテインメント | マイコミジャーナル

今回はじめて3D映画を見ましたが、こっちの未来は暗いと感じました。IMAXシアターで見たのに見づらいところが画面のところどころに見受けられました。おそらく3Dにしたことで解像度が落ちている影響ではないかと思います。3Dは右目と左目に別々の映像を見せる必要があるため、画面の画素数が元のものよりも少なくなってしまいます。IMAXでこれでは3Dの夜明けは今回もこないのではないでしょうか。

映像に一家言ある人も、そうでない人も、劇場で見ると楽しめる映画だと思います。

名作とネット上の評判が良かったのでテレビ放送されていたのを録画してみました。
個人的に響くところはあまりなかったので星は2つぐらい。

子供に見せたいかとなると・・・もっと他にもいい映画あるだろうからそっちを選ぶかな?

Backupify :: Secure Online Backup and Archiving for Gmail, Facebook, Twitter, and Wordpress via kwout

Lifehacker経由で知ったバックアップサービスを試してみました。twitterからdelicious、WordPressのブログからFlickrまで何でもバックアップしてくれるそうです。しかも来年1月末までに登録すれば以降も無料で使えるとか。使ってみて本当に信用に足るなら良いサービスですね。

インストール型のWordPressでもプラグインを使ってデータを吸い出してくれるようです。Blogのバックアップは怠りがちなので助かりますね。

◯2009年12月29日追記
WordPressだけバックアップに失敗してた。
プラグインは一旦サーバ上にzip圧縮されたバックアップを作ってそれをbackupifyのサーバに送っているらしい。つまりサーバ上のバックアップに失敗するとbackupifyで吸い出したファイルはサイズが0のゴミが記録される。

確認方法は管理画面のbackupifyからローカルでのフルバックアップを試してみればOK、自分の場合はフォルダのパーミッションがおかしかったみたいでそこを直せばいけた。
zipファイルを書き出すフォルダが見つからなくて苦労したが、wp-contentの下にbackupify-〇〇というフォルダができていてそれを使っているようです。

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

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

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

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

◯t-wadaさんのTDD話
いつものように資料があとでアップされるのではないかと思います。
個人的にとってたメモを以下に載せておきます。

会場ではt-wadaさんのテスト駆動開発本が見れるようになっていました。かなり読み込まれた形跡があって、TDD愛が伝わります。訳がいまいちというAmazonレビューで躊躇していましたが購入して読んでみようと思います。

◯Test Drivenの作者 Lasseさんの講演
レシーバーが足りなそうだったので英語を聞きとるのに必死になってしまい、話の所々がフォローできず。
twitterの#tddbcタグを見る方が参考になるかも。
内容はレガシーコード改善ガイドの紹介と、Coberturaのライブハッキング。Eclipseのコードさばきが見事すぎて見とれてしまいます。

◯TDD実践編
ペアを組んでサイズ制限付きのハッシュを作成しました。
いつもだとつい実装を先に書いてしまい、テストが後回しになったり、テストに抜けや不足ができてしまうのですが、ペアプロだったこともあって、TDDの基本的な流れが改めて抑えられたと思います。

ソースはgithubに上げてあります。

http://github.com/tune/lrucache

TDDを知るには完成形のソースではなくて、その過程を学ぶことが大事ですね。gitを途中から使っておきながらあまりコミットできてません。次はもうちょっと気を配らないと。

周りにすごい人もたくさんいました。

• ペアプロでのソースの受け渡しをgithub/gistでやっちゃう
• gistにソースあげたし、CIもやるか→ローカルHudsonでCIまで
• 一人で時間あったしやってみたよとLasseさん、しかもJavaとRubyの2言語。Rubyのテストをみんなで見たけどテストが完結で読みやすい、ここまでできるのかと目から鱗でした。

会社ではC言語なのでCUnitを使ってテストは書いていますが、我流になっているところがあって、今日は行けてよかったです。

• テストも製品ソースと同じく綺麗に書く → 主張はよく耳にするけど実際にLasseさんやその他の人のソースをみると上には上がいて、きちんと実践できてます。
• 言語でテストの読みやすさ、書きやすさに差ができるわけではない。Javaでも簡潔にかけるし、Rubyでもどうしようもないコードはかけてしまう。

楽しいイベントを開催していただきありがとうございました。

早くから誕生日ケーキを予約してたので一番上に！ いろいろあったけどお誕生日おめでとう♪

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

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

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

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

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

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

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

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

インクリメンタルだと最初から完成した姿を見越してI/Fを完全に作り込むのはあまりに難しく、かといって完成した部分に都度手を入れていては差分開発による工数の削減にならず、スケジュールが問題化してしまう。だったら前に完成したところは触らず、追加分で黒魔術を駆使しようという勢力が優勢になり、バージョンを重ねるにつれて継ぎ接ぎ部分が問題化する。機能もソース規模も雪だるま式に増えていく一方で、全体最適なソフトを作ることはきっとできない気がする。

差分開発というキーワードは一般的だけど、自分たちが取り組んでいるのは「イテレーティブ型」で、将来にわたってソフトウェアが最大の価値を生めるようにしているからだと主張しないと、ソフトウェアアーキテクチャの設計が悪いから差分開発が徹底できてないと評価を下されてしまう。

マネージャー層の階層を上がるほど「インクリメンタル」を念頭に置いている人が多いような気がします。機能が一通り揃ったら開発を収束させて、別なソフトに触手を伸ばすのもインクリメンタルな発想ありきなマネージメントかな?

昨年(2008年!)の11月に友人から借りてちょこちょこ進めていたゼルダをようやくクリアしました。娘が生まれる直前にちょちょっとクリアして返すつもりだったものが思いがけず時間がかかってしまいました。一番の原因はまとまった時間をとらなかった自分にあるのですが、このゲームもボリュームたっぷりでクリアまでに35時間ほどを費やしました。攻略法を調べながら、途中の寄り道も一切しないでこの時間なのでかなり内容が盛り沢山です。

最初の大きなダンジョン(森の神殿…だったかな)に入るまでが多少冗長なものの、その後は謎解きの難しさや、少しずつ広がるフィールドにわくわくしながらプレーすることができました。巨大なボスとの戦いもまさに手に汗握るシーンの連続で、さすがゼルダと思わせる完成度の高さでした。

この年末はDSでゼルダの新作が、Wiiでマリオの新作が発売されますが、ゲーム以外にテレビドラマや本の積読もひどいことになっているので、しばらくゲームから離れようかと思います。

途中寄ったところは行きに箱根彫刻の森美術館、帰りに御殿場プレミアムアウトレットです。どちらも小さい子供連れでも十分に楽しめました。以下途中で撮った写真です。

ちなみに泊まったのは会社の保養所でした。設備もきれいでご飯もおいしかったです。

紅葉には少し遅かったのかもしれませんが、それなりに楽しめました。

ピークを少し過ぎた仙石原のススキも。2年前にも見ましたが、今回も観光客で賑わってました。

2003年ぐらいからの写真が撮りためられているiPhotoですが、データは全部で20ギガバイトを超えており最近アプリの調子が悪いことが多々有ります。具体的には読み込み途中にフリーズしてデータが消えたり、読み込んだはずのファイルが消えてしまい、キャッシュからは見えるものの参照不能ということがありました。

Googleで調べてもきちんとした原因も、対策も見つからなかったのですが、iPhotoのライブラリファイルを作り直す方法を見つけたので紹介しておきます。Appleの公式Helpページのようですが、引用している人が少ないのか検索結果の上位に表示されないので見つけにくいかと思います。

iPhoto 6 and later：iPhoto ライブラリを再構築する方法

iPhoto ライブラリを再構築するには、以下の手順に従います：
1. iPhoto を開いている場合は終了します。
2. キーボードの「Command」キーを押しながら「Option」キーを押します。
3. iPhotoを 起動します。
4. ライブラリ再構築の確認ダイアログが表示されるまで、キーは押したままにします。
5. 再構築のオプションのダイアログが表示されます。使用したいオプションを選択します。
6. 「再構築」をクリックして再構築を開始します。完了までに数分かかる場合があります。

だそうです。

自分のところで問題となったキャッシュとリンク切れの問題はこれで解決可能です。しかしWindows時代に使っていたPicasaと比べるとトラブルが多い印象です。

去年末からTDDを取り入れて開発を進めていますが、我流で周りに実践者もあまりいません。普段の取り組みで悪いところやコツなど学んで来れたらと思っています。ワークショップも有るので「ただ話を聞いて何となく勉強した気になった」というのも避けられそうというのが申し込んだもう一つの理由です。

実は普段はC言語(xUnitはCUnitを使用)という自分なので、当日使う言語の予習が必要そうです。第1言語はRubyにしましたが、RSpecは書いたこと有りません。第２言語はJavaにしましたが、Java5よりも前で止まっています > < 。

PC持ち込みなので設定して持っていかないと! 忘年会シーズンに頑張れ自分!

映画というより、劇場で見れるドキュメンタリーに位置づけられる映画だと思うのですが、マイケルジャクソンのドキュメンタリーというのは半分当たっていて、もう半分はマイケルジャクソンのライブを見てきたような印象です。劇中にかかる曲はどれも心地よく、自然とリズムを刻んでしまいます。上映後には観客から拍手もありました。熱心なマイケルファンかもしれませんし、映画に感動した人かもしれませんが後者の人が何人かいたはずです。自分がその一人だったので。

ドキュメンタリーとしても面白くて、マイケルジャクソンの人となりが映画を通して知ることができます。

彼は常に謙虚な姿勢で周囲とコミュニケーションをとっていた。ダンサーや演奏者の持ち場を引き出すこともするけど、曲のテンポや間など譲れないところは熱心に周囲を説き伏せる。

彼は完璧主義者でリハーサルの様子はオーケストラを束ねる指揮者のようでした。もしくは一つの作品を作り上げる芸術家かも知れません。正解は彼の中にしかなく、周りが彼と対話しながらより良いコンサートを模索している姿が映し出されていました。

彼と共演したいパフォーマーは世界中にいて、多くが1流の腕を持つ人ばかり。でもその中から超一流のスタッフを選別する。だから観客はこれまでに見たことが無いような体験をコンサートでできる。一流の人が飛行機に飛び乗ってでもオーディションに集まるのはマイケルが超一流のパフォーマーである証。彼と一緒に仕事をすると他の仕事では味わえない楽しさがあるからみなが集まる。

最後のコンサートを発表したとき「みんなが聴きたい曲を歌う」とコメントしてたけど、THIS IS ITは彼の集大成では無かった。衣装や演出の細部に至るまで何かしら新しいことに取り組み、常に挑戦する気概を持っていた。

上映期間は来週末までのようですが、機会があれば劇場で見ることをお勧めします。

マイケル・ジャクソン THIS IS IT – オフィシャルサイト

海外から送られてきます

で、驚いたのが送付元と宛先欄です。親展と日本語表記が有るのに海外から送られてきます。2週間ぐらいかかるというので不思議だったんですがこれが理由のようです。
PIN要求時に住所を英語と日本語の両方で記入していたので英語側が使われるのも以外でした。というか普段英語の住所表記なんて使ってないので結構適当に入れたんですが無事に届いたことに安堵しました。

これからAdsenseを使う人は住所入力を気をつけましょう。

公式にこういう設定があってもよさそうなものですが、AppleはNASとしての使い方を認めてないのか設定項目は無いようです。なのでこんな手口を使ってTimeCapsuleをだますことにします。

• TimeCapsuleはDataフォルダに”マシン名.sparsebundle”という仮想ディスクファイルを作成し、この中にバックアップデータを溜め込む仕様になっている。
• sparsebundleファイルが無ければ新規に作成するが、このときにディスクサイズがHDDの容量と同じで作られてしまう。
• そこであらかじめsparsebundleファイルを作成しておき、ディスクサイズを指定して制限をかける。

sparsebundleファイルはディスクユーティリティで作成できます。
自分は以下のブログを参考にしました。

• Old PowerBook生き残り作戦【アップル パワーブック】 | Time Capsule：Time Machineで使用する容量を制限する
• Time Capsule のバックアップ領域にクォータをかける？ – 某開発者の雑記帳
• Normal is Best.: Time Capsule のパーティションを切ってみる。

上記ブログによるとsparsebundleファイルには有線LANのMACアドレスが入るらしいのですが、自分の環境ではついていませんでした。OSがSnow Leopardになったのか、TimeCapsule側が更新されたのか分かりませんが、最近の環境ではちょっと事情が違ってきているようです。で、問題は上記ブログの通りにやっても容量制限ができませんでした。TimeCapsule側でご丁寧に”マシン名2.sparsebundle”を作って、そっちを使い始める始末です。

で、ディスクが作成済みかどうかを調べる方法が変わったのだろうと思って調べ直したところ以下の情報にたどり着きました。
Macの最適なバックアップ環境(ソフト/ハード)とは
ポイントとなる箇所を引用すると

成功トライ■まず、com.apple.TimeMachine.MachineID.plistというファイルがTimeMachineがTimeCapsuleに作成したスパースバンドルファイルにだけは含まれていますので、これをバックアップしておきます。(デスクトップなどにコピー)

その後、元々のスパースバンドルファイル(例：MacBookPro2.sparsebundle)を削除し、同じ名前を使って、ディスクユーティリティーから新規に(直接TimeCapsule上に)スパースバンドルファイルを作成します。勿論、容量を適度に350GBなどとして作成します。

容量を指定して作成したので、この段階では容量制限も利いています(ディスクユーティリティーから容量の変更を試みると明白)。ここで、実はこのスパースバンドルファイルの中にはcom.apple.TimeMachine.MachineID.plistが含まれていないので、先ほど待避しておいたファイルを(「パッケージの内容を表示」して、その中に)コピーします。これをしないと、TimeMachineは新しい名前の (例：MacBookPro2-1.sparsebundleとか……)を作成しようとするはずです)

これで、通常通りTimeMachineからTimeCapsuleを選択することで正常に、かつ容量を制限(クォーター設定)が可能となりました。同じ要領で他のマシンのスパースバンドルファイルも作成すれば万事解決となります。

鍵はcom.apple.TimeMachine.MachineID.plistです。自分の環境でもこれであらかじめ作成済みのsparsebundleファイルが使われるようになりました。システムの環境設定を見るとTimeCapsuleの容量自体は1TBのままなので、500GBに制限できているのか確認するすべがディスクユーティリティの表示を信じるしか無いのですが、少し間隔を空けて確認してみようと思います。

アップル Time Capsule 2TB MB996J/A

少し流行からは遅れましたが、ようやく読み終わりました。既に各所で絶賛されていますが、自分もなかなかの名著だと思います。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があって、普通に使えてますよ。

WordPressにtwitterのfolloer一覧をウィジェットとして表示できるプラグインです。
つぶやき一覧を表示している人はたくさんいますが、followerの方がブログを書いている人の人となりが伝わりやすい気がしてつけてみました。

• WordPress › Twitter Followers « WordPress Plugins

シネマツさんって

ドミノピザで注文したら名前が「シネマツ」さんに・・・
こんな名字の人いる訳無いよね。

”タ・チ・ツ”のツネマツって電話口で言ったはずなんだけど。

んで、対策として取ったのが gitでリポジトリからのチェックアウト時に文字コードを変換する » tune webだったんですが、今日仕事中にこんなページを見つけました。
GOGA – 数式の夢とコンピュータの現実: UTF8のソースコードをgccとVCで共有すること

なんだ、VisualStudioの方は警告さえ抑えれば普通にコンパイルできるのかとさっそくやってみたのですが、見事に失敗しました。VisualStudioでコンパイルするとエラーが山ほどでてダメでした。
調べてみるとVisualStudio2003まではいけたらしいんですが、自分が使っているVisualStudio2005ではNGでした。今の最新版は2008ですし、来年には2010もでます。VisualStudioのバージョンによらず簡単な解決法を模索したいところなのですが、困りました。

「VisualStudio2008/2010ならBOM無しのUTF-8も扱えるよ」という情報をお持ちの方がいらっしゃいましたらぜひ教えてください。

• iPhoneで撮影した写真をブログなどにアップしている方は要注意！GPS情報ダダ漏れの危険あり！ : ライフハッカー［日本版］, 仕事も生活も上手くこなすライフハック情報満載のブログ・メディア

時間をかければもっといいやり方もあるんでしょうが、最小限の労力でそれなりの結果が得られる方法です。XREAでやりましたが、sshアクセスができるなら他のサーバでもできるんじゃないかと思います。

1. サーバに Exif Jpeg header manipulation toolをインストールする。
iPhoneのカメラでプライバシー情報ダダ漏れだった | Selfkleptomaniacで紹介されていたツールです。XREAの場合sshでサーバにログインして

% wget jhead-2.XX.tar.gz
% tar xvfz jhead-2.XX.tar.gz
% cd jhead-2.XX
% make

とやるとjheadというファイル名の実行プログラムが出来上がります。ホームディレクトリあたりにbinディレクトリを作って、そこにコピーしておくといいでしょう。

jheadを使って特定JPEGファイルのヘッダ情報を削除するには
% jhead -purejpg target_path/target_file.jpg
で元ファイルが書き変わります。

2. cronでjheadによるファイルヘッダ削除を自動で行うようにする。
あとはこれをcronで自動実行するだけです。
自分の場合はこんなファイルを作成して、cronで1時間おきに実行するようにしました。

#!/bin/sh
cd /virtual/tune/public_html/www.tsunematsu.cc/wp-content/uploads

# delete gps information from *.jpg
find . -mtime -1 -name \*.jpg -print0 | xargs -0 /virtual/tune/bin/jhead -purejpg

# delete gps information from *.jpeg
find . -mtime -1 -name \*.jpeg -print0 | xargs -0 /virtual/tune/bin/jhead -purejpg

これでうっかりGPS情報付きのファイルをアップロードしても1時間以内に削除してくれます。

iPhoneのワードプレスアプリを使って画像をアップロードするとアプリ側で消してくれるみたいです。
本当はファイルアップロードスクリプトを書き換えて、保存したあとにjheadを走らせるようにすればより早く消せるんですが、WordPressのバージョンアップに追従していくのは大変そうですし、これで妥協しておきます。

WordPressだけ対策とって安心していましたが、flickrも同様ですね。
あっちはアップロード前に消すしかないのでAutomaterでも使ってアップロード前にひと手間加えるのがよさそうです。また時間ができたときにやります。

以下設定の流れと感想です。

外箱

裏面、よく読むと誤植が

Wiiよりも一回り大きいぐらい

配線はこれまでつかっていた無線LANルータへのLANケーブルをTimeCapsuleに差し替えて終了。あとはPCのアプリケーションから”ユーティリティ->AirMacユーティリティ.app”を起動して質問に答えていくだけです。家の回線はJ-COMのCATVを使っていますが、これがDHCPで外部へのネットワーク設定をやってくれるので、今回はほぼ何もせずにネットワークを切り替えることができました。J-COM万歳!

あとはバックアップを取るだけです。初回は100GB超のデータをコピーするため遅いらしいので、今晩はPCをつけっぱなしで寝ることにします。

で、問題はMySQLテーブルはInsert/Deleteを繰り返していくと領域に無駄ができ、パフォーマンスが落ちる問題がある。これがMySQLのオーバーヘッド。WordPressでMySQLを使っていると何かの原因でオーバーヘッドが大きくなり、MySQLにログインできるものの、オーバーヘッドが大きなテーブルからデータを参照できなくなる。こうなるとインデックスページを表示する処理も、個別ページを表示する処理も、管理画面を表示する処理もMySQLのクエリで処理が詰まってしまう。詰まってしまうといくつものリクエストが待たされてしまうのでMySQLの同時接続数を超えてしまう。こうなるとエラー画面として問題が表面化してくる。これが今回の原因の直接的な原因。

で、なぜオーバーヘッドが増えるのかは不明。ポストデータやコメントデータは増えやすいようだが、自分の場合はオプションを保存するテーブルがオーバーヘッドの問題になっていました。なので一度オーバーヘッドを対策すればしばらく問題とならないケースと、すぐにオーバーヘッドが増えてしまって、根本的な解消にならないケースがあります。

MySQLのオーバーヘッドを直すには最適化処理をテーブルに行えばOKです。phpMyAdminならテーブルを選択して最適化を指示すればOK、SQLで叩くには

OPTIMIZE TABLE `wp_wordpress_options`

でOKです。

ポストデータやコメントは一度問題を解消してしまえばしばらく起きないようですが、自分の場合optionテーブルはすぐまたオーバーヘッドがたまってしまう問題がありました。で、対策としてサーバのcronで定期的にテーブルの最適化を行うように指示しました。
cronにこんなのを書けばOKです。

0 * * * * /home/hogehoge/cron/optimize-mysql >/dev/null 2>&1

optimize-mysqlはこんな感じ

#!/bin/sh
/usr/local/mysql/bin/mysqlcheck -o -r –all-databases -uhogehoge -phugahuga

最後に参考情報を載せておきます。XREAだけでなく、coreserver、さくらも結局ダメみたいですね。

• WordPress › フォーラム » MySQLのオーバヘッド蓄積によるトラブルについて
• phpMyAdminでMySQLのバックアップ・オーバーヘッドの解消 : 今日の覚え書き Tickler’s bunkum days
• ペベリンスキ-ズBLOG v.2 » Blog Archive » 劇的ビフォーアフター
• CORESERVERのCRONでWordPressのDBを定期的に最適化とかする方法 – As a Futurist…

毎夜のストレステストが落ちてた報告がメールできていて問題に気づきました。
エラーメッセージを見るとHudsonでジョブを起動したときに落ちていたので、前日にアップグレードしたHudsonのバージョンの関係かとSlave周りの設定を見直してました。

結果として間違っていたのはHudsonのバージョンではなく、整理したPluginの問題でした。Mercurialやrubyなど使ってもいないプラグインが多数有ったので一括して使わなくしたのでした。その中にSubversionプラグインがあったのですが、これはHudsonのSubversionサポートを強化してくれるプラグインではなくて、Subversionサポートそのものを提供してくれる物だったんですね。昔はSubversionだけ組み込みで提供してくれていたのでうっかりハマりました。

同じ間違いをする人がいるとも思えませんが、参考まで。

ちゃぶ台に立つのがお気に入り

生まれた報告を書いたっきりほったらかしになっていたので成長ぶりを忘れないようにエントリ、もうじき1歳です。

• 身長は平均よりも大きいらしい、体重は軽め。10ヶ月検診時に74cm、体重は8.6ぐらいだったかな?
• ハイハイは自由自在、つかまり立ちも得意、まだ手を離すのは怖いみたい。バランスももう少し。
• 新しい物好き、新しい物を見つけるとすぐ口に入れてしまう。
• 熊のぬいぐるみとアヒルのパペットは継続してずっと好きみたい。
• 自由に動けるようになって自分の意思を主張するようになった、頑固でいらずらもの。
• 生まれた頃に比べればまとめて寝るようになったけど、まだ夜中に1回は起こされる。
• 抱っこしなくても添い寝してれば寝るようになった。ただしものすごく寝相が悪い。
• 初めて呼んだのはママじゃなくてパパ、ここ最重要!

手もかかりますが、成長が目に見えて子供がいると家が明るいです。

• 10/23にブログをリニューアル
• これからはマメに書くか
• 10/27の夜からMySQLサーバに接続できず
• XREAサポートに問い合わせ
• MySQLの接続プロセスをKILLしろという
• 状態変わらず
• 他に原因があるのではないかと再度質問
• 同時接続数ではなく、MySQLのデータベースが腐っているのでは?
• MySQLのデータベースをいったん削除して、バックアップを書き戻したら元に戻った。

何かのデータがアクセスできなくて、新規のリクエストが詰まっていたのかもしれん。

・・・

やっぱり具合悪いかも。
下の質問と同原因に思えるんだけど、データベースは作り直したばっかりだから修復いらないと思うんだよな。
WordPress › フォーラム » 急にデータベース接続確立のエラーとなっています

・・・

もうちょっと詳しい原因が分かったので別エントリに書きました。
WordPressが調子悪い理由が分かった -> MySQLテーブルのオーバーヘッド » tune web

iPhotoで写真を読み込むと、写真を読み込み終わった後にオリジナルを消すかどうか聞いてきますが、この後で削除中にiPhotoがフリーズするとPCへのデータ吸い出しは失敗し、オリジナルのデータは削除されているという散々な状態になります。というか実際なっていたい目を見ました。Appleひどすぎます。

iPhone上のデータはあきらめがついたのですが、iPhoneのカメラロール上の写真数表示と実際の写真数に食い違いが出て2度困ることになりました。

解決法ですが、 窓の杜 – 【REVIEW】iPhone/iPod touch内のファイルをエクスプローラ風に管理できる「DiskAid」の用なツールをつかってiPhone上のファイルを扱えるようにし、DCIMフォルダを削除すれば元に戻ります。

やったことは

• WordPressを2.8.5にアップグレード
• プラグインも全部最新版に
• iPhoneアプリから投稿できるようにアプリ側の設定
• なぜかXML-RPCがiPhoneアプリで動かなかったのでテーマを変更
• 昔から惰性で貼っていたGoogle Adsenseを削除

テーマを変えるのは抵抗がありましたが、WordPressが高機能なせいかあっという間に終わりました。
自分でカスタマイズをごりごりするよりもアップデートに追従しやすくていいですね。

ライオンさん

歌って踊れるぬいぐるみ!?『KUCHI-PAKUアニマルスピーカー』 – ガジェット通信で紹介されてたスピーカーがあまりにもかわいかったので購入してしまいました。名目は近くに迫ってきた娘の1歳の誕生日プレゼント。

買ってみての感想ですが

• 思った以上に動いてすぐ倒れてしまう
• 動くときの音がウインウインうるさい
• モノラルスピーカーなので音楽を聞くにはもう一つ

とさんざんな感じなんですが、いいところも有って

• ラジオをかけると実際に話しているみたい
• マイクで動くモードがあって、話しかけると動いてくれる。フラワーロックのぬいぐるみ版だけど娘がたいそうお気に入り

です。

値段を考えるとウーんですが、娘が喜んでいるのでよしとします。

…

○10月25日追記
ラジオをかけるとこんな感じです。
娘の小さくなった靴下を履かせてます、製品にはついてきませんので。

• Googleの当面のライバルはYahooと紹介されていた。現在では実際にガチンコ勝負できるのはMicrosoftしか戦える相手がいないように見える。
• Googleはどの道に進んでいくのかと本書の刊行時点では分からなかった。正解はVideo(YouTube)、地図(Google Map/Earth)、写真(Picasa)といったところか。結局昔も今も検索で一本筋が通っているのは変わってない。
• SNSが流行り始めた時期だったから少し触れられていた。実際はOrkutは世界的には流行らず、世界的に流行ったSNSはFriendSterではなくFacebookだった。
• この時点で検索の持つ力は世間に認知されてきていたが、Twitterに代表されるリアルタイム性の概念は無かった。
• Googleは当初から「世界中の全ての情報を整理すること」を目指して設立されたように現在では思えるが、この本を読むと結構場当たり的に進んでいた面が大きかった。

特別目新しい情報は無かったけど、Googleの歴史をリアルタイムで追ってなければ面白く感じるかもしれません。

ProGitの情報によるとリポジトリから取ってくるときをsmudge、リポジトリに突っ込むときをcleanと呼ぶらしい。

以下はリポジトリ内のソースファイルがUTF-8 BOM有、改行コードがLFCRの場合の設定例。文字コード変換はnkfを使っています。
WindowsのVisualStudioに合わせると上記設定が望ましいが、Linux環境でgccを使うにはBOM無しにして、改行コードをLFにする必要がある。
まず.gitconfigファイルに以下を追加する

[filter "fixencoding"]
clean = “/usr/local/bin/nkf -w8 -Lw”
smudge = “/usr/local/bin/nkf -w -Lu”

これでsmudgeでUTF-8 BOM無し/LF、cleanでUTF-8 BOM有り/LFCRとなる。

これだけではダメで、フィルタ処理をかけるファイルを指定する必要が有る。
gitの管理フォルダである.gitがあるトップディレクトリに.gitattributesファイルを以下の内容で作成し、git checkout -fする必要が有る。

*.c filter=fixencoding
*.cpp filter=fixencoding
*.cxx filter=fixencoding
*.h filter=fixencoding
*.hxx filter=fixencoding
*.txt filter=fixencoding
Makefile filter=fixencoding

/usr/share/git-core/templates/info/attributes
を作って上記内容を書いておくとclone時に.git/info以下にコピーされてgit cloneしただけで文字コード変換が動くようになる。

動かすにあたって問題となったのはgitでチェックアウトしただけで編集されたことになってしまうファイルが多々発生したことです。原因はいろいろあったのですが
リポジトリインデックス内のファイル文字コードがバラバラだった(BOM無しファイルが紛れ込んでいた とか)
ファイル内の文字に半角カナがあるとダメらしい。
ファイル内の文字に機種依存文字(実際にあったのは丸数字)があるとダメらしい。

git statusなどで編集が有ったかどうかはインデックス内の状態と比較するからcleanして元々の状態と変わってしまうと当然チェックアウトしただけで編集されたと勘違いされてしまうファイルができてしまう ということですね。
WEB DB Press Vol.50で解説されていたgitの内部データ構造を知ってようやく理解できました。

Subverisonだと文字コードをうまく変換する機構も無いのでgitをかましてやるのが便利ですね。

大学時代から使っていたChangeLogメモとchalowですが、Evernoteを使い始めたところ画像の扱いとかiPhoneとの連携とか便利すぎて気がついたらChangeLogメモがほったらかしになっていました。2箇所にメモが散らばっているのも具合が悪いので思い切ってEvernoteにデータを移行しました。ChangeLogメモ自体は残しておいても邪魔にならないし、Evernoteに何かあってもエクスポートはできるみたいなので多分大丈夫でしょう。

作業手順ですが

1. chalowでChangeLogファイルを変換
2. 不要なHTMLファイルを削除(日別のページとインデックスページだったかな?)
3. EvernoteでChangeLogインポート用のノートブックを作成
4. HTMLファイルをインポート

とやりました。

いくつか手こずったとこもありました。

1. chalowの設定が面倒だったのでRuby実装のrchalowにした
2. MacのEvernoteだとインポートがうまく動かなかったのでWindowsでやった
3. 拡張子がhtmlだとインポートできなかったのでhtmにした
4. ChangeLogメモも変換後のHTMLファイルもUTF-8で統一されていたのにインポートしたら文字化けした。しょうがないのでShiftJISに変換してインポートした

これでメモ環境が快適になりました。

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

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

• 共有リポジトリはSubversion、今後もずっとSubversion
• プログラムはWindowsとLinuxで動くように作ってる、ソースは1種類
• エンコーディングはBOM有のUTF-8、改行コードはLFCR
• LinuxのgccはBOM有だと受け付けてくれないのでビルド前に文字コード変換を挟んでいる
• Subversionのリポジトリは複数プロジェクト共同で、古いリビジョンだと存在しないパスがあったり、パスが途中で変わったりしている

何回かチャレンジしたときはmsysgitを使ってgit svnでのチェックアウトを試みたのですが、昔のリポジトリに同じパスのデータが無いのがまずいのかエラー終了してしまうところであきらめていました。
今回は出たばかりのTortoiseGitのバージョン1系を使い、TortoiseGitで(実際にはmsysgitなんだけど)svnリポジトリからのチェックアウトを試みて、昔のリビジョンだとエラー終了するのを指定リビジョン以降のチェックアウトに限定することで回避しました。

修正や機能追加の際にトピックブランチを作って平行開発、終わったらmasterにマージしてsvn dcommitして共有リポジトリにアップ。こんな流れで周囲の和を乱すことなく開発を進められる所まで来ました。途中gitの意味不明なエラーに遭遇したものの、TortoseGitのバージョンがこなれていくに従って徐々に減っていくでしょう。

gitの使い方はWebとWEB+DB Press Vol.50のgit特集と、オーム社の入門gitを使って勉強しました。Webの情報は古いのが引っかかったり、そもそもズバリな悩みの解決法がまだ見つかりにくく、オーム社の入門gitはリファレンスとしては有用そうに見えるのですが、git stashなど基本的なコマンドの解説が無く、WEB+DB PRESSのが一番使えることに間違いなさそうです。

gitのコミッターが書いた秀和システムの入門gitが先週土曜日に発売されましたが、Amazonからまだ発送されてきません。内容はWEB DB Pressをさらに深くしたものらしいので、日本ではこれが決定版になりそうな気がしています。

WEB+DB PRESS Vol.50 (大型本)
入門git (単行本（ソフトカバー）)
入門Git (単行本)

出来はナイトミュージアムよりいいんだけど、あっちが一般映画の寡作だとしたらこっちの映画は一流のB級映画です。期待してみるとがっかりする人が続出するんだろうけど、夏の深夜放送に流れてるのを偶然みたとしたらすごく楽しめるんじゃないかと。

何映画化のか知らずに見たのですが、アクション映画ですね。ロマンスとかサスペンスとか財宝とか入れてるみたいなんですが、あまり印象に残っていません。

主演のジェシカ・アルバはこの映画によく映えますね。

見終わってなぜかディズニー配給の映画だったっけと勘違いしてしまったけど、20世紀フォックスだった。勘違いしてしまうくらい落ちがハッピーエンドで、子供と一緒に見てもいいなと思う映画でした。序盤は展開がかったるくてどうだかなと思いましたが、博物館の警備員の悪巧みが明らかになってからはあっという間に感じました。

なんでこの映画のAmazon評価が宇宙戦争と星半分しか違わないのか不思議でなりません。

テレビで前にやってたのを録画してみました。自分にとって極度の期待はずれなのか採点不能です。
Amazonのレビューを見ると好意的な人もいるので好き嫌いが分かれる映画なのかも知れません。

宇宙人はがっかり。落ちもがっかり。子役の子は主役のトムクルーズを喰わんばかりの存在感だった。というよりもトムクルーズが役に合わなかったのかもね。

SCMのポーリングが実行
Updating http://example.com/svn-repos/
FATAL: Unable to call getCredential. Invalid object ID 109
java.lang.IllegalStateException: Unable to call getCredential. Invalid object ID 109
at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:268)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215)
at hudson.remoting.UserRequest.perform(UserRequest.java:104)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:236)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)

Windowsのスレーブで1.317から出るようになったみたい。
Subversionのリポジトリをポーリングしてビルドを動かすようにしているけど、出るときとでないときがあります。1回目はエラーがでて、2回目は出ない感じ。何なんでしょう?

・・・

下のスレッドで議論されている内容が原因みたい。斜め読みだけどSingletonの使い方がおかしいのかな?
Nabble – Hudson dev – Error in SubversionSCM “Unable to call getCredential”
このnabble.comってのはどんなサイトなんだろう? 修正パッチも有ったみたいだけどHudsonのMLには同様の情報は流れてないのかな。

・・・

よくHudsonのバグリストを探してみたら見つかった、これな気がする。
hudson: 課題 4176
現在もステータスはOpenになってるし、問題として認識されているんだろう。
個人的には毎日何回もエラーメールが飛んできて困るので2票ほど投票してみた。結構根が深い問題なのだろうか、気長に待とう。

こちらも全11巻とちょうどいいサイズだったのでサラリーマン金太郎とセットでレンタル。少し前にドラマがありましたが、原作もなかなか楽しめます。どこで仕入れた情報か忘れてしまいましたが和製24といった内容です。息つく暇もなく状況が入れ替わるサスペンスが楽しめます。

週刊少年マガジンに連載されているからかしょうがないのかもしれないけど、話がせっかく作り込まれてるんだからよくわからない描写(お色気シーンみたいのね)はもっと削った方がいいのになと思いました。

10月から第２部が連載されるそうです。続きが気になるから全部コミックになってから読もうかな。

全５巻とちょうど休みに読み切りやすいサイズだったのでツタヤでレンタル。1巻から始まるテレビ局買収の下りは連載で読んだ記憶があったのですが、このプロローグを読んだ記憶が全くなかったので不思議に思っていたのですが、これはダウンロード版として用意された物をコミックとして出版したそうです。

内容はマンガとして面白いのですが、もうサラリーマンに全く思えません。アラビアのオイルマネーを個人で引っ張ってくるとかね。

ここまでの流れは

• 9月5日にヨドバシで購入
• 9月5日の夜にインストール開始
• インストールが始まった後にメディアが読み込めないとエラーが出てインストールできず
• 9月6日にアップルのサポートへ電話
• 症状を話すとDVDのメディア不良なので代替品を送るとのこと、海外から!!!
• 9月15日にようやくDVDが届いた！まさかの船便だった?

ということで、長い道のりでした。

インストール自体は1時間もかからずに終了。どこが変わったのか分からないぐらいですが、初めてのお布施は何とも手間がかかりました。メディアの初期不良なんて初めて聞いたよ。

ネットで同じ症状の人を捜してみると、ファミリーパックの購入者に多いようです。自分が買ったのはシングルライセンス版だったのですが、これから買う人ははずれもあることを覚悟した方がいいかもしれませんよ。

これもお盆休みに買ってたんだけど書いてなかったので。

価格.comで最安値となっていた在庫処分品を68000円で購入。少し前にHF21が出てたけど、内部メモリの差以外に優位な差がなかったので型落ちの方を選択。普通に撮る分にはまず容量に困らないし、最悪SDカードがさせるので少し長い旅行に持っていっても大丈夫そう。

実はWindowsしか対応が明記されてないんだけど、iMovie08で問題なくデータを吸い出せました。
AppleのHPにもiMovieのビデオカメラ対応状況が載っているんですが、このカメラが載ってなかったのでちょっとドキドキでした。カメラメーカーからもAppleに積極的に情報を出してくれたらいいのに。

お盆休み前に読み終わってたんだけどブログを更新していなかったので。

「振り返り」時に使える技法を効果とともに紹介／解説してくれている。最初に効果的な振り返りの流れを定義した後、問題の抽出、解決のためのアイデア出し、チームとしての方針決定などで使える事例がたくさん載っています。自分たちでやり方を考えるのは大変だし、どういうときに効果があるのかもやってみないと分からないのが解説されているのはいいかも。

Pragmatic Programmer(達人プログラマー)シリーズの一冊だけど、プログラムの話はいっさい出てきません。業務全体に活用できる話かも。

○第１４章　継続的改良
コマンドライン引数を解析するArgsクラスを題材に著者がリファクタリングをしていく過程を追体験できる。
最初に最終結果が提示されたため、それがスタート地点かと思ってびっくりしたが実際は真逆だった。
最初に最終結果を見せなければもうちょっと追って見る気力が出てきたのに。

○第１５章 JUnitフレームワーク
JUnitに対して著者がリファクタリングをしていく過程を追体験。
特記事項は無いので割愛

○第１６章 SerialDateのリファクタリング
OSSのライブラリに対して著者がリファクタリングしていく過程を追体験。
特記事項は無いので割愛。

○第17章　においと経験則
筆者によるチェックポイントのまとめ、よくまとまっていて、レビュー時に使えそうなので全て写経!

• 不適切な情報: 作者、更新日、更新履歴は不要
• 退化コメントを削除：コメントは陳腐化するのでいらなくなったらこまめに削除
• 冗長なコメント
• 記述不足のコメント
• コメントアウトされたコード：読みにくくなる以外の効果は無い
• ビルドに複数のステップを要する：1操作でできるべき
• テストに複数のステップを要する：1操作でできるべき
• 多すぎる引数
• 出力引数：オブジェクトの状態を積極的に変更する
• フラグ引数：2つの関数に分けよう
• 死んだ関数：呼ばれてない関数は削除する
• 1 つのソースに複数言語を混ぜない：コメントにHTML形式のレイアウトを入れない とか
• あって当然の振る舞いが実装されてない：大文字／小文字の区別とか
• 境界値に対する不正確な振る舞い：きちんとテストすること
• 安全軽視：コンパイラの警告はきちんと対処する
• 重複：DRY! Once and only once
• 抽象レベルが正しくないコード
• 継承クラスに依存したクラス
• 情報過多：メソッドは少ないほどいい、インスタンスは少ないほどいい
• デッドコード：決して通ることが無いif文は無いか、カバレッジ計測ツールで確認
• 垂直分離：変数宣言は使用場所の近くで
• 不整合：規約の選択は慎重に、決めたらコロコロ変えない
• 雑然：未使用変数、意味が無いコメント、呼ばれない関数は削除する
• 人為的な結合：意図の無い結合は避ける
• 機能の羨望：実装を他のクラスにさらすべきではない
• セレクタ引数：小さな関数に分割しよう
• 不明瞭な意図：計算過程を変数名で説明するとよい
• 責務を持たせる場所の間違い：直感的にあるべき場所に置く
• 不適切なstatic
• 説明的変数を積極的に使う
• 関数名は名は体を表すべき
• アルゴリズムを理解する
• 論理的な依存性を物理的なものとする
• if/else, switchよりも多態を使う
• 標準規約に従う
• マジックナンバーを定数化する
• 正確であること
• 規約より構造
• 条件をカプセル化する
• 条件の否定形を避ける
• 関数では1つのことに集中する
• 隠れた時間軸上の依存関係を見えるようにする
• いい加減にならないこと：矛盾が生じないように
• 境界条件はカプセル化する
• 関数は一つの抽象レベルを担うべき
• 設定可能なデータは高い抽象レベルに置く
• 推移的なナビゲーションを避ける
• 記述的な名前を選ぶ
• 抽象レベルに適切な名前を選ぶ
• 可能な限り標準の用語を使用する
• はっきりした名前
• 広いスコープには長い名前を割り当てる
• エンコーディングを避ける
• 名前で副作用をあらわす
• 不十分なテストを避ける
• カバレッジツールを活用する
• 些細なテストを省略しない
• 境界条件をテストする
• バグの周辺は徹底的にテストする
• 失敗パターンの傾向に着目する
• テストは高速に実行できるように

これで400ページ弱の本が読み終わったー！

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

直接使うのではなく、ラッパを一つかませると良い。使用者側は特定のニーズに特化したインターフェースを求めるが、ラッパがあれば万事解決。
外部コードをつなぐときには、テストコードを先に書くと振る舞いの勉強ができ、かつ次回以降のアップデートでテストケースができるためオススメ。こうしたテストには「学習テスト」という名前があるらしい。

よい設計は過大な投資ややり直しを求めること無しに変更への対処を可能とする。自分たちのコードの広範囲が3rd partyの実装詳細に関する知識を持たないようにする。

○第９章　単体テスト
テスト駆動開発(TDD: Test Driven Development)の3大原則

1. 失敗する単体テストのコードを書く前に製品のコードを書いてはならない
2. コンパイルが通り、適切に失敗する単体テストができるまでは次の単体テストを買いてはならない。
3. 現在失敗している単体テストが通るまで、次の製品コードを書いてはならない。

テストコードと製品コードはほぼ同時に書く、テストコードの方が数秒先行するだけ。
きちんとやればテストコードの行数は製品コードの量に匹敵し、管理上の問題が必要になるぐらいのはず。
(同じぐらいの分量だと足りない気もするんだけど、適切な量はどれぐらいなんだろう・・・？)

テストも製品コードと同等の品質基準に従うべき。きちんとメンテナンスされ続ける必要がある。
テストがメンテナンスされてないと、新規コードを書く時間よりテストコードを書く時間の方がかかるようになってしまい、テストがされなくなってしまう。結果製品コードも腐ってしまう。

単体テストが以下の性質を実現する。

• コードの柔軟性
• 保守容易性
• 再利用性

テストがあれば変更を恐れずできる。
テストに重要なのは何を置いても「読みやすさ」である。
製品コードほどの実行効率は必要ないことに気づく。読みやすさの工夫の余地が広がるはず。

きちんと整理された1つのテストは「構築ー操作ー検査」のパターンに合致するはず。
1つのテストでは1つの概念を扱う。
クリーンテストはF.I.R.S.T.の規則に従う

• Fast: テストは高速に実行できる
• Independent: テストは互いに関連しない。
• Repeatable: 再現性がある。
• Self-Validating: テストの結果は成功か失敗か明確に判断できる。
• Timely: 必要なときにすぐ書ける。

○第１０章　クラス
クラスは小さくなければならない。行数ではなく、1つのクラスが担う責務に着目して測るのが重要。
クラス名は責務を表した名前を付け、実装は単一責務の原則(SRP: Single Responsibility Principle)に従うようにする。
責務に着目するとクラスの分割がやりやすくなる。

クラス内のメソッドが操作する変数が多い方がクラスの「凝集性」が高い。
凝集性が高いとメソッド変数は互いに依存し合っていることになり、全体として1つのロジックをなすようになる。

○第１１章　システム
システムレベルでもきれいな状態に保つことは大事。
依存性注入(Dependency Injection)を考慮したフレームワークを使うといいよ。

最初から正しいシステムというのは神話、適切に関心ごとを分離して保守していくことでアーキテクチャも改善していくことができる。

モジュール化と関心ごとの分離は管理と意思決定を延期することができ、一般的に後で決断をする方が最善の情報に裏付けられた決断を行うことができる。

○第１２章　創発
単純な設計のための4つの規則

• 全テストを実行する
• 重複が無い
• プログラマの意図が表現されてる
• クラスとメソッドを最小化する

・全テストの実行
システムがテスト可能でなければ検証可能でない。
SRPに従ったクラスはテストも容易。
システムを完全にテストしようとすると依存性注入などのテクニックが自然と使われるようになり、より優れた設計を生み出してくれる。
コードを壊す恐れが減るため、リファクタリングも思い切ってできる。

・重複の排除
重複は余計な作業、余計な危険、不必要な複雑さを引き起こすため悪である。
大きな再利用を実現するため、小さな再利用を理解することが大事。

・表現に富む
書き手の意図が明快であるほど、別の人が理解しやすくなる。
書いた本人が書いた時点で理解できるのは当たり前、なぜなら解く対象の問題を深く理解しているから。
ソフトウェア開発の大半は保守なのでメンテナンスのしやすさの方が大事。

表現に富んだコードを書くには以下が重要

• よい命名
• 関数とクラスを小さく保つ
• 標準の用語(デザインパターンとか)を使う
• 単体テストで使用例を文書化する

・クラスとメソッドを最小限にする
規則の中でも最も優先順位が低い。最小限にするあまり実際的でないルールや実装を行ってはならない。

○第１３章　同時並行性
きれいな同時並行プログラムを書くことは困難を極める。

• 同時平行性は常にパフォーマンスが改善される訳ではない。待ち時間が大量にあって、複数処理で共有できる場合のみ。
• 同時並行プログラムはシングルスレッド時とアルゴリズムも設計も違ってしかるべき。
• 同時並行性の実現には余分なオーバーヘッド、複雑さを伴う。
• 同時並行性のバグは再現性がない。

それでも同時並行性が必要なときは以下の点に留意する。

• 単一責務の原則を守る。同時並行性に関するコードは他と分離する
• データスコープを限定する。クリティカルセッションの数を抑える
• 可能な場合はデータのコピーを利用する。
• スレッドはできるだけ独立させる。

同時平行性の大抵の問題は以下のいずれかか、組み合わせで表現できる。

1. プロデューサー／コンシューマー：キューを使ってジョブをやりとり
2. リーダー／ライター：飢餓状態、古い情報の集積、スループットの低下など問題が多い
3. 食事する哲学者の問題 – Wikipedia

問題を早期に発見して作り込まないようにする。

• 怪しい問題があったらスレッドを疑う
• 最初にスレッド化されないコードを完成させる
• スレッド化されたコードの実行条件は変えられるようにする
• プロセッサの数よりもスレッド数を多くしてテストする
• 異なるプラットフォームでテストを実行する。

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

公開時から評判が良かった映画ですが、子供が生まれた時期と重なって映画館に見に行くことができなかったのでようやくDVDで鑑賞。予想以上の内容で90分間飽きること無く楽しむことができました。

序盤はほとんど会話も説明も無いものの世界観や、WALL・Eの心情が伝わってきて、PIXARが映画を作るとなんでこうなるんだろうと関心しきりです。娘はほとんど興味を示しませんでしたが、そのうち何度もせがまれてみることになる気がします。

来週はポニョのDVDが発売されるようですが、こっちも楽しみですね。

ShureのE3Cを長年使ってきましたが、右耳が断線気味なことと、iPhoneがBluetooth対応したことと、そしてShureのイヤホンを紛失してしまったためイヤホンを新調しました。悩みましたがソニーエリクソンのものにしました。いつものプラグがついているので、最悪自分好みのイヤホンに差し替えられるのもグッドです。

早速MacbookとiPhoneでペアリングして使えるようにしましたが、思っていたよりも音がよく、非常に満足しています。
マイクも試してみましたが、歩きながらの電話も難なくこなせそうです。

あるならShureかBOSEのBluetoothヘッドセットを選びたかったところですが、現段階でベターな選択ができたと思います。

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

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

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

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

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

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

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

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

言い換えると

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

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

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

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

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

いつからこの問題が起きていて、原因もはっきり分からないのですが、一応解決を見たので参考にしたサイトを載せておきます。

まず、真っ白に表示される原因はXREAのPHP動作モードにあるらしく、 WordPressサイトが真っ白 | fusigineko blog / KANADA Co.,Ltd.を参考に、WordPressのトップディレクトリにある.htaccessを修正しました。

これでページは表示できるようになったのですが、WordPress 2.8が悪いのか管理画面にCSSが適用されなくなりました。 WordPress › フォーラム » WP2.8Jの管理画面のCSSがSafariでは適用されないにある

define( ‘CONCATENATE_SCRIPTS’, false );

をwp-config.phpの上の方に定義することで対処できました。後者の問題はそのうちWordPressがアップグレードされてなおることでしょう。

こういうトラブルあると独自ドメインのブログなんてやめたくなりますね。

○第２章　意味のある名前
いい名前を付けるには時間がかかるが、より多くの時間をあとで節約できる。
以下の命題に答えられる名前を付ける。

• なぜ存在するのか
• 何をするのか
• どう使用するのか

嘘の情報や、紛らわしい名前はさける。具体的には”意図した意味以外に使われる名前”は避ける。例えば配列名にAccountListと名付けるとList構造で実装されていると連想させてしまう。(よくこういう名前を付けてるけど混同したこと無いな・・・)

• 意味が無い名前も避ける、例えば一般的すぎる”Info”や”Data”。
• 発音できない名前は使わない。
• 検索可能な名前を使う。
• メンバ変数にプレフィックスは不要。
• ハンガリアン記法もコンパイラの方が賢いので不要。
• 解決する問題領域の用語を使う。用語集や語彙集があるといい。
• 当たり前のことだけど変数名には”名詞”、関数名には”動詞”

(最近は長い名前の変数名も使うようになった気がする。省略形をうまく作ったつもりでも引き継げないことの方が多い。
システム全体で用語集/語彙集を作っておくというのはいいかも。作ったときはコード規約に入れておくといいのかな?)

○第３章　関数
関数の原則は”小さくある”こと。一つの関数では一つのことだけを行い、それ以外のことを行わないこと。この原則に従うとif/else文やwhile文のブロック行は１行になり、関数の中にはネストされた構造も登場しなくなる。
関数の実装から別の関数を抽出できるか調べることで、関数が一つのことに集中しているかどうかを調べることができる。

関数は抽象レベルが高いものを先に記述する。こうすることでコードを物語のように読むことができる。(1ファイル中の並びはアルファベット順でいいのかと思ってた。確かに抽象度順がいいかも。)

関数の引数は0が理想、3以上は避けるべき。オブジェクトの状態を変更するようにコードを書くことで、0引数の関数が実現できる。あわせて出力先を引数で受け取るのも避けるべき(C言語ではこれは無理だ・・・)

例外を多用する、戻り値でエラーコードを返さない。エラーコードを使うとすべてのファイルが特定のエラーコードが記述されたファイルを参照するようになり、そのファイルの修正がしにくくなる。
try〜catchでエラーを補足するのも１つの処理になるので、エラーを補足する関数も別途分ける。

• 副作用をさける。
• 処理を行う関数と、応答を返す関数は分ける。
• 最初から完璧な関数が書ける訳は無い。

○第４章　コメント
「ダメなコードをコメントで取り繕っては行けない。書き直すのだ。」
適切なコメントのあり方は、コードでうまく表現することに失敗したとき、それを補うのに使うこと。

コメントのしようがダメな理由は
古いコメントはメンテナンスされる保証が無い。
コメントを書く労力はコメント無しでコードを明確化する努力に当てるべき。
不正確なコメントがあるぐらいなら無い方がマシ。
書かずに済むコメントよりも良いものは無い。

必要なコメントもある

• 著作権／著作者の表示
• 意図の説明
• 曖昧な引数・戻り値の明確化
• 結果に対する警告(この処理はスレッドセーフじゃないとか)
• TODOコメント

ダメなコメントの例

• プログラマの独り言、コードの他の箇所も理解していないと意図が分からないようなもの
• 冗長なコメント(以下はデフォルトコンストラクタ とか)、コードの処理以上に説明しているコメント
• 変更記録 → ソースコード管理システムに任せましょう
• 閉じ括弧コメント→括弧の対応が1画面内に収まるぐらいに整理する

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

あまりネット上に言及している記事が無いので自分の勉強がてら勉強したことを書いていくことにします。続くと思います、多分。

○前書き
ソフトウェア開発では小さなことこそが重要。
建築家はきちんと閉まらないドア、曲がった床のタイル、汚れた机をよしとするか？
「神は細部に宿る」

5S原則はソフトウェア開発にも当てはまる。

• 整理：どこに何があるかを把握する。名前付けはきちんとできているか。
• 整頓：コードは読む人が”ここにあるだろう”と推測した場所にあるべき
• 清掃：コードをコメントアウトで汚してないか
• 清潔：コーディングスタイル、仕事の進め方
• しつけ：変革を厭わない姿勢を持っているか

設計に終わりは無い。常に元あった状態よりも良くしてチェックインすること。
ソフトウェア開発における改善(リファクタリング)はコストではなく、価値につながる。

○序論
職人技の習得は

• 職人に必要な知識を得る(原則、パターン、経験則)
• 知識を咀嚼して自分のものとする

からなる。
クリーンコードを書くには努力が必要。経験則とコードを洗練してく過程で行った判断が何よりも重要。

○第１章 クリーンコード
要件を詳細に定義し、機械に実行可能なものとするのがプログラミングであり、コードである。
よく定義された要件はコードと同じ、常にコードは必要である。

粗悪なコードはコードを追加／修正するのに必要なコストが結局高くつき開発スピードが遅くなって管理できなくなってしまう（ウェーディング(wading)と言うらしい)
プログラマはコードのプロなので、混乱のリスクを理解できない管理者に屈服してはならない。

きれいなコードを「読める」のと「書ける」のには大きな差がある、センスが重要。クリーンコードの定義は人により異なるが、以下の要件を満たすものが挙げられることが多い。

• エレガントであること
• 明快な抽象化、まっすぐな境界線
• 原作者以外でも読め、拡張ができる
• 誰かが気配りを持って書いたコード
• テストがあり、重複が無く、システムの知識が表現されている

クリーンコードにも流派があって当然で、この本で紹介しているのは流派の1つに過ぎないことを頭に留めておくことは大事。

Clean Code アジャイルソフトウェア達人の技

posted with amazlet at 09.06.04

Robert C. Martin
アスキー・メディアワークス
売り上げランキング: 5682

Amazon.co.jp で詳細を見る

Amazonはこの対極にある気がするな、ポストに本が刺さっているときもあるし。

家電批評のムック本を本屋で見かけて衝動買いしてきました。ずば抜けた歴史に残る家電 ”神機” を扱っています。以前の雑誌記事をつなぎ合わせた感じも否めませんが、まとまっていて保存するにはこっちの方が便利かもしれません。

コメントで初めて知ったのですが、もうこのモデルは廃盤なんですね。結構気に入って買ったデザインなので修理してでも大事に使わないと。

買ってきたのはノーマルのドーナツにさとうきびにごまの3種類です。小さく見えるドーナツですが、2つも食べるとお腹が結構ふくれます。食感はミスタードナッツのポンデリングのように柔らかく、あれよりも噛み切るときにしっかりとした感じが残ります。好き嫌いが出る味かもしれませんが、自分と妻はとても美味しくいただきました。

このドーナツは豆乳とおからが原料に加えられているそうです。美味しかったのでまたぜひ買いにいこうと思います。

• はらドーナッツ：神戸発・話題の「安心おやつ」

まず最初が自動アップグレードができなかったことです。管理画面にログインする度に本体とプラグインのアップグレードを促されるとうんざりしてしまいます。WordPressは2.7以降自動アップグレードシステムがあるのでこれをXREAのサーバで動かすようにしました。
Google先生に聞くとすぐ見つかるのですが、アップグレードをおこなうPHPスクリプトをSAFEモードで動かす必要があるそうです。
作業としてはwp-adminディレクトリに.htaccessファイルを作成し

<Files upload.php>
AddHandler application/x-httpd-phpcgi .php
</Files>
<Files update.php>
AddHandler application/x-httpd-phpcgi .php
</Files>

を追加します。

次にWordPress用のFTPアカウントをXREAの管理画面で作成します。これはFTPのログインディレクトリをWordPressのログインディレクトリにするためです。WordPressだけを動かしているなら必要ない作業ですが、大抵の場合は必要なはずです。

最後に画像のアップロードに失敗していたのでwp-content/uploadsディレクトリの書き込み権限を777に変更しました。これもSAFEモードが関係しているのですが、Googleで調べてみたところ事前にアップロードフォルダを手動で作っている人が多かったのですが、毎回そんなことをするのも面倒だったので、アクセス権を緩くして対処した次第です。

これでようやくまともに使えるようになりました! これで更新のペースが上がるといいんですが。

動物園に行くのは旭山動物園以来、関東に限定すれば上野動物園に行って以来かなり久しぶりです。この動物園は園内の雰囲気がとても良かったです。園内に入って最初に見れるのが象なんですが、森の中を歩いているような感覚になります。散歩としては広さも十分だし最高です。

残念だったのがあまり動物が見れなかったことです。どの動物も死角に隠れてたり、そもそも檻にいなかったり、人が多すぎて檻に近づけなかったりで、ほとんど動物が見れませんでした。それでも久しぶりのお出かけに満足です。

この動物園の目玉はオカピですが、これだけはしっかり見ることができました。ただオカピのいるところが動物園の入り口から最も遠いところで、つくまでに疲れてしまうのが玉にきずです。

次は娘が一人で歩けるようになったぐらいに行こうかな。

他にも数冊渡したはずで、全部は思い出せないのですが思い出せる限りでオススメの本をあげておきます。

C言語ポインタ完全制覇 (標準プログラマーズライブラリ) (単行本)

↑多分渡して一番役立った本です。研修でポインタを教わってもどう使っていいのか分からないのが新人の常なので適切な問題(ポインタに絡む実装や修正の依頼)とセットで渡してあげると効果が倍増するはずです。

定本 Cプログラマのためのアルゴリズムとデータ構造 (SOFTBANK BOOKS) (単行本)

↑またはプログラミングの宝箱 アルゴリズムとデータ構造 (C magazine) (単行本)でもいいかも。
下手な研修だと木構造とか文字列検索とか教わってこないので素養としてこれぐらいは読んでおいて欲しいかも。

ライト、ついてますか—問題発見の人間学 (単行本)

↑実際には渡せなかったけど、あるならこれも渡したかった。
元ネタにはワインバーグの本は無かったけど、著者買いしてもはずれが少ない人だと思います。

我らクレイジー☆エンジニア主義 (講談社BIZ) (単行本)

↑最後は趣味、仕事に望む気持ちの持ちようとして希望に燃える新人にはいい刺激になるかも。

他にもいい本はいっぱい触れてきた気がするんですが、いざまとめるとなるとなかなか出てきませんね。

VMWare Server2からはWebインターフェースで仮想マシンにアクセスする仕様になってますが、裏ではTomcatが同梱され動いているようです。んでHudsonを動かすTomcatとVMWare Server2が使うTomcatが何らかの原因で共存できなくて問題が起こったようです。

本当は○○すればこの問題は解決します とまで調べて書きたいのですが、他の業務に押されて調べきれず、結局VMWare Serverのバージョンを元に戻してしまいました。

Javaが得意な方で、どの辺の設定をいじれば良いものか検討がつく方はいましたらコメントで教えてください m(_ _ )m

Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

posted with amazlet at 09.03.22

Jared Richardson William Gwaltney Jr. でびあんぐる
オーム社
売り上げランキング: 52053

おすすめ度の平均:

実践的です。実用で鍛えられただけあります。
行動を起こすための実用書

Amazon.co.jp で詳細を見る

1月の下旬から2月に読んだ本なんですが、感想を書き忘れていました。

達人プログラマシリーズの1冊ですが、前に読んだ”アジャイルプラクティス”の方が個人的にはお気に入りです。自分にとって既知の内容が多かったからかもしれません。

次は”Manage It!”か”Release It!”を読みたいと思っています。

Where Is the Green Sheep (Horn Book Fanfare List (Awards))

posted with amazlet at 09.03.22

Mem Fox
Harcourt Childrens Books (J)
売り上げランキング: 150683

おすすめ度の平均:

Here is the XXX sheep.が25回。

Amazon.co.jp で詳細を見る

会社でお世話になっているオーストラリアの研究所の方から出産祝いに貰った絵本です。
平易な英語で、いろいろな羊の絵が書いてあります。
うちの娘は色使いがきれいな”bath sheep(お風呂に入っている羊)”が好きみたいです。

オーストラリアでは有名な絵本らしいのですが、こういうプレゼントはうれしいですね。

大げさなタイトルをつけましたが、我が家も超音波歯ブラシのソニックケアを購入しました。妻の強い要望で買いましたが、大正解だったと思います。

毎年の歯科検査でブラッシングの不十分を指摘される自分ですが、ソニックケアを使うと簡単に、短時間で磨き残しを減らすことができます。これなら今年の歯科検査は大丈夫そうです。一時は毎晩15分ぐらい磨いてみたこともありましたが、さっさとソニックケアを買っておくべきでした。

これで歯が健康になるならすぐもとがとれそうです。人生が変わるほどの家電はそうそうないと思いますが、自分はこの歯ブラシを買ったことで、歯の健康状態をよく保てそうです。

クレイマー、クレイマー [DVD]

posted with amazlet at 09.02.07

ソニー・ピクチャーズエンタテインメント (2007-04-04)
売り上げランキング: 2405

Amazon.co.jp で詳細を見る

子供が生まれる前に見た。
子育てに悩み始めた頃に見たらまた違った印象を受けるかもしれない。
子供のためにクリスマスの日に必死に仕事を探す父親の姿がよかった。

サハラ -死の砂漠を脱出せよ- [DVD]

posted with amazlet at 09.02.07

アミューズソフトエンタテインメント (2005-10-21)
売り上げランキング: 18019

Amazon.co.jp で詳細を見る

ペネロペ・クルス主演の砂漠でサバイバルを繰り広げるドラマかと思ったが、一緒にパッケージに映っている男性が主人公の冒険活劇だった。よくあるアメリカのアクション映画 といった感じ。

犬神家の一族　通常版 [DVD]

posted with amazlet at 09.02.07

角川エンタテインメント (2007-07-06)
売り上げランキング: 11183

Amazon.co.jp で詳細を見る

有名な推理ものですが、人生初でした。最後まで犯人が分からなかったので見ていて普通に楽しめました。

シックス・デイズ・セヴン・ナイツ ― オリジナル・サウンドトラック

posted with amazlet at 09.02.07

サントラ
カッティング・エッジ (2001-10-24)
売り上げランキング: 414192

Amazon.co.jp で詳細を見る

DVDが発売されてないのかな?
B級映画ですね。
ハリソンフォードは登場時と最後で全然キャラが違ってたのが印象的でした。

工事が終わって無線LANの設定をしていてはまったのですが、J-COMの160MBコースは1台のPCしか接続を許していないため、設置する機械に妙な制限がかかっています。具体的には接続した機器の情報(具体的にはMACアドレス)を2台までしか記憶できず、3台目以降に接続した機器ではネットにつなぐことができない というものです。

工事の人が回線テストをして1台目、自分が有線LANでつながることを確認して2台目、無線LANにするのにルータをつなぐと3台目になるのでどうあがいてもネットワーク設定を取得できずはまってしまいます。どの資料を見ても載っていないため、詳しい人ほどハマりそうです。

自分はサポートセンターに電話して解決しました。ネットで原因を探していたときにこのことに触れてるブログが見つからなかったのですが、みんなハマらなかったのかな?

• Hudson 1.271以降で追加された機能 – ssogabeの日記

前に書いた不満点に

• マスタにラベルが割り振れない
• Windows 64bitでサービス登録できない

の2点がありましたが、2点とも今回のリリースでなおっているとchangelogに記載がありました。

マスタにラベルを振る機能は自分が望んでいた通りのものでした。WindowsとLinuxを混在させた環境を作るためにマスタで直接実行するのをさけ、あえてslaveとして登録させていましたが、この設定は早速削除しました。

もう一点の64bit Windowsでのサービス登録はやっぱりうまく行きませんでした。エラーのスタックトレースはこんな感じでした。

java.io.FileNotFoundException:

http://example.jp:8080/jnlpJars/remoting.jar

at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown
Source)
…

HudsonのURLが

http://hudson.example.jp:8080

ではなく

http://example.jp:8080/hudson/

なので、どうも要求しているリソースのURLがあってない気がします。これも登録済みのバグなのかな?

2009年1月21日追記
Hudson 1.277でなおったようです。無事に64bit Windowsでもサービス登録できました。
VistaだとUACが悪さをして登録できないようですが、一時的にUACを切ればいけます。

今日0.8にアップグレードして気がついたのですが、チケット一覧を表示するページで右クリックが使えるんですね。所定のチケットの優先順位や状態などを一括して変更できて非常に便利です。

JavaScriptで実現しているんだと思うのですが、最近のWebアプリはすごいですね。

子供が吐き戻し(ミルクの飲み過ぎ)で元旦早々検査入院になるなど慌ただしい年末年始を過ごしていました。

娘はとても元気で入院してもけろっとしています。隣人から騒音の苦情がくるぐらい元気で(過ごし方を考えないと立ち退かなくちゃいけなくなるorz)、色々と手がかかりますが子供がいなかった頃とは違った幸せを日々実感しています。

本年もどうぞよろしくお願いいたします。

色々と書きたいことはあるのですが、眠くて仕方ないのでまた日を改めて。

○追記
すごく心に残るエントリをたまたま目にしたのでメモ
いまをきみが忘れても – tapestry

調べていくとfloatを使った浮動小数点演算で誤差が出ることがわかりました。分からなかったのが、IEEE754でfloatの演算精度は32bitと規定されているのになぜ同じソースから作ったプログラムで結果が違うのかということです。

x86では浮動小数点演算にx87を使うのですが、この演算精度は32bitや64bitではなく、80bitで行われるそうです。この辺の話は 浮動小数点演算ではまった話 – bkブログとかBK通信に詳しく載ってます。要約すると32bitの精度で誤差が生じる計算が含まれていても”たまたま”うまく計算できることがある ということです。

たまたま精度よく計算できるプログラムをx86_64に持っていってコンパイルしようとします。このとき、x86_64では必ずSSEが使えるため、コンパイラはデフォルトでSSEを使うようにコンパイルします。SSEで浮動小数点演算を行うと演算精度がx87の80bitよりも悪くなるため、本来生じるはずだった演算誤差が表面化することになります。

高林さんがBK通信で書いているMac OSで演算結果が違うというのも、Mac OSが64bitOSであることが関係している気がします。

バイナリーハックス買おうかな。

Binary Hacks ―ハッカー秘伝のテクニック100選

posted with amazlet at 08.12.09

高林 哲 鵜飼 文敏 佐藤 祐介 浜地 慎一郎 首藤 一幸
オライリー・ジャパン
売り上げランキング: 23306

おすすめ度の平均:

ハードコア？なソフトウエア
大工さんにおける電動工具の紹介本
当然教科書ではない。でも、とても参考になります。
バイナリアンの基本

Amazon.co.jp で詳細を見る

ゴーストシップ 特別版 [DVD]

posted with amazlet at 08.12.09

ワーナー・ホーム・ビデオ (2006-07-14)
売り上げランキング: 121471

おすすめ度の平均:

女は強いね
ケナゲな美少女の幽霊に感動
殺戮シーンの映像美

Amazon.co.jp で詳細を見る

久しぶりにすげーB級映画に出会えた! 必見ではないけれど、期待しないでみると結構楽しめると思う。
序盤はゆっくりだけど、最初の犠牲者が出てからの展開は早く、あまりにも予想外な結末にびっくりします。

映画館で見たらいろいろ消化不良ですが、ネットで情報を入れながらDVDを見ると楽しめるんじゃないかと思います。

参考
ゴーストシップ＠映画の森てんこ森
ネタばれ注意! ゴーストシップ – あの映画のココがわからない

子供につけようと考えてる”優菜”は22位だった、漢字が違う”優奈”だと12位。
全体的に今風の名前なんだけど、男の子の方は著名人にあやかってつけるのが少なくて、女の子の方は逆に著名人にあやかるのが多い気がする。
男の子だったら、今年なら”遼”あたりランクインしても良さそうなのに入ってない。そういえば自分の時は”大輔”が多い世代だったが、これもランクインしてないようだ。
女の子は”結衣”に”さくら”に”美咲”、”真央”、”夏帆”、”愛”、”桃子”、”あおい”とか著名人の名前が連想できるものが多い。

自分の娘はいよいよ今週末が予定日だ。無事に生まれてきますように。

発売されてからなかなかAmazonから届かなかったのですが、先週の中頃手に入れてようやく読めました。
リファレンスとしては丁寧によく書かれていますが、「これは知らなかった」とか「これはWebでは知ることができなかった情報だ」というのは特にありませんでした。内容としては著者が管理している Redmine.JP | TOPにある情報+RedmineのMLのまとめ のような印象です。新しくRedmineを使い始める人に「分からなかったらこれで調べて」と渡すのに便利な本です。
自腹で買った私本ですが、会社に置いてます。家にあっても使いようがなさそうなんで。

Trac本も何冊か出ていますが同じような感じなんでしょうか?　Redmine使いが増えて、もっと使いこなしに関する情報が出てくるようになるといいんですけど…　とりあえず近日中にリリースされそうな0.8に期待です。

マイアミ・バイス (ユニバーサル・ザ・ベスト第8弾) [DVD]

posted with amazlet at 08.12.05

ユニバーサル・ピクチャーズ・ジャパン (2007-09-13)
売り上げランキング: 1907

おすすめ度の平均:

見ごたえ無いって訳じゃないけど
初めがおとなしすぎて…
期待して見たけど
マイアミのバイスさん
マイアミ！

Amazon.co.jp で詳細を見る

木曜洋画劇場で放送されているのを見ました。レジェンド・オブ・ゾロも消化不良でしたが、この映画も同じく消化不良で終わりました。刑事の潜入捜査を描いた作品ですが話についていけなかったり(なんで主人公らを悪役たちが信用しちゃうの とか)、主人公の行動が理解できなかったり(なんで敵組織の女に入れ込んでるの? お色気シーンいらないし)、原因はいろいろあるのですが、緊張感の無さが一番の原因かもしれません。

レジェンド・オブ・ゾロ コレターズ・エディション [DVD]

posted with amazlet at 08.12.05

ソニー・ピクチャーズエンタテインメント (2007-02-28)
売り上げランキング: 59910

おすすめ度の平均:

…
バンデラスかっこいい〜
現代版ゾロ
小学生の中学年までなら楽しめる

Amazon.co.jp で詳細を見る

前作と変わらず、バンデラスのアクションシーンはかっこいいんですが、何かイマイチでした。
ストーリーが悪いんですかね。

この日記を書いてて気がついたんですが、月曜日に見た映画「フィラデルフィア」に出てくる、トム・ハンクス演じる弁護士の恋人(ゲイを描いた映画なので、恋人が男性)がアントニオ・バンデラスだったんですね。言われてみれば確かにそうかも。同じ人に見えません。