Altebute Blog: 2012

2012年12月8日土曜日

Surfaceが目指す方向性とアーキテクチャ

次期Surface ProにあたるSurface Pro 2がAMDのアーキテクチャを採用すると噂だ。これがもし本当なら何を意味するのか。

まず、Windows 8タブレットの現状について。
IntelのClover Trail世代のAtomアーキテクチャを採用するWindows 8タブレットが多数見られる一方で、
AMDのHondo世代Z-60アーキテクチャを採用するものはまだ殆ど見られない。富士通の10.1型タブレット「STYLISTIC Q572/F」はZ-60を採用しているが、法人向けであり個人ユーザ間での認知度は極めて低い。その他も、Z-60を採用する製品で、ユーザ間での認知度の高い物は皆無と言っていいレベルだろう。

次、現行のSurface ProとSurface Pro 2の比較。
Surface ProがIntel Core i5を採用する一方で、その後継であるSurface Pro 2はIntel Atomの対抗馬にあたるZ-60の後継にあたるTemashを採用する、という噂はかなり興味深い。このリーク情報の信頼度は低くもないし高くもないが、これが本当なら、Microsoftは現行のAtomはWindows 8を動かすには力量不足で、Core iプロセッサが必要だが、次の世代ではAtomと同等のランクのアーキテクチャでもマシンパワーが足りる、と考えているということになる。あるいは、Surface 「Pro」なのであるから、採用するアーキテクチャにもある程度のプレミアリティーが必要だと考えていたが、その考えを改めた、とも考えられる。

最後に、Intel Core iアーキテクチャとAMD Temashの比較。
従来のIntelのアーキテクチャとAMDのアーキテクチャを比べると、AMDがAPUを自称する通り、AMDの方が比較的高性能なチップセット内蔵グラフィックスを実現していることも、Surface ProがFullHDのディスプレイを採用していることと併せて考えれば後継機での採用を後押しする要素となる(最近はIntelのチップセット内蔵グラフィックスの性能もあがったが)。つまり、X86互換のアーキテクチャを採用するにあたって、AtomではCPUは問題ないがグラフィックスの処理能力が足りないからCore iアーキテクチャを採用せざるを得なかったが、AMDのアーキテクチャを採用することでこれを解消しようと考えているのではないか、ということだ。現行のSurface Proで、軽快な操作を実現し、要求されるユーザ体験を実現するために、Atomアーキテクチャを採用せずCore iアーキテクチャを採用するという考えは十分に理解できる。
TemashがSurface Pro 2に採用されれば、現行のAtom採用Windows 8タブレットと同等、Windows RTタブレットに迫るバッテリーライフと重量、そして軽快な操作を両立できる可能性は高いと思われる。期待が懸かる。
本記事で私が述べたいことはTemashを採用することの意味と、それに対する期待だが、最後に述べる私の本音はこうだ。
「Surface Proは買い控えして、Pro 2を買おうかな」

参考文献

2012年11月26日月曜日

ブラウザに見る、各モバイルOSのデザイン哲学

　iPad miniの発表の際に、Appleのフィル・シラー氏は「iPad miniの7.9インチディスプレイは、Nexus 7の7インチより35%広く、ウェブ表示面積では最大67%も広い」（若干の意訳を含む）と述べた。個人的には、iPad miniというハードウェアについての発表をしているのに、突然iOSのSafariとAndroidのChromeを比較し始めるのは不自然に感じる（勿論、iOSとiPad miniはセットで一つの製品なので、全くおかしいとは言わないが）。この発言について、ウェブ上では様々な議論が交わされたが、これは両社のデザイン哲学の違いを表しているように思う。
　一番最初にAppleについての話をしたにも関わらず、この記事の主役はWindows 8/RTとAndroidだ。申し訳ない。

　Windows 8/RT（ここではタブレット向けUIの話をする）では、「コンテンツこそが王様」というデザイン哲学が貫かれているように思う。各種メニューは画面外に追いやられ、アプリケーションをスナップしない限り、1つのアプリケーションが画面全体を占有する。ユーザーが画面全体に表示されるコンテンツに対し没入することができるようOSのUIがデザインされている。Internet Explorer 10では画面全体にウェブサイトが表示され、広々とした画面で気持よくブラウズできる。しかし、タブを移動したり、その他各種操作を行う方法に習熟するには、些かの時間を要求される。はっきり言って、直感的に操作できるか？と言われれば答えはNOだ。Windows 8/RTのUIは、分かりやすさという観点ではあまりにもお粗末な出来と言わざるを得ない。

　一方のAndroidはWindows 8/RTとは対照的だ。分かりやすさを優先するため、画面下部には常にソフトキーとしてナビゲーションバーが表示され、各種アプリケーションではユーザが各種メニューに気付くよう、全てのメニューを出来る限り画面内のアクションバーに表示している（勿論、特にコンテンツが重要なギャラリー等のアプリについてはこの限りではない）。
　この仕様に対する私の印象は以前ほどネガティブではなくなった（慣れてしまったとも言う。分かりやすさはアプリによる）が、やはりコンテンツを広く表示したいアプリケーションにおいてはアクションバーもナビゲーションバーもステータスバーも全てを非表示にして、フルスクリーンでコンテンツを楽しみたい。そう、Chrome君、君のことだよ。

　両者は、分かりやすさを優先するかコンテンツを優先するかで対照的なUIデザインとなっている。画面内にUIエレメントを設置すればコンテンツ領域が狭くなり、画面外に追いやれば操作性が下がる。両者は二律背反的だ。

　これに対し、iOSはうまく中間的なアプローチを取っている。iOSのSafariでは、基本的に常に基本的な操作が画面下部に表示されるが、画面内にフロート表示されているフルスクリーンボタンを押すことで、表示を切り替えることができる。この点ではiOSのSafariが頭ひとつ抜けている様に思う。

　コンテンツを広く表示できることは非常に重要だが、その為にUIが分かりにくくなってはいけない。バランスを意識しつつ、自然に操作できるUIを心がけて頂きたいものだ。というかChromeはフルスクリーン表示させてくれ。頼むから。マジで。

Android 4.2でのフォント変更・AA対応

　先日Android 4.2がリリースされた。いくつかのバグを抱えていたりディレクトリ構成の変更による混乱等が起きているが、基本的にはブラッシュアップされており好ましいアップデートであるように思う。
　Android 4.2では4.1で追加されたfallback_fonts-ja.xmlが無くなり、fallback_fonts.xmlに再統合されている。これは実際にfallback_fonts.xmlを見ての予想なのだが、4.1では使用している言語によって使用するfallback_fonts-xx.xmlを変更していたものを、4.2ではfallback_fonts.xml内で言語を指定してフォントを設定するように使用変更したのだろう。
　上記の様なフォントの指定方法の変更の他、4.2ではフォント自体の種類も増えている。4.1がリリースされた際に追加された"sans-serif-light"で指定されるフォントの他に、"sans-serif-thin"で指定されるフォントが追加された。
　AAに対応させるための方法は、前回と同じように、system_fonts.xmlの先頭でシステムフォントを指定し、その次にＭＳＰゴシックを指定するように変更すれば良い。
　私としては、折角RobotoフォントがAndroidのために開発されたのだから、アルファベットには優先的にRobotoフォントを使いつつ、日本語には任意のフォントを指定したいので、基本的な日本語フォントについてはfallback_fonts.xml内で指定し、system_fonts.xml内ではシステムフォントにRobotoを、ＭＳＰゴシックにtextarを指定している。細字フォントについては、文字のバランスが崩れるのを防ぐために直接日本語フォントを指定している。/system/fonts/ディレクトリに追加しているフォントは以下の通り。

migu-2ds-regular.ttfをDroidSansJapanese-Regular.ttfとして追加
migu-2ds-bold.ttfをDroidSansJapanese-Bold.ttfとして追加
mplus-2p-light.ttfをDroidSansJapanese-Light.ttfとして追加
mplus-2p-thin.ttfをDroidSansJapanese-Thin.ttfとして追加
textar.ttfを追加

　私が使用している変更済みのxmlはこちら。Rootに対応したファイラを使用して上書きし、パーミッションを644に変更するか、adb pushコマンドを使用してファイルをプッシュし、chmodコマンドでパーミッションを変更すれば良い。ここに書いていない細かい手順は関連記事を読んだりGoogleで検索する等して調べて下さい。

関連記事

2012年10月24日水曜日

iPad mini発表ブレークスルーはまだ遠い

　以前から私は常々「ノートPCが3lbsを切った時にブレークスルーが起きる」（このブログで言ってはいないかもしれない）と言ってきた（この表現を私はしばしば多用する。思っているだけでアウトプットしていない可能性があるので、そういう場合は後出しになってしまっていている。申し訳ない。）。
　この3lbsと言う重さは、自身の直感に基づいたものだ。必要十分なスペックと普及価格帯という条件を満たした上で、「この重さを切ったら買ってもいい」と思える基準。その基準こそが「3lbs」という重さだ。
　そして、実際にブレークスルーは起きた。2010年末第4世代MacBook Airのリリースだ。それまでにも素晴らしいモバイルラップトップはあったが、20万円前後とかなり高額な物が殆どの高嶺の花だった。AcerのAspire Timelineによる価格破壊に続く形で、MacBook Airはその市場に求められる価値を大きく引き上げた。
　その後に訪れたのが現在のUltrabook旋風だ。AcerのZENBOOKやLenovoのThinkPad X1 Carbonに代表されるUltrabookは現在のラップトップ市場を代表する製品となっている。

　本題に入ろう。iPad miniについてだ。iPad miniの重量は308グラム。iPhone 5やiPod touchの大幅軽量化に続く形で、かなり軽量になった。流石にMedias Tab ULの249グラムには及ばないが、一般的な競合他社の製品と比較するとかなり軽量だ。
　確かに軽い。非常に軽いのだが、残念ながらiPad miniはブレークスルーを起こすには力不足であると思う。この軽さを実現するには仕方なかったのだろうが、スペックは前世代iPhoneであるiPhone 4Sの流用であるし、Retinaディスプレイも搭載しない。勿論これらのマイナス面は既存のApple製品と比較するからそのように思えるだけで、市場全体における立場を考えれば、Nexus 7とSurfaceの中間の価格、中間のディスプレイサイズを備え、重量ではこの中で最も軽量である事を考慮すれば、バランスに優れた製品である事には相違ない。
　しかしながらiPad miniはあくまでiPad「mini」なのだ。iPadという製品の本流ではない。iPadの主役はあくまでもiPadであり、「mini」ではないのである。

　次のブレークスルーは、10型タブレットが1lbs（453グラム）または500グラムを切った時だと思う。今回発表されたiPad Retinaディスプレイはまだその領域には達していない。1lbsの重量、3万円を切る価格、10型ディスプレイを搭載し、必要十分な性能を備えること。それがタブレット市場を次の段階へとシフトさせるための条件だ。

2012年10月18日木曜日

Google Dart対Microsoft TypeScriptという構図の意味

　TechCrunch Japanの記事でも述べられているが、どうやらGoogleはやはりDartに対してかなり本気らしい。それもその筈、GoogleにとってDartが極めて重要なプロダクトであることは疑う余地が無い。それは何故か？

　それはDartがGoogleにとって次代のプラットフォーム戦争における覇権を握るための極めて重要な切り札であるからに他ならない。

　以前から私が常々言っていることではあるが、現在行われているAndroid対iOS（＋その他大勢）の構図によるプラットフォーム戦争は、その実体を徐々にウェブ上に移していく筈だ。Facebookはパフォーマンスの問題から同社のアプリケーションにおけるHTML5の利用を中止したが、これはつまり「パフォーマンス（と生産性）の問題さえ解決すればHTML5を採用する」ということに他ならない。実際にはこの他にも、各々のプラットフォーム間での挙動や実装、作法の違いからくる不調和等の細かな問題は山積みであるが、それも徐々に解決していくだろう。ゲーム等の非常にリッチなコンテンツをウェブというプラットフォームで動かすのは当分先になるかも知れないが、そうでないアプリケーションの主流がウェブに移っていくのは時間の問題だ。多くのアナリスト達は現在のようなOSは徐々に息を潜め、プラットフォームの主役はブラウザになると分析する。その次に言うことはこうだ。「今はまだ早い」。

　MicrosoftのTypeScriptやGoogleのDartは、このブラウザ上でのプラットフォーム戦争を担う次代のプラットフォームである、ということだ。現在のHTML5が抱える主な問題、「パフォーマンス」「生産性」「仕様の乱立」の3つを全て解決するために両社が尽力している事は、そのプラットフォームの性質から明らかだ。言語としての機能の充実だけでなく、エディタまで提供している事がそれを裏付けている。

　GoogleがChromeの普及に対して殆ど異常とも言えるほど執着していることも、これを更に裏付けている。現在のChromeブラウザにはまだDart VMが搭載されていないが、Windows、Android、Mac OS、Linuxの全てのChromeに大してDart VMが搭載されれば、Dartは一躍巨大プラットフォームへと変貌する。Chrome以外のブラウザに対してはJavaScriptとして提供すればよいし、Chrome上ではネイティブアプリと見紛う程の速度で動くとなれば、同社のシェアは一気に加速するだろう。更に言えば、優れたVMとエディタが合わされば、Android上でのアプリケーション開発における生産性の低さも同時に解決する。

　とは言え、どのプラットフォームがこの次代のプラットフォーム戦争における勝者となるかはまだまだ未知数だ。先行開発したプラットフォームが結局頓挫するケースは数え上げればきりが無いし、後出しで漁夫の利を狙ったプラットフォームが勝利することもあれば結局先行するプラットフォームに追いつけずに負けるケースもある。今後も各々のプラットフォームの動向を注視していきたい。

2012年10月1日月曜日

2012年秋 Apple発表所感

　さて、13日(日本時間)のAppleの発表から二週間余りが過ぎ、無事(？)iPhone 5も世に送り出されクールダウンしてきたところで、一連のリリースに関する私の所感を記事として纏めることにする。

　今回の発表内容は、今までと比較して驚きに欠けたものだったように思う。これは私だけの意見ではなく、ウェブ上では散見される意見だ。ただし、私は驚きに欠けていたことを残念だとは思わないし、故ジョブズ氏が存命なら云々等というのはもっての他だ。そもそもスマートフォン全般の新製品の発表が以前ほど新鮮味に溢れたものでは無くなってきているように思え、それはiPhoneも例外ではなかった、というだけの話であるように思う。つまり、スマートフォンというカテゴリの製品や、それに関する技術が徐々に漸くこなれて来たということだ。
　もし仮に、この次の大きな革新が訪れるとしたら、それはウェブによるものだろう(個人的には、それがオープンウェブであってほしいと願っている)。HTML5アプリケーションとネイティブアプリケーションの区別がつかなくなった時、次のパラダイムシフトが起きるだろう。

　話が逸れたので元の話題に戻る。iPhone 5は、控えめに言ってよくできていると思う。革新性・驚きに欠けるという意見が見られるが、順当に進化してきたのは今までも同じ。iPhoneが劇的に変化したのはRetinaディスプレイの採用程度で、それ以上に大きな変化は無かったように思う。むしろ、今回の発表内容が驚きに欠けるのは事前のリーク情報があまりにも多すぎたからではないか、という気がする。
　LTE対応を、3モデルに分けて行ったのは私的には英断だったと思っている。LTEの全世界的周波数対応はまだまだ難しく、仮にやったとしてもバッテリーライフに不安が残る。消費電力と利便性を天秤にかけた上で、3モデルに分割したのは妥当な落とし所だろう。
　しかし、ブラック＆スレートモデルの傷が目立つというデザイン上の欠陥や、降るとカタカタと音がしたり、ディスプレイの問題の話は頂けない。傷については、iPod classicの前面パネルの傷が目立つという話は聞いたことがないので、同様の技術を用いることはできなかったのだろうか、と思う。一方で指でこすると傷が消えるという話もあるので、わざとこのような表面加工にした可能性もあるだろう。結局、実物を何ヶ月か使用してみなければ本当の所は分からない。その他の問題は、初期ロット特有の問題で改善されていく、という展開を望む。

　iPod touchについても、順当に進化したなという印象だ。24800円から、というまで値段が下がったのは、スマートフォンのような高度なプロセッサを搭載したモバイル製品が徐々にカジュアルな製品になり、コモディティ化しつつあることを示しているように思う。ポップカラーで多数のカラーバリエーションを出してきたことも同様だ。
　個人的に頂けないのは、この色がソフトカラーであることだ。新しいiPod touchの色はiPod miniや第2-3世代iPod nano、第2-4世代iPod shuffleに酷似したソフトカラーを採用している。これは新しいiPod shuffleとiPod nanoも同様だ。個人的には第4-6世代iPod nanoのようなビビッドカラーが好きだったので、全てビビッドカラーで統一して欲しかった。ただまぁ、これは個人的な好みの問題だろう。
　iPod touch loopはとても有り難い。ケースや保護シートを使えば落下時の破損の可能性を低減することはできるが、そもそもの落下する可能性を大幅に低減することができるのは大きな進化と言えるだろう(今まで無かったのがおかしいとも言えるが)。惜しむらくは、このiPod touch loopが全てのiPodとiPhoneで採用されるまでには至らなかったことだ。せめて、全てのiPodとは言わないまでもiPhoneには採用して欲しかったところだ。

　iPod nanoは、Lumia 800にデザインが似すぎているように思う。ただ、元記事にも書かれているように、Lumia 800のデザインが第6世代iPod nanoに似ているとも言えるので、敢えて深く追求する必要は無いだろう。むしろ、ディスプレイ消灯時に黒色のフロントパネルに沈み込み、フルフラットデザインを強調してくれるLumiaのデザインの方が私には格好よく思える。iPod nanoが白色のフロントパネルを採用したのはLumiaと酷似しすぎてしまうのを回避するためか、それともよりライトなユーザ層を意識した結果か、はたまたその両方だろうか？
　縦長のボディへの回帰は私が待ち望んだ物と寸分違わないもので、第6世代iPod nanoが出た時の失望を大きく払拭してくれるものだった。iPod touchを小型化し、ソフトウェア面の拡張性を取り払った、iPod touch miniとでも言うべきこのデザインはポータブルメディアプレイヤーとして非常に優秀だと思う。

　Lightningコネクタは、動的割り当てによるリバーシブル設計や小型化等のコネクタそのものの優れている点については納得できるが、何故Micro USBにしなかったのか、と思う。Appleとしては電圧を自社管理すること等の目的もあるのだろうが、広く普及しているMicro USBケーブルが使えないデメリットの方が私としては大きい。

　iOSに関しては…まぁ頑張ってほしい所だ。OSの設計そのものが陳腐化しつつあるという意見もあり、私も同じように思う。iOSの一貫したUIは非常に優れていると感じるので、Mac OS 9からOS Xへのような進化に期待したい。

2012年9月30日日曜日

ThinkPad USB トラックポイントキーボード導入

　デスクトップPCを導入した折、キーボードをThinkPad USB トラックポイントキーボード(55Y9024)に乗り換えたのだが、外付けキーボード特有の事象か最新のユーティリティの仕様なのか、以前の記事で書いたようにtp4table.datを書き換えることでは設定を変えられない(そもそもtp4table.datが生成されない)事が分かったので、新規に備忘録を書くなど。

　55Y9024向けのユーティリティはここでダウンロードできる。Lenovoのサポート体制の問題か、通常のLenovoのサポートからのドライバーとソフトウェアのダウンロードとは異なり、クイック・パスを利用したり、製品の絞込み指定によるアクセスはできず以下の様な非常に面倒なルートを経由してアクセスする必要がある。(2012年9月30日現在)

Lenovo Japan -> サポート -> 製品と部品アクセサリー - リファレンスガイド -> Desktop アクセサリー -> キーボード / キーパッド（英語） -> Keyboards and Number KeyPads: Available ThinkPad USB Keyboard with TrackPoint -> Additional Product information Software and device drivers
　最終的には英語のサイトにアクセスしないといけない上に、非常に階層が深くとてもアクセスしづらい。

　英語サイトからのアクセス経路は以下のとおり。
Lenovo US -> SUPPORT -> DRIVER MATRIX -> Think Accessories -> Desktop Accessories -> Keyboards / Keypads -> Keyboards and Number KeyPads: Available ThinkPad USB Keyboard with TrackPoint -> Additional Product information Software and device drivers
　辛うじてダウンロードできるから良いものの、Lenovoのサポート体制には改めて疑問を感じざるを得ない。

　閑話休題。アプリケーションごとのスクロールの設定についてどう設定するかに入っていこう。従来のようにtp4table.datは存在せず、代替手段も私は見つけることができなかったので、ここではTrackWheelというサードパーティー製のアプリケーションを利用することにする。TrackWheel.zipを利用するのがお勧めだ。AutoHotkeyを利用している人はダウンロードしたファイルのTW.ahkを利用、そうでない人は単体で動くバイナリのTW.exeをスタートアップに登録すればよいだろう。TW.iniを編集することで、tp4table.datと遜色なく、アプリケーションごとの動作設定を行える。編集方法・文法については、TW.ini内にサンプルが載っているので、それを参考に自分で試行錯誤してほしい。基本的には、デフォルトの設定である程度のソフトウェアには対応してくれる。私の環境では、Skypeでスクロールするための設定を追記してやる必要があった。

2012年9月15日土曜日

Lenovo ThinkCentre M72eでRadeonのドライバをAMD公式の最新版に更新する方法

折角デスクトップPCを購入して今までよりもぐっと高性能な環境を入手したので、早速ゲーム(PSO2)をプレイしようとしたところ、下記のようなエラーが発生。

どうやらキャラクターを表示しようとするとエラーになるようで、解決するためにはドライバを更新する必要がある様だ。AMDの公式HPからドライバをDLして更新しようとしたが、ここでトラブル発生。何をどうやってもインストールすることができない。
しばらく試行錯誤しながら色々試した所、どういう原理か不明だがM72e(その他のThinkブランドのPC全般もそうかもしれない)はThinkVantage System Updateから入手したドライバしか受け付けてくれない模様。

以下はNGだった方法のリスト。

ThinkVantage System UpdateがDLしてきたファイルにAMDのウェブサイトからDLしてきたファイルを上書きしてきてからインストール
インストーラのみ上書きせずに同じ方法
管理者権限や互換設定等

最終的にはドライバを手動でインストールする事で解決したのだが、これがまた曲者だった。AMDがRadeon HD向けに提供しているドライバとユーティリティのセットであるCatalyst Control Centerは、インストーラを起動するとCドライブ直下に一度ファイルを展開した後、その中にあるインストーラを実行するのだが、この展開されたファイルの数が膨大で、ドライバファイルの実態を見つけるのが中々に困難なのだ。ちなみに最新版のバージョンは12.8(2012/09/15現在)で、ドライバはデフォルトで以下のディレクトリに展開される。

C:\AMD\Support\12-8_vista_win7_win8_32_dd_ccc_whql\Packages\Drivers\Display\W8_INF

このフォルダには3つのドライバが格納されており、内訳は以下の通り。

CE145524:Windows 8向け
CL145524:Windows Vista向け
CW145524:Windows 7向け

それぞれmsiファイルを実行することで、対応しない場合にエラーメッセージを表示してくれるのでどのOS向けか知ることができる(このインストーラからドライバをインストールしようとしてもやはりインストールできない)。上にも書いた様に手動でインストールしよう。以下の方法は本来の方法からは大きく外れた方法。最悪画面が映らなくなる可能性があるので自己責任で。一応セーフモードだとなんとかなるのかな？付属のユーティリティを使わずにドライバのみの手動インストールなので非常に危険であることに留意されたし。

デバイスマネージャーを起動ドライバ更新

手動で参照

ドライバ一覧から選択

ディスクを使用

参照

OS毎に任意のinfを選択

任意のモデルを選択。今回の私の場合はRADEON HD 7450。これだけ何故か大文字。

勿論はい

お疲れ様でした。

Lenovo ThinkCentre M72e Towerを買った

Lenovo ThinkCentre M72e Tower 0896CTOを購入。
購入した理由は以下の通り。

今まで使用していたThinkPad X200のスペックが足りない。
ThinkPad X200の調子が悪い。
生活の変化からモバイルPCの必要性が薄れた。

スペック不足に関しては、特にGPUの性能が足りなかった。X200を購入したのが2009年2月28日。3年半前のPCで、しかもモバイルノートとくればゲームをプレイする場合スペック不足にもなろうというものだ。

不調に関してはファンの調子が悪く、起動時にファンを回転させはじめることができず「Fan error」と表示され起動できなくない事があった。また、スリープから復帰した時にファンを回転させはじめられないと、CPUの温度が90度近くなりプツンという音と共に強制終了してしまう状況。また、たまにスリープに入ることができず、BSODから強制終了のコンボもあった。

そんな訳で、今回購入したM72e(11日に届いた)の性能は以下のとおり。

Intel Core i5-3470 3.20GHz, 1500MHz, 6MB
Windows 7 Home Premium 32bit
4GBx1 PC3-12800 1600MHz DDR3 UDIMM RAM
AMD Radeon HD7450 1GB (DVI+DisplayPort) FullHeight
1TB 7200rpm SATA HDD
DVDスーパー・マルチ
内部スピーカー
DisplayPort - DVI-D変換アダプタ

特に注文では指定しなかったが、DVI 11pin - VGA変換アダプタは標準で付属するようだ。11ピンのDVIというのがよくわからなかったので調べたが、結局よくわからなかった。

1ヶ月以内に保守サービスに入らないといけないらしいので早めに入っておこう。

2012年7月4日水曜日

Android 4.1 Jelly BeanでのAA表示

Android 4.1 Jelly Beanではフォント指定の仕組みが再び変更され、基本的に日本語フォントについてはfallback_fonnts-ja.xmlが参照されるようになった。

今回は、system_fonts.xmlでのフォント指定、fallback_fonts-ja.xmlでのフォント指定、fallback_fonts.xmlでのフォント指定について、それぞれ特徴的なフォントを指定することで、どのような場面でどのフォントが参照されるのかを調べてみることにした。

fallback_fonts-ja.xmlではモトヤLマルベリ、system_fonts.xmlでは04B-31、fallback_fonts.xmlではモフ字 1.3を参照することにした。

結果：
基本的な動作として、まず最初にsystem_fonts.xmlが参照される。一般的には、system_fonts.xmlの先頭に記述したfamilyが使用され、ブラウザ等でフォント名が指定されている場合は、その名前に対応したfamilyをsystem_fonts.xmlから探す。システムフォントの中でも通知領域にはsans-serif-lightとして指定したフォントがが用いられる他、sans-serif-condensed（次幅の狭いゴシック体）などが標準的に利用できるように設定されている。
system_fonts.xml内で指定されたフォントの中に、使用したい文字データが含まれていなかった場合にはじめてfallback_fonts-ja.xmlが参照される。私が実験した限りでは、fallback_fonts.xmlが参照されることは無かったため、設定している言語によって参照するxmlを変更し、表示するフォントを変えるための仕組みが実装されたということだろう。

結論：
system_fonts.xmlの先頭でfontfamilyをSystem等としてシステムフォントを設定、同様にＭＳＰゴシックにKuma_LiteやTextar等の携帯端末向けAA対応フォント（PCとはフォントレンダラーの仕組みが異なるため、携帯向けのAA対応フォントでないと表示が崩れる）を設定し、その他のゴシック体のグループにも日本語フォントを指定しておくと良いだろう。通知領域のフォントはよく目にするので、sans-serif-lightもarial等のグループに一緒に含めておくと、フォントの統一感が向上する。
fallback_fonts-ja.xmlでは、MTL3mr.ttfの部分に使用したい日本語のフォントを指定すれば良い。
もちろんアクセス権の設定を忘れずに。

以下に私の設定例を示す。

system_fonts.xml
(前略)
<familyset>

<family>
<nameset>
<name>system</name>
</nameset>
<fileset>
<file>DroidSansJapanese.ttf</file>
<file>DroidSansJapanese-Bold.ttf</file>
<file>Roboto-Italic.ttf</file>
<file>Roboto-BoldItalic.ttf</file>
</fileset>
</family>

<family>
<nameset>
<name>ＭＳＰゴシック</name>
<name>MS PGothic</name>
</nameset>
<fileset>
<file>textar.ttf</file>
</fileset>
</family>

<family>
<nameset>
<name>sans-serif</name>
<name>arial</name>
<name>helvetica</name>
<name>tahoma</name>
<name>verdana</name>
<name>sans-serif-light</name>
</nameset>
<fileset>
<file>DroidSansJapanese.ttf</file>
<file>DroidSansJapanese-Bold.ttf</file>
<file>Roboto-Italic.ttf</file>
<file>Roboto-BoldItalic.ttf</file>
</fileset>
</family>
(以下略)

fallback_fonts-ja.xml
<file>MTLmr3m.ttf</file>
の部分を
<file>DroidSansJapanese.ttf</file>
<file>DroidSansJapanese-Bold.ttf</file>
<file>Roboto-Italic.ttf</file>
<file>Roboto-BoldItalic.ttf</file>
で置き換え。

fallback_fonts.xml
編集しない

尚、textar.ttfはGoogle Code -Textar Fontから、DroidSansJapanese.ttf及びDroidSansJapanese-Bold.ttfはANDROIDLOVER.NETのMyupdate-v1.4-JB.zipを利用している。フォントの変更方法についてはANDROIDLOVER.NETを参照して欲しい。多謝。

2012年6月8日金曜日

今更始めるEvernote -Clearlyによるスクラップブック式活用法-

最近Evernoteを積極的に使うようになった。人によってEvernoteの使い方は様々だろうが、私は今まで何度か使ったものの、あまりピンと来ず、その度に放置していた。クライアントもインストールしてはアンインストールを繰り返してきた（EvernoteのWindows向けクライアントはそれなりに容量を食う）。

この情況を大きく変えてくれたのがGoogle Chrome向けの拡張機能であるClearlyだ。

Clearlyによって整形された記事

Clearlyは上図のように記事を整形して、見やすくしてくれる。私は背景を暗めにし、文字と背景のコントラストを下げる設定にしている。また、フォントも自由に設定することができる。記事によってはうまく整形出来ないことも少なくないが、十分に便利な機能だ。

また、Clearlyの機能はこれだけではない。画像右にあるEvernoteのアイコンをクリックするか、設定したショートカットキーによって記事をEvernoteにクリップすることができる（記事の整形にもショートカットキーを設定できる）。

結局、私はEvernoteを利用するにあたって、気負い過ぎていたのだろう。何か活用法を見出して有効活用しなくてはいけない、それが出来ないのなら使っていても仕方がない、という感情があったのだろう。その点この方法なら気軽に利用することができる（その分無料ユーザは容量超過の危険性が上がってしまうが）。

この利用方法は、Evernoteをスクラップブックとして活用する利用法だ。Google リーダーによる記事の収集、Pocketによる後で読む、という情報収集の方法に、いつかまた読みたくなりそうな記事を検索するための方法を加えることができる。数ヶ月たってからまた記事を読みたくなったのに、記事のタイトルが思い出せない、という時にEvernoteを使って検索すれば、記事を引き出すことができる（はずだ。実際に効果が分かるようになるにはもう少し利用し続ける必要がある）。
Evernoteというサービスが終了してしまうとノートが失われてしまう、というリスクがある点には留意する必要があるが、それは他のあらゆるサービスについて同じことが言えるだろう。

結論として言えることは、Evernoteはまさしくノートである、ということだ。電子デバイスを用いた様々な活用方の提案が成されているものの、その活用法が持つ主要な側面はまさしく「Evernote」の名前通りであることが殆どだ。

「Evernoteを使うといいよ！という記事を今まで沢山みてきたけど結局全然使いこなせていない」という人がこの記事を読んで便利に活用してくれるようになれば幸いである。

2012年6月6日水曜日

私とGalaxy Nexus

実は先日Galaxy Nexusを購入した。契約としては、SoftBankのHTC Desireから違約金を支払ってのMNPによるドコモとの新規契約となる。私自身が最新のNexusブランドの端末を所有したかった事と、安かった事が理由だ。

心配だったPenTile配列の液晶や、大きすぎる4.65インチの液晶も、慣れてしまうと全く気にならない。前者については、よく見れば画面左端が緑色であることが分かるものの、Nexus Sとは異なり普段使っていて気になるほどは目立たない（とは言ってもPenTile配列でない液晶と比較すると普段の目の疲れは異なるだろうが）し、後者についてはLMT Launcher（要root）を利用すれば画面下部へ指を伸ばさなくても基本機能のボタンにアクセスできる様になる（連打はできなくなる）。

以前の記事でも書いたように、ICSのGUIに関しては気に入らない部分が多々あるが、慣れれば操作自体は十分に可能だ（依然として不満ではあるが）。

普段はAndroid Open Kang Project（通称AOKP）とカスタムカーネルのGlaDOSを組み合わせて使っている。最近は消費電力が気になるためLeankernelへの乗り換えを検討中だ。

ところで5月28日にGalaxy Nexusを落下させてしまい、液晶を破損させてしまった。幸いドコモのケータイ補償お届サービスに加入していたため、5250円で修理してくれる上に代替機として同じGalaxy Nexusを借りることができた。

フロントパネルにひびが入ったGalaxy Nexus

電話をかけてから一日で代替機が届き、あまりの早さに驚かれされた。

最近はLumia 900やWindows 8タブレット、新しいiPad等気になる製品が多い。ThinkPad X1 Carbonもとても欲しい。物欲ぐぬぬ…

2012年2月8日水曜日

Ice Cream SandwichのGUIが好きになれない理由

Ice Cream Sandwich(以下ICS)ではUIが大きく刷新され、見た目は随分美しくなり、使い勝手も大きく変更された。しかし、私的には変更されたUIのダメな所が目立って見えてしまう。確かにアニメーション等の細部を見ればエレガントなのかもしれないが、根本的なGUIの設計がスマートフォンの利用形態に適していないように思う。その理由を2つ、以下に挙げる。

1. 再編成された下部のボタン

ICSでは、画面下部のボタンが4ボタンから3ボタンに再編成され、そのボタン構成は大きく変動した。今まで、画面下部には「戻る」、「メニュー」、「検索」、「ホーム」の4つのボタン(端末によっては検索ボタンが省略されていることもある)が配置されていたが、ICSからはこれが「戻る」、「ホーム」、[最近使ったアプリ]の3つになった。

この再編成ははっきり言って私はよくないと思う。2.3以前ではホームのロングタップによって最近使ったアプリの機能を呼び出していたので、それを鑑みれば完全に機能の削減しか行われていないと言える。Googleは、この機能の削減について、「使用可能な機能を常に画面上に表示しておきたい(参照)」ということを理由としているが、この主張にはどうも納得がいかない。

ICSのホームアプリは、初回起動時に、画面中央下のボタンを押すとアプリケーションの一覧が表示されること、アプリの起動方法等をチュートリアルとして表示してくれる。ICSでは、本体下部のボタンも画面内に表示されるのだから、ホームをロングタップすることで最近使ったアプリの機能を呼び出せることを明示すればよいだけの話である。

メニューを非表示にした理由は、これらの機能がアクションバー内部に組み込まれたからであるが、アクションバー自体がそもそもスマートフォンにおける小さな画面内に常に表示されるというナンセンスさを孕んでいる。これについては第2項で後述する。

端末の横幅を考えれば、4つのボタンを配置するのはベストのバランスであるように思う。押し間違いが生じたり、押しにくくなったり、あるいは機能について混乱が生じない限り、ボタンの数は多ければ多い程良いと私は考える。

2. アクションバーのナンセンスさ

メニューボタンはアプリにより表示位置が異なり、右上や右下に表示される。

Honeycomb以降、Googleはユーザに分かりやすいように、使用できる機能を常に画面内に表示する、というスタンスを示した。ユーザに分かりやすいインタフェースを作ろう、というGoogleの姿勢はおおいに評価できるものであるが、アクションバーの実装ははっきり言って気に入らない。

まず、アクションバーは画面の表示領域を狭める。これは、画面の広いタブレットならまだしも、画面の狭い(あるいは、できるだけ表示領域を広くしたい)スマートフォンにおいては致命的と言える。使用できる機能を常に画面内に表示したいならば、メニューボタンに対する動作が設定されたアプリケーションではメニューボタンを表示し、メニューボタンに対する動作が設定されていないアプリケーションではこれを非表示にすればよいだけの話である。

次に、アクションバーはメニューにより呼び出されるボタン類と異なり、基本的にアイコンのみの表示であり、テキストが表示されない。このため、アプリケーションによってはそのアイコンが何を意味するのか全く分からない。Gmailのアクションバーにある既読にする、はまだしも、アーカイブ等、誰が最初に見てすぐに分かるだろうか？(そしてアーカイブを押すと警告なしにアーカイブされてしまい、元に戻すのが面倒である)。更に言えば、アクションバーのボタンは既存のメニューで表示されるボタンよりも小さく押しづらい。

最後に、アクションバーの分断問題が挙げられる。これは、HoneycombとGingerbreadを統合する上で、画面の狭さをカバーするために採られたAndroidのAPIの実装上の問題であるが、これにより、アプリケーションによって、アクションバーが分断されていたりここにさらに補足、メニューボタンが画面右上にあるために非常に押しづらい、などの問題が生じる。画面が大型化する傾向にあるスマートフォンにおいて、片手で操作する上で画面上部にあるボタン、というのは非常に押しづらい。タスクバーの引き下げ等、大雑把な操作で良いものは問題ないが、小さなボタンのタップは困難を極める。

Android版Google Chrome「Chrome Beta」レビュー

殆どTwitterのまとめですが、一応記事をば。

Chrome Betaではブックマークを同期するとパソコンのブックマーク、その他のブックマーク、モバイルのブックマークの3つのブックマークに分けて表示されます。非常によく考えられた実装ですね。

パソコンで開いていたタブも同期できます。こちらは新新規タブの右下からアクセス出来、直接タブが同期される訳ではありません。先ほどのブックマークとよく開くページも併せて複数の機能が新規タブに統合されています。
どうやらChromeがコンピュータごとに同期しているようで、各々のChromeで現在開いているタブにアクセスできる機能のようです。PC側でスリープした場合は維持されますが終了した場合はここに表示はされません。

タブはカードのスタックというメタファで表現され、一番上や下でさらにフリックするとカードが上下に傾き、横にフリックするとタブを閉じます。そこ、webOSとか言わない！全体がICSのGUIと統一されていますね。

メニューには一通りの機能が集約されています。ヘルプは背景のページに、その他の端末はタブの同期機能にアクセスします。でも戻る・進む・ブックマークは再下段に実装すべきだったのではないかなぁ…

検索エンジンはGoogle、Yahoo!、Bingから。残念ながらフルスクリーンの機能はありません。非常に優れたGUIのページ内検索機能を内蔵しています。

Chrome Betaにおいて、AAはずれこそ殆どしませんが、ページ幅の扱いの関係からしばしば激しく改行が入ってしまう上、フルスクリーン機能も無いので、AA表示には向かないと言えるでしょう。AndroidでのAA表示にはFirefoxが向いています。
フォントサイズは極小でもあまり小さくならないので結局AA表示は困難です。

又、ICS以降の各種ブラウザの挙動同様 file://.* で端末内のファイルにアクセスできますが、ディレクトリを表示できない点も同様です。PC版のChromeではディレクトリにアクセスできるのでここは何とかしてほしいところです。

ページの保存機能は(たぶん)ありませんが、PC側でDev チャンネル版ChromeとChrome to Mobileを組み合わせることでウェブページのスナップショットを送信し、オフラインでも見ることができます。私はChrome to Phoneをアンインストールして乗り換えました。

2012年1月4日水曜日

Ice Cream Sandwichのフォント指定とAA対応

ICSからはxmlによるフォントの設定が可能になったので、今回はNexus Sを例にICSにおけるフォントの導入についてまとめる。今回は、MS Pゴシックをmonaya.ttfに置換し、通常の日本語文字にはモトヤフォントを用いることにする。

まずはSDKを導入する。Android SDK revision 16ではいつのまにかfastbootが復活していたので、必要なコンポーネントは最新のAPIのSDK Platform(これにモトヤフォントが含まれる。持っている場合は不要)、Tools->Android SDK Platform-tools(adbやfastboot)、Google USB Driver package(ドライバ)の3つを揃えれば良い。SDKの他に必要な物はClockworkMod Recooveryとmonaya.ttfの2つ(ぐぐって手に入れてください)。

ここから先はドライバの導入とパスの通しが終了していることを前提に記事を書くので、それが済んでいない人は過去記事を参照して頂きたい。

まず、フォントを指定するxmlファイルを取得する。管理者権限不要の任意のディレクトリをカレントディレクトリにし、ClockworkMod Recovery側でsystemをmountしたら、

adb pull /system/etc/system_fonts.xml system_fonts.xml
adb pull /system/etc/fallback_fonts.xml fallback_fonts.xml

と入力し、フォントを指定するxmlを取得する。

取得したxmlをUTF-8とUNIXフォーマットの改行コードを出力できるテキストエディタ(notepad++等)を用いて編集する。fallback_fonts.xmlでは先に書いたフォントが優先的に使用されるので、MTLc3m.ttfをxmlの文法にそって指定すればよい。system_fonts.xmlでは、MS Pゴシックの置換を行うように指定するので、以下のような記述をxmlの文法に沿って記述してやればよい。

<family>
<nameset>
<name>ＭＳＰゴシック</name>
<name>MS PGothic</name>
</nameset>
<fileset>
<file>monaya.ttf</file>
</fileset>
</family>
こうすることでMS Pゴシックをmonaya.ttfで置き換えて表示することができる。今のところ、Android上ではAA対応フォントも微妙にずれてしまうので、monaya.ttfが最もずれないで表示することができるフォントのようだ。
xmlの編集ができたら、フォントは/system/fonts/に、xmlは/system/etc/に送ってやる。

adb shell
cd system/etc
mv fallback_fonts.xml fallback_fonts.xml.old
mv system_fonts.xml system_fonts.xml.old
exit
adb push fallback_fonts.xml /system/etc
adb push system_fonts.xml /system/etc
adb push monaya.ttf /system/fonts
adb push MTLc3m.ttf /system/fonts
adb shell
cd system/etc
chmod 644 fallback_fonts.xml
chmod 644 system_fonts.xml
cd ../fonts
chmod 644 monaya.ttf
chmod 644 MTLc3m.ttf
exit

これでMS Pゴシックはmonaya.ttfに、その他の日本語＋αはモトヤフォントに変更される。あやまって文鎮化させたり不具合が起きても自己責任で。最後になるが、AA対応フォントがその文字に対応していても、うまく表示できない文字が存在するようだ(※)。謎である。

2011/01/04追記
※FirefoxやOperaでは正常に表示されるため、Android内蔵ブラウザのレンダラーが抱える問題のようです。Operaでは文字幅こそ正常なものの、一部のフォントが別のフォントで置き換わっている（ように見える。少なくともFirefoxとは異なるレンダリング結果)症状や、勝手にメールアドレスとして解釈してしまうようです。一方Firefoxはそのようなことはないものの現行版では全画面表示が行えません(ステータスバーを非表示にできません）。一長一短ですね。