今日は久々にプログラミングの話題です。

　当ウェブサイトで公開しております「DMMアフィリエイトのリンク作成支援ツール」はいわゆるWebブラウザを使ってサービスにアクセスするWebアプリケーションの形になっておりますが、Windows版のツールの開発も開始しました。

　まだまだ完成にはほど遠く、公開できる状態にはなっておりませんが、DMMサイトからの商品情報を取得して画面に出力する部分まではうまく出来たようです。Webで公開しているWebアプリケーション版と違い、こちらはサンプル画像の取得もできるようになっています。

　当初、画像を一覧形式にして表示する部分は自前で実装してしまおうかと思いましたが、Windowsに標準で搭載されているListViewの使い勝手が思いの外良かったのでこちらを利用しました。ご覧の通り、画像をグループ毎にまとめることができ、これはWindows XPから実装された機能のようで、Windows標準のエクスプローラなどにも使用されています。おかげで自前で画像ビューアを作る手間が省けました。

技術的なこと

　ソニーのヘッドフォン「MDR-CD900ST」は本来業務用として開発されたヘッドフォンですが、その音質の高さや解像度の高さからiPod等で音楽をより楽しむ目的でも利用する方が近頃増えています。

　ところがiPodなどの機器で使用しようと思った時に、一番のボトルネックになるのはプラグの大きさの違いではないでしょうか。本来なら変換プラグを使えばそのような問題はすぐに解決するのですが、MDR-CD900STの場合はすこし厄介です。

　ご存じの通り、iPod等のポータブルオーディオプレイヤーを始め、我々の身の回りにはステレオミニプラグを搭載した製品が溢れています。対してMDR-CD900STは業務用故にケーブルの先には標準プラグしか付いておらず、また製品パッケージには変換プラグの類は一切付属しません。

　そこで、当然のことながらiPod等の機器でMDR-CD900STを使おうとする場合には変換プラグを別途購入する必要があるのですが、実はこれには鬼門があります。それは変換プラグとMDR-CD900STの相性です。

「MDR-CD900STの片方の音が聞こえません！！！」というトラブルの原因の多くは変換プラグの相性です。

　不思議なことに、他のヘッドフォンでは何の問題もなく使える変換プラグが、MDR-CD900STでは上手く使えないことが多々あります。そして多くの場合、相性の悪い変換プラグを用いると片方の音が聞こえなくなります。通常、ステレオプラグをモノラルジャックに差すとこのような現象が起きることがありますが、「ステレオ→ステレオ」の変換プラグでもこの現象が起きてしまうのです。私はこれで実際に数本の変換プラグを無駄買いしてしまいました。

　そこで、本記事ではMDR-CD900STで確実に使える変換プラグを紹介したいと思います。

　ズバリMDR-CD900STで確実に使える変換プラグはVictorから出ているAP-233Aという製品（写真左）です。このほかに、iPod touchをケースに入れて使う場合には、CN-M30-Bという延長ケーブル（写真右）があるとなおベターです。

なぜ延長ケーブルがあるとベターなのか

　私はiPod touchをケースに入れて使っていますが、ケースによってはジャック周辺に設けられた穴の口径が小さく、微妙に邪魔になってしまい変換プラグが奥まできっちりと刺さりません。そこで、変換プラグとは別にプラグの根本が細い延長ケーブルが必要になります。

　大変遅くなりましたが、この場を借りて新年のご挨拶をさせて頂きます。

改めまして、新年あけましておめでとうございます。

　あいかわらず去年の11月頃から体調不良が続いており、パソコンに触れるのもつらい状況になっております。
めまい＋耳鳴り＋目の前が不意に一瞬暗くなる意味不明な症状、のトリプルコンボに悩まされており、特に耳鳴りはセミが鳴くような音が延々と鳴り続けていて鬱陶しいことこの上ないです。周りからは病院に行くように勧められていますが、恐ろしい病名を告げられるのが怖くてまだ病院には行っていません。（実は私の身内が数年前に同様の症状を訴え、病院で検査したところくも膜下出血の前兆、と言われ大至急手術をして一命を取り留めました）

　さて、今年の抱負ですが何よりも

「万人に役に立つフリーソフトやWebサービスを作りたい」

というのがあります。

　といいますのも、私が製作し自身のサイトで公開しているソフトウェアやWebサービスはパチスロプレイヤー向けだったり、Visual Studioユーザー向けだったり、アフィリエイター向けだったりと、特定の人間には需要があるものの、万人にはほとんど必要のない物であるからです。ところが世の中には老若男女が楽しめるソフトウェアが山ほどあり、私もそのような物を作ってみたいと常々思っておりましたが、まったく以て良いアイデアが浮かびませんでした。
　そこで、何かしらのアイデアが閃いた際には、是非ともそれを形にすべく頑張りたいと思います。また、同時にiOSのプログラミングも勉強したいと思っています。

　なお、去年はこのブログはコンデンサの交換の事ばかり書いておりましたが、今年は音楽活動のほうに力を入れますので、そちらの分野でもすこしでも皆様の役に立てるような記事がかけたら良いな、と思っておりますので、何卒応援の方をよろしくお願い申し上げます。

　ネットをブラブラ見ていたら、MSXパソコンの組み立てキットなるものを発見しました。
しかも、MSXというから古い商品かと思いきや現役の商品だそうです。

http://www.offshore-ww.com/gr8bit-top.html

　MSXとは1983年にマイクロソフトとアスキーにより提唱された8ビットパソコンの規格で、当時ソニーや松下、三菱、日立などからMSX規格のパソコンが発売されていました。

　実は私がコンピュータと出会い、プログラミングにハマるきっかけとなったのがサンヨーのMSX2+で、走査線割り込みからプリンタポートによるMIDI演奏まで、出来ることはやり尽くしました。私がMSXと出会っていなかったら今現在こうしてコンピュータでプログラムを作ったり音楽を作ったりはしていなかったでしょう。

　ただ、心残りなのは、私が当時プログラム雑誌（ベーマガやMSX-FAN）に投稿したプログラムが何一つ採用されなかったことです。無念。

　ちなみに、15年ほど前、私はとある同人ソフトサークルに所属しており、こちらのページでいくつも紹介されているMSXの同人ソフトのとある作品（3つぐらい）の開発（音楽と自分のコーナーのプログラム）に携わりました。実は今もそのディスクを所有しているのですが、今改めて見てみると中二病全快で・・・恥ずかしい・・・。

さて、このキット、GR8BITという商品だそうで、ロシア人による開発だそうです。

　このように箱を開けると、必要な部品がバラバラに入っており、自分で半田付けなどを行って組み立てるキットになっています。

　突然のお知らせですが、コンデンサの交換サービスの新規依頼の受け付けを以下の理由によりしばらくお休みさせていただく事になりました。

• 大人の事情（安い料金で行っているが故に同業者からの圧力が凄かった。）
• 本業がちょっと多忙になってきた（最近は昼10時から夜8時ぐらいまで自宅で作業して、夜10時から翌朝4時ぐらいまでスタジオに籠もってます）
• 体調不良。

　一部の方には「デスクトップGOGOランプ」という愛称で親しまれている拙作フリーソフトウェア「I'm Jugglamp EX」が本日バージョン2.1.5へとバージョンアップしました。

　前バージョンからの変更点は、シミュレート対象機種に「アイムジャグラーAPEX」と「ミラクルジャグラー」が追加された事です。その他の機能追加などはありません。

ダウンロードはI'm Jugglamp EXのページから。

　今後は、徐々にバージョン2.1.X系統をフェードアウトさせていき、2.2系統をリリースしたいと思っていますが、それに伴う機能追加で、あまりにも大量のコードを一人で書いている状況で、切羽詰まっております。（現在でもソースコードが2万行ほどあります）

　実のところ、Jugglampシリーズは元々自分のパチスロの立ち回りの研究のために書き始めたソフトなのですが、現在自分自身がパチスロを打つ時間がほとんど無くなったこともあって、（自分のために作ったソフトにもかかわらず）もう自分にはほとんど必要のないソフトとなってしまいました。しかしながら、要望や意見などは頂いており、自分の時間が空いた時に修正を加えたりしている状況です。

　おそらくは、大きな機能追加はバージョン2.2で最後とし、以後は新機種が登場するたびにマイナーバージョンアップ程度に留めていこうと思います。

　今回のエントリは、Dynabook UX/23のBIOSをアップグレードしたところスタンバイ・休止状態に不具合が発生し、結局元に戻すことになってしまった時の記録です。

はじめに

このエントリは以下の条件に当てはまる方を対象としています。
それ以外の方はこのエントリを読むだけにとどめておいて下さい。BIOSの更新はマシンを再起不能にするリスクを伴います。

• Dynabook UX/23(PAUX23JNLBL)を使っている。
• OSはプリインストールされているWindows XP Home Editionから変更していない。
• アップグレードしてしまったBIOSを元に戻したい。

　今回のご依頼は、DELLのハイエンドワークステーション「Precision Workstation 650」のマザーボードのコンデンサの交換です。この機種は2004年発売の機種で、Xeon CPUをデュアルで搭載するハイスペックマシンです。

　ハイエンドワークステーションだけあって、コンデンサの搭載量も多く、またマザーボードも大きいです。

依頼者様曰く「PC自体はここ一年、徐々に立ち上がりづらくなりました。現在は電源を入れてもBIOS表示されない状況です。MACアドレスの関係でM/B交換はできない状況ですのでコンデンサ交換をして頂けると非常に助かります。」とのことでご依頼を頂きました。

今回交換するコンデンサは以下の38本になります。

赤:6.3V 2200μF φ10　緑:6.3V 1800μF φ10 水色:16V 1800μF φ10 黄色:6.3V 1500μF φ10 紫:6.3V 820μF φ8

　漏れているのは主にニチコンのHMです。コンデンサのスリーブの刻印を見てみますと2002年製造だということがわかります。この時期のニチコンHMはとにかく漏れやすく、私の所へ来る依頼のうちDELLのマシンでは例外なく漏れているコンデンサの一つです。

日本ケミコンKZGも早期に漏れやすいコンデンサの一つ。こちらももちろん交換対象にします。

　CPU周辺に多数あるコンデンサ。電力消費量が多いXeonを2基搭載しているだけあって、コンデンサの数もそれなりに多いですが、こちらは主にルビコンのMBZが使用されており、液漏れは見られませんでした。しかし、負荷がかかる部位であることと使用年数なども考慮してこちらも交換対象にします。

まずはじめに、液漏れを起こしていたニチコンHMの軍団をすべてサンヨーWGへ交換。

　CPUスロット1周辺の17本を交換。実は奥に見えるヒートシンクの下に3本コンデンサがあるのですが、ヒートシンクの取り外しが基本的に行えないため、こちらの交換は非常に手間が掛かりました。

CPUスロット2付近の6箇所。こちらもサンヨーWGへと交換。

チップセット付近、5本。依頼者様のご希望により予防処置として膨らんでいないコンデンサも含め交換しました。

最後にメモリスロット側の2本を交換して完了です。

　本マザーボードは12月11日を以て依頼者様の元へと返送され、動作確認をお願いしたところ、正常に動作している様子の写真を送って頂きました。

　私は現在音楽製作とXcodeの勉強用にMacを所持しているのですが、2011年11月現在未だにOSはSnow Leopardです。

　というのも、私がローランドのXV-5050というシンセサイザの音色エディットに使っているXV EditorというプログラムがOS X Lionでは今現在サポートされていないため、アップグレードしたくでも出来ないのです。今回はこの動かないXV EditorをなんとかLionで動かせないかと試行錯誤してみた末の失敗記録です。

OS X LionでXV Editorが動作しないたった一つの理由

　ご存じの通り、OS X LionではRosettaが切り捨てられました。
Rosettaとは、Power PCコードで構成された従来のMac OS XアプリケーションをIntel CPU上で動作させるための機構なのですが、ローランドのXV EditorもPower PCコードで構成された古いアプリケーションの一つなのです。

　つまり、RosettaをサポートしないOS X Lionではどう頑張ってもXV Editorは動かせないのです。

古いOSを入れたくても入れられないのがMac

　実はMacには大きな罠があり、あるモデルにプリインストールされているOSよりも古いOSにはダウングレードできません。
例えばOS X Lionがインストールされて出荷されているMacに以前のバージョンのSnow Leopardをインストールしようとしても出来ません。無理矢理インストールしようとしても弾かれます。

　つまり私が将来的にMacを新調した場合、その時期に登場したOSより古い物はインストールできず、つまりはSnow Leopardもインストールできない、ということになります。

　ということは、動作にSnow Leopardが必要なXV Editorはこのままでは新しいMacでは動かせないと言うことになります。

ならば、無理矢理動かしてみよう。

　私の脳内の声：「Rosettaは廃止されたけど、エミュレータの選択肢は他にもあるよね。ほら、Windowsアプリを他プラットフォームで動かすWineとか」

　というわけで、何もMac用のXV EditorにこだわらなくてもWindows用があるじゃないか、と気づいたためさっそく検証開始です。

　※私はOS X Lionを所持していないため、実際には「Rosettaが無い」という環境を想定してSnow Loopardで実験を行いました。

WineBottlerという選択肢

　WineBottlerとは、Wineをベースに設定や環境構築をより簡単にしたパッケージで、これを使うとWindows用のアプリケーションを一発でMac用のアプリケーションに変換できるという素晴らしいツールです。実際にWindows用のInternet Explorer等がまるでMacのアプリケーションであるかのように動きます。

　今回はこれを利用してWindows用のXV Editorを無理矢理Mac用に変換してみました。

左のアイコンがWineBottler、そして右のアイコンが実際にWindows用のXV EditorをMac用に変換してみたもの。

動くことは動いたのだが

　早速WineBottlerを使ってMac用に変換したXV Editorを立ち上げてみます。

　ところが、起動してしばらくすると「XV-5050との接続を確認できない」とのエラーを告げるダイアログが表示されます。
このソフトはコンピュータとXV-5050の間でMIDIを使い双方向通信を行い、データの同期や機器の接続チェックなどを行っています。従ってXV-5050が接続されているにもかかわらずこのようなエラーが出ると言うことはMIDIの入出力がうまく働いていないということになります。

　ちなみに、画面上の鍵盤をマウスでクリックするとXV-5050から音が出ましたので、どうやらMIDIの出力のほうは上手く動いているようです。

なぜBoot Campでは駄目なのか

　Wineを使ってうまく動かないのであれば、Boot CampでWindowsを動かしてその上でWindows用のXV Editorを動かす方法が一番確実かもしれません。

　しかし、シンセサイザの音色というのは、単体で鳴らした場合と実際に楽曲を流しながら鳴らした場合では同じ音色なのにずいぶんと違った聞こえ方をします。従って、私がいつもシンセサイザの音色を作る場合には同時にシーケンサーを立ち上げて実際に曲を再生しながら作っていきます。単体でエディタのみを走らせる、ということはめったにありません。そして、私が使っているシーケンサーはDigital Performer、これはWindows版が存在しません。つまりいくらBoot Campで確実にXV Editorが動くからといって私のケースでは残念ながら諦めるしかないのです。尤も、Mac用のDigital PerformerをWindows上で無理矢理動かす手段があれば別なのですが。

結局はRolandの対応待ち

　現在Rolandの公式サイトではMac OS X への対応状況というページに同社のハードウェアやソフトウェアのOS X Lionの対応状況が公開されています。わりと頻繁に更新されているようですが今のところXVに関する情報は全く掲載されていません。結局現在の所はRolandの対応を待つしか無いのかもしれません。ただ、XV-5050はかなり古い機器ですのでこのまま対応されずに終ってしまう可能性も否めません。

それでもすごいWineBottlerの可能性

　今回はXV Editorの使用には至りませんでしたが、それでもWineBottlerを使ってWindows用のアプリケーションがMac用に変換され、実際に動いてしまう様は見ていて感動しました。ひょっとしたらXV Editor意外にも有用な音楽用アプリケーションがMacで動作するかもしれませんし、今後いろいろ試してみる価値はありそうです。

　WineBottlerの入手先はこちら → http://winebottler.kronenberg.org/

　数日前の事ですが、当サイトで公開しているDMMアフィリエイトの商品リンク作成ツールの利用者の方から「今までに比べてリンクの作成に非常に時間がかかるようになった」とのご報告を頂きました。

　今までは遅くても数秒以内に作成できていた物が、早くても10秒以上かかるというのです。

　こちらではしばらくプログラムの変更は行っていませんでしたので、単にDMMのサーバーが重くなっているのではと考えていましたが実は完全に私のミスでした。

何が原因だったのか

　当サイトのDMMアフィリエイトのリンク作成ツールでは、開発言語としてC#が用いられています。つまりは、.NET Frameworkの機能を利用して実装されているということです。

　プログラム中では、ユーザーの問い合わせに応じてDMMのサーバーから実際に商品情報と商品パッケージ画像を取得するのですが、この時に.NET FrameworkのBeginGetResponseメソッドを用いています。実はこのメソッドにちょっとした問題がありました。

　このメソッドはインターネットリソースの非同期要求を開始するメソッドであり、通常このメソッドが呼ばれた瞬間に、要求の完了・未完を問わずに一瞬で呼び出し元に制御が返ってきます。

　ところが、条件によってはBeginGetResponseメソッドから制御が帰らずにスレッドが長時間ブロックされたままになってしまうことがあります。私のツールがリンクの作成に非常に時間がかかるようになったのもこれが原因でした。

どんな条件の時にスレッドがブロックされるのか

例によって、海外サイトを検索していたら次のサイトを発見しました。

webrequest.begingetresponse is taking too much time when the url is invalid
http://stackoverflow.com/questions/1232139/webrequest-begingetresponse-is-taking-too-much-time-when-the-url-is-invalid

ところが。
私のプログラムでは無効なURLは指定していませんし、そもそもDMMの商品URLに通常のブラウザからアクセスするとあっという間に結果が表示されます。

しかし、同時にとある事を思い出しました。

　実は数日前にApacheの実行ユーザをWindowsサービスのデフォルトユーザから、セキュリティをガチガチに固めた「Apache」というユーザ変更しました。そして改めて検証してみると、Apacheをデフォルトユーザで起動した場合にはリンク作成ツールは今まで通りの速度で動作するのですが、ユーザを「Apache」に変更すると10秒以上の遅延が発生するのです。

　ひょっとして、ユーザ「Apache」のインターネット接続設定がおかしいのでは？と思い、ユーザ「Apache」でログオンしていみたところ・・・。

　容疑者発見！

　「インターネットオプション」を開いてみたところなぜか「設定を自動的に検出する」というチェックボックスがオンになっていました。物は試しにこのチェックボックスをオフにして再度リンク作成ツールをテストしてみると、見事に遅延は解消されました。犯人はおまえだったのか。

　参考までに、なんでこのような現象が起きるのかを調べてみたのですが、マイクロソフトの英語版公式リファレンス によると、こんな記述がありました。

The BeginGetResponse method requires some synchronous setup tasks to complete (DNS resolution, proxy detection, and TCP socket connection, for example) before this method becomes asynchronous. As a result, this method should never be called on a user interface (UI) thread because it might take some time, typically several seconds. 

要約:このメソッドは非同期状態になる前に、いくつかの同期タスク（例えば、DNS解決、プロキシ検出、TCPソケット接続等）を完了する必要があり、場合によってはそれらの同期タスクには数秒を要するため、このメソッドはUIスレッドから呼び出されるべきではありません！