年別アーカイブ: 2010年

47件の投稿

XSLT

WEB プログラム

VB6プロジェクトのバージョンアップは目処がついてきました。
ただし、今回ACCESSを使っているのでLINQを十分に活用できなくて、大部分はADO.NETを使用することになりそうです。

この作業そのものが、本来の仕事から外れているのですが、さらにWEBの作業が入ってきました。
ある団地が古くなってきたので、故障箇所を写真にとって、条件に応じて画像を表示するというものです。
現在は200程度の画像ですが、将来はもっと増えると思います。

10年近く前にXSLTの勉強をしました。XSLTは何故か気に入っています。手続き型のプログラムではなく、宣言型のプログラムですが、プログラミングがパズルを解くような感じでうまくいくと快感です（パズルみたいなせいか、忘れるのも早いように思います）。

画像にコメントや複数のフラグ（例えば[外壁]とか[屋上]とか）をつけて、それらのフラグに応じて該当する画像を表示します。
ACCESSのフォームをつくり、各画像に対するコメントやフラグを付けていって、そのデータテーブルをXMLファイルとして出力します。
列名に漢字を使うとXML文書が文字化けするようです。
ブラウザで検索条件を入れる仕組みを作り、サブミットでこのXMLファイルをXSLT変換をして所定の場所に出力します。

XMLに対するXSL変換はほとんどの（多分すべての）WEB言語がサポートしています(PHPでもPerlでもOK)。
今回はWEBサーバーに依存しないJavascriptを使います。変換のプログラムは大したことではなく、XSLTをどう作るかが中心的な仕事です。
先にも書きましたが、XSLTを雰囲気は覚えていますが、細かいことはすっかり忘れています。
これもばたばたとやっつけたいと思います。

リファクタリング

プログラム

Windows95以前のプログラミング環境（汎用コンピュータもUNIXもMS-DOSも）、CやFortranのプログラムでは、変数名の長さは8文字以内の英数字に制限されていました（後でしらべたらCの変数名の長さ制限は31文字でした。昔のことはどんどん忘れます）。
ルーティンが大きくなったり、グローバル変数が多くなると、変数名の命名規則をしっかりしていないと、変数名が足りなくなります。
そのためどうしても意味の無い規則的な変数名になります。

Visual Studioの開発環境になって変数名の長さに制限がなくなり日本語も使えるようになりましたので、変数名の命名が容易になりましたが、その分変数や関数の命名がぞんざいになりがちです。

まだ冬の並木です
まだ冬の並木です

コーディングについては、Steve McConnellの[コードコンプリート]は示唆に富んだとてもいい教科書です。
だけど、それはそれとして、それも鵜呑みにしないで自分流の命名をしたい([コードコンプリート]は英語でのプログラムを想定しているので、大文字と小文字の使い分けを利用しているが、日本語ではそうはいかないから、[コードコンプリート]を100%踏襲できない理由でもある)。
さりとてもちろん無機的で規則的な名前にしたくない、という気持ちがあります。
しかし結果として未だにいい命名ができなくて、はっきり言って統一性のないコードで、ブログでひと様にお見せできるようなコードではないのですが、恥を忍んで仕組みとしてのコードをこのブログでご紹介しています。

さて、そんな中でとても重宝しているのがVBプロパーのリファクタリングの機能-変数名、関数名等の変更用の[名前の変更]です。
またVBでは[DevExpress]の[Refactor!]が使えます。
[Refactor!]では、メソッドの引数並びの変更や変数宣言の位置の変更ができます。
メソッド名、コントロール名、変数名等をどこか一箇所で変更すると、プロジェクト全体にわたって変更してくれます。
同じく引数並びを変更すると、プロジェクト全体で変更してくれます。
これだけでもコードを見やすくするにはとてもありがたいツールです。

VB6プロジェクトのアップグレード 2

プログラム

今月は一度もブログを書いていません。

VB6のプロジェクトを書き換えています。
書き換えでは、[LINQ to DataSet]を使う予定でしたが、結局それらしいコードは余りありません。
私は、同じコードをコピーして使うのが極端に嫌いです。
プログラミングの経験者は分かると思います。
通常プログラムは一度で完成することはないですから（余程時間と金に余裕があって、設計を存分に練ることのできるプロジェクトなら別ですが）、
プログラムの中でコピーコードが何箇所にもあるると、修正が入るたびにそれらのコピー部分を毎回修正する必要があります。
コピーコードをあちこち直し歩くことを考えると、一箇所にまとめてそれをブラッシュアップする方が余程いいのです。
そんな訳でできるだけ汎用的なコードを書きたいのです。
LINQは基本的に型づけされているので、汎用的なコードを書こうとするとうまくいきません。
[LINQ to Entity]では解決策を見つけたのですが、[LINQ to DataSet]では分かりません。

というわけで、LINQではなくADO.NETのコードが多くなります。

今取り掛かっているプログラムは多く見ても2万行程度だと思います。大急ぎで一度書き換えたいと思っています。
VB6のプログラムはクラスを使っていませんので、.NETでカプセル化してOOP風のコードにすると結局全面的な書き換えになります。

ビジネスロジックは基本的にはそのままにします。今月一杯には目処をつけたいと思います。

LINQ to DataSet

LINQ プログラム
[LINQ to DataSet]については、VS2008のドキュメントにかなり詳しく書かれています。

話は変わりますが（突然）、あることについて初めて勉強するときに、コンピュータ画面は不向きだと思います。
ちょっとしたことを調べる、あるいは大体は知っていることについて確認する場合は、画面の方がいいかも知れません。
コンピュータの新しい技術を勉強するとき、一度流して読んだだけでは理解しがたいときが間々あります。
この場合以前読んだ部分を何度も読み返しことになりますが、この読み返す操作では画面は大変カッタルク、書籍がはるかに勝ります。

そんな訳で[LINQ to DataSet]のVS2008のヘルプは、初めての勉強には不向きです。


以前紹介した[murach’s ADO.NET 3.5 LINAQ and the Entity Framework with VB2008]が入門としては最適（私の持ち合わせの中では）だと思います。ここでは[LINQ to DataSet]に一章を割いていて、概要を知るには最適だと思います。

さて、最初VS2008のドキュメントで手探りでVB6のバージョンアップのコードを書いていたのですが、murach’sを読んで大きく間違ってはいなかったと確認しました。

VB6プロジェクトのアップグレード

プログラム

「VB6+ADO」のプロジェクトがあります。

Vistaではうまく表示できない部分があると報告がありました。
「Windows 7」でうまくいけばそれでもいいのですが、どちらにしても書き換えの時期がきたようです。

悪いことに（？）このプロジェクトはAccessを使っています。
このプロジェクトは「Access+.NET」ではどのようになるか検討を始めました。

まず、VBのアップグレードウィザードを使ってみましたが、エラーがいっぱい出てきて、それをを修正していくのが大変そうなので早々にこのウィザードを使うのを断念しました。

ところで私は「LINQ」を気に入っています。
なぜ「LINQ」がいいのかまだ十分分かっていませんが、理由は多分データのセットに対してSQLが使えることだと思います。

例えばList(Of T)に対して従来の技術のみである種の演算をしようとするとそれなりの工夫が必要です。
「ソート」やある条件のデータの合計を計算する等それなりのコードが必要です。

ところがこれらは「Linq」のSQL構文を使えば簡単に処理できます。

さて、「Linq to Entity」は「Access」をサポートしません。
将来の不安もあるのですが、「Linq to Dataset」を検討しています。
私は、「ADO.NET」は使ってきたのですが、数年前に発表された「TableAdapter」は将来性を見てからにしようと考え、使わないできました。

「データソース」作成ウィザードをつかうと、簡単にデータソース(データセット?)を作ることができますし、ここでつかわれている技術は(多分)「TableAdapter」だと思います。

ウィザードで生成された「TableAdapter」を使ってデータソース(データセット?)にDBデータを読み込みますが、このデータはLinq構文を使ってクラスのリスト-List(Of T)-に変換でき(そもそも読み込まれたデータはクラスの集合かもしれません)、したがってこのListに対してSQL演算が可能です。

まだ、十分の調査ではありませんが、「多分使える」、「なかなかいい」という印象を持っています。