2011
iTunes WiFi同期と無線ルータ
2011/11/20 18:53 iPhone
iOS5から可能になったiTunes WiFi同期が不安定で苦しんだ原因を発見の巻。
現象は、iPhone 4、iPadがOS X Lionが母艦のiTunesからデバイスリストに現れたり現れなかったり。あるいは無事現れて同期開始しても、iOSデバイスを検索中になってしまい、いつまでも同期作業を始めない。
暫定措置として、iPhone 4、iPadで１度「機内モード」をON-OFFするときちんとつながり、同期もできるようなるので、何とかしのいでいた。
ところが今度は、Apple TV 2をバージョンアップした途端、iPhone 4、iPadのRemote.appから有線でつながっているApple TV 2に接続できなくなるトラブルが発生。ホームシェアリングをONにしているにも関わらず、iOSデバイス間の通信がまったくダメ。Apple TV 2と母艦のMacとは有線同士でつながっており、こちらのホームシェアリングには問題がないので、明らかに無線LANの問題である。
…というわけで、Buffaloの無線LANルータ、WZR-HP-G300NHの設定を再度見直したところ…
ありましたよ。諸悪の根源が。マルチキャストSnooping機能ONだ。AppleのホームシェアリングやiTunes WiFi同期などは、デバイスを認識するためにマルチキャストを多用するが、Snooping機能によりこれらをブロックされていた訳である。問題なのは、完全なブロックではなく「不要なパケットを抑制」すること。不要か不要でないかを勝手に判断されるので、iOSデバイスが見えたり見えなかったり、つながったりつながらなかったりするのだ。
こういうおせっかい機能は、ふつうデフォルトでOFFにしておくべきものだと思う。Buffaloのバカ～！。って、自分でONにしたのかなぁ？
現象は、iPhone 4、iPadがOS X Lionが母艦のiTunesからデバイスリストに現れたり現れなかったり。あるいは無事現れて同期開始しても、iOSデバイスを検索中になってしまい、いつまでも同期作業を始めない。
暫定措置として、iPhone 4、iPadで１度「機内モード」をON-OFFするときちんとつながり、同期もできるようなるので、何とかしのいでいた。
ところが今度は、Apple TV 2をバージョンアップした途端、iPhone 4、iPadのRemote.appから有線でつながっているApple TV 2に接続できなくなるトラブルが発生。ホームシェアリングをONにしているにも関わらず、iOSデバイス間の通信がまったくダメ。Apple TV 2と母艦のMacとは有線同士でつながっており、こちらのホームシェアリングには問題がないので、明らかに無線LANの問題である。
…というわけで、Buffaloの無線LANルータ、WZR-HP-G300NHの設定を再度見直したところ…
ありましたよ。諸悪の根源が。マルチキャストSnooping機能ONだ。AppleのホームシェアリングやiTunes WiFi同期などは、デバイスを認識するためにマルチキャストを多用するが、Snooping機能によりこれらをブロックされていた訳である。問題なのは、完全なブロックではなく「不要なパケットを抑制」すること。不要か不要でないかを勝手に判断されるので、iOSデバイスが見えたり見えなかったり、つながったりつながらなかったりするのだ。
こういうおせっかい機能は、ふつうデフォルトでOFFにしておくべきものだと思う。Buffaloのバカ～！。って、自分でONにしたのかなぁ？
iCalとiOS5リマインダーの微妙な関係
2011/10/29 15:02 iPhone
iOS5でようやく標準搭載されたApple純正ToDoアプリ「リマインダー」。
相変わらずAppleが作るPIMツールはいろいろと問題をはらんでいるようだ。
OS X LionのiCalにもともと搭載されていたToDoとの同期が出来るようになり、名称も「リマインダー」と統一されたのだが、確認できただけでも次のような仕様（不具合？）で悩んでいる。
リマインダーやiCalで「Work」というリマインダーリストを作ると、リマインダーの中ではなぜか「職場」と表示される。ほかにも同じような変換規則があるのだろうか？
リマインダーの繰り返しの扱いiCalのリマインダーには「繰り返し」の属性がない。そのため、iPhone側で「繰り返し」を登録すると、同期されたiCal側では表示は出来ても編集ができなくなってしまう。
iPhoneリマインダーでソート（並べ替え）ができない一番困るのがこれ。iPhoneのリマインダーは登録順で強制的にソートされてしまうため、締め切り順や重要度順などでソートする手段がない。iCalの並べ替え設定を同期してくれればいいのに。
相変わらずAppleが作るPIMツールはいろいろと問題をはらんでいるようだ。
OS X LionのiCalにもともと搭載されていたToDoとの同期が出来るようになり、名称も「リマインダー」と統一されたのだが、確認できただけでも次のような仕様（不具合？）で悩んでいる。
リマインダーの繰り返しの扱い
iPhoneリマインダーでソート（並べ替え）ができない
Steve Jobs逝く
2011/10/29 15:01 Life
Steve Jobsが亡くなって、１つ人生の楽しみが無くなった。
これまではAppleの動向さえ見ていれば、マーケティングはだいたい理解できた。Appleに対して、ほかの会社や業界はこういう動きをしている…という視点で見るととてもクリアになる。
Apple=Jobsとまでは言わないが、やはり革新を成し遂げるには、集団ではなく象徴が必要だったのだと思う。人柱とまでは言わないが…
これまではAppleの動向さえ見ていれば、マーケティングはだいたい理解できた。Appleに対して、ほかの会社や業界はこういう動きをしている…という視点で見るととてもクリアになる。
Apple=Jobsとまでは言わないが、やはり革新を成し遂げるには、集団ではなく象徴が必要だったのだと思う。人柱とまでは言わないが…
OS X LionのSpotlightとTime Machineの不適切な関係
2011/09/25 13:21 Mac OS X
Lionにアップデート後、Time Machineのバックアップ・ディスクがアンマウントされないのはSpotlightが原因。気長にSpotlightがバックアップのインデックス作業を終えるのを待てば、いつかはアンマウントされるとレポートした。１度インデックス作業が終われば、Spotlightが忙しくなることもないはず。
ところがその後も、頻度は下がったものの、Time Machine バックアップが同じ原因でアンマウントが遅れる事態が起こったのだ。システムのログを見ると、mdworkerが過去のバックアップのインデックス作業に勤しんでいる様子… 過去１年分のバックアップをさかのぼって一生懸命インデックスの再構築をしているようなのである。そのあおりを食らって、たとえ数十MBでもTime Machineのバックアップ時間が20分以上かかることがざら。もう勘弁してくれ。
最後の手段として、過去の遺産であるTime Machine バックアップ（約340GB）を別のHDDに退避した上で、Spotlight再構築（sudo mdutil -E /）をし、Time Machine バックアップも１から作り直すことにした。バックアップ先のTime CapsuleとはギガビットEthernetでつながっているとはいえ、100GBの新規バックアップともなると15時間かかってしまった。
新規バックアップの結果は劇的である。
Time Machine バックアップでのSpotlightインデックス作業は止まった。いや、実際には動いているのかも知れないが少なくともユーザ感知外のレベルにはなった。バックアップ作業も３分くらいで終了するし、バックアップディスクは即座にアンマウントされる。Snow Leopard時と変わらないレベルに落ち着いた。
今回得られたバッドノウハウは、「Time Machine バックアップ上では旧OSとの混在は避けた方がよろしい」。
ところがその後も、頻度は下がったものの、Time Machine バックアップが同じ原因でアンマウントが遅れる事態が起こったのだ。システムのログを見ると、mdworkerが過去のバックアップのインデックス作業に勤しんでいる様子… 過去１年分のバックアップをさかのぼって一生懸命インデックスの再構築をしているようなのである。そのあおりを食らって、たとえ数十MBでもTime Machineのバックアップ時間が20分以上かかることがざら。もう勘弁してくれ。
最後の手段として、過去の遺産であるTime Machine バックアップ（約340GB）を別のHDDに退避した上で、Spotlight再構築（sudo mdutil -E /）をし、Time Machine バックアップも１から作り直すことにした。バックアップ先のTime CapsuleとはギガビットEthernetでつながっているとはいえ、100GBの新規バックアップともなると15時間かかってしまった。
新規バックアップの結果は劇的である。
Time Machine バックアップでのSpotlightインデックス作業は止まった。いや、実際には動いているのかも知れないが少なくともユーザ感知外のレベルにはなった。バックアップ作業も３分くらいで終了するし、バックアップディスクは即座にアンマウントされる。Snow Leopard時と変わらないレベルに落ち着いた。
今回得られたバッドノウハウは、「Time Machine バックアップ上では旧OSとの混在は避けた方がよろしい」。
WordのファイルをePub形式へ変換
iPhoneのiBooksでWordのファイルを読むとすごく快適になった…というお話。
iPhoneやiPadは、標準でもWordやPDFファイルが読めるわけだが、原文のレイアウトをそれなりに再現してしまうため、電子書籍なんかと比べると読みやすさにはかなり難がある。フォントが小さいとか、上下左右マージンのスペースが無駄とか、行送りとかページ送りが面倒とかで、まぁ読めないこともないという程度。GoodReaderはそれなりにがんばっているとは思うのだが…。
その点、電子書籍リーダは、読みやすいレイアウト、ページ送り、しおり機能など、長い文書を読むのには最適。せっかくだから、Wordのファイル（報告書やら読み物やら…）を電子書籍形式で読みたい！せっかくiBooksはePubに対応しているんだから、WordをePubに変換さえ出来れば！といろいろがんばってみた。
だけれども、あんまりがんばることもなかった。実際、日本語のWordファイルを日本語に対応したePub形式にきちんと変換できるアプリケーションってほとんど選択肢がないのだ。最終的に行き着いたのは、Pagesである。Wordファイル（.doc, .docx）を１度Pagesで読み込んで、ePub形式へ書き出すだけ。正直、あまり期待していなかったのだが、これがなかなか実用的であることが分かった！
PagesによるePub書き出しで唯一問題となったのは、フローティングレイアウト形式の画像が変換されないこと。文字列の中に画像を埋め込んだインラインレイアウト形式に一つ一つ手作業で編集せざるを得なかった（数が多いとそれなりに大変）。だが問題といえばそれくらいで、変換時間はもあっという間、変換後のファイルサイズは元のWordファイルの約1/3くらいであった。余談だが、このePub変換のための「書き出す…」メニューが「共有」メニューの中にあるのは、いかにもApple流だ。
肝心のiBooksでの読み心地だが、まさに「言うことなし」である。iBooksでは、通常の電子書籍と同じレイアウトと操作感で読み進むことが出来るのに加えて、Word内の「目次」や「脚注」まできちんと再現されている。さらに「しおり」や「ハイライト」はプッシュによってiPad、iPhone間で共有化されるので、むしろWordで直接読むより読みやすいぞ。
今回はわざわざePub変換だけのためにPagesを購入するハメになってしまったのだがこれは「アタリ」だったかも。Pagesはまだ縦書きに対応していないし、ePubの日本語対応もまだこれからだが、ちょっと将来を先取りした気分になれたかも。
その点、電子書籍リーダは、読みやすいレイアウト、ページ送り、しおり機能など、長い文書を読むのには最適。せっかくだから、Wordのファイル（報告書やら読み物やら…）を電子書籍形式で読みたい！せっかくiBooksはePubに対応しているんだから、WordをePubに変換さえ出来れば！といろいろがんばってみた。
PagesによるePub書き出しで唯一問題となったのは、フローティングレイアウト形式の画像が変換されないこと。文字列の中に画像を埋め込んだインラインレイアウト形式に一つ一つ手作業で編集せざるを得なかった（数が多いとそれなりに大変）。だが問題といえばそれくらいで、変換時間はもあっという間、変換後のファイルサイズは元のWordファイルの約1/3くらいであった。余談だが、このePub変換のための「書き出す…」メニューが「共有」メニューの中にあるのは、いかにもApple流だ。
肝心のiBooksでの読み心地だが、まさに「言うことなし」である。iBooksでは、通常の電子書籍と同じレイアウトと操作感で読み進むことが出来るのに加えて、Word内の「目次」や「脚注」まできちんと再現されている。さらに「しおり」や「ハイライト」はプッシュによってiPad、iPhone間で共有化されるので、むしろWordで直接読むより読みやすいぞ。
今回はわざわざePub変換だけのためにPagesを購入するハメになってしまったのだがこれは「アタリ」だったかも。Pagesはまだ縦書きに対応していないし、ePubの日本語対応もまだこれからだが、ちょっと将来を先取りした気分になれたかも。
Pocket Informant 2.0がもうすぐリリース
2011/09/03 21:02 iPhone
標準のカレンダーアプリがあまりに
PI 2.0のリリースはかなり前から予告されていたものの、当初の計画から６ヶ月遅れとなっているらしい。その代わり、新エンジンを搭載し、最新iOSに対応するためにほとんどのコードが書き直されているとのこと。現在ベータ版ができたところで、バグフィックス作業はこれから。さらに磨きのかかったUIに期待したい。
なお、2.0リリースの前に、1.xのバグフィックス版である1.68がリリースされる予定だそう。
Spotlightで大量のエラーメッセージ
2011/08/30 22:29 Mac OS X
前々回に報告したTime Machineの不具合（ではなかった）の報告の中で、Spotlight（mdworker）が大量のエラーメッセージをコンソールに吐いていると書いた。これがバックアップの不具合の原因と思っていたのだが実はそうではなかったらしい。
件のエラーメッセージは次のようなもの。
この原因についてなかなかそのものずばりの答えが見つからなかったのだが、米国のApple Discussionsの問答の中にThunderbirdなどのメーラを疑う回答が一つだけあった。
そこで試しに、既にMail.appに移行したけども一応何かのために残してあったThunderbird 6.0のバッケージに納められている、Thunderbird.app/Contents/Library/Spotlight/Thunderbird.mdimporterを無効にするため、Thunderbird.mdimporter.disabledと名前を変更してフォルダに変えてしまった。
そうするとあら不思議、大量のエラーログはそれ以後まったく出なくなったではないか。正確なところは不明だが、Thunderbird.mdimporterがLionにきちんと対応できていないのかも知れない。
そもそもThunderbirdは独自に高速検索エンジンを内蔵しているためアプリケーション本体はSpotlightを必要としない。またSpotlightに無理やり対応させるために、本来のメールボックス以外に１ファイル１メール形式の.mozemlという拡張子ファイルまで生成するのでディスクの無駄なんだよね。Mail.appへ移行した理由の一つがこれなんだよ。もう移行しちゃったんだからいいんだけどね～
長年愛用してきたメーラだけに最近の開発状況なども見ているとちょっと寂しいかな…
件のエラーメッセージは次のようなもの。
１秒間に500以上のログメッセージを出している、とまで警告されている。11/08/28 xx:xx:xx.xxx com.apple.mdworker.lsb.0: trying to parse date
11/08/28 xx:xx:xx.xxx com.apple.mdworker.lsb.0: got cur date
11/08/28 xx:xx:xx.xxx com.apple.mdworker.lsb.0: *** process 260 exceeded 500 log message per second limit - remaining messages this second discarded ***
この原因についてなかなかそのものずばりの答えが見つからなかったのだが、米国のApple Discussionsの問答の中にThunderbirdなどのメーラを疑う回答が一つだけあった。
そこで試しに、既にMail.appに移行したけども一応何かのために残してあったThunderbird 6.0のバッケージに納められている、Thunderbird.app/Contents/Library/Spotlight/Thunderbird.mdimporterを無効にするため、Thunderbird.mdimporter.disabledと名前を変更してフォルダに変えてしまった。
そうするとあら不思議、大量のエラーログはそれ以後まったく出なくなったではないか。正確なところは不明だが、Thunderbird.mdimporterがLionにきちんと対応できていないのかも知れない。
そもそもThunderbirdは独自に高速検索エンジンを内蔵しているためアプリケーション本体はSpotlightを必要としない。またSpotlightに無理やり対応させるために、本来のメールボックス以外に１ファイル１メール形式の.mozemlという拡張子ファイルまで生成するのでディスクの無駄なんだよね。Mail.appへ移行した理由の一つがこれなんだよ。もう移行しちゃったんだからいいんだけどね～
長年愛用してきたメーラだけに最近の開発状況なども見ているとちょっと寂しいかな…
Time Machineバックアップ終了後アンマウントされない（解決編）
2011/08/29 22:06 Mac OS X
前回書いた、Time Machineでバックアップが終了しても、Spotlightの索引作成が終了していないため「Time Machine バックアップ」のディスクがデスクトップに残ってしまう件の解決編である。
今回Lionへアップデートしたことで、標準のmdimporterなどもかなりアップデートされている。このためSpotlightは起動ディスクだけでなく、Time Capsule上にあるバックアップに対しても索引の再作成を行っているようだ。実際、アクティビティモニタを見るとSpotlightのmdworkerプロセスがいくつも動いており、さらにTime Capsuleとの間のネットワークアクセスが頻繁になっていた。
ここまで分かれば後は簡単。単にそのままMacを立ち上げたまま放置しておけば良いだけである。３～４時間くらいしたら索引作成が自動的に終了し、それとともにすぐに「Time Machine バックアップ」もアンマウントされた。以後、Time Machineでバックアップが走っても、終了後はすぐにアンマウントされるようになった。Lionアップデート後、いつもの調子ですぐにシステムをシャットダウンしてしまっていたのが間違いでした。
なお、索引終了とともに、/Volumes/Time Machine バックアップ/Backups.backupdb/にあった、.spotlight_repair/, .spotlight_temp/という空フォルダは消えうせ、.Spotlight-V100/という通常のSpotlightの索引フォルダが生成されていた。これにて一件落着。
今回Lionへアップデートしたことで、標準のmdimporterなどもかなりアップデートされている。このためSpotlightは起動ディスクだけでなく、Time Capsule上にあるバックアップに対しても索引の再作成を行っているようだ。実際、アクティビティモニタを見るとSpotlightのmdworkerプロセスがいくつも動いており、さらにTime Capsuleとの間のネットワークアクセスが頻繁になっていた。
ここまで分かれば後は簡単。単にそのままMacを立ち上げたまま放置しておけば良いだけである。３～４時間くらいしたら索引作成が自動的に終了し、それとともにすぐに「Time Machine バックアップ」もアンマウントされた。以後、Time Machineでバックアップが走っても、終了後はすぐにアンマウントされるようになった。Lionアップデート後、いつもの調子ですぐにシステムをシャットダウンしてしまっていたのが間違いでした。
なお、索引終了とともに、/Volumes/Time Machine バックアップ/Backups.backupdb/にあった、.spotlight_repair/, .spotlight_temp/という空フォルダは消えうせ、.Spotlight-V100/という通常のSpotlightの索引フォルダが生成されていた。これにて一件落着。
Time Machineバックアップ終了後アンマウントされない
2011/08/28 21:26 Mac OS X
Lionにアップデートしてようやく安定稼働状態まで来たと思っていたが、ここに来てまたトラブル発生。
Time Machineバックアップが終了後もTime Capsuleがアンマウントされず、デスクトップに残った状態となってしまっている。コンソールを開いてみると、
大量のバックアップをしている訳でもないので、バックアップの索引が壊れているのか？ 実際、/Volumes/Time Machine バックアップ/Backups.backupdb/の中を見ると、.spotlight_repair/, .spotlight_temp/という怪しげな空フォルダができている。単にこれらのファイルを削除したり、Spotlightを初期化するだけでは問題は解決しない模様。
さらに、同じ問題かどうか不明だが、Spotlightは以下のようなメッセージも大量にコンソールに吐き出している。
…という訳で、Spotlight, Time Machine, Time Capsuleの複合的な問題であること、特にSpotlightの何か（おそらくどれかのmdimporter）がそのトリガーになっているところまでは行き着いた。腰を据えて検証を実施予定。
⇒本件の解決編をご参照下さい（その1）
⇒積み残しの解決編もご参照下さい（その2）
Time Machineバックアップが終了後もTime Capsuleがアンマウントされず、デスクトップに残った状態となってしまっている。コンソールを開いてみると、
というログが続いている。要するにSpotlightの索引作成が終わるのを待ち続けているらしい。11/08/27 xx:xx:xx.xxx com.apple.backupd: Waiting for Spotlight to finish indexing /Volumes/Time Machine バックアップ/Backups.backupdb
大量のバックアップをしている訳でもないので、バックアップの索引が壊れているのか？ 実際、/Volumes/Time Machine バックアップ/Backups.backupdb/の中を見ると、.spotlight_repair/, .spotlight_temp/という怪しげな空フォルダができている。単にこれらのファイルを削除したり、Spotlightを初期化するだけでは問題は解決しない模様。
さらに、同じ問題かどうか不明だが、Spotlightは以下のようなメッセージも大量にコンソールに吐き出している。
どうやらmdimporterのどれかが問題と推定しているのだが、まだ原因が分からない。11/08/27 xx:xx:xx.xxx com.apple.mdworker.lsb.0: trying to parse date
11/08/27 xx:xx:xx.xxx com.apple.mdworker.lsb.0: got cur date
…という訳で、Spotlight, Time Machine, Time Capsuleの複合的な問題であること、特にSpotlightの何か（おそらくどれかのmdimporter）がそのトリガーになっているところまでは行き着いた。腰を据えて検証を実施予定。
⇒本件の解決編をご参照下さい（その1）
⇒積み残しの解決編もご参照下さい（その2）
Mail.appで画像ファイルの添付
2011/08/20 16:41 Mac OS X
OS X LionのMail.app 5.0で、JPEG、PNG、GIFなどの画像ファイルを送信するときの問題点とその解決策をレポートしよう。
ThunderbirdからMail.appへ移行して日が浅いので、他のメーラ、特にWindowsのメーラとの互換性は気になるところである。日本語の扱いについては既報通り、LetterFix plug-inでほぼ解決を見たが、次はやはりよく問題になる添付ファイルについてだ。
Mail.appは、「編集＞添付ファイル」で「常に Windows 対応の添付ファイルを送信」、「常に添付ファイルをメッセージの最後に挿入」にチェックを入れることで、他のメーラとの互換性を維持している。ところがMail.app 5.0ではこのオプションを使っても、JPEG、PNG、GIFなどの画像ファイルを送信した場合、受信したメーラによってはその画像を見られない…というトラブルが起こる可能性がある。
Mail.app 5.0から画像ファイルを添付すると、自動的にマルチパートのメールが作成される。１つは標準テキストやプレーンテキストのメールであり、もう１つはHTMLメール。そして画像ファイルは、Content-Disposition: inline というヘッダでHTMLメールに貼り付けられてしまう。結果として、このメールを受信した人は、画像ファイルをHTMLメールでしか見ることができない。プレーンテキストのメールの方からは画像ファイルがあることが分からなくなる。
もちろん受信者側のメーラが、HTMLメールの方を優先表示したり、プレーンテキストのメールから画像ファイルだけを保存できるような仕組みを持っていれば問題は起きない。だが現実はそんなに甘くない。セキュリティ対策のためHTMLメールを標準にすることはあまりないし、Thunderbird 6.0のようなメジャーなメーラでもプレーンテキストのメールからこのインライン画像ファイルを見ることどころか、存在することも分からない。
その解決方法であるが、Content-Disposition: attachment というヘッダを付けて画像ファイルを送れば、プレーンテキスト側のメールでも添付ファイルの存在を確認できるようになる。ところがこのヘッダを切り替えるオプションがMail.appにはないのだ。リッチコンテンツのメールを書きなさいというAppleの意図的な仕様か、あるいはプログラマが単に気が利かないだけなのか…（たぶん前者のような気がする…）。
いずれにせよ唯一の解決策は、Attachment Tamerというシェアウェアをインストールすることである。
Attachment Tamerは、添付ファイル送信時の問題だけでなく、長いファイル名の添付ファイルを受信しても省略せずにファイル名を表示してくれたり、画像のインライン表示を抑制したりもできる。歴史の長いシェアウェアであると同時に、Lionの正式リリース前にLion対応もしており信頼性もそれなりである。$14.99だが、円高のおかげで日本円なら1,216円。何ともならないよりはまし…かぁ。
ThunderbirdからMail.appへ移行して日が浅いので、他のメーラ、特にWindowsのメーラとの互換性は気になるところである。日本語の扱いについては既報通り、LetterFix plug-inでほぼ解決を見たが、次はやはりよく問題になる添付ファイルについてだ。
Mail.appは、「編集＞添付ファイル」で「常に Windows 対応の添付ファイルを送信」、「常に添付ファイルをメッセージの最後に挿入」にチェックを入れることで、他のメーラとの互換性を維持している。ところがMail.app 5.0ではこのオプションを使っても、JPEG、PNG、GIFなどの画像ファイルを送信した場合、受信したメーラによってはその画像を見られない…というトラブルが起こる可能性がある。
Mail.app 5.0から画像ファイルを添付すると、自動的にマルチパートのメールが作成される。１つは標準テキストやプレーンテキストのメールであり、もう１つはHTMLメール。そして画像ファイルは、Content-Disposition: inline というヘッダでHTMLメールに貼り付けられてしまう。結果として、このメールを受信した人は、画像ファイルをHTMLメールでしか見ることができない。プレーンテキストのメールの方からは画像ファイルがあることが分からなくなる。
もちろん受信者側のメーラが、HTMLメールの方を優先表示したり、プレーンテキストのメールから画像ファイルだけを保存できるような仕組みを持っていれば問題は起きない。だが現実はそんなに甘くない。セキュリティ対策のためHTMLメールを標準にすることはあまりないし、Thunderbird 6.0のようなメジャーなメーラでもプレーンテキストのメールからこのインライン画像ファイルを見ることどころか、存在することも分からない。
その解決方法であるが、Content-Disposition: attachment というヘッダを付けて画像ファイルを送れば、プレーンテキスト側のメールでも添付ファイルの存在を確認できるようになる。ところがこのヘッダを切り替えるオプションがMail.appにはないのだ。リッチコンテンツのメールを書きなさいというAppleの意図的な仕様か、あるいはプログラマが単に気が利かないだけなのか…（たぶん前者のような気がする…）。
いずれにせよ唯一の解決策は、Attachment Tamerというシェアウェアをインストールすることである。
Attachment Tamerは、添付ファイル送信時の問題だけでなく、長いファイル名の添付ファイルを受信しても省略せずにファイル名を表示してくれたり、画像のインライン表示を抑制したりもできる。歴史の長いシェアウェアであると同時に、Lionの正式リリース前にLion対応もしており信頼性もそれなりである。$14.99だが、円高のおかげで日本円なら1,216円。何ともならないよりはまし…かぁ。
OS X LionでX11がカーネルパニック
2011/08/19 19:16 Mac OS X
OS X Lionで今度はX11がカーネルパニックを起こした。
どういう訳だか、xeyesどころかGimp、InkscapeなどのX11アプリケーションを起動しても問題もないのに、/usr/X11/bin/xterm, /usr/X11/bin/uxtermなどX11ターミナルを起動した途端にカーネルパニックが起きる。X11はすべてLion標準の環境である。/Applications/Utilities/X11.appをダブルクリックして立ち上げると自動的にxtermが起動するため、xtermのウインドウが開いた途端にカーネルパニックが起きてしまう。Terminal.appからX11コマンドを叩いて起動したりして、xtermを開かなければカーネルパニックが起きないという理屈だ。
ところが、新しく作成したユーザの環境であれば、X11.appでxtermもuxtermもちゃんと起動することが分かった。新ユーザと自分の違いはデフォルトのシェルと環境変数だけである。ひょっとして…と、デフォルトシェルを慣れ親しんだ/bin/tcshからLionのデフォルトである/bin/bashへ切り替えたところ…起動した。xtermもuxtermも起動するし、カーネルパニックも起きなくなった。環境変数もtcshとほぼ同じに設定したが何も起きない…。原因を突き止めるまで何度カーネルパニックを起こしたことか…orz
これ以上突き詰めてはいないが、/bin/tcshとLionのxterm, uxtermなどのX11ターミナルは相性が悪いのか？
しかしxterm上でtcshが起動するだけでカーネルパニックとは…せめてX11がcore dumpするまでに留めておけないものかねぇ。
まだまだLionには危険なバグがたくさん潜んでいそうである。
どういう訳だか、xeyesどころかGimp、InkscapeなどのX11アプリケーションを起動しても問題もないのに、/usr/X11/bin/xterm, /usr/X11/bin/uxtermなどX11ターミナルを起動した途端にカーネルパニックが起きる。X11はすべてLion標準の環境である。/Applications/Utilities/X11.appをダブルクリックして立ち上げると自動的にxtermが起動するため、xtermのウインドウが開いた途端にカーネルパニックが起きてしまう。Terminal.appからX11コマンドを叩いて起動したりして、xtermを開かなければカーネルパニックが起きないという理屈だ。
ところが、新しく作成したユーザの環境であれば、X11.appでxtermもuxtermもちゃんと起動することが分かった。新ユーザと自分の違いはデフォルトのシェルと環境変数だけである。ひょっとして…と、デフォルトシェルを慣れ親しんだ/bin/tcshからLionのデフォルトである/bin/bashへ切り替えたところ…起動した。xtermもuxtermも起動するし、カーネルパニックも起きなくなった。環境変数もtcshとほぼ同じに設定したが何も起きない…。原因を突き止めるまで何度カーネルパニックを起こしたことか…orz
これ以上突き詰めてはいないが、/bin/tcshとLionのxterm, uxtermなどのX11ターミナルは相性が悪いのか？
しかしxterm上でtcshが起動するだけでカーネルパニックとは…せめてX11がcore dumpするまでに留めておけないものかねぇ。
まだまだLionには危険なバグがたくさん潜んでいそうである。
Mail.appへ移行 - さらばThunderbird
OS X Lionのリリースを機に、メール環境をThunderbirdからMail.appへ移行した。
Thunderbirdの利点は、日本語メールにおいてPCとMacとの間で完全な互換性を有する点、さらにPCとMac間（おそらくLinuxも含む）でメールの共有や移行が容易である点などであろうか。またFirefoxと同様、Add-onによる機能拡張も可能なことも愛用し続けてこられた理由の一つだった。しかしさすがにアプリケーションそのものの設計が古いことが災いし始めている。
まず、mbox形式のメールボックスはSpotlight検索との相性が悪い。Spotligt検索用に１メール１ファイルのテンポラリファイルをわざわざ生成するという付け焼き刃の対応により、ディスク容量を圧迫する事態となっている。これが理由かどうか分からないがメール数が多くなると起動がひどく遅い。Thunderbirdは高速検索用に独自の検索インデックスを持っているのでさらに無駄である。
折しもMozillaによる開発体制の方針転換により、ついこの間まで3.1.xだったのに、一気にThunderbird 6.0がリリースされることとなった。OS X版では起動速度が大幅に改善されているのだが、愛用してきたかなりマイナーなAdd-onが一つも使えなくなってしまった。Firefoxと違ってもともとAdd-on開発者が少ないため、今後これらのバージョンアップはほとんど望めないだろう。
一方、Mail.appの最大の弱点は日本語まわりの処理。Mail.app 5.0になってもほとんど改善は進んでいないのだが、さまざまな人々の努力の甲斐あって内部の解析が進み、パッチが提供されるようになった。今では LetterFix plug-in 一本さえあれば、機種依存文字の表示・入力や日本語エンコーディングのバグをほぼ実用レベルで解決できる。
何よりもOS標準のアプリケーションであることに安心感がある。SpotlightやWebkitとの連携など、OSと深く結びつくことにより使い勝手が大幅に向上している。QuickLookでURLをプレビューするのは、リンク先がどんなページかチラ見するのにとても便利である。
Mail.appへのメールボックスの移行はとても簡単であった。「ファイル＞メールボックスを読み込む…」で「mbox フォーマットのファイル」を選んで変換すればよいだけ。メールの消失は起こらなかった。クリーンアップせずに読み込んだメールボックスで、逆に削除したはずのメールが復活してしまったりしたが、これは仕方がないかなぁ。
Thunderbirdの利点は、日本語メールにおいてPCとMacとの間で完全な互換性を有する点、さらにPCとMac間（おそらくLinuxも含む）でメールの共有や移行が容易である点などであろうか。またFirefoxと同様、Add-onによる機能拡張も可能なことも愛用し続けてこられた理由の一つだった。しかしさすがにアプリケーションそのものの設計が古いことが災いし始めている。
まず、mbox形式のメールボックスはSpotlight検索との相性が悪い。Spotligt検索用に１メール１ファイルのテンポラリファイルをわざわざ生成するという付け焼き刃の対応により、ディスク容量を圧迫する事態となっている。これが理由かどうか分からないがメール数が多くなると起動がひどく遅い。Thunderbirdは高速検索用に独自の検索インデックスを持っているのでさらに無駄である。
折しもMozillaによる開発体制の方針転換により、ついこの間まで3.1.xだったのに、一気にThunderbird 6.0がリリースされることとなった。OS X版では起動速度が大幅に改善されているのだが、愛用してきたかなりマイナーなAdd-onが一つも使えなくなってしまった。Firefoxと違ってもともとAdd-on開発者が少ないため、今後これらのバージョンアップはほとんど望めないだろう。
何よりもOS標準のアプリケーションであることに安心感がある。SpotlightやWebkitとの連携など、OSと深く結びつくことにより使い勝手が大幅に向上している。QuickLookでURLをプレビューするのは、リンク先がどんなページかチラ見するのにとても便利である。
Mail.appへのメールボックスの移行はとても簡単であった。「ファイル＞メールボックスを読み込む…」で「mbox フォーマットのファイル」を選んで変換すればよいだけ。メールの消失は起こらなかった。クリーンアップせずに読み込んだメールボックスで、逆に削除したはずのメールが復活してしまったりしたが、これは仕方がないかなぁ。
iPhotoライブラリを共有・メンテナンス
2011/08/15 13:45 Mac OS X
iPhoto '11のライブラリ（iPhoto Share Library）を、同じMac上の複数のユーザ同士で共有する方法は２つある。
一つはAppleが推奨する方法：「iPhoto：複数のユーザでライブラリを共有する」。これは、アクセス権を放棄したボリューム（外付けディスク、またはディスクイメージ）にライブラリを移動するので確実だし、NASでデータを一元管理している場合は都合が良い。
もう一つは、Mac上の共有フォルダにライブラリを置く方法。これは、同じハードディスク上でライブラリを管理できるので、ディスクアクセスは速いし、バックアップもTime Machineにお任せでき、データ消失を心配する必要がないのが利点である。
２番目の方法は情報が少ないのだが、おおむね次の方法にて実現できる。
ややこしいのだが、ここで言うアクセス権とはFinderの「共有とアクセス権」のことであり、UNIXのファイルアクセス権とは異なる。いくらTerminal.appからchmodコマンドなどを使ってユーザへrwのアクセス権を設定してもうまく共有することができない（これに気付くのにだいぶかかった…orz）。
またディスクユーティリティなどを使ってアクセス権の修正などを行うと、iPhotoライブラリの共有ができなくなる場合がある。Lionをインストールした時にこれに遭遇した。
こういう場合は、Command+Optionキーを押しながらiPhotoを起動すると下のメンテナンス・メニューが現れるので、「iPhotoライブラリのファイルのアクセス権を検証して修復」を実行するとよい。
ちなみにこのメンテナンス・メニューは、写真のサムネールがうまく表示されなかったり、登録したはずの写真が見つからない場合にも役に立つ。写真は2,800枚を超え、ライブラリも1.8GBになっているので、メンテナンスも必要だわなぁ。
一つはAppleが推奨する方法：「iPhoto：複数のユーザでライブラリを共有する」。これは、アクセス権を放棄したボリューム（外付けディスク、またはディスクイメージ）にライブラリを移動するので確実だし、NASでデータを一元管理している場合は都合が良い。
もう一つは、Mac上の共有フォルダにライブラリを置く方法。これは、同じハードディスク上でライブラリを管理できるので、ディスクアクセスは速いし、バックアップもTime Machineにお任せでき、データ消失を心配する必要がないのが利点である。
２番目の方法は情報が少ないのだが、おおむね次の方法にて実現できる。
- iPhotoライブラリを/Users/Shared/Pictures/フォルダ（/ユーザ/共有/フォルダの下にPicturesフォルダを作成）にコピー
- /Users/Shared/Pictures/フォルダの「情報を見る」から「共有フォルダ」をONにして、アクセスするユーザに「読み／書き」権限を設定
- iPhotoライブラリの「情報を見る」から「共有とアクセス権」でユーザに「読み／書き」権限を設定
- iPhotoをOptionキーを押しながら起動して、移動したライブラリを選択して起動する
ややこしいのだが、ここで言うアクセス権とはFinderの「共有とアクセス権」のことであり、UNIXのファイルアクセス権とは異なる。いくらTerminal.appからchmodコマンドなどを使ってユーザへrwのアクセス権を設定してもうまく共有することができない（これに気付くのにだいぶかかった…orz）。
またディスクユーティリティなどを使ってアクセス権の修正などを行うと、iPhotoライブラリの共有ができなくなる場合がある。Lionをインストールした時にこれに遭遇した。
こういう場合は、Command+Optionキーを押しながらiPhotoを起動すると下のメンテナンス・メニューが現れるので、「iPhotoライブラリのファイルのアクセス権を検証して修復」を実行するとよい。
ちなみにこのメンテナンス・メニューは、写真のサムネールがうまく表示されなかったり、登録したはずの写真が見つからない場合にも役に立つ。写真は2,800枚を超え、ライブラリも1.8GBになっているので、メンテナンスも必要だわなぁ。
iPhotoのスクリーンセーバ
2011/08/14 19:00 Mac OS X
今さらだが、Mac OS X標準のiPhotoスクリーンセーバが面白い。
スクリーンセーバの設定にある「iPhoto」の表示スタイルには、「スライドショー」「コラージュ」「モザイク」の３種類ある。このうち「モザイク」は、iPhotoのライブラリに100枚以上の写真が入っている場合にのみ利用できる効果。Leopardから追加された機能らしいのだが、全然知らなかった。
写真の枚数をどんどん増やして行き、次の写真をモザイクで見せてくれる。このアニメーションが何とも滑らかで気持ち良いのだ。
いったいどうやって写真をチョイスしているのかとじっくり見ていたら、どうも写真の一部だけしか使わずに必要なモザイクを使っているものもある。例えば空の部分だけを切り取って並べてそのまま空の青色に使ったり、自動車の赤色の部分だけを使ってを紅葉を表現したりと、ずーっと見ていても飽きない。
モザイクはデフォルトで20分割されているが、ちょっと分かりにくいのでオプションで分割行を増やすとさらに感動が増す。
さすがに重たい処理をやっているようで、システム環境設定でプレビューしていると時々落ちたりしてしまうようだが、まぁ愛嬌、愛嬌。
スクリーンセーバの設定にある「iPhoto」の表示スタイルには、「スライドショー」「コラージュ」「モザイク」の３種類ある。このうち「モザイク」は、iPhotoのライブラリに100枚以上の写真が入っている場合にのみ利用できる効果。Leopardから追加された機能らしいのだが、全然知らなかった。
写真の枚数をどんどん増やして行き、次の写真をモザイクで見せてくれる。このアニメーションが何とも滑らかで気持ち良いのだ。
いったいどうやって写真をチョイスしているのかとじっくり見ていたら、どうも写真の一部だけしか使わずに必要なモザイクを使っているものもある。例えば空の部分だけを切り取って並べてそのまま空の青色に使ったり、自動車の赤色の部分だけを使ってを紅葉を表現したりと、ずーっと見ていても飽きない。
モザイクはデフォルトで20分割されているが、ちょっと分かりにくいのでオプションで分割行を増やすとさらに感動が増す。
さすがに重たい処理をやっているようで、システム環境設定でプレビューしていると時々落ちたりしてしまうようだが、まぁ愛嬌、愛嬌。
Lionのウイルスバスタートラブル解消
2011/08/13 15:59 Mac OS X
前回レポートした、OS X Lion上でウイルスバスターが突然停止してしまう問題は、トレンドマイクロからHotFixが提供されて解消された模様。
まず、ウイルスバスター for Mac 1.6 1088のユーザ向けには、ここにあるHotFixと呼ばれる修正プログラムを当てると、コアコントローラが1.1.2048にバージョンアップされる。その後いろいろ試しているが、丸２日間問題は起こっていない。HotFixは「特定の問題の修正」を行うものであり、個々の修正内容やリンク情報はトレンドマイクロのホームページ上にはない。したがってこの情報は、新調されたApple サポートコミュニティの「Lionでウイルスバスターも停止する」という記事の引用である。やはり皆さん困っていたんですね。
なお、ウイルスバスター for Macのホームページからは、最新版の 1.6 1089がダウンロードできるようになっている。自分が試してみた時は、コアコントローラのバージョンはまだ1.1.2047だったので、HotFixを当てた方が無難かも知れない。
いずれは自動アップデートで解消するのだろうが、こういうのはさっさと情報公開して欲しいわなぁ。
まず、ウイルスバスター for Mac 1.6 1088のユーザ向けには、ここにあるHotFixと呼ばれる修正プログラムを当てると、コアコントローラが1.1.2048にバージョンアップされる。その後いろいろ試しているが、丸２日間問題は起こっていない。HotFixは「特定の問題の修正」を行うものであり、個々の修正内容やリンク情報はトレンドマイクロのホームページ上にはない。したがってこの情報は、新調されたApple サポートコミュニティの「Lionでウイルスバスターも停止する」という記事の引用である。やはり皆さん困っていたんですね。
なお、ウイルスバスター for Macのホームページからは、最新版の 1.6 1089がダウンロードできるようになっている。自分が試してみた時は、コアコントローラのバージョンはまだ1.1.2047だったので、HotFixを当てた方が無難かも知れない。
いずれは自動アップデートで解消するのだろうが、こういうのはさっさと情報公開して欲しいわなぁ。
OS X Lionでウイルスバスターのトラブル
2011/07/31 13:04 Mac OS X
OS X LionをSnow Leopardからのアップデートでインストールしたが、２日に１回の割合でカーネルパニックを起こすようになった。
OS Xの場合、カーネルパニックと言っても、Finderの画面に「パワーボタンを数秒間押し続けるか、リセットボタンを押してください」という各国語の表示がかぶさるくらい。スマート過ぎてカーネルパニックと認識しにくい気もするが、UNIXを知らない人にはこれくらいがちょうどよいのだろう。
さて、ウイルスバスターは、１つのシリアル番号でWindowsでもMacでも３台のコンピュータまでインストール可能なのがメリットである。信頼性に欠ける面があるのは否めないが…。というのも、Lionへのアップデートで起こったトラブルで重大なものは、ウイルスバスター for Macが原因と考えられるからだ。起こったトラブルは次の２つ。
1.が、なぜウイルスバスターが原因と特定できたかというと、Lionからウイルスバスターをアンインストールした後、トレンドマイクロのホームページからLionに対応したインストーラをダウンロードして、再インストールを行うだけでカーネルパニックが起こらなくなったからだ。実はここでやらかした間違いは、Snow Leopardにウイルスバスターをインストールしたまま、Lionへアップデートしたことにある。ウイルスバスターに限らず、ウイルスチェックのプログラムはアンインストールしてから、OSのアップデートを行うのが基本である…、と偉そうに言えない悲しさ…
2.の方は、Lion上で再インストールしたにも関わらず直っていない。Time Machineが動き出してTime Capsuleをマウントするタイミングなどに落っこちるような印象があるが、再現性がないため原因が把握できない。よって、バグレポートも出しにくい状況である。一応トレンドマイクロは、ウイルスバスター for MacはOS X Lionに対応（バージョン1.6 1088）している、というのが公式発表なのだが…
（2011/8/13 追記）HotFixにて対応済み！
OS Xの場合、カーネルパニックと言っても、Finderの画面に「パワーボタンを数秒間押し続けるか、リセットボタンを押してください」という各国語の表示がかぶさるくらい。スマート過ぎてカーネルパニックと認識しにくい気もするが、UNIXを知らない人にはこれくらいがちょうどよいのだろう。
さて、ウイルスバスターは、１つのシリアル番号でWindowsでもMacでも３台のコンピュータまでインストール可能なのがメリットである。信頼性に欠ける面があるのは否めないが…。というのも、Lionへのアップデートで起こったトラブルで重大なものは、ウイルスバスター for Macが原因と考えられるからだ。起こったトラブルは次の２つ。
- Lionで不定期にカーネルパニックが起きる
- ウイルスバスター for Macのプロセスが突然終了する
1.が、なぜウイルスバスターが原因と特定できたかというと、Lionからウイルスバスターをアンインストールした後、トレンドマイクロのホームページからLionに対応したインストーラをダウンロードして、再インストールを行うだけでカーネルパニックが起こらなくなったからだ。実はここでやらかした間違いは、Snow Leopardにウイルスバスターをインストールしたまま、Lionへアップデートしたことにある。ウイルスバスターに限らず、ウイルスチェックのプログラムはアンインストールしてから、OSのアップデートを行うのが基本である…、と偉そうに言えない悲しさ…
2.の方は、Lion上で再インストールしたにも関わらず直っていない。Time Machineが動き出してTime Capsuleをマウントするタイミングなどに落っこちるような印象があるが、再現性がないため原因が把握できない。よって、バグレポートも出しにくい状況である。一応トレンドマイクロは、ウイルスバスター for MacはOS X Lionに対応（バージョン1.6 1088）している、というのが公式発表なのだが…
（2011/8/13 追記）HotFixにて対応済み！
新サイト、新OSで再スタート
2011/07/30 22:55 Blog
３回目のホームページ移転、４つ目のホームページとなります。
新サイト「Focus of Interest -info-」を新ドメインでスタートします。ついにドメインを取得してホスティングサービスへと移行しました。AppleのMobileMeサービスが終了するのに合わせて、ホームページ・サービスがどうなるかも不透明だったので一気に引っ越しした次第です。リアルな住み家も10回以上転居を経験しているので、引っ越しそのものにあんまり抵抗感がないというか、ふらふら生きているというか…
ホームページ開発環境は、バージョンアップしたてのOS X LionとRapidWeaver 5.2.1の組み合わせで再スタートです。しばらく大きな変化がなかったOS Xですが、Lionではコアの部分以外にだいぶ使い勝手も変わりました。パフォーマンスもぐっと良くなった感じ。またボチボチと使用感などアップして行こうと思います。
それでは新サイトをまたよろしくお願いいたします。
新サイト「Focus of Interest -info-」を新ドメインでスタートします。ついにドメインを取得してホスティングサービスへと移行しました。AppleのMobileMeサービスが終了するのに合わせて、ホームページ・サービスがどうなるかも不透明だったので一気に引っ越しした次第です。リアルな住み家も10回以上転居を経験しているので、引っ越しそのものにあんまり抵抗感がないというか、ふらふら生きているというか…
ホームページ開発環境は、バージョンアップしたてのOS X LionとRapidWeaver 5.2.1の組み合わせで再スタートです。しばらく大きな変化がなかったOS Xですが、Lionではコアの部分以外にだいぶ使い勝手も変わりました。パフォーマンスもぐっと良くなった感じ。またボチボチと使用感などアップして行こうと思います。
それでは新サイトをまたよろしくお願いいたします。
rsyncによるバックアップ
2011/07/19 22:33 Mac OS X
Mac OS XでのローカルディスクのバックアップはTime Machineで完璧だが、FireWireやUSB接続の外付けHDDを丸ごとバックアップするときはTime Machineのような履歴は必要ない場合がある。
数あるバックアップツールの中でも、Backuplist+はフリーウェアだし、rsyncのフロントエンドなので信頼性が高いことからも重宝しており、Snow Leopardでも全然問題なく動いてきた。
ところが、ベータリリースである8.0.2へ移行したところ、パーミッションエラーを吐くようになったので、これを機にいろいろと調べてみた。するとバックアップ先がNASだったり、Time CapsuleのようにファイルシステムがHFS+の場合は、ちょっとしたコツが必要なようだ。
Backuplist+ 8.0.2にはrsync 3.0.8がバインディングされているが、rsync 3ではMac OS Xを正式にサポートするようになった。そこで、Time Capsuleにバックアップする場合は、サポートのページに記載があるように、次のオプションを"Expert options"で指定すると良いことになっている。
ところが、8.0.2ではこれだけではrsyncがchownエラーをコンソールに吐き続けることになる。-aオプションは-rlptgoDと同等であるが、どうもowner, groupオプションが悪さ(?)をしている模様。そこで、以下のようにオプション指定すると、エラー無しで動くようになった。
ちなみに、--inplaceは大きなファイルを置換しながらバックアップするオプション。通常rsyncはいったんテンポラリファイルにコピーした後にファイルを書き戻す処理をするが、巨大なファイルのバックアップの場合はこのオプションで高速化が可能になる。このほか、--protect-decmpfsはHFS+圧縮に対応したオプション、-AはWindowsとの互換性を取るためのACLを有効にするオプション、-XはUTF-8文字コードに関するオプション…ということらしい。
…という訳でrsyncをMac OS X上できちんと理解して動かすには、なかなか敷居が高いことが分かった次第。バックアップと一言で言っても、実はいろいろと大変で、ユーザに何も考えさせずに動くTime Machineがいかに良くできているか、改めて認識した。
数あるバックアップツールの中でも、Backuplist+はフリーウェアだし、rsyncのフロントエンドなので信頼性が高いことからも重宝しており、Snow Leopardでも全然問題なく動いてきた。
ところが、ベータリリースである8.0.2へ移行したところ、パーミッションエラーを吐くようになったので、これを機にいろいろと調べてみた。するとバックアップ先がNASだったり、Time CapsuleのようにファイルシステムがHFS+の場合は、ちょっとしたコツが必要なようだ。
Backuplist+ 8.0.2にはrsync 3.0.8がバインディングされているが、rsync 3ではMac OS Xを正式にサポートするようになった。そこで、Time Capsuleにバックアップする場合は、サポートのページに記載があるように、次のオプションを"Expert options"で指定すると良いことになっている。
-aHAXNx --fileflags --force-change --protect-decmpfs --inplace --stats -vところが、8.0.2ではこれだけではrsyncがchownエラーをコンソールに吐き続けることになる。-aオプションは-rlptgoDと同等であるが、どうもowner, groupオプションが悪さ(?)をしている模様。そこで、以下のようにオプション指定すると、エラー無しで動くようになった。
-rltpDHAXNx --fileflags --force-change --protect-decmpfs --inplace --stats -vちなみに、--inplaceは大きなファイルを置換しながらバックアップするオプション。通常rsyncはいったんテンポラリファイルにコピーした後にファイルを書き戻す処理をするが、巨大なファイルのバックアップの場合はこのオプションで高速化が可能になる。このほか、--protect-decmpfsはHFS+圧縮に対応したオプション、-AはWindowsとの互換性を取るためのACLを有効にするオプション、-XはUTF-8文字コードに関するオプション…ということらしい。
…という訳でrsyncをMac OS X上できちんと理解して動かすには、なかなか敷居が高いことが分かった次第。バックアップと一言で言っても、実はいろいろと大変で、ユーザに何も考えさせずに動くTime Machineがいかに良くできているか、改めて認識した。
旧ホームページをマージ
2011/07/18 22:43 Blog
旧ホームページ、Focus of Interest -Blog-のコンテンツをマージしました。
iBlogで書き込んだ約200のエントリを手作業で取り込み。iBlogは2.0RC3から開発が止まってしまったため、OS X Lionへアップデートする前に移行しないと取り返しがつかなくなる可能性が大。
おまけにiCloudへの移行のため、.Macのホームページどころか、MobileMeのホームページサービスも虫の息になってしまいました。Appleの変節には慣れっこではありますが、これを機に独自ドメインとホスティングサービスへの移行準備も進めております。
iBlogで書き込んだ約200のエントリを手作業で取り込み。iBlogは2.0RC3から開発が止まってしまったため、OS X Lionへアップデートする前に移行しないと取り返しがつかなくなる可能性が大。
おまけにiCloudへの移行のため、.Macのホームページどころか、MobileMeのホームページサービスも虫の息になってしまいました。Appleの変節には慣れっこではありますが、これを機に独自ドメインとホスティングサービスへの移行準備も進めております。
iPhoneカレンダーでの1分刻みの予定入力
2011/06/18 20:21 iPhone
Pocket Informantは予定（イベント）の時間を入力するピッカーが１分刻みだが、標準のカレンダー.appを含めほとんどのカレンダーアプリは５分刻みである。ところが実は、標準アプリだけを使って１分刻みの予定を入力すTIPSがありましたとさ。
例えば、メモ.appで、「13:11-14:16」と新規予定の開始時間と終了時間だけを書き込んで「完了」とすると、この時間にリンクが生成される。このリンクをタップすると、「イベントを生成」することができ、標準カレンダーで新規イベントを「13:11-14::16」の時間で作成することができるという流れである。さらに時間の前に、「2011/11/4 13:11-14:16」のように年月日を追加すれば、任意の日時で新規予定を作成可能となる。
唯一の欠点は、この新規イベントは標準カレンダー.appからしか入力できない点であろうか。まぁ１分刻みの予定を作成することは滅多に無いので、大きな障害にはならないかな。
ちなみに、カレンダーアプリの一つであるRefillsの時刻のピッカーは５分間隔であるが、新規予定入力欄に「13:11-14:16 会議」という具合に直接時間と予定を書き込むと、自動的に「開始時間13:11、終了時間14:16」の「会議」の予定を作るインタフェース・デザインを採用している。これはこれで使いやすい。
iOS5からはようやく標準でToDoが実装され、カレンダー.appも改善される模様。アップル的にはPIM系のアプリにあまり力を入れない傾向があるが、さすがに改善の兆しが見えてきたというところだろうか。
唯一の欠点は、この新規イベントは標準カレンダー.appからしか入力できない点であろうか。まぁ１分刻みの予定を作成することは滅多に無いので、大きな障害にはならないかな。
ちなみに、カレンダーアプリの一つであるRefillsの時刻のピッカーは５分間隔であるが、新規予定入力欄に「13:11-14:16 会議」という具合に直接時間と予定を書き込むと、自動的に「開始時間13:11、終了時間14:16」の「会議」の予定を作るインタフェース・デザインを採用している。これはこれで使いやすい。
iOS5からはようやく標準でToDoが実装され、カレンダー.appも改善される模様。アップル的にはPIM系のアプリにあまり力を入れない傾向があるが、さすがに改善の兆しが見えてきたというところだろうか。
RapidWeaver 5.1.1の日本語対応
2011/05/22 18:41 Blog
最近更新が滞っているので、情報が遅れがちだが、RapidWeaver 5のマイナーバージョンアップ版、5.1.1がリリースされていたのでアップデート。
App Storeのリリースノートには、「- Improvements to the French and German Localisations.」とあるだけで、日本語リソースには触れていないが、かなり改善はされた。少なくとも、メニューの一部におかしな文字コードが混じるようなことはなくなって「読める」ようにはなった。理解しづらい日本語は相変わらずだが…。
App Storeのリリースノートには、「- Improvements to the French and German Localisations.」とあるだけで、日本語リソースには触れていないが、かなり改善はされた。少なくとも、メニューの一部におかしな文字コードが混じるようなことはなくなって「読める」ようにはなった。理解しづらい日本語は相変わらずだが…。
RapidWeaver 5へアップデート
2011/05/04 19:11 Blog
3ヶ月ぶりの更新。サイトをRapidWeaver 5.1へアップデートしてみた。
単純に更新しただけなので、不具合発生の可能性はあり。
5.1からようやく日本語リソースがついたようだが、あちこちに不備があって、メニューが読めないところさえもある。これじゃ英語版の方がよっぽどましじゃんとか思ってしまう。
この日本語の不備を修正する方法が「RapidWeaver 5.1完全日本語化プロジェクト」だけど、そもそもRealmac Softwareがこれ読んで直して欲しいなぁ。act2で販売している時からかなり怪しい日本語だったので、日本語対応にはあんまり力は入ってない様子。
単純に更新しただけなので、不具合発生の可能性はあり。
5.1からようやく日本語リソースがついたようだが、あちこちに不備があって、メニューが読めないところさえもある。これじゃ英語版の方がよっぽどましじゃんとか思ってしまう。
この日本語の不備を修正する方法が「RapidWeaver 5.1完全日本語化プロジェクト」だけど、そもそもRealmac Softwareがこれ読んで直して欲しいなぁ。act2で販売している時からかなり怪しい日本語だったので、日本語対応にはあんまり力は入ってない様子。
サイトアップデート:Qube 1.4
2011/02/20 22:30 Blog
RapidWeaverのテーマ、NimbleHostのQubeを最新の1.4にバージョンアップした。
最新のRapidWeaver 5に正式対応、HTML5のDOCTYPE、iPhoneおよびiPad対応強化の他、サイト管理者向けにはカスタマイズ項目がかなり増えた。CSSの構造やらが一部変更になってしまったので、旧版1.0のサイトイメージに戻すのにはちょっと骨が折れたなぁ。まぁおかげさまでMacやPCでの見栄えはほとんど変わらないと思うが、iPhone、iPadからは見やすくなっているのではなかろうか。
さて、次はRapidWeaver 5へのバージョンアップだな。
最新のRapidWeaver 5に正式対応、HTML5のDOCTYPE、iPhoneおよびiPad対応強化の他、サイト管理者向けにはカスタマイズ項目がかなり増えた。CSSの構造やらが一部変更になってしまったので、旧版1.0のサイトイメージに戻すのにはちょっと骨が折れたなぁ。まぁおかげさまでMacやPCでの見栄えはほとんど変わらないと思うが、iPhone、iPadからは見やすくなっているのではなかろうか。
さて、次はRapidWeaver 5へのバージョンアップだな。
Pocket Informantで１分単位の予定入力
2011/01/04 12:34 iPhone
設定の細やかさの一例として、スケジュールの時間設定が１分単位でできる点がある。
通常の会議やらの予定は５分単位で十分なんだが、出張や旅行の移動の際、電車の乗換え時間をあらかじめスケジュールに書き込んでおくと便利で、PalmOS時代からの習慣なのである。まぁ、日本の鉄道・バスでしか通用しない方法なのだが…
iOS標準のカレンダーも含めて、ほとんどのカレンダーアプリは５分単位の時間設定しかできない（さいすけは１分単位の時間入力可能）。１分単位の予定を入力するにはわざわざデスクトップ版アプリケーションか、デスクトップ版Webアプリを使う必要がある。Googleカレンダーでもモバイル版Webアプリは５分単位でしか入力できない。
Pocket Informantも初期版では５分単位だったが、最新版では１分単位での予定入力が可能になった。しかも新規予定を入力する場合は１分単位、編集する場合は５分単位と、インタフェースを使い分けている（下図）。使い勝手を悪くしないギリギリの線で留めているのだろうなぁ…
新規予定（１分単位）⇒
予定編集（５分単位）⇒
一方で、Pocket Informantの残念なところは、日本語版がないこととバグとおぼしき挙動が見受けられることだろう。設定項目がなにせたくさんあるので、日本語ヘルプが欲しい。バージョンアップも頻繁であり、どうしても細かい設定を見落としがちで、バグなのか仕様なのか分からないこともしばしば… それだけ、使い込みがいのあるアプリとも言えるのだが…
