We Will Rock You@新宿コマ 今年も

今年も観にきました。
キャストは去年と同じくオーストラリアメンバーなのですが、
数人が入れ替わっていました。(キラークイーンとオズ)
他にも、台詞回しとか演出とかがすこーし変わっていたような。

しっかし、これ観るの通算で4回目になるんだな。

3Dなら

これからのデスクトップ環境が3Dになっていくのであれば、
もうマウスなんてかったるい物は使いたくないです。
すでに言われていることだとは思うんだけど、データグローブでいいじゃないか。
2次元だったカーソル操作が3次元になる。オブジェクトの3次元的ドラッグもできる。ファイルを投げ捨ててゴミ箱に入れてみたりね。
それと、マウスジェスチャーの替わりにハンドジェスチャー。
空中で、{手話, マジック, 太極拳}みたいな動きをすると、ファイルを開いたりアプリケーションを起動したりするわけ。
きっと楽しいと思うけれどなあ。

この梨食べて元気出せ

実家から送られてきた梨が1個痛んできたので、グラニュー糖と一緒にぐつぐつ煮込んでいる。
だいぶ、ジャムっぽくなってきた。

ちなみに梨は写真のようなものです。

.NEt Framework 3.0でた

Microsoft .NET Framework 3.0 Redistributable Package
いそがしくなるかな？

VSUG DAY 2006 Winter

参加しようと思いますー。
カメラ持って行くかな。

続: System.Net.Mail.SmtpClient と Quoted Printable

.NET Framework 2.0のSystem.Net.Mail.SmtpClientクラスでメール送信を試してみていますが、件名が勝手にQエンコードされてしまいます。
日本語メールなら普通Bエンコードだろー。
と文句をたれつつも、回避策はあって、MailMessage.SubjectEncodingプロパティはNothingにしておき、自前でBエンコードした文字列をSubjectプロパティにセットしてやればよろしい。

crypt32がイベントログにエラーを吐く

Windowsサーバークックブック―ネットワーク管理者のためのレシピ集



おれおれ証明書を使ったHTTPS接続で出る場合があるだよ。
http://support.microsoft.com/kb/317541/ja

この問題を解決するには、インターネットに接続するか、ルート証明書の更新コンポーネントを無効にする必要があります。

メモしておこう。

crypt32を含むWindowsの詳細について知りたい人はこの本が参考になる。日本語訳も出ている(インサイド Microsoft Windows)けど、日本語訳だと上・下巻に分かれてしまうし、翻訳は読みにくかったりするので、原書で買ったほうがおすすめ。ほんとですよ。


Microsoft Windows Internals: Microsoft Windows Server 2003, Windows XP, and Windows 2000 (Pro-Developer)



こういうときに限らないが、Windowsのトラブルシューティングに非常に役立つ本がこちら。


.NET&Windowsプログラマのためのデバッグテクニック徹底解説 (マイクロソフト公式解説書)


HTTPSと暗号の関係について知りたいならこちら。


暗号技術大全

夏カレー

挽き肉と夏野菜のカレー。
スパイスは、ターメリック、カイエンペッパー、パプリカ、クミン、フェネグリーク、ガラムマサラ。コリアンダーは切らしてた。
しょうが1個はすりおろし。にんにく5片は絞り器（マッシャー？ラーメン屋にあるやつ）で潰す。
野菜は玉ねぎ1玉、にがうり半本、人参半本、セロリ1本、オクラ5本、なす2本、ホールトマト1缶。なす以外は小さく切る。
挽き肉は合い挽き。カレー用の粗挽き。
味つけは塩メイン。ちょっとだけ醤油。スープの素などは使わなかった。
念入りに炒めて、水分が飛んできたらプレーンヨーグルトと水を加えて煮る。

なかなか美味しくできました。

友人参加のライブ＠大塚

Tower of PowerのコピーでPower of Tower。
ホンセク５本(ペット×２、サックス×２、ボントロ×１)で豪華。
女声コーラスもはまってた。



本家の動画はこちら。

TcpClientのメモ

.NET Frameworkに用意されている各種ネットワークアクセスクラス(WebClient, WebRequest/WebResponse, SmtpClient)ではなく、あえて低レベルのTcpClientを使うときもあります。そんなときのための注意点を。

ストリームの終わりをどのように判断するか、これは悩ましいところですが、NetworkStream.DataAvailableを使うのはやめておいたほうがいいです。送信元がデータを送るとき、いつでも全部まとめて送信するわけではないからです。たとえば、ある瞬間にはDataAvailableがfalseになっていても、1秒後にはtrueになったりします。「じゃあ、NetworkStream.DataAvailableがfalseならしばらく待ってみて、それでもfalseだったら読み取り終了にすればいいじゃないか」というのは筋が悪いです。いったい何秒まてば十分なのかは誰にも分からないですし、それに無駄な待ちが必ず発生することになりますしね。
結局のところ、規定の長さに達するまでStream.Readするか、またはデータの区切り(CrLfなど)が届くまでStream.ReadByteを繰り返すか、そのどちらかを選択するのがいいでしょう。もちろん、どちらを選ぶかはプロトコル次第ということになります。そのように実装すると、データの終わりを受け取るまではブロックすることになります。ですので、適切なタイムアウトは必須でしょう。

データの区切りが(CrLfなど)決まっている場合はStream.ReadByteを繰り返せと書きましたが、反論が2つ考えられます。1つ目は「区切りがCrLfなら、StreamReaderを使ってReadLineした方が簡単」という意見と、もうひとつは「1バイトずつStream.ReadByteするのは遅い」という意見です。

最初の意見ですが、もし送られてくるデータが全て文字列で、しかも最初から最後までエンコーディングが固定されているのなら、そのエンコーディングに対応したStreamReaderを使うのもいいでしょう。ですが、そうでないなら、つまりエンコーディングはデータを受け取るまで分からないとか、あるいは途中からは生のバイト列が必要になるとか、そういう場合はStreamReaderは向いていません。StreamReaderはストリームの先読みをして、内部でバッファリングします。ですので、「次の行からはエンコーディングの異なるStreamReaderを使う」とか「次の行からはバイト列」といったときに、ストリームの位置は次の行の先頭よりも先に進んでいます。要するに、StreamReaderを使った場合は、もう元のStreamは使えないと考えるべきなのです。(天邪鬼な人はISO-8859-1エンコーディングを持ち出すかもしれませんが、その議論はここではしません。「できるけど、ムダが多い」とだけ述べておきます。)

もうひとつの意見、つまりReadByteは遅いという意見ですが、それは生のNetworkStreamを1バイトずつ読み取るから非効率なので、そういう時はBufferedStreamでラップしてやればいいのです。もちろん、BufferedStreamは内部でバッファリングしますから、BufferedStreamを使った場合は、もうもとのStreamは使えないことに注意しなければなりませんが、大きな問題にはならないでしょう。