オープンソース Archive

年末年始と、弁慶フレームワークばかりいじっていた訳ですが、その理由はVSUGコードコンテスト2007に応募するためでした。
勘の良い人なら気付いてたかな？

そして、本日VSUG事務局より入賞のお知らせが届きました。
日本オラクル部門ということで、大変名誉ある賞を受賞できて光栄です。でも、景品はWiiがほしかｔ

頑張っていれば、必ずいいことがあるということで、これからも自己研鑽に勤めていこうと思うのでした。

弁慶フレームワーク

弁慶フレームワーク1.1.0
小弁慶フレームワーク1.0.0
DAOGenerator 1.1.0
DAOGeneratorCE 1.0.0
を公開しました。

今回、弁慶フレームワークのドキュメントも公開しました。
どういう考えで作ればよいのか、まずはご覧ください。

2007/12/27のエントリで書いたように、弁慶フレームワークをバージョンアップしました。
今度のバージョンでは、OracleとPostgreSQLにも対応しました。
これにより、異なるデータベースを複数使うシステム（データ移行等が考えられそう）が、作りやすくなったのではないかと思います。

現在、ドキュメントを整備しておりますので、しばらくお待ちください。
今回のバージョンより、システムの説明が書いてあるHTMLヘルプがダウンロードできるようになります。

そして、小弁慶フレームワークも完成いたしました。
小弁慶は、SQLServer Compact Editionのみに対応しております。

が、しかし．．．
私のJASJAR i-mateで動作確認していたのですが、動作が滅茶苦茶重いのですよ．．．
２行しか存在しないテーブルのデータを、DataGridにBindするだけで、5秒以上掛かります．．．

どうやら、小弁慶の問題ではなく、SQLServer Compact Editionが重いようなので、どうにもならない気がします。
まあ、CPUパワーも無いですし。
こちらも、公開までしばらくお待ちくださいませ。

公開の準備が出来次第、このブログで告知します。

Windows Mobile 6 のスマートフォンを所有しているのに、全然使いこなしていないなあと気付いたので、.NET Compact Framework に挑戦することにしました。

とは言っても、特に作りたいものがある訳でもないので、弁慶フレームワークの Mobile 対応版でも作ってみようかと思っています。
上手いこと完成した場合、他のアプリ作成にも役に立ちそうですし。

プロジェクト名称は、Compact Benkei を略して CoBenkei 、漢字で書くと「小弁慶」と命名しました。
公開は1月以降になると思います。
ついでに、Benkei もソースの整理を行っているので、少しスリムになった形で次バージョンを同時に公開できると思います。

まだあまり触っていないのですが、.NET Compact Framework で気付いた点
・BinaryFormatter が存在しないため、DeepCloneObject クラスの実装が困難に。
・System.Data.Common 名前空間では、SQLServer Compact Edition は操作できないようだ。

いきなり深みにハマった訳ですが、なんとか完成までこぎつけたいと思います。

おおっ、と思うニュースでした。

マイクロソフト、.NET Frameworkライブラリのソースコード公開へ

　米マイクロソフトは10月3日（現地時間）、Scott Guthrie氏のブログで、.NET Frameworkライブラリのソースコードの一般公開を発表した。今年後半の、.NET 3.5／Visual Studio 2008（以下、VS 2008）のリリースと同時に公開する予定だ。

　初めは、ベースクラス（System.IO、System.Netなど）や、ASP.NET（System.Web）、Windowsフォーム（System.Windows.Forms）、ADO.NET（System.Data）、XML（System.Xml）、WPF（System.Windows）のライブラリから提供を初め、続けてWCFやWorkflow、LINQなども公開していくという。

　ソースコードは、マイクロソフトリファレンスライセンス（Ms-RL）で提供される。

　また、ソースコードはダウンロードしてエディタで閲覧できるだけではく、VS 2008における統合的なデバッグのサポートも予定している。

　たとえば、GridViewのDataBind()の呼び出しにブレークポイントを設定した際、従来までは、DataBind()内部での動きの詳細は確認できなかったが、VS 2008ではステップインで.NET Frameworkライブラリ中のコードもデバックできるようになる。［ローカル］ウィンドウや［ウォッチ］ウィンドウで変数を監視することも可能。また、.NET Frameworkのソースファイルは、必要に応じてデバッグ時にオンデマンドで取得するため、あらかじめ全てのファイルをローカルにダウンロードしておく必要はない。

　マイクロソフトでは、.NET Frameworkライブラリのソースコード公開とデバッグの統合は、.NET開発者にとって非常に価値のあることであり、よりよいアプリケーション開発の手助けをしていきたいとしている。

確かに、デバッグ中にライブラリの先が見たいときはありますよね。
今まではソースが無くてもなんとかなったので、必須という訳ではないですが、無いよりはあった方が良いですね。

弁慶フレームワーク
今回はテーブル型を返すストアドファンクションの対応です。
DAOGeneratorは、テーブルだけでなく、ストアドにも対応しているのですが、ストアドと一口に言っても色々なパターンがあるため、一カ所直すと他の所に影響が出たり。。。

Strategyパターンを使っておくべきだったと反省しつつも、今から直すのも大変なのでしばらくはこのままで行こうと思います。
もう少し品質が良くなってきたら、Oracle、PostgreSQL、MySQLといったあたりにも対応していくつもりです。

弁慶フレームワークのBinaryとHelpに、間違ったファイルをアップしていたため、再アップしました。

フレームワークのソース、DAOGeneratorは変更なしです。

ダウンロードしていただいた皆様、お手数をお掛けしまして申し訳ございません。

弁慶フレームワーク、DAOGeneratorを共に更新しました。

今回の更新は、スカラ値のストアドファンクションにDAOGeneratorを対応させることだったのですが、それに伴っていくつか不具合が出てきましたので、フレームワークを合わせて修正しました。

仕様変更ではなく、仕様追加と不具合修正なので、フレームワークを使用したプログラムもそのまま差し替えて使うことができると思います。

弁慶フレームワーク

Ver1.0.2のHTML Helpを公開しました。
今回はSandCastleの2007 June版で作成しました。

今把握している不具合

・Commandのタイムアウト値が指定できない
・CommandTypeが指定できず、プロシージャコールに失敗する
・スカラ型のストアドファンクションに対応していない

近いうちに直します。m(_ _)m

Source Forgeにて、弁慶フレームワークの最新版をリリースしました。

ASP.NETのセッションをタイプセーフに取り扱うクラスを追加しました。

ソースファイル一式

Higtyさんのオリジナル版はこちらから
[CodeZine]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成
[ひぐたぅん]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成

GW前に出来ていたのですが、アップロードを忘れていました（汗）

オリジナル版と比べて、抽象化しまくっているので構造は複雑になっていると思います。
中級者以上向けでお願いします。
あと、弁慶Frameworkに組み込むことを前提に作っていますので、namespaceは変わっています。
オリジナル版と比較される時は、そのあたりに注意してください。

実際に作ってみて、オリジナル版のシンプルさと使いやすさのバランスの良さを感じました。
弁慶Frameworkに入れるためとはいえ、ちょっといじりすぎたかもしれません。
ほとんどの場合は、オリジナル版の方が使いやすいんじゃないかと思います。

以下、説明

まず、Castクラスですが、オーバーロードを１つ増やしています。
で、オーバーロードしたメソッドを呼ぶようにしたことで、重複したコードが無いようにしました。
速度を重視すると重複して書いた方がいい訳ですが、弁慶Frameworkは速度をあまり重視していないので。
で、オブジェクトの型変換は、オリジナル版ではToStringでしたが、これだとDouble型のときに丸められてしまうため、普通(?)に型変換することにしました。
型変換に失敗すると、当然の事ながらExceptionが出ますので、呼び出し元で処理してください。
Exceptionを呼び出し元に任せるのも、弁慶Franeworkの考え方に合わせました。

肝心なSession操作ですが、機能と実装を分けています。
何故か？というと、NUnit等を使用するときSession操作が出来ないので、一時的にHashTableを使用するようにするためです。（というか、このためだけに面倒くさくなりました）
機能と実装を分けたことで、一時的に実装部分を差し替えるという訳です。
この差し替えサンプルについては、NUnitのテストクラス（SessionValueTest）を見てください。

Form、QueryStringも大体同じです。
ViewState、Cockieは、あえて操作クラスを作る必要性が無いような気がしたので、今回は作ってません。

セッションを扱うクラスまで、とりあえず完成しました。
あとは、Coockie、QueryString、ViewState用クラスを作ったところで、アップしようと思います。
公開後、特に問題も無いようでしたら、弁慶フレームワークに入れたいなと企んでいたり。

緊張性頭痛が再発してしまったので、ペース落ち気味です。
期待してらっしゃる方がいたら申し訳ありませんが、もう少しお待ちくださいませ。

オープンソースを作っていると言うと、「それってお金になるの？」と、よく言われる訳ですが。

・理由

オープンソースを作る理由は人それぞれで、ある人はお金儲け（独自のビジネスモデルに基づく）だったり、ある人は趣味だったり、ある人は修行だったりと様々です。

私の場合は、最初に就職した会社でリストラに遭い、仕事を失いかけていたところを多くの人に助けられ、これまでやってこれました。その際、多くのチャンスに恵まれ、多少なりとも技術と経験を積むことができたので、これをなんらかの形で世の中に還元したいなという気持ちがありました。

・環境

エンジニアを取り巻く環境は、一昔前より悪化していると言えます。
受注額の下落、短期間開発で受託開発は疲弊し、多くの企業は安易な偽装請負（※ 犯罪です）に手を出しています。
建築業界と同じ、請負のピラミッド構造になっているため、しわ寄せは末端のエンジニアにやってくるのです。
エンジニアは休むことなく、プロジェクトをたらいまわしにされ、スキルも身に付かないうちに転職を繰り返します。
そして、これが悪循環となっていきます。

この状況を変えることは簡単ではありません。
まずは経営者から末端のエンジニアに至るまで、現状を知る必要があります。
そして、それぞれの立場から、この負のスパイラルから抜け出す方法を考えなければいけません。
多くの経営者は、優秀なエンジニアを重要なポジションに置くことを考えますが、これは短期的な効果しか見込めない場合が多いようです。
長期的な視点から見た改善は、全体のスキルを底上げすることと、工学的なアプローチに基づいた生産手法の確立等の戦略上にあると考えられ、属人性の排除を前提とします。

弁慶フレームワークの自動生成機能は、このような環境を改善する一つの手段として考えたものです。

・ビジネス

最初の話に戻りますが、儲かるのかどうかというと正直儲かるとは思いません。（ほとんど趣味だし）
でも、それでもいいと思っています。
極論から言うと、弁慶を使ってくれなくても、理念を理解してくれて、少しでも環境が良くなる人がいるのならそれで良しとしたいと思うのです。
万が一にもビジネスに繋がるようなことがあれば、それはそれで嬉しいですけど。

DAOGenerator1.0.1をリリースしました。

ストアド用のAccess、Entityを作成するときに細かい不具合がありましたので修正しました。
弁慶フレームワーク自体は1.0.1のままとなっています。

リクエストのキューイングの記事で、ConfigGeneratorと宣言していたものです。
Configファイルを作成するだけでなく、Controller、Commandクラスのスケルトンを生成できる機能まで付けたので、名前を変更しました。

DAOGeneratorと同じく、弁慶フレームワークを使っているため、動作サンプルのコードとして研究目的で使うこともできます。

※　Configファイル、Controller、Commandクラスはこのツールを使用しなくても、手打ちで作ることもできます。（面倒くさいですけどね）
※　弁慶フレームワーク自体は1.0.1のままとなっています。

というか、作ってあったのですが公開忘れてました orz
公開したバージョンは1.0.1用です。
1.0.0版は作ってませんが、大体同じなので勘弁してください。

namespaceのヘルプが作成してないですが、気にしないでください（滝汗）
次のバージョンではちゃんと入れるようにします（ナイアガラ滝汗）

弁慶1.1あたりで、リクエストのキューイング機能を入れようかと思ってます。
現状のままだと、リクエストの投入だけしたいという場合に独自実装が必要なんですが、キューイング機能を加えることでより作りやすくなると思います。

頭の中ではもう出来ているのですが、優先順位的にConfigGenerator、ドキュメントを優先したいので後回しにします。
実質１人で作ってるので、なかなかマルチタスクで作るのは難しいです。

なんとか1.0.1をリリースできました。
ついでにDAOGenerator1.0.0もリリースできたので、よかったらダウンロードしてみてください。
次のリリースでbenkei.config、コントローラクラスを生成するツールを作る予定です。

https://sourceforge.jp/projects/benkei/

TeraStationが故障したりとか、TeraStationが故障したりとか、TeraStationが故障したりとかでトラブル続きで作業が遅れていた訳ですが。

本日ようやく完成にこぎつけました。
機能としては、
・SQLServerからテーブル情報、フィールド情報を取得して、その情報を基にソースコードを自動生成する。
・SQL文からソースコードを自動生成する。
の２点です。

このDAOGeneratorを使うことで、C#の開発がよりスピーディー、高品質になることを願っています。
現在はC#だけですが、VB.NET版も開発予定ですし、対応DBもPostgres、MySQL、Oracle、DB2あたりまで対応させたいなあと思っている次第です。

公開はドキュメントを少し整理してからとなりますので、もう少しお待ちください。

TeraStationが壊れたので、開発できる状況じゃなかったり．．．
今月中にDAOGeneratorをリリースする予定だったんだけどなあ．．．

弁慶のソースはYahoo ブリーフケースに入っているので、ダメージが全くなかったのが救いです。
（昔作ったフリーソフトのソースなんかは全部消えちゃいましたが．．．ぐはあ）

弁慶フレームワークを使う開発のポイントなんですが、自動生成を多用し、生産性と品質を向上させるところにあります。
フレームワークの設計段階から自動生成されることを想定しており、これは揺らぐことのないポリシーと言えます。
特にシステム開発の大部分を占めると思われる、データベース操作についてコードを自動生成することは意味が大きいでしょう。
作成されるクラスは、テーブルと１対１で結びつけるテーブルオブジェクトを使うため、O/Rマッピングを使用しない方法を取ります。
O/Rマッピングは時代の流れではありますが、旧システムのリプレース等、データベースの再設計を行わない場合はテーブルオブジェクトの方が開発スピードが向上すると思います。
また、O/Rマッピングに比べて、インピーダンスミスマッチを考慮する必要がないので、オブジェクト指向初心者でも入りやすいのではないかと思います。

12/29に弁慶フレームワーク1.0.0をリリースできたので、次の公開は自動生成ツールを予定しています。
プロジェクト名は「DAOGenerator」となります。

弁慶フレームワーク

SourceForgeで申請が通ったので、ver1.0.0を早速アップしました。
まだまだこれからのプログラムなので、興味のある方は遠慮なく触ってみてください。

メンバーとして開発に参加してくれる方も大歓迎です！

OSBC開幕--オープンソースの次のチャンスはアプリケーション分野に

これも少し古い記事なんですが。
最近、オープンソースでなにかビジネスができないかなあと思っているのですが、やはり業務アプリですよね。
sugarCRM、Compiereなんかの出来を見ると、とても無料で使用できるとは思えないほど。
まだ日本では高い商用アプリを導入するのが主流なんですが、今後徐々にオープンソースが普及していくんじゃないかな。
うまいことやると高い利益率が出そうな分野だと思います。

現在作成中のプロジェクトを「弁慶フレームワーク」でSourceForgeに申請しました。
さてさて、どうなることやら。

これはほぼ固まったと言える階層図です。
弁慶ではビジネスロジック層、データベース層を対象にしています。

とりあえず主要なクラスだけでもと、クラス図にしてみました。

さすがにソースだけ公開する訳にもいかないので、以前書いたフレームワークのクラス図を修正してるんですが．．．

ああ、クラスを２つほど作り忘れてる．．．．
見なかったことにしよう。

弁慶のライセンスはGPLライセンスにしようかと。

どこかで見かけた言葉なんですが、「美しい物は永く残る」って言葉がありまして、結構気に入っていたりします。
プログラムも似たようなもので、美しいアーキテクチャは永く用いられることでありましょう。
※　弁慶が美しいかは別の話

このGPLも永く用いられてきたライセンス。
永い物にはそれなりの理由があるのです。

大体完成しました。

単体テストクラス（NUnitを使用）は、面倒くさくてあまり作ってないのがちと問題。
仕事で作るテストクラスは、やりすぎなくらい作ってるんですけどねえ．．．

フレームワーク名は「弁慶」に決めました。
年内公開の方向で。

フレームワークのデータベースアクセス部分だが、J2EEパターンで出てくる「DAOパターン」を採用することとした。

データベース操作については、特にコーディングをしないでも、テーブル構造合わせて自動的に処理させようと企んでいたのですが、どうやら破綻してしまったようだ。
SQLが固定でパラメータクエリで実現可能な一般的な操作（PKに対する検索、全件取得、追加、更新、削除）は普通に実装できたのだが、問題は動的にSQLが生成されるようなときに自動化はちと難しいのです。

解決策として最初に考えたのは、条件部分をDecoratorクラスで実装する案。
実はこれは上手くいったのですが、どうも美しくない。
複数クラス間にSQLが分散されているため、メンテナンスが容易にできないだろうと。

そこで、自動生成そのものを見直すことにしました。
今まではオブジェクト生成時に自動生成していたため、生成されたSQLに手を入れることはできず、実行直前に文字列の置き換え処理で対応していた。（置き換え処理はIn句対応で実装済みだったが、本来の意図とは違います）
これを、実行する直前まで遅らせることで、条件にしたがってSQLを自由に構成できるようになった。
同じSQLを実行する際に毎回SQLを生成するようになってしまったが、気が付かなかったことにしようっと。

Javaエンジニアから.NETエンジニアに転向して感じたこと。
それは、アプリケーションフレームワークがほしいなあということでした。

Spring.NETとかあるようですが、なんか説明を読んでいて面倒くさくなってしまった。
個人的な感覚ですが、どうもSpringは発想が私とは合わない（Springが悪いという意味ではありません）気がするし。
それなら作るしか！と最近考えています。

大体、こんな感じになります。
・オープンソースで晒します
・無料ライセンスでＧＯ！
・技術的な敷居が低いこと
・シンプルだけど拡張性が豊かなこと
・コードの多くを自動生成できること
・制限事項が少ないこと（最重要課題）

最重要課題の「制限事項が少ないこと」は非常に難しいところです。
作りにこだわったり、機能を増やしていくと、想定していないような制限事項が出てくることがあるからです。
まずはとりあえずのフレームワークを作成し、それを利用した別プロジェクトをどんどん作っていこうかと思っています。
仕事で実際に使えるような人事システムとかそういうものを作っていくことで、フレームワーク作成で見えてこなかった部分が見えてくると思うからです。
最終的には企業内で必要となるシステム全部（は言い過ぎか）を作っていけたらとか考えています。

既に開発はスタートしているので、製作状況をどんどん伝えていこうかと思っています。