事実上無料になったKeynote、AppleScript対応は大きく後退

OS Xに続き、iWorkも無料になってしまいました。新しいバージョンはツールパレットがなく、ユーザインタフェースも変更されているなど、久しぶりのアップデートで進化したかなと思ったところです。ですが、残念ながら後退したところがありました。

KeynoteやPagesはそこそこAppleScript対応があったので、プレゼンテーションの自動生成に使えていたのです。以下はKeynote Ver.5.3、つまり1つ前のバージョンの用語辞書です。slideというクラスに、bodyやmasterなどがあり、つまりはスライドの中身をスクリプトで構成できるのです。

スクリーンショット 2013-10-26 10.34.12

ところが最新版のKeynote Ver.6の用語辞書はこんなにさっぱりしてしまっています。slideクラスにはプロパティがなく、結果的にこれだと、自動的なプレゼンくらいしか用途はないというところでしょうか。

スクリーンショット 2013-10-26 10.34.54

幸いというか、iWork 09フォルダにあった古いKeynoteはそのまま残っていたので消さずに使い続ける事になりそうです。

Mavericksでは通知センターをスクリプトから使えるようになった

Mountain Lionで登場した通知センターは賛否ありますが、まあ、慣れてくると別に気にならないというか、逆にシステム側で便利につかえるようにどんどんなってきているので、今となってはなくなると不便な人も多いかもしれません。挙動は以前よりシステム環境設定の「通知」で変更はできますが、10.8では、コマンドラインから通知を出せなかったということがあります。しかしながら、それができるようになりました。スクリプトから通知ができます。

そのためのベースの機能は、AutomatorとApple Scriptでの通知のサポートです。それぞれ、次のようなアクションおよびコマンドが追加されています。display notificationコマンドはStandard Additionsにあるので、常に使えるものです。ご覧のように大量にパラメータがある…と思ったら、次のsayコマンドでした。パラメータは4つですね。

スクリーンショット 2013-10-23 13.44.59

スクリーンショット 2013-10-23 13.46.29

このdisplay notificationコマンドをosascriptコマンドで実行してやれば、コマンドラインから通知が可能です。たとえば、こんな感じです。osascriptコマンドの標準入力にAppleScriptのプログラムを送り込めばOKです。

echo ‘display notification “I am a command-line.”‘|osascript

上記のコマンドで、以下のような通知が出てきます。UTF-8での日本語もOKです。

4

パラメータを付けてみます。

echo ‘display notification “コマンドだ!” with title “Terminal” subtitle “ダークサイド”‘|osascript

5

 

通知センターでの表示は、システム環境設定の「通知」で、「AppleScriptエディタ」に対する設定となります。/bin/shとかいった項目が出るのではないということですね。

スクリーンショット 2013-10-23 13.59.29

ともかく、コマンドから通知を出せるようにできるようになるのはうれしいですね。

Mavericksでエネルギー消費をアクティビティモニタで監視

アクティビティモニタが少しすっきりした画面になっていますが、「エネルギー」というタブが追加されていて、エネルギー消費のインパクトになるものが分かります。簡単に言えば「電池を食うアプリケーション」を燻り出すツールでしょうか。

スクリーンショット 2013-10-23 12.50.36

ここでApp Napの列を見ると、App Napの状態に入っているかどうかを確認できるようです。刻一刻と変化するので、「対応しているか」ということではなく、App Napの状態かどうかを示していることになります。

App NapはAppleのサイトよると、バックグランドにあるアプリケーションのCPU使用をぐっと減らしてバッテリーの消費を伸ばすという仕組みです。パフォーマンスも少しは向上するかもしれませねんが、背後で作業をする場合には普通に作業するので、パフォーマンスの向上はわずかになるでしょう。

Appleのサイトでも唱われているSafariの効率化で、背後に回ったタブもApp Napの対象になるとなっています。つまり、Safariのタブは1つ1つ別のプロセスになっているので、事実上、タブ1つが1つのアプリケーションのようなものと思ってもいいでしょう。それらが、別々のプロセスで見えていて、表示していないページの一部はApp Napが機能します。ただし、全部ではないようです。

スクリーンショット 2013-10-23 12.56.42

 

一方、ChromeもGoogle Chrome Rendererというプロセスがアプリケーションの子プロセスになっているので、ページごとに別々のプロセスが描画を担っているようです。しかし、ChromeのRendererは単独でApp Napには入らず、アプリケーション自体だけが背後に回ったときにApp Napに入るのみです。アプリケーションがApp Napに入り、子プロセスがそうでない場合、子プロセスも省電力動作をするかどうかは判断できないところですが、実行機会はすべてのプロセスが持つのですから、親がApp Napだと子供もApp Napということではないと思います。

となると、やはりSafariの方がChromeよりもエネルギー効率は高いのかもしれませんが、よく考えると、ブラウザの種類に限らず、バッテリーを長持ちさせたいのならブラザの余分なウインドウを閉じる方が効果は高いということでしょう。また、使わないアプリケーションも落とすというのが基本ですね。

アクティビティモニタを見ていると、末尾にグレーのアプリケーションがあります。起動しているものもありますが、起動していないものもあります。App Storeアプリケーションがそうなのですが、これはもしかすると、アプリケーション自体が監視のためのデーモンを動かしていることの印なのかもしれません。また、この一覧には原則としてアプリケーションとその子プロセスが見えています。つまり、デーモンはApp Napとは関係ないという事でしょうか(だからAppか!)。

ヘルプを見ると、「高性能 GPU 必要」という項目もアプリケーションごとに出るようで、複数のグラフィックカードがある場合に、高パフォーマンスGPUを使用する必要があるかどうかを示すようですが、私のMacBook Air 2012ではこの列は出せないようです。「表示」メニューの「表示項目」では選択できません。

開発関連の情報を見る限りは、「App Napを有効にする」みたいなフラグがアプリケーションにあるわけではなく、Cocoa Frameworkを使ったアプリケーションには適用されるようなシステム機能と言えます。バックグランドでなるべく何もしないとか、タイマー処理の間隔を広めに取るなどの対策をすることで、よりApp Napに入りやすくなるということのようです。ただ、手元にある比較的古いアプリほど、グレーになっていたりするので、単にCocoaということではなく、一定以上あたしいフレームワークでビルドしないと、App Nap適用されないのではないでしょうか。

[Mavericks] AppleTVデスクトップ拡張でサウンド切り替えに困る

(追加情報)もっと簡単な方法がありました。末尾に追加しました。

OS X Mavericksで便利になった点にAppleTVにAir Playで画面を送る事ができることです。ミラーリングなら前からできましたが、デスクトップを広げる拡張先として、Air PlayのApple TVを使えることです。拡張ディスプレイを、いわばワイアレス接続できるわけです。外部のディスプレイを追加するためにUSBのアダプタを買ったのですが、このアダプタは使わなくなってしまいました。ちなみに、アダプタのUSBドライバはMavericksでは互換性がないとしてメッセージが出てはじかれているので、使えなくなってしまいました。

いずれにしても、Apple TVをAir Play対応にして、Macとペアリングすると、Apple TVをディスプレイとして利用できます(詳しい方法はきっと多くのサイトで紹介されているでしょうから省略)。メニューバーでAppleTVを選択すれば、少し待つと切り替わります。トラフィックの少ないワイアレスネットワークならそこそこ使えますが、せっかくなので、AppleTVもEthernetでつないでしまいました。表示に関する遅れはほとんど感じませんが、時々、微妙な表示途中の状態がチラっと見えることもあります。

pic2

システム環境設定の「ディスプレイ」を見ると、以下のような感じです。このAppleTVは、3rd Generationつまり現行機種です。外見がまったくそっくりな2nd GenerationのApple TVだと、最大解像度が720pまでだったので、Macのディスプレイとして使うためにAppleTVは買い直しました。とは言え、2nd Gen.の方はリビングで使っています。

pic3

こうしてUSBアダプタを使わずに、ネットワーク接続で「画面が広くなる」ということを標準機能だけで実現できるようになったわけです。ただ、ログインの度にApple TVへの接続を手作業でやらないといけないですが、まあ、それくらいはいいとしましょう。起動の度、つまり、毎朝、Apple TVを選択する事になります。

しかしながら、Air Playの送信先を切り替えるため、画面だけでなく、サウンドの出力先も同じApple TVに切り替わってしまいます。私が持っているいちばん音がいいのは、USB接続している初代のSoundSticksなんですが、音を鳴らしながらApple TVに接続すると、サウンドの出力先はSoundSticksから勝手にApple TVに切り替わります。「勝手」じゃなくて「仕様だ」といわれそうな気もますが不便です。なお、Apple TVからさらにAir Playで別のスピーカーを選択していても、Apple TVのサウンド出力、つまりHDMIケーブルで出力された先のディスプレイ等で音が出てきます。Air Playのカスケードはできないということですね。

そこで、Apple TVに切り替えた後、SoundSticksに切り替えたいわけですが、サウンドの出力先の切り替えはシステム環境設定を使う必要があります。メニューアイコンでの切り替えができません。それで、ちょっと不便だなーと思って、メニューアイコンで出力先を切り替えられないか、フリーソフトをあさって見ました。いっぱいあるのですが、比較的シンプルそうなのはこれらです。

SoundSourceは、Mavericksでは起動しませんでした。また、開発元のサイトでもリストアップされていないので、開発はやめているのかもしれません。Audio Switcherは2010年とやや古いのですが、Marvericksでも起動でき使えています。ただし、署名されていないアプリケーションなので、システム環境設定の「セキュリティ」の設定によっては起動しないかもしれません。いずれもアプリケーションなので、利用するには単にダブルクリックだけです。ログイン時に常に使いたい場合には、システム環境設定の「ユーザとグループ」にあるログイン項目への登録を自分で行います。

起動確認できたのは最初の2つで、左側がSound Switcher、右側はVTAudioSwitchです。Sound Switcherは、入力の切り替えができる点と、Preferencesから起動時に選択する項目を指定できることです。出力先の変更はどちらもできますね。右側のVTAudioSwitchはショートカットが割り当てられていますが、アプリケーションのショートカットと当たるのであまり当てになりません。

pic1

ということで、サウンド切り替えもメニューバーからできるようになり、手作業が必要だとは言え、システム環境設定を呼び出すより手軽です。

純正機能でサウンドの出力先を変更できる

標準の機能でできないと思っていたら、メニューバーにあるサウンドのアイコンをoptionクリックしてできることを教えていただきました(ありがとうございます>Miyuki Imaizumi)。左が通常の状態ですが、optionクリックすると、入出力の選択ができますね。悩む必要がなかった(笑)。

2

[IM]PHP Ver.5.3 on OS Xで、APCを稼働させる方法

ファイルのアップロードをするときのプログレスバーを出す方法が「A Simple PHP Upload Progress Bar」というページに紹介されています。シンプルなのでやりやすそうと思われるのか、このサイトのスクリプトを単にコピーしただけのサイトなんかもあります(せめて出展くらい出すべきでしょう)。

当初、動かし方を紹介したサイトはないかと思って探したのが「Mac OS XのPHP 5.3にAPC(Alternative PHP Cache)をインストールする方法」というサイトでした。OS X Lion時代のものなのかこの通りでは動かなかったので、追加で必要な作業をまとめてみました。

プログレスバーを出す仕組みはちょっとややこしいのですが、ポイントの1つはPHPのAPC(Alternative PHP Cache)という機能を利用することです。残念ながら、PHP 5.3では生の状態ではこの機能は使えません。この機能を、OS X Moutain Lion + OS X Server Ver.2.2 + FileMaker Server 12という状況で使えるようにする方法を解説します。PHPは、Ver.5.3.13です。FileMaker Serverでない場合php.iniファイルの扱いが違ってくると思われます。

  1. Webサーバ稼働マシンに、Xcodeをインストールしてください。Xcode 4.6.2で以下の動作は確認しています。
  2. MacPortsをインストールします(インストール済みならもちろん何もしなくてもOKです)。まず、以下のコマンドでダウンロードします。以下のURLはアップデートにより変更されるかもしれません。
    curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.1.3-10.8-MountainLion.pkg
  3. 以下のコマンドでインストーラを使ってMacPortsをインストールします。
    sudo installer -target / -pkg MacPorts-2.1.3-10.8-MountainLion.pkg
  4. 以下のコマンドで、autoconfiをインストールします。
    sudo port install autoconf
  5. 以下のコマンドで、pcreをインストールします。
    sudo port install pcre
  6. 以下のコマンドで、ヘッダファイルの1つをコンパイラが認識するディレクトリにコピーします(参考)。
    sudo cp /opt/local/include/pcre.h /usr/include
  7. APCのソースをダウンロードします。URLはアップデートによって変更があるかもしれません。
    curl -O http://pecl.php.net/get/APC-3.1.13.tgz
  8. アーカイブを展開します。
    tar zfvx APC-3.1.13.tgz
  9. カレントディレクトリに移動します。
    cd APC-3.1.13
  10. 以下のコマンドを入れます。
    phpize
  11. 次のように表示されます。warningがありますが、問題ない模様です。
    Configuring for:
    PHP Api Version: 20090626
    Zend Module Api No: 20090626
    Zend Extension Api No: 220090626
    configure.in:3: warning: prefer named diversions
    configure.in:3: warning: prefer named diversions
  12. おなじみの以下のコマンドでコンパイルします。
    make
    sudo make install
  13. 最後のコマンドで以下のようなメッセージが表示されます。1行目のパスをphp.iniファイルに記述するので、コピーしておくといいでしょう。
    Installing shared extensions: /usr/lib/php/extensions/no-debug-non-zts-20090626/
    Installing header files: /usr/include/php/
  14. php.iniファイルを変更します。以下のパスは、Mountain Lion + FMS12の場合です。使用する状況に合わせて正しいphp.iniファイルを編集します。もし、ない場合は、/etc/php.iniあたりに作成します。使用しているphp.iniファイルのパスを調べるには、phpinfo関数の出力を利用しましょう。
    sudo nano ‘/Library/FileMaker Server/Web Publishing/publishing-engine/php/mountain lion/lib/php.ini’
  15. php.iniファイルに以下の3行を追加します。これらの設定をいままで全く行っていないのなら、そのまま追加でかまいません。すでに設定がないかどうかは検索して確認しましょう。
    extension_dir=/usr/lib/php/extensions/no-debug-non-zts-20090626/
    extension=apc.so
    apc.rfc1867=on
  16. 以下のコマンドを入力して、Apacheに設定変更を適用させます。
    sudo apachectl graceful
  17. phpinfo関数の出力を見て、APCのカテゴリがあることと、apc.rfc1867の値が「On」になっていることを確認します。

ポイントとしては、APCのコンパイルのために、autoconf、pcreが必要である点です。また、APCの設定は既定値ではrfc1867はOffですので、設定ファイルで記述してオンにしておく必要があります。

なぜ、この記事のカテゴリにINTER-Mediatorがあるかというと、この仕組みをINTER-Mediatorに組み込んだからです。

スクリーンショット 2013-06-16 16.44.40

ディスプレイを追加

そういうわけで、BenQの24インチGL2450、USB to HDMI Adapterが到着して、こんな状態になりました。写真がヘタですみません。右が、AppleのLED Cinema Display 27″、左がBenQの24″、右端はMacBook Air、左端はiPad 3rdです。AppleのDisplayの下にはNexus 7とCloud Communicatorなんかもあります。アダプタのドライバは古いものしか製品にはなかったのですが、こちらから最新版がダウンロードできました。

IMG_0018

それで、大画面2台の見え方がけっこう違います。当然、Appleの方がきれいなんですが、まあ、そいういう用途ではなく、ドキュメントなどを開いておくためのものなんで、あまり気にはしていません。ただ、BenQの方はまぶしい…。輝度0にしても、まだまぶしいです。

最初、「システム情報」のシステムレポートで見てみると、2項目は見えたのだけど解像度がおかしいと思ったのですが、ここに見えるのは、MacBook Airのディスプレイチップから接続されている、内蔵の液晶パネルと、Cinema Displayだけのものでした。小さい方の解像度は内蔵ディスプレイです。

ScreenSnapz001

アダプタ+BenQは、システムレポートとしては、USBのカテゴリにしか見えません。これは、「システム情報」がUSBアダプタのディスプレイなどには対応していないということですかね。

スクリーンショット 2013-02-19 11.44.57

 

大画面が2枚欲しい

今の私のメインマシンは、MacBook Air 11″(2012) + Apple LED Cinema Displayです。ディスプレイは前の機材の頃から使っているのです。この数年、だいぶんと視力が悪くなってきて、画面の文字を大きめにしています。XcodeはPresentationの設定がちょうどいい。ということで、大画面でも文字を小さくすると、実質的に「狭い」わけで、ディスプレイの追加を考えました。

AppleのThunderbolt Displayだと2台接続ができるらしいけど、Apple LED Cinema Displayは2台のうちの1台になれないらしい。1台8万円超のディスプレイを2台買うと、いいお値段であり本体より高い。これがいちばん理想的なんだろうけど、ちょっとぜいたくかな。

で、MacBook Airは、Apple製品以外に外付けディスプレイを複数使う方法がないかと思ったら、USBアダプタでどうも可能なようです。まず、これが1つ選択肢。メモリをたっぷり搭載しているので、そんなに重くはならないと思われますが、メーカ保証はないというところ。

別の選択肢は、iPadでAir Displayを使って、iPadからディスプレイにつなぐこと。これを2台目の外付けにするということです。ただ、これはいいアイデアだと一瞬思ったのですが、iPadにディスプレイアダプタをつけたら充電ができない。となると、毎晩、作業が終われば充電のためにつなぎ変えないといけないってことになりますね。さらに、Air Display + Apple TVという回りくどい、けど、ノンケーブルみたいなことを一瞬考えましたがどうだろう。なお、この方法だと、解像度が1080pになるけど、ドット数的にどこまでいけるかですね。直接接続の場合はいいとして、Apple TV経由だと解像度が中途半端になりますもんね。

外付けディスプレイは、Dellの24インチが2万円を切っているけど、21〜24インチだと、量販店でも2万円前後とそんなに高いものではないです。つまり、Apple製品でなければとりわけ安い。ということで、please give me your advices.

OME never die! と言いたいけれど…

<a href=”http://msyk.net/ome”>OME</a>を一生懸命やっていたのは、1999〜2004年くらいかな。ちょうど、<a href=”http://msyk.net/cserver/mdo.html”>MDOnline</a>の頃に重なります。その後も、だましだましOMEを使ってきました。相当だましたので、OS X Lionでも使えてはいますが…。ちょっとかなりきつくなってきました。それでも、never dieと言いたいのですが、かなり苦しいかも(苦笑)。

まず、「再開」の機能により、ウインドウの残り方が今ひとつよくないのか、落ちることしょっちゅうです。まあ、データを書き込んでいないし、所詮テキストファイルなので悪影響はまったくありませんが、あまりいい感じではなく、特に、command+Wでアプリが落ちるのはちょっと面倒です。コンパイルしなおそうとしているのですが、これがなかなかやっかいで、まだうまく行っていません。そこはだましだましなところですね。

そして、ついにというか、やっと気づいたというか、11月11日を境にiCloudのメールの受信ができなくなっていました。できないのをやっと気づいたというのは、iPadでもメールを読んでいるからです。fetchmailコマンドでme.comのメールってなんでだめなんだろうか? 認証のエラーが発生します。

仕方ないので、Mail.appでiCloudメールを受けるようにしました。

そこでふと考えたのは、Mail.appをfetchmail代わりに使うことです。メールソースをAppleScriptで書き出して、メールの整理はOME側でやればいいじゃん!ってことで、近々に取り組むつもりです。

電子メールというきわめてレガシーな仕組みが今だ、同じように残ると同時に混沌さは年々増す感じもします。昔から、電話をいちいち録音していないのと同じように、メールだって、しばらくすると「捨て」でいいとも思ったりもしますが、なぜ、テキストファイルで残したいのかというモチベーションを思い出し、もうひと頑張りしようと思います。つまり、OMEはメールの整理・ストレージに移行するということです。

さて、どうなることやら。

Appleテクノロジーの5年周期

今日の未明に、次期Mac OS X Lionが発表されました。巷ではAirの方に注目が集まっているようですが、Lionの方がこの世界で仕事をしている者にとってはマジなネタです。

2011年、Mac OS X Lionがリリースされるわけですが、大きなポイントは、iOSのエクスペリエンスの統合です。これは、新たなOSが出てくる事に匹敵する程の変化と思われます。しかも、来年夏のアップデートを今からアナウンスするというのは、開発者のアダプテーションが必要だからと考えられます。ということは、単なる見栄えの違い以外にもさまざまな根本的な変化があるのではないかと思われます。

そのように予想するのは、Appleのテクノロジー的な大きな変化は、5年周期のサイクルがあると考えられるからです。Mac OS Xのリリースは、2001年です。Macを取り巻くここからの流れを見ると、アップデートが続き、それぞれ特筆すべき点は多々ありますが、次のジャンプは2006年からのIntel CPU搭載です。1年以内にすべてのラインナップがPowerPCからIntelに切り替わりました。そこまでちょうど5年、そして次の5年目が2011年です。2011年に発生する大イベントは「Mac OS X Lion」であることはもはや疑いのないこと…と考えられませんでしょうか?

一方、iPod〜iOSへの流れを見てみます。デバイスうんぬんについては5年周期はあまり見えないですが、iTunes Music Storeが2003年、App Storeが2008年です。オンラインとの連携がビジネスのキーであるAppleの携帯デバイスなので、ここの5年周期は意味深な気もします。iPodは2001年ですが、2006年にはApple TVが出ています。ここはちょっと判別しにくいのですが、初期のApple TVは「OS X」なるOSが搭載されていました。iPodについては諸説有りAppleの発表がないのでOSは判断しにくいのですが、携帯デバイスのインターナルな世界では、2001年からの初期のOS、そして2006年からのMac OS X系列のOSへと5年周期で変化しています。

90年代にもこうした周期があるのかどうかですが、1996年末に事実上NEXTSTEPを次期OSとして決定していて、そこから5年の2001年に正式リリースになっています。68kからPowerPCへの移行は1993年、そして1998年にはiMacの登場ということもあります。

いろいろなエポックメイキングなAppleのテクノロジーの変化を見る限りは、5年周期は至る所で見られます。従って、Mac OS X Lionは大きな変化をもたらすマイルストーンと考えられます。現状、発表された内容は、エクスペリエンスのiOS化であり、Mac版のApp Storeの開始ということもありますが、きっと全貌はこれだけではないでしょう。こんな次期に発表するだけに、今後デベロッパーが対処しないといけないような何かがあって、機密ベースで少しずつ公開されるものと思われます。そして、2011のWWDCで全貌を明らかにし、夏の発売でいきなりブレーク!というのがAppleのシナリオのような気がします。

ということで、想像ですが、iOSとMac OS Xの違いがかなりなくなるのではないかと考えられます。もともと主要なフレームワークはかなり近いのですが、それを可能な限り近づけるということです。Mac OS Xは高機能ながら複雑で巨大なOSでもあります。そのための使い勝手の悪さや管理の大変さもあるわけです。現在のCocoa Touchのフレームワークで作ったアプリケーションがMacでも動くように拡張をしつつ、Macの側ではファイルというものを意識しないでもいいくらいにまで、iOS的な操作体系になるのではないかと予想されます。