2006.01.20

コーディングしたい!

諸事情により、全然コーディング作業ができてません。プライベートも仕事でも。

あー、コーディングしたい!やりたいことは既にあるんですが、時間がない…。時間を作るには、週末の家族サービスを放棄するしかなさそうです。

|

2005.09.22

物を作るって?

プログラムを始めた頃は、物ができること自体が楽しくて仕方ありませんでした。

そこから成長すると、次はできる物自体の品質を上げていくことが楽しくて仕方なくなります。

で、最終的には作り方を色々と考えていったりします。おそらく、ほぼ全てのプログラマがこういう段階を踏んでいくでしょう。

その道程は経験してきたことだし、これから経験する人も沢山いると思います。

でも、忘れちゃいけないのはプログラミングって作業は、「目的」があってやるもんです。言い換えると、目的が達成できさえすれば「作り方」なんてのはどうでもいいんです。

こういう話って色んなところで繰り返しなされてると思いますが、今現在の私の素直な気持ちとしてチラシの裏代わりに書いておきます。

|

2005.06.28

UML初心者への言葉

UMLという言葉を初めて聞いたときから、もう何年が経ったでしょうか。

私が生まれて初めて聞いたモデリング手法は、「OMT」というUMLが統合したモデリング技術の一つでした。これを入社したてのぺーぺーの頃に「車のエンジン部をクラス図で書きなさい」などといわれて、車の構造すら分からないのに四苦八苦しながら書きつづけ何度も訂正させられて、「二度と使うかばかやろー」と思ったのを覚えています。

このクラス図を実際の実務で使ってみて「お、便利じゃん」って思ったのは、つい先週ぐらいの事なんですが。それまでは、上司に言われるから書くだけで書き捨て状態でした。

さて、このUMLに関してですが実務を経験した中からUMLにはいくつものモデリング手法があるのですが、私はこの中のシーケンス図とクラス図しか実務では使ったことありませんでした。(クラス図は最初の入り口が、OMTというあまりに難しい手法過ぎたので未だに苦手です。)

クラス図と違ってシーケンス図は凄くアバウトに書けて、処理内容を図を見た全員が説明も要らないほど簡単に理解できる図としては最強だと思います。そういう理由から、私は外注との仕様確定時にシーケンス図を使うことを常としていました。下手すると、最初の打ち合わせ時にはシーケンス図しか持っていかないなんてことも。まあ、これは単なる手抜きなんでシーケンス図では表現できない契約上必要な仕様はきちんと書いていかないといけません(^^;。

もし、UMLアレルギーを既に発症してる方が居たとしたら、大抵のUML入門の入り口に位置しているクラス図を一度捨ててください。そして、自分でも「ココの処理内容は何かに書き残しておきたいな」と思った処理をシーケンス図に落とし込んでみてください。

凄く楽に書けて、凄く説得力のある図が書けます。ぜひお試しを。

と、偉そうに書いてみましたが、実はUMLはほぼ独学です。シーケンス図も、Visioを使いながら覚えたようなもんです。よって「正しいシーケンス図」を学んだことは一度もありません。

でも、UMLはコミュニケーションのためのツールに過ぎません。乱暴に言い換えると、日本語や英語などの言葉と同じようなもんです。一番大事なことは、伝えたいことが相手に伝わることであり、ツールの使い方が仕様どおりで正しいことってのは、その次ぐらいに大事なことになるでしょう。つまり、正しくても伝えたい相手に正確に伝わらないなら駄目な図であり、正しくなくても伝えたい相手に正確に伝わるなら、正しくない方が良いのです。

よって、私は相関を表現する線や矢印記号に込められる正しい仕様上の意味に、それほど期待はしていません。UMLの入り口に立った方は、最初は単なる実線のみの図を作成すると良いでしょう。そして、実線だけでは表現しきれないと感じてから、実線以外の線の意味を知れば良いと思います。但し、伝えたい相手が同じように成長してくれないと意味がないわけですが^^;。

|

2004.12.27

XMLHTTPコンポーネントの謎

MSXMLにはXMLHTTPという、非常に使い勝手の良いHTTP通信用のコンポーネントが内蔵されている。これが一番良い点は、IEでの通信と同じ通信をしてくれるという点だ。HTTP通信を別コンポーネントでやると、IEで繋がるのに、なんでこのソフトでは繋がらないんだというのを、いちいち言い訳しなくてはならなくなる。

そういう言い訳をしなくても良いというだけでも素晴らしいのに、使い勝手も申し分ない。それまで、ユーザーに散々言い訳を並べてきたサポート部隊である私としては、このコンポーネントの存在を知ったときは、小躍りしてしまった。いいぞいいぞ。

しかし、つい先日判明した事実なのだが、どうもPOSTででかいサイズのファイルを受信しようとすると、5MBを超えたあたりから異常に遅くなるという事実が判明した。これが、GETなら特に問題はないようだ。(GETとPOSTで全く同じURLを開いて同じ結果が得られる環境を用意してるわけではないので、本当にPOSTだから不味いのかは分からない。)

つまりは、発注元から「5MB超えたら遅くなるので修正してくれ」と来たのである。修正方法を探してるのだが、日本語ではまともにXMLHTTPを解説してくれてるありがたいサイトはないので、英語のページを漁ってたりする。これが、修正方法が見つからない。これは、もしかしてHTTP通信部分を別コンポーネントでやるしかないのか。

というか、誰か良いサイトか良い情報持ってたら、こっそり教えてください。

| | TrackBack (0)

2004.12.24

NMFTPの馬鹿!

仕事でBorland C++ Builder5を使ってます。Web系の開発も、極々偶にやるんですが、その際自力でRFCを読んで開発するわけもなく、インターネットコンポーネントを最大限に活用します。

BCB5にはNM系のコンポーネントが標準装備されているので、もう4年ぐらい前にですが、NMHTTPとNMFTPを利用したActiveXのソフトウェアを作成しました。正確には、私が作らせたわけでも私が作ったわけでもなくて、上司が外注に作らせて、出来上がってきたソースを、「再構築して、メンテナンスおねがいね」とポンっと渡されただけなんですが。

NM系コンポーネントは、当時から既に悪名が高くて有名でした。外注に発注する前の上司からの相談で、私はNM系を使うのは反対したのですが、私の意見は反映されなかったようです。

まあ、それほど複雑なことをしてるわけでもないし、何よりユーザー数が圧倒的に少ないのが良かったのか、特に大きな問題も今までは発生することはありませんでした。

そして、何年も経った今になって問題が発生します。その発端はWindowsXPのSP2です。XP SP2のファイアーウォール機能を使用すると、NMFTPの「切断時」に例外が発生します。調べると、コンポーネントの切断メソッドの内部で例外が発生しているようです。

原因を調べていくと、どうやらFTPは二つのポートを使うのですが、この二つのポートを閉じる順番に問題があることが分かってきました。このあたりの詳しい説明は、「インターネット・プロトコル詳説(10) FTP(File Transfer Protocol)」でも読んでください。

んで、NMFTPの通信のログを確認すると、間違いなく閉じる順番を間違ってるんですよね。つまりは単純なミスだってことです。今まで発覚しなかったのは、単に「偶々動いてたから」という理由だけです。なんてこったいorz。

この不具合の対処は、ソースを購入して修正するか、別のコンポーネントを利用するか、自作するかの3つの対処方法があります。作業する時間もないし、ユーザーが急いでるということだったので、この3つのまともな修正方法ではなく、お手軽な修正を行いました。それは、とりあえずまともに動作してるように見せかけるために、例外をキャッチしてスルーするという手法です。

この「とりあえず」が、永遠にそのままな気がしてなりません。作業する時間がそれなりに必要だからなぁ…。

| | TrackBack (1)

2004.10.30

BCBコンポとツール

私が使用してる、BCBのコンポとツールをフリーのもの限定で記録しておく。あくまで、自分用。

RxLib
http://rxlib.wz.cz/

GExpert
http://www.gexperts.org/

上記二つだけだけど、これで完璧。

|

2004.09.18

飽きれ果てた話

無限ツリー階層をDBのテーブル形式で保持する手法で一般的なのは、親は子知らず型という奴です。

簡単に親は子知らず型を説明すると、テーブルの項目に「親ID」なる項目を設け、子供だけが親のIDを知っておくという形にしておきます。そうすれば、簡単に無限ツリー階層を構築することができます。ルート階層は、親IDがNULLのレコードに当たるわけですね。

まあ、極一般的な手法だとは思いますが、私が飽きれたのは、お役所が作ったある仕様改訂の話。

改訂なので、以前の仕様があるわけですが、以前の仕様になかった親子関係をあるオブジェクト間に構築しようとしたようです。そこで親子関係を作るために、「上位ID」と「下位ID」なる属性が追加されました。そして、この属性の記述方法は、XMLのAttributeで記述するとのこと。ちなみに、XMLタグ内のAttributeは同じAttributeを複数個書けません。

ココまで書けば、想像できると思いますが、この仕様だと大きな制限として、親は子供を一個しか持てないという制限ができるんですよね。

んで、仕様上も実運用上も親は子供を一個しか持てない制限があって構わないというなら話は分かるんです。

でも、どう見ても実運用上で複数の子供を持てるようにしないと不味そう。そう思って、現在仕様作成元に問合せを行なってたりします。親も子も相手を知ってる形にする意味とか考えたんでしょうかね?それとも、完全な素人が全国で利用する仕様書を作成してるのでしょうか?だとしたら、仕事を舐めすぎだと思いますが。

#もし、これが外注に作らせてるとか、どっか詳しい会社に内容をチェックしてもらってるとかだったら、単なる税金の無駄遣いですね。

|

2004.08.20

WindowsXP SP2の変更点

WindowsXPのSP2が出るということで、うちのソフトが動くのかをチェックしてみました。

チェックする前に、何が変更になったかを下調べです。

Windows XP Service Pack 2: 開発者向け情報

調べてみると、関係がありそうなのはRPCの匿名アクセスが制限されるという項目だけです。んで、実際にSP2(RC2)環境にてチェックしてみると、やっぱりRPCができないようです。

そりゃ、通信時に何かセキュリティかけてるわけじゃないので、繋がらないのも無理はありません。そういう仕様変更なんですからね。

んで、修正方法を調べてみると、修正方法は3つあって、「A.匿名アクセス禁止にする」か、「B.匿名アクセス許可にする」か、「C.システム設定を弄って全部匿名OKにする」かの3つのパターンがあります。

Cの対応なんてもっての他なので、AかBの対応になります。Aの修正をするとなると、サーバー側とクライアント側の両方を弄らないといけません。というわけで、まずはBの対応をしてチェックしてみました。

すると、問題なく動作しました。対応方法は間違ってなかったようです。後は匿名禁止にするために、Aの対応をするだけです。

で、ここであまりにあっさり対応できたことで、大半の技術者は本来WindowsXP SP2が求めたセキュリティレベルである「A」の対応をせずに、「B」の対応をしてしまうんじゃないかという考えが浮かんできます。それほど、開発者の中に「セキュリティ」に対する意識は高くないということです。

実は、この問題は開発者以上に、現場の方がセキュリティに対する意識が低いことに起因します。つまり、開発者というのは、エンドユーザーが求める物を作るだけで、啓蒙する立場にないと考える人が多いのです。啓蒙しても、直接的にお金にはなりませんからね。

そして、問合せ等で聞かれて対処するときに良く言われる言葉は「動けばいいから」という言葉があります。今回のせっかくのセキュリティ強化も「動けばいい」的発想で、上記のBの対応がなされるとしたら悲しい限りです。

もっと言うなら、Cの対応する人って多いだろうなぁ。だって、コーディング一切ありませんもん。設定変更するための手順書作っておしまいですからね。

| | TrackBack (0)

2004.08.11

InstallShield 1607 エラーに悩まされる

勤務先で作ってるソフトウェアの配布で、インストーラはInstallShieldを利用して作っている。

しかし、このInstallShieldは様々なユーザ環境に耐えうるだけの品質を持っていないことが判明しつつある。

一番嫌なエラーが「1607」というエラーで、正直原因などこれっぽっちも分からないエラーである。私の勤務先の会社だけじゃなくて、様々な会社が、この1607エラーには悩まされているようで、googleで「InstallShield 1607」で検索すると対処法が沢山見つかる。

んで、この対処法の一つとして「isscript.msi」を実行するというのがあるんだが、このインストーラを実行すると、1327というエラーコードが出ることがあり、上の1607になる原因のほとんどは、ほとんどがisscript.msiの1327に起因するようである。

1327が発生するケースで一番可能性があるケースは、「CD-ROMのドライブ文字を変更している」ケースだ。ほとんどのユーザが、たったこれだけの事で困ってしまうという状況・・・。

というか、ドライブ文字変更したらインストールできないって、全然理解できん。どんな制限だっちゅーの(^^;。


ちなみに、1607エラーは月に数回電話がかかってくる。たかだか数百本のユーザーなのに!こんなんで良いんの?InstallShieldさん。

| | TrackBack (0)

2004.08.03

仕事でのミス

更新がストップしてる間、仕事のミスを連発させてました。しかも、かなりヤバゲな奴。

まあ、多数のエンドユーザに影響あるんじゃなくて、極少数の協力会社に対してのみ迷惑かける形のミスなんですが、会社として品質管理の問題を問われかねないぐらいヤバイ奴だったりします。

なんせ、一度でもコマンド実行したら100%発生する不具合ですから(汗)。

まあ、その他の条件が無いわけじゃないですけどね。見事に、その他の条件に当てはまる環境でしかチェックしてなかったというお粗末な不具合でした。

久しぶりの投稿が、こんな懺悔っぽい形の投稿ですみません・・・。

| | TrackBack (0)