]]>
ＯＳやＨＤＤの引越しは頻繁にしていますが、リアルでの引越しはいろいろと大変です。 ネットやＰＣ周辺も何とか以前の状態に戻りつつありますが、資料などがどのダンボールに詰めたのかわからなくて、余計な時間を取られます。今週末くらいから開発環境も復帰できると言いのですが。
]]>年末にImageGeterのバージョンアップを行ないましたが、追加機能のために不具合が発生したので、早速修正バージョンの公開です。
前回の改良はコードの追加部分をできるだけ少なく、他の機能に影響が出ないように修正したつもりなのですが、やはりチェック漏れが出てしまいました。個人開発なので、機能を豊富にしていくとどうしてもテストが不十分になるので、不具合報告をしていただける方には大変感謝しています。
今後もImageGeterを見捨てないようよろしくお願いします。
]]>「べつやくメソッドクリエーター」が「2007年 窓の杜大賞」候補としてノミネートされました。このソフト自体４月にネタで作って、一ヶ月もたたないうちに開発終了してしまったので、寝耳に水でした。多くのソフトが選出され、力作ばかりなので、ないとは思いますが、こんな張りぼてソフトで何かの賞を頂いたら申し訳ないですね。
暇な人は公平に投票してください
詳細と投票先
http://www.forest.impress.co.jp/prize/2007/
ImageGeterの公開で、なんとなく.Net + Vistaでの注意する箇所がわかってきたので、過去のプログラムも暇を見つけてVista対応バージョンを公開していけると良いなぁ
]]>スレッド処理は、今時のＣＰＵではそれほどロスはないと思っていましたが、バグ取りもしにくい構造でしたし、無駄な処理が多かったのは確かなので、思い切って処理を変更しました。個人的な汎用ライブラリとして作成できたので、まぁ、これはこれで価値がありかと。
ＨＴＴＰプロトコルの処理は、バージョン１．１で処理すべき圧縮転送と、チャンク形式の転送処理を実装していなかったので、今回はしっかり対応しました。これのおかげで通信での無駄はかなりなくなると思います。コネクションの接続維持も実装しようと思いましたが、意外と対応しているサーバーが少なかったので今回は見送りました。
今回のバージョンで特に大きな問題が無ければ、正式にリリースしようと考えています。
他にも、StartsWith とか EndsWith とかも影響するようなのでちょっと見直す必要がありそうです。ContainsとかReplaceが影響しないのがさらに混乱するんですけどね。
そもそも、この仕様ってどうなんでしょう？あいまいな日本語比較より厳密な文字比較をする場面のほうが圧倒的に多いような気がするので、あいまい比較をオプションにするべきだと思うのですが。
さて、この難読化プログラム「NanDoku」ですが、実は設定ＧＵＩには無い機能が実装されています。アセンブリの設定で保存した「なんとかini」ファイルに
ExtendOverload=True
と、追加すると、さらに強烈な同一名称の使用を行なうようになります。
大体、第１位置候補の文字使用率が１０％ほど上がります。
難読化自体に魅入られた方は一度試してみてください。
当プロジェクトのプログラムはこの設定で全て難読化しているので、それなりにの実績もあります。
なぜ、効率が上がるのかと、非公開なのかはまた機会があれば．．．
レンタル品なので金銭的損失は無いのでよかったのですが、
連休前にインターネットに接続できないのはつらい。
故障早々にプロバイダーのサポートへ電話してみるも、時間帯が悪いのか一向に繋がりません。
気は短くないので、そのまま３０程度放置してみました。
空き時間に何かしようとPCを前にして凍りつきましたね。
インターネットに接続できないと何も出来ない！
困ったことにプログラムすら書けませんね。
ここまで依存しているとは正直思っていませんでした。
おかげでカーステ用のMP3データが大量に作成されました。
何とかサポートに繋がり症状を伝えましたが、予想通りのモデム交換で、３日～1週間との返事をいただきました。orz
奇跡的にモデムのカードを発見したので、おかげで、ダイヤルアップでネット接続しています。
.NET Framework 2.0 以前では文字列の存在確認で
IndexOf("あ") != -1
などという記述を大量にしていました。
最近は、
Contains("あ")
で代用することが多くなり、またこの使用法が正攻法でしょう。
通常は特にに気にしていませんでしたが、検索作業自体で数十秒かかるようになると話は別です。で、幾つかの方法を試してみることにしました。コード自体が読みにくくなる改変は避けたいので、候補は以下の3つで
(1)．IndexOf("あ") != -1
(2)．Contains("あ")
(3)．IndexOf('あ') != -1
処理速度は (3)、(2)，(1)の順で、(3)は(1)の十倍程度早くなりますね。最も、(3)は使用できる場合が限定されますが、(1)からの改変でほとんど見た目が変わらないのはいい感じです。(2)は内部では(1)を読み出していると思っていたので、最も遅いと思われましたが、検査条件を限定することで早くしていうるようで、これだけでも数倍の処理速度の差が発生します。
対象が文字列なので、すべて期待している結果が出るとは限りませんが、(1)の表記
IndexOf("あ") != -1
は、今後登場する機会はなくなりそうですね。
以上を踏まえると、大量の文章から該当するデータを探す、たとえば過去のメールデータからある文字が存在するメールを検索するようなことをする場合は、一旦、検査する先頭文字で「IndexOf('あ') != -1」と仮検査し、該当するものだけを本検査にまわす方法もありかと
]]>