2010年03月10日

ADO.NETでの注意

昨年春ごろから、SQL Server を使ってサーバーアプリを構築しています。
普段はクライアントサーバー方式で、サーバーはオラクルデータベースのみを設置するような方式をとるのですが、
この案件では SQL Server を使用し、サーバー側で処理をするプログラムとなるので、全然方式が違います。

まずは、サーバーのプログラムはサービスにする必要があります。
サービスとは、Windowsが起動すると同時に動作するように設定されたプログラムですが、メニューにあるスタートアップ
などと違い、デスクトップを表示しなくても動作する内部プログラムです。

もしサーバーが再起動したときでも画面にログオンしなくても動作するので便利です。
というより、サービスにしないとそもそも使い物になりません。

そしてクライアントや外部からのイベントをもとにデータベースにアクセスし、追加や検索を行ってクライアントに返します。

この場合、処理にスレッドは使用しません。
スレッドを使用するとよいように思えますが、クライアントからのアクセス数が確定できないものなので、いくらでもスレッドで
要求を受け付けるのは大変危険です。
ですので通常のイベントドリブンでマルチ的に動作する仕組みになります。

そうすると気になるのがデータベースへの排他制御です。
同時に同じレコードへのアクセスが発生した場合は、それが原因でデータベースの不整合が発生する可能性があります。

不整合の発生する原因としては
 1.レコード番号などのユニークキーが重複する
 2.同一レコードの更新処理がかぶる
ということがありますが、回避方法があります。

1は、SQL Serverであれば、IDENTITY というプロパティがありますので、これを使用してINSERTしたときにOUTPUTで追加した番号を取得する方法があります。
もしこれはオラクルであれば、SEQUENCEを使う方法とか、SELECT - FOR UPDATE などを使ってレコード情報を管理することで回避が可能です。
こういうオプションはSQL Serverにはなく、やはりオラクルは便利だと思いました。

2は、処理的に同じレコードのデッドロックがかかる処理が発生しないような設計にします。
特にサーバープログラムでは、そのプログラム1つだけでデッドロックがかかるので非常に厄介なので、絶対に発生しないような構造が必要です。

と、このように処理を作成していたのですが、どうも動きがあやしいところが出てきました。
そうして色々と解析しているうちに、ある重大なことに気がつきました。

SELECTの記述に、ADO.NETのDataReaderを使用していたのです!!

DataReaderは、1つのコネクトに対して1つしか使用できないという制約があります。
ふつうのクライアントアプリでは問題ないのですが、マルチで動作するサーバー側アプリなどでは、他の処理でDataReaderで処理をしている最中に、別のdataReaderは動作できません。 (いったんクローズしないといけないのです!)

理由は簡単で、DataReaderは現在よみとっているレコードのポインタとそのレコード1行のデータのみメモリに読み込む方式だからです。
そのため、メモリを占有しないので大容量のデータを処理するときに用いられます。

ということで、DataReader記述をすべて DataAdapter/DataSet 記述に変更しました。
よく考えてみればこの処理では、データ結果がほぼ1件しかかえって来ない検索でしたので、この方式で全く問題がなかったのです。

サーバーアプリですと、デバッグログもなかなかチェックしにくいので、私はデバッグログ自体もデータベースに出力するようにしています。
こういうときにも、DataReaderを使用していると、オープンからクローズの間は別処理が行えませんので、ログも吐き出すことができなくなりますので、できる限り DataAdapter/DataSetに変更するのが望ましいといえますね。

posted by ミーズシステム株式会社 目面 秀信 at 09:37| Comment(0) | TrackBack(0) | プログラミング

2009年07月24日

PHPでの開発とブラウザの種類

PHP開発で「しまった!」ということがあった。

客先でデモをしたときのことでしたが、客先は XP で ブラウザは IE6 を使っています。
そうしたら、スタイルシートでの表示部分がずれて表示されています!!

「ありゃーーー!! デザインが台無しやん!?」

実は私の開発環境はIE8、及び Google Chromeです。

おそらくバージョンの違いということで、帰社してから調べてみると、IE6以前では正常に
表示されない設定のようでした。。

こう考えると、頻繁にバージョンアップされるブラウザ競争の度に、その検証環境を作っていかないといけないのはとても大変ですね。。

せめてIEだけでも表示は統一してほしいものです。 こちらはWindows Vista環境なので、IE6などはインストールできません。 かといってその為にXPを1台用意するのも・・と思っていたら、こんなソフトがありました。

IE Tester (インストール時に Japanese を選択するとよいです)
http://www.my-debugbar.com/wiki/IETester/HomePage

このソフト1つで、IE5.5 と IE6、 IE7、 IE8 の表示テストが行えます!!

※このソフトでチェックしたら、やはりIE6以前では正常に表示されないCSSの記述があったようです。。
 しかし、、どうしたもんだか。。
posted by ミーズシステム株式会社 目面 秀信 at 04:04| Comment(0) | TrackBack(0) | プログラミング

2009年07月23日

アプリ(サービス)の依存関係

弊社では CTI開発を行っています。普段は oracleデータベースを用いて開発を行うのですが、今回の依頼は Windows Server 2003で、SQL Server 2005 Express を用いた開発になります。

CTIサーバーというのは、電話がかかってきたときに、その着信電話番号情報を顧客管理のデータベースを連結させて、その顧客の情報はもちろん、過去の取引や問合せ履歴などを瞬時に、各クライアントPC画面に表示させるというものです。

既に開発は完了していて試験運用期間中なのですが、たまたまサーバーの電源が抜けました。。
(試験用だったのでUPSに未接続・・)

それに気がついて電源を入れなおしたのですが、CTIサーバーが正常に起動していません。。

なぜだ・・ (>_<)


イベントビューアーを見てみると原因が分かった。。
SQL Server Express が修復プロセスに入っていて、起動に時間がかかっていたのです。
その間にCTIサービスは起動しようとする為に、DB接続ができずにエラーとなりました。

こういう電源が切れるという事象は ”通常運用ではない” にしろ、Windows Update 及び
その他の理由で再起動はあり得る話であって、UPS ソフトが導入されていても、数分間の
電源断があればシャットダウン(そして再起動)がかかります。
それにデータが増えてくれば、DBの起動プロセスにも時間がかかるはず。。
そう考えると、なんらかの対策をうたなければなりません。

そこで、サービスの依存関係を設定します。

これは、ServiceA と ServiceB というサービスがあったとします。
この場合、ServiceA は ServiceBが起動していないと動作できない場合に、ServiceA側に、ServiceBを依存関係にセットすれば、ServiceB起動後にServiceAが起動します。

設定方法は以下の通りで簡単。

regedit.exeで以下を探す
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\(サービス名)
「DependOnService」のキーを開き、「値のデータ」に先に起動したいサービス名を入力します。
※「DependOnService」のキーが存在していない場合はREG_MULTI_SZタイプで作成

ここで注意なのは、「DependOnService」にセットするのはサービスの名称であって表示名ではないということです。 SQL Server EXPRESSの場合は "SQL Server (SQLEXPRESS)" ではなく、"MSSQL$SQLEXPRESS" となります。

一度セットしたら、このレジストリの値をエクスポートし、サービスのインストール時に自動でセットするようにすればOKです。

Windowsは、まだまだ奥が深いですね。
posted by ミーズシステム株式会社 目面 秀信 at 09:24| Comment(0) | TrackBack(0) | プログラミング

2009年07月22日

Oracle Express Edition での不具合

Oracle Express Edition (移行 Oracle XEと呼ぶ)は、無料でかつ10gのアーキテクチャをもった高性能なデータベースなので、よく使用します。

でも、開発機では開発用ライセンスで Oracle10g Standard Ed.や Oracle11g Standard を使用することが多いのですが、本番でエラーになるときがたまたま発生してハマりました。

エラー内容は ORA-00942: 表またはビューが存在しません。
というもので、開発マシンでは動作するのに、本番機(Oracle XE使用)ではエラーになります。

実行しているSQLを抽出し、SQLPlusで実行しても動作するので、.Net との相性??
などと色々考えて試行錯誤しているうちに判明しました。

原因は、 select 文の別名でした。

select
     N_URIAGE_NO   as  売上NO,
     C_MAKER_CD    as メーカーCD,
         :

と続くのですが、別名に全角を含む場合は、ダブルクォーテーションでくくるのが正しいようです。。

でも、VBなので、ダブルクォーテーションでくくるとプログラム自体がみにくくなってしまいます。

そこで結局は、別名は簡単な半角英数字にすることにしました。

これで見事にエラーは解決しました!!

列名には全角は一切使わないのですが、別名はアプリでわかりやすいので、たまに使っていました。 だめですねー。 今回は「ー」を含む全角がエラーになっていましたが、今後のサポートも考えて、使用しないほうがよさそうですね。

※でも Oracle XE 以外ではうまくいくのは何故だろう???

    


posted by ミーズシステム株式会社 目面 秀信 at 15:07| Comment(0) | TrackBack(0) | プログラミング

2009年07月21日

PHPの仕事

私の一番の得意な言語は VB です。でも、最近PHPでの仕事があり、大変勉強になります。

PHPですがバージョンアップされて、昔よりかなり使いやすくなっていますね。

HTMLを生成するという方式は変わらないですが、他の最近の言語のよいところを
沢山取り込んでいて、VBからPHPの開発も特に難しくなく入り込めます。

ある意味、VB(.NET)よりもいいなーって思う点も沢山ありますね。

画面の作成などがちょっと手間がかかる点はありますが、ブラウザだけがあれば
どこでも稼働するのは嬉しいものですね。

今後、少しずつPHPの仕事も増やしていきたいですね。

posted by ミーズシステム株式会社 目面 秀信 at 21:33| Comment(0) | TrackBack(0) | プログラミング

2009年04月18日

SQLの中の全角文字について

最近の開発言語では、全角文字の変数を使えるようになってきた。
たとえば Visual Studioでは特に問題なく使えていますが、あまり使わないほうがよさそうです。
SQLでも同じで、項目名に全角が使えたりしますが、使えない文字もあるので注意が必要です。

一番の問題としては、コンパイラであればその機種でコンパイルして動作を確認すれば環境が変わっても動作するのですが、
プログラム中のSQLの場合は環境が変わると、データベースとのリンクを行うアダプタープログラム側の解釈の仕方によってはエラーになる場合があるのです。

ちょうど、今日、お客様のところでだけ発生するエラーがありました。でも私のPCから動かすと問題なく処理できます。
違う点はOSのバージョンとデータベースに接続するアダプターのバージョンでした。
色々とチェックして行き着いた点は、SQL中のselect文で「 MAKER_NAME as メーカー名」という部分でした。
これを「 MAKER_NAME as MAKER名」とすると問題なく動作します。

結局、アダプタープログラムのバージョンがお客様の方が古かった為に、「ー」の文字が記号というような認識でSQLとしてうまく処理ができなかったようです。

環境が変わることによりプログラムが動作しなくなるということはとても不安が残ります。
ですので、SQLはできるだけ全角は使わないようにしましょう。

posted by ミーズシステム株式会社 目面 秀信 at 22:22| Comment(0) | TrackBack(0) | プログラミング

2009年04月17日

Microsoft ACCESSのお仕事

Microsoft ACCESS 2007での簡単なお仕事の依頼がありました。
既にACCESS2003も販売されていないのでACCESS2007になったようですが、以前と画面が大きく違うので、使用説明やアプリ作成については再度勉強しなおさないといけないようです。

意外に驚いたのが、拡張子が mdb とか mde じゃないんですね。。今は、accdb とか accde になっているようです。
どういう点が違うかは以下のサイトに記載されています。
http://office.microsoft.com/ja-jp/access/HA100678311041.aspx

読んでみると以下の点が気になる変更点です。(他にもありますよ)

1.1つのフォールドに複数の値を持つことができる
 (ルックアップフィールド)

2.ファイルをデータベースに格納することができる
 (添付ファイル データ型)

この1については、今までのDBの概念が少し変わりそうな気がしますね。
また2については、情報蓄積するのにとても便利な機能といえますね。
※ただしデータファイルが巨大化しそうですが。。

画面だけじゃなく、中身も進化していたんですね。

どうやら今までの概念でアプリを作ると、新しい機能のメリットを受けられないように思います。
ここらで、きちんと勉強しなおそうと思います。

関連ページは以下にあります。
http://office.microsoft.com/ja-jp/access/FX100487571041.aspx

posted by ミーズシステム株式会社 目面 秀信 at 07:34| Comment(0) | TrackBack(0) | プログラミング

2009年04月12日

階層型データモデル

弊社は長い期間に渡って、RDBMSでのアプリケーションを構築しています。
RDBMSではリレーショナルデータモデルで構成されていて、各データを表というものに整理し、それぞれの表の関係を定義する表現方法を行います。
レコードというものに情報を詰め込み、集合としてデータを扱う場合には使いやすいモデルです。

最近のRDBMSではほとんどがリレーショナルデータモデルなので、関連する書籍も、情報を正規化して格納し、関連づけてSQLで抽出するということを中心に説明しているようです。
このように整理された事務処理系には使いやすく、更新も簡潔でよいのですが、実際の現場の情報としては表現しにくい点もあります。
たとえば社員情報に所属部署情報を格納する場合ですが、兼任する場合などはどうなるでしょう。リレーショナルデータベースとしての推奨では、社員情報を複数持つか、部署と社員情報を連携させるテーブルを追加して関連づけるということになると思います。
こういう兼任のようなケースがある場合と無い場合では、設計やコーディング量が大きく変化しますので、最初にきちんとヒアリングしておかないと後で大変になります。

でも、実際の現場ではこのようなケースは普通にあります。
パソコンの部品でも同じです。1つのパソコンを作る上でいろいろな部品が必要になりますが、それぞれの部品を構成する部品が何段階にも階層的に存在します。
また、下の階層に行くと、他の部品や製品にも使われるものが多くあります。
このように、データを階層的に再帰的に(何階層とは決められない)見てゆくような場合や、複数のところで同じ部品を使う場合があるので、通常のリレーショナルデータモデルで表現すると、処理しにくいものになってしまいます。

ここで、昔にあった階層型データモデルという概念が活躍するのです。
しかし、階層型データベースに切り替えるということではありません。あくまでもリレーショナルデータベースで、階層型データモデルの格納を行い、再帰検索を行うのです。
SQLでの再帰検索は、SQL99に組み込まれ、オラクルはVer8の時代から、 SQL Serverは2005から可能になりました。

分かりやすいサイトがありますので、ここの「再帰SQL」を参考にしてみてください。
きっと、今まで生産管理や原価管理などで悩んでいたことがうそのように楽になりますよ。
http://www.atmarkit.co.jp/fnetwork/tokusyuu/01sql99/sql99_1b.html

 
こういうことが出来ない場合は、全データを読み取ってアプリ側で計算を作りこむことになっていましたが、こういうことができるのであれば、データとプログラムの分離がますます進んでバグも削減可能です。
SQLって本当に奥が深いですね!!
posted by ミーズシステム株式会社 目面 秀信 at 11:24| Comment(0) | TrackBack(2) | プログラミング

2009年04月01日

システム構築は保守での運用を前提に構築する

システムを構築する時に、生産性をあげる手法や、新しい手法を用いることがよくありますが、わたくしは一番に保守のし易さを考えて構築します。
一般的にシステムでは多くの機能があり、それぞれにモジュール化して別々に構築します。
それらを組み合わせて最終的な1つのシステムとするのですが、構築中および運用開始後にも各モジュールの修正作業は発生するので、変更点及び変更内容に影響をうけるモジュールや機能を洗い出してすべて再テストとなります。
この再テストが一番大変なのです。

できれば一度テストを完了したものは、できるだけ手を入れたくありません。
こういう場合に如何にすれば再テストを削減できるかということが重要です。これは単に手を抜いているのではなく、お客様にもバグ発生などのリスクを減らすメリットのあることです。

これを実現できれば保守の工数削減は十分に可能になります。

私が行っている方法としては、
『基本設計を完全に行い、プログラム設計時に機能分解とインターフェースを固める』という方法です。

機能1つ1つを独立させることにより、他とのインターフェースを決めてから構築する為、機能的な変更があってもインターフェースの変更などが発生せず、機能の閉じられた中だけでテストを完結することができます。
よく、構築しながらインターフェースを決めるという方がいますが、最後(完成後)にもう一度プログラムを効率よく作成しなおすぐらいの費用と期間の余裕があればいいですが、最終的には工数も期間もオーバーしてゆくことが多いようです。

また骨組を変えるなら大胆に行うということもあります。
骨組を変えるのに、変にフラグを追加して対応するなどの方法をとると、1年2年と経過していゆくうちにそういうイレギュラーな点が見落とされてしまい、その後に修正を加えるときに過大な手間がかかってしまいます。
骨組はシンプルにするということは守った方がよさそうです。

その他、実行モジュールを1つの巨大なEXEやDLLにしないということも重要です。
これはたとえ文言修正などの小さな修正であっても、再コンパイルによりモジュールすべてが置き換わるときの影響範囲を少なくする為です。文言などを格納するのを小さなDLLや外部ファイルにもつことによって、メインのプログラムを変更しないで対応が可能になります。

次に、保守性を高めることで逆に不具合を出さないということです。
システムを構築する中でログを取得する場合がよくあります。最近のHDDは容量が大きいので問題はないという見方もありますが、ログファイルが大きくなるとシステムに大きな負担を与えます。
まず1つのファイルが巨大になることによるファイルアクセスの負担。 ファイルが増えることによるディスクアクセスの負担。
そしてディスクフルによるシステム停止などのリスク。

必ず容量設計を行い、当初確保した領域の60%を超えない運用や削除や別媒体への移動などの運用が必須です。
私の場合は60%を超えた場合は設計自体を見直しし、何らかの次の手をうつようにします。
これはコード設計と同じで、たとえば1000件で十分に足りるという要件でコードを3桁で設計した場合などに、数年の運用で600件を超えた場合などは桁を増やす必要があるというものです。
昔は設計時にはバイト数を少しでも減らすようにコードには固定長の文字型を使う場合が多かったのですが、最近はデータベースでいろいろな型が使えるようになってきたので、数値型を使うケースが非常に増えてきました。
数値型で有効桁が8桁程度あれば、すべてコードは数値型というような設計もアリだと思います。
ただ、向かないのはNULL値が必要な場合です。 値が無いというNULL値も格納できますが、その場合は数値としての特性ではなくなった使い方が必要になるのでコーディング量が増える場合があるからです。

また日付型はあまりお勧めしません。 これは比較時に日付型に変換するなどのオーバーヘッドやコーディング量が増えるからで、わたくしの場合は日付と時刻をそれぞれ別の項目にして数値型で格納しています。

最後に、重要な点があります。 それはデータベースのフィールドにNOT NULL属性やDEFAULT属性などを効果的につけることです。
入力系のプログラムを構築すると気がつくと思いますが、入力時のチェックは大変厳しくします。
これは、おかしなデータがデータベースに入らないようにということですが、データベースは何もその画面からだけ情報が更新されるわけではなく、他の処理やバッチ処理、移行作業や保守作業などでも入力・変更されるものです。
この時に予期しないデータが入った為にシステムが異常な動作をしたという報告は意外に多いのです。

移行だけを担当しているような人は、どんな情報でもデータベースに入れればよいという考えの方もいますので、NOT NULL制約などは大変嫌がりますが、最終的に本番を迎えたあとはこれのおかげでどれだけ工数が減るかを実感すれば、つけるべきところにはつけるようにしましょう。
私は基本的に区分項目、数値型の項目には基本的にNOT NULLを付けます。 こうすることでコーディング時に、NULLかもしれないという不安がなくコーディングできます!

ある意味これもコーディング規約と同じと思います。

各社それぞれ持論があると思いますが、目的はお客様のリスク軽減のためです!!
それが自社の為にでもなるなら最高ですね!

 
posted by ミーズシステム株式会社 目面 秀信 at 08:51| Comment(0) | TrackBack(0) | プログラミング

2009年03月19日

オラクルとSQL Server

弊社のソフトで使用するデータベースは、オラクルを採用することが多いのですが、ユーザの要望で Microsoft の SQL Server にすることもあります。
 
今回、SQL Server 2005 Express という無償版のSQL Serverで動作させるというオーダーだったのですが、オラクルにはあるのに SQL Serverには無い表現がいくつかあり、最初はかなり戸惑いました。
 
その中で1つを紹介します。
■重複しない番号の取得方法
  オラクルでは、以下の方法があります。
   @特定のレコードの項目をカウントアップする
      select [項目名] from [テーブル名] where [条件] for Update
      その後、
            update [テーブル名] set [項目名] = 値+1 where [条件]
      とすることで、項目の値を1加算させる。
   Aシーケンスを使う
  しかし、このどちらの方法も、SQL Serverにはありません。
  では、どうするか? ということなのですが、今回はこのようにしました。
    まず、テーブルの一意連番を格納する項目に IDENTITY [ (seed , increment) ] というプロパティを追加します。
  こうすることにより、INSERTする度に新しいレコードのこのフィールド値がincrementの値分加算されて自動的に追加されるのです。
  でも、これだけでは追加された番号がわかりませんよね。
  そこで、INSERT文の values の前に OUTPUT INSERTED.[項目名]を追加します。
  例を書くと、
  INSERT INTO [テーブル名] ([項目名]...) OUTPUT INSERTED.[項目名] VALUES('値'...) 
  のようになります。
  このINSERT文は、実行時に INSERTED.[項目名]で指定しているように、追加されたレコードにセットされたこの値をSELECTのように返してくれるという優れものです。
 
  是非、皆さん使いましょう!!
 
※排他制御や重複しない番号取得など、こういうテクニックは確実に埋め込んでおかないと、あとでエラい目にあいますので、十分に勉強しておきましょう!!
 
勉強すればするほど、オラクルの方が記述がシンプルで表現ができる気がします。
また、オラクルはサーバーがWindowsでなくても動作するので、汎用性が高いというメリットもあります。
しかし、どちらが良いとかダメとかではなく、決めるのはあくまでもお客様です。
 
どちらでも最高のパフォーマンスと保守性を保てるように常に勉強してゆかないといけませんね!!
posted by ミーズシステム株式会社 目面 秀信 at 23:01| Comment(0) | TrackBack(0) | プログラミング

2009年03月17日

CTIの活用

CTIをご存知でしょうか。

Computer Telephony Integration の略で、電話やFAXをコンピュータシステムに統合する技術のことです。
実際に導入すると、こういうことができます。

@電話がかかってくると、着信音がなる前に使っているパソコンの画面上に、誰からかかってきたかという情報(会社名や担当者氏名など)が表示される。
A社内、販売管理や顧客管理のシステムがあれば、それと連携することでかかってきた方からの取引情報や過去の問い合わせなどの履歴を表示することができる。

という感じです。
企業が持っている情報をうまく組み合わせれば、色々な情報を電話着信と同時に画面に表示することが可能になります。

少し値段が高い(といってもしれていますが)機器を導入すると、会話内容も全て録音できるようになり、注文内容の確認、クレーマーからの電話内容を記録などにも使用することもできます。

今、弊社の販売管理システムにこれらCTI機器を連携させることで、前述のような対応が可能になるソフトを開発中で、4月末頃を目処に正式発表する予定です。
通販などで多くのお客様を抱える企業や、宅配の注文を受け付けするような企業、得意先の多い問屋様での導入が効果的です。
また、パソコンの画面で顧客をクリックすると自動的に電話をかけるというようなことも可能なので、電話セールスやアポイント業務にも使えますので、ご期待ください!!
posted by ミーズシステム株式会社 目面 秀信 at 23:23| Comment(0) | TrackBack(0) | プログラミング

2009年02月25日

リバースエンジニアリングに注意

.NETで開発をしていますが、ソースコードの中にパスワードや重要な情報を格納しておいたりすることもありますし、重要なテクニックが含まれる場合もあります。

この場合、.NETは中間コードを出力するものなので、リバースエンジニアリングを行うと、元に近い形のソースコードが復元できてしまいます。

もちろん日本語の文字で書けばそのまま復元されます。

これってとっても危険ですよね?

.NETで作成してアップされているものは、ソースコードを守れないことになります。

これはJavaでも同じことであって、ネイティブコンパイラでない限り仕方がないのです。。

もし「本当にそんなことができるの?」と思う方は、以下のルーツ(フリー)で試してみてください。
きっと、その復元の程度にびっくりされると思います。
http://www.red-gate.com/products/reflector/


逆に難読化させるツールで高度に難読化してくれるものには以下のソフトがあります(しかし高い!)
http://www.agtech.co.jp/products/preemptive/dotfuscator/

でもこのサイトに載っているサンプル結果を見る限り、よーく読めば解読はやっぱりできてしまいますね。。
かなり見にくくはなっているのは確かですが・・


少しレベルは落ちますが、以下のものでも結構見にくいですよ。
http://uwa.potetihouse.com/soft/nandoku.html
posted by ミーズシステム株式会社 目面 秀信 at 22:17| Comment(0) | TrackBack(0) | プログラミング

2009年01月21日

Silverlightを囲む会

Silverlightを囲む会に参加してきます。

今回は第7回目だそうで、わたくしは初参加です。
http://silverlightsquare.com/page_1231077073296.html

今回はどうしても出席したい理由があります。
それは、今回のテーマが「業務アプリケーション」だからです。

またセッションにマイクロソフトの大西彰さん、グレープシティの八巻雄哉さんが参加されるということで、これも楽しみの1つです。

おそらくSilverlightでの業務アプリ開発について、どういう点に問題があるのかなどの色々な意見が出るのではないかと思います。
Web系は苦手ですが、業務アプリという点では私も発言ができるのではないかと思いますし、どういった用途が可能かという点もとても期待できそうです。

参加費は200円なので、時間があるのであれば参加してはいかがでしょうか。
続きを読む
posted by ミーズシステム株式会社 目面 秀信 at 07:45| Comment(0) | TrackBack(0) | プログラミング

2009年01月16日

ActiveReports

当社では帳票の出力に、GrapeCityの「ActiveReports」をかなり前から使用しています。

確かVB2.0の時代からなので、もう10数年(もっと?)になります。
昔はGrapeCity(グレープシティー)という会社も、文化オリエントという会社で、今でも文化オリエントと呼んでいる人も多いようです。

で、このActiveReportsなのですが、グレープシティーがData Dynamics社の製品をローカライズしていただけだったのですが、2008年10月に所有権を買収しました。

それが今月、完全なグレープシティーの自社製品として生まれ変わることになったそうです。


これはかなり意味があります。

海外のシステムでは日本ほどレポートに対しての要望が高くありません。
CrystalReportsなどにしても、日本独自の帳票に対する要望の細かさに対応ができず、かなり苦労します。

こういう点が日本の会社になると、とても便利になってゆくと思われます。


今後もグレープシティーには頑張ってほしいと思います。
posted by ミーズシステム株式会社 目面 秀信 at 12:52| Comment(0) | TrackBack(0) | プログラミング

2008年12月27日

子供もオープンソース

私の小さいころは、パソコンがカラー(それまではモノクロ)を出せるようになった1970年代後半で、NECのPC8001やPC6001、SHARP-X1やMZ-2000など、名の有る各社から沢山の機種が発売されていました。

一部、SHARPなどは除いて他のパソコンは、スイッチを入れればすぐに、BASICと言われる言語が動作して、すぐにプログラムを作成できるようになっていて、僕らはそれで色々なプログラムを作っては改造したりして遊んだものです。

このころのパソコンは、10〜30万ぐらいしてましたね。
家にパソコンがある家庭は少なく、1クラスに2人程度だったかな。
価格はむしろ、今の方が安くなってます。


それが今は各家庭にもパソコンがある時代で、子供向けに言語が出ていると。。。

便利なようだけど、どれをすればいいのかよくわからない気もします。
でも、ブロックでも「レゴ」や「ダイヤブロック」など色々なものがありますが、基本の考え方は同じなんです。

プログラマーの世界でもそうですが、「私はこの言語だけしかできない」というような人も多いのですが、センスのある人は、言語の違いは1〜2週間で乗り越えてしまうものです。

だからプログラムを書くという作業よりも、やりたいことをどう表現するかということを習得するのがいいと思います。
そういう意味で、これらのオープンソースのものは、新しい考えを導入していて、非常に面白そうです。

既にプログラミングを経験している人も、お正月に遊んでみては??
posted by ミーズシステム株式会社 目面 秀信 at 14:12| Comment(0) | TrackBack(0) | プログラミング

2008年12月09日

アプリのモジュール構成

私の開発しているソフトの販売管理系のソフトは、機能が多く、機能毎にプログラムを分けて作成しています。

この良い点は、追加やバグ修正があったときにでも、全コンパイルをかけなくて済むので、修正対象外のモジュールの動作は保障されるという点です。

販売管理は使っていくと必ずといってよいほど、追加修正の要望が発生してきます。
でも2、3年経過したぐらいにそういう修正を行うと、ユーザ先へリリースする前に一通りの動作確認が必要になってくるのでとても大変ですが、このようにモジュールが完全に別であれば影響は最小限で済むのです。

でも今までは、1つ1つを別EXEにして起動していたので呼び出しに時間がかかっていました。

これを今回はメインモジュール以外をすべてDLLへクラス化してしまい、必要な時に動的に呼び出す方式に変更する事にしました。
こうすることで、修正時はDLLの入替のみで済みますし、DLLなので、使用していないときには、起動している自分のEXEから更新することも可能になり、自らアップデートするような仕組みももつことができます。

それに、初回起動時のモジュールが最小限になるので、動作が軽くなり、.NET 特有のイライラも少なくなりました。

今後新たに開発をされる方は、ぜひ採用を検討してみてくださいね。
posted by ミーズシステム株式会社 目面 秀信 at 22:17| Comment(0) | TrackBack(0) | プログラミング

2008年12月01日

IPアドレス枯渇とソフトハウスの責任

早ければ2010年にもIPアドレスの空きがなくなってしまう。。
 
これは、TCP/IPという通信プロトコルを使って通信を行う場合に、必要となる192.168.0.1 等というような、"." で区切られた4つの数値の表現のことで、ネットワークを使って相手のPCまで情報を届けるためには不可欠なものです。
 
この形式のものはIPv4 (アイピーブイフォー)と呼びます。 
 
空きが無くなるということは、新規にアドレスがもらえないということで、その空きをめぐって、アドレスが高値で売買されるというようなことも発生するに違いない。
 
これは最終的にエンドユーザの利益を大幅に損ねるものになると思う。
 
このアドレス枯渇に向けて、数年前から IPv6というものが現れてきた。
IPv4では数億個のアドレスしか表現できないが、IPv6では、理論上で340兆の1兆倍の1兆倍 という数のアドレス表現か可能になっており枯渇する可能性がない(現時点の推測で)ように設計されている。
 
では、みんなこれに置き換えればいいのでは? と思うかも知れない。
 
でも、そう簡単にはいかないのです。
 
 
今から20年ほど前に、TCP/IPネットワークが主流になってきた当時からIPv4は使われてきている技術で、その技術の上に現在のインターネットや携帯メールなどの技術が出来上がっているのです。
 
だから、急に変更することは、何年もかけて専門家が研究していますが、難しいということです。
 
2年ほど前に、Windows Vistaが発売され、それ以降のOSはIPv6を標準で対応するようになりました。
 
そのおかげで、今では IPv6とIPv4をうまく使い分けて通信することが可能になっています。
 
   しーかーしー!!
 
未だ、IPv6にいつかは切り替わるという危機意識がソフトハウスにはあまり無いようで、変更に関して必要な情報もまだまだ少ない状況です。
IPv4アドレスの記憶する領域の桁では、IPv6アドレスを記憶できるだけの容量もありませんので、こういったデータベースの領域から見直しが発生してしまうこともあり、昔あった2000年問題以上に危険だと思われます。
 
 
少なくともソフトウェア開発を行っている会社は、今後の開発については、ネットワークを使うソフトは IPv6対応をしておくことが、企業の責任でもあると思います。
 
逆にこれに対応できないソフトハウスは、淘汰されていくのではないでしょうか。
 
私のところも、この対応を順次やってゆこうと思います。
posted by ミーズシステム株式会社 目面 秀信 at 13:15| Comment(0) | TrackBack(0) | プログラミング

2008年10月29日

Remotingによる分散システム

前回、.NETのRemotingについて触れましたが、既存のシステムをこの技術を使って手直ししました。
 
感想は、

 @思っていたよりも高速にレスポンスがある。
 
 A浅く理解して対応するとエラい目にある。 (一応、理解できましたが)
 
 B今後は分散システムに。
 
です。
 
まず@ですが、クライアントにネイティブなドライバを入れて通信するよりは遅いですが、体感的にはほとんど変わりません。
1万件の個人情報をクライアントのデータセットに取り込む処理も一瞬です。

これはRESTを使ってWebサービスを使うよりもはるかに早いです。
対応することのデメリットはあまりないといえます。
 
Aは、少しハマりました。
キーワードは、singletonとsinglecallです。
前者はサーバ側で1つのインスタンスを持ち、後者はアクセスの度にインスタンスを作成します。
データベースをサーバに持っていったので、前者を使用しましたが、これはサーバ1つに1つのインスタンスをもつということなので、クライアントが複数あってもそこからデータベースのオープンやクローズ、トランザクション処理をしてはならないということなのです。
これに気付かず、実行している最中に奇妙なバグがたくさんでました。
最終的には、サーバ側で起動時にDBをオープンしておき、クライアント側ではオープンをしない(これってすごくない?)で接続できます。
 
で、Bについてですが、なんといってもテストが楽になります。
一人で作成できるシステムというのは限界があります。 分散システムにしてそれぞれのプログラムをスレッドを使って通信し、それをイベントにして作成する方法にすることにより、インターフェース部分のみ作成してしまえば、あとは自分のペースで作成&試験が行えます。
通常の流れではないデータでも試験ができるので、単体テストの強化にもなりますね。
 
「インターフェースを作るのって邪魔くさい」って言う人は、対象外ですが。。。
(わたくしも昔はそうでしたが、考えが変わりました)
 
今後、1アプリだけではなく、連携したシステムを構築してゆこうとしているのでこの技術は最高です!!

posted by ミーズシステム株式会社 目面 秀信 at 10:29| Comment(0) | TrackBack(0) | プログラミング

2008年10月25日

概念を変える .NET 技術

.NET Framework 2.0のころから、いいなと思っていた技術の中に、リモートサーバの技術があります。
 
具体的に言うと、Remotingというフレームワークを利用することで、別のマシンで実装しているクラスを実行してしまおうという技術です。
(具体的になっていないなぁ)
 
 
もう少し、わたくしのほうで行っている内容で例をあげてみますと、クライアントにインストールする、DBを使用するアプリがあります。
データベースはサーバにインストールしますので、クライアントからのアクセスには、ODBCやADO、または専用のDLLなどを使ってアクセスすると思いますが、こうすると、クライアントには、ODBCやADO、DLLのインストールなどが発生したり、クライアント側への設定が発生したりします。
 
こういう手間をなくすることができるのです!!
 
データベースサーバに、アクセスするためのクラスを配置しておき、クライアントからサーバ上のクラスをインスタンス化することにより、サーバ側で動作しているかのように動作してくれるのです。
 
直接クライアント側にサーバアクセスを行うモジュールを置かないことでセキュリティー面でも効果はあると思います。
 
少し速度面ではネイティブな接続よりは劣るかもしれませんが、RESTやWebサービスよりも高速に動作できます。
 
なかなか実装するのには勇気がいりますが、.NETであれば意外に簡単に対応は可能です。
是非習得しておきましょう!
 
posted by ミーズシステム株式会社 目面 秀信 at 16:17| Comment(0) | TrackBack(0) | プログラミング

2008年08月14日

草むしりとプログラミング

お盆に実家から母が遊びに来るということで、朝の涼しいうちに庭の草むしりをしました。
 
そういえば、わたくしが生まれた家は裏庭が広くて、そこに色々な野菜や果物(みかんとか)を植えていて、ちょっとした野菜はそこで収穫していました。
 
たとえば夜のごはんの支度中に、サラダを用意したければ、裏庭から、キュウリとトマトを収穫するといった具合です。
 
でもー、この庭は土がよいのか、野菜もすくすく育つのですけど草の生えるのも尋常ぢゃありません・・
だから草むしりも小さいころから当たり前のようにやっていてふとそのときを思い出したのでした。
  
話を本題に戻しますが、草むしりをしていて、あれ? これってプログラミングに似てる!  って思いました。
まず、草むしりの方法ですが、わたくしは3段階に分けています。
 
その1: 
  巨大な草や根のしっかりしたものを道具を使って除去。
その2:
  手前から1つずつしっかり手でつかみ、抜き取ってゆく。
その3:
  抜いた草を集めて、再度チェックし、抜き漏れがあれば
  その部分をやり直す。
 
といった具合です。
 
プログラミングにあてはめてみると、
その1:
  大まかな画面遷移や骨組を、フレームワークを使って
  仕上げる。
その2:
  1処理、1機能ごとにプログラムを作成してゆく。
その3:
  処理、機能毎に動かして問題があれば修正してゆく。
 
と、こんな感じですね。
こういう組み方は、皆さんそれぞれのスタンスをお持ちだと思いますので、結構違うかもしれませんが。。
 
もしかしたら、私は昔からこういう業界が向いていたのかもしれません。
草むしりとプログラミングが似ているのではなく、自分のスタンスが同じだけというものかも・・・
 
posted by ミーズシステム株式会社 目面 秀信 at 10:53| Comment(0) | TrackBack(0) | プログラミング