検索

• ECMA-262 » JavaScript. The core.
  • http://dmitrysoshnikov.com/ecmascript/javascript-the-core/

やっぱり図や絵があると、分かりやすい。
描くのは大変だけど、見習いたいところです。

「動けば良いだろ」的箱庭優先SIerが書いた、分かりづらいソースコードを読んでいて、「・・・これ、どう考えてもバグだよな。」を見つけた時。しかもその原因が「動けば良いだろ」的にコピペしたことであるとき。

一瞬で頭に血が昇り、わき上がってくる殺意や絶望感を抑えつけ、その直ぐ後に襲ってくる無力感。

いや本当、こんなの繰り返してたら健康に悪い。まず血圧に悪い。

あと実際、マジで頭痛がしてくる。以前手伝ったとある仕事では、上記のように
「一瞬でカーッとなる」→「無力感で鬱」→暫く周辺コード調べる→「また一瞬でカーッとなる」→エンドレス
だった。
頭痛はするし、なんだか頭がぐらぐらしてくるし・・・。はっきりとした目眩には至らないんだけど、とにかく感情のUP-DOWNが激しすぎる。
只でさえ、分かりづらいソースコードを読んでいる時は頭使ってるのに、そこに普段は絶対あり得ないほどの勢いでマイナス感情が襲ってくる。津波のように襲い、引いていったあとには途方に暮れたような絶望感、無力感が残り、それでもまた調査に戻ると、また襲ってくる。

もう条件反射になってしまってるのかな。この挙動、自分で手綱を握れない。

無力感で鬱になるのは、「じゃぁ自分の考えるキレイなコードとやらで、この読みづらいソースコードを今から全部書き直せるのか？」と自問し、言わずもがな「否」だから。
それだけ、時間と人とが注ぎ込まれてきたソースコードだから。分量だってそれなりにある。アーキテクチャ、前提条件、既存BUGとの互換性など、それこそ全く同じシステムを作る＋αの作業量が必要になってくる。

「動けばよい」的箱庭SIerの作ったシステムは、実際にそれで動いて、お金を稼いでいる。

単に読みづらいからぶつくさ文句言っているだけの自分は、最初から蚊帳の外、外野、赤の他人、無責任な口だけ人間。

読みづらいソースコードを書いたプログラマが恨めしいし、それに対して文句を言って多少fixするくらいしか手を出せない自分の無力さが恨めしいし、口だけ人間に堕していく自分が恨めしいし、他人をここまで恨む自分も恨めしい。

「作る側」を手伝う限り、そちらに身を置く限りは、特にSIer周辺では、この意識の動きから逃げられない。
SIerがダメならWeb系は？ダメだ。Web系でも「動けばOKでしょ？」でプログラミングする人は居る。

作る側には、もう居られない。
大学時代からの友人には、会うたびに「お前は人間の生臭さに耐えられないタイプ。静かに研究してる方が向いてるんだから大学戻れよ～(w」と茶化されているが、全くその通りなのだろうな。

どうなってるんだろう。
実験：

    public void sessionClosed(IoSession session) throws Exception
    {
        System.out.println("SessionClosed()...");
        System.out.println("isClosing() = " + session.isClosing());
        System.out.println("isConnected() = " + session.isConnected());
    }

結果：

10828 [AnonymousIoService-6] INFO  xxxxyyyyHandler  - [/127.0.0.1:3643] CLOSED
SessionClosed()...
isClosing() = true
isConnected() = false

• [ Prev ]
• [ Next ]
• [ Java ]

Apache MINAで、バイナリ生データをビジネスロジックレベルのオブジェクト（メッセージ）に変換するのに使うのがFilterChainに組み込めるProtocolDecoder/ProtocolEncoderインターフェイス系のクラスです。ProtocolCodecFactoryを介して登録することで、上記処理を挟むことができます。

この時少し厄介なのが、受信データを扱うDecoder系です。次の処理を実装する必要があります。画像ファイルを添付したときのPOSTデータを変換するケースを想像してみて下さい。

• 必要な量のデータ長を受信出来たか？(HTTPヘッダーとmultipart-form-data, Content-Lengthヘッダなどから判断)
  • 足りていれば、これまで受信したデータを連結し、メッセージ変換実行
  • 足りていなければ、今回受信したデータを保存

ProtocolDecoderインターフェイスには、上記の処理をより実装しやすくした派生クラスが存在しますが、ドキュメントやexampleではどのようなシーンでどれを使うべきかの指針や、裏側の仕組みの解説が散逸していてまとまっていません。

本記事ではその辺りを覚え書き程度に書き付けておきます。
なお対象は Apache MINA 1.1.7 です。

ProtocolDecoder : 一番単純で、ベースとなるインターフェイス
 | |
 | +-> ProtocolDecoderAdapter : finishDecode(), dispose()を空で実装して簡略化したabstractクラス
 V
CumulativeProtocolDecoder : doDecode()実装するだけでオッケーなabstractクラス
 |
 V
demux.DemuxingProtocolCodecFactory系 : 複数のDecoder/Encoderを混在させたい場合に使う。
    MessageDecoder(Adapter)/MessageEncoder(Adapter)を実装してregister()する。

9/26に神奈川は三浦半島、城ヶ島でダイビングしてきました。本当は9/25も行く予定だったんですが、台風の影響で中止でした。
ダイビングポイントは１回目が「へいぶ根」２回目が「岩骨」。へいぶ根は透明度が悪かったのですが、岩骨の方は非常に水が澄んでいて、綺麗でした。

• 変数・関数の命名規則が一定していない。特にグローバルな変数とローカルな変数の命名規約が区別されてないので、if()とかのフラグで使われていても、グローバルなのかローカルなのか一々確認しないといけない。
• 変数・関数名が短すぎる。名が体を表してない。つまり、一々ソースをgrepして確認して、覚えておかないといけない。

この時点でソースコードを読む気力が大体、マイナス50%。

あと、たった今出くわしたソースで、

• バイナリデータでやりとりする、それもクロスプラットフォームなデータの構造体をpackで穴埋めサイズを調整してない。＝コンパイラ任せ。

この時点で保守作業のやる気が大体、マイナス50%。

箱庭SIerの書いたソースコードは二度と読みたくない。SAN値を削り取られる。

同じSIerでも、そんなに読みづらさを感じない場合もあるんだけれど、そういうソースって、大概OSSの世界に首突っ込んでたり、言語やOSを複数使ってたり、幅広い現場でさまざまなコードと付き合ったりしてるプログラマが書いてる。
読みやすいコードって結局、変な癖が無くて、「他人が読んでも分かるように」最初から意識されて素直に書かれてるソースなんだよね。

最近、負荷が高くなってくると熱暴走なのか、電源劣化の問題か、マザーボードの電子部品劣化が原因か、

ﾌﾟﾁｯ

っといきなり再起動する。

2004年の8月頃に購入したNECの水冷PCで、スペック的にも静音的にも全く不自由していないのだけれど、さすがにそろそろ寿命かも知れない。6年経ってる。
HDDの方はまだイケルっぽい。HDD特有の寿命間近な「ｶﾘｶﾘ音」はまだ聞こえてこない。
でも電源 or MBの物理的な経年劣化っぽいから、そろそろ新しいの用意しないとダメかも。Windows 7も使ってみたいし。

• [ Prev ]
• [ Next ]
• [ Assembler ]

「暇な時に、手持ちの環境でアセンブラを弄って自己満足」なx86アセンブラの世界へようこそ。

本シリーズは、少しばっかりWeb上の記事でx86アセンブラを聞きかじり、「じゃぁ手が空いた時にでもアセンブラを勉強してみるか」と思っている読者を想定しています。
従って、わざわざ「アセンブラとは何か？」「x86におけるCPUアーキテクチャ」「x86アセンブラ命令一覧」などは微塵も解説しません。その辺はWeb上、あるいは以下に示すように優れた参考書籍がありますので、自力で調べることが出来ると仮定しています。

問題は、「手持ちの環境でx86アセンブラを弄れること」これに尽きると思います。
本シリーズでは16bitDOS環境・16bitBIOS環境(Master Boot Record)・32bitWindows/Linux環境のそれぞれで、無償で入手可能なソフトウェアを使ってアセンブラプログラミングを楽しむ方法を紹介しています。
さすがにメモ帳やバイナリエディタで直接16進バイトコードを打ち込むのは著者の力量では無理ですが、OSに付属していたり、Webから無償でダウンロード出来るソフトウェアでそれなりにアセンブラプログラミングを楽しむことが出来ます。

本シリーズでは「入り口」を紹介するところまでが精一杯ですが、これらを取っ掛かりとして、より深いx86アセンブラプログラミングを楽しんで頂ければ幸いです。

• [ Prev ]
• [ Next ]
• [ Assembler ]

Netwide Assembler(NASM)は80x86およびx86-64用のアセンブラで、MicrosoftやLinux, UNIX上の各種オブジェクトファイル・実行ファイルフォーマットに対応しています。Linux/UNIX/Windows各プラットフォームで動作し、アセンブラの入門レベルからOSの開発まで幅広く使われていています。

なおNASMアセンブラの記述はIntel方式(destination, source)です。

• The Netwide Assembler: NASM
  • http://www.nasm.us/

本記事ではNASMを使って16bitDOSプログラミング(但し.COMファイルフォーマットのみ)を体験してみます。
2010年9月時点での最新版 nasm-2.09.01 を使用し、 Windows XP SP3 (Pen4) 上で動作確認しています。

NASMのインストール方法の詳細については省略します。Web上で適宜検索・調査してインストールして下さい。

• [ Prev ]
• [ Next ]
• [ Assembler ]

1980年代のCP/Mから30年にわたり生き延びてきたデバッガ兼アセンブラが"debug.exe"です。
永らくDOSやWindowsに同梱されてきたdebug.exeですが、さすがにWindows7には含まれていないようです。
もし手元のPCがWindowsXP以前のOSなら、今の内に往時の16bitDOSアセンブラプログラミングを体験してみましょう。

なおdebugコマンドでのアセンブラの記述はIntel方式(destination, source)です。