羽岡哲郎ブログ

ネットエイジを生きる一員という自覚があるのなら，たまには自分をググってみるべきだろう．そう思って，久しぶりに ググってみた ところ，意外な発見があった． 発見１：ブログランキングされている minakoe.jp というところで， ブログランキングされている ことを知った．順位は年間で268263位で，上位33.5%にいるらしい．ご丁寧に偏差値まで出してもらっているが，どうせ正規分布には程遠いファットテール型の分布だろうから，あまり意味はないだろう．それから，勝手にリンクなどの統計データまでとってくれている．頼んでもいないのにここまでやってくれるのはすごい． 発見２：古いブログが上位に 今のブログ（このブログ）よりも，古いブログのほうが上位に表示される．一番上は，そのブログのプロフィールページだったが，先ほどページを削除したので，そのうち表示されなくなるだろう．このことは，つまり，現在のブログが，SEO的に劣っていることを示している．ブログのスタイルに問題があるかもしれない． 発見３：TweetBuzzというサービスがある TweetBuzzというサービスが取り上げていた ．これは，ツイッターのなかでURLのあるツイートを収集し，クリッピングと，ランキング情報などを公開するサービスのようだ．これを見ると，いまツイッターで話題のサイトが分かるという仕組み． 発見４：ランニング大会結果は見当たらない 少し前までは，自分を検索すると，ランニング大会の結果が一番上位に表示されたものだった．そして，その次に，大学のころ書いた研究発表論文などが表示されていた．それが，いまでは検索結果2ページ目以降に表示されるようになり，ランニング大会結果はほとんど見当たらなくなった．結果の公開基準が変わったのかもしれない．すこしさみしい． とまあ，こんな感じで発見があった．今後もときどき自分をググって，SEO的視点からも自分を眺めてみようと思う． あ，そういえばライフネットからもEKIDENカーニバル出場するそうだ．当日見かけたら一声おかけすることにした．勝負になるといいんだが．．．何せ練習不足なもので．．．

現代ビジネス：「国債金利の上昇＝日本国の破綻」は間違っている を読んで，簡単なメモを． 眠い．．．と思えば，もうすぐ2時か．．． つまるところ，著者が言いたいことは，最後の「名目GDP成長率４％以上にせよ」ということのようだ．そうすれば，「理論上は破綻しない」と．しかし，４％以上という数値はかなり高い水準である．ここ15年の日本GDPはほとんど横ばい．ゼロ成長なのだ（下のグラフを参照）．実質GDP成長がせいぜい2%だとすると，残りの2％は期待インフレレートで膨らませるしかない．これを安定に実現する政策はあるのだろうか． まとめ： イギリスの例は，「日本の債務超過が即破綻につながるわけではない」ということを示している． しかし，「日本は破綻しない」ということを示しているわけではない． 「名目GDP成長率4％以上の維持」の実現はかなり困難 国を破綻させないためには，プライマリーバランスをプラスに安定させることが欠かせない．（当然か）． ところで，４％という数値は，日本の現在の税率をもとに算出しているから，その前提が変わったら，例えば，法人税率や所得税率が最大20％になったりしたら，この値はもっと大きくなるはずだ．そうなると，ますますその実現は困難になるよなぁ．．． ああ，だんだん何考えているか良くわからんくなってきた．寝よ．

EETimes から Viewpoint: Maximizing the value of your IP という記事の要約を紹介．これは， Jasper Design Automation Inc. のフォーマル・ベリフィケーション・ツールの広告記事． 現状，RTLの再利用が加速している（現在チップの3分の1，これが，2015年には50％まで増加すると予測されている）．そこで問題になるのは，レガシーRTLの検証工数過小見積もりによる，工数爆発．仕様書やテストベンチがあるが，結局信用できるのはコード（RTL）そのもの． 既存のテストベンチの問題点については，「RTLそのものよりもデカい検証環境がそんざいすることはよくあること」と書かれている． there typically exists an enormous verification environment that is larger than the RTL itself これは，私の経験でも実際見てきた．RTLも巨大だったが，テストベンチのコードは超大盛りのスパゲッティであった． RTLに手を入れる必要があるときに，そんなテストベンチと格闘するのは無駄．代わりにフォーマル・ベリフィケーション・ツールを使って，RTLの動作が変わっていないことを保証すべし．これが実現できれば，IPの再利用は格段にやりやすくなる．つまり，IPの資産価値が高まる，というわけ． A revolutionary approach to answering these time-wasting reuse questions is to decouple the RTL from the large, unwieldy, constrained-random simulation testbench and extract answers from the design itself, through a new application of formal verification technology called Behavioral Indexing. 私の感想 私の前職で，ビデオ・コーデックの開発に関わっていたときには，フォーマル・ベリフィケーションは一部で使用されていたにすぎない．まあ，ほとんどのモジュ

いま我が家では，ちょっとした問題を抱えている．それは，簡単にいえば，子供を抱える共働きの家庭で，ワークライフバランスをとることが困難であることだ．この問題に，ロジカルシンキングで立ち向かおうとしているところだ． 共働きで，二人とも通勤時間が片道1時間以上，そこに，1歳未満の子供がいる．この4月から保育園に通わせ始めたが，通勤時間が往復2時間以上にもなるので，家で食事を食べさせたりしていると，そのほかの時間はあっという間になくなってしまう．それに，子供が熱を出したら保育園を休ませなくてはならない．どちらかが会社を休んで面倒をみることになる． このような状況で，妻のほうが，「もっと職場にちかいところに引っ越そう」と提案してきた．なるほど，通勤時間が減れば，それだけ生活時間にゆとりができるのだから，仕事との折り合いもつけやすいし，通勤で消費するエネルギーを他に回すことができる． ならば，どこへ引っ越すか．．．とPCに向かおうとして，「ちょっと待て」と思った．「それが本当に問題を解決するのか？」そうなのだ，まだ問題の根っこに到達していなかったのに，ある現象だけをみて「モグラたたき」を始めようとしていたのだ． というわけで，まずは「分析」だ．ロジックツリーに分解して，問題の本質にせまらないといけない．そう考え直した．今日のところは，このフェーズ．ここから，1か月の間に解決策を提示できるように，仕事とバランスをとりつつ，考え抜いていく． 思考が煮詰まってきたら，またここで紹介したいと思う．そして，最後にどういう意思決定を行ったか，紹介する予定．

「Googleを支える技術」を読んでいてふと思ったのだが，自分の四半期決算レポートをつくるのはいいアイディアだ，早速始めたい． 話が飛びすぎただろうか．この本には，グーグルの開発姿勢が書かれていて，そこでは，各自の評価が四半期ごとにレポートにまとめられるということが書かれていたのだ． 「決算」と言っても，自分の金融資産を評価するわけではない．自分の目標管理のことである．だいたい元旦に目標を立てるが，ぼーっと過ごしていると，いつの間にか大みそかを迎えている．そこで，もう少し短い期間で評価する仕組みを作るほうがいいと思うわけだ． 週単位，日単位くらいでもやるべきなんだろうけど，その頻度ではレポートを作成するオーバーヘッドが大きくなりすぎる．そこで，四半期がちょうど良さそうだと思ったのだ． というわけで，今度のレポートは6月末の半期決算になるかな．

最近，ひょんなところから情報が転がり込んでくることが多い．だいたいツイッターから入ってくることが多いのだが，今日も， ライフログ・サミット2010 というのを偶然知って，「ライフログ」に関する研究が，情報大航海プロジェクトの一部としてすでに行われていることを知った． このライフログ，自分の行動や発言などをこと細かく記録してくれるもので，その膨大なデータをもとに，いろんなサービスを提供しよう，というのがコンセプトにある．私は，こういうのが前から欲しいと思っていたのだ．ツイッターでかなり近いことができるが，まだ自分が能動的にアクションを起こさないと記録されない． ライフログの利用法については，残念ながら，ライフログ・サミットのウェブサイトには，思いつきとしか言えないものしか書かれていないが，この忙しい現代において，いろんなことをとりあえず全部データベースにぶち込んでおいて，あとで必要な情報を検索出来れば大いに助かる．もう日記をつけるひつようも無いし，撮った写真を毎回アルバムに整理しなくても良くなるのだ． とまあ，夢が膨らむライフログなのだが，どうもこのサミットはあんまり盛り上がっていなさそうな雰囲気を感じる．そもそも，この手の会合が，日経や政府主導で行われている時点で熱気などとは程遠い世界に行ってしまっているだろう．それに，まだサービスが普及してもいないのに，法律家が顔を出す時点で何かおかしいと思う． このあたりの，スピード感の無さが，日本の弱点になっているのではなかろうか． これがアメリカだったら，まず実現可能なところからサービスが登場し，ユーザーの増加とともに新しい機能が追加され，より使いやすい形に進化していく形態をとるだろう．グーグルしかり，ツイッターしかり． 法制度上も同じだ．アメリカでは，「法的な問題は起こってから対処すればいい」というスタンスだから，新しいことを始めやすい．これが日本だと，まず法整備から入ろうとするから，何事も遅々として進まない．それに，法のグレーゾーンが多すぎるので，合法と考えて事を始めても，後出しジャンケンで潰されることも多々行われてきた． 今日は，偶然ライフログプロジェクトが走っていることを知ったのだが，同時に，その将来性の無さも感じてしまった．やはりライフログも，ツイッター発展の延長線上にある可能性が高いと

ソフトウェア開発やハードウェア開発の現場では，よくコードレビューが行われるようになってきた．その目的は，まだ完全でない状態のコードを読むことによって，なるべく早い段階で問題点を取り除くことだ． そのようなコードレビューについて調べていると，森崎修司氏がとても有益な情報を発信されていることを知ったので，いくつかここにリストアップしておく． @IT連載「ソフトウェアレビュー入門」 IBM技術文書「コードレビューの道具、使っていますか？

"The Adventure of Sherlock Holmes" を読んだのだが，時代の違いなのか，いろいろと慣れない表現が良く出てきた．例をあげると，"except"のように使われる"save"という単語や，"because"の代わりに決まって"for"が使われていたり．そして中でも印象に残っているのが，"fancy"という動詞．これは文脈からの推測なのだが，どうやら"guess"のように使われている． それぞれ，原文から用例を引用してみよう． save There was not a soul there save the two whom I had followed. for You are to watch me, for I will be visible to you. fancy I fancy that this grey house on the right must be the lodge. 辞書を引いてみると，fancy は　guess とはやや違う意味合いのようだ． fancy v. (-cies, -cied) [trans.] 1 feel a desire or liking for: do you fancy a drink? 2 [with clause] imagine; think: he fancied hi could smell the perfume of roses. "The New Oxford American Dictionary" より引用 2番目の imagine; think が当てはまるだろう．「想像する」という意味が含まれる．しかし，1番目の用法も気になる．want の控え目な表現というところか． fancy というと，形容詞の「装飾された」という意味を想像しがちだったが，語源は "fantasy" なので，「空想」という意味合いから，そういう用いられ方につながったのだろう．そして，「想像」・「空想」から「欲する」とつながる． そうだ，このエントリを書くにいたった理由が

『ウイスキーの科学』古賀邦正著，を読んだ． ウイスキーを幅広く科学的な視点から分析しているのが，面白い本だ．モルトやグレンといった材料の話から入り，製法を詳細に説明したあと，あの風味が生み出される仕組みの科学的分析を試みている． 驚くのは，これほど科学技術が発達した現代でも，熟成する樽のなかで何が起きているのか，いまだによく分かっていないことが多いということ．ブレンドして加水したあとも，「1か月置かないと味が落ち着かない」という言い伝えも科学的には解明できていないらしい． そんな謎に包まれていることを知ると，ますますウイスキーの魅力を強く感じずにはいられない． そういえば，つまみには，ナッツやチョコレートなどが定番だそうだ．先日，甘いものということで，どら焼きを試してみた．「山崎10年」とはとてもよくマッチしていた．ストレートがおススメ．「マッカラン12年」でもやってみたところ，悪くないが，やや香りがぶつかる感じがする．あんこの甘さには，さわやかなジャパニーズが合うのかもしれない．

日本の成長性を取り戻すにはどうすればよいか．キーはやはり，次代を担う若者（私も含め）にあると思う．その若者の覇気が無い．それは様々な現象として表れている．例えば，外国に留学する学生が減少している．大学生の就職先人気企業は，活気のない年老いた日本の大企業ばかり．．．などなど． 若者に覇気が無いのは何故かと考えてみると，結局のところ，既得権益にしがみつく年寄りのせいだと思う．若者が頑張って会社を立ち上げても，大きくなって既得権益が脅かされそうになってくると，あらゆる手を使ってつぶしにかかる．ホリエモンの逮捕が象徴的である． そういう老人たちの姿を観てきた若者に対して，「たちあがれ」と言ってみたところで，白々しく聞こえる．若者だって馬鹿じゃない．自分の人生を台無しにするような賭けに手は出したくない． そんな社会で，社会起業家を目指す若者が増えているのはなんとなくわかる気がする．若者だって，「何か意味のあることをやりたい」という気持ちを持っている．だけど金儲けをやりすぎると潰される．「社会事業ならそんなことはないだろう」というわけだ．でも，これは，老人たちにいいように飼いならされているということなのかもしれない． ところで，誤解なきように言っておくが，社会事業だって利益を上げないことには話にならない．ボランティアと混同している人もまだまだ多い．そう考えると，社会事業だって，既得権益を脅かす存在になれば，老人たちの攻撃をうけることになることに変わりはないだろう． それで，日本を再生するにはどうするか，というと，この「老人たち」をなんとか排除しない限り，無理なんじゃないかと思う．どうやってやるか？これは難題だが，一つの方法は，「ハイパーインフレを起こして，日本経済を強制リセットする」というもの．それでも本当にリセットするのは難しいだろうが，きっかけにはなると思う．

JavaではSE5以降、enumの実装が変わり、「制約つきのクラス」という感じの扱いになったのだが、それを使っているコードを眺めていて、コードクローンが量産されているケースに出会った。以下がその例である。 新しいenumでは、メンバを持てるようになったのだが、同じようなenumを定義したいときには、同じコードがそれぞれのenumで実装されることになる。これが100個とかになると、コードクローンが量産されてしまうのだ。 どなたか、これをリファクタリングしてコードクローンを取り除いていただけないだろうか。ひょっとすると、これはenumの使い方を間違っているのだろうか。 enum Enum1 { A("01"), B("02"), C("03"); public final String code; private Enum1(String code) { this.code = code; } } enum Enum2 { T01("001"), T02("002"); public final String code; private Enum2(String code) { this.code = code; } } public class Main { public static void main(String[] args) { Enum1 e1 = Enum1.A; Enum1 e2 = Enum1.B; System.out.println(e1.code); switch (e2) { case A: case B: case C: } } } 以下、私が短い時間で試行錯誤した結果をメモにしておく。 まず思いつく改善策は、「基底クラスを抽出して、そこに共通要素をまとめればいい」

「私の中のあなた」映画のDVDを観た．昨秋に小説を読んで，いい作品だったので，ぜひ映画も見てみたいと思っていた． そして，映画も良かった．．．小説のストーリーを踏襲しつつも，また一味違う作品に仕上がっていた．小説の「私の中のあなた」と映画の「私の中のあなた」は若干意味が異なっていて，それぞれいいなぁと思える．一つのストーリーで二度楽しめると言う感じかな． 小説はドラマチックな感じだが，映画のほうがより自然に受け入れられる感じかもしれない． そういえば，この小説との出会いも，ランニングがきっかけだった．何か一つでも一所懸命になるものがあると，そこから芋づる式にいろんなものに出会える気がする． 映画を紹介してくれた，はっちさん，ありがとう！あなたは，最高のセンスを持っています！これからもいろいろ紹介よろしく～． 「私の中のあなた」公式サイト

昨秋，小説を読んでから楽しみにしていた，「風が強く吹いている」をDVDで借りてきて観た． 細かいことはいい．とにかく，ランニングの素晴らしさがあふれているいい映画だった． 私だって一応，ある程度本格的にやっていた市民ランナーなので，素人集団があんなに簡単に箱根駅伝に出場できるなんてファンタジーだと思う．だけど，そんな細かいことどうでもいいと思えるほど，すがすがしい気持ちになれる映画なんだ． 「走るってなんだろう？」．ランナーにとって，これは永遠の問いかもしれない．人類にとって，「生きるってなんだろう？」という問いと同じだもの． というわけで，この映画は，私の中では， イチオシ なのであります． よーし，明日からがんばって走力つけるぞ！ 「風が強く吹いている」公式サイト 「風が強く吹いている」公式ブログ 「風が強く吹いている」ウィキペディア・エントリ

今日は思い切って，投資信託の整理をした．去年スタートした積立の成績が軒並み良かったので，総じてプラスのリターンだったが，全体では，+14%のリターン． 中でも，「欧州新成長国株式ファンド」が37%のリターンと抜きんでていた．まずは，こいつの3分の2を解約．「30％のリターンを得たら，とりあえず利益確保しておけ」と言われている．30%と言っても，投資額が少ないので大した額ではないのだが． そして，19％のリターンだった「フィデリティ・アジア株・ファンド」は全額解約．こちらは投資額がもっと少ないのであまり儲かっていない．さらに，手数料が高いのでおいしくない．やはりファンドは，手数料が低いものを選択すべきだ． あとは．．．「チャイナ・オープン」「トピックス・オープン」か．．．リターンが出ているうちに売り抜けてしまうかな．これは週末考える． 問題は，換金してこしらえた現金をどこに投入するか．．．悩ましいなぁ．FXと，ショート型のファンドも考えてみるか．．． 話は変わるが，昨日買えなかった，「Webを支える技術」を買った．良い本との前評判が高いので，かなり期待している．．．

今夜は時間が無いので，一日のメモをまとめておく程度にしておこう． まず書店で本を買いこんだ．ほんとは，「Webを支える技術」を買いに行ったのだが，置いてなかった（まだ発売前だったのか？）．そのまま帰ればいいものを，気が付いたら5冊も買いこんでいる自分に気付いた． 「Googleを支える技術」 「基礎からのサーブレット／JSP」（いまさら？感もあるが．．．） 「高校数学でわかるボルツマンの原理」 「ウイスキーの科学」 「うまい酒の科学」 独立行政法人「酒類総合研究所」というのがあるらしいぞ． と，ここまで書いて，PCが激しくうなり始めて，ふっとんだ．今回は，ESET（アンチウィルスソフト）が暴走したようだ．強制シャットダウンしたが，管理者権限だったら，プロセス殺せたのかも．． 本屋では，「コワ～イ不動産の話」というのが目に留まって，「今狙い目の土地リスト」を見てガッカリした．過去3年間の人口流入量だけしか見ていないんだもん．それで「買い」と言うのであれば，過去3年間の人口流入量と，その後10年間の土地価格上昇との相関を示さないといけない．それが無いから，とても安っぽい本に仕上がってしまっている．残念だ．．．ということは，こういう統計をきちっとやって，「買いリスト」を作ったら，結構いい情報になるかもな．．と思ったりした． 後は，IT関連の良い情報源： ソフト開発／Web開発関連の良質な情報： http://keicode.com/ COM研究室： http://atata.sakura.ne.jp/com/chap5.html それから，これからの携帯スタイルとして， B-Mobile SIM とSIMロック・フリー携帯の組み合わせが，とっても魅力的である．でも，どうやってこんなに安くしているのか不思議．なんせ，インフラはドコモのFOMAなんだから． そういえば，GmailとTwitterを連携してくれるiPhone Appはないかな．

昨晩遅くから，強い腹痛におそわれている．不思議なことに下痢にはなっていない．結局ときどきやってくる痛みのピークで目が覚めてしまい，昨夜はよく眠れなかった． 原因は不明だが，心当たりとしては，前日まで子供がウィルス性腸炎に罹っていて嘔吐と下痢が大変だったことがあげられる．ロタウィルスに良く似た症状だったので，それがうつった可能性が高い． 今日は朝から会社を休んで，療養中． その間にWordPressのブログを始めてみたりしたが，自由度ではBloggerに勝るものがないことが判明．Blogger以外では，自分でサイトを立てるしかないかな．WordPress.comの良いところは，モバイルテンプレートがしっかりしていること．それから，各種設定もUIが洗練されていて使いやすい．しかし，Bloggerから離れるほどのメリットは感じなかった． 今日の記録：（2010年4月6日） 5:00 起床（腹痛で目覚める） 5:10 体温 37.2　度 6:00 朝食（おかゆと梅干） 7:30 体温 37.0 度，会社休む連絡入れる． 9:30 近所の内科受信．ウィルス性腸炎ということで，内服薬を出してもらう． 10:00 昼寝 11:30 体温 36.7度　昼食（おかゆ） 12:00 昼寝 14:00 体温 37.9度　アイスノン使用開始 16:30 体温 38.0度 19:00 体温 38.3度 19:30 夕食（おかゆと梅干） 翌日(4/7) 6:00 体温 36.5度 お腹の調子は万全ではないが，熱が下がったので，通常通り出社．記録はここまで． Twitter friend から得た情報だが，今日4月6日はタイのチャクリ王朝記念日らしい．建国記念日のようなものなのかな．

今日は，とある事情があって，生命保険の非喫煙者特別割引の対面審査を受けてきた．通常は医師の診断が必要なのだが，今回は，携帯のテレビ電話を使った面接による検査だった．なぜここまでするかというと，非喫煙者割引で保険料が25%も安くなるらしいのだ．保険会社もいろいろ考えた末に，こういう方法を考えたのだろう．なかなか無い経験だったので，記録しておこうと思う． で，面接はというと，次の手順で進んだ．この間，テレビ電話で一部始終が監視されている． 名前の確認，および免許証（身分証明書）の提示． 検査を受けることへの承諾書への署名，住所などの記入 唾液採取のための麺棒を口に含む 麺棒をくわえたまま，検体（麺棒）に添えて提出する書類に氏名など記入 麺棒をプラスチックのケースに入れ，キャップを閉めて，名前を書いたシールを貼る それらを郵送用の封筒に入れて完了 この後は，通常の保険の申し込み用紙への記入となった．ただ，ここで一つ問題だったのが，私の健康診断結果に，要再検査項目があったこと．そして，再検査を受けていなかったこと．何が悪いって，大したことなくて，肝機能の数値の一つが若干はみ出ていたくらいなのだが．そのために，「軽度肝機能障害」という，なんとも不名誉な説明書きを添えることとなった． 余談ながら，このときの保険販売員のおじさんもマラソンを走るそうで，前回の河口湖で３時間半のベストを出したそうだ．この４月には長野マラソンを走るそう．先月は初めて月間３００ｋｍを走ったと言うから，そうそう本格的なランナーだ．そんなわけで，マラソンの話題で盛り上がってしまった． 本題に戻ると，このような検査の方法にも改善の余地がありそうだ．ということは，そこにはなにかビジネスチャンスがあるんじゃないかと思う．テレビ電話を使う仕組みにも弱点はある（例えば，身分証明書の偽造は簡単）と思うし，医師の診断だって１００％信用はできない．医療IT化などとも絡めて，いろいろ出来そうなことがありそうだと感じている． もちろん，規制もいっぱいあるんだろうが． 追記：このシステムの穴を一つ見つけた．それは，サンプル発送用の封筒が普通の封筒であること．つまり，セッション終了後にサンプルをすり替えることが出来る（もちろん，エージェントが協力してくれないとダメだが）．これを防ぐには，セキュア

Twitter Bot をGAE上に作ったときに，Twitter4Jというライブラリを使用したが，この中で， OAuth という認証プロトコルが実装されている．その仕組みをよく知らないまま使っていたので，少しばかり勉強してみた． OAuth のスペック には，次のように書かれている． The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication. ウェブアプリケーションがある別サービスのAPIにアクセスするときに用いることのできる，安全な認証方式という感じ． 例によって，@ITに詳しい説明がある（「 APIアクセス権を委譲するプロトコル、OAuthを知る 」）．とりあえず，入門としてこれに目を通したので，次は，スペックをきちんと読んでみる． このプロトコルでは，電子署名のための秘密鍵を扱う場面がある．この手の技術は，なんとなくわかった気になって使うと非常に危険なので，きちんとスペックを読んで，詳細を理解しておかないとまずいことになるのだ． というわけで，またまた読み物が積まれていく．．．

分散バージョン管理システムについて少し調べてみた．有名どころは， Git や Mercurial など．近いうち，実際に使って試してみようと思っている． 分散バージョン管理については， @IT:分散バージョン管理Git/Mercurial/Bazaar徹底比較 の説明が詳しいので，ここを参照すべし． いくつかキーワードを並べておく． 中央レポジトリ ローカルレポジトリ クローン／コミット／プッシュ／プル ロックできない バイナリ不向き TortoiseGit TortoiseHG Eclipse プラグイン もうすぐ仕事に切れ目ができそうなので，そのとき，集中的に試してみることにする．

ツイッターAPIを使ってつぶやいてみた．言語はJavaを使った．便利なライブラリ Twitter4J というのがあるので，それを利用した． まずは，サンプルコードをコピペで実行．OAuthをほとんど理解していなかったので，初めは何をやっているのかなかなか理解できなかったが，なんとなくわかってきた． でも，何をやるかもまとまっていないので，とりあず，Google App Engine 上にボットをこしらえることにした．今は定期的に時刻と「こんにちは」とつぶやくだけだが，今後拡張していこうと思う．

トーストマスターズを始めてから，スピーチのネタを探すようになったが，まだまだ不慣れなので，スピーチ直前まで何話すかまとまらないことが多い．そこで，このブログに，スピーチネタをまとめていきたいと思っている． 自分の実体験を織り交ぜたスピーチの評価が高いようなので，そういうものを書きためていけば，きっといいネタ帳になることと思う． そんなところで，今日はもう寝よう． と思ったが，ラベルを整理していたら，ネタを一つ思いついたのでメモ． メモを書いていたら，PCが固まった．そして全部消えてしまった．何も言わずに勝手に固まるな！ 思いついたネタは，日本人の場所取りについて不思議に思うところ．それは，花見や花火などの場所取りで，シートだけ敷いていてだれも人がいない，というのが結構目につくこと．中には，ガムテープで地面に直接陣地を主張するグループも結構な数いる．で，不思議に思うのは，後から来た人たちは，誰もいない陣地を決して侵さないということ．権利を主張する人がいないにもかかわらず，シートをはがしたりする人はまず見たことがない．これが本当に不思議でならない．これがイタリアや中国だったら，あっという間にシートをはがされてしまうだろう．（これは要確認）． この不思議な行動から，日本人の心理を導くことができたら，面白いかも．それから現在の日本の状況などにも結び付けられるかもしれない．

昨夜，会社で，サービス業としての心構えについてのお説教（というほどでもないけど）を受けた．そのとき，何度も言われたのが，「サービス業（ITコンサルティング）は，メーカーの技術者（前職はデジタル回路設計エンジニア）とは違う」ということ．「同じことをこつこつやっているだけではダメで，きちんと成果をアピールしていく心構えが必要」と言われた． 「アピールが足りない」というのは，要するに，「コミュニケーションが不足」．どんなに努力をしても，しかるべき人に成果を認めてもらわない限り，所詮自己満足に終わってしまうのだ．サービス業では，そこのところが重要ということだ．指定されたノルマだけモノを作ればればいいというわけではない．ごもっともである． それを聞きながら，あえて口には出さなかったが，「エンジニアだって本質はサービス業じゃないか」と考えていた．エンジニアも，技術を提供してお金をもらっている以上，サービス業である．派遣エンジニアはまさにそのものだ． だから，エンジニアこそコミュニケーション能力を磨く必要があると思う．積極的に自分の成果を他人に認めてもらわなければ，収入は頭打ちだし，さらなる成長のチャンスもあまり回ってこなくなり，将来はリストラ対象，となりかねない．一流になるためには，どんな世界でもコミュニケーションが重要だ． また，エンジニアにはチームワークが重要であり，そこにも高度なコミュニケーションが必要となる．周囲との相談なしに勝手に突っ走るのは最悪（私もかつては何度もそんな失敗をやった．．）．たとえ成功を収めたとしても，それはたまたま運が良かったからであって，下手したら，リソースをドブに捨てることになっていたかもしれない．そんなヤツは決して評価されてはならない． こう言うと，チームワークは個々の働きを抑制するような感じを受けるかもしれないが，本当はその反対で，個々の強みを最大限に発揮できてこそ，チームワークと呼べる．そのためには，個々の高い専門能力も必要だが，それをどう生かすのか，自分の立ち位置をしっかり見極められなければならない．本当のチームワークを実現するためには，高度なコミュニケーション能力が求められるのだ． そういうわけで，技術者こそコミュニケーション能力を磨く必要がある．一流になるためには，コミュニケーションは欠かせない． コミュニ

今日は自宅で子供の看病をしているので，日頃できなかったことを片づけている．そのひとつに，このブログをiPhoneで見やすくすることがあった．iPhoneの画面は解像度が低い（480x320）ので（ええーこんなに低かったの～）ので，PC向けのレイアウトだと，記事の部分を拡大してやらないと読むことが難しい． 少し前に，iPhone用の（小さい画面用の）CSSを記述できるということを知っていたので，iPhone用にテンプレートを追加してやればいいことは分かっていた．しかし，いざやってみると，最後の最後で画面幅が縮まらない． 困ったので，ググってみたら，いいサイトがあった． 「Blogger『TicTac Blue』テンプレートをCSS/JSでiPhone対応」 ．まさに，僕のニーズにぴったり．で，どうやっているか見てみると，ガジェットに，JavaScriptとスタイルテンプレートを記述する，というとてもスマートなものだった． その結果，僕のブログがこんな感じに表示されるようになった． めでたしめでたし． 注意として，ガジェットを追加するときには，なるべくページの先頭の要素に置いたほうが，表示が早くなるのでよい．なぜなら，JavaScriptで画面幅の修正を行っているので，それを先に実行するほうがページの再描画が少なくてすむから．

今日は，Visual Studio 上で，C++コードのメモリリークの調査に明け暮れていた．CやC++のメモリリークは実に厄介．アプリケーションが終了するまで検出されないのだから，原因がどこにあるのか特定するのは困難を極める． しかし，長年の蓄積の結果，その苦労を軽減してくれるツールが揃っている．今回は，Visual Studio に備わっている機能を使ってみた．基本的な仕組みを説明すると，メモリ確保のmalloc　や　new　と，解放する free や　delete を，リーク検出の機能をほどこしたもので置き換えてしまう，というもの． 具体的な方法については， マイクロソフトのサイト が詳しい．簡単に書いておくと，まず，リークを検出したいソース(.cpp)ファイルの先頭に，次の３行を追加する． #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> そして，最初に実行される関数本体の中に，次のステートメントを追加すればおしまい． _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); ビルドしてデバッグ実行をすると，メモリリークが検出されたときに，デバッグメッセージに表示される． 試してみたい人は，次のようなコードを書いてみるといいだろう． #include "stdafx.h" #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> int _tmain(int argc, _TCHAR* argv[]) { _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); int *p = new int; // this memory will leak return 0; } これをデバッグ実行すると，次のようなメモリリーク検出メッセージが表示される．MFCを使っていると，ファイル名と行番号まで特定されるのだが．．．Visual C++ 2008 Expre