地下鉄に乗っていて気づいたのだけれど、柴又帝釈天のロゴ と Twisted Matrix Labs のロゴは似ていると思う。
2006-12-05
2006-11-12
藤本篤志 / 御社の営業がダメな理由
職場では営業日報が義務付けられていないし、そもそも私は営業ではないのだけれど、似たようなことは多々あると思う。[営業日報を活かさないのであれば] 三十分で営業日報を書き上げて、一時間半、パチンコに行っている不良社員と、びっしりと欄が埋まっている営業日報を二時間もかけて書いている社員は、結果的に同じ時間しか営業活動を行っていないのです。 (p.98)
派遣というか出向というかで、半年ほど他社の職場で働いたとき、私が1時間ほどで片付けたバグに、他の人が実は数ヶ月もてこずっていたと聞いて、驚愕した。当然、私よりも何倍、何十倍、何百倍も生産性の高い人たちは、石を投げたら当たるくらいいるし、会ったこともある。いや、ソフトウェア業界では当然なのでしょうけれど、目の当たりにしてびっくりしました。
で、営業も似たようなもんなんだろうなあ、と。あと、成果物らしきもの(売上やコード)が出ていても、後で発現する問題(製品選定の間違いやバグ)の後片付けのコストが、成果を上回ることもあるわけで。
愚痴になってきたので、このへんで。
SEライフ編集部 / 実録 SEの履歴書
プログラミングは好きなんだけれど、下手の横好きな私にもできるかも。もちろん、私のプログラミングスキルは、石井氏の足元にも及ばないことは承知の上で。ちょいプログラマであるという自覚があれば、うまく回るんではないか仮説。平凡なプログラマにもできて、しかも、PostgreSQLにとっていちばん役に立つことは何か。それがいまのような形だと思うんです。ビジネスをまわしながら、残った時間で多少はコーディングをさせていただく。 (p.77 石井達夫氏)
2006-10-29
Thomas A. Limoncelli / エンジニアのための時間管理術
原題は「Time Management for System Administrators」なので、「エンジニアのための」という表現は決して正確ではないと思う。ただし、本書で想定しているのは、割り込みが多い仕事に従事し、かつ、スクリプトを書くなどのソフトウェア技能に長けている人である。なので、システム管理者以外でも使えるかと。
絶対にうそをついてはいけない。誰にうそをついたのか、どんなうそをついたのかを覚えておかずにすむよう、真実を述べるほうがよい。そうしないと、何か重要なことのために温存しておかなければならない頭脳に余計な負担をかけるだけである。(p.97)
なるほど。生産性向上のために、正直であることが必要である、と。
上司を査定するための基準が会社にとってふさわしくないものであると感じたらどうしますか。[...] 上司の査定基準を決定した経営陣の判断を信じなければなりません。あるいは、両方の目標達成に向けて懸命に努力します。むずかしそうですか? 会社に何がふさわしいかについて上司の上司よりもよく理解しているほど懸命であるとしたら、両方の目標を同時に達成する方法も難なく見つかるでしょう。(p.132)
世の中には、どうしようもない経営陣が存在しますが、それでも自分よりは頭がいいだろう、と。少なくとも、自分には当てはまっていると思う。というわけで、上司の言うことは素直に聞こう。
プロセスを改善する究極の策は、プロセスを排除することです。自動化するのではなく、排除するのです。(p.159)
捨てる作戦。他にもメーリングリストのキャンセルなど、破棄を推奨する提案が書かれている。RSS リーダやアンテナの登録数を定期的に見直すべきかも。
Thomas A. Limoncelli / エンジニアのための時間管理術
2006-10-25
新幹線が遅れる
10:40くらいの新幹線を予約して 、10:20くらいに品川駅に行く。人身事故の影響で、運転中止中。ちょ、新幹線で人身事故って。運転再開したものの、2時間以上遅れているので、予約した新幹線に乗るのは避ける。再開直後の次の新幹線に乗る。すいていると思ったが、立ち乗り。甘かった。 12:09着、12:30待ち合わせの予定が、13:00着になりそう。バッファが少したりなかった。
サイモン・シン / ビッグバン宇宙論
ところで、原子核構造を実験によって確かめたのはラザフォードだけれど、構造の予想をした人がもっと以前にいたと思う。本書では、ラザフォードが予想と実験をしたように書かれている。そういう些細な思い違いを、たくさんしているんだろうな、と思いながら読む。
2006-10-18
AMBIENT 1 と
ブライアン・イーノの CD を入手した。これまで、イーノって変な名前だなぁ、くらいしか認識がなかったのだけれど、改めてイーノの解説を読んでみたら、よさげ。アンビエントですよ、アンビエント。
東芝EMI (2004/12/22)
売り上げランキング: 7,915
東芝EMI (2004/12/22)
売り上げランキング: 7,784
2006-10-13
1D文字列配列を高速サーチする裏技
NI Discussion Forum の Darren's Weekly Nugget 10/09/2006 で、1D文字列配列を高速にサーチする技が紹介されています。
1D配列検索や自力で、要素数 N の文字列配列を検索すると、運がよければ1個だけチェック、最悪N個チェック、平均で N/2回チェックが必要です。
ところが、バリアント属性は赤黒木というデータ構造で文字列を保存するため、平均で log N (底は2)回程度のチェックで探し出します。1000 要素あっても、10回くらいで見つかります。
2006-10-11
慣れない送別会に参加する
送別会に参加した。大人数での会合では、どう振る舞えばよいのか分からないので、基本的に参加しない。今回参加したのは、自分が送別される側だから。やっぱり、どう振る舞えばよいのか分からなかったので、お世話になった人に礼を言った。
2006-10-09
DVDブック 2軸トライアスロンで楽に速くなる ~トライアスロンJAPANオンラインショップ~ - RUNNERS SELECTION
DVDブック 2軸トライアスロンで楽に速くなる ~トライアスロンJAPANオンラインショップ~ - RUNNERS SELECTION.
トライアスロン活動を再開することにした。10年ぶり。ちょっと走るとひざが痛くなるので、レースに出るのは再来年から。来年は、スイム+ランのアクアスロンに参加する予定。
体の動かし方を完全に忘れていると考えて、教材を購入。チームテイケイの八尾彰一氏が作ったDVDブック。さて、どうなるか。
2006-10-05
Paul Graham / ハッカーと画家
ベンチャー企業のみで得られる貴重なことのひとつは、中断されないことだ。(p.94)
おお、それはすばらしい。
ハッキングの時間単位はとても長い。問題のすべてを頭に収めるだけで1時間を要するかも知れない。そんなときに、あなたが書類を埋めるのを忘れたことを指摘する電話が来たりすると、その影響は計り知れない。ハッカーが質問をされて、スクリーンから目を離すときに恐ろしく不機嫌な目つきをしているのはこのためだ。 (p.94)
やっぱ、そうだよねぇ。時間が短いかどうかは問題ではなくて、邪魔されること自体が困る。そう思われることを恐れて、他人の作業を中断させてまで話しかけることを躊躇する。これはこれで、あまりよくない傾向ではあるけれど。
オーム社
売り上げランキング: 6,005
2006-10-02
滑りが悪いマウスパッド
実家のパソコンには光学式マウスがつながっている。マウスパッドの表面が光沢のある素材で、マウス操作をしにくいらしい。で、マウスパッドを裏返しているのだけれど、滑りが悪くて困っている、と相談される。とりあえず、アマゾンで、数枚注文しておいた。
2006-09-28
最速経路が破綻
新幹線の指定席を予約するとき、駅すぱあとで、経路検索する。旅程を立てるのが苦手なのだけれど、便利になった。が、この手のサービスで出てきた最速経路は、トイレ休憩や本屋に立ち寄ると破綻してしまう。という当たり前の推論さえできないのが、旅程苦手たる所以である。
2006-09-27
自分らしさを捨てる
オヤジ系の人が、会社の受付担当者の制服が変わるんだって、と嬉しそうにふれ回っていた。真面目で堅実で潔癖な感じの人が、「そのメール、転送してよ」と。私もたまにはキャラを破ってみるべきか。たまにはセクハラしないとか。
2006-09-22
運動と通勤と睡眠
2時間の通勤のうち、1時間ほど乗り続ける電車がある。そのうち50分ほどは睡眠に費やす。運動すると目が冴えるのか、今朝は15分たっても起きていた。その後、仕事をバリバリこなし、食事がおいしい、という30分ほどの夢を見た。すっきり。
2006-09-21
毎分145拍を目指す
心拍計をつけてウォーキングした。毎分145拍くらいが適正負荷らしい。歩き始めると、すぐに毎分120拍くらいまで上がるが、少々早く歩いたくらいでは毎分130拍を超えない。このことから、以下のことが分かる。ふだんは歩行より高い負荷がかかっていない、自力でダイエットに必要な負荷をかけられない、朝食を二人前食べると昨年購入したパンツが入らない。
2006-09-19
モチベーションを買う
5時に起きて、ウォーキングしようと目論んでいたら、目覚まし時計を設定し忘れて、30分ほど寝坊した。ウォーキング中止しようと思った。何かをしない言い訳は、常に探されている。ところが、昨日アマゾンから届いた、心拍計が目に入った。あーこれ使ってみたかったんだ、というわけで、20分ほどウォーキングしてから、出勤した。
電車は公共の場です
電車の中で、死に方や、年金や健康保険の不平等を熱く語る老夫婦がいた。手には宗教のチラシ。なまなましすぎ。わたしが上司がどうした、ストックオプションがこうしたなどと、のたまうのも、生々しいに違いない。
2006-09-18
AnnoyingCoworker - Let your coworker know about their annoying habits!
職場には、うっとうしい人がいる場合がある。なんとか変わってほしいかも知れませんが、本人は迷惑をかけていることに気づかないので、ストレスはたまる一方。そこで、AnnoyingCoworker というサービスだ。はた迷惑な行動をとっていることを知らせる匿名メールを送りつける。ためしに自分のアドレスを入力してみたら、本当に届いた。なんとまあ、ネガティブな。
よくある迷惑行為のリストも用意されている。キーボードをタイプする音がうるさいとか、臭いとか(これは微妙)、メールした内容をいちいち口頭で伝えにくるとか。
2006-09-17
2006-09-01
2006-08-31
2006-08-30
2006-08-29
2006-08-27
ワインバーグ / プログラミングの心理学
毎日コミュニケーションズ (2005/02)
売り上げランキング: 80,297
一度あるプログラム言語が採用されてしまうと、新しい言語は入り込みにくくなる。というのは、たいていの人はもとの言語を使っているから、いわば舗装済みの道路を通るようなもので、それをそのまま使った方がずっと楽だからである。アドバイスがほしいときにも、たやすく見つけられるし、サブルーチンがほしい場合にも、すでに存在している見込みが大きい。(p.111)
たいていの人は、一定の相手との慣れ親しんだ関係を放棄して未知のものに乗り換えるくらいなら、ほとんどいくらでも、といっていいほどの苦痛を甘受するものだ。われわれはこのことのあらわれを、プログラマに彼にとって二番目の言語を教えようとするときに体験する。(p.323)
使い慣れた技術や製品から、別のものに乗り換えようとするときの最大の障壁は、おそらく慣れを手放したくないという心理なのでしょう。プログラミング経験者に、開発言語を売り込むよりも、非経験者や売り込むほうが投資対効果が高いということです。また、すでに何度も乗換えを経験している人に対する売り込みも。
2006-08-26
2006-08-21
2分タイマー
GTD の「2分以内で片付くものはその場で実行する」というルールがあります。これで、やっていると、いつのまにか2分過ぎていることがあります。5分くらいだといいのですが、15分とかだと、すばやく片付けるという2分ルールの目的を達できていません。
というわけで、2分タイマーを作りました。Windows XP で確認。タイマーなんか一瞬でできてしまって、この文章を書…。あ、2分たったので、このへんで。
// 2min.js
WScript.Sleep(2*60*1000);
WScript.Echo("2 min!");
2006-08-20
まったりとDVDで映画鑑賞
まったりとDVD鑑賞しました。
売り上げランキング: 10,915
どちらも、以前に飛行機の中で放映されていて、寝たり起きたりしながら、なんとなく見ていた映画です。飛行機で見たとき、珈琲時光の浅野忠信や、きょうのできごとの池脇千鶴が、私が寝ている間にどんな活躍をしていたのか気になっていたのですが、特にありませんでした。日常をぱつんと切り取ったようなまったり感が、よい感じです。
2006-08-13
Vodafone 804NK に機種変更しました
これまで使っていた携帯電話は落下しまくって、筐体がカパカパなっていました。待っていた Vodafone 804NK が発売されたので機種変更しました。液晶画面がきれいでびっくりです。これまでの液晶画面がしょぼすぎただけすが。
2006-08-07
フィリップ・コトラー / コトラーのマーケティング・コンセプト
東洋経済新報社 (2003/05/02)
売り上げランキング: 33,291
企業の成功は、顧客の成功にかかっているのだと理解することである。(p.61)
企業はロイヤルティの高い顧客に報いるべきである。ところが、きわめて多くの企業が、既存顧客よりも新規顧客のほうを優遇している。(p.131)
既存顧客の重要性を訴える箇所が目立ちました。商品によっては、新規顧客開拓よりも、既存顧客維持のほうが費用対効果が大きいということです。一方、
競争の激しい市場においては、顧客満足と顧客維持の相関がそれほど強くはない。(p.66)
という意見もあります。個人的に「顧客の成功」と「顧客の満足」は別の話だと考えています。顧客の成功は、中長期的なビジネスの成功(成長かも知れないし、維持かもしれない)という意味で考えているため、Win-Win の関係に集中できそうな印象があります。顧客の満足は、かならずしも合理的な評価基準がなく、値切りによる満足など Win-Lose な関係に陥りやすそうな印象があります。値切る=成功な顧客もいるでしょうが、まあ、そこらへんは、アレですよ。
フレデリック・ブルックス / 人月の神話
ピアソンエデュケーション (2002/11)
売り上げランキング: 25,081
「人月の神話」を読みました。
ソフトウェア実体の規模の拡大は、単に同じ要素を大きくすることを繰り返すのではない。必ず異なる要素の数が増える。たいていの場合、その要素は互いに非線形で影響しあうものだから、全体としての複雑性の増加は線形どころではない。(p.169)
スペックが大きく異なる I/O デバイスをシステムに追加する、というような状況で、マネジャーや単純なハードウェアしか分からない人に対しての事情説明に苦労することがあります。
ネット上のアウトプットがないと、死んだと思われる疑惑
ネットでのアウトプットが少なくなった人の存在感で、ネットでのアウトプットが減ると、ネットでしかその人を知らない人にとっては「その人の死」のよう見えるという仮説が書かれています。
私から見て Inoue氏 は、そのような人です。Unix のプログラミングの情報を探していて、偶然見つけたページで、よく読んでいました。Debian を使い始めたときにも参考にしましたし、Python を知ったのもここからでした。ところが、2002年10月からぱったりと更新が止まったので非常に残念な思いをしています。いまでも、ときどき更新してないか確認しています。「たしか、あそこに書いてあったな」と思ったら「ginoue」をキーワードに検索します。
逆に柴田氏のアウトプットが目に付きます。よい意味で。本当は COREBlog など、定常的にアウトプットがあるのですが、私が直接受け取らない情報なのでスルーしています。ところが、最新LLフレームワークエクスプローラ Ruby on Rails, Maple/Ethna(PHP),Catalyst(Perl),TurboGears(Python) 5大フレームワーク徹底攻略 と みんなのPython を執筆したそうで、これは私の興味にヒットします。LLフレームワークの TurboGears はなかなか面白そうで、買って読んで遊んでみました。
2006-06-05
IronPython from LabVIEW
Brian Tyler 氏が LabVIEW から IronPython を呼び出す方法を紹介しています。PythonEngine オブジェクトに文字列を渡して、eval() させるという単純な方法です。ArrayList() などを使うこともできます。
一方、LabPython というプロジェクトがあります。こちらは、LabVIEW のフォーミュラノードみたいなもののアドオンです。変数宣言なども、フォーミュラノードの枠のところでできます。
LabPython の実装は、あらかじめ規定されたインターフェースをもつ DLL を、特定のフォルダに入れてあります。Maple も同じようなものを実装しているようです。そのインターフェースは(たぶん)公開されていないようです。
2006-05-31
ハンケチ
出向というか常駐というか派遣というか、とにかくよその会社のオフィスで仕事をしています。トイレの洗面台にペーパータオルがついていません。乾燥機もついているのですが、これの風量が著しく弱いときています。所有しているのですが、習慣になっていないので、つい忘れてしまうのです。
蛇口を手回しする洗面所であれば「他人が触った蛇口よりも、自分のちんちんのほうがキレイである」という言い逃れができます。が、非接触センサーで水が出る蛇口なのです。
しょうがないので、乾燥機でなんとなく乾かして、ワイシャツで拭いたり、階段の踊り場で、こっそり靴下の足首のあたりで拭いたりしています。
2006-05-28
ジェフリー・ムーア / キャズム
初期市場とメインストリーム市場の決定的な違いは、前者がホールプロダクトを自分で作って競争力を高めようとするのに対して、後者はそういうことをしない点にある。(p.185)
ベンダーが顧客に提供したものが一〇〇パーセント以下であるということは、残りの部分を顧客が自分で調達したか、あるいは、その分だまされたと思っているかのいずれかである。(p.188)
技術サポート業務の対象が初期市場であるという前提で組織を作っていると、メインストリーム市場の顧客からの問い合わせに対して「それは、うちの仕事ではない」と反応してしまいがちです。一方、顧客は商品として不完全であると思うかも知れません。
ホールプロダクト R&D が目指すところは、新しいものを一から作り出すことではなく、既存のテクノロジーと製品をもとにして新たな製品を作ることである。(p.338)
インテグレーションっぽいこともする、と。インテグレーションをやってこなかった組織には、こういうノウハウを持った人材がほとんどいないのが、悩ましいところです。
「ライフサイクル・イノベーション」も読まねば。
2006-05-21
トム・デマルコ / デッドライン ソフト開発を成功に導く101の法則
プレッシャーをかけても思考は速くはならない。(p.200)
やはり登場。数年前に一瞬だけ、言葉を交わしたときに「たぶん真実だと思うけれど、受け入れるのは難しい」と言うと「私もだ」と答えられました。
残業時間を増やすのは、生産性を落とす方法である。(p.200)
これも、難しそうな気がします。スプリントと慢性的残業は違うらしいです。
仕様書があいまいなのは、システムの利害関係者の間で対立が解決されていないしるしである。
入出力の完全なリストのない仕様書は、見込みなしである。仕様を明確にする最初の一歩にもならない。
(p.216)
要求仕様で悩んでいるので、これはもしかしたらヒントになるかも。ならないかも。けれど、これまでに「対立」など考えたこともなかったので、一考の価値あり。
Robert L. Glass / Facts and Fallacies of Software Engineering
Fact 9 Most software estimates are perfomed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time. (p.31)
Why are missing requirements hard to detect and correct? Because the most basic portion of the error removal process in software is requirements-driven. (p.74)
要求がはっきりしないなんていうのは、テクノロジーに疎い人たちが「伝票整理を楽にしたい」みたいことを言う場合だけだと思っていました。ですが、要求を明確にするというのは、思ったよりも難しいことを、最近知りました。サンプリングレート 1000Hz で電圧を取りたいという要求があって、CPU サイクルを節約するために DMA でまとめて転送しましょうと提案します。ところが、後になって、いやフィードバックをしたいので1 サンプルごとに値を確認したい、と言われたり。
Fact 21 For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That's not a condition to try to change (even though reducing complexity is always desirable thing to do); that's just the way it is.""" (p.58)
数字の妥当性はともかく、問題の複雑さの増加よりも、解決ソフトウェアの複雑さが大きくなることは、なんとなく同意できます。特に、ハードウェアに強く依存するようなシステムの場合には。うまく問題を抽象化すれば、ある程度簡単になりそうな気はしますが、それでもシステム側の複雑さは大きくなりそうです。使用するハードウェアの制約が問題を複雑にするのではないでしょうか。
2006-05-15
Andrew Hunt, David Thomas / The Pragmatic Progrmmer
通勤に片道2時間かかるので、読書が進んで仕方ありません。積読状態だった本を読みました。こういう機会に、英語の本も読まないと。
So the first question you have to ask yourself when someone asks you for an estimate is the context in which your answer will be taken. (p.64)
今、オンサイトでサポート業務をしていて、よく質問を受けます。このとき私の回答が、次期バージョンの設計に「そのまま」盛り込まれるのか、プロトタイプの対象になるのかは大きな違いです。
Once you think you know what is going on, it's time to find out what the program thinks is going on. (p.93)
急いでトラブルシューティングにあたるときに、このフレーズを思い出せるかが問題です。急かされて、焦って出した解決策は、往々にして後でより大きな問題になります。
Attempting to build an application you don't fully understand, or to use a technology you aren't familiar with, is an invitaiton to be misled by coincidences. (p.175)
偶然に任せた開発をしてはならぬ、と。ということは、クリティカルな業務外で、新技術や知らない技術の勉強をしなければならないということです。SICP の本も、ずーっと積読です、そういえば。
2006-05-12
計画と進捗管理と成果
上司にあたる人から特に指摘されなかったので、長期的な計画を立てずに、短期的な課題だけに注目して仕事を片付けてきました。が、上司の上司の人が、それではいかん、と。
上司(あるいは顧客、同僚等など)に文句を言われないからといって、問題がないことにはなりません。長期的な計画や問題解決が必要であることは、最初から分かっていたのですから、言われなくても自分でやるべきです。
フリーエージェントのような立場で仕事ができるので、これまで「こうやればいいのに」と思ってきたことを、実践していこうと思います。まずは、成果のあがる現実的な計画を立て、進捗管理するところから。
2006-05-11
求めよ、されば与えられん
仕事に必要なことであっても、作業中の人に声をかけるのを躊躇します。まともに仕事をしている人なら、何かしら作業しているでしょうから、こちらから声をかけないと、仕事が進まないことは分かっているのですが、躊躇します。恥ずかしがり屋というのは、自己中心的な態度なので改めるべきでしょう。そもそも生産性が落ちては本末転倒です。
- 他人の仕事を中断してでも、最優先タスクを実行する(これができれば苦労しない)
- 前もって時間を予約しておく
- メールで会議予約する(でも、隣の席の人なのです)
好子(こうし)や嫌子をうまく使えないかと、考え中です。
2006-05-09
出向がはじまります
今週から出向で、他社のオフィスで勤務、のはずでした。職場に行ってみたら、今日まで休暇だったようで、誰もいませんでした。がっかり。出勤日に休むよりマシなので、結果的には問題は起こりませんでした。これからはカレンダーをしっかり確認しようと思います。
2006-05-07
年の差カップルについてどう思うか
銀座を歩いていたらテレビの人にインタビューを受けました。小泉今日子のように、年上の女性と年下の男性のカップルについて、どう思うか。と。いえ、別になんとも思いません。
そんなことより、小泉今日子のほうが気になります。
2006-05-06
Visual C++ 6.0 に挑戦
仕事で Visual C++ 6.0 を使うことになりました。共同で仕事するので、自分だけ Visual Studio 2005 を使うわけにはいきません。
書籍がほとんど売られていないので、Visual C++ 6.0 環境の効果的な使い方が分かりません。いらいらしてきたので、xyzzy でコードを書いて、cl.exe や cygwin の g++ でコンパイルしてみました。Windows API を呼ぶだけなら、ライブラリなんぞに気を使わなくてもいいようです。
#include <windows.h>
#include <iostream>
using namespace std;DWORD WINAPI hello(LPVOID data) {
for(;;) {
cout << "hello" << endl;
Sleep(1);
}
return 0;
}DWORD WINAPI bye(LPVOID data)
{
for (;;) {
cout << "bye" << endl;
Sleep(1);
}
return 0;
}int main() {
HANDLE h = CreateThread(NULL, 0, hello, 0, 0, NULL);
HANDLE b = CreateThread(NULL, 0, bye, 0, 0, NULL);
Sleep(100);
return 0;
}
「g++ foo.cpp」「cl foo.cpp」のいずれでもコンパイルできます。これのほうが簡単だ。と思ったのも束の間、Visual C++ 6.0 のプロジェクトファイルが必要なのでした。
2006-04-17
中島義道 / 私の嫌いな10の人びと
「よく考えない人」の類型化です。この種の人びとのことを嫌いかという点では、共感できるところと、できないところがあります。ただ、年賀状を送ってくれるなと告げるなど、対外的な行動に出るのは、大人気ないと思います。
これだけしたのに、自分に対する「感謝の気持ち」が相手にないとわかると、むくれる。いいですか、人の世話を焼くのは自由ですが、断じてそれだけは望んではならないのです。(p.62)
非常に共感しました。こちらから頼んだわけでもないのに、勝手に何か行動されて、その行動やその結果に対して、こちらは感謝の念がわかないという状況があります。たとえば「誕生日プレゼントとして、嫌いなデザインのネクタイを贈られる」という状況です。
嫌いなデザインのネクタイは、残念ながら私にとってはゴミです。ここで「せっかく、あげたのに」と、私に感謝を要求する人がいるわけです。私を喜ばせることが目的であれば、喜ぶような選択ができなかった贈る側に全面的に責任があります。プレゼントを気に入るかどうかに関わらず、私からの感謝を要求するのであれば、もはや贈り物ではなく、コミュニケーションらしきものの強要です。
だから、プレゼントとかよこすんじゃねーよ。
2006-04-03
Be admired and respected
旧聞ですが、lifhack.org の「Be admired and respected」という、上司についてのエントリがあります。
When no one else will make a decision, he does. He doesn't hesitate to seize responsibility and the accountability that comes with it when we need him to.
He listens well, and if he doesn't get it (i.e. whatever we're trying to explain to him) he says so and doesn't pretend that he does.
で、
私の上司について同じ印象があり、尊敬しています。ドラッカーが何かの本で書いていた「本気であることが分かるのが、信頼できるリーダーの条件」と似ています。その上司からの指示や意見は、上司が本気で正しいと考えているのだ、と私は信じています(同意することとは別)。私の説明が伝わっていないときは、分かったふりはせずに、お互いが同じ情報を共有するまで時間を割いてくれます。
で、
日経のアソシエ 2006.04.18 号で柳井正がこんなことを言っています。
[恩人] に対して気を使うあまり、判断基準が属人的なものに委ねられている
そういう人がいる、という指摘です。気づいたのですが、私は、その上司に対する批判やネガティブな意見に対して、やたらと防衛的になる傾向があります。別に私は、その上司が常に正しいとは思っていないのですから、他の人が批判的であっても全く当然のことなのですが、なにやら防衛的になります。こういう態度は、むしろ上司に対すて失礼であると思いました。
で、
その上司がこの四半期から、lifehack.org のエントリの上司と同じく、異動になりました。ざんねん。
2006-03-20
水玉潰しゲームソルバーに挑戦
水玉潰しを解くスクリプトを書こうと思い立ちました。が、やたらと時間がかかります。かたっぱしから手を生成して、それをシミュレートするという力技なので、時間がかかるのは当然です。ラスト何か数手であっても数分かかったりします。何かヒューリスティックを考えないといけませんね。
def main():
pattern = [[0,4,4,0,0,0],
[0,0,0,0,0,0],
[2,0,0,0,0,0],
[3,0,0,0,0,0],
[3,0,0,0,0,0],
[0,0,0,0,0,0]]
solution, tank = solve(pattern, 13,13)
print solution, tankdef play(game, sequence=[]):
for x,y in sequence:
game.dropByUser(x,y)def solve(pattern, tank=10, limit=2):
tankMax = -1
solution = None
game = Game()
for currentLimit in xrange(1, limit+1):
print currentLimit
# for each sequence:
for seq in sequences(currentLimit):
# heuristics
if unsolvable(pattern, seq):
continue
# play game
game.init(pattern, tank)
play(game, seq)
# if solved and tank is larger than prev best,
# store tank and solution
if game.isSolved() and game.tank > tankMax:
solution = seq
tankMax = game.tank
if solution:
return solution, tankMax
return solution, tankMaxdef sequences(limit):
if limit==0:
yield []
return
for x in xrange(6):
for y in xrange(6):
for tmp in sequences(limit-1):
yield [(x,y)] + tmp
return_tmp_pattern = [[0 for x in range(6)] for y in range(6)]
def unsolvable(pattern, seq):
for y in xrange(6):
for x in xrange(6):
_tmp_pattern[y][x] = pattern[y][x]
for x,y in seq:
_tmp_pattern[y][x] += 1
if max([max(z) for z in _tmp_pattern]) < 5:
return True
else:
return False
class Game:
def __init__(self):
self.tank = 0
self.cells = {}
for y in xrange(6):
for x in xrange(6):
self.cells[x,y] = Cell(self)
self.splashes = []
self.chain = 0def init(self, pattern, tank=10):
for y in xrange(6):
for x in xrange(6):
self.cells[x,y].drop = pattern[y][x]
self.tank = tankdef dropByUser(self, x, y):
self.chain = 0
return self.drop(x, y)def drop(self, x, y):
self.tank -= 1
self.cells[x,y].growDrop()
while len(self.splashes) > 0:
s = self.splashes.pop(0)
s.move()
if s.alive:
self.splashes.append(s)def notifyCrash(self, cell):
self.chain += 1
if self.chain == 3:
self.tank += 1
self.chain = 0
for (x,y),value in self.cells.items():
if value==cell:
break
for dx,dy in [(1,0), (-1,0), (0,1), (0,-1)]:
self.splashes.append(Splash(self, x,y,dx,dy))def isSolved(self):
for c in self.cells.values():
if c.drop!=0:
return False
return Truedef __str__(self):
string = "tank: %d\n" % self.tank
for y in xrange(6):
for x in xrange(6):
string += "%d " % self.cells[x,y].drop
string += "\n"
return stringclass Cell:
def __init__(self, game):
self.game = game
self.drop = 0def growDrop(self):
self.drop += 1
if self.drop==5:
self.drop = 0
self.game.notifyCrash(self)class Splash:
def __init__(self, game, x, y, dx, dy):
self.x = x
self.y = y
self.dx = dx
self.dy = dy
self.game = game
self.alive = Truedef move(self):
self.x += self.dx
self.y += self.dy
if (self.x<0 or 5
self.alive = False
elif self.game.cells[self.x, self.y].drop > 0:
self.game.cells[self.x, self.y].growDrop()
self.alive = False
if __name__ == "__main__":
main()
2006-03-19
Daniel L. Schacter / なぜ、「あれ」が思いだせなくなるのか
最近、物忘れがひどすぎるので、この本を買いました。
固有名詞には特別な意味はない。その名前で呼ばれる個人を象徴するが、その個人の性質を暗示することはない。[...] 名前がジョン・ベーカーだというとき、比較的よくあるアングロサクソン系の名前であるということの他には、彼個人についてほとんど、あるいはまったく何も伝えていないのだ。 (p.79)
よっぽどのことがない限り、私は、本名を知っている人を、あだ名やニックネームで呼びません。たとえば「ふるっち」や「ふるちん」などの呼び名があるからといって、誰かが私を識別することの役に立たないからです。ただし私の鼻が、他人の鼻より際立って赤い場合に「赤鼻の古川」とか「トオル・ザ・レッド」という呼称には意味があると思います。身体的特徴を口に出すことの倫理性は別として、認識のしやすさという点で、便利です。
記憶結合の失敗が原因で、実際に経験した出来事と、ただ考えたり想像しただけの出来事とが混乱することもある。たとえば、これから外出しようというときに、家のドアを閉めて鍵をかけなければと考える。その一時間後、車のなかで、あなたは突然パニックに襲われる。自分は本当にドアに鍵をかけてきたのか、それともただ想像しただけなのか?(p.117)
ちなみに私は、通勤途中に「ズボンをはいたかどうか」不安になることがあります。毎日、似たデザインのスーツを着ているので、ズボンをはいた記憶があいまいのなのです。あと、トイレでズボンを下ろしたときに、ファスナーを数秒前にあけたのか、元々あいていたのか分からなくなります。せっぱつまっているときは、特に。
つきまとう記憶を本当に和らげるためには、それらを認識し、直面し、対処しなければならないのだ (p.231)
トラウマというほどではないにしても、思い出すと逃げ出したくなる記憶が多々あります。どこかで向き合わねば。
矢幡洋 / とにかく目立ちたがる人たち
事態を客観的に分析したいと考えている人にとっては、ヒストリニオクスのトークは分析的な情報に乏しく、自分の主観的な体験を強調しているだけに聞こえる。 (p.101)
「これは大問題です」とか言うので話を聞いてみると、全体から見るとごく小さな障害に対して過剰に反応しているだけ、ということがあります。私は、「大」「非常に」「超」などの接頭辞を使わないと、他人の注意を集められない事象は、およそ重要ではない、という仮説を持っています。
ナルシストは、自分が他人に与えたものに関しては過大評価し、自分が他人から受け取ったものに関しては過小評価する傾向が強い。 (p.133)
しょうもない情報の提供や、たいした手伝いしかしてもらっていないのに、恩着せがましく「今期の成果」として公表されるときの、がっかり感はすさまじいものです。
以上、自戒もこめて。
日経ビジネスアソシエ 2006.04.04
日経ビジネスアソシエ 2006.04.04 号の特集は「1週間行動計画」です。その特集とは関係ありませんが、笑福亭鶴瓶のインタビューがありました。「らくごのご」や「鶴の間」など即興の笑いをつくる挑戦をしていますねと言われたことに対して、以下の発言です。
これこそプロの技やと思うて見せつけてるんです (p.110)
かっこいい。プロジェクタにつないだ PC 上で即興プログラミング、セミナー中にホワイトボードで数式を展開して解を出すなどの後で、何か発言や提案があると、うなづく率があがる気がする。
2006-03-14
JavaScript/Migemo 0.6 好きなパスに辞書を置けるように変更など
今日は非常に不機嫌で、非生産的な1日だった。どう考えても仕事なんぞ手につかないと思ったので、6時ごろに退社する。気晴らしに JavaScript/Migemo に手を加えることにする。バージョン 0.6 の変更点は以下の通り。
- いいかげんな単体テストを追加。デバッグや、リファクタリングの前には単体テストを作ってから、修正することにした。
- 「n」で終わるときの、かな候補を修正。これまでは「n」で終わるときも、促音が入っていた。「kan」の候補に「かっ」が入っていた。この促音候補を出さないようにした。
- 辞書のパスを自由に指定できるように変更。これまでは HTML と同じディレクトリに、辞書が保存されている必要があった。あまりにださい上に、辞書ファイルの個数が多いので、任意の(ブラウザがアクセス可能な)ディレクトリに辞書をおけるようにした。クエリする前に
migemo.initialize("./foo")
を呼び出すと、./foo 以下に辞書ファイルを探しにいく。
2006-03-13
JavaScript/Migemo が名前空間を汚さないように修正した
職場の検索ツールに JavaScript/Migemo を組み込もうとしたらメソッドがないとかいうエラーがでた。デモではちゃんと動くのに。コードを見たらメインのプログラムと migemo.js との両方で initialize() 関数を定義してることに気づく。JavaScript/Migemo が名前空間を汚しまくっていたのだ。というわけで、公開関数は migemo、非公開関数は _migmeo オブジェクトの中で定義しなおしたら、めでたく動作するようになった。
2006-03-11
JavaScript/Migemo ページのスタイル変更
拙作の JavaScript/Migemo が、いつも読んでいる Moongift や オレンジニュースで紹介されていて、非常にうきうきである。アクセスが増えたときに、ページのデザインがしょぼいと恥ずかしいのではと思い、スタイルを変更した。自意識過剰っぷりを発揮した割には、およそたいしたデザインではない。ル・クルーゼのイメージ。
2006-03-09
藤田憲一 / 金持ち兄さんの王道 専門家をカモにする人・される人
講談社 (2003/04)
売り上げランキング: 49,587
投資の本のはずだったんだけど、マーケティングの勉強になる。著者がマーケターだからか。
あなたが彼ら [専門家] に任せていいのは、「情報の提供」と「労働」だけである。「考えること」「判断すること」は、絶対に人に任せてはいけない。 (p.61)
相手がしょぼければ、そのとおりだろう。けれど、こっちがしょぼいと、相手の判断が正しい可能性が高い。そして、カモにされる、と。
あなたはそこの「麦トロ牛タン定食」が目当てで通っている。しかし、麦トロ牛タン定食はすぐに売り切れる。仕方がないので、そんなときは「日替わり定食」を注文する。その店の経営会社は、あるときPOSデータを分析することにした。どうやら、人気商品は「日替わり定食」らしい。そこで、その会社は「日替わり定食」の供給を増やすことにした。
おお、これはやばい。
2006-03-06
椎木一夫 / エンジニアが30歳までに身につけておくべきこと
20代の間に身につけておけばよかったなぁ、と30代の私が思っているようなことが書かれている。Better Late Than Never ではあるけれど、若い新入社員の人に読んでもらいたいような本である。こんな本を読まなくてもいいような人を、採用すればいいのだけれど、私のように30過ぎて気づくような人間をうっかり雇う職場も存在するのだ。
新しい仕事に取り組む場合、いろいろ慎重に考えすぎると、着手できなくなったりする。そこで「とりあえず始めてみる」のだが、その仕事の目標・目的だけは明瞭にしておく必要がある。 (p.117)
仕事がうまく進まなくなると、人間誰しも「ダメな理由」を考えて上司に説明したくなる。[...] ダメな理由を考えている暇があるなら、「うまくいかせるにはどうすればいいか」と、ここでも前向きの提案が必要だ。 (p.165)
すごい会議っぽい。
2006-03-05
Series60で、ひとり Wiki のスクリプト
Series60 で、ひとり Wiki するスクリプトが、ダウンロードできなかったみたいなので、リンクを修正した。テキストファイル。
xyzzy にも同じようなモードを作って、使っている。手作業で同期するのはだるいので、同期ツールも作った。が、職場の PC ではエラーが出たりと、いまいちなので、今週末に修正の予定。
2006-03-04
ハワード・ゴールドマン / すごい考え方
問題解決の際の、考え方を紹介している。人間の思考を、コンピュータの OS に喩えるという比喩は、私にとっては分かりにくい。
「正しい」(right)かどうかよりも、「効果的」(effective) かどうかがより重要となる。(p.90)
本来の目的に集中して、過程の正しさよりも、成果に集中したい。過程をおろそかするのではなくて、成果のための過程であるという考え方。あたり前なのですが、難しい。つい目先の最適化や正しさに走ってしまいがち。自戒もこめて。
誰もが根本的な問題だと思っているが簡単には口に出せない「タブー化した問題」のことを私は「ひどい現実」と読んでいる。多くの組織において「ひどい現実」が手つかずになったまま、問題を解決しようとしている。そのために表面的な問題解決にとどまってしまっていることが多い。 (p.93)
たとえば、あくまでたとえばですが「そもそも社長がしょぼい」とか、そういう平社員では手の出しようがなさそうな問題があるとすると、どうしよう、とか考えてみる。「社長を変えるなんて、無理だよなあ」ではなく、ではどうするか、という視点に立とアイデアが出るのかも知れない。優秀な参謀で固める、とか。しょぼいな。
忙しいことと生産的であることとは別物だということをはっきり理解する必要がある。 (p.124)
これこそ自戒しなければいけない。時間や労力をかけて取り組んだ活動を、無駄な行為であると認めるのはつらいけれど、認めないと成果に集中できない。
2006-02-26
W・チャン・キム、レネ・モボルニュ / ブルー・オーシャン戦略 競争のない世界を創造する
ランダムハウス講談社 (2005/06/21)
売り上げランキング: 55
二時間ほど気ままに過ごしたいとしたら、どうするだろうか? 映画館に足を運ぶか、マッサージを受けに行くか、それとも近所のカフェでお気に入りの本を読むだろうか。[...] 売り手の立場になると、なぜかこうした直感的な発想をすっかり忘れてしまいがちである。[p.75]
同業他社だけが競合ではない、と。
「ティッピング・ポイント」では割れた窓理論に終始していた、NYPD のブラットンの仕事について、少し詳しくプロセスが書かれていた。
上原ひろみ / Spiral
ユニバーサルクラシック (2005/10/19)
売り上げランキング: 675
テレビでドリカムが褒めていた、上原ひろみのアルバムを衝動的に購入した。ジャンルはジャズになっているが、そんなにジャズジャズしていない。と、思う。しばらくはヘビーローテーションにしよう。
上原ひろみ / Spiral
ユニバーサルクラシック (2005/10/19)
売り上げランキング: 675
テレビでドリカムが褒めていた、上原ひろみのアルバムを衝動的に購入した。ジャンルはジャズになっているが、そんなにジャズジャズしていない。と、思う。しばらくはヘビーローテーションにしよう。
2006-02-25
Windows の FILETIME 型から、.NET の System.DateTime に変換する
Windows の .NET でプログラミングするとき、時刻を表す型がいくつかあって混乱したので、忘れないようにメモしておく。Visual C# 2005 Express Edition で、System.Runtime.InteropServices.ComTypes.FILETIME から、System.DateTime に変換するときは次のように書く。
DateTime datetime = DateTime.FromFileTime(*((long*)&(filetime)));
long は 64 ビットらしい。
2006-02-19
Nokia PC Suite Connectivity API 1.1
Nokia PC Suite Connectivity API 1.1 の存在に気づいた。Nokia PC Suite の機能を使って携帯電話と通信するような PC アプリが簡単に作成できる。以下のコードは、携帯電話の E:\remote\folder\hello.txt ファイルを、PC の C:\local\folder フォルダにコピーする。接続してる携帯電話は1台であると決めうちで、エラーチェックなし。Windows XP と 702NK で動作確認。
#include "stdafx.h"
#include "ConnAPI.h"int _tmain(int argc, _TCHAR* argv[])
{
DMHANDLE dm;
DWORD count;
CONAPI_DEVICE device;
FSHANDLE fs;
_TCHAR filename[] = _T("hello.txt");
_TCHAR src[] = _T("\\\\E:\\remote\\folder");
_TCHAR dest[] = _T("C:\\local\\folder");CONAInitialize(CONA_API_VERSION, NULL, NULL);
CONAOpenDM(&dm);
CONAGetDeviceCount(dm, &count);
if (count==1) {
CONAGetDevices(dm, &count, &device);
CONAOpenFS(device.pstrSerialNumber, &(device.pItems->dwMedia), &fs,
&(device.pItems->dwDeviceID));
CONACopyFile(fs, CONA_DIRECT_PHONE_TO_PC|CONA_OVERWRITE ,
(WCHAR*)filename, (WCHAR*)src, (WCHAR*)dest);
CONACloseFS(fs);
}
CONACloseDM(dm);
CONAUninitialize(0);return 0;
}
2006-02-13
Python for S60 で、ひとり Wiki
ソースファイルは s60wiki.pyで、Python for S60 1.3.1 が必要。
こんなに簡単に作れるのなら、Java や C++ を使う気が失せてしまう。パフォーマンスや API アクセス柔軟性に不安があるものの、コードが動くまでのお手軽さという点では Python for S60 が優れている。Symbian と Series60 の C++ 本を買ったのだけれど、読まずに終わりそうである。
ところで Bluetooth Console を使おうとすると、Discovering... と表示された後、電話側の Python がクラッシュしてしまう。しかたなくエミュレータで開発している。
Python for S60 で、ひとり Wiki
ソースファイルは s60wiki.py
s60wiki.py
で、Python for S60 1.3.1 が必要。
こんなに簡単に作れるのなら、Java や C++ を使う気が失せてしまう。パフォーマンスや API アクセス柔軟性に不安があるものの、コードが動くまでのお手軽さという点では Python for S60 が優れている。Symbian と Series60 の C++ 本を買ったのだけれど、読まずに終わりそうである。
ところで Bluetooth Console を使おうとすると、Discovering... と表示された後、電話側の Python がクラッシュしてしまう。しかたなくエミュレータで開発している。
2006-02-12
谷岡一郎 / 「社会調査」のウソ リサーチ・リテラシーのすすめ
文藝春秋 (2000/06)
売り上げランキング: 4,066
バイアスのかかった調査結果が信用できないことの解説。
[コーヒーのカフェインと心臓病の因果関係を証明するには] まず「砂糖の影響」を消す必要がある。それが「コントロール」の意味である。[p.132]
複数の変数の表面上の相関関係が、どれも一つの共通の原因から生じた結果にすぎないということが間々ある。これを「スプリアス効果(spurious effect)」という。[p.135]
平均と相関で、すべて片付くと思ってはならない。
「非常に満足を1、満足していないを5」と示したアンケートと「満足、まあ満足、どちらともいえない、やや不満、不満」と示したアンケートでは結果が異なる、というような話も紹介されている。つまり顧客満足を定量的に測ることは非常に難しいことが分かる。
年度ごとの利益なり売上げの推移が、10、20、30、40、1、2、3 だったとき、(今年度売上げ)> (前年度売上)を成長したと定義すると、「1年を除いてずーっと成長している」と言うことだってできる。
2006-02-08
三浦展 / 下流社会 新たな階層集団の出現
光文社 (2005/09/20)
売り上げランキング: 362
市場が「中流社会」から「階層社会」あるいは「下流社会」に変わったのに、相変わらず中流社会型のビジネスモデルで対応しているから、売上げが減るのである。[p.34]
階層構成が変わるというのは、市場の人口構造が変わるわけですね。ふむふむ。
ミリオネーゼという言葉は『ミリオネーゼになりませんか?』という本を出した出版社、ディスカバー21の造語 [p.50]
ディスカバー21といえば、個性とかそういう下流系の路線だったと思っていました。
2006-02-05
Joel Spolsky / ジョエル・オン・ソフトウェア
30秒かければリファレンスで調べることもできるが、15秒でジェフに聞くこともできる。彼はジェフの隣に座っているものだから、ジェフに聞くことにする。ジェフは気を散らされて15分を失う(マットの15秒を節約するために)[p.13]
作業中にしょっちゅう話しかけられることに慣れてしまって、最近は自分からも話しかけるようになってしまいました。コミュニケーションは重要ですが、手段やタイミングを冷静に見計らって、合理的に時間を費やしたいものです。たとえば定時に短い打ち合わせをして、そのときに助けてほしいことをあらかじめ伝えておくとか。
「プレーンテキスト = ASCII = キャラクタは8ビット」みたいな考えは単に間違っているだけでなく、救いがたく間違っており、もしあなたが依然としてそのようなやり方でプログラムを書いているのであれば、細菌の存在を信じていない医者よりもひどい。[p.38]
そこまで甚だしくないにしても、分かっていない人は多い。「2ヶ国語話せるのはバイリンガル、3ヶ国語ならトライリンガル、じゃあ1ヶ国語は? 答えはアメリカン」という、どうしようもないアメリカンジョークを聞かされたことがあるのを思い出した。
プロプライエタリであろうとオープンソースであろうと、デバッグ済みのコードはタダではない。たとえあなたがそのために代金を払わなかったとしても、そこには機会費用があり、時間費用があるのだ。[p.307]
ふむふむ。けれど例えば私が今、この文章を書いている xyzzy エディタの開発に、私は1円のコストもかかっていないし、跳ね返ってきてもいない気がする。風が吹いたら桶屋が儲かる式か。
スマートな企業は彼らの製品の補完財をコモディティ化しようとする。[p.308]
あー、そっか。なるほど。
2006-02-03
Pythonista 飲み会
夕べは Pythonista と飲み会でした。学んだことは以下のとおり。
- 年をとると太りやすくなるのは、代謝が衰えるかららしい
- PEP 343 が熱いらしい
- Cherry template は CherryPy なしで
- 特徴ベクトル抽出も熱い
- Planet.Python や Planet Python Japan
開発をする人と話したのは久しぶりでした。人と話すといろいろと、くだらないアイデアが浮かんでくる。
Pythonista 飲み会
夕べは Pythonista と飲み会。学んだことは以下のとおり。
- 年をとると太りやすくなるのは、代謝が衰えるかららしい
- PEP 343 が熱いらしい
- Cherry template は CherryPy なしで
- 特徴ベクトル抽出も熱い
- Planet.Python や Planet Python Japan
久しぶりに、開発をする人と話した。人と話すと、(良い意味で)くだらないアイデアが浮かんでくる。1月は捨てる・やめる月間だった。今月からくだらないアイデアを実現していく方向で。
2006-01-28
Cliff Atkinson / Beyond Bullet Points
Microsoft Pr (2005/02/11)
売り上げランキング: 274,822
Microsoft Press から出版されている、スライド作りの指南書を読んだ。(1) プレゼン=物語を伝える、と考える (2) 物語のあらすじを作ってからスライドを作る、というのが基本的な指針である。
Three Ground Rules for Writing [...] 1. Write complete sentences with a subject and a verb in active tense. 2. Use a conversational tone that is simple, clear, and direct. 3. Constrain the length of your sentences to the limies of the template.
言いたいことを完全な文で書く、というのは恩師の教えと同じだ。しかし、この本を読むまで、私はずーっと bullet point method だった。
石井住枝 / トヨタの役員秘書が見た トヨタのできる人の仕事ぶり
中経出版 (2005/04/29)
売り上げランキング: 7,547
職場の人に借りた。
「この用紙が出て来たら、担当○○までこの用紙をお持ちください」とシートが挿してありました。 [p.76]
現場で不都合が起きたら、責任はすべて仕組みにあるという考え方です。 [p.101]
しくみに焦点を当てることは、私の仕事にも使えることだと思います。「山田が失敗した」のではなく、「失敗するシステムであった」ことを問題視する。
「K役員の [秘書の任期を2年をメドにしよう]という提案は前任の秘書を異動させたかっただけで、 2年交代をルールにしたかったのではない」とささやかれていました。言葉だけを鵜呑みにしてしまうと、周囲にも大きなデメリットを与えてしまうのです。[p.214]
それは伝える側の責任ではないか、と。言葉の裏を汲み取ることは大事だけれど、それを前提に仕事のコミュニケーションするのは、効率悪い。
2006-01-22
Randall Hyde / Write Great Code〈Vol.1〉ハードウェアを知り、ソフトウェアを書く
高級言語しか使ったことがない人、しかも I/O のパフォーマンスに四苦八苦する人の役に立つと思う。メモリや I/O についてはスパコンの講習会で、キャッシュについては研究室の勉強会で断片的に学んだことがある。最初から、こういう本を読んでいれば楽だっただろう。
浮動少数点同士の大小の比較でも [等価かどうかの比較と] 同じ問題がおきる [p.70]
えー!
イクセス127形式では、指数 20 が値127($7f)で表されます [p.72]
なんで、0 にしないのかと悩むこと3日。2-n の場合があるので、20 の場合を 0 にしてはならないのだ。たぶん。
[ASCIIコードでは] 大文字の英字は第5ビットが常に0で、小文字の英字は第5ビットが常に1になります。[p.101]
えー!
参照の時間的局所性と空間的局所性 [p.148]
こういう言葉を知っていると、いかにも知ってる人っぽくなる気がする。ところが、もっと知っている人の前で話すときには、却って無知をさらすことになる。
2006-01-21
三島由紀夫 / 春の雪
登場人物たちの性格が、ことごとく屈折している。映画は見ていないが、綾倉聡子=竹内結子という妄想してしまう。もったいない。
本多は、聡子が少しも外国語を喋らないのに、二人の王子の前で、へりくだりもせず高ぶりもしない、気品のある態度を持しているのに心を博[う]たれた [p.87]
英語が話せないくらいで、おどおどしてはならぬ、と。そういえば、年末に英語学校の資料を取り寄せたっきり、何もしていない。
2006-01-16
ジャレド・ダイアモンド / 銃・病原菌・鉄 下巻
上巻で立てた仮説を、適用・検証していく内容だった。文字、言語、作物、人種、病気、気候などを根拠に、仮説を検証していく過程が続く。大陸ごとの歴史の違いに影響を及ぼした要因は、主に4つ。
- 栽培化や家畜化の候補となりうる動植物種の分布状況が大陸によって異なっていた [p.298]
- 伝播や拡散の速度の違い。ユーラシア大陸は東西方向に伸びる陸塊なので、生態環境や地形の障壁が少ない [p.300]
- 大陸間における伝播の容易さの違い [p.301]
- 大陸の大きさや総人口の違い [p.301]
Mozilla/FireFox 用 Yasazon 検索プラグイン
内容はだいたい分かるんだけど、書名や著者をきちんと思い出せない、という状況では Amazon の検索が難しい。こういうとき Yasazon だと引っかかるときがあることに気づいたので、Mozilla/FireFox 用の検索プラグインを作った。自動的にインストールするスクリプトを作ろうとしたが、何やら「Not Enough Arguments」というエラーが出るので断念。深追い禁止。
<search
name = "Yasazon"
description = "Yasazon"
action = "http://yasazon.asamasi.net/search.cgi"
method = get
queryEncoding="UTF-8"
queryCharset="UTF-8"
>
<input name="key" user>
</search>
2006-01-12
ジャレド ダイアモンド / 銃・病原菌・鉄〈上巻〉
特定の集団(民族とか国民とか)が、別の集団よりも繁栄した原因は、究極的には地理的条件で、農耕や病原菌は因果関係の途中に位置するという主張である。上巻では銃や鉄の話は、まだ出てこない。
ヨーロッパ中央部と南東部に居住していた狩猟採集民のあいだに食料生産が広がっていったのは、食糧生産を実践する生活と競合できるほど、この地における狩猟採集生活の生産性が高くなかったからである。[p.157]
狩猟で食べていけるのであれば、狩猟する。狩猟で食べていけない、または、食糧生産したほうが投資対効果が高ければ、食糧生産する、と。
[熱帯東南アジアや熱帯アフリカ] の植民地支配の確立が、南北アメリカ大陸より約四〇〇年も遅れたは、こうした [コレラや黄熱病のような] 病気がヨーロッパ人進出のさまたげとなったからである。[p.317]
病気が侵略に有利に働いたり、不利に働いたりしたらしい。意図せずに細菌攻撃していたことになる。
2006-01-10
少物主義の味方、BOOK OFF
ブックオフで 25 冊を 1180 円也。他の人のブログで見かける買取価格より低い気がするが、儲けは二の次なので、忘れようと思う。次の週末に売りにいったら、本棚からあぶれた本を一掃できるはず。
少物主義の味方、BOOK OFF
ブックオフで 25 冊を 1180 円也。他の人のブログで見かける買取価格より低い気がするが、儲けは二の次なので、忘れようと思う。次の週末に売りにいったら、本棚からあぶれた本を一掃できるはず。
2006-01-09
ニセ科学シンポジウム@物理学会
身近な人が「マイナスイオン」などと発言したときのがっかり感は相当なものである。2006年3月に物理学会が物理学者が「ニセ科学」といかに向き合うべきかを議論するシンポジウムを開催するらしい。
「ニセ科学」を正しく批判できるのは科学者だけである。そのような批判を展開していくことは、科学者が社会に対して果たすべき重要な責任のひとつであろう。
物理学界隈では学術的に面白いテーマではないだろうし、科研費の申請もできないだろうし、面倒なやりとりが多そうな仕事であろう。科学者の人々が一笑すること、信用してしまう人がいること知ってもらえると嬉しい、というのが個人的な期待である。
2006-01-08
BOOK OFF のトレーナーとトレーニー
BOOK OFF に本を売りに行ったら「買取価格は820円です」と店員さんに告げられた。サービス券がもらえると言われたので、会員カードを作ることにする。「こちらのカードに氏名をご記入ください。入会金は買取価格から差し引きます」
カードに名前を書いたり、買取の用紙に住所を書いたりする。店員の名札には「トレーニー」と書かれている。そういえば、さっきから先輩らしき店員が後ろから、じーっと見ている。こういう見方されると、指導される側が緊張するんだよねぇ。
トレーニーさんはカードを受け取ると、レジの処理をして 820 円手渡してくれました。先輩店員の目が鋭くなって、何か口出ししそうな顔になる。あらら。私は「ありがとうございます。では、会員カードの 100円がこちらですよね」と言いながら、会員カードのレシートと交換した。
2006-01-07
門倉貴史 / 人にいえない仕事はなぜ儲かるのか?
非合法ビジネスは (1) 健全で安全志向な庶民が参入しないので競争原理が働かないことと (2) 所得に課税されないという理由で儲かるのである、という議論である。サラリーマンは所得税を給料天引きされるが、自営ならいろいろできるという話も紹介されている。
アメリカで学生やっていたとき、research assistant の給料に federal income tax が課されていて、年度末には書類に記入していた。当時と、サラリーマンやっている今とで、税金に対する認識が変わったとは思わない。申告の仕方によって、課税額に大きく影響するような消費生活をしていない気がする。
最後の章で、支出税にすれば、最終的な合法的消費に課税されるのだ、と提案している。(1) スポーツ選手のような短期で高額所得がある人も、安定なサラリーマンも生涯を通して同じ率で課税されるし、(2) 非合法ビジネスでの所得も、最終的に合法的な消費により課税される、と。よく分からないんだけれど、たとえば合法的な自動車の製造過程で生じる、すべての消費/購買には課税される。一方、非合法なビジネスでは途中の取引には課税されない。これはいいのか。全然、徴収できないよりマシということか。
今日は晴れているので、ブックオフに本を売りに行こうかな。段ボール2箱くらい、いらない本がある。
IronPython Beta 1
.NET プラットフォーム用 Python である IronPython のベータ版を、マイクロソフトが公開した。.NET のライブラリは開発言語を問わず、.NET のコードから呼び出すことができる。C# で書いたクラスライブラリを、Visual Basic .NET から呼び出せる。
IronPython で NI-DAQmx というI/Oデバイス用の .NET API を呼び出してみた。A/D変換ボード 2 チャンネルから電圧を測定して、CSV ファイルに書き込むコードは以下のとおり。ちなみに、NI-DAQmx はハードウェアなしでも動作するが、インストーラが数百メガバイトあるので、わざわざダウンロードしないように。
"""continuous.pyInstruction:
1. Save this file under IronPython folder.
2. In command prompt, navigate to IronPython folder, then type
IronPythonConsole.exe continuous.py
3. You will have a file "foo.csv" which contains the acquisition result.
"""import clr
clr.AddReferenceToFile(r"C:\Program Files\National Instruments\MeasurementStudioVS2003\DotNET\Assemblies\Current\NationalInstruments.DAQmx.dll")
from NationalInstruments.DAQmx import *task = Task()
task.AIChannels.CreateVoltageChannel("Dev1/ai0:1",
"",
AITerminalConfiguration.Differential,
-10,
10,
AIVoltageUnits.Volts)
task.Timing.ConfigureSampleClock("",
1000,
SampleClockActiveEdge.Rising,
SampleQuantityMode.ContinuousSamples,
1000)
reader = AnalogMultiChannelReader(task.Stream)
f = file("foo.csv", "w")
task.Start()
for i in range(20):
data = reader.ReadMultiSample(10)
for x in range(10):
print $gt;>f, data[0,x], ",", data[1,x]
task.Stop()
2006-01-06
遠藤功 / 見える化 強い企業をつくる「見える」仕組み
現場での業務が基準や計画どおりに行われているかどうかを認知するには、基準や計画と現状との「ギャップ」を測定すれば問題が明らかになる。[p.64]
期待と現実を比べる、というところに行き着くようだ。人気爆発ブログになることを期待しているが、誰も見に来ない。アサマシでウマーのはずが、クリックすらされない。9時台に布団に入るつもりだったのに、水玉潰しで真夜中など。
トヨタでは、「この作業は右手で行う」といった規定まで細かく明文化されていて、左手での作業は行えないことになっている。[p.120]
作業をこれほどまで分析できていれば、かつ、その規定が分かりやすければ、無駄がなくてよいだろう。一方、中途半端な分析を基に右手でと決められたり、規定が分かりにくければ意味が無い。