年別アーカイブ: 2009年

42件の投稿

LINQ をどうするか

O’Reilly の[Programming Entity Framework]の9章まで読んで、開発途中のプログラムをLINQで書き換えています。[LINQ in Action]と2冊の拾い読みでは、なかなかスイスイとLINQは使えません。実際書いてみるといろいろな問題が発生します。

これまでADO.NETを使って、DBとは非接続で作業をしていました。LINQは遅延接続でむしろ「非接続の時間を少なくする」というコンセプトのように思います。既存のプログラムを大幅に書き換えないで、LINQの長所をどのように取り入れるか。

また、単純なことですが、クエリであるテーブルを使用したとします。LINQ to SQLやLINQ to Entity Framework のWizardを使うと、テーブルに対応したクラスが自動的にプログラム内に作成されます。
別のクエリーで再度そのテーブルを使用しようとすると、すでに最初のクエリでそのテーブルに対応したクラスがありますので、クラスの再定義になりエラーになります。逃げる方法があるのか。

このように検討しなければいけない問題が多々あります。
必要に応じて文献等を読み返し、実務に沿って勉強していきたいと思います。

[プログラミング LINQ]は訳が悪いし、[LINQ in Action]は話題が少し古い。[Programming Entity Framework]は解説書としては余りにも不親切です。新たに[Murach’s ADO.NET 3.5, LINQ, and the Entity Framework With VB 2008]を注文しました。勉強する情報としてはこれらとオンラインヘルプで充分でしょう。

LINQあるいは[Entity Framework]そのものの学習は当然ですが、新しいコンセプトによる技術はそれなりの「癖」がありますので、これを使いこなすとなると、この習得には少なくとも後1ヶ月はかかるだろうと予想しています(たぶん甘い)。

ADO.NETでも、従来のデータベースプログラミングと大きく異なりましたので、これを使いこなすまでに半年程度かかりました。
ADO.NETは、David Sceppaの[プログラミング ADO.NET]で勉強しました。何か不満が残る本です。「要所をキッチリ押さえていない」と感じました。

予断ですが、Visual BasicのFrancesco Balenaは100%信頼しています。とても要領よく的確に解説します。VB6の解説書から3つのシリーズを買いました。「頭のいい人なのだろう」と勝手に想像しています。この人の解説書なら出版されれば文句なく即座に購入します。

建築設計とソフトウェア開発

ソフトウェアの信頼性をどのようにして確保したらいいのかという議論がされ始めた時、そのお手本を建築設計に求めたと思います。

オランダのダイクストラが”Structured Programming”(日本語訳「構造化プログラミング」)を提唱したのは1960年代のことです。
彼のなんと言う本だったか、私も買ってかじりつきましたが、記号論理学や数学基礎論等を使って色々な証明をしていました。せいぜい200ページ程度の本でしたが、私には難しくて最後まで読むことができませんでした。
それはともかく、ダイクストラがどの程度建築設計の方法論を意識したかは知りませんが、少なくともタイトルに建築を想起させる「構造化」という用語を使用したのは、象徴的であったと思います。

建築設計は数千年の歴史をもちます。建築設計の方法論は古くて新しい議論です。
通常、建築では施主からの要求条件が出されると、まずエスキース(スケッチ)という段階で基本的な案を練ります。次の段階は基本設計です。建物の基本的な配置や形状が決定されます。続いて詳細設計で必要な詳細図を書きます。更に工事にかかると、実施図を書き、これを見て職人が仕事をします。建築設計では、設計の後戻りはありえません(もちろん現実にはあるが、それはあってはいけないことです)。

ソフトウェア設計の研究者は、このような建築設計の諸段階も研究したと思います。開発手法として最初期に提案された手法は、建築の設計手法と同じく後戻りしない手法で、後にこれをウォーターフォールといっています(建築設計とソフトウェア開発では、何かの違いがあると思います。ウォーターフォールの欠点が指摘され、最近のアジャイル開発まで様々な提案があります)。

またオブジェクト指向プログラミングの時代になって、デザインパターンの提唱がなされましたが、この原案は建築家のクリストファー・アレキサンダーがやはり1960年代に提唱したものです。

建築もソフトウェアもゼロから「もの」を作る創造の世界です。
似たところが沢山あります。しかし、決定的に異なる部分があります。建築設計は視覚的です。設計図も図面という視覚的な媒体を使いますし、建築そのものも視覚的です(もちろん物的、空間的です)。ソフトウェアはIDEを通して視覚化できますが、それはソフトウェアの一側面を表示しているだけです。ソフトウェアの本質はロジックで、基本的には設計者(あるいはプログラマ)の頭脳の中で構築していきます。

建築設計での図面のミスは、ベテランの技術者であれば、即座に指摘することができます。
しかしソフトウェアでミスを見つけることは大変難しい作業です。

人間の視覚によるパターン認識は、ロジックによる認識の何十倍何百倍も強烈です。そこに建築設計とソフトウェア開発の根源的な差異があるのだと思います。

建築の方法論では、たぶんに恣意的な面があり、人によってその解釈に差異が生じます。デザインパターンは建築の分野では、話としては分かるが広く明快に理解され、普及したわけではありません。

その点ソフトウェアのデザインパターンは、明確に定義づけられ、それなりに役立つ手法になっています。

Programming Entity Framework

ブツブツ文句を言いながら[Programming Entity Framework]の7章まで読み進みました。この本のいいところは、VS2008SP1に沿ってEntitiy Frameworkを解説している点です。7章ではリアリティのあるビジネスモデルを設定して、8章以降でこのモデルを操作します。

ウィザードを使えばEDM(ADO.NET Entity Data Model)を容易に作ることができますが、実際に使うには相応の調整が必要のようで、その意味ではこの本の解説は貴重です。

「16章(約500ページ)までは読みたい」と思っています。現在150ページを過ぎたあたりですので、先はまだまだです。

.NET Framework3.5でC#とVBの言語拡張がありました。これもよさそうなのでボチボチ使いたいと思います。

LINQあるいは[ADO.NET Entity Framework]

そもそもLINQあるいは[ADO.NET Entity Framework]はこれからどうなっていくのでしょうか。
[ADO.NET Entity Framework]に対して、多くのテスターが不信任を出しています。
http://japan.zdnet.com/sp/feature/07microsoft/story/0,3800083079,20376043,00.htm

それでもマイクロソフトは[ADO.NET Entity Framework]の開発を進めていくそうです。
[ADO.NET Entity Framework]のいい解説書もない中、今この技術に飛びつくのは得策でしょうか。
もう少し時間がたてば答えがはっきりするでしょう。

いまそのことは横に置いて、勉強中の私がこの時点で理解している限りで、この技術の俯瞰図を描いてみようと思います。

リレーショナルデータベースの問い合わせ、変更等の操作の方法として、リレーショナルDBが考案されて以来SQLがあります。SQLはデータベースを直接操作します。

ADO.NETでは、DBとの非接続の技術が導入されました。すなわち、一度プログラムでメモリ上(Dataset)にデータを取り込んで(DBの接続を切断し)、その後でまとめてDBに返す方法です。これもアプリケーションプログラムでDBを直接管理します。

[ADO.NET Entity Framework]でも直接DBを操作する方法は残っていますが(EntityClient)、その上にビジネスロジックのEntityを操作することでDBそのものを操作をする方法が提案されました。
その操作手段として、まずEntitySQLというT-SQLに似た文字列式があります。EntitySQLはこのどちらのレイヤでも動作します。

これに対して[LINQ to Entity]はいわゆるLINQ構文で、VS2008ではインテリセンスが作動しますし、コードの生産性は非常に高まると思われます。

私は[ADO.NET Entity Framework]についてはまだ初心者ですが、自分で書いてみると、ADO.NETで一つのクエリを発行するのに、コネクションを開き、データセットを定義し…とかの前準備が沢山必要であることを考えるといかに少ないコードですむかということを痛感します。

細かいことはまだわからないことが多々ありますが、(プロジェクトによっては)十分使う価値があると思います。

Dell Studio 540

注文したDell Studioが11日届きました。予定では2週間となっていたのですが、1週間余りで届きました。
中国で組み立てて、船便で送るようです(ついでですが、サポートも中国?)。

それにしても、Amazonも2週間とかの予告で、「しょうがないか」と思っていると、予想より早く来ます。
アマゾンで一度、待っている間にキャンセルしたことがありましたが(勿論合法的、悪意なしです)、いまこれらの会社はキャンセルさせないように早く送っているのでしょうか。

Studio 540(HDD 500G)でパーティションを自分で切り替えました。大した問題はありませんでした。
一点を除いて満足です。
一点とは、解像度が1440 * 900 より大きく出来ません。
原因はCPU切り替え機を使っているのですが、このケーブルがVGAなのです。切り替え機がいけないのかVGAがいけないのか分かりませんが、ともかくうまくいきません。DVIでディスプレイと直接接続すれば問題ありません(VGAでの検証はまだしていません)。
なんとか解決したいのですが…。

これまで、メーカーのコンピュータを余り買いませんでした。
自由に改造をしたいから、最初から自分で組み立てていました。

しばらく自分で組み立てていなかったので、今組み多立てるとなると少し勉強をしなければなりません。
今回は、時間をとられたくないし、面倒だと思ったからDellに発注しました。

解像度の問題を除けば、このコンピュータには満足です。
その理由の第一は、音がほとんどしないということです。

これまで自分で組み立てると、電源に金を使っていないので、ファンの音が大きく「こんなものか」と諦めていたのですが、やはり少し余裕をもってコンピュータを作らないといけないと、変に納得しています。

ところで、DellのHPをみていたら本体1万5千円のコンピュータが出ていました。
一般ユーザには充分です。

環境が整ったので、Entity Frameworkの勉強を早くして、開発に邁進したいとも思います。