心のおもむくままに

TVやラジオはあまり見たり聴いたりしないのですがNHKの番組で、見るともなしに見ていたTVとFM番組がありました。
この年度末の番組編成の変更で、TV番組は新番組に変りFMも女性のパーソナリティが変更になりました。
どちらも朝の番組で、起きてから仕事を始めるまでの間に見たり聴いたりしていました。
いわば1日のリズムを作ってくれていた番組でした。
なんだか寂しいのです。特に月曜の朝、目覚ましラジオから流れてくるパーソナリティの声がもう聞けないなんて・・・。
2年近くの間に、すっかり遺伝子に刷り込まれてしまったようです。
全ての物事はいつか終わる、とわかっていても、そして別にファンになったと言うはずでもなかったのに、もうしばらく続いて欲しかったと思う自分に気がついて、オレって保守的なのかなあ、とか思ってしまいます。

「本の旅人」に連載されている大島弓子の「グーグーだって猫である」は先月から飼い猫ビーの行方不明を描いています。
先月はちょうどフーちゃんが行方不明になったときで、他人事ではありませんでした。
大島さんの心配が痛いほどよくわかります。
ケージを持って近所をさまようあたりは自分と重なります。
たぶん来月の連載で結末がわかるでしょうが、願わくば、フーちゃんと同じように、ビーが帰ってきてハッピーエンドになりますように・・・。
何気なく過ぎていきますが、けっしてあたりまえではない日常の幸せをかみしめている今日この頃です。

週末は、久しぶりにASP.NET(C#)の保守作業でした。不具合の原因はすぐにわかったのですが、修正で手間取りました。
ある箇所でSQL文が意図したとおりに動いてくれないのです。WHERE句で指定した日付の条件がまったく効いていないように見えます。ところがSQL*PLUSの確認ではきちんと動いています。
最初はOracle9iのバグかもしれないとも思いました。パッチ類を何も入れていなかったので・・・。
終いには、日付に不等号って使えるのだっけ、というところまでも疑いました。
最後に判明したのはコーディングミス。SQL文は正しかった。それをコマンドオブジェクトのCommandTextに設定するところまでは正しかった。
ところがDataReaderを作るために使ったコマンドオブジェクトが、SQLを設定したのと違う、外側のループで使っているコマンドオブジェクトになっていました。
微妙に違うSQL文を実行していたことになります。
コマンドオブジェクト名が、MyCommandとかMyCommand2とか紛らわしい名前になっていたのが発見が遅れた理由です。
データアクセスの部分はサンプルコードをコピーして使うことが多いので、オブジェクトの名前とかがみんな似ているのです。
先日も書きましたが、正しいと信じているコードの中でバグを探すことの難しさを示すよい例でした。

一度は経費節減のため購読をやめようと思った「日経システム構築」でしたが、改めて目を通すと参考になることも多く、購読が続いています。
今月は「ユーザーとベンダーの壁を崩せ」で、プロジェクトにおけるユーザの役割、ベンダーの役割を事例を交えて論じています。大規模開発には関わっていないので、そのまま当てはまることはないのですが、それを縮小したような事例を経験することはあります。
コミュニケーションにおける言葉の表現が大事だと言う主張には納得。
あと気になった記事は、連載で「WEBアプリケーションをセキュアに」。仕事用のHPに載せているサンプルプログラムが大丈夫か、心配しながら読む。・・・大丈夫でした。
でも雑誌が届いて最初に読むところは書評なんですよね・・・。

日経コンピュータの3/22号の特集は、「トラブルの根本原因を絶つ　レビューを見直せ」でした。
内容は古色蒼然としたレビュー礼賛。30年前のお話と同じです。
レビューに関しては、ワインバーグとフリードマンの「ソフトウエア技術レビュー･ハンドブック」とGilbの「ソフトウェアインスペクション」で語りつくされていると思います。
その後、ロイスの「プロジェクト管理」ではレビューのメリットが強調されすぎるという意見も出、またXPではレビューに関しては何も言っていません。
議論が一方の方向へ振れると、その反動で次には反対側に振れるというようなことが起こりますが、最近はまたレビュー復権なのでしょうか？
会社員時代にはレビューをやらせる立場で散々苦労しましたが、今の私の課題は一人で仕事をするときにレビューやテストをどうするかです。
建設的な設計のときと反対に、テストやレビューではプロダクトに対して破壊的な考えを持たなければなりません。この切り替えが困難なのです。

フーちゃんが帰ってきて2週間がたちました。もうすっかり元気です。出窓へのジャンプもできるようになりました。体重も以前の8割ほどには回復していると思います。
問題は、また外出させるかどうかなのですが、かなり悩みました。
最初はリードをつけて家の回りを散歩しました。猫の散歩は犬と違って、引っ張ってもついてきません。ひたすら猫の行く方向へついていくだけです。
唯一、人間の入れないところへ行こうとしたときに、引っ張って戻します。
またうずくまってじっとすることがあるのですが、人間側もそこでぼうっと立っていることになります。相当怪しい人に見えたと思いますが。いっそしゃがみこんで、じべたりあんのまねをしようかとも思いました。
で、結果的にフーちゃんはリードをつけて出るのを非常に嫌がるようになりました。
ここで決断を迫られたわけですが、信頼関係を犠牲にしても、迷子になることを恐れて外出させないか、あるいは、ある程度の野性の本能を満足させるために事故が起こるかもしれないことを覚悟で外出させるか、です。
結局、フーちゃんも今回の事件である程度学習したはずだと言う予想のもと、時間限定で外出させることにしました。早朝と夜です。
人間の活動している時間帯はどうも危ない気がします。今回の事件も人間の手がかかわっているのではないかと疑っているのです。
実は玄関前にまたオス猫が集まって、ミャオミャオとフーちゃんを待っている状態が復活していて、これも少々危険だとは思っているのですが・・・

VB.NETで開発しています。このところ悩んでいるのが、Accessのmdbデータベースのoleオブジェクト型のフィールドにOLEドキュメントを入れたり、出したりするにはどうしたらよいかということ。
VB6ではOLEコンテナコンポーネントがあって、データベースのコンポーネントのフィールドに対応付けることができました。何も考えなくてもOLEコンテナにOLEオブジェクトを入れれば、データベースに入ってくれました。
またAccessを開いて、OLEオブジェクト型のフィールドをダブルクリックすることで、OLEドキュメントを開くことができました。
VB.NETではこのOLEコンテナコンポーネントがありません。OLEオブジェクト型のフィールドにOLEドキュメントを入れるときには何らかの方法でSerializeしてBYTEの配列として代入することになります。
しかし、代入したものをDeserializeして取り出すだけならいいのですが、AccessのフィールドをダブルクリックしてOLEドキュメントを開くことはできそうにありません。
結局、OLEドキュメントを一旦ファイルにセーブして、FileStreamをつくり、これからBinaryReaderを作ってバイト配列を作ると言う回りくどいことをやる羽目になりました。
まだ正常に動作するかどうか試していないのですが・・・。

使える時間は目いっぱい使っています。あとは削れるのは睡眠くらい。
タイムリミットまでもう少しあるので、今から睡眠を削るのはきつい。かえって効率が落ちそうです。
となると普段の仕事の効率を上げるしかありません。
いかに賢く省略ができるか？
CMMに従っていてはできそうにないことをやるつもりです。
ここがSOHOの強みかも・・・。

久しぶりに多忙な日々です。
こうなってくると確定申告を税理士さんに頼んでよかった。かなり高かったですが・・・。
また仕事ではいつものようにnetの情報に助けられています。先人たちの情報公開に感謝。
今はただスケジュール通りに終えることに全力を尽くしています。
また熱なんかがでないよう健康管理にも注意。

.iniファイルは16ビットwindowsの名残りです。その後、アプリケーション固有の情報はレジストリに書かれるようになり、現在ではXMLファイルにセーブすることが推奨されています。
今、お仕事でVB.NETで作っているシステムは、.iniを使う仕様です。
これでどつぼにはまりました。
iniファイルI/O用に定義しているKERNEL32の関数でByValで渡しているパラメータが、壊れるのです。
セクションの名前なんかをStringにしてLOOPの中で持ちまわっていたのですが、これだと最初のiniファイルアクセスで壊れます。
しようがないので、関数を呼ぶ直前に変数に設定するようにしたのですが、こんなこと知らないのは私だけ？