[SICP] はてな支店へのエントリ(5)

なかなか進まない SICP の勉強ですが、それ少しずつ読み進めています。

参考文献、1.1.2 Naming and the Environment

あと、今までのタイトルとタグを少しかえました。一章単位で別ページにまとめようと思います。今のところ、はてなリングの SICP の日記あたりがいいかなと思っています。

まだ演習問題が出てきていないので、勉強というよりはノートを取っているような感じです。一応 Gauche を使って、本にある例を動かしてみたりしています。今日は slib をインストールして、trace の機能を入れてみました。trace を使うのはもうちょっと先ですが…

[SICP] はてな支店へのエントリ(4)

はてな支店の「もう一度勉強し直すSICP」エントリを追加したのでリンクを張っておきます。
10 pages / day どころか、もっと遅いペース…

1.1.1 の例を DrScheme でも動かしてみる
SICPを読むときの参考書
Instructor's Manual to accompany "Structure and Interpretation of Computer Programs"で気になった所の覚書き

今までの関連記事はこちらからどうぞ。

[SICP] SICP の勉強会を始めます
[SICP] はてな支店へのエントリを追加しました
[SICP] はてな支店へのエントリ(2)
[SICP] はてな支店へのエントリ(3)

非常にマターリとしたペースで続けております (^^;

[SICP] はてな支店へのエントリ(3)

はてな支店の「もう一度勉強し直すSICP」エントリを追加したのでリンクを張っておきます。
今日は原書の p.7 まで読み進めました。我ながら遅いですね (^^;

もう一度勉強し直すSICP (4)
1.1 The Elements of Programming
1.1.1 Expressions

今までの関連記事はこちらからどうぞ。
[SICP] SICP の勉強会を始めます
[SICP] はてな支店へのエントリを追加しました
[SICP] はてな支店へのエントリ(2)

Schemeに興味のある方は、今後ともよろしくお付き合いください (^^;

[SICP] はてな支店へのエントリ(2)

はてな支店に書いている SICP のエントリへのリンクを追加します。

3.もう一度勉強し直すSICP (2) 1. Build Abstractions with Procedures

4.もう一度勉強し直すSICP (3) Gauche をインストールする

ぽろぽろと五月雨式に追加していくのもなんか一覧性が悪いので、そのうちちゃんとホームページ作ります。しばらくは更新したら、こちらにも貼るようにします。

[SICP] はてな支店へのエントリを追加しました

先日、勉強するぞ宣言をした SICP ですが、昨日新しくエントリを追加したので、ここにも貼っておきます。

1. 2008-02-05 もう一度勉強し直すSICP (0) はじめに
2. 2008-02-06 もう一度勉強し直すSICP (1) 準備

SICPがらみの話を検索してみましたが、皆さん勉強熱心ですよね。私も学生の頃もうちょっとまじめにやってれば…後悔先に立たず。気を取り直して、もう一回やり直しです。これまで何度も挫折してきたSICP、果たして今度はやり遂げることができるのか？自分でもちょっと楽しみです。

[SICP] SICP の勉強会を始めます

以前のエントリ（[language] Objective-C, Java, Perl, Haskell, Scheme そして Ruby…興味のあるプログラミング言語の話）でもやりたいことの一つにあげてましたが、SICP(Structure and Interpretation of Computer Programs (Mit Electrical Engineering and Computer Science Series.))の勉強会を「はてなダイアリー」ですることにしました。

わからない方には「なんのこっちゃ？」ですが(^^; プログラミング言語の一種である「LISP」の一方言、「Scheme」を使って計算機科学について語った本です。大変評判の良い本で（Amazonの書評を鵜呑みにしてはいけません）、アメリカの主立った大学ではコースの教科書として使われている本です。まあつまり、昔でいう購読会とか勉強会をBlog上でやってみるかと。ほかにもやっている人はいるかもしれませんが、自分の手足をつかってみないとわからないので、とにかく初めてみることにしました。

別に場所を移さなくても…とは思うのですが、同じ内容のエントリが集まっていた方が検索性がいいかなと。親指シフト関係の話は、はてなグループ内の日記に書くことにしました。既存のエントリはそのうち移動する予定。

Sio’s Gadget Blog はてな支店
http://d.hatena.ne.jp/Sio_Ikzk/

ここのブログにはエントリのリンクを張ります。よかったら読んでやってください(^^;

これで私が継続してエントリしているネタは

• 勝間和代さん関連
  
• プログラマ本
  
• Macネタ
  
• Mac開発ネタ
  
• SICP
  

の５つになりました。思えば遠くへ…いえいえ、まだまだこれからも書き続けます。

[books] 塹壕から来た？！プログラマのための本…Code Craft --- The practice of writing excellent code

今読んでる本が結構面白いので、まだ読み終わっていませんが紹介したいと思います。
Code Craft ~エクセレントなコードを書くための実践的技法~
Code Craft: The Practice of Writing Excellent Code


私はプログラマ本を読むのが好きなので、目新しいのがあるとついつい買ってしまうのですが、この本は前書き（Preface）にやられました。

This book comes from the trenches. Well, it actually comes from deep within the software factory, but sometimes there isn't too much difference.

(拙訳：この本は塹壕から来た。まあ、本当はソフトウェア工場の奥のほうから来たんだけど、でも時々、それってそんなに大きな違いはないんだ。）

いや、深いですねぇ…私の実感からいっても、確かに「時々」死屍累々という感じで、救いがたくなる現場がある（あるいは「あった」）のは事実だと思います。そんなところから来る悩めるコーダーたちへの福音とはいったい？俄然興味が湧いてきて、今読んでいるというわけです。

ちなみに参考までに拙い訳をつけてみましたが、これは単に英語版の本しか持っていないからで、日本語訳も出ていますので、それを見ればもっとまともな訳が載っていると思います（汗）

肝心の内容ですが、プログラマのタイプ別分析や、その人たちと一緒にどう働けばいいのかなんていう処世術っぽい話もあります。他にも業界別のプログラミングに関する特徴というか法則というか、そんな話題もあって、コーディング・テクニックだけ、というよりは、もう少し社会的・ライフハック的な観点が入っているようです。ソースコードが大量に出てくるわけでもなく、割と楽に読めると思います。とはいえ、私は英語に負けて日本語版も買ってしまいそうです(^^;

コーディングの話だけじゃないところが私は気に入っています。海千山千のソフトウェア業界で苦労されている方にお勧めしたい一冊です。

プログラマ必読の書---お薦めの本：Joel on Software

プログラマやプロジェクト・マネージャ必読の書といわれる本です。私もようやく読み始めました。英語版で読んでいるのでなかなか進んでいないのですが、うなずけることばかりです。日本語の本と英語の原書へのリンクを張っておきます。

Joel on Software, Joel Spolsky著

この本は、著者Joel Spolskyのブログ "Joel on Software"を編集加筆したものなので、実はWeb（英語ですが…※）を読めばだいたいのことはわかってしまいます。しかし、画面上ですべてを読むのは大変なので、私は本を買って読むことをお勧めしたいと思います。
※日本語訳も一部あるようです。

さて、コーディングのことというよりは、プロジェクトマネジメントに近い話が書いてあるこの本をなぜプログラマがなぜ読むべきなのか？ということなのですが、私はこれはプログラマが効率をアップさせるために、ひいては無茶を言ってくるマネージャの論理を粉砕するために（もっとも粉砕したところで、往々にしてスケジュールには影響しなかったりしますが（泣））必要なことが書いてあると思うからです。

残念なのは原書に載っているものは8年前だったりするので、今やJoel Spolsky自身が「これは読まないで！」とWebに書いてあるようなものもあります。たとえば、

Painless Software Schedules, March 29, 2000

と

Evidence Based Scheduling, October 26, 2007

ですね。本に載っているのは "Painless ..." の方なので、Joel Spolskyいわく学んで進化したスケジューリング方法を合わせて読んでみるとよいと思います。

とはいえ、今開発の現場で7年前の教訓でさえできていないところがあるのではないかと思うのです。マーフィーの法則によれば

"If it can happen, it will happen."
「起こる可能性のあることは、いつか実際に起こる。」

だそうですから、きっとどこかの現場ではDeath Marchまっただ中というプロジェクトがあるかもしれません（あまり想像したくありませんが…）

私が一番コーディングに費やす時間（コーディング量ではないところに注意）が多かったと思われる1990年代には、まだWindows95は出てきていませんでした。表計算ソフトはExcelはMacintoshではあったものの、DOS版のはMultiplanという高ーいソフトがあったくらいでしょうか…当時流行りだったLotus1-2-3のような表計算ソフトを、Joelがいうようなやり方でスケジュール管理に使おうなんて思ってもみませんでした。これを知ってたら、多少なりとも改善できたのになぁ…と思うわけです。

もっとも、その当時、バージョン管理ソフトなんて知らなかったし、汎用機で開発していたので、その辺の仕事は全部ライブラリアン任せでした（遠い眼）

つまり、自分で進捗管理するためのツールはOASYSで作った表がすべて。作って提出したらそれでおしまいで、日付を数値として扱って、どれだけの日数を費やして、どれだけ予定から遅れているかor進んでいるか、などを振り返るようなことはありませんでした。

あるプロジェクトにかかわった時は、最後のほうは、ほとんどデス・マーチといってよい状態でしたから（そういえば当時はデス・マーチなんて言葉はなかった）、自分で細かい進捗管理なんて余裕はなかったし（爆）プロジェクト全体はともかく（管理者でないから手に負えない）、もうちょっと自分のことを管理できるスキルがあったら、体を壊すなんてこともなかったなぁと、しみじみと思い出します。そういう発想さえなかったこと自体、ワーク・ライフ・バランスをいかに崩していたかという証左でしょう。

何かを改善しようと思ったら、今の言葉でいう「見える化」（この言葉は私は好きではないので「可視化」といいかえたいと思います）をしなくてはいけないと思います。それが「Evidence Based Scheduling」であったり、「可視化」の作業だったりするわけです。何をどうすればよいかという話は、ぜひJoel Spolskyの書いた本Joel on SoftwareやBlog "Joel on Software"を読んでみてください。

「可視化」に絡めて、私には心配なことが一つあります。この「可視化」やら「Evidence Based」で仕事をするためには、なにかしら開発者の作業logを取る必要があります。私のように一人プロジェクトで自ら率先してするのはいいのですが、ある程度以上の規模の会社だと、逆に労務管理が行き過ぎたりとかする心配もあります。あくまでも、取得したlogは、プロジェクトの生産性の向上にのみ使われるという了解があって成り立つものだということを、運用管理する人は肝に銘じてほしいなと思います。悪意のある管理者は、コンピュータのシステム上では何でも出来てしまいますから…

そうそう、本題とはちょっと話が横にそれますが、プログラマなど実際の作業をする人は、先ほど述べたような作業logを取られていることの潜在的な危険性もあることをよく理解して、言い訳のできない内職などはすべきではない、ということをよーく考えてほしいと思います。就業時間中や大学の講義やら演習中に、全然関係ないWebサイト（たとえば、Mixiやら人に見せられないWebサイト）を大学や会社のネットワークから覗きにいったりしていませんか？そういうことをしている人に親切心から注意すると逆切れされたりすることもあるのですが（私は、そういう人に限って注意した時に逆切れしたり、あとから別件での文句をいうが多いことに、演習や講義を担当してはじめて気がつきました…彼or彼女らは自分のしていることが分かってないのでしょうか？）それって、大学や企業の管理者にはバレバレだってことを、理解しているのでしょうか？大学だったら真面目にやってない証拠と教官に理解されて、場合によっては単位を取れなくてもおかしくないでしょうし（悪質な場合は退学だってありうる）、企業だったらクビになりかねません。（アメリカではE-Mailは管理者がすべてフィルタにかけて、怪しい人をチェックするそうです。こういうことがあると、産業スパイなどの嫌疑をかけられても申し開きをするのは難しそうです。）

生産性の向上だけでなく、自分のための危機管理（過労死を労災申請するときには、この日報や作業ログが重要な証拠と成り得ます）という意味でも、日報やら日々の作業ログは自分で自覚的に取るべきだと思いますが、いかがでしょう。

知のFramework - お薦めの本：効率が10倍アップする新・知的生産術―自分をグーグル化する方法

今年のビジネス書を出版された著者の中で私が一番気になってずっと追っかけていた方、勝間和代さんが、また新刊を出版されました。それも僅かな期間で３連発！それぞれにターゲットとする読者層が違う本をつづけて３冊も出されるのは本当に素晴らしい。（これだから、健康には気をつけなければいけませんと反省しきり）

さて、その直近３冊のなかでも、技術者の端くれとしての私が、一番広く読まれて欲しいと思うのがこの本、

効率が10倍アップする新・知的生産術―自分をグーグル化する方法

です。これは凄い。巻頭カラー、巻末もカラー！300ページ！
ご自身のBlog「私的なことがらを記録しよう!!」で述べられていた（こことここ）とおり、仕事の効率を上げる技術が満載です。

技術的な事はもとより、やはり勝間さんのこの本の神髄は「いかにして知的生産の効率を上げるか」の一言に尽きるともいます。ホワイトカラー版の「かんばん方式」ですね。効率を上げるためにはどうすれば良いか、というこの一点について語り尽くされていると言って良いと思います。

　実は私はこの本のタイトルを見たとき、『「知的生産術」とは大胆な！』と思いました。勝間さんも著書で触れられていますが、「知的生産」とくれば、私はまず最初に梅棹忠夫先生の著書『知的生産の技術 (岩波新書)』を思い浮かべますし、野口悠紀雄先生の『「超」整理法―情報検索と発想の新システム (中公新書)』などの一連の「超整理」本や、立花隆氏の『「知」のソフトウェア (講談社現代新書 (722))』も読んで参考にしてきました。その事が念頭にあったので、「これは野心作だな！」と思ったのです。

　では、勝間さんの著書と諸先生方の知的生産の技術では何が違うのか。私は３つあると思うのです。

（特徴１）いうまでもなく、知的生産に関するコンピュータの活用のための情報であると思います。これは諸先輩方の著書の出版時期を考えれば、至極当たり前の事かもしれません。この本はマニュアルではないので、コンピュータに詳しくない人は、ソフトウェアの使い方については自分で四苦八苦しながら体得していかなければなりませんが、それでも、どうすれば効率化できるか、という点でもう解があるわけですから、その試行錯誤がないだけでも大幅に無駄を削減できます。
　そうそう、親指シフトキーボード（今手にはいるのはこれかな？「富士通 親指シフト キーボード FKB8579-661EV」）は、私もお薦めします！是非使ってみて下さい。

（特徴２）勝間さんご自身が体得した情報の交通整理の方法について。(1)簡略化、(2)階層化、(3)フレームワーク化という事を通して、どうすればあふれる情報に負けないで、自分にとって有益な、いかに雑音の少ない入出力が得られるか、その方法の一端に触れています。また情報の入出力をどう効率化するかについても語られています。

（特徴３）いかに健康な体を維持するか、という点での技も見逃せません。病気にかかってはじめてわかる健康のありがたさ、ですが、とにかく人間の脳は体の一部である以上、体が疲れていれば、なかなか冴えた考えというものは浮かばないものです。（もちろん、病気だからと言って、優れた考えが出来ないという訳ではありませんよ！念のため）
　知的生産の効率を下げるリスクを遠ざけるにはどうすればよいかいろんな方法が具体的に語られています。私を含め、不摂生を自覚している人は、よーく読みましょう。

　アメリカ流のビジネスが流行る現在、MECEやフレームワークという情報の整理術を知っておくのは、今や必須といえるかもしれません。私が外資系で働いていた頃、同僚から「話が分からない」と言われ続けたので、何が悪いんだろうと自問自答していました。今、これを読んで目から鱗が落ちました。なるほど、そういう考え方、情報の交通整理の訓練をしていないことには、相手にとって「わかる」あるいは「意味のある」話は出来ないわけです。自問自答していては、同じ所をぐるぐるしているだけで、相手にわかるはずもありません。彼の国でみんながMBAを取りたがる理由がよくわかります。同じ土俵に登るためには、同じ技術を身につける必要があったわけです。
　私の愛用のシステム手帳は「フランクリン・コヴィー」（ちなみにこんなバインダーです）なのですが、考えてみれば、コヴィー博士の「七つの習慣」も「フレームワーク」ですね。急がないけど重要な事項、と言葉だけではなかなかわかりませんが、重要である・重要でない、緊急性がある・緊急性がない、という対立軸をグラフ化して見せられれば、なるほど！と誰しも思いますね。

いやー、これだけの内容、よく１１万字で収まったものです。いつか「削られた５万字分の内容」も知りたいですね。これからも目が離せません。是非これからも頑張って欲しいなと思います。

　余談ですが、コンピュータ・プログラミングの世界でも、今や「ライブラリ」とは言わず、「フレームワーク」と言いますね。昔と今では「図書館」に通ってあれこれ探すのではなく、Googleのサーチエンジンを使って「ググる」（＝検索する）くらいの違いはあるのかもしれません。

頭の中身と計算機のデータの混沌

デスクトップ・メタファは言うまでもなく、Xeroxのパロアルト研究所で発明された優れものだ。以降、Lisa, Macintosh, NeXT, etc., いろんなものに影響を与えてきたことは、ここで述べるまでもない。

しかし「デスクトップ」という実世界にあるモノを計算機上で見せる形になったため、限りある計算機の資源を人間の頭の中のカオスを計算機にもインプリンティングしてしまったのではないか、と良く思う。もちろん人間が使う以上、そのようなことは当たり前の事かもしれない。でも、これを考えた人は、個人が何十万というファイルを扱ったり、何GB、何TBとというメモリ空間を使うことは考えた人はそう多くはなかったんじゃないだろうか。

テキスト情報だけでなく、音声、画像、動画、etc., いろんな形のデータがパソコンの中にあるが、これを自動的に（自分のやり方にならって）整理することをパソコンに教えることは、実は大変な事である。

まず、絶対にデータがなくなって欲しくない。自分の大事なデータが移動中にどこか行方不明なんて、できの悪い運送業者のような事にはなって欲しいわけがない。それに、思いついたらすぐに出せるようにしておきたい。何時間も検索に時間がかかるようでは使い物にならない。できればバックアップも自動的にやってほしい。でも、これってかなり面倒…市販のツールをいくつか試してみたが、ちゃんと復旧できたためしがない。ディスク丸ごと復旧するのにシステムや基幹のアプリの再インストールをしなくてはいけないようでは困る。

他にも考えてみれば、どんな事をして欲しいかは、いくらでも出てくるかもしれないが…定型の処理なら何とかスクリプトで書けても、その整理法をどうするか、となると頭が痛い。

野口悠紀雄氏の言う「超」整理法は、コンピュータのページングのアルゴリズムでいえば LRU や NFU みたいなモノだが、それでも、思いつきで何かを過去のデータから調べるにはちょっと物足りない。（頻繁に使うものはいいのだが）

結局無差別に大容量のHDDに全データをぶち込んで spotlight か Google Desktop で検索するという方法に落ち着いているのだが、Google Desktop はオプションを切り忘れると、勝手に頻度データなんかをGoogleにレポートされそうで、ちょっと嫌。今のところインデックスを作らせてはいるが、なんとなく心配は心配。

検索アルゴリズムは他にも優秀な人が沢山いて、日々研究成果が上がっているので、私なんぞがクビを突っ込んでもじゃまにしかならないだろうが、個人的な問題の解決に向けては、研究する価値は有りそうだ。検索に100%頼るのでなく、情報の整理も検索を助ける方法として、時間短縮に効果があるだろう。

このへん、ラザルス・ロング（SF好きならおわかりですね？）が「メトセラの子ら」で記憶の整理方法ということでずいぶん検討しているようだったが、詳細がよく分からず残念（苦笑）

なにより、計算機は「持ち主の頭以上には賢くならない」そうだから、結局、計算機に何かを期待するのではなく、計算機を使ってどんな仕事ができるか、ということが大事だと思う。それをみんな考えて作ってきたんだから、人類の知恵として、昔から今に至るまでの成果を科学史としてまとめたい、という野望を持ってしまうのであった。

すくなくとも、加齢と怠慢により「物忘れ」が酷くなった時のバックアップにはなるかも、と期待しているのだが…このブログもバックアップしておかないと（ｗ

だれか「光あれ！」とかコマンドを言うと、勝手に頭の中のモノが分類されるソフトをつくっちゃくれんだろうかのう。（光＝重要書類と闇＝強制削除に分けられても困るけど）

徹夜で論文書き

この前研究会発表でした話をアメリカの学会に投稿しようとして、締切ぎりぎりで提出。物は5日にはネイティブチェック済みで帰ってきていたが、LaTeXとBibTeXのフォーマット合わせが思ったようにいかず…結局中途半端な感じで出さざるをえなかった。文献、もっとあったんだけどなぁ…しくしく。

Wordで5ページだから、かなり削ったのだが、いざレイアウトしてみると3ページでちょっと少ない感じ。2ページの余裕があるんだったら、もっとかけたなぁ。今度からは最初からテキストエディタで書こう…

しかし、久々に徹夜した。お肌に良くない。英語ももっとブラッシュアップしないと…でも養老先生ではないので、いきなりネイティブにOKといわれるようになるまではかなり頑張らないと…

LaTeXとBibTeXはだいぶ分かってきたので、あとは図表の配置の仕方を研究しなくては。

今回査読付きのConference Paperなので、採用されるかどうか心配。acceptされますように。

物欲、again

ほすぃぃぃぃぃぃ！！！！！

http://www.apple.com/ipodtouch/

これは欲しいでしょう。iPod touch. 無線LAN使えるし。とりあえず都会ならなんとか使える。
でも8GB, 16GBモデルってところがなぁ…
買ったことがないのが第二世代だけというiPod好きですが、今の願いは300GB超のiPodが出てくれないかと言うことだったりする（昔のように、FireWire使えるようにしてくれというのもあり）

うちのiTunesライブラリ、日々増えるPodcastのデータで、すでに300GB超えてるし（爆）
バックアップ用に500GBのHDD導入したけど、これもいつまで持つやら。

買うとしたら、iPod Classic 16GBになるだろうけど、いつ発売になるか分からないiPhoneよりは、欲しいなぁ。…しかし、両方買うお金がないなぁ…

X端末と仮想化デスクトップ

IT Media News
「ソフトゼロ」の仮想化デスクトップ

この手の製品を見聞きするたびに「X端末だぁ」と思ってしまう。これはWindows鯖につながるマシンらしい。曰く、

Panoデバイスはすべてのソフトをデスクトップからサーバに移しているため、ソフト更新の必要などがなく、デスクトップTCO（総所有コスト）を70％減らせるとPano Logicは述べている。

大規模な事業者は、従業員のパソコンを管理するコストを減らしたいから、結局、サーバ上に全部物を置いて、セキュリティ対策万全！っていう感じにしたいのだろう。実際、よく忘れ物をして、個人情報企業秘密だだ漏れ…っていうのはよくあるし。

今までさんざんダウンサイジング（死語？）だのSOAだのと言って目指してきたのが、これなのか？ダム端末に汎用計算機っていうスター型の図式と違うところと言えば、各マシンの性能が一昔前とは段違いという事になるんだろうけれど…それでも数が多くなったときのホストの処理能力や、ネットワークのトラフィックは大丈夫なんだろうか。

企業などで使うときには一極集中型の方が管理しやすいし便利ということなのか？（まあ、それはそうだろう。）サーバが攻撃されたら、どうしようもなくなるという根本的な脆弱性については、よりいっそうリスク要因を大きくするだけなのではないか？

ノートパソコンに代表されるようなパソコンは、もはや企業ではお荷物的存在で、そのうち、こんなのに置き換わっていくんだろうなぁ。でもって、今のPCは、きっと真の意味でPersonalな物になっていくような気がする。

個人的な感想を言えば、企業はそれで良いかもしれないが、計算機のあり方として、本当にそれでいいのかという気がする。自分の計算機利用（プログラミングを含む）のリテラシーを上げておかないと、それこそビッグブラザーに無断で接続されていても後の祭り、という怖い考えになってしまった。杞憂だといいのだが。

権力や情報が集中するのは、計算機の世界も、政治の世界も、経済の世界も、多様性を認めないという意味で、あんまり良くない気がする。行き過ぎた管理社会にはご用心…

外来語の表記についての思い出

exciteの小ネタでこんなのがあった。

“コンピューター”と“コンピュータ”正しいのはどっち？
http://www.excite.co.jp/News/tb/News/bit/00091183909194.html

どっちでもいいじゃないか！と思うあなたは、ある意味正解だ。どちらでも良いというのがこの記事の結論である。

でも、ココで注意が必要なのは、記事にもあるが、JIS規格では３文字以上のカタカナ語の語尾についている長音記号「ー」は省略が原則であること。
さらに言えば、メーカー（これもメーカと表記しても良い）なり、ある書籍なり、情報の単位ごとに、用語が統一されている必要はある。（これは基本）

たとえば、マニュアル毎に「コンピュータ」と「コンピューター」が混在していては、読む側が混乱するということなので、大体は、メーカー毎に統一されているはずである。

と、いうような事は実は私は国語の先生ではなく、私の恩師の一人であるN村教授に、それは厳しく突っ込まれまくった。N村教授はJIS規格に深く関わっておられたので、その基準で学生のレポートを厳しくチェックされていた。カタカナ用語だけでなく「てにおは」から果ては句点・読点の打ち方まで、これでいーだろーと思って出したレポートが、真っ赤になって帰ってきたのを懐かしく思い出してしまった。なんで相当枚数ある卒業論文の最初と最後の用語の不統一が指摘できるのか、未だに不思議だ。

聞けばN村教授は、Donald Ervin Knuth米国スタンフォード大学名誉教授から小切手を受け取ったことがあるという…凄すぎる！

※クヌース先生の小切手の話は次を参照
※日本の先生方で、他にも沢山そういう方がいらっしゃるが、N村先生を含めて、誰一人として換金していないらしい。世界中を観てもだれも換金してないんじゃないだろうか？Computer Science界の一番の栄誉というのもうなずける。

フリー百科事典『ウィキペディア（Wikipedia）』「ドナルド・クヌース」の項
http://ja.wikipedia.org/wiki/ドナルド・クヌース

Technology Review (by MIT)
http://www.technologyreview.com/Infotech/11960/?a=f

いまあんなに厳しく指導してくれる先生は居ないのではないか？ていうか、自分がそう有るべきではないのか？と思いつつも、実行できてないのが恥ずかしい…

いまだに用語の不統一甚だしいBlogなんぞを書いているあたり、もう一度気合いを入れ直さなければと思うのであった。

◎◎Hacks

最近ビジネス書で「◎◎Hacks」と名前のついた書籍をよく見かけるようになったなぁと思う。

たとえば、東洋経済新報社から出ているIDEA HACKS!やTIME HACKS!、 PLANNING HACKS!は今でも書店で平積み状態だし、技術評論社からもいくつか同様のビジネススキルに関するTips集が出ている。今挙げた三冊とも購入し、読破した。話の内容は、新人社員でも今からこつこつやれば、モノになりそうな技でまとめてあって、楽しく読めた。私的には知ってる話が多かったかなぁ…使いこなせているとは言えないけれども。

最近のこの手の話の肝はパソコンやインターネットの機能を上手に使うという事に尽きる。ちょっと前までTipsと言っていた話だ。

今時はこうしたTipsをHacksと言ったりするのだなぁと思ったりもする。HackerとかHackingといえばコンピュータを使った悪人や悪事の代名詞の用に言われていただけに、時の移り変わりを感じる現象ではある。とはいえ、本来の意味とは違った意味で使われている事に忸怩たる思いをしていた真性Hackerは多かっただろうと思う。やっと本来の意味で使われてはじめた事は、めでたい事ではある。

私の認識では、最初にHacksと堂々と名前をつけはじめて書籍シリーズを作ったのは、コンピュータ関連の専門書籍出版で有名なオライリー(リンク先は米国O'Reilly Media Inc.子会社のオライリージャパン)だと考えている。しかし、最初かどうかは私も具体的に証拠があるわけではないので、その点、異論があるかもしれない。

この流れで技術評論社他各社がHacksと銘打った本を次々と出版し、ビジネススキルにHackの意味範疇を拡大させて、しまいにゃ人生(Life)までHackの対象にしてしまった。

小技集でもTipsでも裏技集でも、使える技の集合を呼ぶのに何語を使ってもなんと呼んでも良い、とは思う。しかし、一方で「なんでもかんでもHacksと呼んでしまうのはどうよ？＞俺」と一人斜に構えてしまう。

「具象を言語化する日本語、抽象を言語化する英語」とは私の今は亡き大学の恩師がよく言ったもので、こうした現象を見ると「確かにそうだなぁ」と思う。英語は概念が同じなら同じ名詞、同じ動詞を使うし、それが具体的な物事を中心に考える日本人にとっての解りづらさにつながっているという話だ。HacksやTipsも日本語より使われる頻度が上がっているんではないだろうか。この小さな違和感は、日本語を母語として使う日本人だからなんだろうか？

というわけで、日本語サイト限定でググってみた。

　Hacks --- 約2,030,000件
　Tips --- 約2,410,000件
　小技 --- 約1,520,000件
　裏技 --- 約2,550,000件

この結果だけなら、「裏技」という言葉も案外使われている。ファミコンや「伊東家の食卓」様様？
でも「人生の裏技」って、なんか「アレな感じの人」に思われそうで嫌（苦笑）
Tipsは市民権を得てる感じで、Hacksは成長株でしょうか？
私的には、TipsよりはHacksの方が手続きが煩雑そうな気がする。

日本語は具象物にそれぞれ名前をつけていくというのが伝統的な言語化の方法であるように私は考えているのだが、こういう外来語を多用することで、本来の日本語的な造語能力が削がれているのではないかと思うことしばしばである。それとも外来語が一つ増えただけで、日本語の柔軟さを誇るべき？

せめて日本語書籍のタイトルは、英語とは別に、もう少し雅な言葉で考えて欲しいなぁと思うのであった。
もっとも、日本のコンピュータ関係の専門用語は英語ばっかりで、日本語は定着しないのが多かったから、頑張らないといけないのは、計算機関係の学者グループも同じかもしれない。文武両道、文系も理系もできるというのが本来の学問を目指す人の姿だとは思うが、これはまた別の機会に。