プログラマが新MacBookを2ヶ月間いじめ抜いた結果

2015年6月15日月曜日

Retina MacBookを4/10に注文、4/14出荷、届いたのは4/17だったので正確にはもうすぐ2ヶ月ですが。
(追記 2015/11/08) 購入から半年経ったので、この間に入手したアクセサリや使ったソフトなどの近況を更新しました12インチMacBookを使い始めて半年で買ったアクセサリと使ったアプリ、El Capitanへのアプデほかまとめ

ポエムキャンセルリンク

Macと私

この10年近く、日常使いのPCへの投資効果を信じてきた。やりたいことは常時山ほどある。バッテリー持続時間が伸びれば持っていける先が増える。高性能になればオフラインでできることが増える。軽くなれば持ち運ぶシーンが増えて作業時間を確保しやすくなる。PCへ年間数万円突っ込むことで有限な時間の利用効率が高まるならばと、他を削って予算を優先的にPC、特にモバイルノートPCへと振り向けてきた。


ハタチそこそこの頃、軽くて頑丈なWindows PCが大好きだった。さすがにLet'snoteのRシリーズはキーボードを叩きづらかったので、悔しく思いながらWシリーズを買っていた。
その後、周囲にVAIOユーザが数人居た影響もあって、ビジネスノートとしてVAIO type-Gを買った。Let'snoteと比べると液晶の綺麗さに驚いたし、四角のタッチパッドも悪くないなと思った。当時はVAIO type-Zあたりのアイソレーションキーボードを尻目に「やっぱり隙間なく敷き詰められたキーが好きだなー」と板チョコのようなキーボードを好んでいた。
ソニーがVAIO Xを出した時は最高に嬉しかった。外で軽めのコード書きをしてパワポの資料作成、変更、プレゼンをするあたりはAtom機で全く問題なかった。VGAポートとLANポートを搭載するために新形状の端子まで開発してしまうソニーという会社がとても好きだった。
2009年頃、白いプラスティック筐体のMacBookを愛用している後輩が居て、少し触らせてもらった。これがノート型Macを真面目に触った最初の機会で、大きなトラックパッドの全面をボタンとして押せることにただただ驚いた。2本指のスワイプにも衝撃を受けた。
2010年、今の会社に入ってMacを見かける機会が増えた。
当時、会社の開発用マシンは全部Windowsだった。たまにUbuntuへ入れ替えてる人が居たけれど、ほぼWindowsの世界だった。そこに数人、Macを持ち込んでいる開発者が居た。
キーボードにバックライトがついたMacBook Proから、キラキラと光が漏れるさまに感動したのをよく覚えている。
その年の後半にあったMacBook Air大幅改訂はすごく嬉しくて、11インチ版を買った。
当時はEclipseを使ってAndroidアプリ開発をやっていた。そこで、縦768pxしかない環境はほんとに厳しいのだと学んだ。作業ウィンドウを最大化したり、ツールバーの要素を削ったりと工夫してなんとか乗り切っていた。
このMacBook Airを買った直後に、GMOのアプリやろうぜ!という企画のイベントへ出向いていったのは今も良い思い出だ。そこで17"のMacBook Proを広げる人を見かけてビビったのだけど。
この頃はキーボードUS配列至上主義者だった。プログラミングをやるのに日本語配列なんて全然向いてないし、何より使いもしない「かな配列」用のキートップ刻印が嫌いだった。かといってローマ字すっきり配列のキーボードならいいのか?というと、やっぱり気に食わなかったのでハシカみたいなものだったのだと思う。
とにかくUS配列が好きという一心から、自宅ではHHKB Lite 2を使っていた。今ではこのキーボード、配列だけはHHKBだけどキータイプの心地よさ皆無と感じるのだけど、ともかく当時はその配列と長いスペースバーが大事だった。
その後、2011年の改訂で13インチ版を買った。縦900pxで最高に世界が広がった。
発売日にApple Store銀座へ並んだけれど初日の入荷無し、それでも諦めきれず有楽町のビックカメラへ移動したら売っていて興奮気味に買ったのだった。
電源延長ケーブルが日本仕様ではないという大変お粗末な話だったけれど、どうせ使わないからいいんだと自分を納得させたし、実際に使わなかった。
この頃に当時の同僚から「日本語を書くならかな/英数キーもあって、適当にカスタムできるキーの絶対数が多い日本語配列を選ばない理由がない」という話をされた。彼は自分の理想のキーボードなる絵を描いて無理くりAmazonのウィッシュリストへ登録するような、控えめに言ってクレイジーなキーボードジャンキーだったので、一理あるのだろうと思った。
が、やっぱりスペースバーは長いほうが叩きやすいじゃん!と思っていた。
その後は会社のプロジェクトの兼ね合いもあってMacとWindowsを併用するシーンが増えていった。
メモリ4GBのMacBook AirでVMware Fusion上にWindowsを飼い続けるのは辛い。VM上でVisual Studioを使うぐらいなら1GB〜1.5GB割り当てればなんとかなる。Windows Phone 8のエミュレータをVT-x/EPTで動作させるなら2GBがっつり引き渡す必要があったのでほぼホスト側が身動き取れなくなった。
BootCampも何度か試したし、BootCampとVMware Fusionの合わせ技も試したけれど、なかなかしっくりは来なかった。
そんな時に出た2013年のMacBook Pro Retina 13"は最高だった。
店頭で購入できるモデルで最大SSD容量のモデルを速やかに購入した。この頃にはもう物理的なUS配列へのこだわりは消えていたので、日本語配列のモデルを買ってキーカスタマイズ用のツールでUS配列として使うようにした。どうせキーを打つ時にキートップは見ないからいいんだと。
ここまで、SSD容量は128GB→256GB→512GBとMacを買い換える都度倍増させてきた。
単純に保持データ量が多いのと、作業内容的にUnityを複数バージョン手元にインストールしたり、100GB程度はWindowsのVMへ渡したりとしてきたため、これは必須だった。
この1年半は基本的になんでもMacBook Proでやってきた。Unityでの開発やOpenKinectからのセンサー値処理、iOS向けのアプリ開発、Android向けのアプリ開発、Windowsアプリへの改修や検証、Xamarin一式、Monoのフルビルド、boot2docker経由でのDocker利用などなど。Jenkinsを手元で走らせていた時期もあった。
Retinaディスプレイの価値は想像以上に大きかった。当然のように標準サポート範囲で最大限の情報量をディスプレイ上へ表示できるように設定した。
内蔵GPUへの半端無い負荷でカクつくことがあっても、都度細かく設定をいじって対処できた。
PCのコレクションはしていない。VAIOはすべて譲渡済み。過去に使っていたMacも、すべて知人へ比較的安価に譲ってきた。MacBook Proも無事に引き取り手が決まりそうである。
Let'snoteはさすがに古すぎて引き取ってくれる人が居ないため自宅の片隅で眠ってる。PlayStation Mobile(当時はPlayStation Suiteと呼ばれていた)でPSVita開発をする際にどうしてもWindows実機が必要だった時に少し役立った。
とまあこのように役目を終えたPCは都度手放しているので、差し引きおそらく年次の出費は5-6万円。趣味と実益を兼ねた投資額としては十分良い感じではないか。
これによって多くのコードと原稿を書いて来られたわけでもあるし。
そして2015年4月、@nobiの記事に完全なる乗せられ方をして、新MacBookを買ってしまった。これだけは言える。全部@nobiのせいだ。
時系列で見てみよう。
発表時の感想。

@nobiの記事を読んだ後、しばらく経ってから。

心のなかの抵抗。

心が揺さぶられてる。

客観的に見てもう落ちてる。

完全に買う前提。

オンラインストアで注文した直後のアガァアアアアアアアアアアア感。

ポエムはここまで。そういうわけで今回は新MacBookをしばらく使ってみた話です。

購入直前の印象

どうせCore Mに期待なんかしちゃいけないんだから一番安いものを買おうと考えました。前提として、当初はUSB 3.1でなんかの息吹感じよう、ぐらいのノリで日常的な利用割合は従来のMBPが7割/新MBが3割ぐらいだろうという読みでした。

ハードウェア面

ざっくりまとめると、案の定CPU遅いのでWebブラウザでの引っ掛かりもしばしばある一方、専用アプリで回避できる部分も多いところはスマフォと同じだなという印象です。
以下、コンポーネントごとに書いていきます。

キーボード

さすがに1日で慣れるとはいきませんでした。
慣れるまでに3日ぐらいはかかったと記憶しています。
この時間は主に、「ペコペコっぽいけど案外しっかり叩かないと反応しない」という力加減の最適化にかかった印象です。
これに慣れるまではよく右手小指エリアで1文字ミスをしていました。
1ヶ月半以上使ってきた現在ではほぼタイプミス無いのですが、それでもこれまで使っていたMBPよりは少々ミス率が高いと感じます。
今は中指や人差し指での近隣キー連打でたまにしきい値よりも下の圧で叩いてしまって打ち漏らしやすいです(kiのkとか漏らしやすい)。
基本的にキーボードは「カタカタカタカタ!」というよりは「ババババババ」としめやかに叩きたい派なので、ここの最適化はもうちょい頑張るしかないと思っています。

USB Type-C

まだ電源ケーブルへ足を引っ掛けるようなことをしていないので無事に過ごせています。
MagSafeは良かったし、無慈悲な仕様変更が施されたMagSafe2もまあ悪くなかったのだけど、もうあの日々は戻ってこないのです。
追記(2016/03/14): MacBook本体付属のUSB-C充電ケーブルがリコールされ、代替品が届いたのでざっとMacBook 12"の電源用USB-Cケーブルのリコール代替品が届いたへまとめました。

CPU

発売ぴったりぐらいに出ていた英語圏のベンチマーク結果で、2012年ぐらいのMBAと同程度というのが出ていたのでそのつもりで臨みました。案外まともに動くのですが、CPUの筋力が求められるシーンではやはり弱いです。日常的には、大きめのdmgファイルからアプリをインストールする際の検証待ち時間やインストール自体の時間、起動時間などで体感するところです。
I/O性能は出るけどコンピュート性能がさほどよくない、という点でCoreMのセグメントは完全にARMと同じだなぁというのを感じました。Atomの強いやつぐらいの認識で、さほど間違っていない感じです。
x86機の中でTDPが極力低いの、という意味ではほんとにAtomでもよかったのでは(それこそ昔のVAIO Xと同様に)と感じましたが、最近Atom x7シリーズのベンチマークを見た結果、やっぱり重量級OSであるOS Xの最低限をキープするためにはAtomではダメだったかも、と考えを改めました*1
CPUの非力さゆえか、再起動に必要な時間はそこそこ長いです。これにより再起動したくない感じが高まりました。
思えば、MacBook Proの再起動が速すぎたんですね。
個別アプリの体感については後述します。
[*1] 基本的に最近のOS XってWindowsよりもアイドル時のCPU使用多めな印象でもあります。

Taptic Engine

これはやばい。
タップ領域の右上・左上でも軽くタップが効くところにまず感動するし、タップ時のフィードバック重さを3種類から選べるのほどよいし、QuickTime Playerでの>>ボタンに細かく圧力かけていくの楽しすぎてつい「ポリポリポリポリ」と遊んでしまうし、生産性を落とすレベルで驚きがありました。よくない。

SSD

もとよりライトに使うつもりなので容量には期待していません。256GBモデルで、あれこれとアプリをインストールし、1ヶ月半ほど経過した現状での状態は図1のような感じです。
図1 1ヶ月半ほど経過した時点のストレージ状況
案外使ってますね。なんだろ、Kindleの一時データとかだいぶでかいのかな。
定番のDisk Inventory Xで調べてみました。
いろいろありましたが、衝撃的だったのは図2の通り、Atomが逐一アップデート時にアーカイブを残しているところでした。
ふぁぁ。
図2 Atomはアップデートごとにファイルをどんどん残していくらしい
ほかはAndroid SDKとNDKの一式とかXcodeとかAdobe CCの諸々とか、入れているものがそれなりに多い分という感じでした。
なお、これでも結構容量をケチるようになりました。
以前のMBPではネットからダウンロードしたインストーラ類をかなりの割合で保持していました。新MacBookでは使い終わったものは容赦なく捨てるように運用変更しました。
デスクトップ上のファイルも用が済んだら消すようにしています。
TimeMachineでのバックアップについては、アプリディレクトリとワークスペースを除外しました。これらはMacがクラッシュして吹っ飛んでも2-3hで全部復旧できるはず、という読みです。
マインドマップとか、消えるとかなり困るデータはMicrosoftのOne Driveに集約しました。Dropboxは前のMBP時に謎の同期終わらない&CPU100%張り付き現象が起こってから敬遠しています。
SSDの速度については、特に不満の出るような使い方をしていません。
計測上は前のMBPより遅いのですが、通常はCPUの限界が先に来る感じです。

バッテリの持ち

Bluetoothテザリング経由でネットへつないで調べ物をしながら書き物をするようなケースだと正味5時間使って残25%という感じです。
動画を観たりUE4を起動したりすると面白いぐらいバッテリ減っていきます。やはりCPUクロックを上げずに動作させられる範囲での稼働が前提っぽいですね。
完全にメモ用途へ絞り込んで利用すると、大体7時間は使える感じでした(この場合、重量級エディタのAtomは避けたほうが良いです)。

ファンレス機

大昔、Let'snoteのW2あたりを使っていた頃には「ファンレスじゃないとヤダヤダ!」と言っていたものですが、昨今はさほど気にならないし、購入するか否かを決定する要因ではもはやありません。どちらかというと、ファン有りで安定稼働時間が伸びるならむしろつけてくれれば良いのに、というぐらいでした。
まあ、可動部品を減らすことで故障率を下げたり、筐体内のエアフロー確保の必要を減らすことで更に薄型化を狙ったということでしょうし、特にバランスの悪さは感じません。
そうはいっても、ごく稀に図3のようなダイアログが出て「もうこれ以上の発熱はムリっす」となるのはデバイスとしての出来がやっぱり甘いな、と感じました。
図3 CPU発熱がヤバいから勘弁してくれの図
ちなみにこのダイアログは一度しか見たことありません。イスの上に置いてHulu流しっぱなしとかしていた時なので、熱こもりますねそりゃ。

Commandキーの塗装が剥げました

図4 剥げたCmdキー
1ヶ月少々で図4のようになってしまいました。
割とCommandキーに指、というか親指の爪を置いてるんだなーというのを自覚しました。
ディスプレイがMBP13"よりも狭くなった都合上、Cmd+Tabでのウィンドウ切り替えをおこなうケースが増えたというのも要因にはありそうです。
まあ、Atomでテキスト編集をしているとCmd+Sを頻繁に叩くというのもあります。

つれぇ

USBケーブル(図5の右のほう)に3,800円払ったのは確実に生涯初です。
図5 高級USBケーブル
金メッキ端子のUSBケーブルでもこんな値段はしないわけでして。
買う時には非常なるつらさがありました。
さっさとサードパーティのデザインのデの字もないようなUSB-PDケーブルが500円ぐらいになってほしい。私はそっちを買います。
アダプタも5,800円もちと高いなぁと感じます。はよサードパーティの無骨なやつ1,800円ぐらいで出て欲しいな、そのためのUSB-PDだろう、と思っています。

使い始めて1週間ぐらいでSpotlightのOpt+Spaceが効かなくなりました。ショートカットの割当先を他のキーに変えても全然ダメなので、Spotlight自体がなんかぶっ壊れたと判断しました。
しっかりとトラブルシュートするパワーは無かったので、若干後ろ向きな気はしますがYosemiteのSpotlightのパクリ元とよく言われているAlfredを遅ればせながらインストールしました。

やってみたことと所感

案外と多くのことができてしまいます。
当然、FileVaultは有効にしているため、これによる速度面のストレスは多少感じているかもしれません(意識するほどではありません)。
Windows利用については一旦すべて捨てました。Taptic EngineのWindowsドライバがまともになるまでは、BootCamp構成をとるのも無駄な気がしています。
UnityやUE4を扱おうとすると、そもそも前に使っていたMacBook Pro(13")でも厳しいところが一定あったので、動いたら奇跡ぐらいの気持ちで臨みました。

Android StudioでのAndroid用Javaコード書き

  • 案の定Gradleの立ち上がり、初回ビルドの遅さはMBPよりもひどい。これは圧倒的戦力(CPU)の差に起因する

Android StudioでのAndroid用Kotlinコード書き

  • GradleでのビルドはJavaと同様に遅さを感じるけれど、まあ一定はどうにかなる感じ
    • 新AS(+新Gradle)でGradle速くなると聞いたのではよ正式版を出してほしい
      • あれ、2.4のことなのかな??

IntelliJ IDEAでのiOS-RoboVM用Java SE 8コード書き

  • さすがにこれは初回ビルドで2,000以上のJavaクラスをRoboVMの内部形式(というかARM用のアセンブリ)に変換する工程が入るので結構厳しかった。初回ビルドの後は特に問題ない
    • ここまで来ると、別のマシンでフルビルドしてからプロジェクトごとrsyncしたほうが良いのではと感じる
    • 最近のRoboVM側のアップデートで初回ビルドがだいぶ短縮されているようなので、マシになっているかも

XcodeでのiOS(Obj-C)プロジェクト開発

  • 多少ビルドの実行は遅いけれど、あまり気にならない程度。対MBPで3割は伸びるから開いた時間に他のことやろ、というぐらい

Android-NDKでのC++プロジェクト開発

  • NDK-r9系でのビルドだと、x86向けはさておきARM向けがやはり体感できる程度には遅い
    • そろそろ下回り更新するタイミングだなーという気持ち

リモートデスクトップ(MicrosoftのRemote Desktop Client利用)でのWindows操作

  • これは元々さほど重いものではないので余裕
  • 同じLAN内に居てWindows上のVisual Studioを使ってあれこれ開発する分には、MBPと差を感じない

夜フクロウでのTwitter業

  • 起動時のTL読み込みはギリギリ目で追えるぐらいに遅いけけど、別に問題はない

Kindleでの電子書籍読み

  • 特に問題ない。快適
    • MBPだと重さゆえに持っていくのが億劫なケースで新MBなら軽く持っていけることの恩恵を一番受けたのが今のところ多分これ。おかげでダンまち全巻読破した

Calendar.app

  • 特に問題ない。快適

Atom+language-reviewでの原稿書き

  • Re:VIEWで原稿やblogを書くのに使う分には基本的に余裕
  • 400行を超えるテキストをシンタックスハイライトありで使っていると、どうも保存時に数秒フリーズするのに加えてタイピング中やたらと反応がカクカクする状況があった
    • Atomを再起動してもさして改善しないので軽く謎だった。まあAtom自体そんなに軽いエディタではないのでそんなもんかなぁ、と最初は考えていた
  • その後、原因をそれなりに調べた
    • 書いている文章のボリューム依存度は高い。あと、Re:VIEWのモジュール(language-review)を切ってPlain Textとして表示したら普通にサクサク入力できるようになったので、やっぱそういうことかなーと思った
  • 結論としては非力なCPUで文章を高頻度コンパイルしすぎていた。紆余曲折あったけれどPRを出して取り込まれたので一安心
    • TypeScriptな流儀をちゃんと身につけていきたいなーと思った
  • もの書きの中盤から終盤フェイズでは右ペインに常時プレビューを置いておきたい派なのだけど、現在のlanguage-reviewはその用途にあまり向いていないので、少しずつ手を入れようと考えている
  • Atomプラグインの改修によってだいぶ書いていくストレスが減ったので、結果さらにエントリが長くなった

Firefox

  • 気付いたらidle状態でも40%ぐらいCPUを食っている場合がよくある
    • ぽちぽちと全タブを閉じていっても結局変わらなかったので謎事象として放置
    • 暫定対応として、1日に数回(2-3回)Firefox自体を再起動するようにしている
      • 基本的に全タブきっちりリストアできるので、実用上困ることはない
      • この時に困るGoogle Play Musicについては後述
  • コンテンツに依存する部分が大きいので、サイト(サービス)ごとに

Firefoxでニコニコ動画

  • どうせコメントはガックガクだろう、と思っていたけれど、想像よりはマシだった
    • それでもヌルヌルではない。なんせ元のMBPでもそこそこ頻繁にコメントが1秒ぐらい止まって飛ぶ事象は発生していたのであまり気にならない
  • ニコ生とかはあまり見ないのでわからない
    • ニコキャス??よく知らない

FirefoxでYouTube

  • なんの問題もない

FirefoxでGoogle Play Music

  • 結構重い
    • なんというか、ひとつひとつの挙動がもたつく
      • 5月末の新デザイン化で少しマシになったような気はする
    • 再生中はFlashプラグインのCPU使用も含め、結構な割合使う(1コアの70%ぐらいは平然と使う)
    • 前述のようにFirefoxは1日数回再起動する可能性があり、そういう時にストリームが切れて選択・再生しなおしになるのは面倒
    • Radiant Playerという代替ブラウザを見つけたのでそちらへ切り出してみた。結果快適

Radiant PlayerでGoogle Play Music

本家: kbhomes/radiant-player-mac
  • Safari系WebViewベースらしいGoogle Play Music専用ブラウザ(と表現するのが一番穏当かな)
  • Firefox上での利用と比較しての快適さにしびれた
    • CPU使用率がかなり低いし、なによりも音楽再生を中断することなくFirefoxを再起動できる
      • 最少化しておくと、この非力CPUでも再生中6-7%程度しか使わない
    • Radiant Playerを使っていてCPU貧弱だなーと感じるのは、全曲リストとかうっかり開いた時。12,000曲程度だけど容赦なく20秒ぐらい固まったりする
      • ある時からマシになったので、Google Play Music側で表示方法をいじったのかもしれない
  • Fn+F7/F8/F9にマップされているMacのメディアキーを利用できるという、本家では到達できない最強感がある

Evernote

  • 相変わらずエディタ重い。これは前のMBPでも重くて嫌だった
  • 基本的に小さなメモしか最近は書かないので問題ない

Adobe Audition

  • 軽くフーリエ変換かけてサウンド分析するぐらいなら余裕だった

Adobe Photoshop

  • 小さな画像の加工は余裕だった
  • 以前のMBPで扱っていたような5,000x3600ぐらいの解像度の写真は、どうせまともに扱えないので扱わないようにしている

Unreal Engine 4

  • 発売された頃にリリースされていた4.7.5では、起動即クラッシュしていた
    • 「よしよし、クラッシュしてくれれば余計な希望を持たなくて済むぞ」と思っていた
  • 4.7.6でクラッシュしなくなった。ぐぎぎ
  • TPSテンプレを開いた状態で10-12fpsぐらい。レンダリング領域を狭くしても15-16fpsというところで、実用域ではない
    • 圧倒的にCPU不足
  • 多少のBP描きぐらいならできてしまいそうな気がするのでよくない

nodebrewでのnode.jsビルド

  • さすがに遅い。20分ぐらいはかかったと思う。向いてない→追記: @vvakameがnodebrew install-binaryでバイナリインストールすればいいよと教えてくれました。ありがとう!

Xamarin Android Player

  • 最初に試した時は、VBoxがバンドル版かな、4.3.12が入っていて、これはダメだった。起動時にOSごと巻き込んでクラッシュした
  • フォーラムを調べてみると https://forums.xamarin.com/discussion/39002/mac-os-x-crashes-when-running-emulator-via-xapに、新しいVBox入れればokということが書かれていたのでOracleのサイトから最新版*2をダウンロードしてきた
  • 結果、問題なく動作した
[*2] 4.3.28だった

OmniFocus

  • 大量のタスクがある状態でのスクロールなどには一定の引っかかりを感じるけれど、まあこんなもんかなの領域
  • 基本的にOmniFocusからは常時進捗圧を受けることが重要なので、Macを持っていける先が増えたのは良いこと

MindNode Pro

  • 少し厳しい
  • ひとつのマップに半年ぐらい追記し続けて結構巨大化するような使い方をしているのが余計良くない
    • 前のMBPでもスクロールの引っかかりは日常的に発生、ツリーの折りたたみ/展開で5-6秒程度フリーズもザラだった
    • やはり重い。輪をかけて重い
    • 今のところ、マップがあまり大きくなりすぎないように工夫するようにしつつある(試行錯誤中)

MacVim

  • なんの問題もない

GHC

  • brewからGHCを入れるタイミングで、運悪くバイナリのダウンロード中に回線が切断されてインストーラがフォールバックした結果、ソースから入れはじめた
    • たまたま電源つないでなかったので2h経っても終わらなかった
    • ^Cで止めた
  • バイナリで入れる分には割と普通、しかしやっぱunzip遅い気がする

この先について

USB Type-C事情は早々に解消していくはずなのであまり気にしていません。
直近で少し困るのは外部ディスプレイ出力ポートの乏しさですが、プレゼン系を最近ほとんどやってないのであまり問題になっていません。
USBメモリに資料を格納したうえで誰かにMacを借りたり、Slideshareへ事前に資料をアップロードしておいて他の発表者から端末を借りたり、という緊急回避的な策でも生きていけることは判明していますが、相応に迷惑なのでやはり避けるのが無難ですね。
しかし今のところ外部ディスプレイ接続には例の3口の信じられないぐらい格好わるいアダプタを買う必要があります。あの見た目はさすがに無いわーと思っていますが、MBPを手放すことになったので代わりに買おうかと思います。
KickstarterのHub+も悪くはないんですが、まあ1年ぐらい放っておけばあの程度のものは安価に入手できるようになるでしょう。
Miracastをサポートするプロジェクターがもっともっと増えるといいですね。
ディスプレイ事情以上に実用面で一番厳しいのはJava系IDEの重さです。
C++方面で使われるccacheのようなものがあると、一定はカバーできるのかもしれませんが、Javaでそういうものの存在はなかなか聞きません。加えて、Androidの場合にはclass生成とdex生成でまた差があるので面倒だろうなぁという気もします。
もうひとつビルド系では、Mono for UE4のためにMac上でのUE4ビルド環境を維持しようと思っていたんですが、Mono for UE4が終わったのでもういいです。
ともあれ。非力な環境を常用すると、リッチ環境なら力技でなんとかなる系のアプリの重さへ気が向くようになって、OSSコントリビュートも捗るので良いですね
(追記 2015/11/08) 購入から半年経ったので、この間に入手したアクセサリや使ったソフトなどの近況を更新しました12インチMacBookを使い始めて半年で買ったアクセサリと使ったアプリ、El Capitanへのアプデほかまとめ

0 件のコメント:

コメントを投稿