変数のデータ型

ASP

ASP（VBScript）やJavaScpirtでコーディングしていると、ものすごく不安になることが多々あります。
というのも変数の型宣言を行わなくてもプログラムが動いてしまうからです。

私のプログラミング経験はC言語から入り、次にVB6.0、Java、VB.Netなどといった、基本的に型宣言に関しては厳格に検査している言語から学んできたため、型宣言をしないというスタイルがどうも馴染めません。

VBなんかでは、Object型などといった何でも入るデータ型もありますが、そういった汎用型はコーディング規約で真っ先に禁止される型ですので、あまり使う機会はありませんでした。

でも、ASPやJavaScriptのコードを見ていると、型指定を行ってないんですよ。
演算方法によって自動で判別してくれるようですが、自分で明示的に指定してないので、正しく動いてくれるのか不安でなりません。

私の同期であるWeb系のシステムを主に開発してきた人にそのことを聞いてみると、Perlなんかだと型指定という概念自体がないんだとか。
しかも、その人は「変数の型指定なんてめんどくさい」みたいなことを言うんです。

参加したプロジェクトによって、この辺の感覚がものすごくずれてくるようです。

WindowsVista対応試験時の苦悩

試験

WindowsVistaの後続OS「Windows 7」の発売予定日が2009年10月22日となったそうで、私のような末端プログラマにとって、それほどうれしくない日が近づいています。
というのも、既存アプリケーションの新OS対応試験を行わなければならないためです。

ということで、今回は以前行った既存アプリケーションのVista対応試験についてのことを書き留めておこうと思います。


既存アプリケーションをVistaにも対応させたいということで、Vista上でアプリケーション試験を一から全て行います。
Vistaは、Home Basic、Home Premiumなどとエディションの数が全部で6個もあり、それら全てで試験を行えという指示です。

途中までは問題がでなかったので、このまま何事もなく試験を終えられるのかなと思っていた矢先、うまく動かないところを発見してしまいました。

アプリケーションで作成したはずのファイルが、指定したフォルダに存在しない。
ドラックアンドドロップがうまくいかない。

まずはこの辺の問題が上がってきました。
さらに、「アプリケーション起動時に『ユーザーアカウント制御』ダイアログが必ず出力されてしまう」といったことも問題と取られ、これについても解決方法を探さなければなりません。

ということで、早速マイクロソフトのサイトに行って、Vistaに関するドキュメントをダウンロードし読み始めます。
http://download.microsoft.com/download/3/4/4/3448ddf3-ca22-45bd-9984-1237e8ed0019/Windows_Vista_application_compatibility_paper.doc


まず①の問題は、Vistaの新機能である「File and Registry Redirection」が原因でした。
Vistaの場合、例え管理者権限でOSにログインしても、アプリケーション実行時は権限を一般ユーザ権限まで下げるそうです。
その場合、アクセス権が制限され、一般ユーザ権限ではアクセスできないフォルダが出てきます。
こうなると、管理者権限で動作することを前提としたアプリケーションは正常に動作してくれません。
その対応のためかVistaは、アクセス権がないフォルダに対してアプリケーションが書き込み処理をした場合、「File and Registry Redirection」機能が勝手に動きます。

これは書き込み権限の無いフォルダやレジストリへの書き込みを、ユーザーごとの領域にリダイレクトするという機能です。

つまり、ファイルの保存先をVistaが勝手に変えてしまっていたのです。

この問題は、Program Filesファルダの下位層フォルダをデフォルトのファイル保存先としてしまったため起きてしまったことです。
通常、何らかのファイルの保存先デフォルトフォルダはマイドキュメントの下位層にするべきであり、Program Filesフォルダの下位層フォルダをデフォルトフォルダとしてしまったことがそもそもの原因です。

ですのでこれは「Vistaのせい」というより、「アプリケーションの仕様の問題」と言えます。


次に、②のドラックアンドドロップができないという問題についてです。
エクスプローラからアプリケーションにドラッグアンドドロップしても成功してくれず、これについてもいろいろ調べてたんですが、どうやら権限が異なるアプリケーション間のドラックアンドドロップはできない仕様になっているようです。

つまり、一般ユーザ権限で実行しているエクスプローラから、管理者権限で実行しているアプリケーションへのドラックアンドドロップはできないということです。

よく考えたら自然なことなのですが、XP以前のOSではOSログイン後に実行権限が異なるアプリケーションが起動されるなんてことはありませんので、なかなか原因をつかめずまいってました。

そして最後に、「アプリケーション起動時に『ユーザーアカウント制御』ダイアログが必ず出力されてしまう」という件についてです。

試験したアプリケーションを、普通に起動させただけで（エグゼをダブルクリック）、必ずユーザアカウント制御ダイアログが出力されてしまいます。
他のアプリケーションも同じなのかを確かめてみたのですが、ユーザアカウント制御ダイアログが出力されることはありませんでした。

意図してないのになぜ勝手にダイアログが出力されるのか？
これは、Vistaはアプリケーションの起動前に実行に必要な権限をチェックする機能があるようで、その機能に引っかかっているからダイアログが勝手に上がってしまうということのようです。

ユーザアカウント制御ダイアログを表示させないようにするためにどうしたらいいか、かなり悩んだんですが、この件については正直お手上げでした。

確かにそのアプリケーションはドライバを操作する処理など、かなりハードウェアよりの処理を含んでいたので、Vistaのチェック機構に引っかかってもおかしくないと言えました。

むしろ、そういう処理が含まれているためユーザアカウント制御ダイアログが出力されてしまうのは、チェック機構を設けているVista上で動作させる以上仕方のないこと、と捉えても良いのではないか…。

最終的に、ユーザアカウント制御ダイアログが出力されてしまう件については、仕様ということで終えました。


このようにVistaにはかなり苦しめられました。
そもそもエディションをなぜあんなに細かく分けているのか、理解にし難いところがあります。
Windows7も6個のエディションが発売されるそうで、
この変な慣習は今後廃止してほしいです。

映画ファイヤーウォールを鑑賞

日記

ファイヤーウォールという映画のDVDを借りてきました。
本当は別のものを借りるつもりでレンタル屋に行ったのですが、たまたま見つけたDVDの映画タイトルに惹かれて、つい手を伸ばしていました。

ファイヤーウォールとは2006年に公開されたハリソン・フォード主演のアメリカ映画で、
銀行に勤めるセキュリティエンジニアが、強盗に家族を人質に取られて、自ら構築したセキュリティを破るよう命令されお金があっちこっちに動いていく……
と、言った内容です。

コンピュータやインターネットが普及した現在、ハッキングを題材とした映画やドラマはたくさんありますが、どれもいまいち現実味がありませんでした。

ハッキングをパソコン一台いじってるだけで行うなんて不可能です。
ましてや、大企業や政府のコンピュータをのっとるなんてことになるとなおさらです。

でも、映画やドラマではそういった行為をサラッとやりのけてしまうのです。

インターネットに飛び交う情報は全て監視されていると言っても良い昨今において、完全なハッキング行為はもはや不可能なのではないかと思います。
システムに致命的なセキュリティーフォールが存在すれば別かもしれませんが、今の時代、大事な情報を管理する機関は堅牢な体制を築いているでしょうし。

そういった意味では、このファイヤーウォールという映画の内容は筋が通ってたように思います。
内部に侵入して、システムに精通しているエンジニアを脅迫する…
もはや、この方法しかないでしょう。

でも結局最後は犯人の野望は砕かれる…
今のサイバー犯罪の結末は全て、このように失敗で終わると思います。

ASP技術の違和感

ASP

ASP（Active Server Pages）によるプログラムの内容にどうしようもない違和感を覚えました。

「ウェブページを動的に作成する技術」をASPと呼び、プログラム言語というわけではないということだそうですが、ある構成に基づいたソースファイルを作成していくことになりますので、言語とも呼べなくもないような気がします。

そんなASPを使ったシステム開発に初めて携わることになり、ASPのサンプルコードを眺めていたのですが…
「何だこれ」と思わずにはいられません。

ソースの最初の方には、VBScriptでずらーっとコードが書かれており、次にJavaScript、そしてHTMLとCSSのコードがVBScriptに混ざって……

このような形で、ひとつのソースファイルの中に複数の言語が含まれており、プログラムの流れがまったく読めず、何をしようとしているのか見当がつかないです。

サーバーサイドのプログラム技術（言語）として、ASPの他にPerlやPHPなどもあり、世の中にはいろいろな技術や言語があるだなと、毎日学ぶことばかりです。

VB.NetからVB6プログラムの読み出し

Visual Basic

昔は業務系システムの開発をVB6で行うことが多かったようで、VB6で作成されたシステムは世の中に数多く存在しているようです。

そのためか、システムの改修作業などで、今でもVB6で作成されたシステムに触れる機会は多いです。
私も、入社して最初に触れたのはVB6で作成されたシステムでした。

VB6は古い言語ではありますが、ものすごく扱いやすく開発効率が高いすばらしい言語だと思います。

しかし、VB6は開発における全てのニーズに応えてくれるわけではありません。

最近携わっている業務に、データ読込処理と、データ表示処理を同時に行う機能を追加するという話が上がりました。
言語はVB6です。

この機能をVB6で実現しようとしても、恐らくできないと思います。
VB6では複数の処理を同時に行うマルチスレッド処理が仕様上不可能だからです。

言語仕様の問題となると私のような平凡なプログラマでは手も足も出ません。

といっても簡単に「できない」で終わらせられないのが仕事です。
そこで考えた解決案がマルチスレッド処理を必要とする部分を別の言語でDLLとして作成し、そのDLLをVB6からキックさせるといった方法です。

しかしこの方法、
呼び出し元、呼び出し先の双方のプログラムが、.NetFrameworkで作成されていれば、言語間のやりとりの壁はほとんどないと思うのですが、片方がVB6で作成したプログラムであったため、言語間のやりとりがややこしくなります。


VB6のプログラムからVB.NetのDLLを呼び出す手段としてCOMというしくみに着目しました。
COMを使うことで、とりあえず、マルチスレッド処理を実現できたのですが、ここでまた新たな問題が発生します。

COMを通してプログラムを呼び出すためには、DLLの情報をレジストリに登録するという作業が必要になることです。

レジストリ登録の方法としては、.NetFrameworkがインストールされている環境でregasmコマンドを実行することで行えるのですが、エンドユーザへの配布を考えた場合、この作業はインストーラの機能に含め、自動化させなければなりません。

そもそも、VB.Netが絡んだ時点で、インストーラに.NetFrameworkのインストール機能を含めなくてはならず、インストーラの組み直しは避けられません。

こうなってくると色々と工程が増えそうで、追加機能の必要性を考えるとあまり現実的ではないという考えになってきます。

結局、この話はなくなり事なきを得ました。


プログラマあるいはシステムエンジニアは、「できる」「できない」の判断を迫られることが多々あります。

しかし、簡単にできそうなことが実はものすごく難しかったり、とてもできそうにないことが実はものすごく簡単にできたりと、プログラムの実現可否の瞬時の判断は一端のプログラマにしかできない芸当だと思います。

このことはしっかりと念頭に置いておかなければならない、
今回はそれを学びました。

Webメールが使えない

セキュリティ

GmailやYahooメールなどのWeb上で管理されるメールサービスが会社で使えなくなりました。
どうも会社が制限をかけたようです。

最近、仕事で使う個人情報を家に持ち帰って、ウイルスによって流出するなんて事件が増えてますから、まあ間違いなくその対策としてやったのでしょう。

家に仕事を持ち帰ることの是非はともかく、あれだけ事件が多ければ大抵の会社は対策を取るのが普通なのでしょう。

しかしそういう制限をかけられると多少なりとも不便になるところもあるわけです。

そこで、その制限を破る……という言い方は語弊があるかもしれませんが、まあ必要なときに使えるようにする方法をちょっと調べてみました。

すると、WebProxyというツールを使えばいいようです。

レンタルサーバでもなんでもいいので、とにかくCGIを使えるサーバ上にWebProxyサーバをインストールしておき、今後はそのサーバ経由でインターネットにリクエストメッセージを送れば、社内のファイアーウォールをかわせるというわけです。

とりあえず参考までに調べただけで会社のファイアーウォールを突破しようなんて考えていません。
でも実際、破ろうと思えば破れるものなんですね。

最後は結局、倫理的な問題ということになると言えそうです。

ブログ始めます。

新米プログラマの日記ということで、このブログをスタートします。

プログラマとして働いていく中で、技術的な覚書や日々思ったことなどを日記形式で書き留めておこうと思ってます。

働きだしてまだ間もないですが、だからこそ、こういう場でそのとき思ったことを書き留めておく行為に意義があるのではないか、そう考えています。

それに、プログラムばかりパソコンに向かって書いてると息が詰まってきますからね。
まだまだ日々勉強の毎日ですが、こうやって文章として残しておき、あと何年かしたときこのブログを読み返すとまた新しい発見が期待できそうな気がしてます。
あの頃の自分はあんなこと思ってたのかーって、自分が自分で書いたことを笑いとばせる日が来るかもしれませんし。

働くということは結構辛いということがわかった今日この頃。
これはたぶんプログラマという職種に限ったことではないと思います。

これから先、私はどうなっていくのか…

将来自分を見つめなおすときが来たとき、そこまでの道のりをこのブログに残しておき、じっくり振り返ることができるようにしておきたいです。