墜落日記 - 2008年7月の墜落
2008年7月30日
WZ Editor 6.0 プレビュー
自分が拘りの元に使い続けているソフトウェアの１つに、WZ Editor というテキストエディタがある。
フリーではない。
シェアウェアでもないし、オープンソースでもない、一般的とは言い難いが一般のプロプライエタリなパッケージである。
もちろん有料で、1 万円近くする。
これはテキストエディタに変に拘っていない人からすればエライ高価である。
んが、自分には WZ Editor は金払う価値があるエディタなのである。
その WZ Editor、5 年ぶりに新バージョン 6.0 のプレビュー版が公開された。
ま～正直言って WZ Editor は初物に手を出すと手痛いダメージを喰らうことが多いし、今の所 5.0 で充分なので勢い勇んで乗り換えることはないが、最近 WZ Editor の更新が無くて不安になっていたトコロに新バージョン公開の報は僥倖である。
(いや、最悪マジで俺的俺発俺様なテキストエディタ作らないとダメかと思っていたところだった………簡単な話ではないのだけど)
で、その WZ Editor 6.0 であるが………
次期バージョン 6.0 は、かつて 3.0 から 4.0 にバージョンアップした時のような抜本的な作り直しを敢行した模様だ。
画面のインターフェイスは最近流行の TDI (Tabbed Document Interface) に変更された。
全体的にインターフェイスが Windows 標準に完全に背を向けている。
というか、この背の向け方はかなり独善的だ(汗々)
ちと古めの X Window の様な一皮被った感じで、マクロから色々と制御するために一通り実装したのかもしれないけど、これはまたエラク利用者を選ぶ背の向け方かと思われ。
これが「全部WZ」という新機能の威力か？
(ま、WZ 自体が利用者を選ぶエディタなので、その際どうでもいいのかもしれないけど)
新機能もいくつかは「なんだかな～」と思われるモノがある。
マルチタブと多重化の組み合わせは慣れると面白いかもしれないけど、ヘルプまでタブの中に入るのはお節介かも。
世代履歴も別にテキストエディタがやらんでも SVN にでもやらせればよいし………
(SVN ならローカル保存している分だけでなくあっちゃこっちゃで編集した分も世代履歴が当然同期されるわけだし)
で、重要なマクロに関しては 4.0 から 5.0 へバージョンアップした時のような、互換性の維持は全く考慮されていない。
従来の TX-C から Text-C へ変更され、仕様自体だけ見ればなかなかに面白そうだが、その仕様は完全に書き直されたため、従来の HTMLCMD や拙作 HTML Plus! は利用できない。
一応 htmlex などの主要なマクロの機能は標準で取り込んだとしているが、4.0 標準程度の結構貧弱なものであるし (HTMLCMD 並みではない)、なんかタグを大文字で記述するとうまく動かん(爆)
内部的には HTML として処理せずに XHTML として処理している節が見受けられる。
HTML Plus! の様なテンプレート入力機能も微妙にあるが、正直使いにくいし挙動不審だ。
(この辺りは HTML Plus! が完全に自分の好みで作られている部分にも由来する)
う～ん、面白そうではあるのだけど、3.0 から 4.0 へ移行した時のような産みの苦しみを味わうことになるかもしれない。
と言うか、そもそも HTML Plus! は 3.0 から 4.0 へ移行するために作ったのだし、下手すると今回は HTMLCMD の範囲も含めたマクロを完全に書き直さないとダメかも………？
ざっと見てみただけだけど、なんか手広くやろうとしすぎてイマイチ誰をターゲットにしているのか分からない節がみられ。
それに最近 VillageCenter を訪れていないが、4.0 が出た当時のような活気のあるコミュニティの場を VillageCenter 自体がフォローしているようにも見受けられず。
ただでさえマクロの互換性もなくなってしまって完全に作り直しの勢いなのに情報の集約も出来ない状態にある様だ。
(それとも俺が知らないだけでどっかに Wiki が出来ていたり 2ch にスレが立っていたりする？ 2ch だったら俺は寄りつかんぞ、マジで)
面白そうなんだけど、ホントに面白そうなんだけど、でもな～………
今はなかなか WZ Editor 4.0 に HTML Plus! を作った時のような余裕は………(汗々)
2008年7月29日
MX Revolution を買うた
お気に入りの Logicool MX-1000 がラインナップから消えて久しい今日このごろ。
買い溜めしておけばよかったと本気で後悔していたのだが、とうとう自宅の MX-1000 が逝ってしまった。
というか MX-1000 はホント個体差ありすぎである。
自宅の MX-1000 は中ボタンと左ボタンの接触不良が発生した。
中ボタンは全く効かなくなってしまったし、左ボタンはシングルクリックがダブルクリックになってしまって不慮の事故が多発する………
職場で使っている MX-1000 は充電器との接触が劣悪………
自宅と職場で合計 4 台の MX-1000 を使ったが、どれも上記の症状が起きたり起きなかったりで、品質が一定しない。
この品質の不均一さは絶対に中華だと思いつつ………
（いや、実際には設計の問題だろう）
で、この度自宅の MX-1000 が我慢の限界を超えた。
仕事帰りに秋葉原のヨドバシに出陣し、色々とマウスを見て回る。
最新型の MX Revolution は実は自分的にはイケてなさそうだったので、最初は無視の方向だったのだが………
Microsoft は何故かハードウェアはなかなかに良い物を出すので Microsoft マウスを物色してみたが、あの大きさはどう考えても無駄に大きい物が好きなアメリカン仕様である。
自分の手は決して小さい方ではないと思うが、Microsoft のマウスは全く手に余る大きさ、デカけりゃいいってモノではない。
ユーザインターフェイスには個人的な拘りがあるので、その他の一般的なメーカのマウスは申し訳ないが最初から眼中にない。
で、結局 Logicool に戻ってしまった。
MX-1000 にまだ大きさが近い MX-620 と迷ったのだが、MX Revolution とはまた違った違和感があったのと、充電式ではない不安感があった（不安だけで実は実用上問題になるほど短くはない）。
で、結局店頭で SetPoint ソフトウェアの MX Revolution への対応度合いを確認し、当初自分が困った部分に関して対応されているのを確認してから MX Revolution へ落ち着いた。
MX-1000 を長年愛用していたので MX Revolution の妙なコンパクトさにはやはり違和感バリバリだが、キーボードと違って妥協のない別の選択肢が見あたらない以上、体の方を慣らしていくしかあるまい。
これで約 4 年間連れ添った MX-1000 と別れを告げた。
まだ職場では MX-1000 が現役だが、MX Revolution に早くなれるためには容赦なく職場も MX Revolution に置き換えてしまった方が良いかもしれない。
（キーボードは両方とも FKB108M/JB に変えてしまった。さらば iK-37）
2008年7月28日
フォルダ管理 VS タグ管理………何故 "VS"？
唐突だが（いや、そんなに唐突でもないか、時々同じテーマで墜落してるし）、フォルダ管理とタグ管理って相容れない物なのだろうか？
ぶっちゃけて言うと、旧来のフォルダ管理している MP3 ファイルを Winamp なんかで再帰検索したりして再生するスタイルと、iTunes なんかでタグ管理して再生するスタイルは、本当に相容れない物なのだろうか？
自分は基本的に iTunes が嫌いだ。
本格的に嫌いだ。
何故嫌いかというと、自分の今までの管理スタイルを完全に捨て去ることを強要されるからである。
今までフォルダ管理で MP3 を管理していてドコに何があるか分かっていて、再帰検索では要求が満たせない場合（フォルダを横断したい時だ）だけプレイリストを作成するスタイルで運用している。
しかし iTunes ではタグ管理によるフラットなリストからの検索を強要される。
フォルダ管理は全否定されている。
だから、自動的に iPod も嫌いだ。
iTunes 型の管理を強要されるからだ。
だから今使っているのは TOSHIBA gigabeat X60、Linux OS 搭載でフォルダ管理が出来る（WMP が必要ない）最後のバージョンだ。
gigabeat X60 はプレイリストの管理がエライ面倒くさいという弱点はあるが、それでも今までのフォルダ管理を捨てなくて済む。
しかし gigabeat X60 が壊れたら絶望だ。
で、こういう事を論じると決まって「フォルダ管理しか知らないタグ管理が出来ない馬鹿」と息巻いてくる奴が居る。
やれスマートプレイリストが便利だのなんだのと御託を並べてくる。
そいつ等に言わせると、フォルダ管理に拘るのは頭が悪いのだそうだ。
俺みたいなのはタグ管理が出来ない馬鹿らしいのだ。
それこそ巨大なお世話である。
と言うか俺から見ればタグ管理なんて、ドコに何があるか把握できない、分類することが基本中の基本である情報整理が出来ない能無しの言い訳だ(嘲笑)
と、こちらも売り言葉に買い言葉をやると建設的な話が出来ないから止めておくが(爆)
自分はスマートプレイリストが使えないとかタグ管理が出来ないと言っているわけではない。
既に 4,000 曲以上ある MP3 に今更タグ付けしていくのは面倒くさいが、スマートプレイリストが必要ならば使おう、タグ管理が自分にとって本当に価値があるのなら使おう。
しかしそれは新たな手段の１つに過ぎず、従来からの手段を完全に置き換える物ではないし、ましてや置き換えなければならない物では断じてない。
だが、iTunes に限らず最近のインターフェイスはプレイリストやスマートプレイリスト、タグ管理での管理以外を許容しない。
自分が許せないのはまさにソコなのである。
そもそもである。
なんでフォルダ管理とタグ管理を全く別に考えないといけないのだ？
例えば Windows では Windows 95 からディレクトリと言わずにフォルダと言うようになった。
これは何故だ？ フォルダとは仮想的な存在だからだ。
ディレクトリは物理的な存在だが、フォルダは仮想的な存在だ。
考えてもみろ、「マイコンピュータ」や「マイネットワーク」、「コントロールパネル」なんてディレクトリが存在するか？ しないだろう？
ならばスマートプレイリストを仮想的なフォルダとして実装して、従来型インターフェイスと同居させる工夫が出来る筈だ。
なのにフォルダ管理とタグ管理が相容れない存在であるが如きインターフェイスが闊歩し、タグ管理を有り難がっている連中はフォルダ管理とタグ管理が相容れない存在であると無意識に思い込んで御託を並べる。
もう一度言う。
なんでフォルダ管理とタグ管理を全く別に考えないといけないのだ？
タグ管理したい奴にはタグ管理させろ。
フォルダ管理したい奴にはフォルダ管理させろ。
両方使いたい奴には両方使わせろ。
ただそれだけ、自分が望んでいるのはただそれだけのインターフェイスだ。
ちなみに、PC 上でそういう管理をする MP3 プレーヤなら作れると思うんだが、携帯デジタルオーディオプレーヤと組み合わせようとか考えると途端に躓くよな～とか思ってみる。
そもそもフォルダ管理を可能にしている大容量ハードディスク搭載の携帯デジタルオーディオプレーヤってラインナップに残ってるんだろうか？
DRM なんか要らない、というかむしろ邪魔。
USB でマスストレージ接続が出来て簡単に MP3 と M3U プレイリストの転送が出来ればよい。
スマートプレイリストは転送時に検索結果を固定的な M3U プレイリストにして送ってやればよい。
でも、TOSHIBA 辺りが作らなくなったら国内ではもうダメって気もする………
全く面倒くさい状況になったものだ………
2008年7月27日
低解像度に優しくない表記変更
最近方々で話題になっている、Microsoft のカタカナ表記の変更の話題。
今までは Microsoft のカタカナ表記は 3 音以上の場合に語尾に長音符を付けない JISZ8301 に原則に従っていた。
だから "assembler" は「アセンブラ」だし、"folder" は「フォルダ」だし、"browser" は「ブラウザ」だ。
これが今後は国語審議会の報告に基づく内閣告示第二号（1991年6月28日）に従い、"-er"、"-or"、"-ar" で終わるカタカナ語は語尾に長音符を付けることになった。
前記の例だと、
"assembler" は「アセンブラー」となり、"folder" は「フォルダー」となり、"browser" は「ブラウザー」となる。
ただ一部慣例に基づき変更しないカタカナ表記があり、"compiler" は「コンパイラ」のままだそうだ。
"assembler" は「アセンブラー」になるのに、"compiler" は「コンパイラ」のままっちゅ～のは一体どんな慣例なのか首根っこ引っ掴んで小一時間くらい問い詰めてみたいと思うのはさておき。
元々 JISZ8301 に従っていたのは様々な理由があろう。
根本的に工業製品が JIS の範疇というのもあるだろうし、昔の小容量、低解像度では省ける物は省いて簡素化する JISZ8301 の仕様は好ましかったはずだ。
これが近年の大容量化、高解像度化と、日頃目にする表記と Microsoft が使う表記の間にブレが出始めていることによって、今回の変更となったわけだが………
個人的には、余計なコトするなボケ、と思うわけである。
高解像度になったって言ったってモバイルノートなんかの低解像度（自分は横幅 1280 以下は低解像度と認識する）で必要ない長音符を付けられたら幅を無駄に喰ってしまって、一度に見渡せる情報量が減ってしまう。
それに自分は元々機械工学出の機械屋なので（誰か信じろ）、JISZ8301 の方がしっくり来る。
ま～それだけコンピュータが一般化したという証拠なのだろうが………しかし、これは………(汗々)
話変わって。
なんか北京オリンピックが近くなって色々と大変なことになっている。
テロは起こるわ、暴動は止まらないわ、ここは戦時共産主義真っ最中の最前線かというほどの厳戒態勢はとられるわ、ホントこのままだと無事に迎えられるのかどうかと言う原始的な部分で問題が顕在化したと言える。
あんな危険な状態では選手が事前に入国して調整することもままならない。
もはやこれは大前提が揺らいでいるわけである。
どういう大前提かというと、今更になって殊更にかき立てることではないが、
「中国はオリンピックを開催するに値する国家か否か」
という部分であり、大凡の大多数の人々と世界は、中国はオリンピックを開催するに値する国家ではないと思っている―――それを公言するか否かはともかくとして。
大体、記者ら外国人向けに「指南書」など作っている国がオリンピック開催国に値するわけがない。
そもそもオリンピックを中国で開催するということ自体が判断ミスだったと言え、IOC にいったいどれだけの金が流れ込んだのかと疑わざるを得なくなるわけである。
まともな判断能力を持った近代社会に生きる常識人であれば、あんなナチ国家でオリンピックを開催すること自体を選択しなかった筈だ。
ナチ国家でオリンピックを開催という前例はまさに第11回夏季オリンピック―――ベルリンオリンピックだが、これは「ハイル・ヒトラー！！」唱和の中でアドルフ・ヒトラーが開会を宣言した大会であり、ナチスによるプロパガンダである。
アドルフ・ヒトラーはベルリンオリンピックを利用して国民の愛国心を昇華させたあげく、その 3 年後にポーランドに侵攻して第二次世界大戦を勃発させた。
このドイツ第三帝国のベルリンオリンピック前後での動向を見ると、ヒトラー政権を胡錦涛政権に、ナチス党を中国共産党に、そしてベルリンオリンピックを北京オリンピックに置き換えただけで見事なまでの類似性が伺える。
つまり北京オリンピックは成功しようが失敗しようが、世界にとっては遺恨を残しかねない危険なオリンピックとなりかねないということである。
もう中国でオリンピックを開催するなんて無謀自体が、とてもドイツ第三帝国やハーケンクロイツ、ホロコーストをタブー視している人間の発想ではないのである。
しかし決めてしまったものは仕方ない。
やってしまうのであれば取り敢えず表面上は成功するようにナントカ頑張って、北京オリンピック成功後の中国の動向を監視しつつ暴走を食い止め、第三次世界大戦―――それが実際に戦火を交える戦争か、世界経済を崩壊させる経済戦争かはともかく―――が起こらないようにするしかないのかもしれない。
成功してすら遺恨を残すオリンピック、悲しい限りだと思わないか？
オリンピックの話題からは逸れるが、中国にしろ、ロシアにしろ、一度「一国社会主義」を通った国は民主化されている国と合併するような外圧も含めての改革―――東西ドイツの合併のような改革―――をしない限り正常化は無理である、と個人的には考えている。
現実的にロシアは帝政に戻っているし、中国の軍事力は本気で第三次世界大戦を起こすつもりかと疑わざるを得ないものだ。
しかも両国とも国内に実に様々な歪みを抱えており、いつ国民の目を国内問題から遠ざけるために国外に敵を求める本末転倒な事態に陥るか分かったものではない―――というか既にテロという仮想的を作って国民を欺いている。
世界はいい加減に中国、ロシアの暴走を食い止める手段を模索すべきである。
大体こんな馬鹿げた国が常任理事国に居座っていること自体が重大な世界平和に対する冒涜である。
このままだと第三次世界大戦は笑い話でなくなってしまう、と自分は危惧する。
2008年7月19日
メタボ検診
５月末くらい、朝方の極端な膨満感でのたうってからビクビクしつつ１ヶ月を過ごし、同じ症状が頻発するようになってしまって病院に行った自分。
エコー検査で唐突に胆嚢結石が見付かったのが 7/8 で、結石の先がエコー検査では見えないからと CT 検査で輪切りになったのが昨日。
ついでに血液検査の結果も貰ってきた。
結論から言うと、今回の色々な検査は結果としてメタボ検診となってしまった。
要は「太ってる、やせろ」ということである。
胃と腸の間に炎症が見付かったが、細胞を採取しての検査の末、単純な胃炎で悪性ではないとの結論が出た。
胆嚢結石は「うひょ～………」と思うくらい見付かってしまったが、素人考えで症状を調べていた胆嚢結石症ではないとの結論。
胆嚢結石自体は爆弾として保持していることが分かってしまったが、今回の症状には直接の関係はないらしい。
で、結局のところ問題となっていたのは食道裂孔ヘルニアらしい。
食道と胃の間、横隔膜をぶち抜いている部分の食道裂孔が弛んで、胃が胸部側にせり出している状態だ。
先天性の場合もあるようだが、自分の場合は太りすぎで腹圧が上昇して軽い食道裂孔ヘルニアを誘発したらしい。
食道裂孔ヘルニアの症状としては(1)むねやけ、(2)胸痛、(3)つかえ感が見られ、強く自覚するのは夜間就眠時（特に明け方）ということだ。
あ～、言われてみればまさにその通りの症状である………
血液検査の結果は自分が思っていた以上に正常値だったが、唯一尿酸値がやや高いという部分が見付かった。
ま～この辺りは年に一度の健康診断で分かってはいたのだが、取り敢えず万一のためにプリン体を控えることにする。
と言っても自分は日頃からプリン体を多く含む物を食する習慣はないので、意識して減らすにも限度がある。
だから尿酸を尿として排出するために、主としてやせる必要があることになった。
とどのつまりは日頃の不摂生が祟ったということである。
と言うわけで、今回の検査はメタボ検診の様相を呈してしまったわけだ。
う～ん………胆嚢結石も見付かってしまったことだし、不摂生な生活の改善作業から始めないと………(涙)
2008年7月13日
次のDD、MDD
ホームタウンドルパ大阪５で限定販売されるドルフィードリームとミニドルフィードリームの情報が出揃ったようだ。
今回のミニドルフィードリームは斬魔大聖デモンベインから魔導書アル・アジフの化身アル・アジフ、同じく魔導書ナコト写本の化身エセルドレーダ。
ドルフィードリームは新世紀エヴァンゲリオンより綾波レイ メイドドレスVer.と、惣流・アスカ・ラングレー メイドドレスVer.となる。
ま～なんちゅ～か、新世紀エヴァンゲリオンはかつて綾波レイだけＤＤ化していたけど、正直アレは結構お粗末と言うか、そんな感じだったし。
手に入れられなかった人や新世紀エヴァンゲリオンというだけで飛びつくフリークには良いかもしれないが、自分的にはイマイチ琴線に触れないしメイドドレスも全然欲しいと思わないのでスルー確定。
斬魔大聖デモンベインの方は、いくら何でも両方ともＭＤＤにするのは如何な物かと思うが………
たしかにアル・アジフもエセルドレーダも幼い外見はしていたけど、ＭＤＤほど頭身の狂ったキャラデザではなかったわけだし、あそこまで巨頭だと逆に違和感が………
いっそオビツの MIZUKI で頭だけ載せ替えるとかがスケール的には丁度良いかもとか思ってしまう自分が居る。
ま～逝くとしたら多分エセルドレーダかな？
自分的には今回で一番良さげなのはエセルドレーダだと思う。
ただ、妙にアイが深い位置にあるから、アイホールを裏側から削ってやらないと違和感バリバリなんだけどな(汗)
なんにしろボーナスも減ったしで経済的にきついので、逝くか逝かないかは不透明なわけだが………
そう言えば、「エセルドレーダ」って名前の響きは結構好きなんだよな～とか思ってみる。
元ネタは、大魔術師アレイスター・クロウリーが何匹も飼っていたブラッドハウンドの一頭である「レディ・エセルドレーダ」から来ているわけだが。
自分的にもこの名前はいつか何処かで使ってやろうと思っていたり(爆)
2008年7月8日
ドブネズミ共が手を組んだ
ドブネズミ共が手を組んだ。
言うまでもない。
ドブネズミ共とは Microsoft とアイカーンだ。
Microsoft は頼まれもしない Yahoo! 買収を持ちかけて（人それを敵対的買収という）、一端は引き下がった。
しかし今度は企業乗っ取り屋（要は金融ヤクザの一種だ）のアイカーンと手を組んで、Yahoo! の検索事業だけを買収しようとしている。
しかも Yahoo! 取締役会のクーデターによって手に入れようとする、どこからどう見てもヤクザの論理によって、だ。
Microsoft にとって Yahoo! の全社買収は損だ。
検索事業だけを手に入れれば Yahoo! をガタガタに出来るばかりか、最大の競争相手である Google と Yahoo! の提携ですら意味のない物に出来る。
だから、Microsoft とアイカーンは手に手を取って Yahoo! の解体に乗り出した。
Yahoo! 取締役会が言うように、アイカーンには Yahoo! の企業価値を高めるプランなど無いだろう。
アイカーンは Yahoo! を切り売りしてその過程で利益を得たいだけで Yahoo! の企業価値を向上させる必要はない―――尻馬に乗りたい投資家連中が Yahoo! の株価をつり上げるその最大瞬間風速だけでいいのだ。
だからそんな物は最初から持ち合わせていない―――金融ヤクザとは元々そう言う物だ。
このことからもアイカーンという金融ヤクザは長期的な企業価値の向上や既存株主の利益よりも個人の資産を増やすことにのみ興味があるドブネズミだと間接的に証明された。
Microsoft がドブネズミなのは今に始まった事じゃない―――Microsoft はソフトウェア企業でありながら何一つ自分で生み出して来られなかった世界一先進性の乏しい企業である。
まあ、実際ドブネズミ共の悪巧みが上手くいって首尾良く Yahoo! の検索事業だけを買収できたとしても、Microsoft が何か新しい物を生み出してこれる可能性は全くない。
そんなことは誰でも知っている―――世界共通の暗黙知だ。
だが Windows の標準検索エンジンが刷新され、Internet Explorer が Netscape Navigator を追い出し、Media Player が Real Player などを追い出したのと同じことが起こるだろう。
ビル・ゲイツは去るらしいが、下逸と呼ばれた Microsoft はこれからも残り続けるだろう。
だが、もしかしたら今後はビル・ゲイツが居た時よりももっと凄まじい下方向に逸脱する Microsoft が見られることになるかもしれない。
金融ヤクザと手を組んだ Microsoft、真の悪の帝国はこれからなのかもしれない―――
近況追記。
本日は仕事を休んで（何ヶ月ぶりの有給休暇だ？）、病院で検査。
エコー検査と内視鏡検査をやってきた。
で、エコー検査でイキナリ胆石発見………(涙)
日頃の不摂生がモロに出たけど、今回の症状としては胆石自体は関係ないのではないかとのことで、爆弾を持っていることだけ理解させられた(涙)
ま、極度に疲れたりしないかぎりは発作は起こらないとの事だし、発作が起こらない限りは放っとく類の物らしいので、極度の無茶はしないことだ。
―――って、仕事するなってことか？？
続いて内視鏡検査。
内視鏡検査は初めてだが、最近のは鼻から突っ込むらしい。
喉から突っ込んで「うごごっ」とか言うのかと思ったけどそうでもない………と思ったらやっぱり「うごごっ」だった。
（ま、昔よりは遙かに楽なんだろう、涙目になる程度で済んだし）
で、内臓は食道から胃、十二指腸辺りの腸の入口までまんべんなく調べて、なにげにキレイだったみたいだ。
ただ、胃と腸の間辺りに炎症が見られ（ポリープでは無さそう）、多分コレが原因ではないかと言うことで組織を採取。
ちなみに、内視鏡検査はその一部始終を見せて貰った。
で、正式な結果は後日と言うことになった。
ちなみに胆石が見付かった絡みでエコー検査では見えなかった部分があるので、同日に CT 検査で輪切りになる予定………(涙)
さてさて、日頃の不摂生は認識済みとしても、どうなることやら………
更に追記。
先日、共通部品をイージーに直されて腹立っていた件だが、修正点を解析した時の自分の記憶が定かなら潜在バグが発生しているはずだと、湯船に漬かりながら思い至った。
明日出社したら早速調べてみるつもりだが、もし本当に潜在バグが見付かったらまた怒り狂うかもしれん。
こんな事やってるから胃炎なんか起こすんだろうな………(涙)
2008年7月7日
死んで治る馬鹿は大したことない
随分昔に 4,000 行から 5,000 行が BEGIN と END の間に敷き詰められている、無茶苦茶に低脳な PL/SQL で壮絶に腹が立った話を書いたと思うが、また、似たようなヤツと取っ組み合いしている。
今回は前回よりもやや少ない 3,000 行程度だが、なんちゅ～か………
-
やたらとデカイ、主部の BEGIN ～ END。
深く入れ子になった IF ～ THEN ～ ELSIF ～ ENDIF と DML の羅列で異様に追っかけづらい。
しかもインデントが不揃いという爆弾付き。
-
グローバル変数かと思ったら実は実質ローカル変数だった変数群。
もしかしてこいつはローカル変数の存在自体を知らないのでは？？
宣言する場所を変えただけでグローバル変数が半分減ったっ！！
-
やるだけ無駄な中途半端なハンガリアン記法。
変数の接頭語には "w_" を付けているにもかかわらず（多分 "work" の "w" だ）、定数にも "w_" が付いていて代入式を探す羽目になる。
見付けてみたらプロシージャの先頭で CONSTANT 宣言されていた。
-
Ｚ読みに近い目視検査だけでぞくぞく見付かる潜在バグ。
こんな物が共通部品として我が物顔で動いているかと思うと寒気がする。
ホントこのコードを書いた本人は、このコードが素晴らしいと自分で思っているのかね？
低脳の証明にしかなっていないこのコードを！？
億単位の大規模プロジェクトに集められる要員のレベルの低さと言ったらホントに想像を絶する物があるが、「何で自分はこんな巫山戯た糞ソースと取っ組み合いしてるんだろうか………？」と本気で悩むことがある。
プログラマの 35 歳定年説がまことしやかに囁かれているが、これは多分、最新技術に追い付けなくなるとかそう言う類の話ではない。
10 年もこんな巫山戯た糞ソースと取っ組み合いしてりゃ、辞めたくもなる。
これはもしかしたら IT 業界の構造的な問題だ(爆)
（ちなみに自分はまだ 35 歳前だし 10 年も続けていない）
さて、そんなこんなで色々とあって悶々としつつ下手すりゃまた暴れ出しそうな精神状態の自分だが………ちょっと面白い本を見付けた。
面白いと言うか、職業的プログラマ連中に是非とも読んでほしい本だ。
-
すべてのプログラマに効く
危険なプログラムの処方箋
(ISBN978-4-7973-3873-7)
職業的プログラマの量産する禁じられたプログラムに関して実例を交えつつ何がダメなのか、なんでダメになったのかを述べている。
後半は C や C++ に特化した禁じられたプログラムも多くなるので若干普遍性が薄れるが、それでも全体的に見て普遍性のある内容が網羅されている。
プロジェクト管理などのマネージメント上の問題ではなく、あくまでも禁じられたプログラムというソースコードレベルの内容を重視しているのも良い。
C や C++ に特化した内容が書かれているにもかかわらず C や C++ を高級言語と認めていない部分もよい。
この作者は C や C++ をアセンブラと同様の低級言語だとちゃんと認識して書いている。
そして何より、これを読むと自分が常日頃からイライラしているダメコードがほぼ網羅されてしまうからよい。
脳味噌が破壊され尽くした２年目、３年目の連中に対して行う再教育プログラムの導入部には、この本の内容は非常に良いかもしれない。
つまり二等兵以前のお笑い三等兵共に「きさまらはクソだ、そびえ立つクソだ」と最初にストレートパンチをお見舞いできるのである(爆)
まだ半分も読み込んでいないが、これは一読をオススメする。
2008年7月6日
再教育プログラムの必要性
この土日、共通部品をイージーに直されて腹立った事件から回復できず悶々としていたのだが、今日の夕方に結論を出した。
その共通部品がさる事情で別プロジェクト向けにフォークしていたので、現在進めている案件のついでに統合して運用・メンテナンスを簡素化しようと目論んでいたのだが、共通部品をイージーに弄りくさる事象が現実に発生したので統合を見送らせてもらう旨を提言する。
共通部品をイージーに弄って、弄った本人が全く知らない別システムがすっこけて損失が出るよりはずっとイイが、ハッキリ言って屈辱だ。
こんな些細なことで警戒線を張らなければならないほど、自分のやった共通化は脆弱な物ではなかったはずだ。
さて、経緯は別として、今回のことで色々と思ったことがある。
と言うか、ビジネスで職業的プログラムをしていて常々思っていることを今回の件で認識し直したわけだが、とにかくまともなプログラマは希少であるし、量産されたダメなプログラムは殊の外多いということである。
グローバル変数を多用してドコで何が起こるか分からないプログラムがある。
１メソッドの行数が数千行のプログラムがある。
意味のないコメントや巫山戯たコメント、間違ったコメントが書かれたプログラムがある。
そもそも構造化すら考えられていない、オブジェクト指向ではなくオブジェクト試行ないしオブジェクト嗜好なプログラムがある。
その他色々、小はコードの書き方から、大は実装ポリシーまで、枚挙に暇がない。
驚くなかれ、ビジネスで構築されたプログラムにこそこの手のダメなプログラムは多い。
自分も大した能力を持っているわけではないが、その自分から見てもどう考えても目に余る物が多すぎる。
プログラムは動けばいいのではない。
正常に動き、可読性が高く、仕様変更が容易であって初めて良いプログラムと言える。
かつてスイス連邦工科大の Niklaus Wirth 教授は教育用言語として PASCAL を作った。
ALGOL の流れをくんだこれは、Edsger Wybe Dijkstra によって提唱された構造化プログラミングに取り組んだ言語として、後の言語の元になっている。
しかしココで言う教育用とは、ずぶの弩素人相手の教育用ということではない。
ココで言う教育用とは、COBOL なんかでプログラムを囓った人間相手に正しいプログラミングを教育する為の教育用という意味である。
これと同じ事をやらなければならないのかもしれない。
つまり、唐突に VisalBasic や JAVA なんかでプログラミングの世界に入って、ろくな教育も受けないまま、構造化プログラミングもまともに出来ずに脳味噌が破壊され尽くした２年目、３年目の連中に対して、再教育プログラムを考えないといけないのかもしれないのである。
しかしこれは一大事だ。
脳味噌が破壊され尽くした２年目、３年目に対して、エレガントで普遍的なコーディングを教えるためにはどうしたらよい物か………？
何をやってはいけないかは身の回りにあるプログラムを見渡せば実例に事欠かないが、正しいプログラムの例は驚くほど少ない。
（そもそも“正しい”という考え方自体が宗教論争的で微妙だ）
言語の選定も大変だ。
ガーベージコレクションを前提とした言語や、CPU に対しての高率化を最優先した摩訶不思議な仕様を抱えた言語では普遍性がない。
どうする？
これは本気で取り込むとそれだけで本が書ける内容になるぞ？
取り敢えず読んどけ的な本があればよいのだけど………探してみるか………？
2008年7月4日
自分は真性の手前勝手プログラマらしい
今日は自戒を込めて墜落してみる。
自分は真性の手前勝手プログラマらしい。
ちょっと本気でそう思った。
「真性のプログラマ」なのではなく「真性の手前勝手プログラマ」である。
例えるなら、そう、オープンソース開発やエンタープライズな大規模開発に居てはいけないタイプの手前勝手である。
で、どうして唐突にそう思ったのかというと………
自分のコントロールを離れてしまったソースを久しぶりに眺めて、自分の設計理念と 180 度違う修正をされていることに気付いて、本格的な怒り狂ったのである。
その修正に関連するデータベースのテーブル定義の変更を調べて、そのあまりの節操の無さに机を思い切り殴りつけた。
ソースを詳細に解析する間、鬱屈した気分を抱え込んでイライラが収まらなかった。
自分の努力が全否定された気がして、全てがどうでも良くなった。
冷静さを取り戻すのに１時間かかった。
冷静さを取り戻してから修正の経緯を問い合わせたのだが、いきなり電話しなかったのは僅かばかり残った忍耐力のなせる技だろう。
正直、危なかった。
ちなみにそのソースコードは共通部品として徹底的にチューンしていた。
自分のポリシーとして、共通部品には特定の呼び出し側の事情を勝手に認識して有効にされるような処理を仕組んではいけないと考えている。
どうしても仕込まなければならない場合、端から見ると共通部品のひとつのモードの様に振る舞うインターフェイスを構築して、呼び出し側にその機能の有効化を指示するように求める。
もちろん呼び出し側がその機能を有効化しない場合には今までと同様に動作する。
それが特定の呼び出し側の為だけの処理であると使う側に気付かせない様にして、共通部品としての独立性をギリギリまで維持するわけだ。
前述の通り、そのソースコードは共通部品として徹底的にチューンしていたので、特定の呼び出し側だけに必要なコードが無節操に入り込むのは自分の設計理念と 180 度違うわけである。
その自分の設計理念と 180 度違う実装は共通部品の共通部品たる独立性を阻み、利用する側に無用な考慮や注意を強いることになりかねない。
それは共通部品としてエレガントではないダメ実装、と、思うのである。
だが、そのソースコード、たしかに最初にコーディングしたのは自分だが、そのコントロール権は自分にはない。
ぶっちゃけちゃうと他人の持ち物であって、自分が四の五の言っていい類の物ではないのである。
つまり怒り狂うこと自体が筋違いなのである。
心の片隅に残った冷静な部分がこの認識を叫んだから、なんとか踏みとどまれた。
さて、そう考えると自分の悪癖が見えてくる。
自分が最初にコーディングしたソースに対してコントロールを維持したい、そのソースコードに対して最初の自分の理念を貫かせたい、自分はそう思う傾向が強い―――が、そう思うのは少なくともエンタープライズな大規模開発では邪魔な思想だ。
たとえ共通チームのチーフプログラマだとしても、そんな自分勝手は通らない。
それに大規模になればなる程に底辺の開発者のレベルはどん底まで落ちるから、事実上コントロールしようとする行為自体が無理になることもある。
呼び出し側のソースのクオリティを維持することも難しいばかりか、共通化チームが構築する共通部品ですら最初の自分の理念が維持できないことも多い。
そんな現実の中で敢えて組織的に特定のソースのコントロールを特定のプログラマに委ねていたら、単純にそのプログラマがクリティカルパスになって危険性が増すだけだ。
ではこれがオープンソースだったらどうだ？
オープンソース開発では最初の内はよくある伽藍方式だろうが、成熟していくとバザール形式に移行するケースがある。
伽藍方式はどちらかと言えば企業などで一般的に行われていたり、クローズドソースなフリーウェアの形式であるが、バザール形式はもう見事なまでにフルオープンだ。
四方八方からアイデア、意見があつまり―――それ自体はとても良いことだ―――そのコーディネートを中心人物が行うか、議会形式で決定する。
そうなるとお互いの話し合い、意見の応酬は当然あるだろうが、自分の最初の構想と 100% 同じ方向を向くとは考えにくい―――自分も納得する方向転換なら話は別だが。
ここで自分のような意固地になる人間がいると、プロジェクトに不協和音が生まれるか、さもなくばフォークしてしまう。
建設的でないフォークはむしろ貴重なヒューマンリソースの分散を招く罪悪で、自分の癖はその引き金になりかねない。
結局、どちらのケースでも自分の癖は邪魔になる気がする………(笑)
う～ん………結局なにか？
自分が人様に迷惑かけないようにするためには、ひたすらに独立独歩でいくしかない、という事なんだろうか………？？
大きな仕事には参画せず、自分一人で制御しきれる程度のソースコード量の仕事をちまちまと片付けて日銭を稼ぐような………個人事業主？？(爆)
さもなければ最後まで自分がコントロールを維持できるパッケージでも作って売り歩くか………？
う～ん………(汗々)
2008年7月3日
Scalix 11.4 リリース日確定、らしい
現在導入準備をすすめつつ試している Scalix だが、最新版の 11.4 日本語版のリリース日が 7/10 に確定したらしい。
今回目玉になりそうなのが、自分的には、
- Firefox 3.0 への正式サポート
- CentOS 4、5 への正式サポート
あたりかな？
CentOS 5 系最新で Scalix サーバを構成して、Firefox 3.0 で利用するという、現在目指している環境が全て出揃うわけである。
これで本格的にメールサーバの移管に踏み切れそうな気配だ。
詳しくはこちらで。
2008年7月1日
検索するな、マニュアル読め
ここ数ヶ月煩っているというか、のたうっている胃痛だが、とうとう本日病院に行ってきた。
ま、初診だったりしてイキナリ検査とかいうことはなかったが、来週エコー検査と内視鏡検査をしてくる予定。
単純に胃の働きが弱っているか、胃幽門狭窄症だろうという話だが、最悪だと胃潰瘍の疑いがある様だ。
なんか胃痛で病院に行くって、切なくなってきた………俺ももうそんな歳か………(涙)
で、今日の本題はソコではない。
最近の若い連中、特に１年目とか２年目の初学者ですらないペーペーがプログラミングしている姿を見ていると、ふと思うことがある。
何か分からないことがあるとまず Google で検索しているのである。
で、氾濫する情報の中から正しい情報が選別できずに時間だけ掛かっている………
いや、お前ら、まずはマニュアルを読め。
安易に Google に頼るな、むしろググるな。
予測で適切なキーワードを指定する能力も、溢れる情報の中から正しい情報を選び取る能力もない、まったく経験の足りないずぶの弩素人が、Google 検索でどんなに頑張ってみたところで糞の役にも立たない。
精々が無駄な時間ばかりかけて「取り敢えず動いた」でバグだらけの役に立たないコードを量産するだけだ。
根本的に間違っている。
たしかに Google なんかで検索するのは便利ではあるが、それは情報の取捨選択が出来る基礎知識が備わっている人間の言うことであって、基礎知識のない人間は素直にマニュアルを読まなければいけない。
検索で情報を探すのは、あくまでも基礎知識を得た後の話である。
平気で最下層の成績をマークしつつなんとかかんとか学生を卒業できたような俺みたいな馬鹿よりもずっと勉強の仕方を知っているはずの連中が、なぜかここにきてそのセオリーをひん曲げている。
お前ら、勉強するのにイキナリ Google で検索したのか！？
三角関数が分かりませんとイキナリにググったのか！？ 違うだろっ！？ まずは教科書と取っ組み合いしたはずだ！！
と、思うのだが………
今日も弩素人が Google 検索で貴重な時間を無駄にしている………
もしかしてこいつら………
円周率が 3 だと思い込んでいる連中なんだろうか………？
検索エンジンが便利になった反面、人間はどこまでも退化していくのかな～と思ってしまう。
そう、まるで日本語変換が発達したおかげで漢字が書けなくなった俺のように(爆)
