「社内ブログ」と聞いて皆さんは何を思い浮かべますか。
別名「イントラブログ」と呼ばれる社内コミュニケーションツールなのですが、いろいろな活用方法があるんです。
・技術情報の共有
・プロジェクト管理
・トラブル対応履歴
・日報
・研修報告
・社長の日記
・社内ニュースの掲示
・新商品、新企画募集
・飲み会のお誘い
etc
活用方法の多さもさることながら、何よりブログだから、PCに詳しくない人でも簡単に運営できる点は、非常にポイントが高いのではないでしょうか。
ただし、いわゆるIT業界ではない職種の方にとっては、初期導入時に必要なサーバー設定やソフトウェアインストールは、負担が大きいです。
そんな「社内ブログは使ってみたいけど、サーバー設定とかよくわからない」という会社の方には、初期導入時の環境構築やソフトウェアインストールを実施する、『社内ブログ構築サービス』をお奨めしています!!
C#にも対応したObjectService.net(v1.1.0)がリリースされました。
ObjectService.netは、VisualStudio2005の開発環境に統合されるO/Rマッピングツールです。O/Rマッピング機能以外にも
■クラスモデリングから自動でテーブル生成
■クラスの継承に対応
■オブジェクトの履歴管理に対応
といった機能を備えており、オブジェクト指向開発による効率化を実現できる環境を提供します。
トライアル版がありますので是非一度お試しになってみてください。
なお、4月中に、VisualStudio2008対応のv2.0.0がリリースされる予定です。
既にVisualStudio2008を導入されているお客様は、今しばらくお待ちいただければと思います。
VB.NET向けO/Rマッピングツール「ObjectService.net」が
第17回ソフトウェア開発環境展に出展されます。
会期：2008年5月14日(水)～16日(金)
会場：東京ビックサイト
URL： http://www.sodec.jp/
会場に足を運んだ際には、是非ブースにお立ち寄りください。
ソフトウェアアーキテクトの仕事とは、アプリケーション開発の枠組みをプロジェクト単位で決定することだと思います。
うまくできあがった枠組みは、詳細実装の段階で、SEやPGの守備範囲を限定でき、プログラムの複雑度を一定の範囲内に維持することができます。逆に、詳細実装の段階で枠組みが崩れてしまうと、最初からやり直さない限り、人間の能力で品質を担保するのはかなり困難な状態に陥ってしまいます。プロジェクトの成否やプロジェクト参加メンバーの仕事量を決定付けるという意味で、非常に重要な役割になってきます。
建設業にたとえると、”基礎工事”にあたりますが、ソフトウェア開発はまだ歴史も浅く、ソフトウェアアーキテクトの仕事といっても明確に定まっていないのが実情ではないでしょうか。
プロジェクトを成功に導くためにソフトウェアアーキテクトがしなければならない具体的な作業として、下記の4つを考えてみました。
1)ビジネスオブジェクトのスケルトン定義
この段階では、主要オブジェクトが何を表し何がキーなのかだけ定義されればよいと思います。シンボリックなフィールドはプロトタイピングでも重要になるので仮で定義しておきましょう。
2)ビジネスオブジェクトの妥当性についての動作検証
作成したスケルトンオブジェクト群で要件を満たせるのかどうか、ラフな画面プロトタイプや遷移動作を作成して検証します。ER図は、いろんな視点で書けてしまうので、いくらにらめっこしても”これでいける”という確信にはなかなか至りません。動作するプロトタイプを自ら作成して、気になる部分を自分の目で確認して、確信を持てるようにすることが重要です。わかりきっている部分はスキップしながら、主要なオブジェクトのライフサイクル全体をチェックしておく方がよいと思います。また、この段階で開発メンバーの意見を仰ぎ、妥当な仕様かどうかフィードバックを得ることも重要です。
3)アプリケーションの整合性を決定付けるコアロジックの発見と実装
どんなアプリケーションでも枠組みレベルで見渡すと、複雑な部分(コアロジック)は実は限定されています。重要なのは、その複雑さが実装時にアプリケーション全体に分散してしまわないように設計することです。プロトタイピングを通じて、まず複雑さを生み出しているものが何なのか発見します。最初に作成したスケルトンではうまく動作しなかったり、コードが途中で書けなくなる部分がコアな部分であることが多いです。そこで、スケルトンを修正したり派生関係を見直したりしてコアロジックをなるべく単純に書けるようにスケルトンオブジェクトを再定義します。そして再定義されたスケルトンオブジェクトに基づいてコアロジックを実装します。
4)アプリケーション構造の分割
開発スタッフがフリーハンドで実装できないようにプログラミング上の制約となるベースクラス/インターフェースなどを作成しアプリケーション構造をいくつかに分割します。例えば、メイン画面(メニュー)/一覧画面/編集画面/ビジネスロジック”といった4分割にするために、編集画面は、必ず前もって作成しておいたベースクラスから派生し、保存時は直接”ビジネスロジック”を呼出すといった確認しやすいルールを定義します。ベースクラスは、前回のプロジェクトで使用したクラスを参考にしながら、プログラミングの複雑性を下げるために本当に効果があるのかどうかといった視点で、改良を加えて使用するようにしています。
アプリケーション構造の分割は、もちろん他の要素に基づいて決定することもできますが、サーバー/クライアント的な分割方法だとうまく行かないケースもあるので気をつけてください。
ソフトウェア開発の仕事は、困難な局面がつきまとい大変な感じもしますが、経験と工夫で必ず進歩していく分野だと思います。エンジニアの皆さんめげずにがんばりましょう。
VB.NETからSQLServer2005に接続したい場合に、例えば以下の処理で接続が可能です。
‘接続設定
Dim SqlCon As New System.Data.SqlClient.SqlConnection(”Data Source=SERVERNAME;Initial Catalog=DBNAME;User ID=sa”)
Dim SqlCmd As System.Data.SqlClient.SqlCommand = SqlCon.CreateCommand()
SqlCon.Open()
SqlCmd.CommandText = “SELECT * FROM SampleTable”
Dim SqlDR As System.Data.SqlClient.SqlDataReader = SqlCmd.ExecuteReader()
While (SqlDR.Read())
‘カラム情報を取得
End While
‘終了処理
SqlCmd.Dispose()
SqlDR.Close()
SqlCon.Close()
SqlCon.Dispose()
ただSQLをソースに直接書くと、抽出条件やテーブルレイアウトが変わる度にコードを修正する必要が生じるので、後々苦労することが多いですよね。私も「コードの修正に時間がかかって開発が進まない」なんていう経験をしたことがあります。
この記事を書いていて、改めて「ObjectService.netって便利だなぁ」と思いました。トライアル版がありますので、みなさんも是非お試しください。
ベースクラスとしてGenericForm(型パラメータを持つフォーム)を作成し、派生フォームをデザイナで編集しようとすると下記(一番下に記載)のようなデザイナエラーが発生し、デザイナを開くことができません。
「Type.ContainsGenericParameters が true に設定されているため、GenericFormSample.GenericForm`1 [objectType] のインスタンスを作成できません。 」
Googleでかなり検索してみましたが、この現象は、どうも既知の問題のようで、VisualStudio2005のフォームデザイナはGenericコントロール(フォーム)から継承したコントロール(フォーム)のデザインができないようです。
http://www.codeprof.com/dev-archive/39/2-5-396762.shtm
型パラメータを持つベースフォームがあると開発の効率化につながるので、いろいろ試したところ下記のような簡単な方法でエラーを回避することができましたので参考にしてみてください。
1)TypeCodeDomSerializerを継承したカスタムシリアライザを作成する。
Serialize/Deserializeメソッドをオーバーライドし、Formの標準のTypeCodeDomeSerializerにリダイレクトします。Serializeメソッド内でリダイレクトする前に、引数のdeclarationオブジェクトにダミーの型をセットします。
2)ベースクラスにカスタムシリアライザを関連付ける。
システムインテグレーションのためにシンガポールに滞在しています。絶好調な中国&インド経済の影響を受けているのかシンガポールでもちょっとした不動産バブルで、日本の停滞気味な雰囲気との違いが印象的でした。
ちょうど日本を発つ日の日経新聞に、”アメリカIT企業の売上に占める日本市場の比率が5%を割り込んだ“と書かれていました。新製品リリース時の日本語マニュアル作成などローカライゼーションの優先順位が下がってきていて、日本市場がだんだん後回しにされるようになっていくという内容の記事でした。
日本が世界経済の中で生き延びていくために、今まで以上に”英語”が必要不可欠なものになってきているのかもしれませんね。
VB.NETプロジェクトでユニットテストを行う際、エンジニアは、簡単なフォームとボタンを配置し、テストスクリプトを作成するケースが多いと思います。ただ、これでは他人が見ると何がテストされているのか意味不明で、労力をかけて作成したスクリプトも一時的なもので終わってしまいます。せっかくテストスクリプトを書くのであれば、開発チームでユニットテストツールを使用し、テストスクリプトを蓄積できるようにすると、リファクタリングや仕様修正時のデグレーション回避に効果的なのかなと思います。
下記は、最近社内用に作成した簡単なユニットテストツールです。なるべく少ないコードで、網羅的なシナリオを書けるように工夫してみました。
ユニットテストツールのダウンロード(ソース&サンプルプロジェクト)
昨年末にリリースされたObjectService.netの原型(ランタイム部分)は、2年ほど前、受託プロジェクトを進めるために社内利用目的で開発されました。当時、受託プロジェクトの後半で発生する要件変更が、整合性のとれていた当初の設計を劣化させてしまうことに悩まされていました。そこで、アジャイル開発(:シンプルな実装からはじめて修正を繰り返しながら実装を深めていく手法)を取り入れようとしましたが、VB開発は効率よく進む一方で、データベース部分は、やはり修正が何度も繰り返されると作業が煩雑になりうまくいきませんでした。データベース部分も含めてプロジェクト全体でアジャイル開発を実現するために、
■VBクラスの実装深化にともなってテーブルを自動修正できること
■フォームに直接バインドできるVBクラス(コレクションを保持)をロードできること
■VBクラスの派生(継承)に対応できること
を目的としてObjectService.netが開発されました。
ObjectServiceの開発自体はかなり難航しましたが、プロジェクトの実装部分ではオブジェクト指向開発を徹底でき、90%程度のSQL文を排除できました。エンジニアは、オブジェクトの構造や相関性に集中できるようになり、テストや修正開発も容易に進められるようになりました。アジャイル開発プロセスらしきものがようやく実現したのです。
完璧なO/Rマッピングを実現するのは困難ですから、SQL文が部分的に使用されることも想定して、自動生成されるテーブル構造は、極力ストレートに表現されています。原則はクラス名がテーブル名となり、クラスのパブリックプロパティがテーブルのカラム名となります。派生クラスに関しては、オブジェクトのKEYと派生クラスで作成されたフィールド(プロパティ)のみが生成され、SQLを書くにあたっても簡単にInner Joinでロードできるような形となっています。是非一度、トライアル版をダウンロードして試してみてください。
不慣れなPhp&MySQL&オープンソースと格闘すること3日間ようやくブログ&製品フォーラムの開設にこぎつけられました。最終的に採用したWordpressもBbpressもどちらもインストールは簡単なのですが、その他にもいろいろなオープンソースのブログ&フォーラムエンジンのがネット上に公開されており、どれがフィットするのか試行錯誤に時間がかかってしまいました。
さて、昨年末にVB.NET向けO/Rマッピングツールを製品リリースしました。これを機に.NET開発に関するトピックを積極的に情報発信していこうということになり、ブログを開設する運びとなりました。.NET開発に関連するツールやプロジェクト開発現場での工夫などいろいろな話題を提供していけたらと思います。
どうぞ本年もよろしくお願い致します。