つれづれ
その167
ThinkPad X100e。ThinkPad s30 にゾッコンだったわたしにはかなり気になるノートです。ThinkPad な モバイルPC というので期待が高まってしまいます。
確かに、あまりに 変わりすぎていることに「これはThinkPad なのだろうか」と、不安も覚えます。というか不満です。でも、s30のようなコストを掛けたモバイル機の市場は既に失われていますし、10万円を切る「ThinkPad X100e」は本当に“ThinkPad”なのかを読むと、コスト制約の中でできるだけ ThinkPad であろうとしたその姿勢は良し！とも思えてきます。
しかし気になるとはいえ、去年の夏に Wind NetBook U100 を買ってしまっています。 U100には不満もないし、当分は見送りかな。でもでも、トラックポイント付きネットブックというだけで、ググッと欲しくなるのですよ。これでキータッチが素晴らしかったら ズキュンとやられてしまうかも。
あぁ、あの妙なキーボード、打ち心地はどんなものかしら。早く打ってみたいなー。
その168
お年玉、そう、お年玉。
貰う方の立場からすると、社会人にとって 3,000円とか5,000円とかははした金・・というか負担を掛けているなんて夢にも思わず無邪気に無心していたなぁ、と思い出します。しかし払う方になればこんなに辛いものなんて。3,000円でも10人寄れば3万円です。兄弟なんてもう、「甥っ子は仲間を呼んだ」みたいな。MP がガンガン削られます。
あぁぁ、予想外の出費が痛い。タダでさえ true tears Blu-ray Box で 借金してしまってるというのに...orz
その169
最近 Smalltalk を使っていない。・・・このフレーズをかくのは何回目でしょ。
先日、ちょっとした Web ツールを書きたくって、日頃使い慣れている Seaside でプログラミングすればチョチョイよ・・と書き出したら、忘れてる忘れてる・・・。慣れていると思い込んでた Seaside だけに、すっかり忘れているというのは凄いショックでした。ガガーン。
なんだか、わたしのSmalltalk力は一生こんなもんで終わってしまうような気がします。
その170
最近、xyzzyより MS Word の方が使用時間が長いわたしです。
先日、客先の担当者が変わったために、わたしのほうがよっぽどドメインエキスパート、というシチュエーションが増えてしまいました。思えば長いの、この仕事。そんなこんなで、タダでさえ減っていた仕事でコードを書く機会が、ここ最近激減です。仕事で日常的にコードをかいてないと腕が錆びちゃいそうで怖い。
正直、仕様書書いている間に動くコードが作れちゃうのになー、と思ってしまう。その動くモノをみながら、仕様を詰めていく方が上手くいくんじゃないかなと思う。
けれどこの不景気のため、「標準化」「管理をしっかりやってムダをカット」みたいな風潮が強くなった、恐ろしくガチガチなウォーターフォールになりつつあるわたしたちの開発環境 ではムリなお話。
で、この書類駆動開発の流れですが、逝くとこまで逝ってるなぁ、と思う出来事がありました。なんとついに「デバッグ中に行ったテスト」の項目まで「試験表にして」「印鑑と実行ログをつけて」納品することになってしまいました。
言い分としては、「デバッグといっても項目を考えないでテストするのは怠慢だ」「考えたなら試験表に成っているはずだ」「ちゃんとデバックできたかを検収するのは管理として当然だ」・・みたいな論理のドミノらしいけれど。
・・・ぉぃぉぃ。
（注：このほかにも納品前に結合試験は別にちゃんとやっていて、その試験表などは納品しています/さらに品証の試験もやってるよ/すげぇ）
その171
昨年の暮れは Windows で GNU Smalltalk で遊んでました。
BLOX.BWindow subclass: PetitWorkspace [ | txtAria | initialize: parent [ <category: 'private'> super initialize: parent. self createCodeText. self createPouUpMenu. self map ] createCodeText [ <category: 'private'> | container | container := BLOX BContainer new: self. container setVerticalLayout: true; defaultHeight: self height; defaultWidth: self width. txtAria := BLOX.BText new: container. txtAria stretch: true ] createPouUpMenu [ <category: 'private'> | pmenu | pmenu := BLOX.BPopupMenu new: txtAria. (BLOX.BMenuItem new: pmenu label: 'do it') callback: self message: #doIt. (BLOX.BMenuItem new: pmenu label: 'print it') callback: self message: #printIt. pmenu popup ] doIt [ <category: 'blue button menu commands'> ^Behavior evaluate: txtAria getSelection to: self ] printIt [ <category: 'blue button menu commands'> txtAria insertTextSelection: self doIt printString ] ] win := PetitWorkspace new: 'Petit Workspace'. BLOX.Blox dispatchEvents: win
こんなスクリプトファイルを作って、実行。
今は Tk のパス解決の問題で、ショートカットにスクリプトファイルを ドラッグ&ドロップ で起動する、というちょっといけてない使い方をしています。また、なぜだか CPU使用率が非常に高くなるのでちょっと常用できません。けれど、将来Windows に簡単インストールできて、ダブルクリックで実行できて、安定するなら 直ぐに Python から乗り換えたいとところ。待ち遠しいにゃ〜。
けれど、そうなったらそうなったで、他のファイルを「モジュール」として inport できないので 本当に単ファイルスクリプトだけしかダメ、というのが次のネックに感じるのかな？この贅沢ものめー。
その172
久々に Seaside を使っていて思ったのは、カスケードと 流れるようなインターフェイスって相性がいいな、ということ。
renderContentOn: html
html inputText text: 'ここにお名前を入力してください';
callback: [ :x | self inform: 'ごきげんよう、', x, '様' ]
みたいに書くとき、無名の inputText に対し、変数に束縛することなく(名付けることなく)、複数のメッセージを連続して送れるし、それが不自然でないし、なにより「連続して送っている」と文法上明らかなのは美味しすぎる。text: の戻りが yourself ならばカスケードがなくても出来るけれど、連続して送ってるぞ！という意思表明が読みやすい、と私は思う。
そういえば、Little Smalltalk はカスケードが独自な挙動で再定義されていて、
"Smalltalk-80" 7 + 5; - 8; "7 - 8" * 2 "7 * 2" "Little Smalltalk" 7 + 5; - 8; "12 - 8" * 2 "12 * 2"
と挙動が違うけれど、Little Smalltalk 方式は text: の戻り値次第で callback: 送り先が変わるため、このわかりやすさは得られない、てことになるのかな？
その173
年末はちょっと立て込んでいて、今更なのだけれど
「俺のソースだから」というプログラマは死んだらいいのに - 神様なんて信じない僕らのために
を読むと、わたしも妄想がこよなくふくらみました。
この話は考えてみたら凄い話で、喩えて言うなら「運転のしかたが解らないからクルマを自分でスクラッチしてみた」とか、「（手元にレシピがあるのに）レシピを読むのがめんどくさいと、ペリメニを何も見ないで イメージだけでなんとなく作ってしまう」とか（肉マンになってしまう・・）、そんなちょっと 世界ビックリニュースなノリの話です。・・・ってペリメニはムリがありますね orz
けれど、コの業界人ではあんまり驚かないのは、
- 自分でスクラッチするのがそれだけ簡単に思える
- 他人のコードを理解するのはそれだけ超〜〜〜〜ぉ面倒くさい
からだと思います。
が、前者は単なる錯覚、もしくは幻。スクラッチして出来るのは「クルマ」じゃなくて「クルマ風」の何かであって、ちゃんとクルマを作るのなら、それだけ手間が掛かる。それこそコードを理解する方が楽であるハズ。
プロだったらそんなことぐらい判れ、「そんなことも判らない」「Cに魂を惹かれた人々」を「だから抹殺すると宣言した」というのが Isoparametric さんで、わたしも「あれ、あたしに実感なんだ」です。
その174
けれど、組み込み屋のわたしは、全部をスクラッチしてしまえる、と思いたい気持ちもわかるというか。
アセンブリ言語で組み込みの開発していたときは なにもかも自前スクラッチだったし、Cでのプログラミングはその雰囲気が良く残っていたと思います。そして C++ にもそんな「全部出来てしまう」と思えてしまう雰囲気がギリギリあると感じます。
例えばコンテナやStringが 言語のシンタックスで特別扱いされたりし出すと、一般の開発者と 言語や標準ライブラリを作り人達の間に、それが壁として ドーンと立ちはだかって、そうして「ここから先はブラックボックス」と尻込みできるようになる。けれど、C++ は 反対に言語と標準ライブラリの間に距離感があるから、アイツ(って誰だ?)が出来るんなら自分でも出来るんじゃないかと、イケイケGoGoな気分になれる。――それがいいことか悪いことかは別にして。
C++の場合、「わたしにも（現実的なコストで）できそう」はほぼ錯覚なのだけれど、C++ の「錯覚が多いよね」がある意味有害な現状が、全てが手に負える、ブラックボックス境界（自作の地平線）のない、フラットでコンパクトなシステムの存在の可能性や価値を否定するものでもないと思うし、C++ であっても魅力であると思います。
その175
他人のコードって読みにくいね、と思います。何でこんなに大変なんだろう。読むくらいなら自分でいっそ作り直してしまった方が早い・・と思ってしまう気持ちはわかります。
他人のコードが読みにくいから、ドキュメントを整備することが推奨されちゃう。つまり誰かがコードを理解して、それをもとにドキュメントを作れば、みんなが楽を出来る、という現実があって。
Python の魅力に良く整備されたマニュアルがあるけれど、Python のユーザー層でもそれが魅力に思えるくらい 強がったってコードは読みにくいです。理解しやすさは ドキュメント > コード または ドキュメント > プログラム。
再発明厨さん達が後から後から沸いてしまうのは、ここらへんが諸悪の根源。悪いモノは元から絶たなきゃだけれど、他人のコードがどうしても読みにくい（理解に手間が掛かる）のは、本質的なモノかもしれない。
数式が一部の人間しか解りやすいと感じないのと同様、コードも「フツーの人は読みにくいよね」となるし、そのフツーの人には職業プログラマのボリュームゾーンでもあります。それそのモノは、飲み込みやすい別のモノには永遠に勝てないというか。そうであったら、厄介な。
その176
昨年わたしは、ある機器のリファレンスドライバを書く仕事をしました。と言っても、主に社内の別の部署部署が使うもので、たいしたものではないのです。
実際に使うドライバと、プログラマが機器の理解のために参考に読む為のドライバじゃ、やっぱりコードの書き方が違います。規模と複雑さを押さえることが機能よりも優先される。その場だけみれば全てが解るように書くのが優先される。だから異常系はヘナチョコですし、拡張性は必要に足りてないですし、マジックナンバーだって使っちゃいます。それは使うには良いコードではないけれど、かわりに「わかりやすい」と言われます。わかりやすいってなんでしょうね。
「ドキュメントとしてのコード」は、まだまだ 実際に使うコードと一致しにくいということかしら。
ただ、そういうコードなら「ドキュメントよりコードのほうが解りやすいって」言って貰えます。先の再発明厨さんたちだって、ゼロから再発明するでなくサンプルコードを踏み台にすることのほうが多い。だから「元を経つ」にはこの程度の読みやすさで十分かもなのだけれど。
うーん、このわかりやすさを実コードでも提供できればいいなぁ。抽象化技法はその為のものですが、今一歩及ばない。（わたしが無知ってだけかもしれない）
余談ですが、こう勘違いされたらどうしようとか、こう使われたらバグっちゃうとか、いろいろ考えると、神経がつかれるというか、大変でした。これで本当に社外に出て行くサンプルコードとか、オマケに紙面まで限られる技術書のコードとか。作ってる人は大変だなぁと改めて実感。
その177
こんな偉そうなことを書いておいてなんですが、わたしは他人様のコードをあんまり読みません。だって面倒くさいです。(ぉ
たとえば boostのコードとか読むとき、結構気合いをいれて「よし、よむぞーっ！」と勢いをつけないと、なかなか取っつけません。少なくとも「ちょっと使い方が解らない」程度では、コードを読むよりまずGoogle先生に相談です。あぁ、へたれだわ。
そんなわたしですが、Smalltalk はちょっと別で、「使い方が解らない」程度でコードをチョコチョコ読んでしまう。そんなくらいに Smalltalk でのコード読みの敷居が低いと感じます。
* * *
Smalltalk は「子供でも十分理解できて、その子供が大人になっても使える本格さも併せ持つ」ことを目標につくられたシステムで、もしかしたら先のサンプルドライバの話の理想を地で追うシステムといえるかな？「コードがドキュメントだ」を追求してるシステムでもあります。だから かなり読みやすい。（おかげでドキュメントが全然整備されない...orz）
Smalltalk のコードの読みやすさには
- コードが、良くドキュメントとして整備され、その閲覧環境もリッチであること
- 動いているプログラム（オブジェクト）を動かしたままで自在にこねくり回せること
の二つの軸があると思います。
前者は、例えば、クラスカテゴリやメソッドカテゴリで整理されたコード。「テキストファイル」というコードのインスタンスを持たない Smalltalk だから、プログラムの抽象化要素と同じ粒度にコードが分割されていて、捜しやすい。それを「システムブラウザ」というできの良いドキュメントビュワーでサクサク読めてしまう。
また、書かれたコード自体もドキュメントとして親切で、例えば Smalltalk にはクラスメソッドとして Example を用意する文化があります。他にも実際には最適化のため動かないものについても、コードが用意されてたり。実際のアプリケーションとしては意味のないコードが、人に読ませるためだけに存在するのが普通です。
後者は、動いているプログラムそのものに際限なくアクセスできることの強み。デバッグモードとかじゃなくって、完成品の運用中のプログラムで、です。
喩えるならば、今あなたがこのblogを読んでいるWebブラウザ、そのタブってどういう仕組みなのかな？――と思ったら、今まさにそこにあるタブオブジェクトのフィールドもコードも直ぐに覗けてしまう。覗くだけでなくフィールドを変更することも、コードを変更することも、実行しているままで出来てしまう、そんな仕組み。
動いているモノを直接動かしたまま分解出来るというのは、現実世界のモノを理解するときそれが強力なのと同様に、プログラムの理解にだって早道です。
「動いてるプログラム」と 「動かないドキュメント」のうち、ドキュメントのほうが楽にプログラムを理解できるというのは、「コード＝動いているプログラムそのもの」じゃなくって、コードとプログラムそのものの間にちょっと距離が離れてしまっているからです。
だからコードを読む頭の中でプログラムの姿を再現しなくてはいけなくなると言うか。そういう余分なステップや脳力が必要になるのが面倒くさく感じるというか、歯車そのものと、歯車の図面の違いというか。そういうのがなければ、シンプルに、プログラムを直接弄くり回したほうが理解しやすいハズ。
とはいえコードの実際はやっぱり設計図で、Smalltalk にあるのは、コードを設計図に見せない、そのものに見せてしまうシステム、なのだけれど。ツールが上手くマッピングしてくれるのですね。
そんな素敵な Smalltalkだけれど、まだ十分ではないのは現実です。規模の悩みとも無縁じゃないし、もっとコンパクトでなければ、と言われることもあり。なにより Smalltalk は主流になれなかったから、ナンデモ分解理解できる理想郷は、箱庭になってしまっているのが、悲しいところ。
* * *
もちろんSmalltalk のは一つのアプローチでしかないと思うし（文芸的プログラミングとか）、統合開発環境の進歩だとか、強力な抽象化技法だとか、どんどんコードは読みやすくなっていくのだと思います。Isoparametric さんのエントリーみたいな話が、ギャグにしか見えなくなるくらい、コードを読むのが簡単になればいいな、と思いました。
その178
以上、連想妄想終了。
その179
フィルムスキャナを手に取るまでは、単なる情報の読み取りという風に捉えていて、「フィルムを先込むと自動でビーッと全コマ読み込んでくれる便利な機械」くらいの認識でした。けれど実際は大きく違って、まず、一コマってどの範囲？という認識からして人の手を煩わせます。
それはそうです、考えてみればロールフィルムに適当な四角で適当な位置に露光してあるだけで、基準も位置合わせの原点もない、画像の見た目だけがキモの世界なのですから。露光不足のコマとかあると人間にだってお手上げ。
そしてそのコマ自体ののスキャンにも手間が掛かります。フィルムの持っている全情報を取り込める訳じゃないので、露出を合わせなくてはいけません（自動露出はあるけれどね）。
この手間って、印画紙に焼くのとあんまり変わらないじゃん。とすればこれは 一種の引き延ばし機なのだなぁ、と思うようになりました。スキャンは単なるデータ化ではなく、絵造りの一環なのだ。
そうなると、良いフィルムスキャナというものに俄然興味が沸いてきます。引き延ばし機はカメラと同じくらいに写真の命です。・・ですが、フィルムスキャナはフィルムカメラ以上に絶滅危惧種となってしまっていて、しかもフィルムカメラのような熟成技術ではなく、発展途上技術です。
これはちょっと頂けぬ。むー、なんとかならないかなぁ。
その180
フィルムスキャナ、国内メーカでは もう Nikon しか作っていません。その Nikon も新製品をもう開発していないでしょうから、あとは頼りになりそうなのは台湾の plustek 社だけかな？と思います。
OpticFilm シリーズは、Nikon の SUPER COOLSCAN V ED と同じ価格帯。2009年11月に国内発売になった新型の 7400 で光源がそれまでの冷陰極管から LED になったり。フィルムを手で動かす仕組みになっていること以外はCOOLSCAN Vとだいたい同じような感じかな？（7300の後継が7400。現行の最上位機7500の後継は7600で、こちらはまだ日本では売っていない）
Plustek Film Scanner - OpticFilm 7600i Ai
一方の Smart Photo F50 は 12,000円の 簡易スキャナで、YASHICAブランドで売っているのと同じ位置づけっぽいけれど、モノは違うし、なによりデザインがカッコイイ。
Plustek Film Scanner - SmartPhoto F50
（こちらのblogの写真が凄くカッコイイ）
普通のフィルムスキャナが引き延ばし機ならば、こちらはライトボックスだと思えばよいかしら。
一応レビューを捜したのだけれど、イマイチよくわかりませんでした。
http://journal.mycom.co.jp/news/2009/12/09/042/index.html
今は わたしの SUPER COOLSCAN V は元気ですが、彼女が逝ったときの参考用に、人柱希望です。
その181
http://www.nikkeibp.co.jp/article/column/20091221/202102/
こうした技術製品が現在のように複雑なものとなっている理由を、私は少なくとも3つ挙げることができる。第一に、技術を開発するのが普通の人々ではなく、技術者であるということ。短絡的で職業分類に偏った見解かもしれないが、マニアたちは複雑さを好む。（中略）彼らにとっては、余分な機能の使い方を学んだり、分かりにくいユーザーインターフェースをマスターしたりすることが喜びなのである（なんとも悲しい幻想のなのだが、ツールを使いこなす自分たちの高等な技術をかっこよく思ってもらいたいと彼らは望むものなのだ）。
これを読んだとき、反射的に「ばっかじゃないの」と思いました。「技術者の感性が歪んでいるのが問題だ」なんて、なんて幼稚な。
感性以前に、製品仕様を決めるのは技術者じゃない事が多いですので、世の中の製品が複雑である理由としては、ちょっとこじつけかな？、と思いますし、技術者の感性についても、わたしの意見はおおむね
現場の技術者からすると、全く反対の意見だ。
技術者は、マニアであればあるほどシンプルで特定の機能に特化した製品がかっこいいと思い、できればそのような製品を作りたいと思う。
しかし、開発費を出す人やマーケティングと呼ばれる人は、特定の機能に特化した製品は、売れる場所が限られてきてしまい売りにくいので、好まない。
従って、このような人たちの意見を幅広く取り入れた結果、多機能すぎて肥大化した製品が完成する。
のコメントと同じです。
なんてったって仕事です。自分の欲しいモノ なんて滅多に作ることはできません。もし世の技術者にそんな力があったなら、ポピュラーな好みであり夢である 「PDF だけ読めれば十分な シンプルなタブレットが欲しい」は、とっくに実現しているハズ。あぁぁ、CrunchPad..orz
その182
さっきの記事。反射的には「ばっかじゃないの」と思ったものの、すこし経って Emacs を思い浮かべてしまったら、技術者の感性を疑われるのもムリはないなぁと思い直しました。
Emacs はある意味シンプルだと思うのですが、これをシンプルといったら「頭おかしいのとちゃう？」と言われてしまいます。
技術屋さんが自分で自分のために作るツールは「ムチャクチャシンプルで、かつ、、ムチャクチャ取っつきにくいことが多い」かな。これを「シンプル」とみるか「複雑」と見るかは、その人の立ち位置の問題だよなー。
それにお客さんと話していると、UI や目に見える手続きが複雑であるのと、そのドメインモデルが複雑なのとを、区別を付けて貰うのは難しいなぁと、思いました。
その183
去年の秋頃、父様のつかっている LANケーブルの 爪が折れてしまったらしく、「使ってないケーブル持ってないか？」と聞かれたので、「それくらいなら頭付け替えればそのまま使えるよ」と、サクッと RJ-45コネクタを付け替えてあげたのですが、「始めてプロっぽいところを見た」と言われたとき、なんとも複雑な気分でした。
うーん、いままでも各種設定とかトラブルシューティングとかやって上げているし、そっちのほうがよっぽど 本来の仕事に近い内容なのだけれどなー。
技術者というと、やっぱり工作めいたことを手際よくする姿 をみせないと、プロっぽく見えないのかしら。むー。
その184
フジフイルムの高級フィルムコンパクトカメラ「クラッセ」が安い。38mm F2.8 のクラッセS で 実売 38.000円くらい。普通のフィルムコンパクトである ナチュラクラシカ と 5,000円くらいしか変わらないというのは、安く感じます。
クラッセは写りは本当に抜群で、ちょっと欲しい。けれど、デザインもイマイチですし、チョイ大きいし、実は写りを別にすれば ナチュラクラシカの方が格好良くて欲しかったり。いあ、でも、買いだなぁ。買いたいなぁ。
その185
わたし、こんなふうに物欲まみれで、我ながら浪費家なのだけれど、それでも買えずに我慢しているものはかなり多いです。それはみんな同じで、友人をみてても、blog とか巡ってても「欲しいけれど、買えない」は良く目にする気がするのですよね。
もちろん 目に付くものだけで判断するのは意味がないけれど、それでも、うーん、最近の若い子が嫌消費ってホントかなって思います。（←おまえは若くない、ってツッコミは禁止）
その186
ひだまりスケッチ×☆☆☆ （って、表記でよいのかな？）、本編は良く動くし面白かったのですが、オープニングとエンディングが全然動かない・・というか、落ちてしまったかのようなのは、なんだったのかなぁ。シャフトだし、本当に間に合わなかったのかと思われてしまいます。
ひだまりのOP は動くというイメージがあっただけに、「アレ？」と思ってしまいました。
その187
言葉は「意味」と、それとは別に「イメージ（印象）」を持ちます。言葉の持つイメージに着目して用語を作り出すのはマーケティングとして有効です。けれどそれは buzzword 化を招き、議論を阻害する困ったちゃん。だから技術者だって科学者だって、言葉の意味を大事にします。
「コミックサイエンス」は「似非科学」の類義語らしいけれど、「コミック」に、「子供だましの」「もっともらしい」「嘘の」という意味はありませんし、コミックの事実とも異なります。
「コミックサイエンス」はイメージ語です。
事実とは異なる、いわゆる言葉のイメージをもって、自陣の説得力を増そうとする構図は、まったくもって「ゲーム脳」と同じ。ここまでそっくりさんをやられると、こんなときどんな顔をしたらいいか解らない。
注目すべきはこれは「ミイラ取りがミイラになった」訳ではないということ。
この名前に問題を感じずに団体名にしてしまった時点で、お里が知れたと思います。彼らは「マイナスイオン」などの（科学っぽい、という印象を利用した）マーケティング名称を、企業が受け入れたのと同じ倫理観を持って行動しているんだぞ、と自ら公言してるのです。そこに科学者としての矜持はありません。
つまるところ、彼らは「科学」なんてちっとも大事にしていない。彼らはもともと、彼らが撲滅しようとしている輩と同じ穴の狢で、「似非」サイドの住人です。
