ユーザー (#1)2007年1月アーカイブ

　コードの最適化を進めています。とりあえず、マルチスレッドでの処理の無駄を除いたところで、設定画面を修正に取り掛かりました。ImageGeterの設定は当時の未熟な技術のため、古臭い設定画面でしたが、今回修正し終わると、MagicMirrorやNanDoKuと同じ分かりやすい設定画面に変更されます。この辺で、機能追加はありませんが、一旦ベータ版の公開を行なおうか考えています。熱望される方はコメントでどうぞ

　ImageGeterのリファクタリングを行なっていて、なんとなく難読化処理を行なってみたら、実行時にエラーが発生するでは有りませんか。「またもやNanDoKuにバグ発生か？怪しげな記述をしたかなぁ」などと考えながら、原因追求をしていくと
System.Windows.Forms.Application.SetCompatibleTextRenderingDefault(false);
という、C# 2005ではお決まりの記述でエラーが発生していることが分かりました？

なぜ？

しかも、このエラーDebugビルドで発生して、Releaseビルドでは発生しない？

なぜ？

さらに原因追求していくと、アセンブリの逆コンパイル→コンパイルのみで発生する
NanDoKuは関係ないようだし

迷宮入りか？

　昔作った汚いコードと格闘しています。実はリファクタリング＋αで、パフォーマンスが改善されるのでは？と思うような個所いくつかあったり。

　現状では、初期設計の問題で追加できなかった機能や、その後得た技術で改善できる点などしたいことがいろいろ有るのですが、ユーザーサイドの視点での意見を得るためにアンケートページを追加しました。

　なんとなくImageGeterをC# 2005でコンパイルしてみました。Framework 2.0ではスレッド処理関連が厳密になったので、当時未熟だったソースではエラーが多発すると思っていましたが、思ったほど悲惨な状況にならないのは驚きでした。うまくやれば、Framework 2.0で充実したライブラリ機能に乗っかることで、速度アップとコードのスリム化が実現するかも。　というわけで、ImageGeterの開発を再開しようか迷っています。
　当初、手(t)抜きプログラムとして「ImageGeter」と命名していましたが、最近「ImageGetter」と記述される方が多いので、この際名称の変更もしようかなぁ。

　先日バージョンアップしたImageGeterで不具合を発見してしまった。Google画像検索のＨＴＭＬ解析に問題があって一部のＵＲＬの「http://」部分が重複してしまうようです。近いうちに修正しなければ．．．

　いつの間にか、GoogleとYahoo!の画像検索の取得結果が変更されているために画像の自動ダウンロードが行なえなくなっていました。報告していただいた方には感謝しています。で、この点について今回修正バージョンアップを行ないました。　今後も今回の様な仕様変更があった場合にはバージョンアップをして行かないといけないのだろうか？何かいい方法が無いか現在模索中。

　難読化に関しての不具合は出尽くしていると思っていいましたが、まだバグが潜んでいました。イテレータのインナークラスの命名が想像を絶する奇怪さのため思ったより時間がかかり、年を超えちゃいましたね。

　最近何だかこのソフトの需要が増えているのですが、これは難読化が認知されてきたのか、.NETのプログラマーが増えたのかどちらなんでしょうかね