計算機を使っていると、何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、それを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、 といった類いのノウハウは多い。そうした雑多なノウハウのことを、 本来は知りたくもないノウハウという意味で、私はバッドノウハウ と呼んでいる。 バッドノウハウは、ソフトウェアの複雑怪奇な仕様が歴史的に引き ずられ、根本的な改善は行われないまま、そのノウハウが文書によっ て受け継がれることによって蓄積が進行する。Unix 上で広く使わ れているツールとしてはTeX, Emacs, sendmail, bind, perl, gnuplot, procmail などは、役に立つツールであると同時に、その 複雑怪奇な仕様によって長年に渡ってユーザを苦しめ続け、バッド ノウハウの温床として悪名が名高い。こうしたツー

シンプル＝バッドシグナル説 知人と話していて、シンプルという言葉は手抜きの言い訳として使われることがあまりに多いので、シンプル＝バッドシグナル（バッドな兆候）なのではないか、という話になりました。 シンプルが言い訳としてよく使われるのは以下のような場面です。 必要な機能が足りていない デザインがださい そこらじゅう手を抜いている プログラミングにおいてよくあるのが、まじめに実装していないクラスに Simple なんとかという名前をつけるパターンです。自らシンプルと名乗っているものには疑ってかかったほうがいいのかもしれません。 以上、シンプルな考察でした。

読解いやな法則: にわかな奴ほど語りたがる 私のウェブサイトでひそかに人気のあるコンテンツにいやな法則があります。思いついたいやな法則を箇条書きで集めているページです。 解説をつけると野暮になると思い、あえて箇条書きだけにしていたのですが、法則にまつわる背景やエピソードはいずれまとめてみようと思っていました。今回はその第1回として「にわかな奴ほど語りたがる」を取り上げたいと思います。 この法則は要するに、自分の行動パターンそのものです。最近、 C++ についてのエントリをよく書いていますが、これはまさに「にわかな奴ほど語りたがる」の典型例です。 ホームページ作成が流行り始めた頃は、想像を超えるかっこわるさの「○○君のホームページ講座！」のようなページによく遭遇して度肝を抜かされたましたが、これも「にわかな奴ほど語りたがる」による行動パターンと思われます。 私は、何か本を読んで感銘を受けたと

最初の一冊はワインバーグの「スーパーエンジニアへの道」にしました。 この本は コンサルタントの秘密―技術アドバイスの人間学と相補的な内容となっています。スーパーエンジニアの方は主に自分が学ぶするための方法、コンサルタントの方は人に影響を与えるための方法について書かれています。以前に、コンサルタントの秘密を読んで改心した話を書いていますが、結局のところ、基本的にはあまり変わっていないような気もします。

yak shaving で人生の問題の80%が説明できる問題 つい最近、 yak shaving （ヤクの毛を刈る）、という言葉を知りました (原典)。これは「一見無関係に見えるけど、真の問題を解くのに必要な問題を解くのに必要な（これが何段階も続く）問題を解くのに必要な活動」という意味の言葉です。 yak shaving は、ようするに「ある問題を解こうと思ったら別の問題が出てきて、それを解こうと思ったらさらに別の問題が出てきて…」ということが延々と続く状況を表しています。ちなみに、ヤクとは毛が長い、牛の一種です。 yak shaving は、以前に覚えた bikeshed と同じくらい便利そうな表現です。というもの、プログラムを書いていると yak shaving 的な状況がすぐに発生するためです。 たとえば、「Amazon のほしい物リストを CSV 形式に変換して Excel で読み

この文書は何だ? この文書では「いい作品とは何か」という本質にはまったく迫らず、 作品をよく見せるための、手っ取り早く実践できるお手軽なテクニッ クを紹介する (実は難しいものも混ざっているが)。ここでいう作 品とは主にソフトウェアや研究成果のことを想定している。他にも いいテクニックがあればぜひ教えていただきたい。 目次 作品の公開 公開する Webページを作る いい名前をつける 宣伝する 作品を公開する理由 作品を公開しない理由 作品の表現 作品の見せ方に気を配る プレゼン資料の作り方 プレゼンの仕方 ソフトのデモの仕方 Webページの作り方 図の描き方 色の選び方 フォントの選び方 クリップアートの使い方 グラフの描き方 表の描き方 ビデオの作り方 写真の撮り方 文章の書き方 その他 他人の作品および作品の表現 参考文献 あとがき 謝辞 作品の公開 公開する 公開されていない作品は存

その1: なまず 額に入れれば何でも芸術っぽく見えるんじゃないの? と思い立って なまずの絵を額に入れてみた。 なまず芸術: 額に入れただけ いまいちである。 とある先輩 から助言をもらった。 「芸術作品」として何かが欠けている。 ずばり、朱印かサインがあれば芸術っぽくなると思われる。 あとは、あいだみつを風な文章があると良い感じ。 「いつも底のほうでぼーっとしている でもその感性で一目置かれている そんな、なまずみたいな生きかたもいいじゃないか」 とか。 さっそくやってみた。 なまず芸術: 変な文章と朱印入り 少しはよくなったが、まだまだである。 その2: 額の内側に台紙を入れる 知人から「『芸術作品』にはまだ足りないものがある。それは額装だ。 額の内側に台紙を入れるべし」と指摘された。 内側に台紙を入れた額装 その3: 端末野郎 額の内側に入れる台紙を入手し、 ノートPCの液晶ディ

yak shaving で人生の問題の80%が説明できる問題 つい最近、 yak shaving （ヤクの毛を刈る）、という言葉を知りました (原典)。これは「一見無関係に見えるけど、真の問題を解くのに必要な問題を解くのに必要な（これが何段階も続く）問題を解くのに必要な活動」という意味の言葉です。 続きを読む...

思いついたいやな法則を集めています。 生産性 何もやらないよりはだらだらやった方がまし せっぱつまらないとやらない。せっぱつまってからではできない やらなければできない。やってもできない やらなくていいことはできる やらなければいけないことは楽しくない やらなくていいことをやっている人はいきいきしている 横着をするための労力を惜しんではいけない 横着をするための労力を惜しんではいけない、という口実で現実逃避してしまう 現実逃避の方が生産性が高い いやな仕事は、もっといやな仕事があるとき、いやではなくなる 決断 正しいことはすぐに中断し、間違ったことには頑固にしがみつく どちらかじゃなくて両方欲しい アイディア 考えて出てくるアイディアにろくなものはない アイディアを探してもアイディアは出てこない すぐにでも実行したいアイディアは嫌な仕事をしているときに思いつく よいと説明しないとわからない

ポール・グラハム論法 ポール・グラハムの「ハッカーと画家」はハッカー的な人間のための癒し系エッセイである。ちょうど、もやもやと考えていたようなことを気持ちよく代弁してくれる。 氏のエッセイを読んで感化された人間は、「ポール・グラハムも言っていた」という一言を自分の主張に加えるという誘惑にかられる。虎の威を借りる作戦である。 これをさらに押し進めると、ポール・グラハムが言っていないことでも、ポール・グラハムが言っていたことにするといういかがわしい論法にたどり着く。「100論文は1ハックに如かず、とポール・グラハムが言ってたよ」という具合である。 「100論文は1ハックに如かず」はめちゃくちゃだが、ハッカー的な人間にとっては一理なくもない。ポール・グラハムも言っているように、大学などにいるハッカーは、論文を書かなくてはという強迫観念にかられ、結果として、ハックの手を止めてしまう。これは社会的な

作れる、作る、作った たまに「Namazu を作ったなんてすごいですね」と言われる。そう言われると、いつも違和感を感じる。同等のソフトウェアを作れる人ならざらにいるからだ。作れることは自体は全然すごくない。 では本当は何が評価されているのかというと、何かを作って公開し、それが比較的広く使われたことだ。作れる人はざらにいるし、同じようなものを作ってみようと考える人もそこそこいるけど、実際に作ってくれる人はなかなかいない。だから、作った人が登場するとありがたがられる。それが広く使われれば、より評価される。案外、自分ではたいしたことないと思っているものでも好評を博したりする。 文章でも同じことが言える。誰でもうすうす分かっていて、誰かが日頃から考えているようなことでも、それを書いてくれる人はなかなかいない。だから、書いた人が登場するとやっぱりみんな喜ぶ。それが広く読まれれば、より評価が高まる。読

プログラミングに関するノウハウは大きく 3つにわかれると思う。 (またもや強引な分類) 1. 普遍的なノウハウ アルゴリズム, データ構造, オブジェクト指向, ツールボックスアプローチ, λ計算, etc. 2. システムのノウハウ 言語処理系, 計算機アーキテクチャ, OS, ネットワーク, etc. 3. 雑多なノウハウ 恣意的なAPI, 恣意的な言語仕様, 各種ソフトウェアの設定, 各種コマンドラインオプション, ソフトウェアのインストール作業, 各種システムの仕様の違い, 「最新技術」, etc. プログラミングをする上では 3種類のノウハウすべてが多かれ少な かれ必要なのだけど、僕のような人は、ついつい 3番目の雑多なノ ウハウばかりが増えていってしまう。日々のネットサーフィンで得 られるノウハウは大抵これである。 雑多なノウハウというのは、「たまたまそうなっている」だけであっ

このページでは Unix Magazine 誌に 2002年1月号から 2003年2月号にかけて連載し ていた記事の元の原稿を公開しています。 目次 第1回: Unixのメモ技術 (2002年 1月号) 第2回: Migemo: 日本語のインクリメンタル検索 (2002年 2月号) 第3回: 履歴マニア (2002年 3月号) 第4回: ttyrec: 端末を録画再生するツール (2002年 4月号) 第5回: QuickML: 超お手軽なメーリングリスト (2002年 5月号) 第6回: chatty: 小うるさい端末 (2002年 7月号) 第7回: zphoto: ズーミングするオンラインアルバムを作るツール (2002年 8月号) 第8回: pdumpfs: 毎日のスナップショットを保存する (2002年 9月号) 第9回: Sary: Suffix Array のライブラリとツー

やっとくよ - 学校では教えてくれないバッドノウハウ英語 #2 学校では教えてくれないバッドノウハウ英語の2回は、"Will do." を取り上げたいと思います。主語も目的語もなく Will と do とピリオドだけで構成される、テストでは 0点をもらいそうな表現です。 この表現に初めて出くわしたのは、私が出した "I think it would be good to handle this case (この場合も処理したらいいと思う)" といった感じのメールに対する返信の中です。 そのときの返事は "Will do." の一文しかなく、主語が省略されているため、肝心の「誰がやるのか」という点がはっきりせず、もしかして、 "You will do that (お前がやる)" だったらどうしようとかなり焦りました。結局、省略されていた主語は "I" で、 "I will do that (

自転車置場の議論 人が集まると、なぜかどうでもいいようなことほど議論が紛糾してしまう傾向がありますが、このような現象のことを、FreeBSD のコミュニティでは自転車置場の議論 (bikeshed discussion) と呼んでいることを知りました。 この、「瑣末なことほど議論が紛糾する現象」はパーキンソンの法則という本の「議題の一項目の審議に要する時間は、その項目についての支出の額に反比例する」という法則として知られています。 この本の中で著者は、原子炉の建設のような莫大な予算のかかる議題については誰も理解できないためにあっさり承認が通る一方で、市庁舎の自転車置場の屋根の費用や、果ては福祉委員会の会合の茶菓となると、誰もが口をはさみ始めて議論が延々と紛糾するというストーリーを紹介しています。 このように、「瑣末なことほど議論が紛糾する現象」はパーキンソン氏によって見事に説明されているの

スルー力カンファレンス (スルカン) 開催決定！ ものごとをやり過ごしたり見て見なかったことにしたりすることを「スルーする」と呼ぶようになって久しい今日この頃ですが、このたび「スルー力」、すなわち、スルーする力に関する、 ITエンジニアのためのカンファレンスを開催することになりました。ユニークな靴下でおなじみの某社CTOをはじめとする豪華なスピーカ陣による講演が行われる予定です。 「人生の大半の問題はスルー力で解決する」とはスルー力研究の専門家の間では共通のコンセンサスですが、昨今頻発するネット上での炎上事件、人間関係上のストレス問題、あるいは仕事上での燃え尽きの多発などの事情から、スルー力に対する社会的、特にITエンジニアの間での認知度が足りないのではないか、という問題意識が今回のカンファレンス開催の背景にあります。 現在、スピーカは調整中の段階にありますが、スルー力のベストプラクティス

捨てる派? 捨てない派? 情報整理術は興味の尽きないトピックです。誰もが何かしらのこだ わりを持っているため、ひとたび議論が始まると、自分はこうやっ てる、俺も昔はそうやっていたが駄目だった、などと始まって収拾 がつかなくなります。これはちょうど誰もがうまいラーメン屋につ いて一家言を持っているのと似ています。 私の観察によると、ある種の人たちが情報整理術について議論を始 めると永遠に平行線で終わるようです。それは「捨てる派」と「捨 てない派」です。 捨てる派によれば、「物理的なものにしろ電子的なものにしろ、い らないものはどんどん捨ててしまえばよろしい。不要なものがたく さんあるから必要なものが見つかりにくくなるのだ。第一、ものが 少ない方が気分がすっきりする。昔から、墓場まで情報は持ってい けないと言われているではないか」ということになります。 一方、捨てない派によれば「必要か不要か簡

読解いやな法則: 何もやらないよりはだらだらやった方がまし 読解いやな法則の第5回です。今回はとりわけ怠け者にぴったりな法則である「何もやらないよりはだらだらやった方がまし」を取り上げたいと思います。 「何もやらないよりはだらだらやった方がまし」という言葉には、いかにも消極的な響きがあります。大抵のことは集中して作業した方がだらだらやるよりも断然はかどります。仕事であれば「だらだらやる」という発想自体がとがめられそうです。 それでは、自主的に専門書を読んだり英語を勉強したりといった場面ではどうでしょうか。このようなことはやらなければいけないわけでもなく、締め切りもないので、さぼるのは簡単です。こんなときに役立つのが「何もやらないよりはだらだらやった方がまし」の法則です。この法則によれば、何も読まないよりはだらだら 1ページ読んだ方がまし、となります。 1日に1ページというと相当少ない気がし

読解いやな法則: 横着をするための労力を惜しんではいけない 読解いやな法則の第3回です。今回は、プログラマに当てはまりやすい法則である「横着をするための労力を惜しんではいけない」を取り上げたいと思います。 以前に、横着プログラミングという連載記事の第1回で次のような言葉を紹介しました。怠惰は発明の母であるという主張です。 私は必要が発明の母だとは思わない。私の意見では、発明とは怠惰から、おそらくはまた、まさに無精から生じるものである。面倒を省くために。 -- アガサ・クリスティ 一方、 Perl の作者である Larry Wall は「プログラマの三大美徳は怠惰・短気・傲慢である」と述べています。怠けるためにプログラムやドキュメントを書くのはプログラマにとって最大の美徳である、とのことです。 このような先人の知恵を元に「横着をするための労力を惜しんではいけない」という法則は生まれましたが、

日本語テキストをテーブルで表示する DHTML でテーブルを作って日本語テキストを表示します。 文字を逆さまにすることもできます。 「将棋を JavaScript で作りたい。 駒を表示するために文字を逆さまにしたい。画像は使いたくない」 というようなことを知人が言っていたのに触発されて作りました。 いわゆる一発ネタです。 フォントは kbanner2 のものを変換して使っています。 ソースコード: font.js, tabletext.js, mkjsfont.rb 表示エリア