マーベル・コミックの映画化は当たりがとても多い。本作はスパイダーマンからダークなところを取り除いた娯楽作という印象を持ちました。

主役のラプンツェルとフリン以外に、カメレオンと馬が愛嬌があってなかなか可愛い。
娘が最初から最後まで飽きずに観れた! 凄いかも!

最近機内でiTunesレンタルした映画を見て時間を潰しているのですが、音量を最大にしてもセリフが聞き取りにくいことが多いので思い切ってノイズキャンセリングヘッドフォンを購入しました。他の国は分かりませんが、香港ではBOSEのお店で買っても日本よりも安く購入できます。ビックカメラやヨドバシカメラの2/3ぐらいの値段かと思います。

機内で聞ける音はBOSEのお店で体験できるデモとほとんど同じです。完全に無音になることはないのですが、音はかなり聴きやすくなります。街中で常用できるものではありませんが、何度も飛行機やフェリーに乗る現在の生活だとそれなりにペイできそうです。

豪華アクション俳優陣が揃っているのにオーシャンズ11のように感じさせない稀有な映画。序盤はちょっと期待が持てたけど後半に行くに従って銃撃戦だらけになってしまったのが残念。

観始める前は期待していなかったのですが、観終わった今ではライトニング・マックィーンのグッズが欲しくなるぐらい引き込まれる映画でした。グッズがメーターを押している割にはこっちには余り惹かれなかったんだけど…

iTunesの映画レンタルで観ました。最初はリチャード・ギアがなかなか好きになれなかったものの、途中までは想像がつくストーリーだなと思っていたので最後のシーンはやられました。
なんて役者なんだろうとびっくりして調べたらエドワード・ノートンでまたびっくり。それもデビュー作だったなんて…

観終わった後はなかなか面白かったかなと思ったんだけど、ネットの評価はそんなに良くなくて以外。
余り期待しないでみたのが良かったのかも。

キャラクターに愛嬌があってなかなか可愛い。終わってから何かの映画に似てるなーと思ったんだけど、カンフーハッスルにそっくりだ。

これもネタ的には5月頃の話なのですが、Nexus Sを購入してみました。たまに来る家族に貸すためという名目もありますが、Android端末を触って勉強してみたかったのが一番の理由です。アップデートもなるべく早く、なるべく長く対応して欲しかったのでGoogleのNexus Sを自然に選択しました。

当初は違和感がかなりあったのですが、ある程度アプリのカスタマイズに慣れてくると使い勝手は限りなくiPhoneに近づけることが出来ます。びっくりしたのは充電の持たなさですね。量販店で買って、サービスで替えのバッテリーを付けてくれたのですが、8時間も持たないのならそりゃつけてくれるよねとあとで納得しました。

これももちろんSIMフリー端末なので、次回の日本出張にはおともに連れていこうかなと考えています。

かれこれ5年使っていた財布の小銭入れ部分が破けてしまい、4月に日本出張へ行った際に修理をお願いしていました。愛着がある財布だったので修理して使おうと思っており、当初は3000円ぐらいという話だったのですが最終的に買った時よりも高い値段での修理となりました。このモデルはもう作ってないらしく、日焼けを楽しむBREEの財布なのでまた1からやり直すのもなと思い、何かおかしいと感じつつも修理をお願いしました。

財布がなかった3ヶ月ぐらいは「かわりの財布でも十分使いやすいな…」と感じることもありましたが、戻ってくるとやはり愛着がある財布はいいです。せっかくなのでもう5年頑張ってもらいます。

すごい映画なんだと思うんだけど、解説をよく読んだ上で見るのと、何の情報もなしに見るのだと評価が大分異なるはず。自分は事前にかなり勉強してから見たんだけどそれでも分からない所が多すぎる。

不覚にも泣いた・・・ 沈まぬ太陽と間違えてレンタルしちゃっただけだったのに・・・

よく分からなかったのがあれほどのハッカーがなぜ学内SNSのアイデアにあそこまで可能性を見たのか? あの頃はもうMyspaceとかあった気がしたんだけど… 気のせいだっけ?

震災後に見ると「何が新エネルギーだよ」と突っ込んでしまう。
盛り上がったのは前作の主人公バド・フォックスが登場した時かな、あとはあまり印象に残らなかったので残念。

どこかでこういう映画見た事あるなと感じたのですが、どことなくMatrixに似てると思いました。

この前日本出張に行った時にどうしても購入したくて東京駅地下にあるNHKグッズショップで購入してきたコッシーの椅子カバー。NHK教育を見せながら子育てをしている親は見たら絶対購入するだろうグッズのはずなんだけど、NHKは宣伝とかしないから認知度が著しく低い気がします。子供用の小さい椅子に括りつけるとコッシーくんになるというそれだけのカバーですが、我が家にコッシーがいるようでなかなかいいです。

椅子になかなか座らない娘のために買ったのですが、食いついたのは最初だけで、今ではどうも本物のコッシーだと思ってしまい、遠慮して座りません。うーむ。

Amazonでも買えるよ。

みいつけた!コッシーにへんしん!なかよしイスカバー

posted with amazlet at 11.05.15

セガトイズ (2010-08-05)
売り上げランキング: 725

Amazon.co.jp で詳細を見る

あまり期待しないでみたんだけど突き抜けてて最高に楽しめた。映画である意味は多分ないんだけど、続編はぜひ見たい。

蘇州で泊まったホテルからの眺め。これまで出張で行ったホテルの中で最もコストパフォーマンスがよかった! こんな広くて立派なホテルに日本のビジネスホテルよりも安く泊まれるなんて中国素敵。1泊しか出来なかったけど次は連泊したい。

蘇州から国内便で北京へ移動。無錫の空港の周りは何もなくって中国の大きさを実感。

無錫空港は元々軍事空港だったらしいのですが、中は割と綺麗でした。

北京に移動して、仕事を済ませ夜の移動中に見かけた面白い形のビル。テレビ局とのことです。地震とかあったらすごく危ないと思うんだけど…

飛行機の搭乗時間まで時間があったので、ちょっとだけ北京観光に付き合ってもらいました。故宮や万里の長城をおすすめされたのですが、一度見てみたかったのでオリンピックスタジアムに行ってみました。

鳥の巣の中の写真。今でも立派なスタジアムなのですが、余り使われていないらしく、痛みや汚れがちょっと目立ちます。まだ3年しか経っていないのに。

名前は知らないけど見覚えがあったのでパチリ。

鳥の巣の隣にあるプールもついでに見学。鳥の巣よりも綺麗だけどこっちもあまり使われてないのかな。

中国本土自体が初めてでしたが、どちらの都市もまた来たいと思う出張でした。次はもう少しゆっくりした出張日程を組みたいな。

これまでのハリーポッターシリーズ同様、無難な作り。もはやファンタジー映画の要素はなく、ホラーとアクションものみたいです。

まどろっこしいストーリー展開だなと見ていて感じたのですが、原作を読んだ人にとってはこれでもはしょり過ぎで評価はイマイチみたいですね。

長らくPowerShot G7を使っていましたが、妻の強い希望で購入。
こんなによく撮れるカメラが3万ちょっとで買えてしまっていいのでしょうか?

ズームは余り出来ないけど、明るく取れてスナップ写真が綺麗にとれるのでかなり満足しています。フィルタやイフェクト機能も最近のカメラは結構付いているんですね。

Canon デジタルカメラ Powershot S95 PSS95 1000万画素高感度CCD 光学3.8倍ズーム 広角28mm 3.0型液晶 F2.0

posted with amazlet at 11.04.03

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

Amazon.co.jp で詳細を見る

を日本で見て、

を新横浜ビックカメラで確認。

その後…
キヤノン：電子辞書 wordtank発売延期のお詫び

メーカーズシャツ鎌倉トップ-MAKER’S SHIRT KAMAKURA via kwout

香港で仕立てたほうが安くて良いシャツが買えそうなんですが、どうにも行く時間が作れなそうなので日本出張時にしこたま買い込んできました。何度か二子玉川のお店に足を運んだことがあったのですが、その時は購入までには至りませんでした。今回みなとみらいの店舗に行ってみたところ、品揃えも豊富で手頃な値段のシャツが多数おいてあってので3着試しに買ってみました。

同じ値段の他のシャツと比べると素材や作りがしっかりしていると思います。オーダーもそんなにしないようなので次はオーダーをしてみようと思います。

帰りの飛行機で見たのはこの映画。TVシリーズも前作の映画も一度も見たことがない自分でも楽しめました。毎週のドラマも見てみようかな。

日本出張時の機内で見ました。続編のウォールストリートと両方選べたのですが、まずは第１作からだろうとこちらを選んでみました。まさか帰りの飛行機では続編が見れないとは…

我が家はiPhone2台&iPad体制なので発表された時から目を付けていました。香港のお店でたまたま見つけたので即購入、これで充電ケーブルの悩みから開放されると思ったのですが、いくつも問題がありました。

• 1番は子どもがすぐ触ってしまうため、机の上に置けないこと。これは買う前から想像していました。
• 2番はケースをしているとうまくはまらないこと。ケーブルを少し出す必要があり、抜き差しに時間がかかります。
• 3番は質感が想像以上に安っぽかったこと。1万円近い製品ですが、何にこんなに金がかかっているのか謎です。

とりあえず充電用と割りきってどこかに置けないか検討中です。iPadさえなければ他にも製品があるのですが、なかなか出てきません。あまり需要が無いんですかね。

仕事以外に目を向けると楽しいことだけでなく大変なこともありました。特に私の家族にとっては子供の面倒をみつつ、引越しの準備をして、さらに言葉が通じない生活が始まりストレスも大きいと思います。いいことがあったり、いやなことがあったりする毎日ですが、これも日本では得られない経験と考えて前向きに過ごしています。
赴任して良かったと最後に思えるよう、来年も家族協力して香港を楽しみたいと思っています。

色々と出歩いて大分香港も案内できるようになりましたので、2011年はぜひ香港にも遊びに来てください。

実はこれ香港で売ってないんですよね。香港では音楽配信すらまだ始まっていません。
でも電圧は香港のも対応しているし、ケーブルは世界共通だし、つなぎさえすれば簡単に使えました。何気にAppleの製品は世界どこに出荷することになっても電圧・アクセサリはおろか、言語もほぼ網羅されているので安心出来ます。

セットアップも特に戸惑うこと無く簡単に終わりました。しいて言えば電源の消し方が分からなくて困ったぐらいです。iPhoneのように明確な電源ボタンがなく、一定時間操作がなければ勝手に止まるようです。

香港はネットも早いのでレンタル映画もスイスイ見れます。レンタルビデオ店が撤退などで近くに無いのでこの製品はとっても活躍しそうです。とりあえずトイ・ストーリー３を家族で見てみました。こんなに便利に見れていいのでしょうか。

旅のおともに酔い止め、英語だと「Motion Sickness Drag」。マカオは船で行くので妻のために購入。

今回泊まったのはTAIPAにあるベネチアンホテル。マカオでも指折りの大きさを誇るホテルで、全室スイートだそうです。一見豪華に見えるけど作りが雑なのはこのへんの中国共通ですが、広さだけはものすごいです。

このホテルのウリは下にショッピングモールがあって、人工の運河があり、ゴンドラに乗ることが出来ます。日本で言うとビーナスフォートに運河を引いて、ディズニーランドのゴンドラアトラクションをつけたような感じです。ゴンドラは混んでて乗れませんでした。

世界遺産もちらっと見てきました。ですがクリスマスのせいかどこも飾り付けられていて、ちょっとざんねんな感じです。

天気がいまいちでしたが、時間が少し余ったのでマカオタワーにも行ってきました。高さはかなり高く、足がすくみます。次はスカイウォークかバンジージャンプにチャレンジしてきたいところです。

街も綺麗だし、ご飯も美味しいし、きっと来年も行くと思います。
香港へ遊びに来る方は3泊4日コースだとマカオにも行けますよ。

最近アニメでも漫画でもワンピースから離れていたから結構楽しめたのかも。よく良く考えてみたら劇場版ドラゴンボールとかと対して話の筋は変わらない気がする。ワンピースの映画としては…よく出来てるぐらいのものかも。

日本のテレビがインターネット経由で見られるサービスを申し込みました。仕組みはロケフリやその他類似サービスと同じだと思います。ここのサービスは加入するとセットトップボックスを設置しに来てくれて、関東と関西の地上波、BS放送が見れるようになります。画質はSD品質(アナログ)ですが、来年からはハイビジョンにも対応するそうです。

少し画像は汚いですが、見てればなれる程度です。ハイビジョンの画質も少し見せてもらったのですがとてもきれいでネット経由で見ているとは感じないほどでした。夜一時的につながりが悪くなったり、セットトップボックスの反応がたまに悪くなったりしますが概ね満足しています。

1週間の全局放送内容を自動で録画してくれて、月に480HKDです。かえって日本よりもいいテレビ環境になってしまいました。

welcome to Jitakutv.com

スタンドは2箇所あるようですが、今回はリスボアシートを選んでみました。長い直線の後のコーナーが前車を抜く要所になっていて、スリリングな駆け引きが見れる人気シートのようです。コーナーには少し距離がありますが、かなり前の席でモニターも見やすく当たりの席でした。

見たレースは2種類、市販車をベースにしたものと、F3です。クラッシュも度々起こり、セーフティーカーが頻繁に入るレースでした。

PowerShot G7を持って行きましたが、コンデジではこれが限界です。F3とはいえ、スピード早いですね。

リスボアシートの近くにある「グランドリスボア」ホテル。カジノも立派で香港とは違った雰囲気です。

昼ごはんはグランドリスボアの中にある麺屋で刀削麺を食べました。これで500円ぐらいなので、かなりコストパフォーマンス良いです。

街もきれいで街歩きも楽しそうです。マカオが気に入ったのでクリスマスに今度は家族で行ってきます。

• MacauTicket – Macau entertainment, show tickets, News, informationを訪問
• マカオグランプリのチケットを選択、リスボアシートというのがいいらしい。
• 必要な項目を記入して購入を進めれば良い、基本ネットショッピングと一緒。
• “Pickup”という項目があるが、これはチケットの受け取り場所のこと。香港は1箇所しか無い模様。
• 香港でチケットを受け取る場合は1週間前購入だとダメっぽい(チケットが届かない)。
• 直前の購入だとお店を直接訪問するのがいいみたい。
• 購入番号を後で表示する方法がなさそうなので必ずメモすること、紙に！ Evernoteを使ったら購入番号だけ消えててあとで困った。
• 購入後のメールは送られてこない、チケットは自分で取りに行かないと送られてこない。

“Pickup”を「当日入場するときのバスの乗り場(富士スピードウェイのF1をイメージ)」だと思って、マカオのフェリー乗り場を選んだんですが大失敗でした。香港のチケット売り場にピックアップしに行ったら「そんなチケットは届いてない」ということで、結局購入時の席をキャンセルして取りなおしてもらいました。

ともあれ初めてのF3、少し予習もして来週末楽しんできます。

ソルトよりもおすすめ。セブンみたいに、次の犯人の行動をどきどきして期待することができた。観終わってから振り返ると、あの犯人何がしたかったんだと思うけど、途中まで映画の雰囲気は良かったと思う。

2は想像の範囲内だけど、3は反則。飛行機の中で涙してしまった。
3つ揃えてDVDを買ってもいいぐらい、素晴らしいシリーズになったと思う。

来週、日本へ出張へ行くのでおみやげを調達してきました。奇華餅家というお店で売っているパンダクッキーです。香港のおみやげ選びはモノが少なく難しいらしいのですが、このクッキーはわりかし評判がいいようです。

でも今回これ使っちゃうと、次また悩まないといけない…困りましたね。

「性格が歪んでしまった」わけではないので、最近の自分の考えを整理して残しておきます。

ソフトウェア開発に多少明るかったこともあり、日本にいた頃から「周囲への啓蒙」、「伝道師の役割」を期待される場面が少なからずありました。日頃ブログで情報を発信している人には組織で似たような役割を演じている人も多いのではないかと思います。バージョン管理、テストの整備、開発プロセスの改善、後進エンジニアの育成、便利なツールの紹介などなど… 新しい技術や新しいやり方を広めようとすると反対者が少なからず出てきます。それぞれ言い分があって

• メリットがわからない。
• 成功するのか(効果があるのか)怪しいものだ。
• 私は今のやり方で困ってない。

辺りがメジャーな反論ではないかと想像します。あと滅多に口には出てきませんが「私のやり方に口出ししないでくれ」や「手柄をたてようとしているあなたが気に入らない」というのもきっとあると思います。

アドバイスを何度か繰り返すと、あるとき提案が受け入れられるタイミングがでてきます。「トップダウンの命令で仕方なく」もありますが、私が考える一番成功しやすく、効果が出るタイミングは「聞き入れる側が”本当に困っている”」ときです。

例を挙げてみましょう。ある会社Aで作られたプログラムを、いろいろな理由から別の会社Bへ管理を移し後継モデルの開発に取り組んだところ、大量のバグがでてきたことがありました。会社Bでは同じ過ちを繰り返さないよう次期モデルの見積りを念入りに行い、そして計画案が出てきました。改善する箇所を絞って品質を改善するというもっともな計画ですが、一言「ところで改善する箇所はどうやって決めたの? どうやって改善していくの?」と聞いたところ「改善箇所はA社から引き継いでよく分からず、バグが多かった(気がする)ところを選んでいる。改善方法は”1行ずつソースを読んでから考える”」との解答でした。

私は「1.ユーザは改善の効果を体験できるの? 2.ソースが複雑なところにバグは入り込みやすいよ。 3.ソース読んでも時間かかるだけで、元の仕様なんて分からないよ。」というコメントを出してみました。これをきっかけにB社はいろいろな質問をだしてきて、「1.処理時間を測ってボトルネックを改善してね。 2.ソースの複雑度を測ってね。 3.テスト書いてね」といったこちらからの3つの改善提案が前向きに検討されています。逆の順番で、提案を先に行ったらどういう反応があったでしょう? 「前の開発でも勝手な要求ばかりでスケジュールがかなり押したのに！こっちの開発を邪魔してほしくないものだ！！」と思われたのではないかと思います。

私が思うに世の中には直面している問題を正しく認識できてない「困ったふりをしている人」がかなりいて、こんなことをよく言っています。

• 昔からやり方はこうだった。
• ルールがこう決まっている。
• どうしようもないんだよね。何かいい方法ない?

人から指摘されても、その人にとっては現状を言ってもらったに過ぎず、「改善すべき問題」ではありません。「問題ではないので、アドバイスも効果が無い」のかなと思います。

アドバイスなり啓蒙活動をするには、まず問題を認識させる必要があるというのが私の今の考えです。手を変え品を変え取り組まないといけません。これまでのやり方では問題が起きるようにわざとお願いしてみたり、いやでも認識出来るぐらい問題が大きくなるまで放置してみたり… これが冷たいと言われたら返す言葉がありませんが…

そういえば困ったふりをしている人は「問題を大きく捉えすぎて何から手をつけていいのか分からず、とりあえず普段は放置している」パターンもありますね。このタイプの人は定期的に同じような話題で相談してきて、アドバイスしても3日坊主で終わることが多い気がします。

photo credit: Kinologik

香港の会社でもWeb閲覧制限がされているものの、日本よりも若干緩いようでこれまで使えなかったサービスが割と使えたりする。試してみて明らかに駄目だったのはtwitterぐらい。香港でもみんなやってるのだろうか?。

就業中でも使えるようになったWebサービスのうち、一番便利なのがGoogle Calendar！日本にいた頃は社内スケジュール管理ソフトが決められていて、わざわざGoogle Calendarに同じ情報を家で入れ直すのが面倒で放置気味だったんですが、会社で規定のスケジュール管理ソフトが無いのでGoogle Calendarに集約し始めたところすごく便利！見やすいし、動作も早いし、一人で使っているのがもったいぐらいです。

ただ、このスタイルに慣れ過ぎると日本に戻ってからが苦労しそう。

photo credit: TheTruthAbout…

問い合わせたらこんな回答が来た。ちょうどカードの切り替わり時期と香港赴任時期が重なって、ネット上や実生活でいろんなところから使っていたのが不正利用のパターンに引っかかった模様。確かにわからないこともないな。

平素は三井住友カードをご利用いただきありがとうございます。

先日は、カードご利用の際にスムーズに
ご利用頂けず、ご迷惑をお掛け致しましたこと
を深くお詫び申し上げます。今回ご決済いただけ
なかった原因は、弊社セキュリティーシステムによる
もので会員様のカードには、一切問題なかった
ことをご報告申し上げます。

近年、盗難・偽造に遭ったカード又は、インターネット上
にてご本人様も気付かないうちに不正使用される犯罪が
増えております。
そこで弊社では不正使用防止の観点から金額に
関わらず、過去の様々な不正使用パターンに
類似した取引があったすべての会員様に対し
まして、コンピュータが一時的な保留をかける
セキュリティーシステムを導入させて頂いております。
これにより、不正使用防止に効果を上げている
一方、今回のように会員様にご迷惑お掛けして
しまうこともございます。

弊社と致しましては、今回の事態を厳粛に受け止め、
セキュリティーシステムの精度向上に努めて参る
所存でございますのでどうか今後とも弊社カードを
ご利用賜ります様宜しくお願い申し上げます。

何にせよ使えるようになってよかった。

日本だと今更な感じですが、家の下にある映画館でちょうど「秋の映画祭」にかこつけて上映していたので見てきました。9月に1と2を上映して、10月１週目に3をやったようです。「続編ものの最新作だし、てっきり日本人しか見に来ないだろ」とたかをくくっていたのですが、どうも日本人が僕一人で、あとは香港の人だったみたいです。みんな字幕を見てセリフよりも速く反応するので笑いや驚きのツボがずらされます。

映画の内容自体は自分としては大変楽しめました。コネタを挟みすぎて、続けてみて無いと楽しめないという意見もあるんでしょうが、これだけつづいているシリーズなので、私はこれでいいと思います。ぜひ4も期待したいところです。

今回1番驚いたのが、中国から研修に来ているワン刑事が空手で犯人をやっつけるシーンですね、香港人大喜び。日本人がカメラ持って名刺交換して回るのと同じくらいステレオタイプだと思ったのですが、そういうのも受け入れちゃってるんですかね。

暗殺者ジェイソン・ボーンが最初の任務での出来事を悔いて贖罪する…話だったと思うんだけど、あまり感情移入できなかったな。アクションは相変わらず素敵なんだけど。

マット・デイモンがジミー大西にしか見えないんだけど、アクションはやっぱり凄いと思う。動きが滑らかで見ていて気持ちいい。

主演の女の子がかわいいと思ったんだけど、ラン・ローラ・ランの主演の子なのね。こんな顔立ちだったかな…

前半と後半が全然別のストーリーみたいでびっくり。評価も話の展開についていけた人と、ついていけなかった人で2分されている。見て驚くという意味では確かに驚いた。傑作ヒーロー物かというと…ちょっと違うかも。

あとAmazonの以下のコメントが参考になった、裏はとってないけどあってるかな?

講釈：
ジョン・ハンコックはアメリカ独立宣言書に最初に署名した人物で、密貿易も行っていた商人であるが、独立戦争を財政的に支えた。
彼の署名は人一倍大きく他人の目を引いたので、John Hancockは署名の代名詞となった。
主人公が記憶喪失するほど負傷し入院した病院から退院する時、窓口で書類に署名するよう「Put your John Hancock」と求められた。
自身の名前すら忘れていた主人公は署名欄にJohn Hancockと署名、彼はそれ以来ジョン・ハンコックとなった。

映画見ていてずっと疑問だったんだよね。

写真で見たことある景色…なんですが、この日はあいにく霧模様でいまいちですね。夏の香港は霧がよく出るようなので、秋以降がいいかもしれません。

この日のお昼は展望台の中にあるBABA GUMP SHRIMPを選んでみました。フォレスト・ガンプをテーマにしたレストランです、全然香港らしく無いですね。調べてみたら日本にも3店舗ぐらいあるようです。

食べたのはSHRIMPER’s HEAVEN(エビ好きの天国)という、蒸したエビやエビフライがいろいろと楽しめるセット。これにビールをつけて2000円ぐらい、味もまぁまぁ。次はエビ好きの妻を連れてこないと怒られるな…

お店をでたところでお店のマスコットキャラクターに遭遇。カメラを向けたらにこやかに手を振ってくれました。名前はなんて言うんでしょう? 娘が見たら泣きそうな風貌です、ごめんよシュリンプくん(仮)

家の近くにある映画館で見てきました。日本語情報なしで映画を見たのは初めてでしたが、ちょっとハードルが高かった気もします。大体のストーリーの流れは終えたのですが、物語の肝心なところになると英語が聞き取れませんね。家に帰ってからGoogle先生に色々と教えてもらいました。

以下の記事がよくまとまっていておすすめです。

• 結局、ディカプリオは現実に戻れたの？ 『インセプション』の感想＆考察まとめ – はてなブックマークニュース
• 【ネタバレ】 映画「インセプション」を語るスレ ：アルファルファモザイク

ニンテンドーDSi LL ナチュラルホワイト

posted with amazlet at 10.09.13

任天堂 (2009-11-21)
売り上げランキング: 173

Amazon.co.jp で詳細を見る

ソフトは無難で、長く楽しめそうなやつを2本購入

アルティメット ヒッツ ドラゴンクエストIX 星空の守り人

posted with amazlet at 10.09.13

スクウェア・エニックス (2010-03-04)
売り上げランキング: 448

Amazon.co.jp で詳細を見る

ゼルダの伝説 大地の汽笛(特典無し)

posted with amazlet at 10.09.13

任天堂 (2009-12-23)
売り上げランキング: 125

Amazon.co.jp で詳細を見る

今更感漂う買い物ですが、時期を外しているだけあって値段はどれもお手頃でした。

買い物するところは少しずつバリエーションを増やしているところですが、なんだかんだで日本と同じお店に行ってしまいます。写真はホンハムという街にあるジャスコです。ジャスコ以外にも食品系ではアピタがあったり、ユニクロはあるし、無印良品はあるし、吉野家はあるし、香港は日本人にとってかなり住みやすい街です。

香港は競馬が盛んと聞いて楽しみにして来たのですが、ちょうど夏休みと重なってしまい、まだ競馬を観に行けていません。先週末から再開したそうなので、近々都合をつけて見に行ってみようと思います。香港には2つの競馬場があり、写真に写っているのは毎週水曜日の夜にレースが行われるハッピーバーレー競馬場です。開催日程は日本の東京シティ競馬みたいですが、この競馬場は社交場的な要素が強いそうです。写真には写っていませんが、クラブメンバーの施設もすぐ近くにありました。この競馬場、トラックの内側は運動場がびっちり詰まっていて、開催日以外も開放しており、中を散歩することもできます。

観光と言ってもお寺ぐらいしかないのですが、乗り物は早めに一通り乗っておきたいと思ってロープウェイの先にあるNgong Ping Villageというところに行ってきました。山頂に大仏があるのですが、屋外にある大仏としては世界最大らしいです。観光地らしく外国の方もたくさんいました。上りのロープウェイは混雑するようなので、香港島から船で山の裏側に回り、バスで山頂まで行くルートがおすすめです。詳細に知りたい方は連絡ください。

9月5日にはホテルをチェックアウトして、契約した家に入居しました。場所は九龍駅の真上で、空港にも電車一本で行けるアクセスが良いところです。ただ買い物が…ちょっと不便ですね。日本では会社の社長になっても、同じようなところに住むのは難しそうなので、これはこれでいい経験かもしれません。

前の家は6帖の2部屋をつなげてリビングぽく使っていましたが、今回はちゃんとしたリビングルームつきです。ソファーも置けてくつろげますね。ホテルも悪く有りませんでしたが、やっぱり自分の家は落ち着きます。次の問題は洗濯ですかね、香港の家はベランダが無いので…

仕事の関係で中国本土には3回出張に行きました。2回が深セン、1回が珠海です。深センは会社の取引先の方が車を出してくれて英語の通訳もしてくれましたが、珠海は1人での行動が多く中国語しか通じないことからかなり苦労しました。今でも中国語の勉強は合間を見てやっていますが、こういう経験がないとヤル気に火が付きませんね。

iPhone4はまだ買えてません。街中でプレミア付き(3万ぐらい?)で売ってるのはよく見かけるようになりましたが、キャリアからの購入は相変わらずの大渋滞です。この前売り場の人に聞いてみたら4週間ぐらい待ってもらってるそうなのでもう少しだと思うのですが。香港を堪能するためのアプリはたっぷり用意したのに、出番がなくて残念。

◯1日目 8/6

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

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

◯2日目 8/7

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

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

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

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

香港島へはスターフェーリーで渡れる。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だそうです。仕事で使っているけど新たに学べることがあるかなと思って迷います。