平日だったためかイメージしているアキバよりも活気がなかった感じです。PCパーツショップの通りは、ジャンクパーツのコンテナが道に並んでいないとね!

今日はこんなものを調達してきました。(覚え書き)

メニューバーをクリックすると気に間違ってクリックすることがあって、とくに「書き込む」ボタンは結構良いボジションにいるので間違ってクリックするとドライブがオープン。これが過去に何度もあったので消したいのです。

ちなみに、これはXPの時代ではウィンドウの左側にありました。左側にあれば間違ってクリックすることはないのですが。また、XPだとパフォーマンスの設定で非表示にすることもできます。

インターフェースって難しいね。

とはいいつつ、残高だけでも確認だけると便利ですよね。実はアクセスジェイのテレフォンアクセスの体験サービスとして残高照会をするサービスが提供されているのです。

• ご利用時間: 平日 7:00～23:00 / 休日 9:00～21:00
• 対象口座: 普通預金口座
• 電話番号: 0120-86-8973

ナビゲーションは以下の流れになっています。

1. 0120-86-8973へダイアル(携帯OK!)
2. [支店コード]#
3. 01(=普通預金口座)#
4. [通帳番号]#
5. [通帳に記帳されている最終残高の下4桁]#

これを使うと特に申込や費用を必要とすることなく残高照会できます。携帯でも使えるフリーダイアルというのがすばらしい。常陽銀行ユーザーはご活用あれ。

• 常陽ダイレクトバンキングアクセスジェイ・サービスのご案内

Windows Media Playerのライブラリのインターフェースに慣れていて、できればWMPでASIOへ出力しようと試行錯誤してみたのですが、うまくいかなかったので乗り換えです。一応プラグインとしてはASIO Window Media Player Pluginがあるようです。自分の環境では動かなかったですが。64bitとかが原因かもしれません。

DTMをするわけではないので、ASIOで出力する必要があるかどうかはナゾですが、Direct Showを経由するよりは余計なフィルタがなくて音が良さそうじゃないですか。

で、実際に聴き比べてみた感じ、ASIO出力の方がクリアな音が出てました。プラシーボではなく、同じ音源の同じポイントで比べましたよ。低音のボヤケがなくなったことと、一つ一つの楽器の位置がわかりやすくなった感じです。

オンボードオーディオ・自作2.1chスピーカー→サウンドボード変更(PRODIGY 7.1XT)→スピーカー変更(BOSE FreeStyle II)→出力形式変更(ASIO)、といろいろ進化してきましたが、もうどのステップにも戻れないです...。音の環境は投資すればするほど良くなっていくのが困りますね。まぁ今のハードウェアのレベルは出し切っていると思われるので、しばらくは今の環境で十分かなぁと思うところです。パソコン使って音楽再生している中では、今の環境は結構いい音出していると思いますよ。

PCを組み立てる当時、64bitに対応していてそれなりの価格でマトモなサウンドカードがこれくらいしかなかったのでBetaドライバでも使用していたのですが、2年越しでやっとこさ正式に対応してくれたみたいです。

Betaドライバの時はマスタボリュームがWindowsのMMEとバッティングしていることや、このサウンドボードのひとつのウリであるASIOが使えないなどいくつかの問題があったのですが、今回のドライバで一通り修正されているようです。

このサウンドカードはかなりオススメなのですが、価格.comでは掲載がなくなっていますね。もう販売していないのかな。性能対コストのパフォーマンスは非常に良い製品と思います。

• AUDIOTRAK Japan

あぁ腹へったけど食う元気がでない。つーか作るのも、買いに行くのも面倒くさい。紅茶に砂糖どっさり入れて、血糖値だけ上げて、空腹に気がつかないうちにさっさと寝てしまおうかと思う。とかいってブログは書いているけど。

いろいろ忙しかったり大変だったりするけど、今しかできないことだと思って楽しんでやっているところでございます～。ってことでおやすみ!

どこかでGoogleはお金の入口と出口を押さえてしまおうと企んでいる、というような事を聞いた気がするが、楽天は別の意味でこれを実現しようとしているのだろうか。GoogleはAdSenseで広告費の出入口を押さえつつあるが、楽天はショッピングと銀行という生活費の出入り口を押さえようとしているのかと。

ところで、楽天バンクとか既存の楽天の金融サービスとはどう関わっていくのだろう。

• ネットで番組配信　在京、在阪１３局本格参入

と喜ぶのもつかの間、首都圏は東京、神奈川、千葉、埼玉だけらしい。しかもお気に入りのNack5はまだ始めないようだ。残念。

IPベースでエリアを判別しているということは、視聴可能エリアのIPさえあれば良いわけだ。東京にありそうな激安VPSとかにSoftether入れて、配信元IPだけroute addすればなんとかなりそうだな、とごにゃごにゃ考えてみた。

今日行ったクライアントは今まで見た中で一番ひどかったかもしれない。ひどいというか可哀そう。

まず悪いのは本人。パソコンとかインターネットがよくわかっていないのに、営業マンの言う事をホイホイ信じてパソコン・アプリケーションを購入してしまった。しかもシバリの強いリースで。よーく考えてみれば、その人がそこまでのITソリューションが必要でないことは自明である。

次に売った人。どう考えても売りたい商品がその人にマッチしていないことくらいわかるだろう。明らかに相手がパソコン関係に疎いことを逆手に取ってだましに近い状態で買わせている。パソコンとアプリケーションで120万とは、まぁいい商売しているじゃないか。

そしてリース会社。契約の際にリース会社の人も立ちあったらしいが、生活状況を見れば月数万の支払いを継続していくことは難しいことくらい予想できるだろう。ってかあの状況でリースって通るんだな!!

そしてトドメは契約書の内容。リース契約期間が60ヶ月になっていたが、「契約期間終了1ヶ月前までに甲乙のいずれかが異議を申立てしない限り、自動的に1年間延長する」と書いてあった。っておい!完済しても契約きらない限り月額支払い続けるのかいな。回収じゃないのか?これはひどい契約だ。おそらく本人は5年後に解約通告しなければいけないことを忘れているだろうし、そもそも契約するときに気づいてよ。

第三者の目から見れば、あれは完済する前にバンザイしそうな気がする。突如改心して本人が本気になってITを活用しようと努力すれば、支払った対価ぐらいには見合う成果を残せるかもしれないが、希望は少なそうだ。

どうにか助けてやりたいという気持ちもあるが、契約書がある以上どうにもならん。見守ることもできず、見放すしかできないことが本当に虚しい。自分はただ単にネットの設定(ネットの契約もおかしかったがな!)に行っただけなのに、後味の悪い帰りになった。

どうやらオイル交換したときにオイルフィラーキャップを閉め忘れてしまったようです。なんという初歩的なミス...。そしてキャップは道路のどこかへ落としてしまったようです。途中デイズタウンあたりでボンネット内で何かが落ちる音がしたんだよねぇ。

ちなみに、とりあえずディーラーまでと思ってこんな感じのキャップで応急処置してみました。ホットコーヒーの缶を逆さにすると調度良いサイズ!ネジ山は完全にはあっていないけれど、固定は普通にできます。オイルキャップで応急処置が必要になったら使えますね。トヨタ系のネジ式なら多分使えるはず。

午前中にディーラーで注文したら午後には届いていました。素晴らしいぞ、トヨタ!ディーラーの整備士さんもオリジナリティーあふれるキャップには興味津々でした。

みなさんもオイル交換したらキャップの締め忘れがないように確認しましょうね。

ということで、本年もどうぞよろしくお願いいたします。

さてドラマのライアーゲームのSeason2が始まったみたいですね。僕好みのドラマが始まって何よりです。で、早速1話を見逃したわけですけどね。ま、いずれにせよテレビチューナー壊れちゃった(Friio壊れた!!)ので、しかるべき所で見てますけど(笑)。

ライアーゲームがドラマ化したのは2007年のこと。当時は23時台の放送だったんですよ。教育実習終わって風呂入って一息ついていると、ちょうどライアーゲームの時間。実習期間が終わってつくばへ戻ってからも欠かさず見てたくらい良く見てたなぁ。

ということで、今日の放送も早くどこかにアップされないかな!映画も楽しみだ。

ISO-2022-JPについて

• JISコードはエスケープシーケンスでASCII文字のコードか漢字のコードか切り替える
• 一言にJISコードといっても策定されたバージョンがいくつかある
• メールなどの普通のJIS文字を扱うなら、1997年のJIS X 0208を相手にしていればOK。
• 第3水準、第4水準の漢字を含めたJISなら、JIS X 0213(通称：JIS2004、ISO-2022-JP-2004)を使う。
• JIS X 0213はIANAに登録されていない(Wikipedia調べ)らしいのでメールの標準エンコードとしては使えない。
• JIS X 0213は下位互換(JIS X 0208を包括)
• JIS X 0213でエスケープシーケンスが増える。

Unicode(UTF-16)について

• Unicodeも何回もバージョンアップしているんですね
• Unicodeへの変換はアルゴリズムではできず、変換テーブルを使う必要がある
• 変換テーブルは、Unicode Consortiumとかこちらとかにある。
• JIS X 0213の変換テーブルはこちらなんかがヒットした
• JIS X 0213の文字までUTF-16に変換しようものならサロゲートペアを考慮しなければならない
• Windows VistaからサロゲートペアのUTF-16も扱っているから、プログラム書くときは結局このあたりも考慮しなければならない
• サロゲートペアってのは4バイト(UTF-16文字*2文字)使って1文字を表す方法。Ansi文字における2バイト文字みたいなものか?(ってか結局2文字かよ!Unicodeになっても後続文字かどうかを判別しなければならないなんて...)
• ちなみにDelphiでサロゲートペアを考慮するときはEmbarcaderoのページが役立つと思う

まぁぶっちゃけるとMIMEの処理を行いたいわけだけど、ISO-2022-JPの文字列をstringに突っ込むとどうなるんだろうとか、Base64のエンコード・デコードをしたときにデータを格納すべき変数のデータ型は?とかが、いろいろ分からないのです。データを全部TStream系とかarra of Byteか何かで処理すれば気にしなくていいんだけれど、そうすると文字列検索なんかが面倒になる。ちなみにIndyとかはarray of ByteをTBytesとして宣言して使っているっぽい。

まぁこんな感じで悶々と考えたわけだけれど、結論としてDelphi 2009以降がないとわからん!ってことであきらめました。とりあえずstringはすべてAnsiStringとして考えておくことにします。

それにしても寒いなぁ。今日ジョイ本行ったときについでに灯油買っておけばよかった...。