Swift: アウトレットを含めたプロパティで Optional “?” を積極的に使う

Swiftの特徴として、クラス名のみで示す型では、nil値を許さないことです。一方、?や!でnil値を許す変数の定義などができます。それぞれ、OptionalとUnwrapped Optionalと呼ばれています。

var myLabel1: UILabel = UILabel(frame: ...) // nilを許さないので何か入力しないといけない
var myLabel2: UILabel?
var myLabel3: UILabel!

ここで、アウトレットについて考えてみます。アウトレットは、Interface Builderで線を引くなどして参照先のオブジェクトが指定されていれば、ストーリーボードのロード時などに自動的に参照先が設定されます。しかしながら、オブジェクト生成直後では値が確定しないので、OptionalかUnwrapped Optionalのどちらかにしないといけません。

ここで、Appleのドキュメントでは、Unwrapped Optionalにすべきと書かれており、Xcodeでアシスタントエディタで、Interface Builderのオブジェクトからctrl+ドラッグでコード上にドロップしたときに作られるプロパティは、自動的にUnwrapped Optionalになります。もし、アウトレットをOptionalで定義すると、Optional Binding、つまり、

if let aLabel = myLabel2 {
    x = aLabel.text
}

のように、ifで囲う必要があります。そうなると、Objective-Cで作られたプログラムを移植するようなときに、流れが変わってしまい、作業効率が悪くなるということもあると思います。こうした点を総合して、AppleはUnwrap Optionalをアウトレットの推奨形態にしていると思われます。

しかしながら、Optionalか、Unwrap Optionalかは、仕組みの上ではどちらでも構わないのではないでしょうか。つまり、nil値を許せばいいのです。また、nil値になる状態での不要な処理を避けるという意味では、明示的にOptional Bindingを記述することになるので、不都合はなく、むしろ好都合かもしれません。余分に記述するのが目障りということもあるかもしれませんが、予防的な措置であれば、むしろ歓迎すべきです。これらの点は、個人的な嗜好ではありますが、むしろ評価すべきです。そもそも、Swfitは安全な言語ということが謳い文句だったはずです。であれば、Optionalをもっと積極的に使うべきではないでしょうか。

Optionalにしたら、面倒と思うかもしれません。たとえば、以下はいずれも、エラーになります。tagというプロパティはないとエラーでは記述されています。

myLabel2.tag = 3
let m = myLabel2.tag

しかしながら、若干の誤差を許していただければ、基本的には非常に緩いルールでこれらのエラーは逃れられます。それは、Optionalなプロパティが左辺にあるときには、単に、変数名に?をつけるだけでいいのです。右辺で利用するときには原則としてバインディングを行います。

myLabel2?.text = "aaa";
if let label = myLabel2 {
     let m = label.text
}

これだけのことでいいのです。これだけのことで、より安全になるのであれば、手間をかける価値はあるのではないでしょうか? アウトレットを含めたプロパティは、Optionalで定義する〜このルールでも構わないと考えます。

iOS 8のデバイスの回転可能な方向の設定

iOSのネイティブアプリケーションを開発するとき、Xcodeのビルドするアプリケーションの設定のDeployment InfoにあるDevice Orientationにあるチェックボックスの設定が重要です。iOS 6以降、この設定がそのままInfo.plistファイルに設定され、アプリケーションはその設定に応じた動きをします。このDevice Orientationは、その方向にデバイスを向けたときに、画面が回転して、画面の上端が実際に上に見えるようになるということを示しています。通常、Upside Downつまり、ホームボタンが上に来る縦長の状態にしたときには、回転は行われないということになっています。つまり、Upside Downの方向にしたときには、写真は90度あるいは180度傾いて見える状態のままになるということです。

shot9897

前の図のDevice Orientationの設定は、iOS 7までは、iPhoneとiPadで別々でした。それぞれで回転可能な方向を決めることができました。iOS 8つまりXcode 6からは、その上のMain InterfaceがiPhoneとiPadで共通になっているので、Device Orientationも共通かと思ったら、Xcode 6.1.1で作ったプロジェクトでは、iPhoneとiPadのDevice Orientationの設定が、別々に定義された状態になっています。以下は、Infoをクリックして見たところで、Supported interface orientationが、iPhone向けの設定であり、General(前の図)で見えている設定です。それに加えて、Supported interface orientation (iPad)もあり、4つの方向がチェックされています。このiPadの設定はGeneralには見えていません。したがって、General側で設定をどう変更しようと、iPadの場合はこのInfoで見えている設定に従うために、すべての方向に回転ができるようになります。

shot9898

ちなみに、iPhoneとiPadの両方の設定が必要なら、Generalのパネルに双方の設定ができるようにすべきです。もしかして、iPadのDevice Orientationの設定は間違えて紛れ込んでいるのでしょうか? ここで、iPad側の設定を削除したいなら、Supported interface orientation (iPad)の項目を選択し、項目名の右に見える、丸にマイナスの部分をクリックします。これで削除できます。

shot9899

ここで、まず、Info.plistに項目が存在するかどうかによって、どのように稼働するのかを見てみます。これを見る限り、既定の動作をさせるには、要するに、これらのInfo.plist項目はそもそもない方が素直な設定の気がします。既定の動作をさせないときに、項目を定義するというのが理にかなっているような気もします。

Supported interface orientation Supported interface orientation (iPad) 回転の動作動作
設定なし 設定なし iPhoneはUpside Down以外が可能、iPadはすべての方向へ可能、つまりデバイス既定の動作
設定あり、要素なし 設定あり、要素なし
設定あり、要素あり 設定なし iPhoneもiPadも、iPhone側の設定に従う
設定あり、要素あり 設定あり、要素あり iPhoneはiPhoneの設定に、iPadはiPadの設定に従う

Supported interface orientationにチェックが入れば、その方向で回転するというのが概略の説明ですが、正しくは1つの場合だけ回転しません。回転しない例が、iPhoneの場合のUpside Downです。つまり、このチェックを入れるだけでは、その方向に回転しないのです。つまり、デバイスの規定値の方が優先順位が高いとみていいでしょう。

では、iPhoneでもUpside Downを可能にするにはどうすればいいか? UIViewControllerにあるsupportedInterfaceOrientationsメソッドにヒントがあり、このメソッドをオーバーライドするのがポイントです。このメソッドは、UIViewControllerであらかじめ定義されており、ビットマスク値を返します。ホームボタンの位置が上下左右のそれぞれに対応する4ビット分のマスク値を返します。UIViewControllerに実装されているメソッドだと、iPadだと4つのビットがすべて1、iPhoneだとUpside Downを除く3つのビットが1になっています。実際に回転していい方向は、Info.plistの設定と、supportedInterfaceOrientationsメソッドの返り値をビットANDをして、残ったビットが回転をしてもいい方向になります。なので、Info.plistの設定で全部にチェックされていても、iPadでは全方向に回転は可能ですが、iPhoneでは、Upside Downはマスク設定で0になっていて、キャンセルされてしまうのです。

それでは、自分で定義しているUIViewControllerの継承クラスで、supportedInterfaceOrientationsメソッドを実装して、全部のビットが1になっている値を返せばいいではないかと考えるところです。しかしながら、この回転の判断は、いちばんルートにあるビューコントローラで判定されます。Single View Applicationで作ったようなプロジェクトだと、いきなり自分で定義しているビューコントローラのクラスがルートにあるので、そこでメソッドを組み込めばいいでしょう。以下のコードに追加されているメソッドを加えます。しかしながら、Master-Detail Applicationのテンプレートで作ったプロジェクトでは、例えば、MasterViewControllerやDetailViewControllerクラスにsupportedInterfaceOrientationsメソッドを作ってもうまくいきません。これらのクラスのオブジェクトはルートのビューコントローラではないからです。Master-Detail Applicationで作ったプロジェクトのストーリーボードファイルを見れば、ルートはUISplitViewControllerクラスのオブジェクトです。そこで、以下のような、UISplitViewControllerクラスを継承したMyRootViewControllerクラスを定義します。そして、メソッドにはsupportedInterfaceOrientationsだけを定義すれば良いでしょう。returnの後のenum型の値が、すべての方向のビット値が1に設定されたものです。返り値がIntなので、rawValueプロパティを使ったり、Int型に変換するなど、Swiftではちょっとややこしいですね。

shot9900

そして、ストーリーボードのUISplitViewControllerクラスのオブジェクトを選択します。右側のユーティリティエリア上部では左から3つ目のアイコンを選択して、アイデンティティインスペクタを表示して、Classのところで、前の図にあるMyRootViewControllerを選択します。

shot9901

こうしておけば、Master-Detail Applicationで作ったプロジェクトでも、iPhoneでUpside Downの方向でも回転ができるようになります。もちろん、プロジェクトのDeployment Infoの設定にあるDevice Orientationのチェックボックスは4つともオンにしておく必要があります。

言語ごとのiOSシミュレータを用意する

Xcodeでシミュレータが見えなくなるトラブルが発生しましたが、復旧過程で「機種ごとだけでなく、言語ごとにデバイスを用意する」ということができることに気づきました。その方法を紹介しましょう。

いろんなバージョンのXcodeを行き来しつつ、ユーザも切り替えながら使っていることもあるせいなのか、ある日、XcodeでiOS向けのプロジェクトで、iOSシミュレータがまったく選択できなくなりました。現在は、Ver.6.1.1が公開されている中で最新ですね。

shot9502

ここで見えるシミュレータは、WindowsメニューのDevicesで確認できます。やっぱりみんな消えています。なぜかはわかりません。

shot9503

シミュレータを追加するには、左下の+部分をクリックします。すると、次のようにシートが表示されて、名前や機種、iOSのバージョンなどを指定してシミュレータを追加できます。全部消えてしまっても、もちろん、こうして追加すればOKです。

shot9504

ここで、ふと「同一の機種は追加できるのか」と思ってやってみたらできました。そこで、さらに思いつきました。たとえば、iPhone 4sを2つ登録して、それぞれで、シミュレータの言語を「日本語」と「英語」にしておけば、言語の切り替えがポップアップからできるようなものではないだろうかということです。

以下のように、iPhone 4s-EnとiPhone 4s-Jaの2つのシミュレータを追加登録します。どちらもDevice TypeはiPhone 4sを選択しています。

shot9509

Xcodeでは、このように、指定した名前(Simulator Name)のポップアップメニュー項目が出てきます。

shot9506

それぞれのシミュレータでアプリケーションを起動するなどして起動し、「設定」アプリケーションで言語を日本語と英語に設定しました。そうすれば、以下のように、もちろん、それぞれの言語でシミュレータが即座に立ち上がります。シミュレータ側でのHardwareメニューのDeviceでは、名前でなくデバイスタイプが出るようで、ちょっと不便ですが、まあ、Xcode側で選択できさえすればいいので、これで、Xcode側から言語を指定したシミュレータの呼び出しができるということです。

shot9508 shot9507

ちなみに、XocdeからプロジェクトのRun等をしないでシミュレータを起動するには、Xcodeで、XcodeメニューからOpen Developer ToolのiOS Simulatorを選択すれば良いでしょう。

shot9505

以下の書籍ではこの話題は入れられませんでした。こちらの書籍もよろしくお願いします。

ios_programming_cover1

Yosemiteのmanは2本指スライドでスクロールするぞ!!

Yosemiteを入れた方、ターミナルを起動して、たとえば、「man diskutil」と入れてください。長いmanをスクロールするのは、えーっとcontrlなんだっけ〜と思う前にトラックパッドで2本指でスライドさせてください。なんと、manがスクロールします。Linuxマシンにつないでもできますよ。

ということで、manというより、Terminal.appの動作がトラックパッドに最適化されたってことですが、わかりやすいタイトルをつけてみました。

Appleの新言語Swiftは普及するのか?

もちろん、月日を経ないと結論は出ませんが、今時点では今後普及すると考えます。その理由を考えてみました。

まず、「開発言語の大きな変更」というのは、Mac OSからMac OS Xへの移行時にありました。その成り行きは非常に重要です。Mac OSは、CあるいはC++が主要言語だったと言えますが、Mac OS XはOPENSTEPからの名残でObjective-Cが開発言語になることが、当初NeXTとAppleが合流したときの事実でした。しかし、既存のMac OS開発者からは支持は得られず、AppleはMac OS Xの正式リリースが近づく頃にJavaに対応しました。1999〜2000年頃は、Javaが登場して4年程度の頃で、エンタープライズ分野で使われ始めるなど、ある意味では注目が集まっていた言語でもありました。また、その頃は、Flash vs Javaという構図でもまだ微妙に拮抗していた時期です。Appleは「Javaだとみんな納得してくれるだろうし、他のプラットフォームの開発者にもアピールできるだろう」と考えたのかもしれません。しかし、現実はそうではありませんでした。技術的な問題と、心理的な問題があったのです。

おそらく、いちばんの見込み違いは、これまでNeXTの世界でObjective-Cで開発して来た人たちよりも、Javaだから参入しようと思った人たちの方が少なかったからでしょう。いまでこそ当たり前のOS Xですが、移行時は「Mac OS Xは失敗してMac OSに戻すだろう」みたいな発言を堂々と公言する人たちも多く居たので惑わされたのでしょう。WWDCに当時参加していた人は、Mac OSへの逆戻りはあり得ないことは理解していたと思います。しかし、プラットフォーム外の人はそうした変な噂にも惑わされて、言語以前にMac OS X自体への注目がされなかったのでした。この点が大きく、AppleもMac OS X発売直後くらいからObjective-Cにフォーカスし、Java対応は順次縮小して現在に至ります。

技術的な側面でも、Javaでは参照渡しという仕組みがないと言えばなく、Objective-Cで培われたAPIに微妙にマッチしていませんでした。そして、メモリモデルが異なる2つの言語では、思わぬ落とし穴がどこかにあって、「なぜか動かない」という箇所に当たってしまうこともあり、安心して使えなかったことも事実です。また、Javaは遅いという世間の意識にもマイナス方向の力が働きました。

そして年月が経過しました。魅力的な製品iPhone/iPadで稼働するアプリケーションを作りたいために、それまでAppleに見向きもしなかったたくさんの人が、Objective-Cの学習をしたのです。これは、Mac OSからOS Xへの移行時とはすでに状況が違います。Appleは、OS Xリリース前のJava対応の混乱から、「他の世界のプログラマに魅力がある」ということよりも、「今現在プラットフォームにコミットしている人たちの満足度」がより重要であるということを学習しているのだと思います。

しかし、Objective-Cへの不満はいつもどこかでつぶやかれていました。そこで、まず取り組んだのが、複雑なメモリ管理へのテコ入れであり、ARC対応です。同時に、ブロック対応した点でも、コンピュータの世界の基準に追いつくことをしたということです。そして、今回のSwiftがあります。iPhoneアプリを作りたいことで、Objective-Cを学習するような人なら、Swiftの学習をすることくらいはさほど難しくないと言えます。しかも、文字列を+でつなげられるわけで、JavaScriptなど多くの人たちがObjective-C以外で経験して来た言語に近い訳です。Objective-Cが理解できるプログラマなら、Swiftは理解できるでしょう。しかも、?によってよりシンプルに記述できるとか、プロパティがオブザーバブルといったより良い特徴も目立ちます。

さらに、「すでに有名である言語である必要はない」という意識も、Appleには現在のObjective-Cプログラマの増加から出ているのでしょう。既存の言語、ruby/Python/JavaScript等ではない理由としては、すでにコミュニティがあって色が付いた言語だと、その世界のしきたりに引っ張られるのですが、「新言語」と言い切ってしまえば、Appleは独自にその中身を構築できるのです。これは、もちろん、Appleにとって有利に働きますし、そういうことでないと、Cocoaとの完全な統合はできないと言えます。Javaのときの技術的な問題に対する対処も、Appleの手中に最初からあるということです。

Mac OS X初期の頃と違い、たくさんの開発者がすでにコミットしている上では、新しい言語は十分に受け入れられるだろうと判断したのでしょう。また、iOSのアップデートがきわめて順調である点も追い風になるでしょう。これから開発するアプリケーションは、iOS 8以上対応という決定がなされるのがおそらく普通かと思われます。そうなら、思い切ってSwiftでやるぞという結論になる確率も高いということです。

そういうことで、Swiftは昔のJava for Mac OS Xのようにはならないと思います。OSのバージョンアップのスピードを考えれば、来年のWWDCの頃にはSwift率はけっこう高くなっているのではないでしょうか。半々くらいになるかな?(数字は出したくないのだけど〜笑)また、プログラミングと言えばいまだに「言語の理解」という間違った意識がありますが、実際には「フレームワークの理解」ということの方がよほど大変です。SwiftになってもCocoaの諸概念を理解して利用するという点では、Objective-Cと違いはありません。現在のiOS開発者にとっては、「ちょっと書き方が変わる」くらいの話であり、今までがんばって学習してきたCocoaの知識は十分に活かせるし、むしろそれらが必要なのです。Appleはきちんとレールを敷いた上で、新しい言語を持ち出したのです。

OS X Mavericksとdocdiff 0.5.0

単語単位での2つのファイルの相違点をカラー表示してくれるdocdiffは非常に重宝します。wdiffだと日本語がうまくいかないということで、rubyで作られているdocdiffを使っていますが、Mavericksにアップデートしたら動かなくなるとか、インストーラが以前はあったけど現在のシステムで動かないといろいろあり、困ってしまいました。ソースから動かす方法を、ほとんど自分の備忘録として書いておきます。

まず、githubにあるdocdiffのサイトから、ソース一式を「Download ZIP」ボタンでダウンロードします。Makeとかあるのだけど、Ver.1.8 onlyとあります。MavericksはVer.2.0がデフォルトです。それで、最低限の作業を考えた結果このような流れでできることが分かりました。ダウンロードしたファイルを展開したdocdiff-masterフォルダを基準に説明します。

  1. bin/docdiffを/usr/local/binにコピーする(あるいは/usr/binにコピー)
  2. libにある1フォルダ3ファイルを、Rubyのライブラリフォルダにコピーする

ライブラリフォルダとは、以下のパスになります。

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0

これで、1でコピーした先にパスが通っていれば、docdiffコマンドとして稼働します。つまり、

docdiff --format=tty file1 file2

とすれば、カラーリングした結果でファイルの違いを文字単位で表示します。

なお、これをsvn上で使いたいので、次のようなことをしています。まず、上記、ダウンロードしたdocdiffファイルを/usr/local/binにコピーしたとして、/usr/binに以下のようなスクリプト「docdiff」を作ります。もちろん、実行権限を与えておきます。

#/bin/sh
/usr/local/bin/docdiff --format=tty $6 $7

こうすれば、svnでのコマンドで

svn diff -r PREV --diff-cmd=/usr/bin/docdiff file

とすることで、たとえば、こんな感じに見えます。このコマンドだと、現在のファイルとRevision 15のファイルを比べていて、赤は消えたもの、青は追加されたものです。黄色の代わりに緑になるという感じです。

shot0180

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

Byte誌を創刊した人が亡くなられたという記事を読み…

PragPubの最新号(Oct 2013)を読んでいたら最後のページに訃報が掲載されていた。Wayne Green、1975年にBytes誌を創刊、いっしょにビジネスをしていた元妻と即トラブって後々の同誌の栄光時代はともに歩んでいないとはいえ、PragPubはMr.Greenの最大の功績としてByteの創刊を挙げている。日本だと、私と同世代を中心に「日経バイト」の読者も多いだろうし、その隣の編集部で私は何年か過ごしただけに関係者とも今でもFacebookでつながっている。日本で発行する遥か前に関わった人ではあるけど、こうして雑誌で紹介されるのは、Byte誌の存在感はすでに廃刊している今も大きいということだ。

日本で日経バイトが発行されたのは80年代、私は高校→大学→就職→転職とめまぐるしい10年だったが、コンピュータ雑誌は情報を得る最も先端的な手段だと皆が思っていた。研究室では当然ながら誰かが買って来た1冊を回し読みをする。みんなお金がないので、特定の雑誌を買っている研究室にわざわざ読みにも行く。そんな研究室で、日経バイト購買担当は自分だった。「日経バイト」を読んでいたら、コンピュータに疎い同級生が「いいの載っているか?」と聞いてくる(そのバイトやない…)。「すごいよー」と言って見せると、ひー!と言いやがった。その日経バイトの翻訳記事でMacintoshはよく掲載されていた。毎日自分が見ているコンピュータのあまりの違いにショックであり、すごく高価だけどアメリカではこんな先を走っているのかと印象付けられた。そして現在がある。

出版や雑誌の存在感が大きな時代は、もはやなつかしいものになった。そんな時代に短いながらも出版社で雑誌を作る仕事ができたことは、得難い経験になった。自分のキャリアのベースはそこにある。雑誌は特にチームプレイであり、「映画を作るような熱狂」(映画を作った事はないので想像だけど)を年がら年中やっていたような高揚感があったことを思い出す。時代は移り、インターネットの発展でメディアの立ち位置は大きく変わったが、Byte誌という言葉を聞くとなんだかワクワク感が戻ってくると同時に、はるか昔のさまざまなことを思い出させてくれる。Mr.Green、享年91歳。