  |
はてなキーワード: エミュレータとは
名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた - Qiita
この記事はよく調べてあるなぁと思う反面，事実関係の間違いも多く当時の空気感など欠けていると思う部分がいくつかある。事実関係に関しては追い切れないので参考文献を挙げるにとどめておくが，空気感のほうはいくつか書いておく。なお当該記事の「当時と今では状況が全然違うんだから，安易に『UNIX 哲学』とかいうな」という主旨には大賛成である。
初期の UNIX の歴史について興味がある向きには次の書籍をお薦めする。
Peter H. Salus『A Quarter Century of UNIX』(1994, Addison-Wesley Publishing)
和訳の『UNIXの1/4世紀』(Peter H. Salus, QUIPU LLC 訳, 2000, アスキー) は絶版のうえ訳も微妙なので薦めづらいが，原書は The Unix Heritage Society (tuhs) で PDF が無償公開されているので，英語が苦にならないのなら読んでみるといい。
また同じく tuhs で無償公開されている Don Libes and Sandy Ressler『Life with UNIX』（1989, Prentice Hall）を読めば80年代終りの UNIX の状況（XENIX についてもしっかり言及されている）や利用者目線での雰囲気もある程度判るだろう。
元記事で一番気になるのが「哲学」という語の捉え方。この言葉の強さに引きずられているように読める。でもこれ，当時は設計の基本的な考え方くらいの意味でわりとよく使われていた言葉なんだよね。たとえば米 BYTE 誌のアーカイブを “philosophy” で全文検索するとこんな感じ。
https://archive.org/details/byte-magazine?query=philosophy&sin=TXT&sort=date
ほぼ毎号のように出現していたのが判るだろう。
もっとも猫も杓子も「哲学」を振りかざしていたわけではないし，UNIX の開発者たちが「哲学」の語を好んで使っていたのも間違いないように思う。傍証の一つが AT＆T の定期刊行物『The Bell System Technical Journal』の1978年7, 8月号だ。元記事で言及されているマキルロイの Forword の初出がこれで，ネットのアーカイブから PDF が入手できる。
この号は二部構成になっていて第一部が Atlanta Fiber System に関する論文12本（全172ページ），第二部が UNIX に関する（Preface や Foreword を含む）論文22本（全416ページ）となっている。さて前述の PDF は OCR されているので “philosophy” で全文検索してみると8箇所見つかる。これが見事に全部 UNIX の論文なのだ。もちろん論文の性質もページ数も違うからこれだけで確定的なことはいえないが「日常的に使っていたんだろうなぁ」という推測は成り立つだろう。じつはマキルロイの哲学とされている部分は “Style” であり “philosophy” の語は一切使われていないというのもちょっと面白い。UNIX の開発者たちがなぜ「哲学」という語を好んだか正確なところは判らないが，それまでにない新しい考え方に基づいた OS を開発しているという意識があれば，そういう言葉を選ぶのが自然な時代だったことは間違いない。
UNIX が認知され拡がっていく過程で「哲学」も知られるようになっていった。自分が好むものの良さを他人にも識ってもらいたい，あわよくば他人もそれを好むようになって欲しいという布教活動は今も昔を変らないわけで「哲学」はその便利なツールとなったわけだ。元記事ではガンカースの著作を「外部の人間が後から打ち立てた哲学」と表現しているが，そんなたいしたものではない。マキルロイの論文に影響を受けた布教のためのああいう説教は到るところにあった。たとえば前掲の『Life with UNIX』にもしっかり Philosophy の項がある。また日本で最初期の UNIX 解説本のひとつである，村井純・井上尚司・砂原秀樹『プロフェッショナル UNIX』（1986，アスキー）には冒頭次のような一節がある。
オペレーティング・システムは，コンピュータを使うものにとっての環境を形成する基盤であるから，そのうえで生活する者の個性を尊重し，より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェアでなければならない。この主張こそが，UNIX のオペレーティング・システムとしての個性ではないだろうか。
「より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェア」とはテキストを入出力フォーマットとする単機能のコマンド群のことで，これらをパイプでつなげたりシェルスクリプトでまとめたりすることで「そのうえで生活する者の個性を尊重し」た「より良い環境へと作り上げて行く」ということだ。こういった説教はありふれたものであった。たんにそれを「哲学」の語を用いて書籍にまとめたのが，たまたまガンカースだったというだけのことである。
そしてじつは UNIX の場合，布教活動とはべつに「哲学」を広めなければならない切実な理由があった。これを説明するのは非常に面倒くさい。当時と今ではあまりにも環境が違うのだが，その違いが判らないと切実さが伝わらないからだ。マア頑張ってみよう。
UNIX は PDP というミニコンピュータ（ミニコン）上に開発された。このミニコンを使うためには専用の部屋に行く必要がある。その部屋は，もちろん場所によって違うわけだが，マアおおよそ学校の教室くらいの大きさだ。長机が何列か並んでおり，そのうえにはブラウン管ディスプレイとキーボードを備えた機器が等間隔に置かれている。壁際にはプリンタが何台かあるだろう。通っていた学校にコンピュータ室などと呼ばれる部屋があったならそれを思い浮かべればだいたい合ってる。ただし置かれている機器はコンピュータではなくコンピュータに接続するための端末装置（ターミナル）だ。端末装置のキーボードで打った文字がコンピュータに送られコンピュータが表示した文字がそのディスプレイに表示される。現在 Unix 系 OS で CLI を使うときターミナルとか xterm という名のアプリケーションを用いるがこれらは端末装置のエミュレータで，もともとは実体のある装置だったわけだ。
さてコンピュータ室にたいていは隣接するかたちでマシンルームなどと呼ばれる六畳くらいの部屋がある。窓ガラスで仕切られたこの部屋には箪笥や洗濯機くらいの大きさの装置が何台か置かれている。これがコンピュータ本体だ。もっともコンピュータが何台もあるわけではない。この箪笥が CPU でそっちの洗濯機がハードディスク，あの机に置かれているタイプライタが管理用コンソールといった具合に何台かある装置全部で一台のコンピュータになる。どこが〝ミニ〟だと突っ込みたくなるかもしれないが「六畳で収まるなんて，なんてミニ！」という時代のお話だ。
端末装置それぞれから（USB のご先祖様の）RS-232 という規格のアオダイショウみたいなケーブルが伸び，マシンルームに置かれたターミナルマルチプレクサと呼ばれるスーツケースに台数分のアオダイショウが刺さってコンピュータとの通信を行う。コンピュータと多数の端末装置を含めたこれら全体をサイトと呼び，root 権限を持って管理業務を行う人をシステム管理者あるいはスーパーユーザと呼んだ。
結構上手に説明できたと思うのだが雰囲気は伝わっただろうか。ここで重要なのは一台のコンピュータを数十人が一斉に使っていたという事実だ。洗濯機とかアオダイショウとかは，マアどうでもいい。
当時の UNIX の評価を一言で表すと〝自由で不安定な OS〟となる。メーカお仕着せではなく自分好みの「より良い環境」を作りあげる自由。さらに他のメインフレームやミニコン用 OS に比べると一般ユーザ権限でできることが圧倒的に多かった。そしてその代償が不安定さ。今では考えられないが UNIX のその不安定さゆえにプロ用 OS ではないと考える向きは多かったし「でも UNIX ってすぐ落ちるじゃん」というのは UNIX アンチ定番のディスりだった。UNIX の落とし方，みたいな情報がなんとなく廻ってきたものだ。
こういった雰囲気を鮮やかに伝えてくれるのが，高野豊『root から / へのメッセージ』（1991，アスキー）だ。当時アスキーが発行していた雑誌『UNIX MAGAZINE』に連載されていた氏のエッセイの1986年11月号から1988年10月号掲載分までをまとめた書籍である。著者の高野氏は勤務先の松下電器で1980年ごろから UNIX サイトのスーパーユーザを務めており，日本では最古参の一人である。この本の中で高野氏は繰返し UNIX の自由さと不安定さに言及している。すこし長くなるが，その中の一つを引用しよう。
CPU は，システムにとって重要な共有資源であるが，この CPU を実質的に停めてしまうことが UNIX ではいとも簡単にできる。たとえば，cc コマンドを10個くらい同時に走らせてみたらよい。VAX-11/780 といえども，同時に実行できるコンパイルはせいぜい3つか4つである。それ以上実行することも当然可能ではあるが，他に与える影響が無視できなくなる。つまり，てきめんに vi のカーソルが動かなくなる。あるいは，すこし大きめなディレクトリ上での ls コマンドの出力が表示されるまでに煙草を1本吸い終えてしまったり，タイムアウトでログインが撥ねつけられたりといったバカげた現象が起きだすのである。こういった状態になると，UNIX は破壊されたに等しい。真夜中，独りで VAX を占有して使っているのなら何をやろうとかまわない。しかし，20人30人と多数の人間が使っているときに勝手をやられると非常に困るのである。当人の仕事が遅れるのは自業自得だとしても，そのとばっちりで他のエディタまで止まってしまうと，もはやどの仕事も進行しなくなる。
ディスクについても同様なことがいえる。UNIX では，ファイルシステムを使いはたすまで大きなファイルを自由に作ることができる。したがって，自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュアが使うと悲惨なことになる。ディスクを使いはたすと，コンソール・タイプライターにエラー・メッセージが出力されるが，夜中にそれが発生して，コンソール・タイプライターが一晩中エラー・メッセージを打ち続け，朝マシンルームに行ってみると紙を一箱打ち尽くしてしまい，ピーピーと悲しげな声を上げて人を呼んでいた光景を私は何度も見てきた。こうなると，それをしでかした本人のプロセスは当然のこととしても，同じディスクで走っている他のプロセスも先に進めなくなってしまう。すこしでも負荷を夜間にまわそうとする善意は逆転してしまい，わずかでも仕事を先に進めようとする意図も完璧に打ち砕かれてしまうのである。
そして，こうした不安定さが「哲学」を必要としたのだ。自分が利用しているサイトに「cc コマンドを10個くらい同時に走らせ」たり「自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュア」がいるとその累は自分にも及んでしまう。だからサイトの利用者全員に UNIX の設計の基本的な考え方を理解してもらうことが，自分のために必要だった。UNIX の伝道がより苛烈だった理由のひとつがここにあるのだ。
ミニコン上で誕生した UNIX は 4.3BSD（1986）で最高潮を迎える。注意したいのはミニコン時代の UNIX は Research UNIX と CSRG BSD みたいな区別をせずにまとめて UNIX として扱われていたことだ。実際『プロフェッショナル UNIX』も『root から〜』も UNIX と記述されてはいるが実際には BSD を扱っている。べつに当時の人が無知だったわけではない。なにしろ BSD を利用するためにはまず AT＆T から UNIX のライセンスを購入し，そのうえでカリフォルニア大学バークレー校（UCB）から BSD を入手しなければならなかったからその関係は当然広く知られていた。ベル研で発明された UNIX を外部の人たちも含めみんなで改良し，それら全体が UNIX であるという考え方が自然だっただけである。『Life with UNIX』のような英語の文献によく登場する “Berkeley UNIX” という言い回しが当時の気分をよく表している。UNIX vs BSD みたいな捉え方は法廷闘争を経た90年代以降の感覚だ。
もっともそういう70年代風味の牧歌的風景はミニコン世界限定の話であった。BSD そのものはミニコン用のものしかなかったが，そのコードを受け継いだ BSD 系 Unix や AT＆T が推し進める System V などがワークステーション市場を舞台に80年代中盤から激しく覇権を争うようになる。いわゆる Unix 戦争で，PC 用 Unix であるマイクロソフトの XENIX も当然参戦した。ミニコン世界が牧歌的だったのは，ぶっちゃけていえば先のない技術だったからだ。ただ Unix 戦争はあくまでも標準という聖杯を争う戦いであり，AT＆T と BSD 系 Unix の Sun Microsystems が共同で System V Release 4.0 (SVR4) を作りあげたように後の法廷闘争とは趣が違う。
こうしたミニコン UNIX からワークステーション Unix への転変は Unix そのものや文化にも変化をもたらした。まず激しい競争は Unix の高機能化を加速した。商品として判りやすい惹句が「あれもできます，これもできます」なのは誰もが知っている。もちろん安定性を増すために quota のような利用者の自由を制限する機能も含まれていた。またワークステーション Unix は現在の Unix 系 OS と同様同時に一人が使うものであり前述の布教の必要性は大幅に減じた。達人たちのみの楽園から万人に開かれた道具に変ったのだ。こういった変化を体感したければ『root から〜』と水越賢治『スーパーユーザの日々』（1993，オーム社）を読み比べてみるといい。『スーパーユーザの日々』はワークステーション Unix のシステム管理の入門書だ。この本ではたんに知識を羅列するかわりに架空のソフトウェアハウス（開発会社）を舞台に新卒社員が先輩社員からシステム管理を学ぶという体裁をとっており，そのおかげで架空の話とはいえ90年代前半の雰囲気が堪能できる。出版年でいえば『root から〜』と二年しか違わない『スーパーユーザの日々』の落差は “dog year” と称された当時の激烈な変化まで体感できるだろう。
当時はよくいわれたのに今やほとんど聞かれなくなったものがある。マキルロイの論文の結論部分に書かれたそれは，1973年に出版されたイギリスの経済学者エルンスト・シューマッハーの著作の題名で，中学生の英語力があれば十分に理解できる平明な一文だ。
Small is beautiful.
マキルロイは『人月の神話』を引いて一定の留保をつけてはいるものの，これが UNIX 哲学の背骨であることに違いはない。機能をありったけ詰め込もうとして失敗した “kitchen-in-a-sink” な MULTI•cs のアンチテーゼである UNI•x にとって，これ以上のスローガンがあるだろうか？
ひるがえって現在の Unix 系 OS をみれば，ブクブクと肥え太ったシステムコール，全容を俯瞰するだけでも一苦労するライブラリインターフェイス，一生使うことのないオプションスイッチまみれのコマンド群。UNIX が仮想敵とした OS そのものだ。そのことについてとくになにも思わない。ハードウェアは長足の進歩を遂げ，コンピュータの応用範囲は途方もなく拡がった。UNIX が変らなければたんに打ち棄てられ，歴史書を飾る一項目になっただけだ。ただ現在「UNIX 哲学」を語るならそうした背景は理解していなければならないし，どれだけ繊細な注意を払ったところで〝つまみ食い〟になってしまうことは自覚すべきだ。
('ω')つ エミュレータ
ただし本家本元の再限度には多少劣る
配信すると著作権的にグレーらしいんで、ローカルでテストするだけにすべき
https://www.youtube.com/watch?v=xb7q6dvkYhw
■ファミコンのディスクシステムのCMを見ていて思った素朴なこと
ディスクシステムってファミコンにアダプター噛ませてドライブからデータ読み込んでゲームするじゃない。
これって今では当たり前のようにできる話だと思うんだけど。
でね、思ったっていうのはこの後の書く事なんだけど、まあディスクシステムを見て思っただけなのでディスクシステムの仕組みとちげーっていうツッコミはなしで。
先日さ、PS Plusのサービスが変わってPS3のゲームやらそれ以前のゲームも配信されるようになったけれど
ユーザーが求めたのって『所持しているゲームを現行機種でプレイできるようにしたい』って事だと思うんだよね。
だからほしいのは配信というサービスじゃなくて、PS2やPS3のディスクを読めるドライブと現行機種でプレイするために必要なアプリだと思うの。
それが発売されたら、購入する人って結構いると思うんだけど。
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
AndroidスマホGalaxy Note9、Windows PC、iPad Pro12.9、Fire HD 10を所持
記号は良い★★★★★＞＞＞＞☆☆☆☆☆悪い
★★★★★iPad・・・対応してないことはほぼなく殆どのゲームがおそらく快適にプレイできる。OS保証期間もAndroidより長く、数年経ってもスペックも最新ゲーム対応してることが多い。
★★★★☆Androidタブレット・・・対応してないことはほぼないが快適さではゲームによっては高スペックタブレットでもiPadに若干劣る可能性。
★★☆☆☆Fireタブレット・・・低スペックでもできるゲームならプレイできるかもしれないが恐らくスペックが苦しい。
★☆☆☆☆Windowsタブレット・・・対応してない可能性が高い。エミュレータで可能かもしれないが快適ではないし手間もかかる。
★★★★☆iPad・・・快適ではあるがAmazon Kindleアプリで購入ができない。少しだけ手間がかかる。SDカード対応してないので容量に余裕持たせたいと思ったら端末価格が高くなる。
★★★★★Androidタブレット・・・言うことなし。SDカードも対応のものが多い。
★★★★★Fireタブレット・・・動作は若干重いが気にならない程度。Fireタブレットならアレクサの文章読み上げ機能も使える(らしい)。SDカードも対応。コスパも加味すれば最強。
★★★★★Windowsタブレット・・・勿論快適だがこの用途だけのためには無駄に高い。
★★★☆☆iPad・・・無料アプリでも簡易な文書作成や表計算などができるので、端末のみで完結する簡易な仕事やネットサーフィンなどの作業だけなら可能だが、サブPC的に使うとファイル管理仕様がPCと違うため使い勝手が悪くストレスが溜まる。WIndowsやAndroidに慣れてる人なら許容できない可能性が高い。
★★★★☆Androidタブレット・・・仕事や作業などにおいて無料アプリの使い勝手では若干iPadに劣る可能性もあるが有料込なら十分可能だろう。ネットサーフィンにおいてはiOSをはるかに上回る使い勝手がいいアプリを揃えている。ファイル管理の仕様もPCと大差ないのでサブPC的に使うこともまあ可能。Galaxy TabならDexモードでPCライクに使えて快適らしいが、しかしPCと比べると流石に制限があり劣る。
★☆☆☆☆Fireタブレット・・・OSベースがAndroidなのでAndroid同様に使えないこともないがスペックが足りず作業は文書作成ですらやってられないだろう。ネットサーフィンだけでも完全に快適には使えない。
★★★★★Windowsタブレット・・・勿論スペック範囲内であらゆることが可能だろう。アプリが豊富にあるしネットサーフィンなども快適にできるだろう。
★★★★★iPad・・・液晶タブレットやPC用アプリと完全に同様にとまでは行かないまでも絵の仕事に実際使っているプロが少なからずいるくらいだから単体で絵を描けるタブレットとしてはアプリ含め最強と思われる。メモ用アプリも高機能のものが揃っている。ただ高評価で有名なアプリは安いが有料のものしかない。
★★★★☆Androidタブレット・・・Galaxy Tabなどスタイラスペン対応端末なら快適に使えるだろうし、最初からスタイラスペン付属のものもあるのでApple Pencil別売りのiPadより安く済む。イラストやメモ系アプリの使い心地や書き味などはiPadに若干劣りそう。Galaxyなら純正メモアプリだけなら数年前のGalaxyNoteの時点でApple Pencilに劣らない書き味かつ無料。しかしサードパーティ製アプリだと遅延が発生する。現在は改善されてるかは分からない。
☆☆☆☆☆Fireタブレット・・・全くできないということもないだろうがスペック的な面で向かない。
★★★★☆Windowsタブレット・・・surfaceなどがスタイラスペンに対応しているしベースがWindowsなのでアプリ面では最強だが、ペンの使い心地がどの程度Apple PencilやGalaxy Sペンとどれほど勝負できてるのか分からない。
iPadを買えばいい。Androidでも悪くないがiPad系の方が快適安心。
それくらいならiPadの安いものや昔の安いiPadの整備品でも安いAndroid系でも十分使えると思うし財布と相談してどれでも好きなのを買えばいい。
1万前後のFireタブレットですら十分使えるのでコスパ最強、と言おうとしたが(書いてたが)、Fireタブレットには一つ注意点があるのを思い出した。
イヤホンジャックがあるので有線イヤホン使う人は問題ないが、ワイヤレスイヤホン使う人には向かない。
イヤホンを低遅延モードにしても動画再生で遅延を感じる。Amazon Primeの動画なら調整してくれるのか問題ない気がするが、YouTubeその他だと遅延が起こる。
スマホゲームやらないならWindowsタブレットが何でもできて最適。スマホゲームやるなら高スペックAndroidタブレットなら何やるにも及第点。
Chrome bookはPC同様にネットサーフィンできる上にスペック(GPU)的に本家Androidほど自由ではないが同じAndroidアプリを入れられて融通きくしコスパ的にかなりいいらしい。
iPad＋Apple Pencilを買えばいい。Android(Galaxyタブ)でもいい。
大画面が良ければ現状Pro12.9インチ一択。その他は色々解説してるApple好きが多いので好きに調べればいいし迷ったらAirが丁度いい。Proは殆ど意味ない。
無印やminiも快適に使えるだろうが個人的にはスマホ持っててmini買う理由がよく分からない。どうせタブレット買うなら10インチ以上がいいと思う。
あと仕事やゲーム、動画編集などでガッツリ使うとかでなければ容量は128GBか256GBでいい。サブPC的に使えると思って安いところで512GBを買ってしまったが、ファイル管理仕様の問題でサブPC(メインPCの一時的SSD的な用途込み)で使えなかったので無駄な512GBになってしまった。
M1 iPad Pro12.9を買ってしまった自分が買う前の過去の自分に助言送れるなら2in1 WindowsタブレットPCを勧めたい。
結局作業にしてもネットサーフィンなど暇つぶしにしても画面が大きいならPCと同じように使えるのが1番使い勝手がいい。つまりWindowsがベストで、タブレット的にも使えたら持ち運んでの使用も楽でいい。
スマホ持っててPC持ってない、PC持たず不自由なく生きてこられた人ならPC的な使い勝手いらないだろうし結局安定のiPadでいいかもしれない。
なんでもそれなりに使えるタブレットがいいならAndroidのGalaxy Tabがいいと思う。自分も最新のGalaxy Tab S8＋/S8 UltraとiPad Pro12.9で迷った。
自分の場合スマホゲームとほぼ訣別できてるしやるとしてもAndroidはスマホがあるので、Windowsタブレットが結局1番よかったと分かった。
ただWindowsは快適に使おうとしたらそれなりのスペックを要し価格が上がるので比較的低スペックでも快適に使えてPC同様にネット見れてChromeに拡張機能も入れられるChrome OSは使う内にやっぱあれもこれもしたい(本格的な仕事やお絵描き、スマホゲームなど)とか言う性格じゃなくネットサーフィンや電子書籍、動画で用途が完結するならよさそう。
ちなみにiPad買う前にいろんな動画やサイトでタブレットを調べてた時、「Android＆Windows信者でもタブレット買うならiPad一強になってしまってる」という話を多くの人が言ってるのを見たが、買った結論としていうほどiPad一強じゃないと思った。ただApple Pencilは確かにいい使い心地。
中国との距離が近いことから、日本国内にあるのが米国から見れば安全保障問題となる。
企業側としても、需要のあるところに近い方が輸送コストの削減、先端プロセスの要望を受けることができる。
日本の大学が、装置メーカー、材料メーカーにとって他に代わりにならないような教育や研究を実施しているわけでもない。
大学の研究時に、装置が入手できない、見たことがないので探せないということに波及。
半導体の入手が出来ないことに注目されているが、他のリスクがある。
自動車向けの共通OSを1社独占、OSが動く半導体が独占される。
AndroidのようにOSの発表と同時にハードを作って発表する場合、OSを先行リリースをしてもらう必要があるが、
（OSメーカーは差別化となる技術は社内に数年発表せず先行する)
例えば出荷試験をするための装置やソフトなどの一式を購入しないと規格認定されない、という事態がありえる。
OSが先行して提供される企業と、開発期間が半年ほど違うといったスケジュール的に不利な立場になる可能性もある。
米国独占
エミュレータと呼ばれるソフト的なシミュレーションより早く結果を出すハードウェアもある。
トランジスタ数のスケーリングに対して設計ソフト(EDA)のスケーリングが十分ではない。
設計ソフトが対応していなければハードが作れない、1企業の要望で開発できる規模でもない、
先端プロセスに対応する場合、そこで起こる問題と、その回避方法を開発ソフトに取り込む必要がある。(ファブレスでは無理)
実装がGithubに転がっていない、詳しい論文は出てこない、など、米国が独占している理由の一つ。
製造に関する売上に比べると金額規模は減るが、設計ソフトで対応している範囲内でしか半導体は作れない。
なお設計ソフトの数と機能も膨大になっており、使いこなすためのノウハウ共有も必要となる。
(ネットでピンポイントではなく、ソフトウェアのドキュメントを読み込み、評価といったことが必要となる)
AIチップや自動運転チップに注力するとしても、人材育成にそれなりに時間がかかる。
実際にチップを作って不具合の評価、対策からのデザインルールへのフィードバックも必要となる。
(TSMCから提供されるライブラリを使えば不具合が起きなくなるわけではない。確率は減る)
Appleのように巨大な最終製品を作るメーカーに振り回される。
インテルですらAppleにモデム不採用になったら事業ごと売却を迫られる。
また半導体は長期的に周辺にあるものを1チップに集積していくため、最初は採用されていてもAppleが自前で作るようになるといったことも起こりうる。
物理限界への挑戦といった、リスクの高い部分を請け負うことになる。
開発したとしてもノウハウをもっと安い地域へ展開されるリスクもある。
開発として従来の製品に対してより優れた数値目標を設定することになるが、最終製品のノウハウがないため、次第に過剰品質とコスト高に陥る。
最終製品を作っている企業は、リッチなCPUとソフトウェアでより安い部品で良いかを検討するが、それは部品メーカーからは見えず、ある日採用されないという事態になる。
ハードを捨ててソフトのみに行った場合、差別化要因にならない。
ソフトはすぐに真似られる。(クラブハウスがTwitterやFacebookにすぐ真似られたように)
Googleが真似られないのは膨大なサーバーに裏打ちされている。
衛星といった特殊なハードから取れるデータを活用するといった部分も差別化要因。
CPUやGPU、スマホのような目に付きやすい部分は情報が集まりやすく、それ以外の情報は集まりにくい。
もちろんプレスリリースや論文のみであり、公開しても良い情報である。
1人では難しく、複数の分野の情報を集めて横断的に分析できる組織が必要となる。
既に日本の場合は設計情報を集めていたSTARCはなくなっており、AIチップ設計を進める場合、そういった団体の支援から必要となる。
作ったは良いが売れない、赤字を垂れ流し続けるというのを防ぐために、ニーズの分析も必要となる。
いやはやまったく、はてブにあがってたので読んでしまったが、久々にあまりにも酷いレビューを読んでしまった。あぁそうそう引用している記事にはアクセスしなくても良い。時間とトラフィックリソースの無駄だ。
記名は編集部となっているが、Business Journal編集部員の質はこの程度なのか？まるで「私たち編集部はWeb検索すらしないで又聞きした情報を記事にしています」と宣言したいがために記事を公開したのかと邪推したくなる。
1つの記事へ膨大な時間を掛けて執筆することは生産性を考慮すると悪手であるのは間違いない。しかし、いくらなんでも"ほど"があるだろうと言わざる得ないのだ。
下記の理由からBusiness Journal編集部は当該記事の編集部員へ二度とゲーム記事は書かせないほうが良いと"ご意見"をよせさせて頂く。
当該記事では太正100年が既存のサクラ大戦シリーズとの歴史的連続性の無さを指摘しつつ、蒸気エネルギーが排除され主要エネルギーが採用されたことへ対して非難の声がよせられていると書いている。
しかし、太正100年は西暦で言えば2011年である。半世紀以上の時間が経過していながらサクラ大戦シリーズはいまだ蒸気エネルギーへ依存し続けなければならないと本気で思っているのだろうか？
そして、歴史的連続性の無さを指摘しているが現在公開されているサクラ革命のシナリオは、チュートリアルと九州編と中国編(そして九州を舞台としたサイドシナリオ特別イベント)のみだ。
サクラ革命は47都道府県を舞台としようとしているのは現状で明確にわかる。つまり素直に受け止めれば45シナリオが残されている。全体のシナリオ進捗は約4.25％であり、この状況ではサクラ革命がサクラ大戦シリーズでどういう立ち位置なのかほぼわかっていないとWeb検索するまでもなく察することが出来るので、なぜこれを"爆死＆大炎上"の理由としたのか本気で謎である。
サクラ革命を現状で物凄くやり込んでいるプレイヤーすら何もわかっていないのに、何をわかったつもりで居るのか。
サクラ大戦シリーズにおいて蒸気エネルギーは主要エネルギーとして確かに重要であり、サクラ大戦シリーズを彩るスパイスとして無くてはならない存在であるのは間違いない。
しかし、サクラ大戦シリーズにおいてスチームパンクはスパイスであってメインの素材ではなく、あたかもサクラ大戦シリーズはスチームパンクだからこそ支持されていたかのように描くのは誤解である。
サクラ大戦シリーズファンへはわざわざ説明するまでも無い話だが、申し訳ないけれども知らない読者のためにも付き合って頂きたい。
端的にかつ簡潔に述べるならば、サクラ大戦シリーズは「アイドルマスター」シリーズのご先祖様である。
サクラ大戦シリーズは宝塚歌劇団をパロディした作品であり、その痕跡はキャラクター名や帝国華撃団など各名称に現れており、歌って踊り、企画段階で強くメディアミックスを意識され、当時の声優業界すら巻き込んで現在にもその影響を残しているターニングポイントだった作品だ。
霊子甲冑のデザインを著名なメカデザイナーが手がけているなど日本のSFとして決して軽視できるものではないが、宝塚歌劇団のパロディとしてゲームに落とし込んだという要素に比べればスチームパンク要素は些細と言って過言ではない。
だから「戦うアイマス、アイドルマスター XENOGLOSSIAかよ」と一部のユーザがそう感じてしまうのも仕方ない。ご先祖様なのだから。
ついでに誤解なきよう言及しておくと、蒸気エネルギー要素はディスコンされていない。当該記事の書き方では蒸気エネルギーがディスコンされてしまったものと誤解する読者が出てきそうなので。
これにはサクラ革命プレイヤーとプロジェクトセカイプレイヤーの双方が怒って良い。というか既に怒っているだろう。
どういう神経でプロジェクトセカイを持ってきたのか呆れて果ててしまう。
現代のサブカルシーンでは主題のコンテンツを貶めるため他のコンテンツを持ってくるのは禁じ手とする傾向が強くなってきているのを読み取れていないのか。
作品Aはカワイイ、作品Bもカワイイ。どっちもカワイイ。どちらがカワイイのではないどちらもカワイイ。
これが現代のサブカルシーンであり、当該記事の書き方はまるで10年前のゲームハード戦争真っ直中の素人レビューのようだ。
他のコンテンツを貶める暇が在るなら推しコンテンツを布教しろ。
Business Journalとかいう質が低すぎる文字同人サイトの誤りを指摘したので、次は実際にサクラ革命プレイヤーである筆者がサクラ革命が非難される理由を書こう。
ネタバレになるので詳細は控えるが、サクラ革命で現在配信されている3つのメインシナリオであるチュートリアル、九州編、中国編すべてでお涙頂戴が展開される。
しかもお涙頂戴の起因が3つとも同じだと言って良い。どれだけライターはこのシチュエーションが好きなのか。流石に3連続、というか配信されているすべてのメインシナリオがコレなのはおかしいだろう。
この繰り返される同じお涙頂戴シチュエーションについてはTwitterでちょっと検索するだけで出てくるので当該記事を書いたBusiness Journal編集部員はおそらくWeb検索すらしてないと思われる。
Twitterユーザーの100文字に満たないツイート、例えば「お涙頂戴繰り返すからサクラ革命のシナリオは微妙」みたいなレビューよりも質が低い上に、あれだけの文字量なのだから執筆時間もTwitterユーザーのツイートより掛けているだろうから生産性まで低い。圧倒的な質の低さである。お前Twitterユーザー以下だぞと。
サクラ革命の戦闘シーンで敵ユニットが毎ターンほぼ確定で自ユニットへ弱体化補正(いわゆるデバフ)を決めてくる。
つまり、敵ユニットが自ユニットへ対して攻撃力や防御力、必殺技ゲージの低下を(自ユニットが弱体化耐性を持っていない限り)毎ターンほぼ確定で決めてくるのだ。
ディライトワークスが開発するスマートデバイス向けの別ゲームタイトル「Fate/Grand Order」のプレイヤーならば慣れているゲーム設計と言えるが、ディライトワークス製ゲームを初プレイするプレイヤーに取っては不快なゲーム設計だろう。
サクラ革命はスマートデバイス向けRPGでありがちな、いわゆる「育成周回」が必須のゲーム設計となっている。
そしてサクラ革命には攻略ステージ毎へ親切にも自ユニットの適正レベルが記載されているのだが、どうやらこれは自ユニットの攻略ステージ開始時の初期ステータスを基準にしているらしく、適正レベルへ至っていてもターンが進む毎に敵ユニットから弱体化補正をかけられ続けると攻略が困難になってくるのだ。
当然、非常に高度な立ち回りをすると苦戦しつつも結果的に勝利を収められるが、忘れてはならないのがサクラ革命は「育成周回」が必須のゲーム設計なのである。
「育成周回」しなければならないのにターンを膨大に重ねるのは非効率なので、ここに矛盾が生じて慣れていないプレイヤーはストレスを感じてしまう。
「Fate/Grand Order」プレイヤーはこのゲーム設計に慣れているので即座に「最短ターンで編成を組むのがサクラ革命の最適解」と察して行動を取れたが、ディライトワークス製ゲームを初プレイしたプレイヤーはより一層のストレスを抱えているだろう。
これは完全にディライトワークス製ゲームのプレイヤー間の内輪ネタだが、ディライトワークス製ゲームにとってバグは"お家芸"である。何も笑えないが、ネタにして笑い飛ばすくらいの胆力がないとディライトワークスには付き合っていられない。
「Fate/Grand Order」でもローンチ直後から様々なバグがあり、その伝統は本作にも引き継がれ、大いにプレイヤーを笑わせてくれている。・・・その笑いは失笑かも知れないが。
筆者が笑ってしまったのはローンチ初日、サクラ革命もアプリ初回起動後に追加データダウンロードというゲーム系アプリにはありがちな仕様(初回起動時に追加データダウンロードが発生するのは各アプリストアの仕様上の制限である)で、ダウンロードプログレスバーが表示されている間に、登場キャラクターの簡易プロフィールが読めるという演出になっていた。ダウンロード中にプレイヤーが飽きてしまわないよう配慮された仕様だ。
しかし、この簡易プロフィールのデータがどうやら初回起動後の追加データに含まれていたらしく、1人目以降まったく簡易プロフィールが読めないというバグがあった(現在は修正済み)。ゲームプレイする前からわかりやすいバグが発見できる。これがディライトワークス。
サクラ革命を実際にコーディングしている開発者からすると変な汗が出る初歩的なバグであるのは筆者も情報技術者の末席に連ねる者としてお察し出来るので心身痛み入る、まぁそういうこともあるさという言葉を送りたい。
こうやってディライトワークス製ゲームプレイヤーが開発元ディライトワークスをイジるのが内輪ネタというわけである。
「Fate/Grand Order」のバトルシステムは登場当初スマートデバイスでもバトルっぽいことができると示した素敵なエコシステムだが、サクラ革命のバトルシステムはそのエコシステムのエコさ加減を最大限に活かしつつ、ちょっと戦略性を上げましたというバトルシステムである。
サクラ革命という新しいゲーム開発へ関わったのだから「もうちょっとなんかあったやろ」というツッコミが方々から聞こえてくるが筆者としては1周回って「ディライトワークスだしコレで良いんじゃね？」と思えてきている。
詳細なバトルシステムが気になる人はYoutubeか何かで観たほうが早いだろうし割愛する。所詮はポチポチゲーですよ。
筆者としては歌劇シーンを観ることができると思ってサクラ革命をインストール事前予約してまで期待して待っていた(ディライトワークスなのでバトルシステムは鼻から期待してない)のだが・・・観れないんだなぁ・・・(遠い目)。
いやコチラが勝手に期待したのが悪いっちゃ悪いんだが、3DCGでやるって言うんだもんアイドルマスターみたいな歌劇シーンを期待しちゃうじゃないですか。もしかしたら初代サクラ大戦のメンバーとかもスペシャルゲストとして動いてる様子が観られるとか思っちゃうじゃないですか。
このあたりが怨嗟を生んでる気がするんですけど、ディライトワークスさん1周年イベントで良いんで歌劇シーンやりましょうや。
悪いところばかり挙げるのもアレですし、とりあえずプレイせず様子見している"司令"も居るでしょうから良い点も挙げておく。
初代サクラ大戦のイメージを引っ張っている司令からすると違和感が物凄いけれども、慣れてくるとこれはこれで良いものなのではないかと思えてくる。
ただモーションは固定なので高く期待するほどでも無い。
サクラ革命ではガチャゲーで、アイテムや装備も一緒に排出されるいわゆる"闇鍋ガチャ"であるが、☆5キャラの排出率が恒常ピックアップ☆5キャラが0.375%で「Fate/Grand Order」と比較すると悪くはない(FGOの恒常ピックアップ☆5キャラは0.029%)。
筆者もそうであるが、コレクター的な性質を持つプレイヤーならば出費少なく結構簡単に現行でガチャ実装されているキャラが揃ってしまうので、その辺は気持ちよさがある。
ちなみにガチャで所有キャラが被ると必殺技の性能が向上するという仕様。最大でLV20。
前述したとおり、ガチャで所有キャラが被ると必殺技の性能が向上するという仕様だが、ガチャでなくとも必殺技の性能を挙げるためのアイテムが存在する。
いわゆる"箱推し"でなく"嫁"を愛でる性質を持っているプレイヤーであるのならば自由意志で集中してアイテムリソースを注ぎ込むことが可能だ。
一部の読者からすると途端にマニアックな話になって申し訳ないが、サクラ革命はChrome OSのAndroidエミュレータで動作可能で、Chrome OS上のGoogle Play Storeで普通に配信されている。
これはおそらくAndroidアプリ開発の統合環境Android Studioの仕様で、デフォルト設定だとChrome OSでの動作が許可されているためだ(ちなみに「Fate/Grand Order」も動作する)。
筆者は細かな検証をしていないが、どうやら新しいApple Sillicon M1を採用したMacでは動作しないようなので、この点だけはほんの少し新しいMacbook Airよりも一歩、いや半歩だけ進んでいると言って良い。
ただ、どうやら配信されるバイナリはARMアーキテクチャ向きのものであり、x86(x86_64)アーキテクチャ向きのものではないようで、そのためかレンダリングへ一部不具合を抱えている上に動作が重い。これが半歩の理由。
Chrome OS上でサクラ革命の動作を検証した筆者のChrome OS環境で最大スペックのものはCPUがCore i7-10510U(第10世代)でワーキングメモリ16GB、M.2 SSD 512GB(PCI Express 3.0)であり、それでも「軽快さはないがプレイに全く支障はない」くらいの重さを感じるので、現状でサクラ革命をChrome OSでプレイするならこの程度のスペックは必要になると思われる。
情報技術者としては今後デスクトップおよびラップトップコンピュータでスマートデバイス向きアプリケーションが動作するのが一般的なのは目に見えているので、アプリ開発者はデスクトップおよびラップトップ向きのハードウェアサポートを検討する時代へ突入し始めていると多少の意識を向けたほうが良いのかも知れない。
例えば、各アーキテクチャへ最適化されたバイナリや、スマートデバイスではあまり意識されてこなかったハードウェアキーボードのサポート、シングルタップ時とマルチタップ時のトラックパッドの振る舞いの違い、変動するアスペクト比など挙げればキリはないので頭が痛い話だ。
<
