2010年03月17日

迷惑メールの撃退に効果あり!

スパムメールや一方的な広告メールなどの、こちらが意図しないメールが毎日山ほど送られてくる。
その中には自分が何かアクションを起こして申し込んだメルマガ関連から企業に売られたであろうメルアドとしてくるものや、ホームページなどから収集したメールアドレスから自動的に送ってくるものまで多数あります。

その中でもしつこいのが2週間ほど前から来るようになりました。
それも毎回2通ずつ少し時間をずらしてきます。
うちにきたのは「★ 50万円までのご融資なら98%大丈夫。 ★」という内容のものでした。
何しろ目立つので余計に腹が立ちます。
最初は3日で10通ぐらい送られてきました。
メール最後のほうには「このメールは特定電子メール送信適正化法・改正特定商取引法を遵守の上送信しておりますが」とかかれていますが、
本来あるべきの、解除する方法などが一切かかれていません。
記載されているホームページも、連絡先は携帯になっているようで、超あやしいサイトです。

こんなところに電話でもしたら、逆にいちゃもん付けられそうでしたので、メールに返信という形で、受信拒否したい旨を伝えました。
結果はその後も全く変わりなくメールが届きます。
そこで、今回はこういうサイトに申請してみました。

迷惑メール相談センター
http://www.dekyo.or.jp/soudan/ihan/

そうすると、2日ほどでピタッと来なくなりました!!!
何か対策をしてくれたのかなーって思います。

もし困っている方は試してみてはいかがでしょうか。
 
posted by ミーズシステム株式会社 目面 秀信 at 17:37| Comment(0) | TrackBack(0) | 日記

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) | プログラミング

2010年03月05日

ネット販売を始める前に

ネットショップ出店をすることは、実店舗出店するに比べてハードルも低く、比較的簡単に行うことができるようになりました。
 
しかし、最近、お客様と打ち合わせしていて気付くことは、分析と計画の甘さかと思います。
 
というのは、ネットショップを行うにあたり、それを本業としてしっかり事業計画をたてている場合はよいのですが、本業が別にあって、売上が減ってきたからネット販売で儲けてみようというタイプだと、ほぼ間違いなく失敗していきます。
 
まず、出店に関しては以下のケースがあると思います。
 1.実店舗がありすでに商品の販売を行っている。
    追加としてネット販売を始める場合。
 
 2.メーカーとして商品はあるが、直販を行っていない。
    追加として直販を始める場合。
 
 3.あらたな商材を使ってはじめて物販をおこなう。
 
まず、1のパターンでは、目的は『新規顧客の開拓』となります。
次に2のパターンでは、『新たな販売チャネルの創出』、と、業界における『消費者動向のタイムリーな把握』となるでしょう。
3のパターンでは『新規事業の創出』だと思います。
 
こういういろいろなケースにおいて、一律に「こういうソフトを入れればいいですよ」とは言えないのです。
 
また、それぞれのパターンでもお客様の中で何がネックになるか、どういう部分を改善すればそれが解決できるか。 解決するのに投資するにあたり費用対効果はどうなのか?
これらすべてが関わってきます。
 
仕入先を確保し、サイトを構築し、システムを構築して万全にしてから通販を開始するという方もいらっしゃるかと思いますが、よほど十分な専門知識と独創性のある商品(商品力)、ライバルの有無、広告媒体との連携などを行わない場合は、田舎の山奥に巨大ショッピングセンターを建設するようなもので、集客がほとんどできず、最初の投資金額が回収できないだけでなく、維持費もかさんでいくことになります。
 
これはネット店舗というものの特性ということもありますが、そもそもモノを売る商売ということに対する考え方が甘いということに原因があります。
おそらくモノを右から左へ販売することを主にしておられる会社様はまずこういう失敗はあまりなく、ネット店舗というものを実店舗と同等かそれ以上に慎重に出店されるようです。
 
しかし、もともとメーカーであったり、別事業として始める方についてはそういう意識がすくなく、ネット販売をすることで小投資で大きな利益が得られるものと勘違いしてしまいます。
 
弊社はそういうことでネット進出をして、すぐに撤退していく、もしくは衰退していくことがないよう、適切なアドバイスをさせていただきます。
 
これからネット販売を開始してみようと思われる方は、ぜひご相談ください。
posted by ミーズシステム株式会社 目面 秀信 at 09:31| Comment(0) | TrackBack(0) | 日記