これから読む本
「これから出る本」を本屋で貰うのが楽しみだったのですが、最近もらってないなー、なんて思い出しつつ。
『グラフ理論』(R.ディーステル著 根上生也・太田克弘訳)を先日買いました。
学生時代私が所属していた研究室は、グラフ理論の研究室でした。だから多少は馴染みがあります。もうかなりの部分をわすれてしまいましたが、計算機科学的な応用でもグラフ理論は重要です。これからじわじわ読んでグラフ理論を思い出してみようかと思います。
2006年2月18日
2006年2月17日
擬人
モジュールだのオブジェクトだの、ソフトウェア内に出てくる何かをときどき「ひと」という指示代名詞で呼びます。私だけじゃなくて、まわりにもけっこうそういう人がおおいです。技術屋さんには普通にあることかな?
擬人化して捉えているという意識は希薄で、習慣的に無意識につかっています。
ある日、ユーザー認証を伴うシステムの構成のなかで、とある属性値を持っているオブジェクトについて話していました。
私 「このひとがこういう属性値を持っていたとしますよね？」
相手 「その属性はユーザーにつくものなの?」
「ひと」って言葉を安易につかわないよう気をつけよう。
2006年2月16日
最近読んだ本
『Joel on Software』
ビジネスとしてのソフトウェア開発に関する問題がユーモアにあふれた平易な文章で、しかし舌鋒鋭く語られた本です。すべてのソフトウェア技術者におすすめです。巷に溢れるソフトウェア開発方法論の本をいっぱい読んで目が回ってふわふわ浮き上がってるひと(それは私だ)には特におすすめです。地に足がつきますよ。
帯に「マネジメントの世界へようこそ」と書いてありますが、別にマネジメントに特化している本ではありません。もちろんマネジメントの話もあるんですが、帯での強調の仕方はちょっと適切さを書いているかなという気もしたり。
たとえば「漏れのある抽象化」という考え方はマネジメントが知っていればいいことではなく、すべてのプログラマが意識している必要があることでしょう。
この本で印象に残った主張を列挙。
- 顧客をチームに取り込むなんてムリだ
- オープンソースソフトウェアのやり方では上手にソフトウェアをデザインできない
- 報奨金は有害
- 抽象化された環境での開発は却って必要な知識量が増える
- 誰にでもできる「プラクティス」にはたいした効果はない
- 車輪を再発明せよ(それが必要なら)
- 80/20の法則なんてクソだ
えええ、っておもった方は読んでみてください:)
『Write Great Code Vol.1 ハードウェアを知り、ソフトウェアを書く』
あちこちに「グレートプログラマーは」とか「グレートソフトウェアは」なんて言葉が普通に出てくるのが楽しいです:) 翻訳もこなれていてよいです。
こういう低レベル(機械に近いレベルって意味ですよ)の話は久し振りに読んだので楽しくよめました。よくまとまっていると思います。
でも対象読者って誰なんだろう? というのをちょっと疑問に思いました。当たり前のことしか書いてない印象です。このレベルを知らないプログラマがいたら、このレベルを知る必要があるとは思います。しかしそういうプログラマはこの本読む意義が分からないんじゃないかな、『こんなことしらなくったってプログラムはかけるよ！』って。
Vol.4まであって、だんだん上の層にあがっていくみたいです。続きも楽しみです。
自分語りの恥ずかしいエントリ on SICP読書会
素人くさいSICP読書会に参加してきました。
こういう勉強会に参加するのは初めてです。参加したみなさまと話す話題が、どんな細かいことでもいまの私には非常に刺激的でした。ソフトウェアで遊ぶ感覚ってこういうのだったな。と、10年遅れで思い出しました。
ソフトウェアを書くことを仕事にしてからは、ある程度意識的にソフトウェアじゃないことに興味をもっていくようにしていました。それは悪いことばかりじゃなかったとは思いますが、「仕事だけじゃやだから」という判断は今にして思うと浅はかでした。だって仕事にするくらいソフトウェアに関することが好きだったんだから。
ソフトウェアではもうわくわくできない、って感じてたのは単に私が怠けていたのが理由だということがよくわかりました。
ソフトウェアで遊ぶことを忘れていたブランクは10年弱と長いです。ちょっと残念に思いますが、自分の性格をからすると避けられたとは思えません。後悔してもはじまりません。どんなことでも遅きに失したということはありませんしね。Better late than neverです。
えー、というわけでSICP読書会関係のみなさま、歳くってる割にやくたたずなわたしですが、これからもよろしくどうぞ。
2006年2月11日
わざわざ「自動生成」と名乗るものは
自動生成ってなんかダサいと思います。 いや、ダサいとかそうい問題じゃなくて、必要な時と場合もあるってのはわかるんですけどね。 自動生成ってのは、なにかのギャップを埋めるための暫定対応的なものなんじゃないかと思います。
同感。
例えばバーチャルマシンを例にあげると、あれって要はマシンが実際に実行するための命令を自動生成しているわけですよね。
てゆーか、コンパイラってマシンコードの自動生成器ですよね。
ソフトウェア開発の世界では、自動生成されたものをいじることが想定されていない場合やいじる必要がない場合、そのメカニズムを「自動生成」と呼ぶことはないように思います。JavaコンパイラがJVMコードを自動生成する、なんていいませんよね。自動生成を名乗るメカニズムは、生成されたものに人間があとから手を加えることを想定しているのではないでしょうかね。
生成されたバイトコードに手を入れないと使えないJavaコンパイラみたいなものですね、といったらいいすぎかな。初期のC++コンパイラはCのコードを生成するプリプロセッサでしたが、そっちのほうが近いかな。
自動生成といえば、設計モデルからコードを自動生成する、とか、制約として記述した仕様からコードを自動生成する、なんて話があります。私はこれにも懐疑的なんですが、書いてみようとしたらあんまり知識がない上に考えがまとまっていないことが分かったので出直してきます。
2006年2月 5日
かつて読んだ本
以前に読んだ本について本家で感想を書いた記事のうち、こちらの傾向にあいそうなものをリンクしておきます。コンテンツ水増しです。
- 『直観でわかる数学』 : 工学屋さんが道具としての数学について熱く語った本
- 『一冊で分かる数学』 : 数学の本質は抽象であることを数学者がクールに語った本
- 『暗号技術入門』: 暗号技術というよりはPKI全般についての主要な知識を、結城浩さんが分かりやすく語る本
最初は記事そのものをコピペしようかと思ったのですが、プログラマがそんなことしてはいけないだろう:D ということでリンクを貼るにとどめておきます。
日本人も日本語を学べ
ブログとかに向いたくだらないテーマに「英語を学ぶ前にしっかりとした日本語を学べ」とかいうのがある。あまりのくだらなさに即終了でもいいように思うのだが、当方もくだらないブログなんでそんな雑談を。
極東ブログの中のひとはわたしなんかよりよっぽど明晰な切れ者で、わたしよりずっと日本語を上手に扱うひとだと思っています。そのひとがこんなことを言うとは驚きです。
わたしは母語をちゃんと扱えない人間が外国語を学んだってしょうがないといいたいです。なぜなら人間は母語で考えると信じているからです。
アメリカで出版されている英語の文法書を眺めると「英語を使うため」の文法書であることがよくわかります。学校で使ってた日本における日本語の文法書を読んでも、日本語の使い方はさっぱりわかりません。思想的にはアレですが、本田勝一氏の『日本語の作文技術』を読むほうがよっぽど日本語の使い方が分かります。
アメリカ人はしっかりとした英語の教育をされているが、日本人はちゃんと教育されていないのではないかと私は疑っています。教育の必要がない一部のセンスあるひとだけが、しっかりとした日本語を使ってしっかりとした思考をしています。その人たちの多くは、自分が「しっかりとした日本語をつかっている」という自覚がないのかも知れません。
(「日本語が論理的じゃない」とかいう俗説がはびこるのは、教育の不備によって「日本語を論理的に使えるひとが少ない」のが原因ではないかと思うことがあります)
証明は困難ですが、ひとは言葉で考えていると私は考えています。System.exit();のこの記事によれば、ウィトゲンシュタインも言葉によらない思考である「私的言語」はありえないといっているそうです(虎の威をまごがりちゅう)。
日本人は日本語で考えます。だから日本語をしっかりと操れなくてはいけません。別に英語をしっかりと操れてもいいですが、とにかく思考の足場となる母語が必要です。日本に暮らしながら英語を母語とするのは難しいでしょうから、日本にいる日本人は日本語を選択するのが現実的でしょう。
(英語などの)外国語も日本語もコミュニケーションの道具です。母語である日本語は思考の道具でもあるのです。
とはいうものの「ひとが言葉で考えているかどうか」という証明も反証も困難(あるいは不可能)な問題への立場が根っこにあると思うから、同じ考えじゃないひとを納得させるのは無理なんだろうな。
と台無しにして、この論をしめくくります。
追記:
「ちゃんとした日本語」といったときに、過剰にウェットで装飾的で形容過多な日本語を思い浮かべる方がいるかもしれません。たとえばこんなんです。
都会の雑踏に疲れたわたしの頬を、ふと撫ぜた氷の女王の息吹のようなそよ風に、清冽な冬の静寂な訪れを予感した
いまわたしがでっちあげた文章なのでどっちにしても悪文ですが、こういう装飾を上手にすることはこの論でいう「ちゃんとした日本語」の範囲ではありません。また、わたしがでっちあげたこんな悪文ではない本当の「美文」レベルをここでいう「ちゃんとした日本語」に求めているわけでもありません。
2006年2月 2日
.NETのスレッド停止
超コネタ。
C#でスレッドを実装していて外部から停止させたいときにどうしようかと調べていたところ、Thread.Abort()を呼べばThreadAbortExceptionが対象スレッドで発生し、停止させることができると分かりました。しかしこのThreadAbortExceptionは特殊な例外で「catchしてもcatch節の最後で自動的に再スローされる」のです。
それを抑制するためには、Thread.ResetAbort()を呼べばよいとのこと。MSDNでThread.Abort()の項にはそのようなサンプルが書かれています。ぐぐってみても「再スローされる」ことに悩んだものの結局ResetAbortを呼ぶことで回避するようなコード例ばかりみつかります。
なんか変です。再スローされるという特殊な仕様にしたのはそれなりの理由があるはずです。その理由もわからずにResetAbort()を呼んで再スローを抑制するのは危険な気がします。
いろいろ調べたりひとに聞いたりした結果「通常の処理でスレッドを停止させたい場合にはThread.Abort()を使うべきではない」という記述がMSDNにあることを教えてもらいました。スレッド側はなにがなんでも停止させられてしまうため、リソースの開放が困難になる可能性があるから、という理由です。つまりAbort()を使うべきなのは急いで止める必要があるときということでしょうか。
でThreadAbortExceptionが再スローされる理由は結局分からなかったのですが、こんなところではないかと推測します。
- Thread.Abort()を呼ぶのは非常時
- 非常時でもcatchしてリソース開放などの後始末チャンスは与えたい
- でも非常事態なのでスレッドは例外で終了させたい
再スローされる特殊な例外にしたのは何故なのか、ThreadAbortExceptionの説明のところに書いておいてほしいですよね。MSDNドキュメントのどこかには説明があるのかもしれませんが...。
