Hexagon Technocrat 更新情報:2012年上半期

 
 

2012年06月

[2012.06.18]

確認の励行と連絡の徹底

Thunderbolt Software Update 1.2

上記標題は、かつて勤務していた某国営企業で安全綱領として叩き込まれた標語である。具体的には、指さし確認と呼ばれる「右よし、左よし」という実際に声に出して連呼する、最初はちょっと気恥ずかしい確認手順を始めとした、安全安心の基本理念である。

これを怠ったため、鼻骨骨折の憂き目に遭った体験を思い出してしまった。救急で運び込まれた病院で、鼻の穴に鉗子を突っ込まれてゴキッと音がするまで(骨折部位が正しく接合された証らしい)グリグリやられた苦い経験はあまり思い出したくないモノで、それ以来指さし確認の声もいっそう大きくなった。

のっけから余談であるが、どうやらアップルが、またもやチョンボをやらかしたらしい。

当方でも、件のアップデートは公開後早い段階で、旗艦の iMac と弐番艦である MacBook Air で実行したが、起動不可になるような重篤な影響は今のところ発生していない。

巷で(といっても、主にネット上の話だが)話題の「Thunderbolt Software Update」の件について、今回はアップルとしては珍しく、謝罪の意を表明しているらしい。

現時点では本国のサイト(もちろん英語だ)だけで、なんだけどね。

ニュースサイトやらそれに準ずるコミュニティサイト、またはその内容をコピペした個人のブログ等で話題になるぐらいだから、アップルにとって謝罪(apologizes)という言葉が、いかに異例であるかが窺い知れるというものだ。

で、どのような内容か早速アップルのサイトを訪問してみたが、目立つ所にはあるはずもなく、サポートページでも目視で発見することはできない。そこで「Thunderbolt Software Update 1.2」でサイト内検索をかけて、やっとサポート情報の一部として引っかかった。

内容としては、やれ TimeMachine のバックアップからアップデート以前に戻せとか、ターゲットモードで別の Mac で起動し 10.7.4 のコンボアップデートをかけろだの、およそちょっと慣れたユーザならこういう場合の対処法として考えそうなことが、簡潔に案内されているのみである。

ニュースサイト等が話題にしているのはどちらかと言えば以下の最後の一文であろう。(以下、引用)

Apple apologizes for the disruption this caused for customers with affected Macs.

「コイツのせいで、運悪く起動できなくなったマックユーザさん達ゴメンね。」というのが概要と思われるが、辞書を引くのも面倒なので、ネット翻訳をかけてみた。

だいたい趣旨としてはわかるのだが、やっぱちょっと変である。

[Google]Appleはこの影響を受けるのMacをお持ちのお客様のために引き起こされる混乱について謝罪。

「受けるのMac」というのがウケるよね。謝罪の対象はあくまでも混乱に対してのように見えるが、「お客様のために」の後に句点を入れたら意味は通ると思う。

[Exite]アップルは、これが影響を受けたマックと顧客のために引き起こした混乱について謝罪します。

エキサイトの場合は、「これが影響」という部分はいただけないが、見方によってはユーザのみでなく Mac に対しても謝罪しているようにも思えるのが、微笑ましい。

ここはヒトツ、

「アップルは、このアップデートによって引き起こされる混乱の影響を受けた Mac をお使いのお客様に対して、謝罪いたします。」

と、キメて欲しいところだが、"for" が二つも並んだら、たいていまともな文章に翻訳してはくれないところも、相変わらずである。

早晩対応策は講じられるものと信じるが、どうも最近のアップデートは迂闊にかけるとロクなことがない。やっぱ、ひと呼吸おいてが無難なようである。

しかし、先陣を切って人柱となることを生業にしている者にとっては、そういうわけにもいかない。願わくば、ちゃんと動作確認をやってから配布してよね、と言いたいところだ。

ま、今回は自分自身(と、その周り)がその影響を受けていないため、割と気楽に眺めている「Thunderbolt Software Update」事件をオカズにした、散漫なヒマネタでした。

…ということで、ヒトツよろしく。

[2012.06.14]

必要な変更なのか?

MagSafe 2

MagSafe は、MacBook シリーズ本体にパワーアダプタからのケーブルを、磁力によって吸着するタイプの電源コネクタである。

電気ポットなどの家電製品で多く採用されており、要するに電源ケーブルにけっぱんづいても簡単に外れて、熱湯を浴びるような悲惨な事故を防ぐ目的で開発されたのであろう。もちろん、Mac の場合は給湯機能を搭載された機種はまだないので、現時点では本体の落下による破損を未然に防ぐこと、が主目的である。

2006年1月、Macworld Expo で発表された MacBook Pro 15 [MA463-464J/A] に採用されたのが最初であり、今年でもうはや6年目になる。その MagSafe が、今回その形状を厚み方向で薄くなって MagSafe 2 と命名された。MacBook Pro 15 Retina ディスプレイモデルの筐体に合わせた変更であろうことは、容易に想像できる。

しかし、エッジ部分の薄さという点においては、それ以下である 2008年1月に発表された初代 MacBook Air では、その薄い筐体に接続するため、本体下面(斜下)に向けてかなりトリッキーな方法で装備されていた。実際に使ってみると結構使いづらく、置き方によっては本来の Safe の部分に関してかなりアヤシイ面があったことも否めない。


たぶん、ついでだろうが MacBook Air も 2012年モデルでは、2010-2011年モデルと外形寸法に全く違いが無いにもかかわらず、薄型の MagSafe 2 に変更された。後になって考えりゃあ、あのときこうしておけばと思うことはよくあるが、アップルの場合まいど「オラが規格」で新設計するんだからもう少し考えてからサイズを決めることもできたろう。今更であるが、2006 年の時点で MagSafe の高さ方向をせめて USB 程度に設計しておくべきだったろうという気もする。

いや、それよりも現時点であの程度のリサイズで十分なのだろうか、という心配も出てくる。どうせならもっと先を見越して、革命的な電源の取り方を採用しても良かったんではなかろうか…と。(特許まで取得して、サードパーティの参入を規制しているんだからね)

今回アップルとしては珍しく、[MD504ZM/A] MagSafe − MagSafe 2コンバータ(¥980)を同時発売して、旧タイプの MagSafe 電源を所有しているユーザにも配慮するという、小技も披露している点は評価できる。

加えて細かいところだが、MacBook Air シリーズに対しても従来本体側面に対して平行に配置された接点部分が、デビュー当時の MagSafe 電源のように直角に接続される形状に変更された。見た目は確かに平行が良いのだが、これも同様に Safe の部分が期待できなくなることに配慮した変更であろう。

また、同じく [MD463ZM/A] Thunderbolt ギガビットEthernet アダプタとThunderbolt FireWire 800 アダプタというものも発表されたが、現時点で後者の FireWire 800 アダプタは本国の Apple Store にも登録されていない。

どうせ Thunderbolt 絡みで出すなら Thunderbolt USB 3.0 アダプタというのも欲しい。できれば、Thunderbolt 1 Port の反対側にディスプレイポートやサウンド入出力も含めて全部入りがついてりゃ面倒がなくていい。かなりブサイクなデザインになるのは避けられまいが、せっかくのマルチインターフェイスである Thunderbolt も、それぐらいでないと同時に使えないからあまり意味がないと思う。ベルキンかグリフィンあたりで出してくれんかなあ…、余談である。

そんなことより気になるのは、今回の新製品で行われた、各ポートの名称がレタリングされた位置の変更である。



2010年モデルでは、各ポートのリアエンドよりに記載されていたレタリングが、すべてフロントエンド側に変更されている。単純に考えれば、ケーブルを差し込んだ時隠れて見えにくいから変更したんだろうと予想される。しかし、まさかこの2年の間、誰も気がつかなかったわけぢゃないだろうが、それなら前回の2011年モデルでは、なぜそのまま放置したのだろう。各方面からの賛否両論を上手くまとめることができなかったから、なんてことでなけりゃよいのだが。

だいたいポート(穴)の位置なんか差込む前には気にするが、ひっこ抜く時には誰も見やしないから、ケーブルに隠れて見にくいなんて文句いうヤツはまずいない。そんなことに突っ込みを入れるヤツいるとすれば、たぶん…。

だから、どうでもいいくだらないことなんだけど、こんな行き当たりばったりの対応を見るにつけ、最近のアップルにはこんな細部のダメ出しをする役回りの存在が欠けているようで、ちょっと気になった点である。

ま、過去には「逆さまアップルロゴ」の例もあることだし、細かいところにも気を配っているんだぞと、エラそうにフカしている割には、結構ヌケているところもあるアップル製品でした。

…ということで、ヒトツよろしく。

[2012.06.12]

WWDC 2012

アップル WWDC 2012 基調講演において新製品発表。

やはり、打上げ花火は 最上位の MacBook Pro 15.4 インチモデルのみで、後はクロックバンプを中心にした機能拡張に留まったようだ。たぶんコイツが従来の 17 インチモデルに替わって MacBook Pro シリーズ旗艦になるのだろう。

ま、あまり事を急いでもロクなことにならないだろうから、これはこれで正解なのかもしれない。

ただ、高価なモデルが高性能/高機能なのは当たり前である。

たしかに、15.4インチで 2,880×1,800 ピクセルというのは大したものだと思うが、解像度でいえば 220 ppi 程度でアップルのいう網膜(Retina)ディスプレイの基準もどんどん下がってきている。どうせやるなら13.3 インチで実現したらほんとにスゴイ、になっただろう。

ここ最近のアップル製品は、そこそこの価格でも結構な性能を実現してコストパフォーマンスに優れることが最大の魅力であったはずなのに、iMac シリーズのみが唯一その役割を担っているに過ぎない。

売れ筋の MacBook Air シリーズは前回魅力的な躍進を遂げたので、今回のマイナーアップデートは想定内であったのだが、MacBook Pro 13インチモデルの 1,280×800 という解像度は、いまさらどうよである。

IvyBridge がなんぼのモンかは知らないが、もはや MacBook Air (13.3 inch :1,440×900) はおろか iPad (9.7 inch : 2,048×1,536) にさえも引き離されてしまった感のある 13 インチモデルに対するテコ入れは必修と考えていただけに、そこはかとなくガッカリ感が漂う。

せめて、MacBook Air (11.6 inch :1366×768) を上回るスペックを奢ってもバチは当たるまい。いっそ、名前を MacBook に戻し価格を $1,000 以下に設定して、お勤め品の雄を目指すのならいざ知らず、そうでなければ Pro の名を与える意味はないと思うな。

また、今回会場では言及されていなかったようだが、個人的に最も期待するのは、2008年の 802.11n 以来久しくアップデートがなかった [MC414J/A] AirMac Express だ。

見た目は Apple TV を白くしただけのセルフパクリデザインだが、MacBook Air と同様に初代より革命的なアップデートを行われた Apple TV のデザインを有効活用した良い選択である。


デュアルバンド化はもちろん、Ethernet LAN ポートも追加され従来より格段に使い勝手が良くなっているように見える。ついでにギガビットまで実現してくれたら完璧だったのだが、兄貴分である AirMac Extreme の立場もあるんで、そのへんは大人の事情に配慮して…、というところかな。

その他の新製品についても、おいおいに明らかになると思われるが、取り急ぎ WWDC 2012 における発表に対する感想まで。
[AM 04:30]

…ということで、今月もヒトツよろしく。

2012年06月某日 Hexagon/Okayama, Japan

2012年05月

[2012.05.23]

iCloudの要件が満たされていない場合でも?

iCloudの要件が満たされていない場合でも、メールは iCloud へ移行できるようになりました。

すでに相当な日数が経過してしまったので、いまさらな旧聞かもしれないが、前回の独断による iCloud 移行手順のまとめ的なモノを書いているウラでアップルは密かに(でもないけど)、救済措置を実施していたようだ。

それが、標題の「iCloudの要件が満たされていない場合でも、メールは iCloud へ移行できるようになりました。」である。


iCloudへの移行
http://www.apple.com/jp/mobileme/transition.html

以下、引用:--------------------------------------------------------
すべてのデバイスでEメールだけを使い続けたい場合は?

MobileMeが終了した後、iCloudのシステム条件を満たさないデバイスでも引き続きEメールを使うことができるオプションを選べます(5月1日現在)。me.com/moveにアクセスして、MobileMeの終了後もEメールを使い続けるオプションを選択してください。この簡単な準備をするだけで、2012年6月30日にMobileMeが終了した後も、iCloudのシステム条件を満たしていないデバイス上でEメールを使い続けることができるようになります。
-------------------------------------------------------------------------

ここでは(5月1日現在)というところがミソで、いくら…なりましたァ♪、と明るく言われても参るよな。

あらかた移行作業が終わったこともあり、仕様変更に気付くまで概ね3週間近くを要したことは、我身の不徳の致すところではある。

要するに、昨年6月の iCloud 発表以来 4月31日 4月30日までは iCloud に移行しないのはユーザの勝手なんだから知らねえよ、という態度であったわけで(少なくともユーザサイドからはそう見える)、移行作業に伴う不可解な挙動もある意味アップルの準備不足が原因であったに違いない。

(訂正:4月31日→5月1日に対する皮肉を込めたつもりだったが、あまり通じそうにないので素直に訂正)

現実に、システム環境設定内に MobileMe はおろか .Mac しか存在しない 10.4.11 (Tiger) がインストールされた PowerBook で移行してみた。前述の「iCloudの要件が満たされていない場合」のオプションを選択すると、何の変更も無しに使用できる。Tiger の場合、送受信サーバのデフォは「smtp.mac.com & mail.mac.com」であり、「xxx.me.com」ですらない。

前回までアカウント設定に際してトラブった送受信サーバの問題などはいったい何だったのか、と思えるほどあっけなく終わる。いや、実際には何も始まってもいないのだろう。


この手続き自体、アップルに対して 6月30日以降もアカウントを継続使用する決意表明を行ったに過ぎない。所謂 iCloud 移行予約みたいなモノで、当然 iCloud のサイト(https://www.icloud.com/)に行っても、このアカウントでは入れてもらえない。旧来の MobileMe のサイトに跳ね返されるだけで、門前払いである。

実際に MobileMe が完全終了してみないとわからないのであくまでも可能性の話だが、もしこのままスノレパ以前のシステムにおいて、移行前の設定に何の変更もなく使用できるのであれば、アップル側のサーバ管理方法に互換性維持に対する対策が行われたと考えられる。

しかし、7月1日になってまたもやメール設定のやり直しを強いられるのなら、問題を先送りにしているだけで、あまり意味は無い措置なのかもしれない。

また新たな懸念材料として考えられるのは、先々 iCloudの要件が満たされた次点でフルセットのアカウントに移行することが可能なのかどうかである。まさか、以前のメール専用アカウントのような扱いでは無いと信じるが、現時点では少なくとも「今すぐ移行」というオプションは残されている。

が、はたしてこの救済措置は、いつまで有効期限があるのかは明確になっていない。

昨年の iCloud 発表時には、新しい機能のウリ部分ばかりが強調され、失われる機能についてはそのユーザ数が少ないという前提で行われた感があるのは否めない。その機能を使用しているユーザにとっては、切実な問題であるはずなのだが、もともとそれほど面倒見がよい会社でもないので期待するのが間違いであることは承知の上で、あえていまさらの苦言を呈する。

iCloudへの移行により失われる機能

iWeb 公開領域:

これは後述の iDisk とも関連する項目であるが、有料オプションなどで領域を確保さえ出来れば FTP サーバの提供など、さほど技術的に困難なサービスでも無いように思われるが、なぜ廃止という極端な方法しか採れなかったのだろう。

ギャラリー:

もともと Mac OS X 標準の iLife に含まれる iPhoto 関連の機能であり、iWeb と並んで有料化された MobileMe の最大のウリであったはずのサービスである。いつのまにか iWeb は出来の悪いまま iLife ファミリーから外され、iPhoto は旧 Mac OS X ユーザに対して有料化されてしまった経緯がある。その有料版まで購入してアップグレードしてきたユーザにとっては、詐欺にあったような印象さえ受ける。

確かに現在においては、有料・無料(有象無象といってもいい)ウェブ公開アルバムのサービスは数多あるが、日本語化する気もまるでなさそうな Flickr を標準サポートした程度でお茶を濁そうとする態度には少々ムカつく。曾ての iCard や Home Page などの、一般ユーザに喜ばれそうなお手軽サービスさえも早々に辞めてしまうのは、いったいどういう了見なのだろう。

iDisk:

昨今、Dropbox などのサードパーティのサービスで代行できるものの筆頭かもしれないので、一番影響は少ないように思われる。確かに、死ぬほど遅い巨大フロッピーディスクと揶揄されることの多かった iDisk であるが、なぜアップルでは iDisk を Dropbox のように快適に使用できる環境にアップグレード出来なかったのだろう。

iOS 機器などの併用では iDisk など足下にも及ばないほど、快適な環境が提供されることに対して感心もするが、なぜアップルには iCloud でそれが実現できなかったのだろう。というより、iCloud でこそ実現すべき最大の機能であったはずである。

これが実現できたなら、上記2点は廃止することもなくおのずと解決できただろうし、結果失うものは何も無かったはずだ。

自社内で実現できないなら、Dropbox その物を丸ごと買収するという手もあっただろう。スティーブの健康問題やらで何かと混乱を極めた時期であったことは想像できるが、2011年8月時点で50億ドル程度の企業ならアップルにとって容易いことだったに違いない。

ま、事を起こすつもりならもっと以前に、それこそ iCloud の構想段階で動いておくべきことではあるが…。

「ご近所の皆さまへ...」新本社屋についてAppleからお手紙が届きました。
http://www.gizmodo.jp/2012/05/apple_36_20120522.html

上記リンク先にあるギズモの記事によると、アップル新社屋建設に関して地元に配布された資料には、1万3千人もの従業員が本来ならその地域に及ぼすはずのプラスの経済効果さえもアップル内部に吸収してしまう旨が説明されているらしい。

あくまでも、ギズモの見解を信じるならという条件は付くが、これなどどう考えてもあきれた暴挙といえよう。

「敷地内にジムやレストラン等の施設を併設し、周辺のお店や道がApple社員のせいで込み合わないような配慮」というのは、地元にとってされて有難いものなのだろうか?

社内施設の一般公開のないことを心配するより、もっと別の視点で評されるべき話題のような気がするのだが。

で、常々持ち上がる疑念、「ほんまにアップルの連中は賢いのか?」、「先見の明を持ち合わせたリーダーは、存在するのか?」の要因がこのあたりにわき出てくるのだ。

MobileMe データのバックアップ方法のページの最下行に、保険屋の定款よろしく読めないほどの小さい文字で書かれている文章によく表われているように思う。

自ら自信と責任を持って提供するサービスが無いと、如何に言い分けがましく、他力本願的な逃げ口上に見えることか。

MobileMe データのバックアップ方法
http://support.apple.com/kb/HT1813?viewlocale=ja_JP

以下、引用:--------------------------------------------------------
重要:他社の Web サイトや製品に関する記述は、情報提供のみを目的としており、支持または推奨を意味するものではありません。Apple は、他社の Web サイトに掲載されている情報または製品の選択、性能、使用については、一切責任を負いません。Apple は、これらの情報を、ユーザの利便性を考慮して提供しているに過ぎません。Apple では、これらのサイトに掲載されている情報の評価を行っておらず、その正確性または信頼性についてはいかなる言及もいたしません。インターネット上のあらゆる情報または製品の使用には本来リスクが伴うものであり、この点について Apple はいかなる責任も負わないものとします。他社のサイトは Apple とは無関係であり、他社の Web サイトの内容を Apple が管理しているわけではないことをご理解ください。詳細については、「ベンダーに関する情報を見つける」を参照してください。
-------------------------------------------------------------------------
[上記要約]
  ○ 本来リスクが伴うものであり、Apple とは無関係で推奨を意味するものではなく、いかなる言及もいたしませんので、一切責任を負わないことをご理解ください。 詳細については、5番の窓口へ…。ハイ、次の方。


[2012.05.10]

OS X Lion アップデート 10.7.4 (Build 11E53)

かねてより評判の悪かった「再ログイン時にウィンドウを再度開く」が、ようやく修正された。

改善項目の筆頭に件の修正点が表記されていたので、アップデート後どのようなオプション設定が追加されたのかと「システム環境設定」内の該当項目を探してみたが、それらしいものは発見できなかった。

ただ、よく調べて見ると特別な追加オプション(選択項目)で実現したわけではなく、前回チェックが入っていれば従来どおりに、一度チェックを外したら次回からチュックボックスは未設定になるという、非常にスマートなやり方で実現されている。

これなら、ウィンドウを再度開いてくれた方が良いと考えるユーザも、いやいやあれは鬱陶しいだろうと嫌悪感を示すユーザも、両方満足させる上手いやり方である。


シロウト考えでは、てっきり何らかのオプションで選択させるものと思い込んでいただけに、あのようなシンプルな方法で実現されると、やっぱアップルの連中は賢いのかなと関心する一方で、しかしそれならなんで最初からそうしておかなかったのか、という疑問もわいてくる。

たしかにアップルサイドに立って考えれば、「再ログイン時に…」に関しては、一般ユーザに極力負担をかけまいとする配慮からあえて選択肢を削り、よりシンプルな操作性実現が最優先事項であるという理由づけも納得できないわけではない。

しかし、ある程度 Mac に慣れたユーザからすれば、せめてイースターエッグ的なモノでもよいから、それがオフにできる機能も用意しておくべきだろうと考える。問題はその機能を隅々まで探す手間は厭わないユーザに対しても、全く門戸を閉ざすやり方だ。

ちょっとググればリスキーな荒療治も含めて情報は数多あるが、やたらターミナルから須藤さんに頼る方法は Mac らしくないし、より安全な方法でカスタマイズ可能な逃げ道を作っておいて欲しかった機能でもある。

個人的に好んで常用している TinkerTool というフリーウェアがあって、OS の隠された機能を設定することができる非常に便利なツールなのだが、コイツの最新版にも「再ログイン時に…」に関するオプションは無かった。

ドザから信者と揶揄される妄信的なアップルスキーな連中は、ユーザサイドに立って要望の多いものから徐々に実現していくという、アップル的な計算されたやり方だと擁護する意見もある。しかし、前述のスマートな実現方法は、OS の隠された機能にも無いところを見ると、あらかじめ用意されていたモノではなかったに違いない。

どうも最近のアップルを見るにつけ、たしかに賢いしやればデキる子なのだが、中々ヤル気を起こさせるのが難しい問題児のように思えてならない。

だいたいにおいてアップルは、昔からユーザに選択肢を与えず、身勝手で上から目線でエラそうな態度が鼻に付いて…、いやまあここはヒトツ素直に喜んでおこう。文句を言い出したらキリがないからな。

それはそうと前回、iCloud 移行前にパスワードの変更をしておいた方が良いという趣旨の文章を書いたが、その変更方法が以前と(というより状況によりかな?)変わっているようなので補足しておく。

5月10日現在の正しい変更方法は、パスワードリセットを行うことが推奨されている。

Apple ID のパスワードを変更する方法:
http://support.apple.com/kb/HE36?viewlocale=ja_JP

MobileMe からまだ移行していないユーザは、MobileMe ログインページから入って、アカウントへアクセスしてサイドバーの「パスワードの設定」を選択して変更というのが従来からのやり方であったはずだが、最近は以下のような訳の分からんメーッセージが表示されて、行き詰まってしまう。

以下引用:
パスワードまたはセキュリティに関する情報を変更するには、 へアクセスしてください。(原文のまま)

「へアクセス」とはいったいなんぞや? …と、思うかもしれないが、たぶん何らかの文字列が挿入されて、文章を構成するのだろう。

おそらく、「へ」の前には「My Apple ID」のリンク先あたりが表示されるのがスジであるが、ここしばらくはずっと上記のマヌケな文面が表示されるのみである。

ところが、「My Apple ID」へ行ってパスワードを変更しようとしても、ここでもまた訳の分からん状況に遭遇する。変更後に何度保存ボタンを押しても、別の設定項目に移動しようとすると「変更内容を保存しますか?」というメッセージが表示され続ける。


もちろん、このメッセージの「変更内容を保存」というボタンをたぶん百回クリックしても結果は同じであり(39回まではやってみたけど)、一度サインアウトして再度サインインしようとしても、新たに設定したパスワードは有効になっていない。

で、結局パスワードリセットを行うしか手がないのである。

ただ、以前  MobileMe メール専用アカウントから移行したアカウントでは、「My Apple ID」で変更した記憶があり、いつの時点からできなくなったのかは全く不明で、気まぐれなアップルの仕様変更と半ばあきらめている。

これは、全くの憶測であり個人的な想像だが、どうもアカウント(メアド?)が @mac.com と @me.com の違いによっても発生している不整合性のような気がしてならない。

Apple ID に関してよくお問い合わせいただく質問のページ(http://support.apple.com/kb/HE37?viewlocale=ja_JP)にも、両者は同等の扱いである旨が書かれている。

以下引用:
<これまでの mac.com の ID を Apple ID として使うことはできますか?

2008 年 7 月 11 日以前に .Mac にサインアップし、それ以降も有効なアカウントをお持ちであった場合は、iTunes Store やオンラインの Apple Store での購入時、および iPhoto や Aperture で作成した Apple プリント製品の購入時に、その mac.com の ID を Apple ID としてお使いいただくことができます。mac.com や新しい me.com の ID (どちらの ID でも同じアカウントにアクセスします) は引き続き Apple ID としてお使いになれます。

注意:MobileMe や .Mac アカウントの有効期限が切れている場合は、Apple ID に関連付けられているメールアドレスを変更する必要があります。詳しくはこちらの記事を参照してください。
(リンク:
http://support.apple.com/kb/HT2968?viewlocale=ja_JP)>

が、コイツが当てにならない。

当該のリンク先にも「Chat アカウントについて」の追加情報があり、

以下引用:
<MobileMe iChat アカウントは、アカウントの期限が切れると、作成日に応じて、動作が異なります。通常、2008 年 7 月 9 日以降に作成された MobileMe iChat アカウントは、MobileMe アカウントの期限が切れると、無効になります。2008 年 7 月 9 日より前に作成された古い .Mac iChat アカウントは、MobileMe アカウントの状態にかかわらず、引き続き有効です。>

と、いうことになっているらしいが、ここにも明らかな矛盾点がある。

○2008 年 7 月 11 日以前に .Mac にサインアップし…

□2008 年 7 月 9 日より前に作成された古い .Mac iChat アカウントは、…

と、2008 年 7 月 10 日にアカウントを作成したユーザが頭を抱えてしまう文章が記載されている。

当初、原文(たぶん英語)翻訳の段階で発生した時差の問題かとも思ったが、少なくともこの地球上ではその自転周期から考えても、2日以上時差のある地域は存在しないハズだ。

以上のように、移行に関するトラブルは枚挙に暇がない。

強いて言うなら、.Mac から MobileMe サービス移行時の最も余計なお世話である、 @mac.com → @me.com 変更が今になっても尾を引いているのではあるまいか。(MobileMe の怨念か?)

生前スティーブは、iCloud では MobileMe のサービス開始時のようなお粗末な対応はしないと豪語していた、と記憶している。

もし墓参りに行けるチャンスがあれば、いやいやそれに劣るとも勝らん程度には結構バタバタしておりまっせ、と報告してやろう。

…ということで、今月もヒトツよろしく。

2012年05月某日 Hexagon/Okayama, Japan

2012年04月

[2012.04.29]

iCloud のメール

仕事柄、iCloud 移行に伴う雑事で忙殺されて、ココの更新もままならない状態が続いている。

iWeb 絡みのウェブホスティングの問題はそう簡単には解決できないので、もともと長期戦の構えではあったのだが、iCloud アカウントへの移行はそれほど難儀をするとも考えていなかったので、先月来メールに関連するトラブル解消に奔走させられている現状は予想外である。

業務や使用アプリの関係もあって、おいそれとはライヨンにアップデートできない、またはしたくないユーザは結構な数にのぼる。また、そういったユーザほど iCloud への移行はギリギリまで待ってからと考えがちなのは、致し方の無いところだろう。

トラブルの大半は、MobileMe から iCloud へアカウント移行するとメールがコケるというものだ。いや、もちろんコケない場合もあるのだが、だいたいはコケる。

ライヨンの場合はまず問題ないのだが、それ以前のシステムではかなりの確率でうまくいかない。たいていは、送受信サーバがパスワードを拒否というパターンが多いのだが、その対策はシステム環境によって微妙に異なる。

ま、全組合わせを厳密に精査したわけではないので適当な推測に基づいている点も多々あるが、ある程度こうやれば上手くいくハズ的な対処法がかすかに見えてきたので、覚書のつもりで書いている。

Tiger (10.4.11)、Leopard (10.5.8)、Snow Leopard (10.6.8) などで、MobileMe から iCloud へ移行したアカウントでは、それまで正常に送受信できていたメールが前述のパスワード拒否で使えなくなることが多い。

で、いろいろやってみた結果から、その対策について。

IMAP サーバの場合、メールデータは全てサーバにあるので、それまでに使用していた機器から環境を移す必要はない。全くに新規に設定しても正常に設定が終われば、従来の環境がそのまま再現され便利である。

が、その設定が iCloud に対する設定項目のない旧システムでは、まともなアプローチではたいてい正常に終わらない。そこで、まともではない(わけでもないが)アプローチを試してみることにより、かなりの確率でうまくいく。

其の壱:MobileMe アカウントを iCloud へ移行する前に My Apple ID へ行って、Apple ID が主要メールアドレスになっていることを確認する。MobileMe 以前の @mac.com のアドレスを使用しているユーザは、Apple ID もそれに揃えていた方が、あとあと面倒がない。

其の弐:8文字以下のいい加減なパスワードを設定していたユーザは思い切って、パスワードを変更する。英数大小文字を含んでいて連続3文字以上同じでなければたいていは通る。

以上2点は、メール専用アカウントから iCloud へ移行するユーザには必修といってもいい儀式であり、其の弐のパスワード変更は、8文字以下のパスワードを設定していなかったユーザも、このさい心機一転新しいパスワードを設定することだ。(←ココ重要ね)

実際、同じスノレパでもかたや何も変更しなくても送受信おけ〜もあれば、なにをやっても送信はおろか受信さえも絶対にできない、というパターンもある。どちらのアカウントも同じパスワードを設定しているにもかかわらず、一方だけは受信サーバがパスワードを拒否という壺から抜け出せないという状況なのだが、結局パスワードを変更したら、それだけでウソのように正常動作に復帰した。

ついでにいえば、事前にソフトウェアアップデートを行い、現状のバージョンで最上位に更新しておくことも重要だ。

  1. Mac OS X 10.6.8  Build 10K549 -Snow Leopard

  2. Mac OS X 10.5.8  Build 9L31a  -Leopard

  3. Mac OS X 10.4.11 Build 8S165  -Tiger

  4. Mac OS X 10.3.9  Build 7W98,  -Panther, ... ect.

スノレパユーザは、運が良ければこれだけでメール設定は何の変更もなくそのまま使える。もちろんパスワードは送受信とも新しいのに入れ替える必要はある。

運の悪いスノレパユーザおよびタイガー以前のユーザは、もう一工夫が必要になるが、パンサーおよびジャガーユーザはこの際思い切って最新型に買い替えよう。そうすれば、こんな苦労は全くする必要がない。

.Mac、から MobileMe になったとき、受信サーバはそれまでの mail.mac.com から mail.me.com に変更になった。今回の iCloud では imap.mail.me.com に変更しなければならない、ということになっているらしい。が、必ずしも絶対ではないところが厄介の種。

運の良いスノレパユーザが、なぜ mail.me.com のままで正常に受信できるのかは未だ謎であるが、できないものはウダウダいっても始まらないので、素直に変更しよう。といっても、MobileMe アカウントの場合そのままでは受信サーバ名は変更できないので、一度アカウントをマイナスボタンで削除し作り直す必要がある。

前述のように IMAP アカウントで設定していれば、削除しても再登録で復活するからなにも問題はないが、POP アカウントとして登録していたユーザは設定によってはメールデータがすでにサーバから削除されている可能性もあるので、メールフォルダのバックアップをとってからやった方がよい。

また、アカウントを作り直す場合も @mac.com および @me.com のアドレスは、そのままでは MobileMe アカウントとして認識されて自動設定により変更不可になってしまう。そこで、MobileMe ではなく IMAP として設定変更する必要がある。それにより、受信サーバの名称変更が可能になる。

IMAP への設定変更ができないバージョンの裏技として、ネット接続を切ってわざと設定エラーを起こさせて設定変更とか、とりあえずウソッパチなメアドを入れておいて、後から正しいメアドに変更などというのもある。

アップルのサポートサイトでも情報が交錯し、
  受信サーバ:mail.me.com、imap.mail.me.com
  送信サーバ:smtp.me.com、smtp.mail.me.com

など、サーバ名だけでも複数存在し、ハッキリこれが正解というのは現在のところ無い。

また、一時的に受信できたからといって安心はできない。翌日になって、パスワード拒否されて設定をやり直した例もあるぐらいだ。

ライヨンでは、受信サーバの頭に p99-imap とか p02-imap などが自動設定されている場合もあるが、これを真に受けてマネしても、スノレパ以前のシステムではたいてい蹴られるので、バージョンが違うとあまり参考にはならない。

受信サーバの設定が運良くうまくいって、正常に受信が確認できたら次に送信サーバの設定である。

送信サーバのアカウント名は通常 @ より左側のユーザ名を設定するのだが、アップルのサポートサイトでは @ 以降を含めたはメアドを入れよと案内されている。しかし、メアドを設定してうまく送信できる場合は、ユーザ名だけでも送信はできる場合が多いので、これとてかなり怪しい情報だろう。

確実なのは、SSL ON Port 587 ぐらいだが、べつにSSL OFF Port 25 でも送信はできる。ただし、プロバイダのスパム対策等により、相手が受信してくれるかどうかは甚だ疑問だが…。

ようするに、ライヨン以外では各ユーザの環境により、コケ方もその対処法としての設定の仕方が多彩に変化する。

それは以前に設定したパスワードや、@mac.com および @me.com のいずれが Apple ID に登録されているか、移行する以前のアカウントがメール専用か正規アカウントか、またはそのアカウントを取得した時期など、あらゆる要素が絡んでくる。

したがって、ちょっとググったぐらいの情報では自分の設定環境にとって正解にブチ当たる確率はそれほど高くない。うまくいくヤツはいくし、いかないヤツはどうやってもいかない。少なくとも現状では、正しい設定というのは、とりあえず動作するというのも含めると複数あるようだ。

それでも、ムリヤリ基本的な設定手順の要点をまとめると以下のようになる。少なくとも、下記要点の1.2.を事前にやっておけば割とすんなり完了するはずだ。

<iCloud メール設定手順:スノレパ・レパード・タイガーなど>

1.My Apple ID:Apple ID の確認
  主要メールアドレスを設定(xxx@mac.com or xxx@me.com)

2.My Apple ID:パスワードに変更
  英数大小文字を含んだ8文字以上

3.MobileMe:iCloud アカウントへ移行

4.メールを起動し、送受信確認
  何も問題がなければメデタシだが、しばらく様子を見よう
  即座にパスワード拒否されたら、あわてず5へ

5.IMAP メールとして再設定

メール設定項目
  ○メールアドレス:xxx@mac.com (or xxx@me.com)
  ○ユーザ名:xxx
  ○受信サーバ:imap.mail.me.com (or mail.me.com)
   認証:パスワード (SSL=ON, Port 993)
  ○送信サーバ:smtp.me.com
   認証:パスワード (SSL=ON, Port 587)

また、すでに設定済みでパスワードを拒否される場合も、各項目が正しく設定されていれば、やおら My Apple ID へ行ってパスワードを変更してからメール設定に再度入れ直すことにより、正常に送受信できるようになる場合もある。

たかがメールされどメールであるが、こんなばかばかしいトラブルでユーザを失うことぐらいアホらしいことはない。

第一の問題は、iCloud へ移行したアカウントもスノレパ以前のシステムでは MobileMe アカウントであると見做されることであり、これはもうアップルの問題といってもよい。

スノレパ以前のシステムに対して、システム環境設定の iCloud やメール/連絡先/カレンダーの設定項目程度はアップデータやインストーラで対応できるはずなのにこれをやらないことが、問題を深刻化させていることに他ならない。

次にユーザの問題、といっても半分はアップルの問題でもあるんだが、iTools、.Mac、MobileMe 時代を通して、いい加減なパスワードを設定していたことが尾を引いて、不可解なパスワード拒否現象を引き起こしている可能性があることだ。

ただ、ユーザが任意で決めて嘗てアップルもそれを一度は認めたんだから、いまさらセキュリティレベルを口実に上から目線で一方的に拒否というエラそうな態度は、如何なものかと思う。

10.7 以上の Mac OS X、Intel Core 2 Duo 以降の Mac、iOS 5 以降のモバイル機器を持たないユーザに対する制裁措置であり、イヂメでもある。

いくら iOS 機器をコマセに潜在的次期マックユーザをかき集めようが、旧来のユーザに対して余計な手間を強いたり、サポートを犠牲にしていたのでは意味がないだろう。

毎度々々、いい加減な手抜きアップデートを改めりゃいいのに…、まさか山猫でも、こんなことをくりかえすつもりなのだろうか?。

アップルの連中が巷で言われるほど本当に賢いなら、こんなアホらしくスマートでないやり方はしないと思うな。

…ということで、来月もヒトツよろしく。

2012年04月某日 Hexagon/Okayama, Japan


2012年03月

[2012.03.08]

新しい iPad と Apple TV を発表

新しい iPad の名称は、”iPad 2S” でも “iPad 3” でも “iPad HD” でもなく、なんと「新しい iPad」である。

ちゃんちゃん。

しかし、初代が iPad で2代目が iPad2。で、今回の新しい iPad が「新しい iPad」なんだが、次のモデルの発表の時にはいったいどうするんだろう?

たぶん「より新しい iPad」か?それとも「最も新しい iPad」?

その時には、今回の「新しい iPad」は「かつての新しい iPad」とかに改名されるのだろうか?

今から、次期モデルの発表イベントが楽しみである。

肝心のスペックに関しては、価格も含めて事前に期待をもって噂された通りであり、その名称以外は大きくハズした部分もなさそうだ。ただ残念ながら、やはり iPad には「Siri」の搭載は見送られたようで、iPhone 4S のみの対応という点も想定内である。

iOS も ver. 5.1 の配布が開始された。お約束の日本語化された「Siri = Kyoko?」が搭載され、相変わらずのたどたどしくも色気の無い発音で、情報を提供してくれるようになった。

ま、無骨な男の声にならなかっただけマシというものだが、そのうちプロの声優でも起用して「Siri Pack 日本語版」みたいなものを販売したらウケそうである。これは全くの私見ではあるが、戦場ケ原ひたぎのツンデレ版あたりなら、たぶんポチってしまうだろうな。

iOS 5.1 に関しては問題なくアップデートできたのだが、午前6時半の時点ではアップルストアのサーバがコケているようで、予約注文はできなかった。だぶん、原因は想定を超えたアクセスにより処理しきれないという、おなじみのトラブルなのだろう。

だが、案の定 iPad 版のミュージックアプリは全く改善されず、デキの悪いまま放置されている。おそらくアップルとしては、とりあえず動作はしているもの(it just works)に対して、まったく問題意識などないのだろう。

今回の発表に合わせて、数多くの iOS アプリもアップデート版の提供が開始されているようだが、iOS ばかりがどんどん先へ進んでいるのに、今年の夏が過ぎるまで Mac ユーザは、その対応を待たされるのかと思うと、複雑な気分である。

メモやリマインダぐらいソフトウェアアップデートでさっさと対応しやがれ、と思っているマカは少なくないと思うな。

そういえば、今回のイベントではスコットもジョニーも登場しなかったようだが、いったい何が…?。

…ということで、今月もヒトツよろしく。

2012年03月某日 Hexagon/Okayama, Japan


2012年02月

[2012.02.20]

ライヨン、いろいろな順序

ファイルの表示順序に関して数多くの機能が盛り込まれたライヨンであるが、どれひとつとしてまともに使えるものがない。

たとえば、ファインダ上でフォルダやら書類やらが混在するウィンドウを開いたとする。

表示オプションを選んで、
  ○アイコン表示でブラウズ
  ○並び順序:なし
  ○表示順序:種類

上記のように設定した時の並び方は、表示メニューから整頓順序:種類(またはオプ+コマ+2)を選択した時の並び方と全く異なる。(このオプ+コマ+2も、なぜかときどき効かなくなることがある)

スノレパまでは、その両者は一致していたはずだ。たしかに、ショートカットはコマ+コン+5という違いはあるものの、機能としては全く同じはずなのに、である。

同じ階層を別ウィンドウで開いて、リスト表示を選択してみるとよくわかるが、種類でのソート順が全く逆なのである。これは、果たしてバグなのかそれとも仕様なのか?

ま、以前からリスト表示の種類順なんぞは、ファイル種別で並べてくれるつもりはさらさら無いようで、単なる適当に命名した種別名順に過ぎないのだが。

日本語ローカライズ担当者の種別名の付け方がいい加減なおかげで、同じイメージファイルでも JPG と PNG では、生き別れになってしまう。原因はJとPの間に、Microsoft Excel や Numbers の書類が割込むからであり、当然テキストクリッピングと標準テキストの間には、書類でも何でもないフォルダが並ぶという、かなりムチャクチャな順番である。

姓名が日本とは逆の西洋人だって、ファミリーネーム順に並べたい時は “Jobs, Steve” というような記述をすることだってある。

日本人なら誰でも知っていると思うが、文字コード順に並べりゃ数字やアルファベットは、漢字(全角文字)より頭にくるのは常識である。 ファイル種別名順ではなく、ファイル種別順に並べる気が本当にあるなら、日本語化するとき種別名の付け方にひと工夫することぐらいは、どんなバカでも思いつくだろう。

それを念頭において、たとえば以下のように。

  ○イメージ(JPG)            ←JPG イメージ
  ○イメージ(PNG)           ← PNG イメージ
  ○テキストクリッピング
  ○テキスト(rich-text)        ←リッチテキストフォーマット
  ○テキスト(plain-text)       ←標準テキスト
  ○フォルダ
  ○書類(Microsoft Excel) ← Microsoft Excel 書類
  ○書類(Numbers)           ← Numbers 書類

こんな単純な問題を、姑息にも「並び順序」やら「並べ替えボタン」などという機能の追加で解決を図ろうとするのは、新たな混乱を増やすだけである。

ソート順序に関しては、iTunes においても不可解なことが多い。

ファインダのリスト表示では一番上に並ぶはずの数字で始まるタイトルは、iTunes では曲名で昇順を選択するとなぜか一番下に並ぶ。

iOS のミュージックアプリではもっと酷い。なんと平仮名とカタカナがトップで、数字はアルファベットの後、漢字の前という訳の解らない並びになる。

よくもまあ、そんな奇っ怪極まりないソートを実現するアルゴリズムを考えついたものだと、関心するばかりである。

いいかげん余計な機能を増やすよりは、基本機能がまともな動作をすることに注力してくれたほうがはるかに有難いのだが、はたして山獅子ではそれが改善されるのか、それとももっと混沌の世界へ突入するのだろうか?

願わくば、iOS との統合(整合性)を図る過程で、これ以上 Mac OS にそのようなゲテモノを持ち込まないで欲しいものだ。

フィードバック済み)


[2012.02.17]
[02/20:追記]
ライヨン、山に登る?

今年の夏の終わり頃にはリリースされるらしいが、OS X Mountain Lion (10.8) だそうな。

昨年7月のライヨン騒ぎからわずか1年でのメジャーアップデートである。

デベロッパプレビューのリリースを見るにつけ、iOS とのスリ合わせが主目的のようにしか見えない。なぜこれをメジャーアップデートとして位置づけるのかわからないんだが、どうもアップルはスノレパを早く切捨てたいようだ。

前回、セキュリティーアップデートでやらかしたチョンボを二度と繰り返さないためには、合法的(といってもローカルルールだけどね)にスノレパ、ひいてはロゼッタ環境をサポート対象から外そうという荒療治に出たわけだ。

…と、つい僻んだ見方をしたくなるが、要するに iOS ディバイスで拡大したモバイル市場のユーザを一気に網にかける作戦なんだろう。(さずがはクックさん、商売人やのう)

しかし、旧来のユーザにしてみれば迷惑な話ではある。

まあ、6月までにはライヨンへアップデートせにゃいかんよなあ、などとのんびり構えていた御仁にとっては寝耳に水であり、おいおいちょっと飛ばし過ぎだろうという気がしないでもない。

だいたい百獣の王の名を冠した OS を、そんな短命で終わらせるのはライヨンさんに対しても失礼だろうし、しょっちゅう名前を変えるのも使い捨てっぽくていい気分はしない。

同期可能なメモやリマインダーごとき、屋台骨から更新しないと実現出来ないほど大仰なアプリとも思えないんだが…、現にメーッセージはベータ版として iChat のリプレイスで配布しているしね。

結局のところ、ライヨン自体世界中を巻き込んだ壮大なベータテスト版だった、ということなんだろうか?

個人的には、それで Mac ユーザが増えるのなら別にかまやしないが、こんなご時世なんだから、もう少しユーザ環境にも配慮した方が良かろうと思う。資源のリサイクルというか、ユーザ資産の有効活用という点においても、せめて自分とこで開発・販売した旧アプリのデータ変換や、読込みができる程度の機能ぐらいは、最新版のアプリに搭載してからやって欲しいな。

前回は250、今回も100と数多くの新機能を謳うメジャーアップデートらいしが、機能ばかり多くしてライヨン山に登る、てなことにならねばよいが…と、思う。


[2012.02.16]

Web Server 移行 Part 3

モノはついでとばかりに、COSMOS M&S のネットワークもフレッツ光プレミアムからフレッツ光ネクストに移行。

プレミアムも、速度自体にさほど不満があったわけではない。

しかし、プレミアムのおバカな特殊仕様のため MTU サイズ(1,438バイト)の指定を変更しないと CTU をパスできなかったり、CTU を使えば使ったでダブル NAT になったり、内部ローカルサーバへインターネット越しにアクセスできなかったり、とか実は開設当初からありとあらゆる問題があったわけで、決して好きでたまらないわけではなかった。

外部のウェブホスティングを使用する限りはそれも我慢の範囲だが、社内サーバを構築するにあたり、これぢゃあマズイよなあ。

てなわけで、必然的に IP アドレスは変更になり、面倒な DNS 設定をやりなおす羽目になることを覚悟でネクストに移行した。

ちなみに、フレッツ光ネクストの MTU 値はBフレッツと同様に1,454バイトで、PPPoE 接続。邪魔臭い ONU、CTU、ひかり電話用VoIPアダプタが一体型になっている。だからといって、小さいわけぢゃないのがご愛嬌だが、あんな巨大な筐体になっても、AC アダプタを内蔵する気は全く無いらしい。(HP のプリンタを見習え!)

相変わらず、デザインをしょっちゅう変更して嫌がらせとしか思えないほど分かりにくい Network Solutions のサイトでの設定変更も無事終えて、なんとか繋がっているようだ。

ところで、セカンダリ DNS は未だに自宅の「OpenBlockS」が担当しているのだが、いやはや丈夫なものでかれこれ12年目に突入しようとしている。ハードディスクなんぞは初代 iBook (Clamshell) から移植した容量3GB の骨董品で代用しているが、音がウルサイことを除けばなんとか実用にはなっている。(それでも、named.conf や zone の記述書式なんぞは完全に忘れていて、けっこう焦ったな…)

家電であれ、コンピュータ周辺機器であれ、概ね電子機器というのは、ハズレを引くと新しくても壊れる時はあっけなく壊れるが、中にはとんでもなく丈夫で長持ちなモノもある。

そういえば、社内で使用している電子レンジは 1985年製造のナショナルの「私の Elly」という名の黄色いレアモノだ。未だ元気に活躍しているが、今年でなんと27周年になる。機能はシンプル温めるだけ、操作はダイヤルを適当に回すだけ、完了のお知らせは当然、チ〜ンである。

それにひきかえ、自宅の電子レンジは3年目ぐらいで故障したので一昨年買い替えたのだが、プリメインアンプよりスイッチが多い曲者で、まっこと使い勝手が悪い。たかが牛乳をチンするにも2ステップ以上の操作を要し、滅多に好みの適温になることがない。

温める時間ぐらいユーザにまかせりゃいいのに、やたらに余計なお世話をしたがる。だいたい、でき上がっても怪しげなメロディが流れるだけで、決してチンとは言ってはくれない。

日本のメーカはどうしてなんでもかんでも、あのように複雑怪奇なシロモノに変えてしまいたがるのだろう。たかが電子レンジ、されど生活必需品、そう何年も使われては商売上がったりというもの理解できるが、一般ユーザにとってはやっぱシンプルがベストだなあ。

アップルも、早くも次期 Mac OS X Mountain Lion(山獅子?そんなのいるの?) なるものの概要を公表しているが、やっとノートパッドや備忘録のようなシンプルなアプリを復活させるようだ。と、いっても大半は iOS からのパクリで、良く言えば整合性をとる(Back to the Mac)ということなんだろう。しかし、なんでライヨンのままでやらないのか、理解に苦しむところだ。(以前から言っていることだが、メモ帳&備忘録ぐらい標準で付けとけよな→Mac OS X)

ま、個人的にはひとつひとつがシンプルなアプリの集合で環境を整えること自体は、大歓迎である。そのほうが覚えるもの早いし、結局長く使えるモノになるからだ。

願わくば、「OpenBlockS」と「私の Elly」にはいましばらく、いやいっそ末長く、これからも元気に頑張ってもらいたいものだ。


[2012.02.05]

セキュリティなアップデート?

まいど、イノベータやアーリーアダプタといわれる連中は、ベータテスターとして利用されることが世の常であるが、デベロッパーリリースの様なものを一般ユーザを巻き込んで公開でやるのは如何なものか。

セキュリティアップデート、額面通りに解釈すれば、防犯的更新とか保安的向上とか、いわゆる安全確保を目的とした安全・安心な響きのあるアップデータなんだが、現実にはそうとは限らない(ことが、最近やたら多い)。

アップルは、以前にも Java に対する警告ともとれそうな、特定のプログラムが起動できなくなるアップデートを配布した経緯がある。(コイツの修正には、たしか1ヶ月近く待たされたような…)

今回のアップデータもまるで、ロゼッタ利用者に対するハラスメントのようなアップデートであるが、アップルとしてはどの程度悲鳴が上がるか試してみたかったに違いない。もし、苦情が少なければサポートに対する資源を減らせるし、今後の方向性を決めやすくなるとでも考えたのだろう。

もしかすると、最近 Macユーザもアップルが理想とする数より増え過ぎてきたので、あまり金を使いたがらないユーザを少し整理してもっと儲かるユーザを増やしたいがどうするべ、と相談した結果マーケッティング担当からこんなんどうでしょう、みたいないい加減な思いつきの提案をティムクックが鵜呑みにした結果かもしれない。

または、最新版の販売促進を目論むサードパーティからの依頼でもあったのかもしれないが、今後もこのような、旧アプリを使用し続けているユーザに対する攻撃(≒新しい環境への誘い)は日増しに増えてくると予想される。

そのような意図でもない限り、今回のような致命的なバグをもったままのアップデータを公開するなどということは考え難い。スノレパはまだサポート対象なんだから、ロゼッタに対する簡単なテストぐらいは行われているはずだろう。それとも最近のアップルは、単なるバカなのか?

で、あちこちから予想以上の悲鳴が聞こえてきたので、あわてて修正版を公開し事の沈静化を図ったようだ。

いずれにしても、業務用途で旧ソフトを使用しているユーザ(およびそのサポートを生業にしている者)にとっては迷惑な話である。

アップデートはひと呼吸おいてから、というのは業務ではお約束なのだが、安定動作を何よりも望む業務ユーザが、動作に対する不具合を恐れてアップデートを敬遠してしまうようでは、セキュリティアップデートの本来の目的は遠のいてしまう。

ま、以前と違って今回は対応が早かったので被害は少なかったが、ご迷惑をおかけしたユーザに対して、おい、なんか一言あって然るべきぢゃねえのか、とも思うな。


[2012.02.04]

Web Server 移行 Part 2

前回の「COSMOS M&S」ホームページに続いて、「Hexagon-Tech」もお引越し。

せめて、わずかでもアップルに対する嫌がらせになればとの思いから、ぎりぎりまで MobileMe のサービスにしがみついてやろうと考えていたのだが、アホらしくなったんでやめた。

自宅ネット環境をBフレッツからフレッツ光ネクストに移行したのがきっかけなんだが、接続サービスが変わると IP アドレスも強制的に変更になっちまうみたいで、再度固定 IP を取得しなければならなくなった。

で、IP アドレスやらサーバ環境やら、その他面倒なモノを全て一新して心機一転、出直しのつもりで新たに始めることに。

本来ならこれを機に出来の悪い iWeb をやめて、昔のように CSS やら html タグをゴリゴリ書いてページ作成するべきところなんだが、45MB 以上にも及ぶソースコードを目の当たりにして、イマイチ体力と気力が湧いてこない。(iWeb の元データは 300MB 越えなんだが、かつて総量 5MB のレンタルサーバでサイト作成していたころがなつかしい)

このサイトの前身であるコスモスホームページのスタートは、1996年頃の “columbia.digiweb.com” だ。その後家庭内 Linux サーバ “OpenBlockS” を経て、“iTools” サービス開始とともにアップルのホスティングサービスへ移行、“.Mac”、“MobileMe” などですったもんだの揚げ句、またもや家庭内サーバへ戻る。…と放浪を続けてきたわけだが、そんな気が遠くなるような大昔のデータまで、この期に及んでいまさら再編集する気には到底なれない。

iDisk 上にまだ残っている旧ページも含めるといったいどれぐらいあるのか…、考えたくないなあ。

ま、今しばらくは iWeb の出力するまことにきちゃないソースにも目をつぶって、お茶を濁すことにする。

「COSMOS M&S」と同様に、ドメイン名とかは変更がないので「www.hexagon-tech.com」を今後とも、ヒトツよろしく。


2012年02月某日 Hexagon/Okayama, Japan


2012年01月

[2012.01.29]

Bose OE2i & Audinst HUD-mx1

深夜の作業中においては BGM を大々的にスピーカに出すわけにもいかんので、もっぱらヘッドフォンを愛用している。外では iPhone 用として [MA850G/B] Apple In-Ear Headphones with Remote and Mic という長い名前の製品を常用しているが、個人的にどうも耳栓タイプの装着感は好きになれないし、室内においては許容できない。

長年使用していたのは、禅(Sennheiser HP500)と二代目 iPod に付属していたオマケイヤフォンおよびその後継同タイプなんだが、さすがに両者ともくたびれてきた。エージングが進み過ぎて単なる劣化の域に達した感があるので、そろそろ後継を物色。

思わず笑っちゃう価格の HD800 はこの際見なかったことにして、かつて短時間だったが試聴してすこぶる印象の良かった、禅の HD650 が第一候補だ。インピーダンスが 300Ω なんでヘッドフォンアンプが必要になる可能性が高い。まずはそこから探索してみた。


以下、都合により別ページへ...つづく


[2012.01.23]

Web Server 移行

誠に腹立たしい、過去を振返らない無謀な iCloud の仕様変更のせいで、またもや社内サーバに戻ることになった。

で、ライヨンサーバ設定の過程でドメイン設定を適当にしていたら、IDisk 上に展開していた「COSMOS M&S」が、いきなしアクセス不能になっちまったぜ。

…ということで、復旧はいつになるやら不明だが、とりあえずここはヒトツ長い目で見てやって欲しい。

[01/25:追記]
暫定復旧はしたものの、なにかと不具合も多い。ココ、Hexagon Tech も後日別サーバに移行予定だが、どうなることやら。ただ、スノレパサーバに比べてはるかに設定は楽でわかりやすいから、なんとかなるだろう、…たぶん。

[2012.01.01]
泣く子も笑う、謹賀新年♪

ナニはなくとも、とりあえず年は越せたぞ。

今年は御大不在のアップル、アレやコレやと不満も少なくない、一筋縄ではいかない企業体質だが、真価を問われる一年になる。

11月上旬に申込んだ iPod nano 1st. 交換プログラム。製品修理サービスの依頼から約1ヶ月ほど経過した12月9日になって、やっと受領通知が来たかと思えば、年も押しに押し迫った土壇場の12月31日に交換品が戻ってきた。

ネット上でも噂になっていたことだが、ユーザには何の事前通知もなく現行製品の第6世代 iPod nano にすり替えられてしまった。新製品に替えてあげたんだから文句は無いだろうと言わんばかりの一文が添えられているのみで、保証期間も修理品ではお約束の実施日よりキッチリ90日、なんのオマケも無しある。

別にケチ臭いことを言っているのでは無い。確かに、交換プログラムに応じて送付したのは本体のみだから、アップル的には何も文句をいわれる筋合いはないのだろう。

しかしユーザからしてみれば、パーソナライズ刻印まで施したオリジナルファーストモデルを取り上げられ、容量こそ増加したとはいえ全くデザインも異なり価格的にも購入当時より安い8GBモデルが、イヤホンやケーブルも付属しない、まんま本体のみがビニール袋に入って、忘れた頃にいきなり送られてくりゃあムっとする。

人によっては、アップルの思惑通りに新しいモノに替えてくれるんなら御の字という場合もあるだろうが、個人的には現行モデルの iPod nano はあまり好みでは無い。もし事前にその旨伝えられていたら、送付時点では取り立てて問題も無く動作していたことも鑑みて、たぶん交換プログラムには申し込まなかっただろう。

2ヶ月も前に始まったことを、今更蒸し返して事を荒立てるつもりは全く無いのだが、日本には古来より「トラブった時には菓子折」という伝統があり、我地元では、大手まんぢゅうというのが定番になっている。

大手なんたらがいったい幾らするのか買ったこともないので知らないが、おそらく一ヶ百円もしないと思われるので十ヶ入りでも千円以下だろう。  ちなみに、コイツは専ら他人様に差上げるモノで、貰って食べることはあっても自分で食べる為に買うヤツは少ない。(たぶん)

要するに、アップルに大手まんぢゅうを持って来いとか、越後屋よろしく菓子折の底に金子を忍ばせろ、などと悪代官のようなこと言うつもりも無い。けっして金額の多寡ではなく、気持ち問題なのだ。

せめて価格的にも直近上位の16GBモデルであるとか、8GBモデルなら販売されている製品版と同様に、ちゃんとケースに入ってイヤホンやケーブルまで付属している製品を送ってくるなりの、誠意を示して欲しかった。

何が言いたいかといえば、我国では相手のミステイクでトラブったら、等価交換で納得するようなアメリカンなヤツは少ない、ということだ。

う〜む、やっぱケチ臭いなあ。

新年早々セコイ始まりになっちまったぜ。

 …ということで、今年もヒトツよろしく、です。


2012年01月吉日 Hexagon/Okayama, Japan



◎ 2014年〜後半の雑記へ

◎ 2014年〜前半の雑記へ

◎ 2013年〜後半の雑記へ

◎ 2013年〜前半の雑記へ

◎ 2012年〜後半の雑記へ

◎ 2012年〜前半の雑記へ

◎ 2011年〜後半の雑記へ

◎ 2011年〜前半の雑記へ

 

2012年上半期