カテゴリー「プログラミング」の記事

日本国際賞授賞ニュースを見て

デニス・リッチー氏とケン・トンプソン氏が「日本国際賞」を受章したとのニュースを、今日0:00のNHKニュースで知りました。

ソフトウェア業界ではあまりにも有名すぎる、いわゆる「K&R」であり、彼らなくしては、今のIT産業の繁栄もインターネットの繁栄もなかったかもしれないと思うと、ノーベル賞受章にも値するのでは?と思うのですが。

おそらく、「K&R」の2人がいたから、「ソフトウェア開発で飯を食う」ほど、ITが「産業」と言うほど育つのに40年の時間を得ることが出来たのか?・・・もし「K&R」がいなかったら・・・?

少なくとも、2010年のウィキリークスとか2011年のチュニジアの政変はなかったかな。

| | コメント (0) | トラックバック (0)

Windowsのエラーダンプ解析

昨年の6月に設計を開始し、この2月で一応の完成を見たWindowsアプリケーションを、チームの人に試用してもらっていたところ、「特定の操作をするとアプリが落ちることがある」という報告を受けていました。しかも、一見したところ再現性がない、と。

最初は、ソースコードを読んでバグのありそうなところを一つづつ潰していき、怪しそうな部分にログ出力コードを埋め込み、非常にに怪しいと思われる部分をtry-catchで囲ってみたりしたものの、それでもアプリがクラッシュ(;_;)

で、最後の手段と思って、その名も「Windowsダンプの極意 エラーが発生したら、まずダンプ解析! 」なる本を買いました。

UNIX系OSであればcoreダンプはおなじみのはずで、10年ほど前に(私のキャリアの中で唯一)HP-UXのアプリを開発したとき、かなりお世話になったものですが、Windowsでも同じことができる、というわけです。

つまり、アプリがクラッシュしたときにダンプファイルを出力させ、そのファイルを後から(別のPCでもOk)解析してエラーの原因を突き止めるということが可能になるわけです。

解析に先立って、エラーダンプを解析するためのwindbgというデバッガをマイクロソフトからダウンロード&インストールしたり、リリースビルドでmapファイルを出力するようにVCプロジェクトを設定したり、ターゲットマシンでダンプファイルを出力する設定をしたり、といった準備をしておき、今朝、ダンプファイルをゲット。

昼過ぎまで別の作業があったので、午後3時ごろから解析開始。
windbgの使い方に慣れていないのと、スタックトレースを追いつつ逆アセンブルコードを眺めつつmapファイルを見て対応するソースコードを探したり、で2時間経過。

結果、WM_MOUSEMOVEイベントハンドラの中で落ちていることがわかり、後はソースコードレベルの解析に切り替え。さすがにソースコードレベルの解析は手馴れているので、コードを見た瞬間に「あちゃ~^^;」。
マウスカーソルが特定の場所にあるときに限ってちょっとしたデータ処理をする必要があり、データがゼロのときに処理してはいけないはずのところで処理を突っ走ってしまって不正なメモリ領域をアクセスしていた、というオチでした。

試用してもらっていた環境が「VistaにインストールしたVirtual PC上で動作するXP環境」だったので、その環境に特有の問題かと(根拠のない)推測をしていたのですが、何のことはない、(こう言うのもなんですが)ごく普通のバグでした(--;)

ともあれ、エラーダンプ解析はかなり有用だ、ということが身をもって分かりました。

| | コメント (0) | トラックバック (0)

掲示板のSPAM対策

先週末から今度の日曜まで9連休の夏休みになったものの、最初の5日は、「寝る、食う、呑む」の3拍子揃った、だらけた生活。体重計に乗るのが怖いくらいです。

というのはさておき、本家サイトの掲示板には5月頃からSPAMな書き込みが頻発していて頭を悩ませていました。

DNSの逆引きではIPアドレスからドメイン名が取得できなかったので、Web上のwhoisサービスサイト(たとえばこことかこことか)を使って、どうやらイギリス領ヴァージン諸島(に登記簿がある?)のドメインらしいことは判明。とりあえず、当該サイトの特定のIPアドレスからの書き込みは排除するようにしていたが、かなりの頻度で(1時間に1回くらい)アクセスしているのが明らかになると、いい加減ブチ切れて(笑)、掲示板自体を停止したのが6月末。

そんな中、7月に東京でDさんと会ったときに、彼も相当SPAM対策で苦労したということを訊き、教えていただいたSPAM対策(その節は多謝>Dさん)を導入したのが一昨日(苦笑)。導入作業自体は(Perlならびにプログラミング全般の知識があれば)非常に簡単ではあったのだが、単に不精だっただけ(爆)

「じゃあついでに(^^;)」、というノリで、前から導入しようかと漠然と考えていた、「画像で認証キーを表示しておき、認証キーを入力しないと書き込みできなくする」という仕掛けも、一から書き起こして2日間でとりあえず出来上がり、導入完了。
あるタイミングで掲示板の出力のスナップショットを取って、そこからSPAM投稿スクリプトを作ったとしても、投稿を受け付けない仕掛けにはしてある(つもり)ので、そう簡単にSPAM投稿は出来ないだろうと思っているが、万が一突破されたときは、まだ更なる奥の手を考案済み。

「奥の手」はまだ実装していないが、これを実装したら、突破できるのはおそらく暗号解読のエキスパートくらいではないかと推測(爆)

| | コメント (0) | トラックバック (0)

UML CASEツール

前の派遣先を5月末で契約解除し、6月から新しい派遣先での勤務が始まりました。
今回の派遣先での業務は、化学系の分析装置を制御するソフトの作成です。

一応、大学は化学系だったので、分析化学の授業で今回扱う分析方法の概要を習った記憶だけはあったのですが、学生実験でその分析装置を操作することもなく、「思いっきり物理」(^^)の研究室に進んでしまい、修論の研究テーマは新しい分析手法の開発(ハード、ソフト込み。ただしソフトの比重が非常に高かった^^;;)で、新卒から7年ほど勤めた会社では音響計測のアプリケーション開発の仕事が多かったので、よくよく計測系の仕事に縁があるらしいです。

今回は、詳細設計からコーディング、テストまで関わるのですが、設計から関わるのは、実は数年ぶり。今まで派遣要員として関わった仕事は、コーディングとテストしか担当しない場合が多かったのです。
設計するにあたってUML CASEツールを使うことを考えているのですが、昔使っていたツールは、Visual Studio 6.0(のEnterprise Edition)に付属していたVisual Modelerという、Rational Roseのサブセット版でした。

自宅のPCにインストールしてあるので数年ぶりにVisual Modelerを使ってみたのですが・・・。クラス図しか描けない。せめてシーケンス図も描けないと使用に耐えないです。まあ10年も前にリリースされたツール、しかも開発環境におまけでついてきたサブセット版なので仕方ないといえば仕方ないですが。

ここ1年ほど個人的に使用していたJUDE Communityというツールは純国産ですが、今回はC++とVBでの開発なので、Javaのコード生成しかできないJUDEは却下。

そこで海外製のフリーのUML CASEツールを探して、いくつか試用してみて気に入ったのが、SDE for Visual Studio .Netというツール。Visual Studio 2003/2005に組み込まれて動作し、UML2.1に準拠し、当然C++やVB.NETのコードを生成することができ、逆にソースコードからクラス図を生成する、リバースエンジニアリングにも対応していて、ドキュメントもWordのdocファイルで出力できるという優れもの。これでフリーというのが信じられない出来です。
ただ・・・Core2 Quad 2.4GHz、メモリ4Gのマシンでも動作が重く感じることがあるのが悩ましいところではあります。またインストーラが130Mバイトもあり、FTTH環境でないとダウンロードもままならないです。

できればVC++6.0とVB6.0で開発したい事情があるのですが、2005に移行したほうがいいのか、悩ましいところではありますが・・・。

---- 7月18日追記 ----

色々探した結果、C++とVB(.NET以前のバージョン)のソースコード出力/リバースエンジニアリングもできるツールとして、Enterprise Architectというものを見つけました。
とりあえず30日トライアル版で試用してみて、「これは使えそう」という感触を持ったので購入して頂きました。たしか1ライセンスあたり3万しなかったというのが大きな理由だったような。

ここに例示した、どのUMLツールも、VisualStudio6についてきたVisualModelerとは比べ物にならない使い勝手のよさ。UML自体が普及したことにより、こういったCASEツールが普及したのかなぁ、などと思い、今思えば非常に力不足なVisualModelerを使って設計していた昔と比べて、10年の時間を感じました。

| | コメント (0) | トラックバック (0)

ディスコグラフィ作成:いよいよ検索用CGIスクリプトの作成

ディスコグラフィ作成も、PC上でのデータ入力や辞書作成のツールは完成の域に達し、CDデータの入力も辞書作成も一段落し、いよいよ検索用CGIスクリプトの作成に取り掛かることになった。

が、Perlを使うのは数年ぶり、PerlでUnicodeを使えるのかも良く知らない・・・。ということで、まずはPerlでUnicodeを使えるか、使えるならば何に気をつけるべきか、といったことをWebで検索してみて、どうやらそれほど難しくはなさそうであることだけは「なんとなく」分かった。

それではと、ごちょごちょコードを書いていくうちに、どうにか検索CGIができてしまった。予想通り、Perlの細々としたテクニックはかなり忘れてしまっていたが、昔書いた掲示板のCGIスクリプトを読み返して思い出したりした。

PerlでUnicode(厳密にはUTF8エンコード文字列)を扱う方法として、とりあえず分かったこと。

  1. (当然といえば当然だが)スクリプトをUTF8で記述しておく。
  2. スクリプトの先頭にuse utf8; と use Encode; を記述しておく。
    →どうやら、これでスクリプトでUTF8文字列を使うよう設定され、文字コード変換のサブルーチンが使用できる、らしい・・・。
  3. binmode STDIN, ':bytes'; で、標準入力からのデータに文字コードを仮定させない。また、標準入力から読み込んだCGIパラメータは、入力がUTF8文字列の場合、
    $data = decode('utf8', $data);
    のようにして、Perlに認識させる。
  4. open File, '<:encoding(utf8)', 'sample.txt';
    とすると、読み込み元のファイルの文字コードを指定できる。
  5. binmode STDOUT, ":encoding(shiftjis)";
    または
    binmode STDOUT, ":encoding(utf-8)";
    のようにすると、標準出力への出力データは自動的に文字コード変換される。

ざっと、こんなところだろうか。PerlでUTF8を使う方法の詳細については、以下のサイトを参考にしていただきたい。
Perl 5.8.x Unicode関連
perl 5.8における日本語コード変換のメモ
perl5.8のUnicodeサポート

1ヶ月ちょっと続いたディスコグラフィ作成は、これで一通り終わり、後はCDデータの追記と、定期的に同義語辞書の拡充を行い、CGIスクリプトの出力の体裁を整えるだけとなった。

| | コメント (0) | トラックバック (0)

ディスコグラフィ作成:同義語辞書の作成

ディスコグラフィ作成に取り組み始めて1ヶ月を経過。もはやちょっとしたプロジェクトと化してきた感があるが、ようやく同義語辞書の作成にかかることができるようになった。

辞書のファイル構造は、

ルードヴィヒ・ヴァン・ベートーヴェン  Ludwig van Beethoven
弦楽四重奏曲  String Quartet Streichquartett Quatuor à cordes
Martha Argerich マルタ・アルゲリッチ
....

といった具合に、1行に同じ意味の単語を羅列している。C++で記述するオブジェクト構造も基本的には、

CSynonymEntryクラス  ファイルの1行を表現し、単語の羅列を保持する。
CSynonymDicクラス  辞書全体を表現し、複数個のCSynonymEntryオブジェクトを保持する。

という構造であるが、CSynonymEntryクラスは、単語の保持以外にいくつか機能を追加したいので、
class CSynonymEntry : std::vector<CString>{...};
と実装した。

また、CSynonymDicクラスは、ある単語が辞書に登録されているか調べる必要があることと、ファイルに記述したイメージ通りデータを保持しておく必要があることから、

typedef boost::shared_ptr<CSynonymEntry> CSynonymEntryPtr;

class CSynonymDic
{
private:
    class CDictionaryOrder{
    public:
        bool operator()( const CString& lhs, const CString& rhs ){...}
    };
   typedef std::map<CString,CSynonymEntryPtr,CDictionaryOrder> CSynonymMap;

    CSynonymMap                            mxDictionary;
    std::vector<CSynonymEntryPtr>    mxEntries;
public:
    CSynonymDic();
    ~CSynonymDic();
    //その他メンバ関数
};

と記述した。つまり、単語が辞書に登録されているか調べる目的に、map<CString,CSynonymEntry*>を用意し、ファイルに記述したイメージ通りデータを保持しておく目的から、vector<CSynonymEntry*>を用意した。

が、実際にはCSynonymEntry*の替わりにboost::shared_ptr<CSynonymEntry>を使っている。これはBoostというクラスライブラリで提供されている、参照カウントつきポインタを定義するshared_ptrクラステンプレートを用いているためである。
また、mapのテンプレート引数の3番目にCDictionaryOrderを指定しているが、これは独自のソート順序を定義するためである。

このようにして辞書のデータ構造を実装し、GUIを作ってひたすらデータ入力。結果、登録単語数として1600、辞書ファイルの行数として500余りになった。Perlで検索処理を行うことを考えると、単語の平均文字数の大きい行ほど前に来るようにソートしておいたほうが何かと都合が良いと考えられるので、ファイルを保存する時にソートすることにした。

あとは、Perlで検索CGIを書くだけだが、Perlを個人的用途で触るのは4、5年ぶり、業務でも3年前に30行程度のCGIスクリプトを書いたことがあるだけなので、Perl独特のクセはかなり忘れてそう・・・。

| | コメント (0) | トラックバック (0)

ディスコグラフィ作成:CDジャケット画像の縮小とWebサーバへのデータ転送

700枚余りのCDのデータ入力とジャケット写真をスキャナでJPEG画像として取り込む作業は終わり、その後買い足したCDについても、買った当日にデータ入力とジャケット取り込みをするように習慣付けるようになったので、データ入力に関しては問題はクリアできた。

しかし、CDデータを収めたUTF8形式のタブ区切りテキストファイル3つと、CD枚数と同じだけのJPEGファイル700個をFTPクライアントソフトを使ってWebサーバへ転送するのがかなり面倒・・・。
FTPクライアントソフトを使って、転送したいファイルをいちいち選択して転送するという作業自体が面倒だし、転送漏れも起こりうる。これは、データ入力ツールにFTP転送の機能も追加したほうがよさそう。これは、MFCのインターネットクラスなどを使うことで1日でサクッと作れてしまうのだった。

それともう一つ。携帯からも検索できるようにしようと考えているのでジャケットの画像ファイルのサイズを小さくしたものも用意しておきたい、という要求も出てきた。データ入力の際、スキャナからは100dpiで取り込んでいるため、大体480×480ピクセル、80~100kバイト程度のJPEGファイルが700個ある。携帯の画面サイズは(少なくとも私の持っている東芝のau向け機種では)240×320ピクセルなので最大でも200×200ピクセル程度まで画像を縮小する必要があるし、ファイルサイズも小さくないとパケット通信料も馬鹿にならない。とにかくJPEG画像を縮小したい。

最初は、オリジナルの480×480ピクセル、100kバイトのファイルをCGIで動的に縮小することを考えていたので、PerlでJPEGファイルのリサイズできるものはないかと検索してみたが、なかなか見つからない。まあ、JPEGファイルの仕様自体が、離散コサイン変換とか圧縮と言った数学的内容を含んでいて難解なので、簡単にPerlベースのソースコードを見つけようというのも無理があるわけだが・・・。

そんなわけで、CGIで動的に画像を縮小することはあきらめ、PC上で画像を縮小するためのツールやライブラリをVectorで検索してみたが、どうも見つからない。
で、いろいろ検索するうちに、ImageMagickというオープンソースのライブラリがあるらしい、ということを知り、ImageMagickの公式サイトからWindows用のインストールパッケージ(WindowsInstaller形式ファイル)をダウンロードして、インストールし、公式サイトのチュートリアルページを参考に、
「JPEGファイルを読み込み、元の1/4に縮小し、JPEGファイルとして書き出す」
というコードを書いてみたが、ファイルを読み込むところで落ちてしまう。インストールされていたサンプルコードと見比べても何が違うのか良く分からない。

仕方ないのでライブラリの全ソースを圧縮したzipファイルを公式サイトからダウンロードして展開し、ライブラリをビルド・・・してみたが、コンパイルエラーが出まくってどうしようもない。結局、インクルードファイルの中のマクロ定義を2つコメントアウトしたらビルド成功。コメントアウトしたマクロ定義は、XWindowを使うかどうかを決定するマクロと、GNOMEのxmlライブラリを使うかどうかを決定するマクロだった。ソースをダウンロードしてからビルドに成功するまで丸1日・・・。今使っているノートPCはいろんなソフトをインストールしまくっているせいかビルドがやたら遅いので、セーフモードで起動した状態でビルドする、という有様(笑)。それでもデバッグモードでのビルドに要した時間は1時間弱。今のPC、今度の3月で4年になるし、そろそろ新しいPCに乗り換える時期にきたかも。
ライブラリをデバッグモードでビルドするのに1日かかったあと、ようやくデバッグ再開。ライブラリの奥底までステップインしてようやく分かったのは、環境変数MAGICK_CODER_FILTER_PATHとMAGICK_CODER_MODULE_PATHを定義しておかなければいけない、ということだけだった。

まあ、そんなドタバタはあったものの、ImageMagickライブラリ(より厳密には、ImageMagickにアクセスするためのC++インタフェースクラスライブラリ)を使うと、非常に簡単にJPEGファイルの縮小ができた。以下にサンプルコードを示す。

#include <Magick++.h>      //このファイル1つをインクルードすればライブラリの全機能が使用可能
using namespace Magick;

int main( int argc, char **argv )
{
   InitializeMagick(*argv);   //exeファイル名を引数としてライブラリを初期化

   try{
    Image xImage;   //画像データを保持するオブジェクト

    //jpeg画像を読み込む
    xImage.read( "sample.jpg" );

    //元画像の25%に縮小
    unsigned int uWidth = xImage.columns(), uHeight = xImage.rows();  //画像の幅と高さを取得
    Geometry xGeometry( uWidth/4, uHeight/4 );  //サイズを定義するクラス
    xImage.resize( xGeometry );

    //jpeg画像を保存する
    xImage.write( "sample_small.jpg" );
   }
   catch ( Error& rxError ) {
    std::cout << rxError.what() <<std::endl; //エラーの内容を表示
   }
}

このImageMagickライブラリ、画像ファイルの読み書きとサイズ変更だけではなく、さまざまな機能を持っているらしいので、画像を扱うアプリを書く機会があれば勉強してみたいと思う。そんなことはさておき、同義語辞書を作成するためのGUIをまだ全然考えていない。うーん・・・。

| | コメント (2) | トラックバック (0)

ディスコグラフィ作成:とりあえずデータ入力は終わったが・・・

ディスコグラフィ作成に取り掛かり始めてはや20日。どうにかこうにか年内にデータ入力だけは終わりました。入力したCDの枚数700枚ちょっと(DVD10枚、VHS1本も含む)。

データを入力するためにCDを棚から取り出すたびに、
「このCD、いらんわ」
と選別もしたのですが、選別されて「売却」のカテゴリーに入ったCDは約200枚。うち25枚はアマゾン・マーケットプレイスに出品できなかったのですが、残りの約175枚を延々とアマゾンに出品するのにトータルすると丸1日分くらいの労力は使ったかも(^^;)
プラケースがホコリをかぶってたり、CDが汚れてたり(汚れを栄養にしたのか、カビが生えてるものも・・・)していて、ウェットティッシュでプラケースを拭いたり、CDを食器洗い用洗剤で洗ったり、といった作業が大変でした。

入力したCDの枚数にして500枚に達した頃から、データファイルの読み込みが遅くなる、という事態が発生。
データはUTF8エンコーディングのタブ区切りテキストファイル3つに保存していたのですが、読み込み処理が終わるのに50秒もかかる有様。
ファイル読み込み部分のC++のソースを読み返してみると、UTF8からワイド文字列に変換した後のファイルの内容を1行1行分割してvector<CString>に格納している(厳密に言えばLPCTSTR→CStringの変換コンストラクタ)のが遅い原因と推測し、行ごとに分割したテキストデータ(正確に言えば、バッファ上のデータの各行の先頭を指すLPTSTR)をvector<LPTSTR>に格納することと、その他細々した改良で、50秒を15秒まで短縮。それにしても、3つのテキストファイルは合計しても1万行にも満たないので、15秒はまだ時間がかかりすぎ。
そこで、コードの呼び出し回数と処理時間を計測する、プロファイリング用の小さなライブラリ(ソースファイルとヘッダファイル1つづつ。本当に小さい)を1時間ほどでチャチャっと作り、テキストの各行を解析するコードの1行1行の処理時間を計測。すると、1行分のテキストをタブ文字ごとに区切ってvector<LPTSTR>に格納していた部分で、vectorをresizeしたり、データをpush_backするのに最も時間がかかっていることが判明。で、結局、vector<LPTSTR>ではなく、LPCTSTRの配列に、タブ区切りされた文字列の先頭アドレスを格納することで、15秒を5秒に短縮。
もともとのコードでは50秒かかっていたので5秒まで短縮したので、処理速度10倍!1万行弱のテキストデータを処理するのに、C++で書いたネイティブコードで5秒なら妥当なところかな。

そんなこんなで700枚強のCDを入力し終えた今、次に考えないといけないのは、以前の記事でも触れた「同義語」の辞書を作成する問題。1つ前の記事のコメントでDさんに提案して頂いた、googleのサイト内検索、というのもいいかな、と思ったけれど、googleで「ベートーヴェン」で検索をかけたところ、「ベートーベン」はヒットしたが、「Beethoven」はヒットしない。
「ベートーヴェン」で検索をかけたら「Beethoven」もヒットして欲しいし、「弦楽四重奏」で検索したら「String Quartet」(英語)も「Streichquartett」(ドイツ語)も「Quatuor à cordes」(フランス語)もヒットして欲しい。

そうすると、やっぱり自前で同義語辞書を作る必要があるなぁ・・・。
同義語辞書を作るアプリを作らないといけないが、データ構造を考えるのはさほど難しくなさそうではあるが、どんなユーザーインタフェースにしようか、というところで悩んでしまう。
これは来年(といっても2日後^^;)の課題です。

明日は、東京文化会館でベートーヴェンの中期と後期の弦楽四重奏曲を聴き倒すコンサートに出かける予定。しかし、寒波が南下しているというニュースがあるし、彦根や岐阜の明日の天気予報は雪だから、新幹線、事前に予約していたのより1時間早いのぞみに変えようかなぁ・・・(明日の朝の時点でその列車の指定席に空きがあれば)。

| | コメント (0) | トラックバック (0)

ディスコグラフィ作成の尽きない悩み

ディスコグラフィを作成しようと思い立ってから早2週間。最初の3日でCDデータの登録アプリをサクッと作り、その後は登録アプリの使い勝手を少しづつ改善しつつ、ひたすらデータ入力の日々が続いて10日を過ぎました。

入力したデータはCD(DVD10枚程度とVHSテープ1本含む)500タイトルあまり。それでも、まだ半分強です・・・(はぁ)。
入力作業の間に、
「このCD、多分5年以上聴いてへんわ。これからも聴くことなさそうやし売りに出そ。」
というCDが9枚出てきました。全ての(というか、入力しようと思っている対象の)CDを入力し終わって売りに出すCDがそろった時点でアマゾン・マーケットプレイスに登録する予定。

そんなこんなのデータ入力の日々が続き、データが貯まってくるうちに深刻な問題が発覚。例えば、"弦楽四重奏曲"を検索した場合、"弦楽四重奏曲"だけでなく、"String Quartet"や"Streichquartett"、"Quatuor à cordes"もヒットして欲しいなあ、と考えたのです。
ここで、"弦楽四重奏曲"、"String Quartet"、"Streichquartett"、"Quatuor à cordes"を「同義語」と呼ぶことにすると、同義語の辞書を用意しないといけない、しかもCDを1枚入力するごとに同義語も登録していく必要があるかもしれない、という問題が出てきます。

同義語の辞書を効率よく作成するにはどうすればいいか?考え始めると、いろいろ課題は出てきそうですが、とりあえず、CDのデータを入力し終えた段階でじっくり考えることにします。

| | コメント (3) | トラックバック (0)

ディスコグラフィ作成に足を踏み入れてしまった

12月10日の記事の中で、「ホントにディスコグラフィ作る気なのか・・・、と現在自問中(^^;)。」などと書きましたが、結局作ることにしました。

10日から今朝までの3日ちょっとで、ササッとデータ入力用のアプリをVC++2005で作成。
プログラム的にはごくありふれた、MFCのダイアログベースのアプリではあるものの、ShiftJISにはない文字(例えばドイツ語のウムラウトやフランス語のアクセント記号つき文字など)も入力したいので、Unicodeモードのアプリとして作成。
以前から文字列を_T()マクロを使って記述する習慣をつけていたので、コーディング上は、データファイル(UTF8で作成)とアプリ内部(ワイド文字列を使用)との相互変換にちょっと手間取ったくらいで、それ以外は特に問題なし。
データ入力ができるようになったら、「CDのジャケットをスキャナで取り込んでJPEGファイルとして自動で保存する機能もつけたいなぁ」と考え、Vectorでスキャナ制御ライブラリを検索するとSCANCTRLというのを発見。OLEオートメーションDLLとして実装されているので、VBやVBAからも使えるのがうれしい。インストールしてから2時間あまりの試行錯誤で、スキャナから取り込んだ画像を無事JPEGファイルとして保存することに成功。

アプリは作成できたものの、まだ完全にバグが取れた自信がないので、デバッガからアプリを起動し、簡単に直るバグを発見した場合は、デバッグ中にちょいちょいとコードを修正してはエディット・コンティニュー機能のお世話になりつつ、ひたすらデータを入力し続ける・・・。

結局、朝から晩までかかって今日1日で入力したデータはCD60枚分!
しかし、それでも手持ちのCDの、おそらく10分の1にも満たない量。
全部入力し終わるのはいったいいつになることやら・・・。

とりあえず、200枚か300枚分くらいのデータを入力できたら、PCサイト用と携帯サイト用のデータ検索CGIを、何年ぶりかでPerlで書いてみようかな。

| | コメント (0) | トラックバック (0)

より以前の記事一覧