SimpleBoxes

ラグビーワールドカップ 2011 日本 vs フランス

いよいよラグビーワールドカップ 2011 が始まりました。ちょっとしたお祭り雰囲気になっています。

昨年の 6 月にラグビー日本代表とニュージーランド・ノースハーバー州代表の対抗試合を観戦しましたが、今回本命 (?) の日本代表対フランス代表を観戦してきました。

[写真1]ノースハーバースタジアム・試合前

会場は日本代表とノースハーバー州代表の試合と同じノースハーバースタジアム。前回は正面に見えるグランドスタンドで観戦しましたが、今回は反対側のオープンスタンドより観戦。屋根がない席のため、天気が心配でしたが、ご覧のとおり、快晴でした。

[写真2]日本代表、試合前アップ

試合前の練習風景。中央に見えるスーツ姿の男性は、おそらく日本コーチで元オールブラックスのジョン・カーワンだと思うのですが……。

[写真3]試合直前

試合直前。両チームが円陣を組んでいます。日本は赤いユニフォームで、フランスは白いユニフォーム。日本のユニフォームは昨年見たときから少し変わっています。

[写真4]ラックからボールを出す日本

前半は (フランス) 25 - 11 (日本) で折り返します。前半だけ見ると、やはりフランスは世界ランク 4 位だけあって力の差がある印象で後半このままずるずると離されるのかと思ったりもしたんですが……。

[写真5]アレジ選手のコンバージョン

後半、二度に渡るピンチをどうにか凌ぐと日本の猛攻が始まります。アレジ選手大活躍!!日本の全得点は彼によるもので、マン・オブ・ザ・マッチにも選出されたのも納得の活躍でした。

[写真6]4 点差!

あと 4 点、1 トライで逆転というところまで追い詰めます。フランスも焦ったのかハンドリングミスを連発したり、完全に流れが日本という感じに……。

残念ながら、その後地力を差が出て最終的には 47 - 21 という差になってしまいましたが、内容的にはとても良い感じで、ワールドカップの雰囲気を味わうこともできたし、私的にはかなり楽しめました。よかったよかった。

日本代表には是非とも結果を残してもらいたいです。

スポンサーリンク

FloatyMemo / FloatyMemo+ ver 1.09 リリース

FloatyMemo ならびに FloatyMemo+ ver 1.09 がリリースされました。

今回は FloatyMemo+ で「メモ一覧」をサポートしたのがもっとも大きな変更になります。

iTunes Store で頂いた takuxya さんの要望

できれば、
■□□□□□□□・・・
↑の現状の仕様通り、右にページが増えるモードと別に、

□□□
□■□
□□□
↑のようにタイル状にページが増えるモードが欲しいです。
一番右のページまでスクロールさせるのが結構時間かかるので。

[→FloatyMemo+ カスタマレビュー]

をアレンジして実装した形になります。アイデアをご提供いただき、ありがとうございました。

新たに追加された「メモ一覧」ボタンをタップするか、ページ自体をピンチすることで「メモ一覧」モードに移行します。

FloatyMemo+ 自体は横一列にページが配置されていますが、ページ一覧ではスペースをより効果的に利用するため、各ページがタイル状に配置されます。

[イメージ]メモの一覧表示

以下、技術的なお話。

「メモ一覧」では、各ページのスナップショットをイメージとして取得して、それをタイル状に並べることで実装しています。

この「スナップショット」は、UIKit の UIGraphicsGetImageFromCurrentImageContext() 関数を利用することによって実現しています。

ただ、そのままの実装だと、最大までページを追加した状態 (16 ページ) だと、簡単にメモリ不足に陥ってしまい、OS から強制終了されてしまいます。

とくに初代 iPad だとあっさり落ちることが多く、メモリ不足で強制終了された場合、デバグもできない状態になります。

最初はメモリの警告を受け取ったら、それ以降はサムネイルを作成しないようにしたんですが、一部しかページサムネイルが表示されないのはあまりにあんまりです。

UIKit のドキュメントをつらつら見ていたら、UIGraphicsBeginImageContextWithOptions 関数に気づきました。

イメージコンテキストを初期化する関数 UIGraphicsBeginImageContext に追加のオプションが指定できる関数で、iOS4 から利用できます。

この関数の三番目の引数 CGFloat scale で iPhone4 などの Retina ディスプレイでは高解像度のイメージが取得できます。

UIGraphicsBeginImageContextWithOptions(view.bounds.size,
                                       view.opaque,
                                       [[UIScreen mainScreen] scale]);

のように [[UIScreen mainScreen] scale] を渡すとデバイスの解像度に応じたイメージが取得できます。

この scale に実際の解像度より小さい値を渡すと、実際よりも低い解像度のイメージを取得することもできます。そうすることで使用メモリも大幅に減らすことができます。

今回のようにサムネイルとして利用する場合は、実際の解像度は必要ありません。むしろ利用するメモリを制限するために、あえて低解像度のイメージを取得するようにします。

UIGraphicsBeginImageContextWithOptions(view.bounds.size,
                                       view.opaque,
                                       [[UIScreen mainScreen] scale] * 0.5);

これで初代 iPad で最大ページを利用していてもかなり安定して動作するようになりました。

iOS4 より前の OS でも動作するようにするためには UIGraphicsBeginImageContextWithOptions が利用できるかチェックする必要があります。

if (UIGraphicsBeginImageContextWithOptions != NULL)
{
  UIGraphicsBeginImageContextWithOptions(view.bounds.size,
                                         view.opaque,
                                         [[UIScreen mainScreen] scale] * 0.5); 
}
else
{
  UIGraphicsBeginImageContext(view.bounds.size);
}
[view.layer renderInContext:UIGraphicsGetCurrentContext()];
UIImage* image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

iOS4 より前では、解像度の指定はできなくなってしまいますが、マルチタスクでもないため、とりあえず、これでよいかなと思っています。

スポンサーリンク

OS X Lion で FastCGI を利用する

Mac OS X 10.6 Snow Leopard のときには FastCGI が標準でインストールされた状態でした。

ですので、FCGI モジュールを CPAN 経由でインストールして、conf ファイルで FastCGI モジュールを読み込むように設定するだけで FastCGI に関する基本的な設定 (perl CGI で FastCGI を利用するための下準備) は完了できました。

しかしながら、Mac OS X 10.7 Lion では標準で FastCGI がインストールされていませんので、自前でインストールする必要があります。

FastCGI 最新版と FastCGI Apache2 モジュール最新版を fastcgi.com からそれぞれ取得します。

まずはいつものように FastCGI をインストール。

$ tar zxf fcgi-current.tar.gz
$ cd fcgi-(VERSION)
$ ./configure
$ make
$ sudo make install

続いて Apache のモジュールをインストール。

$ tar zxf mod_fastcgi-current.tar.gz
$ cd mod_fastcgi-(VERSION)
$ apxs -o mod_fastcgi.so -c *.c
$ sudo apxs -i -a -n fastcgi mod_fastcgi.la

参考 : Running Movable Type on OS X with FastCGI & apxsでapacheにモジュールを追加する

perl の FCGI モジュールは cpan コマンドでインストールしておきます。

httpd.conf で インストールした FastCGI をロードするように追加します。

LoadModule fastcgi_module libexec/apache2/mod_fastcgi.so

最後に Apache2 を再起動して設定終了です。

$ sudo apachectl restart

スポンサーリンク

FloatyMemo / FloatyMemo+ ver 1.08 リリース

FloatyMemo ならびに FloatyMemo+ ver 1.08 がリリースされました。

今回はシゴタノさんのところ「シンプルに使えるiPad付箋アプリ3選」で要望 (?) として挙がっていた

付箋新規作成のアクション(画面ダブルタップが望ましい)

[→シンプルに使えるiPad付箋アプリ3選]

を追加機能として盛りこんでみました。

倉下忠憲さん、ご紹介いただきありがとうございます。

また、同時にご利用いただいているユーザーから頂いたメモ位置の保存に関する不具合を修正しています。

FloatyMemo / FloatyMemo+ ではメモ位置をその時の座標位置をそのまま保存しています。

縦画面・横画面も一応考慮しているのですが、iOS の仕様上、アプリケーション開始時に横画面になっていても、内部では常に縦画面で開始される動作になっていました。

この動作に基づいて座標の変換処理を入れるようにしましたが、誤差が結構ある様子なので、FloatyMemo / FloatyMemo+ の再起動を何度も繰り返すと徐々にずれていってしまいます。なので完璧ではありませんが、とりあえず以前の動作よりもずいぶん素直な動作になったと思います。

スポンサーリンク

Safari 5.1 の機能を強化する - SIMBL プラグイン・機能拡張

MacBook Pro セットアップ - デフォルトアプリケーション編」でも触れたとおり、Mac OS X Lion 導入を機に Safari をデフォルトウェブブラウザとして利用するようになっています。

Safari 用の SIMBL プラグイン

Safari の機能を強化する定番 SIMBL プラグインに SafariStand があります。

SafariStand には色々な機能がありますが、その中でも個人的に重宝していた機能は

  • セッション復元機能
  • アドレスバーのキーワードサポート

の二つです。前者は Safari 5.1 で正式にサポートされるようになりましたが、後者は Safari 単体ではまだできないようです。

最近、このキーワードをサポートする Safari Omnibar という SIMBL プラグインを見つけました。

Safari Omnibar のもっとも特徴的な機能はアドレスバーと検索バーの統合です。Safari Omnibar をインストールすると、検索バーがなくなります。アドレスバーが検索も兼ねる Google Chrome のような動作になります。

キーワードは SafariStand 同様カスタマイズすることができます。SafariStand とも併用できますが、キーワードが重複していると、Safari Omnibar の方が優先されます。

Safari Omnibar でキーワードをカスタマイズするには、アドレスバーでコンテキストメニュー (右クリックあるいは Ctrl + 左クリック) を表示して「Edit Omnibar Search Providers ...」を選択します。

[イメージ] Safari Omnibar のメニュー

{searchTemrs}が入力された検索ワードで置き換わります。「Set as Default」ボタンで選択されたプロバイダをデフォルトプロバイダとして設定します。

[イメージ] Safari Omnibar 検索プロバイダの設定

デフォルトになったプロバイダは「編集」メニュー「検索」でも利用される他、「?」キーワードでも利用できるようになります。

Safari の機能拡張

Safari では ver 5 より機能拡張に対応しています。2011.08.14 現在、インストールした機能拡張は以下の通り。

Hatena Bookmark Safari Extension

見ているページをはてなブックマークでブックマークしたり、ブックマークコメントを見たいときに利用します。

Firefox 版 / Chrome 版もあります。

AutoPagerize

複数のページに別れたウェブページをページ遷移することなく、その場で継ぎ足しロードしてくれる定番の機能拡張です。

Firefox 版 / Chrome 版もあります。

User CSS

特定のウェブページに独自のスタイルシートを適用することができる機能拡張です。

Firefox / Chrome では Stylish という機能拡張を使って、特定ページのスタイルをカスタマイズしていましたが、User CSS でもほぼ同様なことができます。Stylish のように作成したスタイルシートを共有する仕組みがありませんが、私の利用範囲では十分。

AdBlock

広告イメージやフラッシュを非表示にしてくれる定番機能拡張です。

Firefox 版 / Chrome 版もあります。

Ultimate Status Bar

Firefox 5 や Google Chrome のような可変長ステータスバーを表示してくれる機能拡張です。

気がつくとこちらのスタイルにすっかり慣れてしまっていたので、導入してみました。

時々うまく表示されないことがあったりしますが、それ以外は快適に利用できています。

スポンサーリンク

MacBook Pro セットアップ - デフォルトアプリケーション編

Mac OS X Lion になって、これまで Leopard / Snow Leopard とデフォルトで使ってきたアプリケーションが変わりました。

ブラウザ
Firefox → Safari
メーラー
Thunderbird → Outlook
開発環境
Xcode 3 → Xcode 4

Firefox / Thunderbird という Mozilla 組でも問題があるという訳ではないのですが、

  • Safari → 動作が軽快。スワイプジェスチャーによる「戻る・進む」動作が視覚的に分かりやすい
  • Outlook → 動作が軽快。横長レイアウトが見やすい

という点が気に入って、現在 Safari と Outlook (Microsoft Office 2011) を使っています。

Firefox / Thunderbird どちらも Maximizer を利用することでフルスクリーンアプリケーションとして利用することができます。

Word / Excel / PowerPoint は Carbon アプリケーションで Maximizer でもフルスクリーン化できませんが、Outlook は Cocoa アプリケーションでフルスクリーン化が可能です。

メーラーに関しては、Apple 純正の「メール」も候補の一つでした。Mac OS X Lion の「メール」は横長レイアウトがサポートされ、フルスクリーンで利用することで、MacBook Pro 13 インチの画面の狭さがあまり気にならなくなります。

「メール」だとフルスクリーン化した時、メールの編集画面がその場で開きます。Landscape (横画面) で使っているときの iPad のメール編集画面と同じように動作すると言えばイメージできるでしょうか。

[イメージ] メールでのメール編集画面

一方、Outlook では Maximizer でフルスクリーン化している影響もあるのだと思いますが、メール編集画面は別画面で開きます。結果、もうひとつ別のフルスクリーンが追加されるような形で動作します。

[イメージ] Outlook でのメール編集画面

一見すると、「メール」での動作の方がフルスクリーンアプリケーションとしては自然な感じがするのですが、このインタフェースだとメール編集中に他のメールが見ることができないという欠点があります。

他のメールからコピーしたいときは一度下書き保存してメール編集画面を閉じる必要があります。一方、Outlook の方式だと、メール画面は別スクリーンなので、Outlook のメインスクリーンに戻れば、いつでも他のメールを確認することができます。

また、私の環境では、Apple 純正の「メール」よりも Outlook の方がキビキビ動作している印象です。

Outlook も IMAP 接続でサーバ側ですでにある「下書き」フォルダや「送信済み」フォルダを使ってくれず、独自のフォルダを作成してしまうという作法的にどうなのという仕様がありますが、使い勝手の面で Apple Mail / Thunderbird に優っていると今のところ感じています。

開発環境は Xcode 4 に……。Xcode 3 はおそらく Mac OS X Lion にはインストールできません (試していませんが)。Xcode 3 & Interface Builder という組み合わせでできていたことが、Xcode 4 でできなくなっていたりします (例えば、高解像度での xib ファイル編集など)。

とは言っても、MacBook Pro になって初代 MacBook で感じていた「重さ」は解消されましたし、タブインタフェースとフルスクリーンの活用で、画面の「狭さ」はあまり気にならなくなりました。

ちなみに以下のアプリケーションを通常フルスクリーンで利用しています。

  • Safari
  • Outlook
  • iTunes
  • iPhoto
  • Xcode 4

Maximizer を利用しているせいなのか、iPhoto はフルスクリーンで挙動不審になることがあります。iLife アプリケーションは、今のところ iPhoto ぐらいしか使っていませんが、おそらく GarageBand や iMovie もフルスクリーンで利用したほうがいいような気がします。

ちなみにフルスクリーンはマルチディスプレイ環境とは、あまり相性がよくありません。フリーズするとかそういう相性ではなく (私の環境では一度もフリーズしたことはありません)、インタフェース的にマルチディスプレイが考慮されていない感じ。

フルスクリーン化されたアプリケーションはメイン画面のみに表示され、サブ画面はログイン画面でも利用されているデフォルト背景が表示されるだけの画面になります。……なんかもったいない。フルスクリーンのサブ画面は補助的なデスクトップとして利用できたりしたら、ぐっと使いやすくなる感じがするのですが。

スポンサーリンク

Mac OS X Lion における Launchpad に関するアレコレ

[イメージ] Mac OS X Lion で導入された Launchpad

Mac OS X Lion で新たに導入された Launchpad ですが、正直なところ使い勝手は今ひとつという印象。

こんな人には向いている……?

まっ更な状態から始めるという方には Launchpad は使いやすいかもしれません。

アクセスのしやすさは抜群 (Mac OS X Lion がプリインストールされたラップトップなら専用キーもある) ですし、インストールされたアプリケーションを俯瞰してざっくり探すのには向いています。

Mac App Store からインストールされたアプリケーションは、ここを見ればあるのが確実なので、迷うことも少ないでしょう。

なにより iPad / iPhone のスプリングボード (ホーム画面) と同じようなインタフェースで、同等のユーザーエクスペリエンスを実現しています。同等なグループ機能ももちろんサポートされているので、同じような感覚で利用できます。

Snow Leopard から移行すると……

ただ、Snow Leopard から移行した場合には、「アプリケーション」フォルダにあるアプリケーションは、ほぼもれなくリストアップするという仕様が「あだ」になっているような気がします。

Snow Leopard から移行した場合、以下のようなルールでリストアップされているようです。

  • メインの「アプリケーション」フォルダ以下のアプリケーション
  • 「アプリケーション」内の「ユーティリティ」フォルダは「ユーティリティ」グループとして登録
  • 「ユーティリティ」以外のサブフォルダは第一階層のみ「アプリケーション」フォルダ直下に置かれているものとして扱う。例:Micorosoft Office 2011
  • サブディレクトリの第二回層以下はフォルダ名をグループ名にして登録
  • ホームディレクトリ直下に置かれた「アプリケーション」もメインの「アプリケーション」と同等に処理される
  • 「/Developer/Applications」の直下に置かれたアプリケーションは「Developer」グループとして登録

従って Snow Leopard から移行すると、いきなり大量のアプリがざっくり平面的に登録されている、なかなかカオスな状態でスタートします。

上述のルールを元に Lion に移行する前に Snow Leopard のアプリケーションディレクトリを整頓しておくのはひとつの「手」です。アプリケーションによっては場所を変えるとまずいものもあるかもしれませんが。

解決策はあるのかな?

それでも柔軟にカスタマイズできれば問題ないのですが、インタフェースは基本的に iPad / iPhone のスプリングボード (ホーム画面) を移植してみた程度の出来で、「カスタマイズも面倒くさい」というのが正直な印象です。

編集モードで複数のアプリケーションを選択できるようにしたり、キーボードショートカットで削除できるようにするだけでも、かなり印象が違うと思うのですが……。

余談になりますが、Launchpad ではアイコンを長押しして編集モードに入る iOS 的な操作以外に option キーを押すことで編集モードに入ることができます。shift キーを押すとスローアニメーション、カーソルの左右キーでページ移動がそれぞれ可能です。

Lunchpad Control を利用すると Launchpad で表示するアプリケーションを選択できます。

余計なアプリケーションを隠すことができるので、ずいぶん使い勝手がよくなります。

一度非表示にしたアプリが不意に復活してしまう場合があった (OS の再起動で非表示にしたアプリが再登録されてしまうのかも……) ので、現在は使用を一時的に休止しています (2011.08.12 現在)。

Launchpad Control は「~/Library/Application Suppprt/Dock/」以下にあるデータベースファイルを編集して Launchpad での表示されるアプリケーションを制御しているようです。

リストを編集した際にオリジナルのデータベースファイルには backup という拡張子が付加されてバックアップ用に複製されるようです。

スポンサーリンク

MacBook Pro セットアップ - 補助的アプリケーション編

MacBook Pro セットアップ - システム環境設定編に続いて、SIMBL などの補助的アプリケーションについて

ImageUp

ImageUp は入力ソース (インプットメソッド・IME) の状態をメニューバーを使わずに視覚的に表示してくれるツールです。

フルスクリーンアプリケーションでは、基本的にメニューバーが表示されないので、現在日本語入力状態なのか、英語入力 (直接入力) 状態なのかが、一目では分かりません。

[イメージ] マウスカーソル付近に表示された入力状態マーカー

ImageUp では、「A marker at the cursor」というオプションをオンにすることによって、マウスカーソル付近に入力ソースの状態に応じてマーカーが表示されます。

メニューバーを表示したり、テキスト打ってみたりしなくても、入力状態が一目で分かるようになります。

SIMBL プラグイン

SIMBL そのものは新規ではないのですが、新たに Maximizer を導入したので、触れておきます。

Maximizer は Cocoa アプリケーションで「フルスクリーン」に対応していないアプリケーションをフルスクリーン化するプラグインです。

Drift Diary XIII さんの「Maximizerで一足先にLionの新機能を満喫する」にあるとおり、Mission Control できちんとフルスクリーンアプリケーションとして認識してくれるようになるのが大きな特徴です。

相性の良い・悪いはあるようですが、後述する Outlook がきちんとフルスクリーンアプリケーション化されるので、重宝しています。

Safari Stand は定番 Safari 強化プラグインですね。アドレスバーでキーワードが利用できるようになるのが、かなり便利です。

Homebrew
  • wget
  • git
  • imagemagick

Homebrew は Mac OS X 上の UNIX のパッケージを管理するソフトウェアです。

これまでは MacPorts を利用していました。MacPorts では、バイナリを /opt/local/bin/ という独自のパスにインストールするためパスを通したり、シンボリックリンクを張ったりハック的な運用が必要でした。

Homebrew では、標準にパスとして通っている場所にバイナリをインストールするので、標準な環境と親和性が高くなっているのが特徴です。

実際、MacPorts では若干苦労していた ImageMagick のインストールは Homebrew を使ったら、呆気なくできたり……。素晴らしい。

git は Xcode 4 と一緒にインストールされるので、必要ないんですが、テスト的に brew を使ってアップデートしました。

スポンサーリンク

MacBook Pro セットアップ - システム環境設定編

Mac OS X Lion になって色々と新しく機能が追加されたのに伴い、Snow Leopard と作法が変わった部分もあります。

基本的にはできるだけ Mac OS X Lion の新しい作法に準じる方向で使っていたほうが後々楽だと思うのですが、まだ不安定な部分もあったりするので、試行錯誤しながら使っています。

2011.08.11 現在、「システム環境設定」の主な項目は次のように設定しています。

一般
  • アプリケーションを終了して再度開くときにウィンドウを復元 → オフ

[イメージ]システム環境設定:一般

これだと Safari のセッションが復元されなくなってしまうので、Safari の「復元」だけを個別にオンにします。ターミナル上で

defaults write com.apple.Safari NSQuitAlwaysKeepsWindows -bool true

というコマンドを発行します。

「オン」にしていないのは、defaults コマンドで制御できないアプリケーションがあるからです。Carbon なアプリケーションはその傾向が強く、当面全体の設定は「オフ」でオンにしたいアプリケーションだけ defaults コマンドでオンにするという運用にします。

Dock
  • 画面上の位置 →
  • 起動済みのアプリケーションにインジケータ・ランプを表示 → オン

[イメージ]システム環境設定:Dock

Dock の位置は左側で。以前は右側に置いていましたが、最近はメインスクリーンが左側にくる傾向が強いので、Dock は左側に配置しています。

Mission Control
  • Dashboard を操作スペースとして表示 → オフ
  • 最新の使用状況に基づいて操作スペースを自動的に並べ替える → オフ

[イメージ]システム環境設定:Mission Control

Dashboard はあまり使わないので、そのためのスペースは必要ありません。

デスクトップからフルスクリーンに切り替えたときに、そのフルスクリーンが該当するデスクトップの右に来るような動作になっている感じですが、順番がころころ変わってむしろ鬱陶しいので「デスクトップは左・フルスクリーンは右」に固定。

本来はドラッグで自在に順番を変えられるべきだと思うのですが、どうなんでしょうね。

トラックパッド
  • タップでクリック → オン
  • スクロール方向:ナチュラル → オン
  • ページ間をスワイプ → オン:2 本指で左右にスクロール
  • フルスクリーンアプリケーション間をスワイプ → オン:3 本指で左右にスワイプ
  • Mission Control → オン:3 本指で上にスワイプ
  • アプリケーション Expose → オン:3 本指で下にスワイプ
  • Launchpad → オン:親指と 3 本指でピンチ
  • デスクトップを表示 → オフ

[イメージ]システム環境設定:トラックパッド・ポイントとクリック [イメージ]システム環境設定:トラックパッド・スクロールとズーム [イメージ]システム環境設定:トラックパッド・その他のジェスチャ

話題になっているスクロール方向は「ナチュラル」で。他の Snow Leopard / Windows XP / Windows 7 の環境も全てナチュラル準拠の方向に統一しました。

本当はトラックパッドのみ「ナチュラル」で、マウスのホイールはスクロールバーを操作するという形で設定したいのですが……。

Snow Leopard では Scroll Reverser で、Windows では AutoHotKey で。Windows ではトラックパッドのドライバによって「ナチュラル」と同じ方向に設定できる場合もあります。少なくとも、Synaptics のドライバソフトウェアでは可能でした。

「ページ間をスワイプ」は Mac OS X の標準設定に従っています。あとで触れますが、デフォルトブラウザを Safari にしたので、この設定でも特に問題ありません。

ユニバーサルアクセス
  • マウスとトラックパッド / トラックパッドオプション / ドラッグ → オン:ドラッグロックなし

[イメージ]システム環境設定:ユニバーサルアクセス

タップでクリックをオンにしたので、ドラッグ操作を行うためにこのオプションを設定。

「3 本指でドラッグ」というオプションが「トラックパッド」の方にありますが、これをオンにすると、Misson Control の操作に 4 本指を使わなくちゃいけなくなってしまって、少し億劫に感じたので、「3 本指でドラッグ」を使わずにこちらのドラッグオプションを有効にしています。

スポンサーリンク

MacBook Pro 13 インチ (Early 2011) を購入

[写真] MacBook Pro 13 インチ (Early 2011) を購入しました。

MacBook Air がリニューアルされたタイミングになりましたが、MacBook Pro 13 インチを購入しました。

ユニボディは、格好良いだけじゃなくて、剛性もしっかり取れている印象です。所有している MacBook は、パームレスト部分が黄ばんで交換しましたが、そういう心配もなさそう。

という訳で、いずれは欲しいなぁ……。

[→新しい MacBook が発表された]

現行デザインの MacBook が発表された 2008 年にこんなことを言っていましたが、三年越しにそれが実現したことになります。

新しいマシンを選ぶ

長らく [*1] 初代 MacBook を愛用してきましたが、ここ最近になって、重めの作業を行うと突発的にフリーズしてしまうことがたびたびありました。

[*1] 初代 MacBook は 2006 年 6 月から使用していて、丸 5 年間使用していることになります。

扇風機の風を当てたり、保冷剤をあてがったりして、しのいできましたが、それを見かねた嫁さんから「新しいのに変える?」と言われ、新しい機種の選定に……。

条件としては……

  • 予算は 10 万円以内
  • 今後 5 年は利用したい

初代 MacBook のディスクの使用状況を考えると、最低でも内蔵ストレージは 128GB は欲しい。今後 5 年間使用したいと考えると、64GB では足りない感じがします。

現在、iPhoto のライブラリだけでも 60GB 以上使っています。iPhoto・iTunes は、外部ストレージに保存用のライブラリを置いて都度切り替える運用にすれば、本体側の占有量を減らすことができそうです。しかしながら、それを考慮に入れても 64GB ではやはり心許なく、若干余裕を持たせて 128GB は欲しいところです。

候補としては、

  • MacBook Air 11 インチ / 128GB - 102,800 円
  • MacBook Air 13 インチ / 128GB - 110,800 円
  • MacBook Pro 13 インチ / 2.3GHz - 108,800 円

になります (価格はオンラインアップルストアより [2011/08 現在] )。オプションに関しては、US キーボードが必須になります。

ニュージーランドで購入すると、消費税の違いなどもあって、この価格に 2 〜 3 万円ほど上乗せした価格になります。当方はニュージーランド在住なので、日本のアップルストア店舗で免税してもらうことも可能です。するとさらに価格差が広がります。

MacBook Air と Pro では、

拡張性
Pro の方が上。メモリ・内蔵ストレージは自力で換装可能。DVD ドライブをストレージに換装してしまうことも可能。
機動性
言わずもな、Air の方が上。でも Pro 13 インチでも初代 MacBook よりも軽くて薄い。
入出力ポート
実質的にはほぼ同等 (11 インチは SD カードスロットがないのが劣る)。Air には Firewire / Ether がないけど、あまり困らない。
キーボード
ほぼ互角。店頭デモで触れてみた感じでは、なんとなく Air の方が打ちやすかった感じがしますが、微妙な差。
画面解像度
スクリーンの解像度は Air の方が上。特に Air 13 インチは 1440 x 900 と Pro 15 インチと同じ解像度を誇ります。

初代 MacBook からは 8 〜 9 世代の違いがあり、MacBook Air にしても MacBook Pro にしてもパフォーマンス的には大幅な向上が見込めます。特に MacBook Air は SSD 採用でかなり体感速度が速そうです。

MacBook Pro に決める

ここまで調べていて、ふと「整備済製品」というリンクが目につきました。もしかして……と思い、ニュージーランドの整備済製品を見てみると……

ありました、MacBook Pro 13 / Intel Core i5 2.3GHz。およそ 11 万円。

これでも予算オーバーなんですが、日本で購入する値段とほぼ一緒になります (消費税を抜けばむしろ安い) 。キーボードも確実に US キーボードですし、(日本から) 持ち運ぶリスクもありません。

……と嫁さんを説得して、購入することに!

や〜、Mac 歴 15 年を越えますが、オンラインの Apple Store でハードウェアを購入するのは、初めてです。

TNT エクスプレスという運輸業者で配送されましたが、配送トラッキングがドキドキものですね。

[イメージ] MacBook Pro の配送状況

  • あ〜、シドニーを出た@20:38 In Sydney, Shipment In Transit
  • もうオークランドで税関も通ってる@02:01 In Auckland, Shipment Released Following Customs Inspection.
  • あ〜もう、オークランド事業所何やってんの05:00 〜 12:00 In Auckland
  • おっ、事業所を出たって!@12:46 In Auckland, Out For Delivery

という訳で手元に届くわけですが、開けてびっくり。

MacBook Pro 届く

注文した内容では、メモリ 4GB / 内蔵ストレージ 320GB となっていて、届いた箱にもそのように表記されていましたが、実際開けてみると……

[イメージ] MacBook Pro / この Mac について

  • メモリ : 8GB
  • 内蔵ストレージ : 500GB (5400rpm)

という構成になっていました。このオプションで新品を購入すると、(日本の Apple Store では) 13 万円はしますから、かなり嬉しい誤算 (特にメモリ 8GB が嬉しい)。

今となって、参考になるか分かりませんが、初代 MacBook との比較を交えながら、使ってみた感想を。

本体の質感がまるで違います。初代 MacBook と比べて 400g ほど軽いんですが、感覚的にはあまり変わらない印象です。実際に持ち比べると「あ、軽い」と分かるんですが。本体の質感からくる印象でしょうか。

キーボードの打鍵感はほぼ同等。「キーストロークは微妙に浅く、新しいせいか若干固い」という印象はありますが、気のせいレベルと言って差し支えないでしょう。使い勝手は同等です。

初代 MacBook からキー配置が一箇所だけ変わっていて [*2] そこだけちょっと慣れていません。憧れていたキーボードバックライトは綺麗でほれぼれします。

[*2] 初代 MacBook では、右コマンドキーの右に「enter」キーが配置されていましたが、MacBook Pro では「option」キーになっています。

トラックパッドは MacBook Pro の方が断然使いやすい。タップによるクリックは、これまでトラックパッドで嫌いな操作のひとつだったんですが、MacBook Pro では全く考え方が変わりました。むしろクリックしたときの音が気になる……。

ほぼ同時に使い始めた Mac OS X Lion というソフトウェアの影響も大きいと思いますが、これまでのトラックパッドに対する印象を変えるぐらいのインパクトがあります。

スクリーンの光沢は MacBook Pro の方が反射しやすく、映り込みが激しくなっています。しかしながら LED バックライトと液晶の品質の影響でしょうか、MacBook Pro の方が、視野角が広く発色も良いので、見やすくなっています。1280 x 800 という解像度は決して広くありませんが、Mac OS X Lion の影響でしょうか、思ったよりも外部ディスプレイなしで作業がこなせる感じがします。

細かいことですが、MacBook Pro は iPhone/iPod のイヤフォンがコントロール部分も含めてきちんと利用できます。初代 MacBook では対応していません (そもそも初代 MacBook が出た 2006 年には iPhone はまだリリースされていないので、仕方ないといえば、仕方ない)。

ハードディスクドライブを換装する

パフォーマンスは良好。潤沢なメモリと高速な CPU でアプリケーションのビルド時間などは確実に短縮されました。

ただ、マシンの立ち上がり時間は手持ちの初代 MacBook の方が圧倒的に速い…… (ざっくり測った感じでは 初代 MacBook の起動時間は MacBook Pro の 50 〜 70% ぐらい)。

システムプロファイルを見ると、初代 MacBook は Seagate 製 7200rpm のハードディスクドライブに換装しています。

なるほど。ハードディスクの性能が効いている模様。XBench でベンチマークも取ってみましたが、ディスク性能では初代 MacBook の方が優っています。

……ということは、この MacBook に使っている HDD を MacBook Pro に適用すれば……お金かけずに高速化できるんじゃ……?

容量は 500GB から 320GB に減ってしまいますが、500GB は内蔵ストレージとしては、むしろ多すぎる (バックアップなどにも困る) という感じだったので、問題ありません。それよりも高速化の恩恵の方が個人的には嬉しい。

……という訳で HDD を Seagate 製 320GB 7200rpm に差し替えました。

2011 年 8 月 10 日現在の構成は以下の通り。

モデル
MacBook Pro 13 インチ (MacBookPro8,1)
CPU
Intel Core i5 2.3GHz
メモリ
8GB 1333MHz DDR3
グラフィック
Intel HD Graphics 3000
ストレージ
320GB 7200rpm (Seagate 製)

いずれ内蔵ストレージは SSD に換装するとしても、現状でとりうる最適な構成にできたんじゃないかと思っています。

スポンサーリンク

4/25