◯1日目 8/6

9時55分発の便で香港へ出発。午後から出社のためビジネスクラスを満喫(お酒を飲む)出来なかったことが残念。
香港は思っていたほど暑くない、クーラーがあちこち効いている分、日本より過ごしやすいかもしれない。炎天下の中外を歩き続けなければ気にならないレベル。

社員のみなさんに英語で挨拶して、夜は歓迎会を開いてもらう。来週からの駅までの行き方を教えてもらいつつオクトパスを購入。これは日本のSuicaに当たるカードで、香港では1種類しか電子マネーが無いらしい。これひとつで電車もバスもタクシーもフェリーもコンビニも何でも使えるのでかなり便利。

◯2日目 8/7

朝起きてとりあえず会社に行ってみることに。会社があるのはLai Kingという駅で工場・倉庫街のよう。ちなみにこの建物までは駅からバスが出ている。香港の人は基本的に外を歩くことが嫌いらしい。

午後は会社の先輩に色々案内してもらい、香港島から夜景をみて終わる。香港では夜の8時にイルミネーションショーがあるのだが、香港島からだと音楽に合わせてイルミネーションが変わるというデマを聞いてしまった。正解は九龍サイドのAvenue of Starsという観光地から音が聞こえるらしい。

◯3日目 8/8
この日は一人で香港の観光地を散策。

まずはStar of Avenue、海沿いでなかなか気持ちイイ。

香港島へはスターフェーリーで渡れる。2階建てで2階の方が若干料金が高いらしい。

香港の人はコカ・コーラが大好き。日本だとまだお台場にしかないような振ると凍るコカ・コーラもフェリー乗り場にさりげなく置いてあったりする。

日曜日の香港島市街地はどこもこんな感じ。日陰にいる人はフィリピンから出稼ぎに来ているメイドさんらしい。日曜日はお休みなので友達に会いに香港島に集まるらしい。通路という通路、日陰という日陰にびっしりいるので最初はびっくり。

香港の人は基本的に信号を守らない。危なそうなところは地面に気をつける方向が書いてある。車優先社会。

◯4日目 8/9 〜 6日目 8/11

会社の仕事を黙々とこなす。あまり夜も出歩かなかった。家とホテルの往復の日々。

◯7日目 8/12
深センの工場視察のため、初めての出張。そして初めての大陸入り。深センの印象は道路がどこも3車線でかなり広い。でも市街地まで行くとクラクションのオンパレードになる。この日だけで日本で1年間に聞くクラクションを超えたかもしれない。

◯8日目 8/13
香港住民に発行される香港IDと銀行口座をつくりに行く。香港IDは香港の住民であることを証明するカードで、入国審査の時に指紋チェックだけで気軽に行き来できるようになる。この日貰えたのはテンポラリの紙だけなので、本物は1ヶ月後らしい。

◯9日目 8/14

会社が紹介してくれた不動産やさんと物件巡りに行く。この日巡ったのは6物件、11部屋。香港のいい物件だと70〜80階建てになっている。この日見たのは25〜35階前後が中心、低いとせっかく香港にいるのにもったいないし、これより高いとおそらく予算オーバーになると思われる。

かなり元気でやっています。

◯空港を出るまで
羽田からも便があるけど変な時間(深夜だったかな?)なので、行く方も迎える方も成田便の方が楽。赴任者本人はJAL指定らしいけど、家族は会社が選べるらしい。空港降りるところまで日本語でいろいろ頼めるのを考えるとJALかANAがいいと思う。

空港着の目安が2時間前、登場前安全検査の目安が1時間前らしい。早くから手続きはできるから早めにどんどんやっておいたほうがいいかも。空港ついたらまずは手荷物を預ける。窓口がいっぱいあって迷うので近くの空港職員を捕まえて聞くのが早い。その次に手荷物検査、最後に出国審査がある。空港まで迎えにいくのでお金の両替は不要、成田空港を発つまでに最低限必要そうなお金(1万ぐらい?)を財布に入れた状態で着てくれれば良い。

ビジネスクラスだと出国審査の後にラウンジという施設が使えるかも。チケットに〇〇ラウンジ(JALだとSAKURA LAUNGEだったかな?)と書いてあったら行ったほうがいいと思う。出発までゆったりと過ごせるはず。ついでにビジネスクラスだと優先搭乗が出来る。

◯機内
4時間半のフライトだけど機内食が出るはず。子供を抱えたままだと食べれないかも。
機内で香港空港に着陸してからの手続きを説明したビデオが流れるので見ておいたほうが良い。なんとなくだけど流れがわかる。
出国カードという紙が入国手続きに必要だけど多分会社の旅行会社が印刷してくれるはず。スチュワーデスさんが配って回るけどいらないですと言えばOK。

◯空港ついてから
便に寄るんだろうけど、空港中心から遠いところに飛行機が着陸すると、最初に電車にのることがある。お金もいらないし、そのまま街中まで突き抜けることもないのでみんなに習って乗ったほうが楽。

案内板を見ながら入国審査場を目指す。Hong Kong Residents(香港住民)とVisitor(観光客)で入国審査口が分かれているが、滞在できるビザでくるのでHong Kong Residentsでもいいらしい。こっちの方が空いてるので必要があればこっちを使うと楽。入国審査場では広東語か英語で話す必要がある。自分が聞かれたのは「今回の入国はビジネスビザで入るのでいいのか?」みたいなことを英語で聞かれた…気がする。英語が苦手な状態でどうやったらうまく入国できるか、不安だったらツアーズの人に聞いてみるといい方法を教えてくれるかも。

入国審査が終わった後に手荷物を預けていたらを受け取りに行く。乗ってきた便名と、手荷物を並べてるブースが表示されているので合ってるところに取りに行けばいい。国内線のように手荷物があってるかのチェックは無い、そのまま空港をでることが出来る。

A出口とB出口があるのでA出口から出る。人がプラカードを持って並んでいるので頑張って探してもらう。いつが込むのか分からないけど、多分すぐに見つかる程度の人しかいないと思う。

あとはタクシーなり電車なりで家まで移動して移動終わり!!!

photo credit: E.HOBA

twitterには流してましたが、8月1日付の人事異動で香港に赴任することになりました。8月6日のフライトで香港に発ちます。すでに携帯電話は解約済みで、ネットもしばらく音信不通になる気もします(あっさりiPhone4でも手に入れば別ですが)。以下よく聞かれるFAQです。

Q. 何でまた香港に
A. 以前の上司が2008年末から香港にいる関係で声をかけていただき、呼ばれる形で行くことになりました。
向こうでは電卓と電子辞書の企画・開発・生産を行っており、自分はソフトウェア面を担当するエンジニア・マネージャとして働くことになります。入社して5年目になりますが、これまでとは異なる業務領域を担当することになります。

Q. どれぐらい行ってくるの?
A. 社内の書類では3年となっていますが、あまり効力は無いと聞きます。
うちの会社で赴任する人の平均が5年と聞いており、それぐらいになるのではないかと思っています。
もっともせっかくの機会なのでできるだけ長くいたいとも思っています。香港は7年いると永住権がもらえるそうです。

Q. 「赴任おめでとう」か「実は行きたくないの?」
A. 元々海外留学 or 海外勤務を希望しており、長期の赴任がいいと言っているぐらいなので「赴任おめでとう」でOKです。

Q. 家族は一緒?
A. 一緒です。娘はもちろん、私も家内も初めての海外です。(旅行すら無し)
今回の件で初めてパスポートを取りました。
私は8月6日に出発しますが、家族は3ヶ月遅れぐらいで来る予定です。

Q. 今後どうやって連絡とったらいいの?
A. とりあえず以下の手段を使ってください。向こうでの住まい・電話などが整ったら改めて連絡します。ネット上の活動はこれまで通りだと思います。

メール：tunepolo@gmail.com, yuichi@tsunematsu.cc
twitter : @tunepolo
skype : tunepolo
facebook : http://www.facebook.com/tunepolo

Q. SIMフリーのiPhone4/携帯電話買ってもらえるね
A. 顔見知りの方はお気軽に相談どうぞ。

Q. 香港案内してもらえるね/美味しいところ紹介してね
A. 調べておきます

◯第10章 グラフアルゴリズム
深さ優先探索と幅優先探索の並行実装例を紹介している。どちらも逐次処理だと再帰実装がよく用いられるが、再帰と並行処理の相性が悪いためキュー・スタックをつかって探索位置を管理する必要がある。スタックを使えば深さ優先探索に、キューを使えば幅優先探索になる。

次が最短経路探索問題のアルゴリズム。Floyd-Warshall法やDijkstra法があるけど、本ではFloyd-Warshall法だけTBBを使って紹介。特筆事項は無し。

最後が最小スパニングツリーを見つけるアルゴリズム。KruskalとPrimがあるけど、本ではPrimをTBBとOpenMPを組み合わせて並列化する手法を紹介。これまでの総集編といった趣。

◯第11章 スレッド対応ツール
宣伝じゃないと言いながらもIntelの製品をパワープッシュ。
著者はIntelの社員さんなのは割り引いて聞く必要があるかも。

◯全部読んでの感想
会社のメンバで輪講したのですが、後半はアルゴリズムの解説が多く、ソースの実装もいまいちだったように感じました。さらに後半は元の文が悪いのか、訳が悪いのか読んでいてわからないところが頻出しました。並行処理の基礎知識を習得するのに5章までを読むのにはいいかもしれません。後半は並行処理実装のアイデアを色々もらえるけど、いくらか疑ってかかったほうがいいと思います。

2年ぶりに受けたTOEICの結果が返ってきました。結果はリスニング460点、リーディング370点の合計830点で過去最高を更新しました。ここ2年間は英語の勉強をほとんど何もしていなかったので不思議でならないのですが、仕事でたまに使っているおかげなのかもしれません。

リスニングは特に目立つ弱点もなく、バランスよく点が取れていました。問題はリーディングで、リスニングと90点も差があることに加え、語彙に関する質問が他よりも正答率が悪かったです。ちなみに次に悪かったのは文法に関する問題でした。仕事でも相手が話していることは大体理解できるものの、文書やメールは苦手で、意思の疎通もジェスチャーや図に頼ることが多かったので、現在の英語レベルが正直に測れている気がします。

次は900点台を狙いたいところですが、シャドーイングだけに頼った勉強法ではリーディングを伸ばすことは非効率化もしれないので、語彙力の強化と文法の復習を少しずつやっていこうかと思います。twitterで900点台を狙う勉強法を聞いたところ、以下のアドバイスを貰いました。

1. NYTを読む。単語の言い換えが多く、洗練された英語が学べる。
2. TOEIC TEST英単語スピードマスターをやる。
3. 海外に移住する。
4. K/Hシステムの教材を使う
5. BBCの教材を使う

本も書店で幾つか見てみたのですが、しばらくは英語の新聞を中心に知らない単語をこまめに引く習慣をつけようかと思います。最もその前に英語の活字を読む習慣をもっとつけなくてはいけませんが…

3連休の後ろ2日を使って行ったのですが、高速料金割引の効果か、子どもが夏休みに入った効果か、天気が良かったのかとにかく道路が渋滞して大半を車の中で過ごした気がします。とはいえ途中吊り橋に寄ったり、那須サファリパークに寄ったりして私も家族も楽しく過ごせました。

個人的にアルパカ牧場　那須ビッグファームに行きたかったのですが、ここはまた今度になってしまいました。最も夏はアルパカが毛を刈ってしまってモフモフ感が足りないそうなので涼しくなった頃が狙い目ですかね。

photo credit: 池田隆一

scanbooks.jpから業務用スキャナを借りること6日間、前に裁断した155冊の書籍を全て電子化し終えました。

実際にやってみてハマったことに、こんなことがありました。

• スキャナがWindowsしか対応してない→急遽実家からWindows PCを借りた
• スキャナが用紙サイズの自動判定に対応していない→サイズが似通った本が連続するよう調整
• 飽きる→2時間ぐらいたったら休憩が必要
• モノクロ印刷に赤ペンでの書き込みがある→面倒なので24ビットカラーで読み込み

紙詰まりや順番が狂うなどのアクシデントはほとんど起きませんでした。起きたとしてもきちんと裁断されてないなどのスキャナ以外の要因でした。

またやりたいとは思いませんが、本棚が1つ処分できて部屋が綺麗になりました。気になるデータサイズも150dpiスキャンしたJPEGをzip圧縮したもので5.3GBでした。書籍によってスキャン条件をもっと細かく調整するともっと小さく、綺麗にできたのでしょうが、これはスキャナ・裁断機を自分で購入するぐらい腰をすえてやらないと駄目でしょうね。

◯第8章 ソート
プロセッサ時間の80%以上はソートに費やされるとも言われる。ソートを高速化すれば処理全体の高速化につながりやすい。
この章では5つのアルゴリズムについて並行化を検討している。

バブルソートは左右で要素を比較して、小さい値(または大きい値)が泡のように上がっていくことからそう呼ばれる。スレッドの順番が入れ替わらない限り、頭から複数スレッドで配列を走査してもソートは保証される。このアルゴリズムは波の動きに似ているためwavefront法とも呼ばれる。単に前のスレッドを抜かさないようにするとオーバーヘッドが大きくなるため、配列をいくつかのゾーンに区切って制御すると良い。

奇偶転置ソートは「奇数インデックスの比較→偶数インデックスの比較→奇数インデックスの比較」を繰り返してソートを行う。隣接同士の比較・変更しか起こりえないので、データ分解による並列化が容易。

シェルソートは配列全体を適当なサイズで分割し、分割された範囲内でソートを行う。徐々に分割サイズを小さくすることでソートを行ない、要素が大きく動かせることからソートが早く行える特徴がある。逐次処理では有効だが、並行処理ではキャッシュが効きにくくなり並行処理では短所にもなりうる。

クイックソートは逐次処理では最も一般的なソートである。再帰を使って実装することもあるが、並行処理には不向きなのでキューを使うなりして再帰は避ける必要がある。スレッドをプールし、ソート対象のインデックス範囲をキュー/スタックに入れておくことでスレッド間の競合を抑え、処理を並行化することができる。処理が終わったかどうかを判断し、スレッドに処理を辞めるよう促す実装が若干面倒。

奇数ソートはソート対象を二進数と考え、上位ビット/下位ビットを使ってソートしていく。同じ値の順序が保たれる安定ソートであることが特徴。実装では複数ビットをまとめてソートすることになるが、ソート後の移動先の計算がかなり面倒。本でもトリッキーに思える例が紹介されていた。

◯第9章 サーチ
未ソートデータに対するサーチと、ソート済みデータに対するサーチの例を紹介。

未ソートデータの場合、全要素を見ないといけないので、配列をデータ分解してスレッドに処理させる。探索対象のデータが見つかったときに処理を打ち切る工夫を入れるぐらいでOK。素直な実装になる。

ソート済みデータの場合、逐次処理では2分探索が一般的。並行処理ではこの考え方を発展させてN分探索すると良い。配列をNつに分解し、探索対象がどちら側にあるか(右側、左側、見つかった)を調べる。探索対象のデータは向きが異なるブロックに含まれるため、このブロックを探し出し、内部をさらにNつに分解して再帰的に探索を続ける。

アップだとこんな感じです。止口はゴムになっていて、黄色以外に青や緑が有ります。
Fantabulous iPad Case – Star Without Wars

海外のショッピングサイトでpaypal支払いし、配送料も含めて2700円ぐらいでした。悪くない買い物だったと思います。

届いたのは先週の土曜日なんですが細かいことは気にしないことに。使ってみての第一印象を書き留めておきます。ちなみに用途は自炊する本の閲覧用がメインと考えています。

• ベッドでゴロゴロ使うのに向いてるマシン。もしくは机の上に置いて使うべき。
• 電源はかなり持つ。2、3日ぐらい充電しなくても使えるかも。
• 縦持ちのキーボード入力はちょっと狭い
• iPhoneアプリが使えるけど画面が小さくて実用に耐えない。いくつか入れておいたけど全部捨てた。
• 動きがある本はアリスよりもTOY STORYが面白い。
• iPadアプリはまだまだ数が少ない。
• ケースも画面シートもいらなそう。
• Webページが見やすくなった。前はInstapaperを経由してよく読んでいたけど、普通に開いた方が早くてレイアウトもいい。
• iPhone向けにエンコードした動画はちょっと小さい。iPadだとノイズが気になるようになる。

肝心の自炊データはまだ突っ込めておらず要検証です。

胃カメラでなくバリウムも選べたんですが、昔胃カメラ飲んだことあるから同じのにしておくかと思ってしまいました。チューブを飲み込んでいる間は、選んだ昔の自分を殴ってやりたいと心底恨みました。

胃カメラって飲んで終わりかと思っていたんですが

• 胃を洗浄する薬をコップ1杯
• 胃の動きを抑える肩への注射
• 喉に麻酔をかけるうがいタイプの薬
• 喉に麻酔をかけるスプレータイプの薬

と結構事前準備が大変です。バリウム+下剤も大変だと思うのですが、もっと楽に体内の調査ができるようになるといいですね。

Canon デジタル一眼レフカメラ EOS Kiss X4 EF-S 18-55 IS レンズキット KISSX4-1855ISLK

posted with amazlet at 10.06.05

キヤノン (2010-02-26)
売り上げランキング: 1325

おすすめ度の平均:

デジイチ動画
Kiss X4 ◎◎◎！　と SEKONIC L-208も◎◎◎！
素晴らしい
泣きたいぐらいの駄機種
使いやすくかつ便利

Amazon.co.jp で詳細を見る

少し前からEOS Kiss X4を借りる機会があって週末に色々撮ったりして遊んでいました。週明けに返却してしまうので、何を借りてどんな写真を撮ったのか記録に残しておこうかと思います。レンズも選べたのでキットレンズではなく、単焦点・広角・オールマイティ(望遠)の3種類を借りています。

Canon EFレンズ 28mm F1.8 USM

posted with amazlet at 10.06.05

キヤノン
売り上げランキング: 13027

おすすめ度の平均:

使いやすいです。
昔日の感動が甦りました
キャノンユーザでよかったと思える一本
APSデジ一の標準レンズにどうぞ
贅沢な短焦点レンズ

Amazon.co.jp で詳細を見る

まず単焦点レンズがこれ、借りて最初に使ったのがこのレンズです。カメラの腕を上達するには単焦点レンズがいいと聞いたことが有りますが、色々とアングルを考える必要があるので確かに当たっているかもと思います。背景が綺麗にぼけてくれるのでそれなりにとれてしまう問題もあるのかもしれませんが…

Canon EF-S レンズ 10-22mm F3.5-4.5 USM

posted with amazlet at 10.06.05

キヤノン (2004-12-01)
売り上げランキング: 15962

おすすめ度の平均:

他社に比べると…
やはりいいね。
Nice lens
これは楽しいレンズ
出番は少ないが圧倒的な存在感

Amazon.co.jp で詳細を見る

広角がこれ。コンパクトデジカメとは段違いの画がとれますが、あまり遠出をしなかったので広角を生かした写真がとれたかは疑問です。風景とか撮るのに向いているんでしょう。

Canon EF-S レンズ EF-S18-200mm F3.5-5.6IS EF-S18-200IS

posted with amazlet at 10.06.05

キヤノン (2008-09-26)
売り上げランキング: 12836

おすすめ度の平均:

Wズームが１本で！
欠点が見つからない程、良く出来てます！
確かに高倍率は便利だけど．．．
これ一つで充分でしょう。
オールマイティ

Amazon.co.jp で詳細を見る

オールマイティなレンズがこれ。感覚的にはこれまで使っていたコンデジに近い感覚で使えますが、ズームが効くし、撮れた画は段違いでした。

レンタルしてみての感想ですが、やっぱり撮れる画の綺麗さが全然違います。子供を中心に撮っていましたが、長期で旅行に出かけるときなどあると思い出がより良く残せるかと思います。購入するかというと…iPadを注文してしまったのでちょっと難しいかな。

万年筆(LAMYサファリ)、ボールペン(LAMY2000)とラミーの筆記具で揃えてきましたが、就職してからシャープペンシルを使う場面がほとんど無いためこれまで100円ぐらいの安いヤツでしのいでいました。でも前からシャープペンも欲しいなと思っており、もうじき昇進試験の練習も始めるしなと思って万年筆とお揃いのイエローで揃えました。アルミを使ったちょっと高価なモデルのアルスターと最後まで迷いましたが、手に持った感じが映えるイエローに惹かれて最後はおそろいのものを選びました。

これで主要な筆記具が全てラミーで統一されました。あとは・・・ローラーボールがあるけど、これはどうしようかな。

諸事情により本棚の削減を始めました。読み返すときに紙で読みたい本以外は既読も未読も合わせて裁断し、iPadで読もうと思います。

2つある本棚を整理したところ、155冊が裁断対象となりました。裁断機とScanSnapを買って1ヶ月ぐらいかけてやると今後も持たない生活が継続できていいのでしょうが、ちょっと時間ももったいないため今回は裁断サービス&スキャンレンタルサービスの本の裁断・解体サービス｜背表紙 裁断｜高速スキャナー 無料レンタル｜雑誌 漫画 マンガ まんが 蔵書｜スキャン 保管 保存 整理 処分｜scanbooks.jp（スキャンブックス）を使うことに決めました。冊数が揃っていると返送時の配送料や、スキャナの無料レンタルが利用することが出来ます。かかるお金は裁断依頼時に送る宅急便代と、1冊110円の裁断料です。自分の場合、155冊の本を4つのダンボールに詰めてクロネコヤマトの配送料が5000円弱、これに110円×155冊=16,500円がかかります。あとiPadを買うと数万円の上澄みが必要です。

でもこのおかげで本棚が一つ捨てられそうなので、部屋を広く使えると思うと投資の対象として見合っていると考えました。
スキャンがどれぐらいで出来るか未知数ですが、7月の中旬を予定しています。

途中ペルシャ軍に属する不死の忍者軍隊が出てくるまで歴史に忠実な映画かと勘違いしてしまいましたが、アタマを空っぽにして楽しむエンターテインメントでした。割りきってみてしまえばストーリーも分かりやすく、ラストも納得出来る終わり方で楽しめます。

守犬のお部屋 via kwout

茨城県守谷市発のゆるキャラ、守犬だそうです。常磐道守谷サービスエリアで見つけました。守谷のあたりはなまっている感じがしないのですが、キャラの特徴を出すためかなまってますね。守犬だけにグッズはお守りが充実、値段が高かったので買うのは見合わせましたが・・・

ちなみにこの守犬、アメーバブログに加えてアメーバなうもやってるそうです。ゆるキャラ業界も新しいことに取り組んでいかないと淘汰が激しいんでしょうね。

守犬さんの投稿したなう | Amebaなう(アメーバなう)

最初にMapReduceの説明があり、直後にリダクション処理(配列の和を求める処理)のMapReduce実装例が載ってるんだけど、前章までに扱ってた処理と何が違うのかこれだけではさっぱりわからない。Map処理とReduce処理をきちんと分けた処理にする必要はわかるんだけど、1つのCPU上で動くようにコードを書いても読者にメリットは伝わらないと思う。MapReduce自体の説明は2006年8月31日のRadium Software Developmentがおすすめ。

7章の残りはスレッドのバリア同期の実装について。並行コンピューティングの理解を深めるために必要となってるけど、Pthreadでも提供されている機能だし、自前実装するよりも用意されているものを使った方がいいんじゃないかな、多くの場合では。

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

posted with amazlet at 10.05.09

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

Amazon.co.jp で詳細を見る

photo credit: una nos lucror

長年蔵書管理に使っていたSocialtunes* モノ系ソーシャルですが、一向にサービスが改善される気配が無いのでとうとうしびれを切らして乗り換えました。サーバのレスポンスは問題なかったのですが、ブックマークレットがメンテナンスされず動かないURLが出てきたり、他サービス連携が出来なかったり、iPhoneアプリもなかったり、今後も主力で使っていくのに不安が大きすぎたのが理由です。コトノハと同じ運営元ですが、あちらは今でもメンテナンスがされているのでしょうか…

さて移行ですが、ちょっとしたスクリプトと正規表現を使ってSocialtunesのペタページからAmazonのASINを取り出してCSVファイルにしてデータを吸い出しました。ASIN一覧ぐらいサービスでエクスポート機能があっても良さそうですが、メンテナンスされてないWebサイトでは仕方ないですね。

乗り換え先にはメディアマーカーを選びました。デザインはイマイチですが登録のしやすさ、欲しい機能の整備状況、他サービスとの連携がちょうどバランスが取れていると思います。過去の読書履歴を全部そのまま移すのは骨が折れそうなので一旦リセットして、これからまた記録していきたいと思います。

メディアマーカー – tuneのバインダー

企業の研究者をめざす皆さんへ―Research That Matters

posted with amazlet at 10.05.04

丸山 宏
近代科学社
売り上げランキング: 131342

おすすめ度の平均:

IBM東京基礎研究所のようす
企業研究者を目指す学生は勿論のこと、企業研究者にも参考になる。

Amazon.co.jp で詳細を見る

この本を読んでいてどこか既視感があったのですが、情熱プログラマー ソフトウェア開発者の幸せな生き方
に通じるところが非常に多い本です。情熱プログラマがソフトウェアエンジニアのキャリア構築について述べた本なら、こちらはリサーチエンジニアのキャリア構築について書かれた本です。必要とされる技術やバックグラウンドが多少異なるのかもしれませんが、世界基準で力を蓄え、世の中を大きく変える創造性を求められる点で抑えておくべき素養は似通ってくるのかもしれません。

本の冒頭部では研究者は「ものごとの原理に常に立ち返って真理を追求する姿勢を失ってはならず」かつ「お客様や社会の問題を常に意識して、それを解くための真理・原理・仕組みを考えていく」必要があると説いています。これから先自分の仕事が仕分けされないようにするには研究者としての本分を忘れず、世の中に貢献していく姿勢が求められます。研究者の貢献と言うと最近ではイノベーションという言葉で曖昧に表現されている感がありますが、この本では「どんな形であれ、インパクトの大きさで測られるべき」としています。Appleが出すようなセクシーな製品や、TEDで見れるような数年先の未来モデルだけではなく、Linuxのような世界中で使われるソフトウェアを開発することも立派なインパクトの一つとしています。この定義はこれまで「インパクトのある大きいことをやれ」とただ言われていただけに感じていた自分には
納得感が有るものでした。

その他、研究者として自らを伸ばしていくためにいくつものアドバイスがあります。

• 目標となる人物・師を探すこと
• 解くべき価値がある、いい問題を見つけること
• 成果はすぐに使われない可能性があるので、きちんとした形(論理性のある文書、例えば論文)で残しておくこと。
• コミュニケーションとは相手に”納得”してもらい、相手に次の行動を促すこと。
• 見えないことはいないのと同じ。存在感を出すこと。
• 外の世界を積極的に経験すること。

研究者としてのアドバイスの他に、IBM社内での取り組み事例が各所で紹介されていて、IBMという組織の巨大さ、底力を垣間見ることができます。自分が知っていたIBMとはずいぶん違う点もあり、ここも面白く読むことが出来ました。

大学で研究室に配属されたばかりの学生や、企業に就職して研究開発部門に配属された新人社員が読むと得られるものが多いと思います。この本はIBM東京基礎研究所内のイントラブログをつなぎ合わせる形で構成されていますが、複数の文書をつなぐために記述が冗長な所も見受けられます。もっと多くの人に読まれていい本だと思うので第２版が出るならこの点が改善されるといいなと感じました。

・・・

ちなみに自分の本は丸山さんからいただいたサイン付きです♪

MacBookのパームレストにひびが入り、下の基板が見える状態になっていたので渋谷のApple Storeに行って修理してもらいました。MacBookのパームレストにヒビが入る問題は発売頃からあったようで、ネットで探すと同種の現象がすぐに見つかりました。Appleもこの件は不具合として認めているようで、無償で修理してくれるそうです。ただし郵送でPCを贈る必要があり、PCがない生活がしばらく続くのは不便なのでApple Storeに持ち込んで修理してもらいました。

• またMacBookにひび割れ問題発生 – 気になる、記になる…
• Flickr: My MacBook Was Cracked By Itself

修理までの流れはこんな感じでした(A:Apple, 自:自分)

前日

• 自:Appleのお客様窓口に電話
• 自:症状を説明、無償で修理してくれる旨を向こうから聞く
• 自:郵送で修理は嫌なのでApple Storeで修理出来ないか、こういう事例もネットで見かけた。
• A:Appleのお客様窓口とApple Storeのジーニアスバーは連携していない。なので別途お客様から連絡して貰う必要がある。
• 自:キーボードの交換在庫ぐらい確認出来ないのか?
• A:できない、ジーニアスバーの予約なら代理で出来る
• 自:ならそれでOK、渋谷店で予約をお願いする。
• A:連絡用に電話番号とメールアドレスを教えて欲しい
• 自:Appleに製品登録したときに使ったのでいいよ → 予約確認などの案内は送られてこず。

当日

• 自:Apple StoreにPCを持ち込んで再度説明
• A:無償で修理させてもらう。修理時間は6時間ぐらい
• 自:そんなにかかるの? まあいいけど
• 自:GW中の渋谷で6時間もブラブラして時間をつぶし、Apple Storeで修理されたMacを回収

無償で修理してくれたことに着目するとAppleの対応は良かったって思いがちだけど、よくよく考えてみるとあまりAppleの対応は良くないと思う。そういえばSnow Leopardのインストールメディアも初期不良で、Appleは無料で交換してくれたけど、その時は船便で10日ぐらいかけて送ってきたことを思い出した。
紆余曲折がありSnow Leopardへ » tune web

Apple製品で言うと、妻が使っているiPhoneは画面右上にあるボタンが最初から陥没していて非常に押しづらくなっている。自分にとってAppleの品質面の印象はかなり悪くなっている。前に使っていたThinkPadは最後まで問題を起こすことはなかった。あのレベルまでは求めないけど、もうちょっと何とかならないものだろうか。

まずはカバン。相変わらずしっかりしていていますが、使用頻度が落ちているからかもしれません。一度雨の日があるとカバンを取り替えてしまい、翌日以降晴れていてもこのカバンを使わないことが多いです。日焼けは前とそんなにかわりないかも。

色が濃くなっているのはこの財布が一番。毎日使っているからか、手垢がつくからか手入れをする度に汚れがたくさん落ちます。ところどころ痛んできていますが、まだまだ使えそうです。鞄と同じく4年選手です。

一番使用頻度が低いのが名刺入れ、研究開発職だと名刺交換をする機会が少なくてついつい鞄の中に入れたっきりにしてしまいます。もうちょっと使ってあげないとな。

せっかくなので色の変化を時系列で並べてみました。こんな感じで色がついていくという参考になれば。
◯2005年12月

◯2006年8月

◯2007年4月

◯2009年5月

◯2010年5月

git smudge/cleanはPro Git – Pro Git 7.2 Git のカスタマイズ Git の属性に詳しく解説されています。
git smudge/cleanの設定は前の日記に書きましたが、ここでも引用しておきます。

まず.gitconfigファイルに以下を追加

[filter "fixbom"]
clean = “/usr/bin/bom_util -a”
smudge = “/usr/bin/bom_util -d”

これでsmudgeでUTF-8 BOM無し、cleanでUTF-8 BOM有りになります。

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

*.c filter=fixbom
*.h filter=fixbom

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

上記で指定している、BOMをつけ外しするプログラムは結局自作しました。単にファイル先頭のBOMを検知して追加・削除をするだけです。ハマったこととしてgit smudge/cleanのデータは標準入力から渡され、標準出力へ書いた内容で差し替えられます。外部コマンドとして起動されるのかと思っていましたが異なるようです。
BOMをつけ外しするプログラムを下に貼っておきます。(gistはこちら→gist: 386410 – GitHub)

#!/usr/bin/ruby

require "optparse"

mode = :help

opt = OptionParser.new
opt.on("-a", "Add BOM"){|v| mode = :add}
opt.on("-d", "Delete BOM"){|v| mode = :delete}
opt.parse!(ARGV)

case mode
when :add
 STDOUT.binmode
       lines = readlines
       unless lines[0] =~ /^\M-o\M-;\M-?/ then
               print "\xEF\xBB\xBF"
       end
       print lines

when :delete
 STDOUT.binmode
       lines = readlines
 lines[0].sub!(/^\xEF\xBB\xBF/, '')
 print lines

when :help
       STDERR.puts opt.help
end

VisualStudioでの開発をメインにしているので、リポジトリ内のソースをUTF-8 BOM有、改行コードをLFCRにして運用しています。
これでLinux環境での開発がひとつやりやすくなりました。

• Googleは全プリンタ（既存のものも！）をWebプリンタとして標準化統一化することを目指す
• プリンタドライバの役割をクラウドに – Googleが「Cloud Print」を発表 | パソコン | マイコミジャーナル
• Introduction – Google Cloud Print – Google Code

TechCrunchが一番詳しく報じていましたが、それでもGoogle Cloud Printが何をしてくれるのか、現状どういう状態にあるのか知ることが難しかったので元情報にあたってみました。そんなに難しい英語ではありませんが、後で参照することを考えて訳も残してあります。きちんと原文と対応する訳ではありませんが、参考にはなるんじゃないかと。

• tune’s google_cloud_print_ja at master – GitHub

Google Cloud Printって何?
Webブラウザ/デスクトップアプリ/携帯端末全てから、ドライバの問題を気にすることなく世界中全てのプリンタに印刷出来るようにすることを目指すGoogleのプロジェクト。
GoogleはCloud Printのデザインドキュメントとプロトコルを公開し、さらにCloud Print Serviceを将来公開する。 アプリケーションは印刷指示をOSやドライバに送る代わりにGoogle Cloud Printに印刷ジョブを送る。Google Cloud Printが登録されている適切なプリンタにジョブを送り、アプリに印刷状況を伝える責任を果たす。

Googleがこのプロジェクトに取り組むのはChrome OSで全てのプリンタに対応するドライバを用意することが不可能だから。Chrome OSはCloud Printを使うように設計される、プリンタドライバは一切搭載されない。

現状何があるの?
Googleがこんなこと考えているよというデザインドキュメントだけ。
数ヶ月以内に追加の発表があるかも。

この段階でCloud Printを発表したのはプリンタメーカーとコミュニティの協力/フィードバックを早期に得るため。

どうやって実現するの?

Cloud Printではクラウド対応のプリンタと、レガシープリンタの2種類のプリンタを想定している。現在世の中にあるプリンタはWeb連携していてもレガシープリンタに分類される。Googleの考えるクラウド対応プリンタとはCloud Printで想定しているプロトコルを解釈出来るネットワーク対応プリンタを指す。かといって全てのプリンタがクラウド対応になるのを待ってるわけにも行かないから解決策も提供する。それはGoogle ChromeにCloud Printのプロトコルを解釈出来るプロキシを搭載することである。これにより、Google Chromeユーザは既存のレガシープリンタをPCをプロキシとして、Google Cloud Printのサービスを利用することが出来る。かといってこの方法だとPCもプリンタも常時電源をつけていなければならないので、例えばルータでプロキシが動くようにすればこの問題を解決出来ると考えている。(Google Cloud Printの絵にルータが書いてあるのはこのため。)

もう少し詳しい技術情報を
ユーザとプリンタの関連付けはGoogleアカウントを用いる。ユーザは既存のアカウントでログインし、はじめに利用するクラウド対応プリンタ(またはプロキシ下のレガシープリンタ)を登録する。プリンタはGoogle Docsのドキュメントのように扱うことができるので、プリンタを複数のユーザで共有することも簡単。

Cloud Print Serviceとプリンタの会話はHTTPで行う。サービスでは以下のAPIを定義

• register : プリンタの登録
• update : プリンタ情報の更新
• list : 特定ユーザが利用可能なプリンタ一覧の取得
• delete : プリンタの削除
• control : プリントジョブの状態取得
• fetch : 次のプリントジョブの取得

出力はjson, xml, textを選択することが出来る。

プリントジョブは永続化したXMPPコネクションを使ってGoogle Talkサーバから通知される。定期的にサーバからfetchしてもOK。

印刷データはfetch APIの出力に記載されているfileUrlから取得出来る。プリンタはfileURLにアクセスした際のHTTPのMIMEタイプを見て直接印刷可能かを判断する。 出来なければfetch APIに記載されたticketURLの方をアクセスし、PDFでデータを受け取ることができる。 当初はPDFのみをサポートするが他のフォーマット(例えばXPS)も将来サポートするかも知れない。PDFへの変換はGoogle Cloud Printが担当する。

雑感
Googleの今ある技術をうまく組み合わせてプリントジョブ管理の仕組みを作ってきたなという印象です。

プリンタドライバはジョブ管理以外にレンダリングなども担当していますが、この処理はプリンタ側に組み込む必要がありそうです。コピー機ぐらいのリソースがあれば問題ないかもしれませんが、1万から2万ぐらいの安いプリンタではリソースが厳しそうです。いずれにせよやるとなったら値段が高い方の機種から対応が進んでいくでしょう。

PDF内のデータは表示順に並んでいないと聞いたことがあります。1ページ目にある画像がファイルの後ろに格納されていると言った具合です。これではプリントジョブを受け取りながら印刷できないのでプリンタ側で一旦記録バッファリングしなくてはいけません。プリンタにはどれぐらいメモリの余裕があるんでしょう。

あとプリンタがGoogleアカウントと結びつけられるのは便利そうですが、近くに無いプリンタに出力してしまうこともよくありそうです。自宅の印刷物を会社のプリンタに出したりしては問題だと思うのですがどうするんでしょう? コピー機ではセキュアプリントなどと言った名目で、印刷ジョブを出した人がその場に行ってボタンを押さないと実際に印刷を行わないようにできます。こういう機能が一般的になるんでしょうか。

いずれにせよクラウド対応プリンタを実現するには、これまでよりもプリンタ側で製造コストをかけないとダメそうです。逆に言うとプリンタで使えるリソースが増えるのでこれまでは出来なかったことも考えられるかもしれません。プリンタメーカー各社にはピンチではなく、チャンスと思って色々考えて欲しいですね。

photo credit: lett -/=

最近Adobeのニュースが賑わっています。CS5の発表もありましたが、多くはAppleとやりあっているFlash関連のニュース。とうとう先日AdobeはiPhone/iPad向けのFlashから手を引き、Androidに注力することを宣言しました。業績が好調のAppleがAdobeを買収するのではという憶測も定期的に出てきています。

• Appleとの溝を深めるも将来に自信を見せるAdobe – ITmedia エンタープライズ
• AppleがAdobeを買収するというシナリオ – ENGINE04 blog

AdobeはFlashを共通のミドルウェア化することでWebの覇権を取りに行こうとしていますが、Flashそのものでは利益を生めません。Flashをオーサリング出来るAdobe Flash、さらにはPhotoshop, Illsutratorを買ってもらってソフトウェアで利益を上げるビジネスだと自分は認識しています。MicrosoftがOfficeの値段を下げる中、AdobeのPhotoshopはアップグレードでも48300円するそうです。まとめて購入するとMac Proが買えるぐらいの金額になります。

これだけ高いお金を払ってもらうには相応の機能が必要と考えるのが一般的です。Adobeは今回のCS5で様々な目に見える機能を実装しています。「えげつない」と評されたPatchMatchは話題になりました。

こういった新しい技術はCG技術を画像処理に応用する”Computational Photography”に分類されます。一口にComputational Photographyと言っても色々アプローチがあって、SIGGRAPHなどの有名な国際会議で活発な研究成果の発表を知ることが出来ます。Adobeは世界で最も”Computational Photography”に注力している企業の1つです。なんですが…なんでAdobeがこんなに注力するのかが自分にとって謎でした。Photoshop/Illustratorに最新の画像処理技術を組み込んでさらに魅力的にして、CS6, CS7とアップデートしてもらうのも1つの理由でしょう。でも”Computatioal Photography”は特殊なハードウェアを要求するものもあり、どんなにAdobeが頑張っても実現出来そうに無いものもあります。そこが謎でした。技術の将来性があるからといって、すぐに利益を産めないものにリソースを使いすぎなんじゃないかと。

で、教えてもらったのがフランケンカメラプロジェクトです。カメラのハードウェアとソフトウェアを切り離し、ハードウェアを共通化する。その上でソフトウェアで価値を生み出せるようにするカメラ、それがフランケンカメラです。iPhoneで沢山あるカメラアプリを想像すると、このカメラでどんな可能性が広がるか伝わりやすいかもしれません。

• オープンソース・デジカメ「フランケンカメラ」開発中

これがあれば、Adobeはカメラメーカーになることができます。それもレンズや撮像素子は差別化要因にならず、ソフトウェアで差別化を図る必要がある「ソフトウェアで画質が進化する次世代カメラ」です。今のカメラよりも従来のデジカメとは2世代ぐらい先を行っているでしょう。こうなればComputational Photographyに一日の長があるAdobeがカメラメーカー、携帯メーカーとは異なる軸で戦うことができます。フランケンカメラにAndroidを積んで、その上で動くUI/アプリをFlashで作れるなら現実的にAppleと戦えそうな気も少しだけしてきます。

実際Adobeぐらいの規模なら業績が悪いカメラメーカーを買収することぐらいできるでしょうから違うアプローチを取るかもしれません。カシオはソフトウェアで差別化を図っていくつもりのようなので、Adobeと波長が合うかもしれません。

• デジタルだからできること：「画像処理エンジンは100倍パワフルだっていい」――カシオ計算機（後編） (1/2) – ITmedia デジカメプラス

以上、会社の同僚から教えてもらった話でした。
間違ってる可能性の方が高いと思いますが参考まで。

◯並列和
配列の和を全部求めるよくある処理。楽なのはOpenMPやTBBを使ってリダクション処理をそのまま利用すること。
自前で実装するなら配列をスレッド数で分割して個別に小計を計算。全スレッドが計算終わったら小計を全部足して合計をもとめるというやり方がおすすめ。

◯プリフィックススキャン
[3, 5, 2, 5, 7, 9, 4, 6]という配列を与えたときに[3, 8, 10 15, 22, 31, 35, 41]という配列を求める。配列のN番目に元の配列の0〜N番目までの和を入れておく処理に当たる。包含的プリフィックススキャンとも言うらしい。
先頭を覗いて[0, 3, 8, 10, 15, 22, 31, 35]の配列を求める排他的プリフィックススキャンの方法もある。

並列化の手法として、スレッド数で配列を分割し、個別にプリフィックススキャンを行う。次に末尾の要素を使って前後のチャンクに伝搬させる値を計算する。計算が終わったそれぞれのスレッドが担当するチャンクに値を加算してプリフィックススキャンを完了する。

さっきの例を3スレッドでやるとこんな感じになる。2と4のステップが並列化可能になる。
2から3、3から4に移るときに毎回スレッドを生成/破棄するとオーバーヘッドになるので、スレッドのイベント通知機能を上手く使って使いまわすのが吉。

1. 入力をスレッド数で分割
[3, 5, 2, 5, 7, 9, 4, 6] -> [3, 5, 2], [5, 7, 9], [4, 6]

2. 個別にプリフィックススキャン
[3, 5, 2], [5, 7, 9], [4, 6] -> [3, 8, 10], [5, 12, 21], [4, 10]

3. 配列の末尾の値で排他的プリフィックススキャンを行い、伝搬させる値を計算する
[3, 8, 10], [5, 12, 21], [4, 10] -> [10, 21, 10] -> [0, 10, 31]

4. 3で求めた値を2の処理結果にそれぞれ加算
[3, 8, 10]+0, [5, 12, 21]+10, [4, 10]+31 -> [3, 8, 10, 15, 22, 31, 35, 41]

◯セレクション
配列をソートしてN番目の値を取ってくるという処理。
ソートしてもいいけど、1回しか呼ばれないとか、適宜順番が変わるような配列だとセレクションがおすすめ。

公知のセレクションアルゴリズムがあって、その中でいくつかを並列化する。

1. 配列数がQ(本では5を勧めている)より小さければデータをソートして、k番目の要素を返す。Qより多ければ次のステップへ
2. チャンクから中央値を選ぶ(本では配列を分割して中央値を求め、その中からさらに中央値を求めるやり方をしているけど、配列の中身が適度にバラバラなら適当に選んでもいいかも)
3. データを A.中央値より小さい値を持つ B.中央値と同じ値である C.中央値より大きい値を持つ の3種類に分け、A,B,Cの数を数える。
4. 求めるk番目の要素がどこに入るかを調べる。Bに入るなら値を返して終了、AかCなら再帰的に1から処理を続ける。

本で高速化しているのはこのうちの2の処理、3の処理、4の処理の一部である。ポイントは4の処理で、再帰的に呼び出す際の配列の部分集合を使うのにプリフィックススキャンを使って詰め直し先のインデックス値を求めている。逐次処理に慣れきっていると重そうだけど、実際実行してみたら早いのかな? 要検証。

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

posted with amazlet at 10.04.23

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

Amazon.co.jp で詳細を見る

ソフトウェア開発者のみならず、あらゆる分野でその道を極めようとしている人におすすめです。プログラマ固有のところは極めて少なく、自分の人生を自分で切り開いていくために必要な情報が分かりやすく整理されています。

以下この本で気になった所を引用しておきます。この本がプログラマ以外の人にも示唆に富む内容であることが伝わるのではないかと。

より良い製品を作って仕事を確保することだけが大切なのではない。より実りある人生を送るためのスキルと感性を磨くことも大切だ。人生には素晴らしいことがたくさんある。仕事はそのひとつに過ぎない。(David Heinemeier Hansson)

偉大になることを望んでいる人のほうが、自分の仕事をこなせれば良いと思っている人よりも、偉大になる可能性がずっと高いからだ。

何かのスペシャリストであると言うことを、単に他のことを知らないという意味で使っている人が多すぎる。

ビジネスの仕組みを知りもしないで、ビジネスが利益を上げるために想像力を働かせて協力できるだろうか?
・・・
想像力を働かせて付加価値を高めるためには、自分が関わるビジネスについての徹底的な理解が必要だ。

本当の意味で何かを習得しようと思ったら、誰かに教えてみることをおすすめする。自分の理解をはっきりした形にする一番いい方法は、自分の言葉を使って、他の人にもわかるように説明することだ。

プロセスを身につけたいなら実践しろ。

いいマネージャの役割は、チームの仕事に優先順位を設定し、チームが仕事をこなすために必要なものを用意し、チームがやる気と生産性を維持出来るように配慮し、最終的に要求を実現することにある。

短く働いた方が、より多くの成果をあげられる。

ソフトウェアの品質が本当の意味で試されるのは、何か問題が起きた時だ。

本当に出来ないときに臆せずに「できません」と言える強さを持ったチームメンバーがいれば、彼らの「できます」という言葉には偽りが無いと確信出来る。

多くのソフトウェア開発者は勘違いしている。事情に通じたマネージャや雇い主なら自分の技能を見ぬいて当然だと思い込んでいるんだ。・・・全部言い訳。彼らは怖がっているだけさ。
誰かが何かすごいことをしても誰もそれを知らなければ何もなかったのと同じだって言うんだ。

大局的に見るなら、作文技術は必要かつ供給不足なんだ。
君ももっと大量の文章を書くことになる。文章を書くことが仕事の一部になるとすれば、もっと作文技術を磨いた方がいい。

君に信念がないと、こういうことはできない。会社の連中が間違った事をするのを傍観していられない。改善の余地があるなら君が変えなければ。

目立つっていうのは、聞かれる前からみんなが君のことを話題にするっていう意味なんだ。

君のキャリアにとって本当に重要なのは昇進でも昇給でも無い。重要なのは、そういう成果を得るために努力した時間だ。もっと重要なのは、そういう成果とは関係ないところで努力した時間だ。

• 並行コンピューティング技法 第１章 » tune web
• 並行コンピューティング技法 第２章 » tune web
• 並行コンピューティング技法 第３章 » tune web

◯第４章 マルチスレッドアプリケーション設計の8つのルール
・8つのルール

1. スレッド化設計モデルに加えるべきルール、順不同。
2. 真に独立した処理を特定する
3. 並行性はより上位で実装する
4. コア数増加に備えスケーラビリティ対応を早期に計画する
5. スレッドセーフなライブラリを使用する
6. 適切なスレッドモデルを採用する
7. 実行順序を前提としない
8. ローカル変数を使用する、できなければロックで保護する
9. 並行性向上のためのアルゴリズム変更を恐れない

・ルール1: 真に独立した処理を特定する
これが最も重要。 処理が互いに独立していなければ並行実行できない。

・ルール2: 並行性はより上位で実装する
並行性を見つける方法は2種類ある。

• ボトムアップ
• トップダウン

どちらを選ぶにせよ、より上位で並行化した方が良い。 アルゴリズムの上位レイヤほど、より多くの独立した処理を含んでいるからである。

・ルール3: コア数増加に備えスケーラビリティ対応を早期に計画する
今後もプロセッサコア数は増加の一途であることが予想される。 開発中のソフトウェアであっても、このことは考慮に入れておくべき。

並行性の設計はタスク分解とデータ分解の2種類があったが、 アプリケーション内の独立した処理とデータサイズではデータサイズの方が増える傾向が強いため、 データ分解設計の方がスケーラビリティーでは有利である。

設計中のソフトウェア/システムが計画している処理能力を十分に達成できても、 将来要求される処理能力は増加する可能性が高い。 処理能力に余裕があれば、処理するデータはまだ誰かが持っている。

・ルール4: スレッドセーフなライブラリを使用する
車輪の再発明は決していい方法ではない。 一般的なライブラリ関数で置換可能であればそれを使うこと。

使用の際には、マニュアルを参照してライブラリがスレッドセーフであるかを必ず確認する。 自作ライブラリなら関数がリエントラントであるように設計する。

・ルール5: 適切なスレッドモデルを採用する
スレッドの明示的な使用(Pthread/Windowsスレッドの直接的な利用)は避けるべき。 抽象化ライブラリ(OpenMP/Intel Threading Building Blocks)を通してスレッドを利用すること。 多くの並行化作業はスレッドを明示的に操作する必要があるほど柔軟性が求められておらず、 実装が複雑になるとバグが入る可能性が高くなる。

開発上の規約などにより、抽象化ライブラリの使用が禁止されている場合でも、 プロトタイプは抽象化ライブラリを使うことで手間を省くことが出来る。

・ルール6: 実行順序を前提としない
スレッドの実行はOSなどのスケジューラで管理されるものであり、 アプリケーション側で順序を決定することは出来ない(非決定性がある)。 スレッドがどんな順序で実行されても正しい結果を返すように設計すること。

また性能の観点から、出来る限りスレッドの実行に制約を課すべきではない。 例えばスレッド処理の待ち合わせをするときは本当に必要か立ち止まって考える必要がある。

・ルール7: ローカル変数を使用する、できなければロックで保護する
同期処理は必要悪だが、最小限の使用に留める必要がある。 共有変数の更新が少ないほど、オーバーヘッドも少なく済む。

まずはスレッドごとに持たせるローカル変数で問題が解決出来ないかを考える。 駄目なら適切なロックを共有データに対して適用する。 デッドロックの温床となるため、1データに対して複数のロックを対応付けてはならない。

・ルール8: 並行性向上のためのアルゴリズム変更を恐れない
逐次処理では最良だったアルゴリズムが、並行処理では最良でないことがある。 並行化出来なかったり、他のアルゴリズムの方が並行化による恩恵を受けやすいことがある。

◯第５章 スレッドライブラリ
・抽象化ライブラリ
スレッドの制御(作成・管理・同期)を抽象化し、プログラマに楽をさせてくれるライブラリ。 スレッドを明示的に作成する処理は無く、柔軟性は落ちる。

・OpenMP
専用のpragma、指示文(ディレクティブ)、環境変数を用いて並行処理可能な部分を指定する。 並行実行コードはコンパイラにより生成される。 並列環境と非並列環境でほぼ同一のソースコードを使用できるという利点がある。

スレッドの管理はfork-joinモデルを採用している。 マスタスレッドが並行処理可能な領域(パラレルリージョン)に到達すると、子スレッドが生成され(fork)、 各スレッドがパラレルリージョンを実行する。 パラレルリージョンの終了時には子スレッドが待ち合わせ(join)、 パラレルリージョン後からメインスレッドが処理を続行する。

・Intelスレッディング・ビルディング・ブロック
並列アルゴリズムが定義、実装、提供されており、 並行処理がカプセル化されたクラスを通して使用する。 商用バージョンとオープンソースバージョンがある。

・明示的スレッドライブラリ
PthreadとWindowsスレッドがある。提供される関数は大差ないはず、必要に応じて調べて使いましょう。

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

posted with amazlet at 10.04.11

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

Amazon.co.jp で詳細を見る

photo credit: drdaeman

makeplex salon：あなたのスキルで飯は食えるか？　史上最大のコーディングスキル判定 (1/2) – ITmedia エンタープライズを解いてみました。ソースはtune’s itmedia_makeplex at master – GitHubに上げてありますのでリビジョンも見れるようになってます。最初のコミットを上げるまでに、面子の表示順の違いを抑えるところで詰まってチンイツの待ちを出力するプログラム – 107143955443560を参考にしました。参考にしましたというよりもC++のソースをRubyに移植しましたと言う方が近いほど同じ処理です。基本的なアルゴリズムは最後まで踏襲しています。

最初のコミットまでが3時間ぐらい、リファクタリングに1時間ぐらいです。ちょっと時間がかかりすぎですが、日常的に書いてないRubyで、日常的にプログラムしてない家のMacパソコン、プラグインが古いのか5分に1回落ちてしまうMacVimで時間がとられたと言い訳しておきます。ただの実力不足です、ごめんなさい。

成立する可能性がある面子を減らしながら、総当たりで探索しています。面子の順序違いによる重複表示を避けるのが結構面倒ですね。刻子を優先して探さなければならず、色々試行錯誤してみたのですが、参考にさせていただいたid:staebchenさんよりも良さそうな方法に達しませんでした。もっといいやり方があると思いますが、参考まで。

#!/usr/bin/ruby

class Array
  def sum
    s = 0
    self.each do |v|
      s += v
    end
    return s
  end
end

class Fixnum
  # 刻子
  def anko
    num = self+1
    "(#{num},#{num},#{num})"
  end

  # 順子
  def shuntsu
    num = self+1
    "(#{num},#{num+1},#{num+2})"
  end

  # アタマ
  def atama
    num = self+1
    "(#{num},#{num})"
  end

  # 単騎
  def tanki
    num = self+1
    "[#{num}]"
  end

  # リャンメン(ペンチャンも兼ねる)
  def ryanmen
    num = self+1
    "[#{num},#{num+1}]"
  end

  # カンチャン
  def kanchan
    num = self+1
    "[#{num},#{num+2}]"
  end

  # シャボ
  def shabo
    num = self+1
    "[#{num},#{num}]"
  end
end

#
# 雀牌を表す数字列を解析し、0〜8の配列に与えられた個数を入れて返す
#
def parsePai(str)
  pai = Array.new(9, 0)
  str.split(//).each do |p|
    pai[p.to_i-1] += 1
  end

  # 入力の妥当性チェック
  if pai.sum != 13 then
    # 与えられる牌は13枚
    raise RuntimeError
  else
    pai.each do |val|
      if val > 4 then
        # 1種類の牌が4枚より多いことはない
        raise RuntimeError
      end
    end
  end

  return pai
end

#
# 手牌を再帰的に解析し待ちを表示する
#
# 順子を刻子に優先して探索する。
# 順子はfromが9〜18の時に探索される
#
def analyzeTehai(pai, from=0, mentsu=[])
  shuntsu_phase = 9
  skip_anko_check = false

  if from >= 9 then
    skip_anko_check = true
    from -= shuntsu_phase
  end

  if pai.sum > 4 then
    # 面子を揃える

    # 刻子
    unless skip_anko_check then
      from.upto(8).each do |i|
        if pai[i] >= 3 then
          tmp = pai.dup
          tmp[i] -= 3
          analyzeTehai(tmp, i+1, mentsu+[i.anko])
        end
      end
    end

    # 順子
    from.upto(6).each do |i|
      if pai[i]>=1 && pai[i+1]>=1 && pai[i+2]>=1 then
        tmp = pai.dup
        tmp[i] -= 1
        tmp[i+1] -= 1
        tmp[i+2] -= 1
        analyzeTehai(tmp, i+shuntsu_phase, mentsu+[i.shuntsu])
      end
    end

  else
    # 残った4枚から待ちを絞る

    # アタマを探す
    0.upto(8).each do |i|
      if pai[i] >= 2 then
        tmp = pai.dup
        tmp[i] -= 2
        analyzeMachi(tmp, mentsu+[i.atama])
      end
    end

    # 面子(刻子 or 順子)があれば単騎待ち
    # 刻子
    unless skip_anko_check then
      from.upto(8).each do |i|
        if pai[i] >= 3 then
          tmp = pai.dup
          tmp[i] -= 3
          analyzeTanki(tmp, mentsu+[i.anko])
        end
      end
    end

    # 順子
    from.upto(6).each do |i|
      if pai[i]>=1 && pai[i+1]>=1 && pai[i+2]>=1 then
        tmp = pai.dup
        tmp[i] -= 1
        tmp[i+1] -= 1
        tmp[i+2] -= 1
        analyzeTanki(tmp, mentsu + [i.shuntsu])
      end
    end
  end
end

#
# 4枚から待ちを絞る
#
def analyzeMachi(pai, mentsu)
  0.upto(8).each do |i|
    # リャンメン(ペンチャン)
    if pai[i]==1 && pai[i+1]==1 then
      puts mentsu.sort.to_s + i.ryanmen
    end

    # カンチャン
    if pai[i]==1 && pai[i+2]==1 then
      puts mentsu.sort.to_s + i.kanchan
    end

    # シャボ
    if pai[i]==2 then
      puts mentsu.sort.to_s + i.shabo
    end
  end
end

#
# 単騎待ちの数字を調べて待ちを表示する
#
def analyzeTanki(pai, mentsu)
  # 単騎待ち
  0.upto(8).each do |i|
    if pai[i] == 1 then
      puts mentsu.sort.to_s + i.tanki
    end
  end
end

# 以下実際の処理
pai = parsePai ARGV[0] unless ARGV[0] == nil
analyzeTehai(pai)

photo credit: TANAKA Juuyoh (田中十洋)

早いもので大学院修士卒で働き始め5年目に突入しました。4年間も働いていれば色々なことがあるもので、同期入社の友人が退社したり、同期同士の結婚式に呼ばれたり、海外赴任もいれば、自分のように同じ業務をこなし続ける人もいます。仕事は一貫して同じ内容ですが、異動はあって上司は4人変わったし、私生活では結婚して子供もできました。4年間は短いようで振り返るといろいろありますね。

今日から新年度ということもあり、色々な方が新社会人にエールを送った文章を書いているかと思いますが、自分も4年前の自分に教えたいことをまとめるつもりで書いてみます。リクルーターに選ばれる機会もなくて自分で振り返りをしないといつか忘れちゃうのも理由の一つです。ちなみに私の仕事はカメラやコピー機を作っているメーカーの研究開発職(ソフトウェアエンジニア)です、会社名まで知りたい人は2006年の5月あたりの過去ログを探すとわかるんじゃないかと思います。大学で情報処理を学んでいて、将来はメーカーで働きたいなんて人のお役に立ちますように。

◯これから就職活動を始める方へ
自分が就職活動をしていたときに気にしていたけど、今となってはどうでも良くなってしまったことです。

• その会社の社風
• 長く勤められる企業かどうか
• 初任給

ベンチャーならともかく、社風は気にしすぎない方がいいと思います。
大きい会社になればなるほど事業部や部門によって雰囲気がぜんぜん違います。気になるなら何とかしてそこで働いている人にコンタクトを取ってご飯を食べながら話を聞くのがいいかと思います。今ならtwitterで呼びかければ誰かしら見つかるのではないでしょうか? もちろん真摯な態度でお願いする必要はありますが。

「リストラはしない方針」、「外資系だけど日本文化も取り入れた日本企業」、「長く勤められる会社に行きたい」もアテにならないですね。リストラしないというのはこれまでしてこなかった過去の結果を言ってるだけで、この先不景気にやればやらざるを得ません。この不景気なご時世だから信じてかかる人のほうが少ないかと思いますが。自分が就職活動で第2希望に挙げていた外資系の企業は昨年研究所を閉鎖してしまいました。20何年間の歴史があっても終わるときはきます。長く勤められる会社を探して寄生するよりも、どこの会社でも生きていけるスキルを持っている方がいいですよね。自分のキャリアは自分で作りましょう！ 情熱プログラマーの受け売りです。

初任給がそのままの給料の会社もあれば、しばらくは「研修期間」で少しすると(ウチの場合は修士卒だと1年)ぐっと上がる会社もあります。実際に働いている人に聞けば手取りでいくら貰えているのかすぐに教えてくれるので新卒の募集要項なんて見てないで聞いてみるのがいいでしょう。

やっておいた方がいいのは自分が行きたい「部門」で働いている人へのインタビューと、できるならインターンですね。私の大学院の指導教授は「どこそこの会社に行きたい」と言ったらその会社の組織図を使ってどこに行きたいのかと指させましたが、とても理にかなっていると思います。「就社」でも当面の間働くのは配属先の部門ですからね。大学で情報系を学んでいてもプログラムが好きな人ばっかりでは無いと思います。私の毎日は朝から晩までC言語とにらめっこをしていますが、駄目な人は駄目みたいです。根性や気合でどうにかなるものではないので早めにわかっておいた方がいいでしょう。

◯アウトプットは将来の履歴書
ブログなり、Mixiなり、Twitterなり学生の頃は暇に任せて使う時間がありますが、就職するととたんに更新頻度が落ちて、使う人が減っていきます。会社での成果は当然会社に帰属するので、ただ毎日を過ごしていると自分の社会人になってからの成果を示すものが何もなくなってしまいます。自分の会社は学会活動も活発ではないので、転職することになって何か出せと言われたら特許公報でも持っていくしかありません。最初から転職ありきでブログを書けというつもりはありませんが、何かしら社会人になってからの自分の成長を書き留めておくアウトプット先があるといいでしょう。会社の業務も秘密のものばかりではなくて、よくよく見てみるとブログに書けるような一般性が高いものもあります。でもどこかに書き留めておかないとそれに気づくことも出来ないでしょう。

ネットがあれば履歴書はいらない-ウェブ時代のセルフブランディング術 (宝島社新書)

posted with amazlet at 10.04.01

佐々木 俊尚
宝島社 (2010-01-09)
売り上げランキング: 1307

Amazon.co.jp で詳細を見る

◯新卒が即戦力足り得ないのはその会社のルールを知らないから
持論ですが、どんな能力を持った人も入社してから半年は立たないと本来の力を発揮出来ないのではないかと思っています。会社には独特のルールや文化があり、それを踏まえて動かないと思ったように成果がでないことが多々あります。最悪なパターンに「事前の根回し」がありますが、それ以外にも小さなところで考慮すべき点はあります。例えば「その技術は会社の事業にどう貢献するのか」、「顧客にどう付加価値を伝えるのか」、「特許的な問題はないのか」、「製品アーキテクチャを考えて十分なパフォーマンスが出るのか」、「事業部の方針と提案する技術はあっているのか、興味を持ってもらうにはどう話したらいいのか」などなど、ベテランになるほど暗黙のうちに受け答えのパターンを作ってしまって気づかない点です。最初はしかられたりして落ち込むこともあるかもしれませんが、学ばなければならないルールを一つ気づくことができたと割りきってどんどん失敗するのがいいと思います。先輩も上司も失敗しない新入社員なんて期待していません。

◯仕事は自分で楽しくするもの
これも情熱プログラマーの受け売りです。エキサイティングな業務もあれば、つまらない業務もいっぱいあります。資料集めでネットサーフィンを延々とやるとか、PowerPointファイルを1ヶ月ぐらいこねくり回すとか、上司に指摘された修正をその上の上司に覆されるとか、いっぱいあります。
こういう時に発想の転換をして「いかにネットサーフィンが快適な環境を会社につくるか」、「今度の資料ではプレゼンテーション Zenを取り入れてみよう」と視点を変えてみましょう。

◯「この上司は分かってないな」と感じたら、上司に情報が十分に伝わってない可能性を疑うこと
「上司が分かってないのは仕様だ」というツッコミも来そうですが、私のアドバイスとしては、まは自分の伝え方を疑ってみることをおすすめします。上司はなぜそう判断したのか考えて、分からなければ聞いてみましょう。

「これからはクラウドだ」と言う上司にきちんとクラウドの動向情報をインプットしましたか? プライベートクラウドが駄目な理由を伝えましたか? クラウドで何ができるか事例を調べてメールで送りましたか? 飲みの席でDropboxとかEvernoteとか見せびらかしましたか? 上司に伝える情報を偏らせて自分の望む方向に誘導するのはやりすぎですが、「分かってない」と落胆する前に出来る限りのことをしましょう。

◯身だしなみを大切に
新入社員研修でお互いに毎朝プレゼンするというのがあったのですが、今でも覚えているのは「毎週靴の手入れをしましょう」というものでした。靴の磨き方は靴の手入れなど検索すればすぐに見つかりますが、実践している人は少数かと思います。自分も実践してみた(今でも隔週ぐらいで革靴の手入れをしています)のですが、足元を気にすると全体の身だしなみにも注意が行くようになります。

WordPressに貼っつけたものがほとんどなのでSearch Regexを使って一括置換で対応出来ました。もっと速くに気づくべきでしたね。まぁ便利なWordPress Pluginを見つけられたのでよしとします。

フジテレビの深夜放送を追いかけ続け、ようやく見終わりました。録画に失敗した回は全部で2回、うち1回は巨人の優勝による放送時間の変更だったのでかなりの確率で録画できたんじゃないかと。もっとも録画の成功は妻によるところが大きいのですが・・・シーズン8はぜひ1週間の集中放映に戻して欲しいのですが、どうなるのでしょうか。

内容的には結局いつも通りなのかなという感想です。舞台がワシントンDCに代わって、所属する組織がFBIに変わってもストーリーの作り方がどことなく既視感を覚えます。シーズン8で終わってしまうのは寂しい気もしますが丁度いいところなんじゃないですかね。

「今まで見てなかったの？」というぐらい遅れていますがようやく見ました。Pixarの映画の中でもピカイチで面白かったと思います。設定も面白く、ラストも綺麗な終わり方でした。

娘がもうちょっと大きくなったらぜひ一緒に見たいと思います。娘が気に入ったらDVDも買ってあげないとな。文句なしに5ツ星です。

• 並行コンピューティング技法 第１章 » tune web
• 並行コンピューティング技法 第２章 » tune web

「第３章 正当性の検証と性能測定」

◯第３章で学ぶ内容

1. 誤りの無い並行アルゴリズムをきちんと設計できたかをどう確認するか
2. 並行ソースコードが”十分に”並列動作しているかをどう確認するか

◯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倍までしか速くならない。

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

posted with amazlet at 10.03.28

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

Amazon.co.jp で詳細を見る

ということで、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ユーザの方は一度試してみることをおすすめします。

実用Git

posted with amazlet at 10.03.23

Jon Loeliger
オライリージャパン
売り上げランキング: 16867

おすすめ度の平均:

翻訳の質が低くて残念

Amazon.co.jp で詳細を見る

言いたいことは全てAmazonに投稿されている書評で言ってもらった気がします。

翻訳の質が低くて残念です。
すでにgitについてある程度の知識を持っている人でないと、そういったミスリーディングな翻訳文から真の意味をつかむのは難しいと思います。
「入門git」と「入門Git」を制覇して次のステップを目指す人が、翻訳のまずさを自力で補う覚悟のうえで買うのなら、よい本です。

駄目な本かというとそうではなくて、Gitについてこの本より詳しく記述された文章はネットでもないので貴重だと思います。個人的にもgit-svnの使い方が大変勉強になりました。そこだけで3000円ぐらい払っても惜しくないぐらいです。たまに出てくる意味が取りにくい訳がなければ星4つ、O’reilly独特の言い回しが邦訳で取り払われていれば星5つだったと思います。

Gitのオブジェクト管理についてはWEB DB Press Vol.50でも、入門Gitでも紹介されていますが、この本が一番詳しく、説明が丁寧で、わかりやすかったです。Gitをじっくり学びたい人におすすめです。使いたいだけなら入門Gitでいいでしょう。

• Subversion, Git, Redmine, Hudson – 現状の連携 » tune web
• Subversion, Git, Redmine, Hudson – 今考えている連携 » tune web
• Subversion, Git, Redmine, Hudson – 今考えている連携2 » tune web

ネットワークが切り離された外部チームとのやりとりは結局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先生も分散バージョン管理で間違いないって、ベイビーと言ってるほどなので分散バージョン管理に移行しましょう!

映像だけが取り柄のB級大作映画。長いくせに前半がグダグダなのでそこで見限らないように注意が必要。

ロボットがかっこいいんだけど何度も変身してると飽きてくるし、敵か見方か一見してわかりにくいのもマイナスだと思う。

吹き替え版で見たんだけど、主役級ロボットのオプティマスプライムの口調がおかしくて仕方がなかった。子供の頃は大好きだったはずなんだけど…

GO TO DMC! GO TO DMC!! GO TO DMC!!!

ということで、原作を読んでいた自分ですが、割と忠実に映像化してくれていて楽しむことが出来ました。Amazonのレビューの焼き増しになってしまいますが序盤急ぎ足でエピソードが消化不良なのと、オリジナルのラストがイマイチだった以外は登場キャラが皆ハマリ役だったと思います．

• 並行コンピューティング技法 第１章 » tune web

「第2章 並行か非並行か？それが問題だ」

◯大前提
全ての処理を並列化することは出来ない。世の中には並列化が不可能な処理があり、何がそうなのか知っておく必要がある。並行化できないアルゴリズムは以下が代表例。

• 状態を持つアルゴリズム
• 漸化式
• 帰納変数(ループの度に値が増加する、ループ変数とは1対1に対応しないインデックス)
• ループ内の処理依存

◯並行アルゴリズムの設計モデル
順序に依存しない処理を並行に実行する「タスク分解」と、大量のデータの個別の部分を並行して処理する「データ分解」がある。
どちらを選んでも基本のフレームワークは変わらない。タスクを準備し、スレッドへ処理を割り当て、次の処理へ進む前に全てのタスクが完了したことを確認する。

◯タスク分解
スレッドに割り当てるタスクを抽出する難易度はソースコードや処理内容に対する理解に反比例する。良く知っていればタスクの抽出も容易になる。タスクを簡単に見つけ出す裏技はないが、処理時間を多く占めるホットスポットにおいて、ループに着目するとそこがタスク抽出に適していることが多い。数値計算もタスク抽出のポイントとしておすすめ。

抽出したタスクの数にもポイントが有る。まずタスクの数はスレッド数(≒コア数)と同じ数以上にする。これはアイドルスレッドを避けるためである。次にタスクの粒度は出来るだけ大きい方が良い。これは並列化によるオーバーヘッドが生じることが影響している。タスクが大きい方がメモリキャッシュが効くなど性能面で有利な点がある。

タスク同士の間には2種類の依存性がある。1つ目は順序の依存で、あるタスクが他のタスクの処理結果に基づいて実行される場合が該当する。2つ目はデータ依存で、変数の使い方で問題が生じることがある。

タスクの割り当ては最初に決めてしまう静的割り当てと、動的にタスクを決める動的割り当てがある。タスクの処理時間が固定の時は静的割り当てが簡単でオーバーヘッドもなくてよい。処理時間にばらつきがある場合は動的にタスクを割り当てる必要がある。

◯データ分解
基本ルールはタスク分解と同じ。分割する数はスレッド数よりも多くする、細かすぎると並列化によるオーバーヘッドが問題になるので大きい粒度で。処理対象となる分割されたデータ領域をチャンクと呼ぶ。チャンク分割はタスクの粒度と境界長の比率が最大になるように分割すると良い。

チャンクの境界において、別チャンクのデータを参照する必要があると工夫がいる。簡単なのは境界部分を予めスレッドごとにコピーしておく方法がある(ゴーストセル)。そうでなければ処理時に必要に応じて参照させる方法があるが、参照対象のデータが未処理の場合、参照処理をまたしておく必要がある。どちらも一長一短がある。

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

posted with amazlet at 10.03.11

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

Amazon.co.jp で詳細を見る

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

あまり話題にもならなかった気がするし、そこそこな映画かなと思っていたのですがかなり楽しめました。実際の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-〇〇というフォルダができていてそれを使っているようです。

@V字回復の経営【書評】 - livedoor Blog（ブログ）" href="http://blog.livedoor.jp/tabbata/archives/50679863.html">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も扱えるよ」という情報をお持ちの方がいらっしゃいましたらぜひ教えてください。

→2010年5月2日 解決しました Windows/Linux両環境で動作するC言語ソースの一元管理をGitで行う » tune web

• 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級映画です。期待してみるとがっかりする人が続出するんだろうけど、夏の深夜放送に流れてるのを偶然みたとしたらすごく楽しめるんじゃないかと。

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

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