米アップルは多くの利用者から不満が寄せられていたiOS6のマップの正確性を改善するために、マップの内容ではなく地球の地理そのものを変更することを決定した。
The Onionのレポーターは「アップルはiPhoneのマップアプリの不満に対応するため、地球の地理そのものを並べ替えマップアプリの内容をより正確に反映させる計画を発表した」と語った。
「同社幹部らはすでに、大きな非難を浴びている同社のマップと地球上の地理を一致させるため、道路の名前を変更し、建物の位置を変更、あるいはいくつかの歴史的建造物などを完全に取り壊し始めていると発表した」
「アップルは常に最高のユーザー体験を提供したい」と語る同社最高経営責任者のティム・クック氏はこう切り出す「それが、我々がブルックリン橋を解体したりロンドンをカナダに置く理由だ」
※かなり意訳してます。(ソース:https://news.idg.no/cw/art.cfm?id=59546A9F-D003-8865-9B8F88C32C719705)
※The Onionは風刺サイトです。
久しぶりのブログ更新になります。
Digital Performer 8が発表になりました。64ビット対応になり大量のメモリが使えるようになったり、プログラムがCocoaで書き直されてキビキビと動作するようになりました、というのが公式の発表のようですが、海外のフォーラムでは動作が重すぎるとか言われているようですね。私も64ビット化したことで大量のサンプルデータをプロセスメモリに読み込める事を期待したのですが、しばらくはアップグレードせずにDigital Performer 7のままで様子を見てみることにしました。
さて、そのDigital Performer 7なんですが、OSをMountain Lionにアップグレードしてから気がついたことがあります。
それは、イベントリストがめちゃくちゃ重いという事です。Snow Leopardで使っていた時にはイベントリストの編集に全くと言ってストレスを感じなかったのですが、なぜかMountain Lionでは実用に耐えないほど動作が重いのです。CPUはCore i7 2.3GHzです。イベントリストの処理如きで困るような性能ではありません。
具体的には、以下のような現象が発生します。
さらに、私はイベントリストを頻繁に使います。基本的には鍵盤でラフに弾いたあとクオンタイズなりをかけてピアノロール上で大まかに編集した後、イベントリストでさらに細かく編集する、というのが私の作業の流れです。ですからイベントリストが重いとなると、これは作業に支障を来すと言わざるを得ないわけです。
ところが、そのまま作業を続けるといつのまにかイベントリストが通常の軽さに戻っていることがあるのです。
おそらくは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インチ(非Retinaディスプレイモデル)を購入しました。 今まで使っていたiMac early 2008からの買い替えになりますので、iMacとの性能比較を主にレビューを書いてみようと思います。
MacBook Pro 15インチ Core i7 2.3GHz (MD103J/A)
新品MacBook Proの匂いにつられてやってきた猫。
付属品は至ってシンプルで、ACアダプタと簡単な説明書、ディスプレイの汚れを拭くためのクロスが付属します。説明書は説明書というよりはぺらぺらの紙になっていて「このMacBook Proはあなたのために生まれました」という冊子もありませんでした（汗）
私はプログラミング用途にWindowsマシンを、音楽制作用途にMacを所有しているのですが、最近になってプログラミングの作業よりも音楽の制作の作業を行うことが多くなり、また、自宅で作業した続きを外のリハーサルスタジオに持ち出してそこで続きの作業を行うことが多くなりました。
主にリハーサルスタジオで行う作業はボーカルやギターの録音です。実は今までにも同様の作業を行っていたのですが、その場合には自宅のiMacのDigital Performerでトラックダウンした物を東芝のネットブックに取り込んでスタジオに持ち込み、フリーソフトのDAWを用いてボーカルやギターなどを録音してから再びMacへと録音したトラックだけをコピーするという面倒な手順を踏んでいました。
また、音楽の制作においては重いプラグインを多用することもあり、2008年モデルのiMacでは力不足を感じていました。そこで、メインマシンとして使う事も可能であり、ある程度の性能を有しつつ、自宅で作業中の物をそのまま外へ気軽に持ち出して作業の続きを行える携帯性も兼ねたマシンの購入を検討しており、MacBook Proの購入に至ったわけです。
当初は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の場合自宅でじっくり作業をする場合には外部ディスプレイを接続して作業できるわけですから、標準解像度ディスプレイを選択したことは全く後悔していないどころか、目があまり疲れないのでむしろ快適です。
このMacBook ProはMountain Lionへの無償アップグレード対象機種でしたので、私も早速アップグレードしました。 そして、Mountain Lionを起動してみてアクティブィティモニタを見てみると、なんと起動直後に2GB前後のメモリを消費していました。最小構成の4GBではせいぜい残りの2GBがフリーエリアということで、DAWを走らせたりタブを大量に開いてWebブラウジングを行うには少々キツい物があります。
やはりメモリは最初から8GBにしておいたほうが良いと思います。私は最初に4GBのモデルを購入して後で安いメモリを購入して増設しましたが、メモリ増設の際に外そうとした裏蓋のネジが以外とキツく、少しねじをナメてしまいました。外観を気にする方は最初からメモリを8GB搭載した状態で発注したほうが精神衛生上よろしいかもしれません。
また、Appleの公式ではこの機種に搭載できるメモリの最大容量は8GBとのことですが、実際には16GB搭載できるようです。
ウェブブラウジング
私がメインで使っているブラウザは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本来の４コアに加え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が高温になってからファンの回転数が上昇するのにはタイムラグがあります。どうもシステム的にはバッテリーの持ちやファンの耐久性を考慮してできるだけ回転数を抑える戦略になっているように見えます。
また、省エネルギー設定で「グラフィックスの自動切り替え」を有効にしていると、低負荷時には電力をより多く消費する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以下の指向性を感じなくなる音域の音を主に鳴らすためにあるのでは・・・？
これはハードウェアの不具合なのかソフトウェアの不具合なのかはわかりません。 しかし、以下の条件を満たすと再現します。
この状態でアカウントからログオフすると、ログオンスクリーンに点滅する灰色の四角が現れます。 ちょうどマウスカーソルがある位置に現れるようです。
最初はGPUの不具合でこのような現象が起きているのかと思いましたが、Apple Hardwar Testを実行しても異常は報告されず、画面共有を用いてリモートで操作しても同様の現象が発生しましたので、ソフトウェアの不具合の可能性も否めません。まだ購入して1ヶ月も経っていないため、時間のあるときにアップルのサポートにでも連絡を取ってみようと思います。
若干の不具合がありましたが、性能には概ね満足していますし、クアッドコアを搭載したパソコンが高々2キログラムのボディに収まってそれを自由に持ち運びができるとは、すごい時代がきたものです。MacBook Proの購入を検討されている方で、性能を重視する方はクアッドコアCPUを搭載したモデルを是非ともおすすめします。重量が重いという難点はありますが、それ以上の価値はあると思います。
余談になりますが、私のはじめてのノートパソコンはPC-9801NS(中古)で、学生時代はMS-DOS上のMIDIプレイヤー(MIMPIという名前だったと思います）を走らせてライブで打ち込みを流したりしていました。
今回発売されたOS X Mountain Lionでは旧機種の切り捨てが行われ、Appleからは2007年以前に発売の殆どの機種で動かないことが公式に発表されました。
ところが、海外のフォーラムでOS X Mountain Lionが動かないとされる旧機種で無理矢理インストールして動かしてしまった方がその方法を発表されていましたので、こちらに和訳して載せたいと思います。
なお、これは非公式な方法ですので、この方法を行った事による一切の損害に対しての責任は負いかねます。あくまで自己責任にて行って下さい。
原文はこちら：[GUIDE] SUCCESS! Install 10.8 on OLD unsupported Mac
準備：あらかじめMountain Lionインストール用に20GB程の大きさのパーティションを作成しておくこと。
訳者注：手順はこれで終わりではありません。グラフィックとサウンドを有効にする手順が続きますがそれは後編にて。詳しく知りたい方は原文を参考にしてください。
先日のことですが、今までMovableType 5.1で運営していたこのブログをWordPressへと移行してみました。
移行したきっかけはやはりMovableTypeの再構築にかかる時間の長さです。現在は自宅サーバーで運営されている当サイトですが、近日中に諸事情から安いVPSに移行しようかと計画しておりまして、その際ブログのカスタマイズを行ったりする度に（安い低スペックなVPSでは）再構築に何十分も待たされるんだろうな、と考えていたことから、WordPressへと移行したというわけです。
MovableTypeにはブログデータをエクスポートする機能が標準で備わっていますが、今回はこれを使いません。一度この機能を使って移行してみたのですが、ブログエントリの「タグ」が移行されませんでした。
そこで
MovableTypeからWordPressに固定リンク込みで完璧に移行する方法を参考に、一旦MovableTypeのデータをXMLで書き出してそれを利用することにしました。
私の環境では、今までMovableTypeで扱ってきた画像などのファイルは全て/blogディレクトリ以下の様々なディレクトリに保存されているのですが、この/blogディレクトリを/mt_oldに改名します。と同時に、中にある画像以外のファイル(MovableTypeが生成したhtmlファイルなどは全て削除します） 本当はこのディレクトリを名称変更せずにそのまま使いたかったのですが、このディレクトリ内部にMovableTypeが生成した日付などのフォルダが存在するとWordPressで不具合が発生したので思い切って別ディレクトリに移動しました。
1の工程でエクスポートしたXMLファイルをエディタ等で開き、href=”hogehoge/blogやsrc=”hogehoge/blogとある場所（以前のブログの画像などのパス等）をhref=”hogehoge/mt_oldやsrc=”hogehoge/mt_oldに置換します。
画像パスの置換さえ上手くできていれば、先ほどのXMLファイルをWordPressへインポートするだけで既にブログとして機能するようになりますが、パーマリンクなども維持したいという場合にはもう少し作業が必要です。
私の場合は、以前MovableTypeで使用していたパーマリンクの書式に則って、以下のように設定しました。
MovableTypeからインポートすると、カテゴリのスラッグは引き継がれずカテゴリ名のままになってしまいますので、これを修正します。 カテゴリが多数有ると面倒ですが、手作業でやらないといけません。
MovableTypeの時には、カテゴリアーカイブのパーマリンクは「/blog/categoryname/」となっていましたが、WordPressの場合ですと「/blog/category/categoryname/」のように、「category」という文字が途中で入ってしまいます。そこで、MovableTypeの時のパーマリンクと互換性を持たせるためにこの部分を消してやります。それには「WP No Category Base – WPML compatible」というプラグインを使います。
WP No Category Base – WPML compatible
以上の作業で、MovableTypeのブログをWordPressに移行することはできましたが、若干の問題が残ります。
MovableTypeで作成したブログのエントリのパーマリンクにハイフン「-」が含まれていると、WordPressにインポートする際にアンダースコア「_」に変換されてしまう事があります。（変換されない場合もある）
私のブログの場合はアクセス数も少なく、ソーシャルブックマークなどからもあまりブックマークされていませんので、そのまま放置して、Googleに再インデックスしてもらうのを待つことにしました。
パーマリンクのハイフンがアンダースコアに変換されてしまう問題のおかげで、404 Not Foundが大量に発生し、Googleのウェブマスターツールを見ると大量の404エラーが記録されていました。当然、アクセス数は5分の1まで激減！ それでもこのブログはアクセス数の減少はそれほど致命的ではないので再インデックスを気長に待つことにします。
やはり、ブログをあれこれいじくったあとに再構築をしなくても良いというのは快適です。また、画像などのアップロードがドラッグ＆ドロップで行えるようになったので、時々ではありますが画像を多用する当ブログでは編集作業も楽になるのではないかと思います。
ちなみに、移行後「WordPress Super Cache」というプラグインを入れて、負荷を少しでも減少させるようにしてみました。
いよいよブックマーク機能を実装しました。
今回は、ブックマーク機能を実装するにあたって利用したMVCという設計手法とXBELという規格の話が中心です。
まずはスクリーンショットをご覧下さい。一般的なウェブブラウザに搭載されているような階層構造を持ったブックマークがウィンドウ左側に表示されているのがわかると思います。
このブックマーク機能の仕組みですが、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がどのように働くかを説明します。
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が存在する場合でも
画面に複数のドキュメントウィンドウが開かれている等、複数のViewが存在する状況でも、単にModelはそれぞれのViewに対して同時にModel更新の通知を送ってやれば、各Viewの表示内容が一斉に更新されるわけです。今回ブックマーク機能の実装にあたりMVCを利用した最大の理由が「場合によっては画面に複数のViewが存在する」という理由です。
ドラッグ＆ドロップの実装
今回一番時間がかかったのが、ブックマークのドラッグ＆ドロップによる編集です。
TreeViewにはドラッグ＆ドロップをサポートする機能が標準で搭載されていますが、若干機能不足です。
たとえば標準のドラッグ＆ドロップではTreeNodeを他のTreeNodeの上にドラッグし、ドラッグされたTreeNodeの子とすることは簡単にできますが、あるTreeNodeを二つのTreeNodeの間にドラッグして任意の位置にアイテムの挿入を行う、といった機能はありませんから、こういった機能は自前で実装する必要があります。
また、ドラッグ＆ドロップにも下記のようなルールを設ける必要があります。
これらの機能を一つ一つ検証しながら実装していたのですが、あまりにもややこしすぎて時間がかかってしまいました。
ブックマークの保存形式
ブックマークの保存は、ブックマーク記述言語「XBEL」形式で行います。XBELとはXML Bookmarks Exchange Languageの略で、XMLを利用したブックマークの相互利用のための規格です。XML形式ですので、ブックマークの保存の際にはブックマークのツリー構造を再帰的に辿ってXmlDocumentを構築した後、ファイルに出力しています。XBEL形式に関してはこのページを参考にしました。
この形式を利用する利点は、様々なブラウザのブックマークとの相互変換が可能である事です。自作のアプリとはいえ、独自のデータ形式を使ってしまっては後々困ることになりますから、オープンな規格はどんどん利用すべきだと思います。
さて、次回はWeb版、デスクトップアプリ版両方のDMMアフィリエイトリンク作成ツールに搭載されているキャッシュシステムについて書いてみようかと思います。
最近のブラウザには「要素を調査」という機能が搭載されていますが、Firefox 11に搭載のソレは凄いことになってしまっているので紹介します。
まずは普通に適当なサイトを開いてみます。
次に、ページの適当なところで右クリックし、「要素を調査」を選択。
続いて、ウィンドウ右下の「3D」をクリック。
すると・・・ページの各要素の階層構造が3Dで視覚化されます。ある要素が別の要素に内包されている様子がとてもわかりやすく表示されます。
この3D画面はマウスをつかってぐるぐる動かせたりできます。
なおこの機能はMacでは動きましたが、Windowsでは「3D」のボタンが出てきませんでした。
今回もまた、プログラミングに関する記事です。大変申し訳ございません。
前回のエントリを書いてから、空き時間を見つけては地道に作業を続けておりました。
前回からの改善点は
徹底したマルチスレッド化
前回のバージョンではURLボックスにURLを入力して情報取得ボタンを押すと、すべての情報の取得が完了するまでウィンドウがフリーズした状態になっていました。画像が多い場合、全情報の取得には10秒以上かかる場合もあり、その間ユーザーは何の操作もできずに待たねばならなかったのです。これはすべての処理をシングルスレッドで行っていたため、情報取得が完了するまでメインのGUIスレッドが止まるからです。
ところが、たくさんある商品の情報を次々と取得したい場合、ある商品のURLを入力し、表示が完了するまで待ち、次の商品のURLを入力し、また待ち、なんてことはかったるくてやってられません。
そこで、今回はHTMLのスクレイピングから画像の取得まで、すべてをスレッド化し、個別の情報が取得でき次第次々とイベントが発生するように改良しました。発生したイベントはメインのUIスレッドに伝えられ、その度に画面の更新が行われます。この状態でもメインのイベントループが動き続けているため、他の操作を行うことができます。
おかげで、下の画像のようにたくさんのウィンドウを開いて次々と情報取得を行っても非常にぬるぬるとなめらかに動くようになりました。
エラー処理の強化
シングルスレッドで処理を行う場合、極端な話必要な処理を関数として書けるので、どこかでエラーが発生すればその時点で関数を抜けて処理を中断し、エラーが発生したことをユーザーに告知するだけのシンプルなプログラムで済みます。
ところがマルチスレッドの場合には話がすこしややこしくなります。
たとえば平行していくつものスレッドが動いている場合、あるスレッドは正常に完了したが、あるスレッドは途中でエラーが起きた、という状況が起きます。具体的には、複数の画像データをマルチスレッドで平行してダウンロードしていたがある画像のダウンロードだけは途中で失敗した、等のケースです。この場合、あるスレッドで発生したエラーをどのようにメインスレッドに伝えるかが問題となります。.NETではあるスレッドで発生した例外を他のスレッドでキャッチすることができないので、例外が発生した場合にはイベントを発生させてメインスレッドに例外を伝えるということをやっています。
また、エラーの告知方法も少し工夫しました。
このツールでは、ユーザーが商品情報の取得を開始して比較的早期に発生したエラー（URLの入力ミスやパッケージ画像が取得できなかった等）はダイアログを表示してその時点で処理が中断されます。
今後搭載したい機能今日は久々にプログラミングの話題です。
当ウェブサイトで公開しております「DMMアフィリエイトのリンク作成支援ツール」はいわゆるWebブラウザを使ってサービスにアクセスするWebアプリケーションの形になっておりますが、Windows版のツールの開発も開始しました。
まだまだ完成にはほど遠く、公開できる状態にはなっておりませんが、DMMサイトからの商品情報を取得して画面に出力する部分まではうまく出来たようです。Webで公開しているWebアプリケーション版と違い、こちらはサンプル画像の取得もできるようになっています。
当初、画像を一覧形式にして表示する部分は自前で実装してしまおうかと思いましたが、Windowsに標準で搭載されているListViewの使い勝手が思いの外良かったのでこちらを利用しました。ご覧の通り、画像をグループ毎にまとめることができ、これはWindows XPから実装された機能のようで、Windows標準のエクスプローラなどにも使用されています。おかげで自前で画像ビューアを作る手間が省けました。
技術的なこと
以前にもこのブログで書いたことがあるのですが、Webアプリケーション版のツールはPerlやPHP等ではなくC#で開発されています。従ってこのようにWindows版を作ることもすぐに出来るわけです。
