slotware のすべての投稿

米アップル、iOS6のマップの改善のために地球の地理そのものを変更すると決定。


米アップルは多くの利用者から不満が寄せられていたiOS6のマップの正確性を改善するために、マップの内容ではなく地球の地理そのものを変更することを決定した。

The Onionのレポーターは「アップルはiPhoneのマップアプリの不満に対応するため、地球の地理そのものを並べ替えマップアプリの内容をより正確に反映させる計画を発表した」と語った。

「同社幹部らはすでに、大きな非難を浴びている同社のマップと地球上の地理を一致させるため、道路の名前を変更し、建物の位置を変更、あるいはいくつかの歴史的建造物などを完全に取り壊し始めていると発表した」

「アップルは常に最高のユーザー体験を提供したい」と語る同社最高経営責任者のティム・クック氏はこう切り出す「それが、我々がブルックリン橋を解体したりロンドンをカナダに置く理由だ」

※かなり意訳してます。(ソース:https://news.idg.no/cw/art.cfm?id=59546A9F-D003-8865-9B8F88C32C719705)
※The Onionは風刺サイトです。

Digital Performer 7のあまりにも重すぎるイベントリストを軽くする方法。


久しぶりのブログ更新になります。

Digital Performer 8が発表になりました。64ビット対応になり大量のメモリが使えるようになったり、プログラムがCocoaで書き直されてキビキビと動作するようになりました、というのが公式の発表のようですが、海外のフォーラムでは動作が重すぎるとか言われているようですね。私も64ビット化したことで大量のサンプルデータをプロセスメモリに読み込める事を期待したのですが、しばらくはアップグレードせずにDigital Performer 7のままで様子を見てみることにしました。

さて、そのDigital Performer 7なんですが、OSをMountain Lionにアップグレードしてから気がついたことがあります。

それは、イベントリストがめちゃくちゃ重いという事です。Snow Leopardで使っていた時にはイベントリストの編集に全くと言ってストレスを感じなかったのですが、なぜかMountain Lionでは実用に耐えないほど動作が重いのです。CPUはCore i7 2.3GHzです。イベントリストの処理如きで困るような性能ではありません。

具体的には、以下のような現象が発生します。

  • イベントリスト上の数値などを編集しようとして、数値をダブルクリックしてから編集可能になるまでに相当待たされる。
  • イベントリストのスクロールがマウスホイールやスクロールバーの動きに追随できないほど重い。(トラックパッドの2本指スクロールもまた然り)

さらに、私はイベントリストを頻繁に使います。基本的には鍵盤でラフに弾いたあとクオンタイズなりをかけてピアノロール上で大まかに編集した後、イベントリストでさらに細かく編集する、というのが私の作業の流れです。ですからイベントリストが重いとなると、これは作業に支障を来すと言わざるを得ないわけです。

ところが、そのまま作業を続けるといつのまにかイベントリストが通常の軽さに戻っていることがあるのです。

おそらくはSnow Leopard上では現れなかった何らかのバグがMountain Lionでは現れることによってこのように重くなってしまっているのでは、と予想しましたが、肝心の「いつのまにか軽くなる」条件がわからずにいました。

しかしながら今回、偶然Digital Performerをいじくっていてその解決方法を発見しました。残念ながらこの方法も確実ではなく成功率は8割程度なのですがそれでも便利ですので方法を紹介します。

手順

1.画面に開いているウィンドウがトラックオーバービューだけの状態にする。

余計なウィンドウが開いていると成功確率が下がるようです。そこで、ショートカットウィンドウやツールウィンドウも含め、他の余計なウィンドウを閉じて画面に表示されているウィンドウがトラックオーバービューだけの状態にしてやります。

 

2.適当なトラックのシーケンス上でOptionキーを押しながらダブルクリックし、イベントリストを開く。

この状態ではまだイベントリストは重いままです。イベントリストを開いたら、イベントリスト上の適当な箇所をクリックしてウィンドウまたはタブ(コンソリデイトウィンドウの場合)をアクティブにします。

 

3.今開いたトラックのトラック名をトラックリスト上でOption+クリックし、トラック名の変更が可能な状態にする。

トラック名を示すテキストがハイライトされ、選択状態になります。

 

4.カーソルキーの右を押し、トラック名のテキストの選択が解除された状態でリターンキーを押して確定。

この状態でカーソルキーの右を押すと選択状態が解除され、代わりにカーソルが点滅表示になります。この状態でリターンキーを押して確定します。

 

上記の手順で8割ぐらいの確率でイベントリストが元の軽さに戻ります。
戻らないときにはウィンドウを閉じてから開いてみたり、何度もトラック名の編集を行ったりすると成功することが多いようです。

さらにイベントリストを軽くする方法

Digital Performerのイベントリストには、イベントの位置を[小節|拍|Ticks]の形式だけではなく実時間で表示する機能も備わっています。しかしこの機能を有効にしていると若干ではありますがイベントリストが重くなります。そこでこの機能が不要な場合には切ってやりましょう。

この機能を無効にするにはSetupメニューからTime Formatsを選択します。

 

すると下の図のようなダイアログが現れますから、「Event Information」グループ内にある「Real time」のチェックを外してやります。

 

これでイベントリストには実時間が表示されなくなり動作が軽くなります。

 

MacBook Pro 15インチ(Mid 2012) レビュー


先週の事ですが、MacBook Pro 15インチ(非Retinaディスプレイモデル)を購入しました。 今まで使っていたiMac early 2008からの買い替えになりますので、iMacとの性能比較を主にレビューを書いてみようと思います。

購入機種

MacBook Pro 15インチ Core i7 2.3GHz (MD103J/A)

  • 8GB RAM / 500GB HDD
  • 標準解像度ディスプレイ
  • JISキーボード

開封の儀

新品MacBook Proの匂いにつられてやってきた猫。

付属品は至ってシンプルで、ACアダプタと簡単な説明書、ディスプレイの汚れを拭くためのクロスが付属します。説明書は説明書というよりはぺらぺらの紙になっていて「このMacBook Proはあなたのために生まれました」という冊子もありませんでした(汗)

購入の動機

私はプログラミング用途にWindowsマシンを、音楽制作用途にMacを所有しているのですが、最近になってプログラミングの作業よりも音楽の制作の作業を行うことが多くなり、また、自宅で作業した続きを外のリハーサルスタジオに持ち出してそこで続きの作業を行うことが多くなりました。

主にリハーサルスタジオで行う作業はボーカルやギターの録音です。実は今までにも同様の作業を行っていたのですが、その場合には自宅のiMacのDigital Performerでトラックダウンした物を東芝のネットブックに取り込んでスタジオに持ち込み、フリーソフトのDAWを用いてボーカルやギターなどを録音してから再びMacへと録音したトラックだけをコピーするという面倒な手順を踏んでいました。

また、音楽の制作においては重いプラグインを多用することもあり、2008年モデルのiMacでは力不足を感じていました。そこで、メインマシンとして使う事も可能であり、ある程度の性能を有しつつ、自宅で作業中の物をそのまま外へ気軽に持ち出して作業の続きを行える携帯性も兼ねたマシンの購入を検討しており、MacBook Proの購入に至ったわけです。

ProかAirかでずいぶん悩みました。

当初はMacBook AirにするかMacBook Proにするかでずいぶん悩みました。実は私は音楽の制作以外にも趣味の小説を書くのにもMacを使っており、重量が軽く気軽に持ち運べるMacBook Airに惹かれていたのも事実です。

しかし、音楽の制作において重い処理を行うことを考えると、クアッドコアCPU搭載という点だけはどうしても譲れませんでした。MacBook Airは11インチ、13インチともにデュアルコアですし、MacBook Proも13インチモデルはデュアルコアです。従って必然的に購入機種はMacBook Pro 15インチに絞られました。

また、MacBook Airはメモリの増設が不可能ですからメモリが安くなったときに増設する事もできません。ストレージの交換はできるようですが、ユーザ自らストレージの交換を行ってしまうと保証が効かなくなってしまうというのもマイナスポイントです。

対して、MacBook Proの場合はユーザによるメモリ増設やストレージ交換が認められていて、Appleの公式サイトでも手順が公開されています。私の場合は最初はHDDで運用し、大容量のSSDが安くなったタイミングを見計らってSSDに交換する予定でしたので、この時点でMacBook Airは購入対象外になってしまいました。

結果的にMacBook Proの購入に至ったわけです。やはり重量の点では不満が残ることになりましたが、それでも性能には大いに満足しています。

あえて標準解像度ディスプレイを選択したわけ

MacBook Pro 15インチモデルはBTOで高解像度(1680×1050ピクセル)ディスプレイが選択できます。

私は最初、今まで使っていたiMacの解像度が1680×1050ピクセルであることから、MacBook Proも高解像度ディスプレイを選択すれば、iMacの環境を殆どそのまま再現できると考えました。また、Digital Performerはわりと広い画面のほうが快適ですから、やはり普段使い慣れている解像度の方が良いと考えていたのです。

ところが実際に高解像度ディスプレイを搭載したMacBook Proの実物をみて考えが変わりました。 残念ながら目が悪い私に、15インチで1680×1050ピクセルの解像度というものは字が小さくて長時間の作業は辛いと感じたのです。そこで標準解像度(1440×900ピクセル)のディスプレイを選択したわけですが、これはやはり正解だったと思います。

今まで1680×1050ピクセルの環境でDigital Performerを使っていて、これを一回り低い解像度の1440×900ピクセルで運用すると「あ、狭いな」と感じます。しかし、MacBook Proの場合自宅でじっくり作業をする場合には外部ディスプレイを接続して作業できるわけですから、標準解像度ディスプレイを選択したことは全く後悔していないどころか、目があまり疲れないのでむしろ快適です。

メモリはやはり8GB以上あったほうが良い

このMacBook ProはMountain Lionへの無償アップグレード対象機種でしたので、私も早速アップグレードしました。 そして、Mountain Lionを起動してみてアクティブィティモニタを見てみると、なんと起動直後に2GB前後のメモリを消費していました。最小構成の4GBではせいぜい残りの2GBがフリーエリアということで、DAWを走らせたりタブを大量に開いてWebブラウジングを行うには少々キツい物があります。

やはりメモリは最初から8GBにしておいたほうが良いと思います。私は最初に4GBのモデルを購入して後で安いメモリを購入して増設しましたが、メモリ増設の際に外そうとした裏蓋のネジが以外とキツく、少しねじをナメてしまいました。外観を気にする方は最初からメモリを8GB搭載した状態で発注したほうが精神衛生上よろしいかもしれません。

また、Appleの公式ではこの機種に搭載できるメモリの最大容量は8GBとのことですが、実際には16GB搭載できるようです。

iMac Early 2008との比較

ウェブブラウジング

私がメインで使っているブラウザはGoogle ChromeとFirefoxで、場面によって使い分けています。 iMacではどちらのブラウザももっさりとした動きをしており、快適とはいえませんでした。特に私は大量のタブを開いてウェブブラウジングを行うことが多く、そうなるとタブの切り替えやウィンドウの切り替えがかなりもっさりとします。

ところがMacBook Proのほうではどちらのブラウザもサクサク動きますし、ユーザーインターフェースの反応も機敏です。さらに、iMacでは10枚もウィンドウを開けばExposéのフレームレートがガタ落ちしてカクカクとした動きになっていましたが、MacBook Proではそれが発生しません。

また、Mountain LionではSafariがかなり高速化したと聞いたので私もSafariを試してみましたところ噂通り爆速でした。さらにSafariとマルチタッチジェスチャの組み合わせはかなり強力で、ピンチアウト・インによるスムーズな拡大・縮小、2本指による滑らかなスクロール、これらが本当に快適に動きます。

実際、ウェブブラウジングに至ってはほぼマウスを使わずに快適にこなせます。まるでiPadを操作しているかのような感覚です。これならSafariをメインブラウザにしても良いな、と思いました。

Digital Performer

私がメインで使っているアプリケーションです。そして今回このMacBook Proを購入した目的の9割はDigital Performerです。 Digital Performerはバージョンが2.7の頃からお世話になっていて、MacがまだG3の頃から使っていました。

去年、音楽制作マシンをPower Mac G4からiMacに切り替えたときにもそのパフォーマンス向上に衝撃を受けたのですが、今回iMacからMacBook Proに切り替えてみて、またまた衝撃を受けました。

現在制作中のプロジェクトはコンプレッサやキャビネットシミュレータを大量に使う重たいプロジェクトなのですが、iMacでは重たくてどうしようもなかったものが、MacBook Proでは何の苦もなくサクサクと動きました。プロジェクトのロード時間もMacBook Proのほうがかなり高速でした。

こちらは、同じプロジェクトをMacBook ProとiMacで再生したときのパフォーマンスメーターの表示とアクティビィティモニタのCPU使用率の表示になります。公正を期すためにどちらも同じオーディオインターフェースとドライバを用いて、バッファサイズは256サンプルに設定しました。

 Digital PerformerのAudio Performanceの表示に限って言えば、およそ2倍の性能向上ということになりますが、実際にはそれ以上の性能向上がありました。 アクティビティモニタの方を見ていただくとわかりますが、iMacの方は再生中にほぼCPUの使用率が天井張り付きになります。これはオーディオ処理以外にもDigital Performerの画面周りの描画処理でCPUが食われるからで(実際にプロジェクトを再生中はDigital Performer以外にWindowServerプロセスが大量にCPUリソースを食いつぶしていた)、実際にこのプロジェクトを再生するとiMacではミキサーのレベルメータ表示の動きがカクカクになり、ユーザーインターフェースの反応も極端に悪くなります。

対して、MacBook ProのほうではまだまだCPUの能力に余裕があるように見えますし、実際にこのような重いプロジェクトを再生してもレベルメータはスムーズに動き、ユーザーインターフェースの反応も重くなりませんでした。さらに、CPU使用率を見ていただくと分かるとおり、Core i7本来の4コアに加えHyper-Threadingにより認識されている仮想4コアにもきちんと処理が割り当てられています。

これだけでも今回MacBook Proを購入した価値はあったと思います。 最後に、このプロジェクトのバウンスにかかった時間です。やはりMacBook Proが圧倒的に速いです。

ベンチマーク

比較対象として、本機のほかにPhenom II X4 945(3.0GHzクアッドコア)を搭載した自作WindowsマシンとCore 2 Duo(2.4GHzデュアルコア)を搭載したiMac Early 2008を用いました。

Cinebench

まずはじめに実行したのがCinebenchです。 このベンチマークはCPUの性能とGPUの性能を測定できます。マルチスレッドに対応しているためマルチコアのCPUでの性能測定を行えるほか、あえてシングルスレッドでの実行に限定することでシングルコアでの性能を測定することもできます。

Windows版とMac版がありますので、自作WindowsマシンではWindows版を、MacBook ProとiMacではMac版を用いて測定しました。 CPUの性能測定ではマルチスレッド・シングルスレッドのどちらにおいても下の表のようにCore i7を搭載したMacBook Proの処理能力が高いという結果になりました。

次にOpen GLのベンチマークを実行し、GPUの性能測定を行いました。ただし、比較対象機種の自作Windowsマシンに載っているGPUはGeForce 210という2000円ぐらいのGPUですので性能は良くないです。

このテストでもGeForce GT 650Mを搭載したMacBook Proが一番高い性能を示しました。ついでですのでIntel HD Graphics 4000の性能も計測しましたが、GeForce GT 650Mには及ばない物の2008年モデルのiMacのGPU(Radeon HD 2400 XT)よりもずっと高い性能を示しました。

Hyper Threadingの効果が確認できた

Cinebenchのベンチマーク結果にはMP Ratioという項目があります。これはシングルコアで実行したベンチマークをマルチコア(マルチプロセッサ)で実行した場合にどれだけ性能向上するかの指標です。

たとえばあるテストを二つのCPUコアで実行したときに単一のコアのみで実行した場合と比較して2倍の性能向上が見られた場合にはMP Ratioは2になります。 通常、マルチコアでの理論値はそのコア数になりますが(たとえば2コアなら2倍)、実際にはスレッド管理のオーバーヘッドがありますので、実際の数値は理論値よりも少し劣ります。

下の図はCinebenchを実行した各マシンのCPUコア数と実際にどれだけの性能向上があったかを示すMP Ratioの値になります。

iMac Early 2008と自作WindowsマシンのMP Ratioはほぼ理論値に近い値となりました。いずれもMP Ratioの値が実際のコア数を超えることはありませんでした。 対して、MacBook Pro Mid 2012は4コアの CPUを搭載しているにもかかわらず、理論値よりも上の4倍以上の性能向上が見られました。

これはHyper-Threadingの働きにより、4コアのCPU上で8スレッドが効率よく動いたことを示しています。Hyper-Threadingのような機構を持たないCPUでは4コアのCPU上で8スレッドを動かしてもこのような性能向上は見られません。

CPUは基本的に一つのCPUコア内に複数の演算ユニットを持っているのですが、あるCPUコアの使用率が100%をキープしていたとしても実際には全部の演算ユニットが満遍なくフル稼働している事は稀で、瞬間で観測すると演算ユニットの使われ方に偏りが生じ、遊んでいる(使われていない)演算ユニットがあります。

そこで、OSに対してさも仮想的なCPUコアがあるかのように見せかけて、遊んでいる演算ユニットを他のスレッドから活用してやり、コア全体の使用効率を上げてやろうというのがHyper-Threadingの基本的な考え方です。

4コアのCore i7ですと、Hyper-Threadingの働きによりOSからは8個のコアがあるように見えます。8コアあるように見えるからと言って、単純にシングルコアの8倍の性能にはなるわけではありませんが、このように空いている演算ユニットが有効に使われることにより、実際のコア数以上の性能が出ることもあるわけです。

Super Pi

こちらは有名な円周率の計算プログラムです。MacではBootcampを用いてWindowsを走らせて測定しました。 BootCamp上のWindowsの電源設定で「バランス」を選択しました。つまり最高のパフォーマンスが出るようには設定していません。この設定にすると負荷が低いアイドル時はCore i7のクロックは1GHz前後になります。そして負荷がかかるとTurbo Boostが効く事もあり3.1GHz前後まで上昇します。対して自作Windowsマシンの設定はパフォーマンス重視とし、クロックは3GHzに固定されます。つまり、MacBook Proが幾分かのハンデを負っている形になります。

測定結果はCore i7を搭載したMacBook Proが104万桁の円周率の計算にかかった時間が11秒と、すばらしい性能を発揮しました。ただし、Intel系のCPUはSuper Piで競合他社のCPUと比較してもかなり高いスコアを記録することが知られていますのでこのスコアだけを以て総合的な性能評価を行うことはできないでしょう。

余談ですが、私が初めてパソコンを自作した時のCPUがTualatinコアのCeleronの1.2GHzで、円周率104万桁の計算に2分以上かかっていましたので、クロックあたりの性能の向上はすさまじいものがあります。

自作プログラムによるベンチマーク

著名なベンチマークの他に、私が自作したプログラムによるCPUの性能測定を行ってみました。こちらもWindows上での測定になります。 このプログラムはI’m Jugglamp EXといって、当サイトでも配布しておりますパチスロの出玉シミュレーションを行うプログラムです。このプログラムには数千万~数億プレイのシミュレーションを一気に行う機能も搭載されており、実行には若干の時間がかかるので、今回はその機能を用いてそれぞれのマシンでの実行時間を計測し、CPUの性能測定を行ってみました。

なおこの機能はCPUの機能をフルに使うわけではなく、主に整数演算と条件分岐、メモリのランダムアクセスが使用されます。また、マルチスレッドには対応していないためシングルコアあたりの性能測定となります。今回は一億プレイのシミュレーションにかかった時間を測定しました。

結果を見ていただくとわかるとおり、Core i7を搭載したMacBook Proがぶっちぎりの結果を残しています。 このプログラムはシングルスレッドですので、おそらくは実行中にTurbo Boostが効いてCPUクロックが3GHz前後まで上昇したと思われますが、比較的クロック周波数が近いPhenom II X4 3.0GHzの実行結果と比較してもそれでもなおクロックあたりの性能は高いと言わざるを得ません。

発熱など

通常の使用ではボディのファンクションキーの上あたりが若干生ぬるいかな?という程度ですが、負荷をかけるとかなり発熱します。 アイドル状態ではCPU温度が60度前後でファンの回転数も2000回転/分でしたが、Cinebenchの実行中にはCPUの温度が100度を超えました。Ivy BridgeのTjMaxは105度だそうですので、これでもまだスペック的には安全なのでしょうけど耐久性の面ではどうなのかな?と少し心配になりました。

なお、ファンが低速回転している間は騒音についてはまったく気になりません。ただ、CPUが高温になってからファンの回転数が上昇するのにはタイムラグがあります。どうもシステム的にはバッテリーの持ちやファンの耐久性を考慮してできるだけ回転数を抑える戦略になっているように見えます。

GPUの自動切り替えについて

また、省エネルギー設定で「グラフィックスの自動切り替え」を有効にしていると、低負荷時には電力をより多く消費するGeForce GT 650Mの代わりに省電力なIntel HD Graphics 4000が使用されます。そしてOpenGLを使用したりGPUに負荷をかけるプログラムを実行すると高性能なGeForce GT 650Mに切り替わります。

この切り替わりはとてもスムーズで、一瞬マウスカーソルがちらつくだけです。ただしGeForce GT 650M使用時にはやはり本体がそれなりに発熱します。 私の環境では、iPhotoを起動したりSkypeでビデオ通話を開始した際にGeForce GT 650Mに切り替わりました。

しかし、Skypeでビデオ通話を終了させても元のIntel HD Graphics 4000には戻りませんでした。これを元に戻すにはいったんSkypeを終了させる必要がありました。AC電源で駆動する場合には気にならないでしょうが、バッテリー駆動の場合には注意をしないとバッテリーの消費速度がかなり早くなります。

そこで、パフォーマンスは二の次でいいから常に省電力なIntel HD Graphics 4000のみを使用したいという場合もあるでしょう。この場合残念ながら省エネルギー設定にはそのようなオプションはないのですが、gfxCardStatusというユーティリティを使用することにより使用するGPUを固定することができます。

なお、Intel HD Graphics 4000が使用されている場合にはMission ControlやアプリケーションExposéのフレームレートが若干下がるようですが、GeForce GT 650Mの場合にはかなりスムーズに動きます。

不満点など

今のところ性能面では全く不満がありません。しかしハードウェア面での不満があります。

一つはテンキーが標準装備されていない点です。私がメインで使用するアプリケーションはDigital Performerなのですが、このアプリケーションは主要な機能がテンキー操作に集約されていて、テンキー無しでははっきりいって作業効率がガタ落ちします。

もちろんキーのカスタマイズを行うこともできるのですが、私はかれこれ10年以上Digital Performerと付き合ってきた為、Digital Performerの操作は体で覚えてしまっています。従って今更キーのカスタマイズをしたとしてもそれを頭に再びたたき込むのには時間がかかります。しょうがないから今のところはiMacのキーボードをわざわざ繋いでDigital Performerを使っています。

もう一つは内蔵スピーカーの音量バランスについてです。 購入当初からiTunesなどの音楽を再生する際にどうしても右のスピーカーからの音が大きく感じました。しかし、これはMacBook Proの仕様のようなもので、本体右側にサブウーファーが配置されているためにどうしても右からの音が大きくなってしまうのとのことでした。しかし、サブウーファーというのは本来100Hz以下の指向性を感じなくなる音域の音を主に鳴らすためにあるのでは・・・?

不具合みたいなもの

これはハードウェアの不具合なのかソフトウェアの不具合なのかはわかりません。 しかし、以下の条件を満たすと再現します。

  1. OS Xのユーザーアカウントが2名以上存在する。(メインユーザ+ゲストアカウント有効でも可能。)
  2. 省エネルギー設定でグラフィックスの自動切り替えが無効になっている。

この状態でアカウントからログオフすると、ログオンスクリーンに点滅する灰色の四角が現れます。 ちょうどマウスカーソルがある位置に現れるようです。

最初はGPUの不具合でこのような現象が起きているのかと思いましたが、Apple Hardwar Testを実行しても異常は報告されず、画面共有を用いてリモートで操作しても同様の現象が発生しましたので、ソフトウェアの不具合の可能性も否めません。まだ購入して1ヶ月も経っていないため、時間のあるときにアップルのサポートにでも連絡を取ってみようと思います。

総合評価

若干の不具合がありましたが、性能には概ね満足していますし、クアッドコアを搭載したパソコンが高々2キログラムのボディに収まってそれを自由に持ち運びができるとは、すごい時代がきたものです。MacBook Proの購入を検討されている方で、性能を重視する方はクアッドコアCPUを搭載したモデルを是非ともおすすめします。重量が重いという難点はありますが、それ以上の価値はあると思います。

余談になりますが、私のはじめてのノートパソコンはPC-9801NS(中古)で、学生時代はMS-DOS上のMIDIプレイヤー(MIMPIという名前だったと思います)を走らせてライブで打ち込みを流したりしていました。

【飜訳】OS X Mountain Lionを動作対象外の機種で無理矢理動かす方法 -前編-


今回発売されたOS X Mountain Lionでは旧機種の切り捨てが行われ、Appleからは2007年以前に発売の殆どの機種で動かないことが公式に発表されました。

ところが、海外のフォーラムでOS X Mountain Lionが動かないとされる旧機種で無理矢理インストールして動かしてしまった方がその方法を発表されていましたので、こちらに和訳して載せたいと思います。

なお、これは非公式な方法ですので、この方法を行った事による一切の損害に対しての責任は負いかねます。あくまで自己責任にて行って下さい。

原文はこちら:[GUIDE] SUCCESS! Install 10.8 on OLD unsupported Mac

準備:あらかじめMountain Lionインストール用に20GB程の大きさのパーティションを作成しておくこと。

用意する物

  1. 8GBのUSBメモリ
  2. 20GBの空きパーティション(Mountain Lionインストール用)

動く機種と動かない機種

  • Mac Minis with X3100 > 完璧に動作。
  • Mac Pros with upgraded graphics >完璧に動作。
  • MacBooks with X3100 > 動作する物の、ディスプレイ輝度とスリープに問題あり。
  • MacBookAir with X3100 >動作する物の、ディスプレイ輝度とスリープに問題あり。 
  • MacBookPros with X1600 > グラフィックに問題あり (Core ImageのフレームバッファモードでQuartz Extremeが機能しない)
  • iMacs with X1900 > グラフィックに問題あり (Core ImageのフレームバッファモードでQuartz Extremeが機能しない)
  • MacBooks with GMA 950 > 動作する。ただしQuartz Extreme/Core Imageをサポートしない。
  • iMacs with GMA 950 >動作する。ただしQuartz Extreme/Core Imageをサポートしない。
  • Mac Minis with GMA 950 >動作する。ただしQuartz Extreme/Core Imageをサポートしない。
  • Mac Pros with 7300GT and X1900XT >全く動かない。
  • iMacs with 7600GT >全く動かない。

手順

  1. まずはMountain Lionを購入して下さい。たったの1700円ですから。お願いします。
  2. LionがインストールされたパーティションからMacを起動し、Finderで不可視ファイルを表示できるように設定を変更します。やりかたはググって下さい。
  3. Mac App Storeで購入したOS X Mountain Lion.appを右クリックし「パッケージの内容を表示」をクリックします。Contents/Shared Supportフォルダの中に”InstallESD.dmg”というファイルがありますのでこれをデスクトップにコピーします。(訳者注:この後InstallESD.dmgをダブルクリックでマウントする物と思われる)
  4. 「不可視ファイルの表示」がまだ無効なら有効にして下さい。”BaseSystem.dmg”というファイルが見つかると思いますからそれを開いてマウントしてください。
  5. 8GBのUSBメモリを差し込み、Disk Utilityを開きます。Disk Utilityで先ほど差し込んだ8GBのUSBドライブをクリックし、「復元」タブをクリック。サイドバーからBaseSystem.dmgをソースにドラッグ、続いてUSBメモリを復元先にドラッグします。この工程は大体10分から20分ほどかかります。無事に復元が完了したらUSBメモリを開き、System→Installationとフォルダを開き、中にある”Packages”というファイルをInstallESDの中にある同名のファイルで置き換えます。このファイルはおよそ4GBほどです。
  6. コピーが完了したら、さらに置き換えるファイルがいくつかあります。リンクから1.14MBのZIPファイルと、hackedOSInstall.mpkgをダウンロードします。(訳者注:どちらもZIPファイル)
  7.  ダウンロードした二つのZIPファイルを展開すると、” MountainLionHack”というフォルダが現れます。中には”CoreServices”と”i386”の二つのフォルダと、”OSInstall.mpkg”というファイルがあると思います。先ほど作成したUSBメモリを開き”/System/Library”フォルダを開きます。そしてダウンロードしたZIPファイルから展開された”CoreServices”フォルダの中身を”/System/Library/CoreService”フォルダへドラッグしマージします。(訳者注:フォルダをドラッグするとマージではなく置き換えになるので注意。必ずフォルダの中身をドラッグすること)、同様の手順でUSBメモリの”/usr/standalone”フォルダを開き、先ほどダウンロード・展開した”i386”フォルダの中身を”/usr/standalone/i386”までドラッグしてマージします。最後に、USBメモリの”/System/Installation/Packages”を開き、先ほど入手した”OSInstall.mpkg”をドラッグしてファイルを置き換えます。
  8.  Optionキーを押しながらMacを再起動します。先ほど作成したUSBメモリを起動ドライブとして選択しエンターキーを押して下さい。インストール画面が表示されたらインストール先ドライブの選択が現れるまで「次へ」をクリックし続けること。ドライブ選択画面で全てのドライブを表示するように設定した後、Mountaion Lion用にあらかじめ作成しておいた20GBのパーティションを選択し、インストールを行います。インストールの完了後システムが再起動しますが、まだ絶対にMountain Lionパーティションからの起動を試みないで下さい。システムの再起動時にはOptionキーを押し続け、Lionから起動します。Lionが起動したら、先ほどの”MountainLionHack”フォルダにある”PlatformSupport.plist”ファイルをMountain Lionパーティションの”/System/Library/CoreServices”の中へコピーしファイルを置き換えます。
  9. Mountain Lionパーティションから起動し、Macのセットアップを行って下さい。(手順はまだ終っていません。引き続き手順に従うこと)
  10. グラフィック(訳者注:グラフィックアクセラレーションの事だと思われる)とサウンドが機能していないことに気づくと思います。

訳者注:手順はこれで終わりではありません。グラフィックとサウンドを有効にする手順が続きますがそれは後編にて。詳しく知りたい方は原文を参考にしてください。

 

ブログをMovableTypeからWordPressへと移行したときの作業記録


先日のことですが、今までMovableType 5.1で運営していたこのブログをWordPressへと移行してみました。

移行したきっかけはやはりMovableTypeの再構築にかかる時間の長さです。現在は自宅サーバーで運営されている当サイトですが、近日中に諸事情から安いVPSに移行しようかと計画しておりまして、その際ブログのカスタマイズを行ったりする度に(安い低スペックなVPSでは)再構築に何十分も待たされるんだろうな、と考えていたことから、WordPressへと移行したというわけです。

作業工程

1.MovableTypeのブログデータをエクスポートする。

MovableTypeにはブログデータをエクスポートする機能が標準で備わっていますが、今回はこれを使いません。一度この機能を使って移行してみたのですが、ブログエントリの「タグ」が移行されませんでした。

そこで

MovableTypeからWordPressに固定リンク込みで完璧に移行する方法を参考に、一旦MovableTypeのデータをXMLで書き出してそれを利用することにしました。

2.古いブログの画像データなどを別のディレクトリに移動

私の環境では、今までMovableTypeで扱ってきた画像などのファイルは全て/blogディレクトリ以下の様々なディレクトリに保存されているのですが、この/blogディレクトリを/mt_oldに改名します。と同時に、中にある画像以外のファイル(MovableTypeが生成したhtmlファイルなどは全て削除します) 本当はこのディレクトリを名称変更せずにそのまま使いたかったのですが、このディレクトリ内部にMovableTypeが生成した日付などのフォルダが存在するとWordPressで不具合が発生したので思い切って別ディレクトリに移動しました。

3.MovableTypeからエクスポートしたXMLデータ内で、画像などのメディアファイルにリンクしている部分を新しいディレクトリのパスへと置換する。

1の工程でエクスポートしたXMLファイルをエディタ等で開き、href=”hogehoge/blogやsrc=”hogehoge/blogとある場所(以前のブログの画像などのパス等)をhref=”hogehoge/mt_oldやsrc=”hogehoge/mt_oldに置換します。

4.XMLファイルをWordPressへインポート

画像パスの置換さえ上手くできていれば、先ほどのXMLファイルをWordPressへインポートするだけで既にブログとして機能するようになりますが、パーマリンクなども維持したいという場合にはもう少し作業が必要です。

5.パーマリンクの設定

私の場合は、以前MovableTypeで使用していたパーマリンクの書式に則って、以下のように設定しました。

 

6.カテゴリのスラッグを再設定

MovableTypeからインポートすると、カテゴリのスラッグは引き継がれずカテゴリ名のままになってしまいますので、これを修正します。 カテゴリが多数有ると面倒ですが、手作業でやらないといけません。

 7.カテゴリアーカイブのパーマリンクから「/category」を削除

MovableTypeの時には、カテゴリアーカイブのパーマリンクは「/blog/categoryname/」となっていましたが、WordPressの場合ですと「/blog/category/categoryname/」のように、「category」という文字が途中で入ってしまいます。そこで、MovableTypeの時のパーマリンクと互換性を持たせるためにこの部分を消してやります。それには「WP No Category Base – WPML compatible」というプラグインを使います。

WP No Category Base – WPML compatible

 8.問題点

以上の作業で、MovableTypeのブログをWordPressに移行することはできましたが、若干の問題が残ります。
MovableTypeで作成したブログのエントリのパーマリンクにハイフン「-」が含まれていると、WordPressにインポートする際にアンダースコア「_」に変換されてしまう事があります。(変換されない場合もある)

私のブログの場合はアクセス数も少なく、ソーシャルブックマークなどからもあまりブックマークされていませんので、そのまま放置して、Googleに再インデックスしてもらうのを待つことにしました。

9.移行後はやはりアクセス数が激減

パーマリンクのハイフンがアンダースコアに変換されてしまう問題のおかげで、404 Not Foundが大量に発生し、Googleのウェブマスターツールを見ると大量の404エラーが記録されていました。当然、アクセス数は5分の1まで激減! それでもこのブログはアクセス数の減少はそれほど致命的ではないので再インデックスを気長に待つことにします。

 移行を終えての感想

やはり、ブログをあれこれいじくったあとに再構築をしなくても良いというのは快適です。また、画像などのアップロードがドラッグ&ドロップで行えるようになったので、時々ではありますが画像を多用する当ブログでは編集作業も楽になるのではないかと思います。

ちなみに、移行後「WordPress Super Cache」というプラグインを入れて、負荷を少しでも減少させるようにしてみました。

 

 

DMMTool(仮名) for Windows開発状況その4


いよいよブックマーク機能を実装しました。

今回は、ブックマーク機能を実装するにあたって利用したMVCという設計手法とXBELという規格の話が中心です。

まずはスクリーンショットをご覧下さい。一般的なウェブブラウザに搭載されているような階層構造を持ったブックマークがウィンドウ左側に表示されているのがわかると思います。

bookmark.png

このブックマーク機能の仕組みですが、MVC(Model-View-Controller)という設計手法に則って設計されています。なぜこのような手法にしたかというと複数のウィンドウ間でブックマーク表示の同期を取らなければならないからです。

このツールは一般的なウェブブラウザ同様、複数のウィンドウを開いて作業を行えるようになっているため、あるウィンドウでブックマークの変更を行った場合、他に開いているウィンドウにもその内容が即座に反映させなくてはなりません。

MVCを使わない場合・・・

まず、標準のTreeViewだけで上記の要件を満たしたブックマーク機能を実装することを考えてみます。

TreeViewの表示内容を弄るにはNodesプロパティを使います。ここにTreeNodeオブジェクトを追加したり削除したりすることによりTreeViewの表示内容を弄ることができます。TreeNodeは名前の通りツリー構造になっていて一つ以上の子TreeNodeを追加することができ、これによりデータの階層的な表示を実現できます。つまり、TreeViewは表示に関する機能と、表示するデータを管理する機能の二つを両方持っているということになります。従ってここにブックマークのデータを入れてやればTreeViewを使ってブックマークデータの編集や表示が行えるというわけです。

ところが、複数のウィンドウが開かれていて、それぞれのウィンドウが同じブックマークの内容を表示したい場合はどうでしょう。当然それぞれのウィンドウがTreeViewを持つことになりますがこの場合、変更があったTreeViewの内容を全ての他のTreeViewにコピーして回らなければなりません。

また、あるウィンドウでブックマークの追加や削除が行われたことをどうやって他のウィンドウが知れば良いのでしょうか。また、他のウィンドウで行われたブックマークの変更を自分のウィンドウに反映させるにはどうすれば良いでしょうか。さらに、もっと多くのウィンドウが開かれたり閉じられたりをしていた場合のTreeViewの管理はどうなるでしょう。

おそらくはデリゲート等を用いてウィンドウ間の通知機構を実装する方法にたどりつきますが、考えただけで面倒です。

このような動作をより簡単に実現させるためには、まず表示部分とデータの部分を独立させなければなりません。その上でデータの変更を表示部分に通知するメカニズムと、表示部分に対して行われた操作によって、データの変更を要求するメカニズムを実装する必要があります。これがいわゆるModel View Controllerという設計手法です。

前述の通り、標準のTreeViewだけで上記の要件を満たしたブックマーク機能を実装するのは非常に面倒です。
なぜならWindows.FormsのTreeViewはView(TreeView)とModel(Nodes)が一体になっているため、データと表示部分の分離がされていないからです。

MVCを使うと・・・

 そこで、TreeViewには単に表示に専念するだけのViewになってもらい、ブックマークのデータを保持するModelを独自に作ります。

 これでViewとModelの分離は行えました。こうするともはやTreeViewのNodesプロパティはブックマークのデータではなく、単なる表示内容のデータになりますから、ブックマークの編集が行われる度にこのデータを他のTreeViewにコピーして回るという面倒なことはしなくても良くなります。

 ここでは、ユーザーがブックマークアイテムをあるフォルダへドラッグして移動したケースを例に、MVCがどのように働くかを説明します。

MVC.png

ViewとModelの関係

Modelにはブックマークデータを管理するツリー構造の他に、ブックマークの追加や削除、移動、コピー、名前の変更、フォルダの作成などを行うメソッドを作っておきます。.NET Frameworkには(頻繁に利用されるデータ構造であるにも関わらず)データのツリー構造を管理するクラスが用意されていません。そこでまずはツリー構造を管理するクラスの自作から始めました。

対してViewはWindows標準のTreeViewを用いますが、データの表示に専念させ、データの管理は全く行わないようにします。また、ドラッグ&ドロップやクリック、アイテムの削除の操作は全てコントローラに通知されるようにします。

Controllerの働き

ControllerはユーザーがViewで行った操作に従って、Modelに適切なメッセージを送り、データの変更要求を行う役目を持っています。

上の例ではユーザーがブックマークをドラッグして移動しています。するとこの操作はControllerに通知され、Controllerはその通知に従い実際にモデルに対してデータの変更を要求します。ちなみにControllerはModelのデータを直接いじりません。データの操作を行うのはあくまでModelになります。

ModelからViewへの通知

 さて、実際にModelが変更されるとModelからViewへ「Modelの内容が変更されたから表示を更新してください」といった通知が行われます。通知といっても実際にはメソッド呼び出しだったりイベント発生だったりするだけです。ViewはModelの内容を視覚的に認識できる形で画面に表示します。今回の例では、ツリー構造を持ったModelの内容を元に、TreeViewのアイテムの再構築を行っています。

この時大事なことは単一のModelに対してViewは複数存在することができる、ということです。つまり、画面に複数のウィンドウがあり、そこへそれぞれのViewが貼り付けられていたとしても、Modelから各Viewに対して適切に通知が行われれば、あるウィンドウで行ったModelの変更が即座に他のウィンドウのViewにも反映される、ということになります。


複数のViewが存在する場合でも

multipleviews.png

画面に複数のドキュメントウィンドウが開かれている等、複数のViewが存在する状況でも、単にModelはそれぞれのViewに対して同時にModel更新の通知を送ってやれば、各Viewの表示内容が一斉に更新されるわけです。今回ブックマーク機能の実装にあたりMVCを利用した最大の理由が「場合によっては画面に複数のViewが存在する」という理由です。


ドラッグ&ドロップの実装

今回一番時間がかかったのが、ブックマークのドラッグ&ドロップによる編集です。
TreeViewにはドラッグ&ドロップをサポートする機能が標準で搭載されていますが、若干機能不足です。

たとえば標準のドラッグ&ドロップではTreeNodeを他のTreeNodeの上にドラッグし、ドラッグされたTreeNodeの子とすることは簡単にできますが、あるTreeNodeを二つのTreeNodeの間にドラッグして任意の位置にアイテムの挿入を行う、といった機能はありませんから、こういった機能は自前で実装する必要があります。

drag_drop.png

 また、ドラッグ&ドロップにも下記のようなルールを設ける必要があります。

  1. あるフォルダをそのフォルダ自身が内包しているフォルダには移動できないようにする。Windowsのファイルシステムを例にあげて説明すると、C:hogeというフォルダと、C:hogehageという二つのフォルダがあった場合、前者のフォルダを後者のフォルダの内部に移動させる操作はできない、といった具合です。
  2. あるフォルダをそのフォルダ自身の子とすることもできない。
  3. ブックマークの項目をフォルダへ入れて子とすることはできるが、ブックマークの項目をブックマークの項目の子とすることはできない。
  4. 同様にフォルダをブックマーク項目に入れて子とすることもできない。

これらの機能を一つ一つ検証しながら実装していたのですが、あまりにもややこしすぎて時間がかかってしまいました。

ブックマークの保存形式

ブックマークの保存は、ブックマーク記述言語「XBEL」形式で行います。XBELとはXML Bookmarks Exchange Languageの略で、XMLを利用したブックマークの相互利用のための規格です。XML形式ですので、ブックマークの保存の際にはブックマークのツリー構造を再帰的に辿ってXmlDocumentを構築した後、ファイルに出力しています。XBEL形式に関してはこのページを参考にしました。

この形式を利用する利点は、様々なブラウザのブックマークとの相互変換が可能である事です。自作のアプリとはいえ、独自のデータ形式を使ってしまっては後々困ることになりますから、オープンな規格はどんどん利用すべきだと思います。

bookmark_xml.png

さて、次回はWeb版、デスクトップアプリ版両方のDMMアフィリエイトリンク作成ツールに搭載されているキャッシュシステムについて書いてみようかと思います。

Firefox 11の「要素を調査」が凄すぎる件


 最近のブラウザには「要素を調査」という機能が搭載されていますが、Firefox 11に搭載のソレは凄いことになってしまっているので紹介します。

まずは普通に適当なサイトを開いてみます。

firefox11-1.jpg

次に、ページの適当なところで右クリックし、「要素を調査」を選択。

firefox11-2.jpg
続いて、ウィンドウ右下の「3D」をクリック。

firefox11-3.jpg すると・・・ページの各要素の階層構造が3Dで視覚化されます。ある要素が別の要素に内包されている様子がとてもわかりやすく表示されます。

この3D画面はマウスをつかってぐるぐる動かせたりできます。

firefox11-4.jpg
なおこの機能はMacでは動きましたが、Windowsでは「3D」のボタンが出てきませんでした。

DMMTool(仮名) for Windows開発状況その3


 今回のエントリもまたまた開発状況報告になります。
1.履歴機能 & UIの若干の改良
 今回は、履歴を実装してみました。(お気に入りはまだです)
また、ウィンドウのタイトルバーに現在開いている商品のタイトルがちゃんと出るようになりました。 なお、今回履歴を実装するに当たってはじめて「LINQ」という技術を勉強して使ってみたのですが、あまりの便利さにケツが浮きました! これについでは後日別のエントリで改めて書こうと思います。

history.png

2.ドラッグ&ドロップで簡単に画像をダウンロード
 DMMのアフィリエイトは、パッケージ画像の他にも宣伝素材としてサンプル画像の利用が許可されているカテゴリがあります。(カテゴリによっては全く許可されていないものもあるので注意)
 従来、サンプル画像(特に大サイズの物)を利用しようとする場合、まずブラウザで該当の商品ページを開き、次にサンプル画像をクリックし、大きいサイズの画像を表示させてから右クリック、もしくはドラッグ&ドロップで一つ一つ保存、というやり方を行っていた方が殆どだと思います。
 しかし今回ドラッグ&ドロップをサポートしたことにより、画像一覧から画像をエクスプローラにドラッグするだけで一発で保存できます。複数の画像を一気にまとめて保存することも可能です。
dragdrop.png
 保存した画像を開いたところ。ダウンロードとはいえ、実際にはすでに取得済みのキャッシュをエクスプローラへとコピーしているだけなので、複数の画像であっても取得速度は圧倒的に速いです。
samplepic.png
デモ動画

 実際にいくつかの商品情報を取得し、そのサンプル画像をダウンロードする様子を動画でご紹介します。雰囲気だけでも伝われば光栄です。

DMMTool(仮名) for Windows開発状況その2


今回もまた、プログラミングに関する記事です。大変申し訳ございません。

前回のエントリを書いてから、空き時間を見つけては地道に作業を続けておりました。

前回からの改善点は

  • ネットワークアクセスから何から、ありとあらゆる物をマルチスレッド化した。
  • エラー処理の強化

徹底したマルチスレッド化

 前回のバージョンではURLボックスにURLを入力して情報取得ボタンを押すと、すべての情報の取得が完了するまでウィンドウがフリーズした状態になっていました。画像が多い場合、全情報の取得には10秒以上かかる場合もあり、その間ユーザーは何の操作もできずに待たねばならなかったのです。これはすべての処理をシングルスレッドで行っていたため、情報取得が完了するまでメインのGUIスレッドが止まるからです。

 ところが、たくさんある商品の情報を次々と取得したい場合、ある商品のURLを入力し、表示が完了するまで待ち、次の商品のURLを入力し、また待ち、なんてことはかったるくてやってられません。

 そこで、今回はHTMLのスクレイピングから画像の取得まで、すべてをスレッド化し、個別の情報が取得でき次第次々とイベントが発生するように改良しました。発生したイベントはメインのUIスレッドに伝えられ、その度に画面の更新が行われます。この状態でもメインのイベントループが動き続けているため、他の操作を行うことができます。

 おかげで、下の画像のようにたくさんのウィンドウを開いて次々と情報取得を行っても非常にぬるぬるとなめらかに動くようになりました。

dmmtool_overview.png

エラー処理の強化

 シングルスレッドで処理を行う場合、極端な話必要な処理を関数として書けるので、どこかでエラーが発生すればその時点で関数を抜けて処理を中断し、エラーが発生したことをユーザーに告知するだけのシンプルなプログラムで済みます。

 ところがマルチスレッドの場合には話がすこしややこしくなります。

 たとえば平行していくつものスレッドが動いている場合、あるスレッドは正常に完了したが、あるスレッドは途中でエラーが起きた、という状況が起きます。具体的には、複数の画像データをマルチスレッドで平行してダウンロードしていたがある画像のダウンロードだけは途中で失敗した、等のケースです。この場合、あるスレッドで発生したエラーをどのようにメインスレッドに伝えるかが問題となります。.NETではあるスレッドで発生した例外を他のスレッドでキャッチすることができないので、例外が発生した場合にはイベントを発生させてメインスレッドに例外を伝えるということをやっています。

 また、エラーの告知方法も少し工夫しました。

 このツールでは、ユーザーが商品情報の取得を開始して比較的早期に発生したエラー(URLの入力ミスやパッケージ画像が取得できなかった等)はダイアログを表示してその時点で処理が中断されます。

error1.png

 対して、すでに処理を開始してからある程度の時間が経過しており、もうそろそろ処理が終るだろうと思われる頃合いに発生したエラー(サンプル画像を取得中に発生したエラーなど)に関してはダイアログで告知せずにエラーが発生した事を示すアイコンのみを表示し、そのまま続行可能な処理を続けます。これには二つの理由があります。
  • ユーザーを完了まで待たせるだけ待たせておいてエラーで処理が中断されてはフラストレーションになるから。
  • 取得した画像全てがユーザーが必要としている画像となるケースは希であるから、リロードを行うかどうかはユーザーの判断に任せることにした。
error2.png
現時点で搭載している機能

 まだアフィリエイトリンクを作成する機能は実装されていませんが、以下の機能を搭載しています。
1.商品のタイトル、説明、出演者などの情報をテキストとして取得。
2.商品のパッケージ画像(大、小)を取得
feature1.png
3.商品のサンプル画像(大、小、ただしサンプル画像がある場合のみ)を取得
feature2.png今後搭載したい機能
  • お気に入り、履歴など
  • タブを用いて一枚のウィンドウで複数の商品情報を開けるようにしたい
  • 複数の商品のアフィリエイトリンクを効率よく作成できる手段の提供
なお、完成はまだまだ先になると思われますので、今すぐにでもDMMのアフィリエイトリンクを手軽に作成したい!という方は、当サイトで既に公開しておりますWebサービス版をご利用ください。

DMMアフィリエイトリンク作成ツールのWindows版の開発を開始しました。


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

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

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

dmmtool_win.png

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

explorer.png

技術的なこと

以前にもこのブログで書いたことがあるのですが、Webアプリケーション版のツールはPerlやPHP等ではなくC#で開発されています。従ってこのようにWindows版を作ることもすぐに出来るわけです。

 さらにプログラム内部では
DMMItemInfo item = new DMMItemInfo();
 item.BeginScrape(“DMMの商品URL”);
みたいなことを書くだけで商品情報を取得できるようになっています。
実際に商品情報の取得に成功した後は、
 string hoge = item.Description;
とか、
 DMMPictureInfo hogePicture = item.LargeSamplePictures[3];
みたいな感じで、商品の説明やらサンプル画像が取り出せるようになっています。
さらに、DMM側のサーバにできるだけ負荷を掛けないように独自のキャッシュシステムも構築しています。
ご意見、要望などをお待ちしております。

 私はプログラミングは得意な方ですが、Webデザインに関しては全くの素人で、売れる広告デザインの作り方などはまったくわかりません。そこで、このプログラムがある程度完成したら最初にごく少人数の方にベータテストという形で使って頂き、スタイルシートに関する意見や、プログラムに関する要望などを募集しようと思います。また、このブログのコメント欄などでも、搭載して欲しい機能などの要望を受け付けておりますので、よろしくお願いいたします。