すでに販売してないでしょうが、東芝のTranscube ってハードディスクビデオを持ってまして、こいつは録画した内容をMPEG2ファイルとしてPCにダウンロードする事ができます。で撮り溜めてはUWSC を使って自動でPCに移動、時間があったら見ようと思ってたら結構たまってしまいました orz

そのうち毎週録画していた番組がすでに最終回を迎えていたにもかかわらず録画し続けたものが結構増え、これを一気に削除したいなと。Transcubeのプログラムをアップデートするとファイル名が番組のタイトルになるという機能が付くのですが、これで自動ダウンロードをすると毎週録画の番組は古いファイルが上書きされてしまうため、あえて無意味な英数字の羅列がファイル名になる状態で使用してました。よってファイル名で削除する方法は使えず。

削除したいMPEGファイルの共通点は時刻。録画終了時刻がファイルの作成時刻になっているため、これを使えば確実に目的のファイルを選び出せます。しかし共通しているのは時刻だけで、日付は曜日以外に共通性なし。こういう時PowerShellだと以下のようにできます。

dir *.mpg | where {$_.LastWriteTime.Hour -eq 21 -and $_.LastWriteTime.Minute -eq 54 -and $_.LastWriteTime.DayOfWeek -eq 0} | del

dirコマンドで拡張子mpgを持つファイルのオブジェクト(System.IO.FileInfo)配列を作成、次のwhereでそのオブジェクトのLastWriteTimeが日曜日21:54になっているものだけを抜き出し、delコマンドで削除します。whereコマンドの指定が正しいか確認したい場合、最後のdelコマンドを打たなければdirコマンドの様に選ばれたファイルのリストが表示されます。

分かっている人には当たり前の内容ですね。UNIXでもPerlとか使えば可能でしょうがこちらの方がスマートですし、これが.NETというVisual StudioやASP.NETなどと同じ基盤を背景にして実行されているというのが興味深い。私としてはWindowsって95のころはつまらなかったのですが、バージョンが進むごとに面白くなってしょうがないです。でも7はVistaとほとんど変わりなしみたいで、つまらなさそうｗ

[2011/4/7 追記] アクセスログを見ると最も古いファイルを消すという内容で検索が入ってました。以下のでどうでしょう?

(dir | where {$_ -is [System.IO.FileInfo]} | sort LastWriteTime)[0] | del
(dir | where {$_ -is [System.IO.FileInfo]} | sort LastWriteTime)[0..2] | del
(dir | where {$_ -is [System.IO.FileInfo]} | sort LastWriteTime)[0,2,4] | del

2行目は最も古いのから3つ、3行目は最古・3番目・5番目(どういう状況だ?)を削除。便利だ。

以前にも何度か書いた通り私はうつの治療中なのですが、通常3割医療費自己負担のところを障害者自立支援法によって１割負担になってます(この法律成立前は5%負担だったので、これから比べると負担増なのですがw)。

しかしこの法律の適用には対象の病気で治療中のほか、ある一定の収入がある人は対象外になります。先に書いた通り元々が5%だったためそこからいきなり6倍の3割は急激過ぎるという事で、一定期間収入に関係なく法律を適用する特別期間が設けられてまして、今年の３月末で特別扱いが終わる予定でした。

が、どうやら特別期間が延びるらしい・・・。いいのか、国家財政? 去年のガソリンといい、給付金といい、国民生活のためとか現状を見極めてという名のぐだぐだ感が漂ってきます。

この分だと地デジ完全移行も先送りですね。個人的には移行時期延期よりもB-CAS 廃止を希望w。

「～自分のプログラムを100回疑え｣。大学でC言語を勉強していたときの先輩の言葉です。

別にこれはどの言語でも当てはまる事なのですが、特に(.NETを除く??)C/C++言語は実行時に変数型や値のチェック、自動型変換などほとんどやってくれないため、高速で曲芸的なことをするプログラムが書ける一方奇妙なバグを生みやすく、また奇妙ゆえ原因も分かりにくく、ついコンパイラやライブラリに問題があるのではないかと疑いたくなります。

しかしマイナーな製品ならともかく、MicrosoftやGNUのコンパイラ・ライブラリは出荷前はもちろんの事、出荷後も世界の多くの人が使用して動作を確認しているわけでして、そう頻繁に問題に出くわすわけはない。99%自分の書くプログラムに問題があるはずだから何回でも見直しなさい、というのが上の言葉の解釈です。

今日はTcl から呼び出されるコマンドのWindows DLLをVisual Cで書いていたのですが、実行するたびに使用メモリが増えていく、いわゆるメモリーリークに悩まされていました。使用メモリの大きさから、この部分のメモリが解放されなければ計算上はつじつまが合うというのは目処をつけたのですが、解放する処理は行われているはずでなぜ解放されないのか分からない。Tcl拡張コマンド用DLLという特殊な物でもあり、なにかメモリを解放するライブラリにバグがあるのではと頭をよぎったのですが・・・

やっぱり私が悪うございました orz

別の箇所でまったく同じ量のメモリを確保していて、そちらを解放していなかったというお粗末な内容。

ちなみに私の経験の中で自分のプログラムが悪くなかった(と思う)のは、Windows 95のTrueTypeを描画するAPIだけです。まったく同じプログラムをWindows NTで実行したら何の問題も無かったので・・・