読者です 読者をやめる 読者になる 読者になる

kondoumh のブログ

- とあるソフトウェアエンジニアのめったに更新されないブログ -

iPhone SE 購入

奥さん用に買いました。

今までガラケーだったので、最初はやはり安心の iPhone かなと。

そこで 4インチで女性でも片手で使える iPhone SE です。 A9 チップと M9 モーションプロセッサを搭載して性能的にも数年は十分な端末。Apple はいいタイミングで4インチの端末をリニューアルしてくれました。5s(A7/M7) でも問題ないのですが、iPhone 6s 相当のカラーバリエーションがあるのがいいですね。写真も 5s の 8MP から 12MP になって綺麗になってますし。

渋谷のアップルストアでローズゴールド 32GB を買って、駅近くのビックカメラで IIJmio の音声通話機能付き SIM を追加。

IIJmio は 音声通話機能付きを2枚、データ通信用を1枚と計3枚持っていることになります。パケットを分け合えるのもお得です。ビックカメラの BIC SIM は店頭で即日発行してくれて助かります*1

電話機としてはすんなり使い始めてくれました。フリック入力とかはこれからです。iPhone は何世代も使って操作を熟知してるので、教えるのも楽です。Nexus 以外の Android だと中々手頃な端末がないし、家族に持ってもらうのはハードルが高い感じなんですよね。

ということで、iPhone SE はそんなに高くないし、大きさもちょうどいいし、標準的な iPhone だし、家族に持たせるにはうってつけのスマートフォンだと思います。

f:id:kondoumh:20170514204615j:plain

*1:IIJmio の会員サービスで Web 申し込みだと届くまで1週間ぐらいかかるようですので。

Visual Studio 20th Anniversary

blog.kondoumh.com

Visual Studio 2017 のインストーラは Electron + Riot.js みたいです。Riot 流行るかもですね。

qiita.com

祝 2017 リリース記念ということで、僕と Visual Studio の関わりを 24年前ぐらいから振り返ってみました。完全おっさんトークです。

Visual Basic 1.0

93年ごろ、研究室の先輩に「Windows の画面がめちゃ簡単に作れる言語があるよ」と Visual Basic でフォームにボタンを貼り付けてイベントを作成するところを見せてもらいました。同じ Microsoft の QuickBasic*1 は触ったことがありましたが Windows 3.x アプリがポトペタで作れることに感心しました*2

Microsoft C/C++ 7.0

Visual でもないし、Windows がメインのターゲットでもありませんが、MS C/C++ 7.0 は C++ の GUI ライブラリ MFC*3 が同梱され Windows 開発がサポートされた最初のバージョンだったと思います。

1992 年前後、大学の研究室では Turbo C/C++*4 が使われていて MS-DOS のコードエディタ、デバッガが動いてました。そもそも C++ が登場して商用のコンパイラが出たのが90年頃なので、まだ若い言語だったのです。

MS C は高価だったため、最初に入った会社で使った時にやはり企業はお金持ってるなと妙に感心したりしました。

94年に入社した会社では MS C で PC98の MS-DOS アプリケーションを書いてました。Turbo C/C++ のような統合開発環境は付属していなかったか別売りだったのでしょうか。VZ Editor 使ってました。

当時は C/C++ コンパイラは個人的に買うには高価だったので、自宅 PC には DJGPP*5 や LSI C-86 試食版をインストールして CUI プログラムを書いていました。Linux で本物の GCC が使えるのはもう少し先。そんな Visual C++ 登場前夜でした。

Visual C++ 1.0

Windows 3.1 の SDK と MFC を正式サポートし C++ の統合開発環境 (IDE) を提供した最初のバージョン。

このころはまだ MFC ではなく C と Win32 API で開発。あまり GUI は作成せず、簡単なダイアログとか設定画面ぐらい。システム寄りのファンクションコールや高速なアルゴリズムを実装。DLL*6 や VBX*7 を作って VB の画面担当エンジニアに提供してました。

Visual C++ は 486SX 33MHz / RAM 6MB のラップトップでも軽々動いてました。DOS/V と PC98 では一応同じバイナリが動作しましたが低レイヤーのコードは分ける必要がありました。

Windows 3.x では、DDE*8 というプロトコルでプロセス間通信がサポートされていました。後発の OLE*9 が主流になりましたが、現在でも DDE は Windows のダイアログボックスで親画面とのデータ交換で使用されています。OLE によって Word ドキュメントに Excel のスプレッドシートを埋め込むということができました*10

Windows も 3.1 で成熟し 16bit アプリの爛熟期。この間に Windows NT が着々と開発され 32bit 時代を迎えることになります。

Visual C++ 2.0

Windows NT 3.1 向けの 32bit コードを生成する最初のバージョン。会社でも購入していましたが、リリースされたばかりの NT 向けのお仕事はあまりなく*11、使う機会はありませんでした。付属していた 16bit 用 の Visual C++ 1.5 を使っていた記憶があります。

Visual C++ 4.0

華々しく登場した Windows 95。

IBM の OS/2 がマシンリソースを要求するのを体験していたので 同じ 32bit OS である Windows 95 が Windows 3.1 用マシンで動くのか半信半疑でしたが、意外とさくさく動いてました*12

Visual C++ 4.0 は Windows 95 のバイナリを生成する C/C++ コンパイラを搭載。NT と同じ 32bit プロセッサの広大なメモリ空間が使えるようになりました。Visual Basic と Visual C++ は別製品でした*13

この頃ようやく C++ と MFC を覚えて、ライブラリだけでなくアプリ全体も作るようになりました。画面描画は GDI*14 を MFC の薄いラッパー経由で使っていました。

ただ、この頃の業務アプリは PowerBuilder や Visual Basic 4 などの 4GL*15 で画面を作成し Pro*C *16 で開発したライブラリや RDO*17 経由で DB 接続する方式が主流でした。画像データベースシステム*18を開発するため、Oracle から取得した BLOB を Bitmap に変換して返す DLL 関数や OCX などを作ってました。

Visual Studio 97

1997年に登場した Visual Studio の名を冠した初のプロダクト。Visual C++ 5.0 / Visual Basic 5.0 / Visual J++ 1.0*19 を同梱したスイート製品。C++ と Basic の IDE は別プログラムでした。

当初は Web を軽視していた Microsoft ですが、このバージョンで Visual InterDev という開発環境と ASP*20 という Web テクノロジーを投入してきました。僕は Web アプリは JSP*21 で書いていて Visual InterDev は使う機会ありませんでした。

翌年リリースされた 6.0 の印象が強すぎて、あまり覚えてませんが Visual C++ 4.1 / 4.2 のプロジェクトを移行して使っていたと思います。

Visual Studio 6.0

1998年リリース。Visual Studio 98 になるかと思いきや連番に逆戻り*22。 Visual Basic と Visual C++ は相変わらず別 IDE。

当時は研究所の仕事をしていて Enterprise Edition を購入してもらえたのでした。Enterprise Edition には、Visual Modeler という Rational Rose のサブセット版が同梱されており、僕を UML 厨として開眼させてくれました。

C++ では Template による総称的プログラミングパラダイムが登場し STL*23 が整備されたので、自分の MFC アプリで使っていた直行性に欠けるコレクションライブラリを駆逐してました。

Template は Microsoft でも積極的に活用され、軽量な COM*24 コンポーネントを作るために ATL*25 が登場しました。ブラウザで動作する Active X Control は MFC で作ってるとサイズが大きくて当時のインターネットの帯域では耐えられないということで登場したものです。独特な API セットでした。ATL を拡張した WTL*26 も登場しましたが、あまり流行りませんでした。今でも ATL のコードは Windows の奥深くで動作しているはずです。

この当時 C++ や Java など異種言語間でコンポーネントの相互利用を可能にする分散オブジェクト技術である CORBA*27 が登場し、Microsoft も COM の分散コンポーネント版である DCOM をリリースして対抗。Visual Studio での開発をサポートしました。これらはのちに SOAP や REST など Web ベースの技術によって超レガシーになってしまいましたが。。

開発のターゲットは Windows 95 / 98 でしたが、Visual C++ 使ってると不安定になるので開発マシンは NT 4.0 にスイッチしました。

OpenGL や GDI+ による可視化アプリ、動画からフレームを抽出してサムネイルとインデックスを生成するアプリ、IBM の 音声認識エンジン ViaVoice による音声による対話で操作するアプリなど開発してました。Windows CE Toolkit for Visual C++ 5.0 で Windows CE 機 から GPS データや画像を送信するアプリなども書いてました*28。Visual C++ で一番コードを書いていた時代です。

Visual Studio 6.0 に同梱された Visual C++ 6.0 は Windows の C++ 処理系として長く君臨し、Windows 2000 / XP 時代を通して使われました。2004年までサービスパックが出るようなロングセラーでした。

blog.kondoumh.com

この頃は Visual Studio の成熟期でもあり停滞期でもあったのでしょう。エンタープライズな分野においては、Java がイケイケで VB / C++ はレガシーになっていきました。

Visual Studio.NET 2002

ビジネスアプリ部門で Java に水を開けられていた Microsoft は C/C++ Win32 を基盤技術とした MFC / COM+ とは全く異なるクリーンでモダンな アプリケーションフレームワークとランタイムを開発、.NET Framework 1.0 としてリリースしました。Visual Studio にも勢い余って .NET をつけてしまいました。

最初 .NET Framework のホワイトペーパーを読んだときはよく意味が分かりませんでした。Java っぽいものを出すみたいだけど、Windows でしか動かない? 何それおいしいの?

J++ は無くなりましたが、J# という言語が Java -> .NET マイグレーション用に提供されていました。

自分的には .NET Framework よりも Visual C++ / C# / VB.NET が一つの IDE に統合されたのが大きかったです。と同時に MFC アプリ開発にとっては Visual C++ 6.0 の UI とのギャップが大きくて戸惑いました。

Visual Studio.NET 2003

2002 の翌年に 2003 が出て、.NET Framework 1.1 デビュー。このバージョンからエンタープライズでも .NET が使われ始めました*29

当時のプロジェクトでも、VBA で作っていたレガシーなコンポーネントを一部、VB.NET に移行しました。

blog.kondoumh.com

個人的にはポスト MFC を求めて Qt を触り始めてました。

blog.kondoumh.com

Visual Studio 2005

.NET Framework 2.0 デビュー。ようやくエンタープライズで本格的に使えるアプリケーションフレームワークとして成熟してきました。

blog.kondoumh.com

Java 案件が多かったので、.NET はスルーしてきましたが、大規模な業務システムのアーキテクチャを .NET で構築するプロジェクトに入ったことで真剣に取り組まざるを得なくなりました。

C# / VB.NET も進化し、Property, Partial Class, Typed DataSet, Delegate などが実装され、当時の Java (5.0) を抜き去りました。ASP.NET / Windows Form / ADO.NET など業務アプリを作成する上で欠かせないテクノロジーが整備されました。Web プロジェクト周りもサービスパックで強化。

blog.kondoumh.com

2006年から3年ぐらい .NET による業務アプリケーションの開発支援をしていました。

その後、.NET Framework 3.0 が登場し、LINQ による関数型プログラミングとか WPF による MVVM プログラミングなどの新しいパラダイムに触れてエキサイトしたものでした。そういえば、Silverlight も登場しましたね。

Visual Studio 2005 は業務で C++ のコードを書いた最後の Visual Studio でもありました。Visual Studio Express Editon*30 が提供されるようになったのはこのバージョンからですが、MFC はサポートされていませんでした。

iEdit は Visual C++ 6.0 から 2005 に一気に移行し Visual Studio.NET 2002/2003 はスルーしていました。

blog.kondoumh.com

blog.kondoumh.com

Visual Studio 2008

.NET Framework 3.5 をサポートした Visual Studio が 2008 年に登場。.NET 開発支援の頃は、あまり触っていませんでしたが、WPF / WCF / Entity Framework / Silverlight などの技術を積極的に使うようになりました。

blog.kondoumh.com

この頃は、日本マイクロソフトのエバンジェリストグループのお手伝いで .NET 3.5 テクノロジーを駆使した Dinner Now というリファレンスアプリのドキュメントを MSDN 用に作成したりというお仕事もありました。イベントにも参加してましたし。

blog.kondoumh.com

ASP.NET DynamicData という ASP.NET WebForm ベースの Rails オマージュなテクノロジーを使って自社の SFA アプリを開発したりもしました。DynamicData はもうオワコンになっています。Microsoft のテクノロジー戦略は節操なく変更されるので、見極めが難しいですね。

ASP.NET MVC が登場したのもこの頃ですが、Java な案件に長期携わることになり、ずっと後まで使うことはありませんでした。

Microsoft がめちゃ推しだった Silverlight で iEdit クローンを作ってみたのもこの頃でした。

blog.kondoumh.com

github.com

Visual C++ 2008 は iEdit のメンテナンスで結構長く使っていました。

blog.kondoumh.com

blog.kondoumh.com

Visual Studio 2010

.NET Framework 4.0 サポート。F# デビュー、C# は 4.0 に。Azure の開発をサポートし始めたのもこのバージョンから。.NET のパッケージマネージャ NuGet もこのバージョンで登場しました。

お仕事で、自社サービスの宣伝を兼ねて「Visual Studio 2010 と Team Foundation Server 2010 を活用した業務システム開発のライフサイクル管理」というホワイトペーパーをマイクロソフトの Visual Studio 2010 キャンペーン用に作成し、Visual Studio 2010 のローンチイベントで配布してもらいました。

そんな資料を配っておきながら、実業務は長らく Java プロジェクトだったため 2010 を本格的に使ったのは 2014年。ASP.NET MVC でパッケージ開発案件でアーキテクチャを構築しました。MVC は初めてでしたがすでに成熟期に入っており、さほど戸惑うことなくその生産性を享受することができました。

この時は .NET Framework 4.0 がターゲットの実行環境ということですでに登場していた Visual Studio 2013 と C# 5.0 を使わず、2010 / C# 4.0 / MVC 3.0 を選択したのですが、.NET Framework 4.0 をターゲットフレームワークに指定するだけで C# 5.0 / MVC 4.0 で開発できたというのは後で知りました。

Visual C++ も C++11 対応で モダン化の途上にありました。

blog.kondoumh.com

Windows Phone 7 の Developer Tools なんてのもありましたね。

blog.kondoumh.com

au から発売されていた IS12T は買おうかどうかかなり悩んだ端末です*31

www.fmworld.net

Visual Studio 2012

.NET Framework 4.5 サポート。Windows 8 のメトロスタイルアプリあらため Windows ストアアプリが開発できるようになったバージョンです。メトロはタイポグラフィと UI を融合させる斬新なスタイル*32。Windows RT という Windows から Win32 レイヤーを削ぎ落とした軽量 OS を搭載した Surface RT が登場し、iPad ではできないコンピューティングを一瞬だけ夢見させてくれました。

Windows RT 及び Windows 8.1 のタブレットモードで動作するストアアプリは、バックグラウンドになった時は活動を停止して電源消費を抑え、フォアグランドにマシンリソースを解放します。アプリ間のデータは共有ブローカー越しにやり取りする。ノンプリエンプティブなシングルタスクとグローバル領域でのデータ授受。これはまるで Windows 3.x アプリの実行モデルです。

開発は、WPF や Silverlight と同じ XAML プログラミングに、独自のイベント処理やデザイン上の規約に準拠する必要があります。例によって、ダイアグラムエディタを習作。

github.com

しかし、結局 Windows RT は Windows CE Handheld PC と同じ道を辿り衰退しました。アプリ開発者が集まらず、アプリが増えず、利用者が増えないという悪循環。個人的には期待してたんですが。これに懲りたのか Windows 10 は PC とタブレットをサポートする 2in1 OSとして、軽量化と UI 改善を果たし生まれ変わりました。Windows RT 的なレイヤーは Windows 10 の UWP(Universal Windows Platform) として生き残っています。まだ成功してるとは言い難いですが。

ということで、2012 はメトロの夢を見て終わりました。

Visual Studio 2013

.NET Framework 4.5.1 サポート。C# は 5.0

blog.kondoumh.com

2013 年 Microsoft は One ASP.NET というビジョンを提示して、フロントエンド開発における存在をアピールしていきました。 MVVM な JavaScript フレームワーク Knockout.JS 、プロトタイプベースな JavaScript にクラスベースなプログラミングパラダイムをもたらす TypeScript、WebSocket の .NET 実装 SignalR などが登場。 Visual Studio 2013 のプロジェクトテンプレートに Single Page Application が追加されたり、ASP.NET/Web API として WCF に依存しない 軽量な REST フレームワークが提供されたり。すでに 2012 で Web Essentials という Web のフロントエンド開発支援用アドインが出てましたし、Windows での Node.js ネイティブサポートなど Microsoft がどんどん Web な会社になっていきました。OSS コミュニティへの歩み寄りも顕著になりました。ということで Visual Studio Express シリーズは Community 版として提供されるようになり、MFC アプリ開発も Community 版に降りてきました。

個人的には GPU 使った可視化がやりたくて C++ で Direct 2D をちょっと触ったりしました。

www.youtube.com

Visual Studio Tools for Cordova による ハイブリッドアプリ開発の環境構築とガイド作成を実施。ブラウザで動作する Android エミュレータはなかなかの出来でしたが、Node.js が標準と違うパスに入るなど色々カオスで、今なら普通に npm で Cordova 導入して Visual Studio Code と Android Studio でいいじゃんという感じです。

昨年は .NET による基幹系システムフレームワーク開発を1年半。がっつり使いました。

blog.kondoumh.com

このプロジェクトでは GUI は残念ながら Windows Form でした。エンタープライズでは WPF はまだマイナーです。WPF も Blend 使わなくても、Visual Studio のデザイナでレイアウトできるようになったり地道に改善はされてるのですが。

Visual Studio 2015

.NET Framework 4.6 / Windows 10 サポート。Windows のバージョンはずっと 10 で固定されることになりました。 blog.kondoumh.com

Xamarin がサポートされ、スマートデバイスの開発環境の有力候補として存在感出はじめました。

Visual Studio Code とか for Mac とかマルチラットフォーム展開も盛んです。

blog.kondoumh.com

blog.kondoumh.com

あとは、なんと言っても OSS 化された .NET Core ですね。みんな使うようになるといいなぁ。

まとめ

古い記憶を辿りながら、Visual Studio との関わりを書いてみました。6.0 / 2005 / 2013 が一番使ったバージョンですね。

いろんな技術の栄枯盛衰とともに進化・発展してきた Visual Studio。インストーラーも 2012 ぐらいからかなり賢くなり導入楽になっています。英語版と日本語版のリリースもラグがなくなりましたし。当面、2年単位でバージョンアップしていくのでしょうか。

今はまた Java な案件どっぷりで、使用機会が減りました*33。C# や .NET Framework 自体は好きなので、プロジェクトがあったら使うことはやぶさかではありません。ただ、Java に比べて技術者が少ない問題があるので。。Xamarin で開発とかあったら今後も使うかもしれません。

@mattn さんのコラを貼って終わりにします。

f:id:kondoumh:20160410130320p:plain

*1:構造化プログラミングが可能な Basic 拡張言語。Visual Basic の前身。

*2:Macintosh の HyperCard を知ってたのでそれほどのインパクトは受けませんでしたが。

*3:Microsoft Foundation Class Library

*4:後の Borland C/C++。この時代は速さを表す形容詞として Turbo を使っていたのでしょう。C++ の標準化を先導するライブラリも Boost という名前ですね。

*5:GCC を DOS で使うための DOS-Extender

*6:Dynamic Link Library

*7:Active X Control の前身の OCX の前身の 拡張部品。VB eXtension?

*8:Dynamic Data Exchange

*9:Object Linking and Embedding

*10:のちに COM / DCOM / COM+ という分散オブジェクト技術に発展します。

*11:そもそもマシンの要求スペックが高くて試しにインストールすることもままならない状況でした。

*12:内部的にはかなり 16bit コードが残っていたようです。真の 32bit OS は 先に出ていた Windows NT 3.1 でした。

*13:3.0 系が抜けているのは日本未発売の Windows for Workgroups 3.11 がターゲットだったからでしょう。95 以前の日本企業では Novell NetWare が普及してました。

*14:Graphical Device Interface

*15:アプリケーションを構築するための高機能プログラミング言語の総称

*16:Oracle に接続するバイナリを生成する C のプリコンパイラ

*17:Remote Data Object

*18:今の人には意味不明な言葉だと思いますが、Web 登場前の90年代、画像を検索・表示するシステムを構築するのは大変な手間暇がかかったものです。

*19:Microsoft 版 Java。今はなかったことになっています。

*20:Active Server Pages

*21:Java Server Pages: ASP オマージュなサーバーサイドレンダリングテクノロジー

*22:結局、リリース年がつかない唯一のバージョンとなりました。

*23:Standard Template Library

*24:Component Object Model

*25:Active Template Library

*26:Windows Template Library

*27:Common Object Request Broker Architecture

*28:今なら全部 スマホで簡単にできちゃいますね。

*29:1.1 でもまだベータバージョンというべき出来で、移行に苦労してるシステムを時々見ます。

*30:Express Edition は C# や Basic など言語別に提供され、2012 からは Web や Desktop などターゲットプラットフォーム別に提供されていました。

*31:結局購入には至りませんでした。

*32:フラットデザインや Google の Material Design でも採用されました。

*33:Visual Studio Code は便利に使ってますが。

Visual Studio 2017 Community をインストール

Visual Studio 2017 がリリースされ、Community / Professional / Enterprise 全てのエディションが利用可能になりました。

現時点では、下記サイトのリンクからインストーラをダウンロード可能です。

www.visualstudio.com

Community を VMware Fusion の仮想マシンにインストールしてみました。

インストーラ改善

インストールエクスペリエンスの改善ということで、必要な機能だけを素早くインストールできるようインストーラーが刷新されました。

ワークロードが、

  • ユニバーサル Windows プラットフォーム開発
  • .NET デスクトップ開発
  • C++ によるデスクトップ開発
  • ASP.NET と Web 開発

などの単位で分類されており、必要なものだけを選択して導入できるようになっています。

f:id:kondoumh:20170308060833p:plain

ひとまず上の4つをインストールしたら30分もかからずに導入が完了しました。

なお、ワークロードやコンポーネントを追加したい場合、新規プロジェクト作成ダイアログで「探しているものが見つからない場合 : Visual Studio インストーラーを開く」というリンクからインストーラーを起動できます。

f:id:kondoumh:20170308062036p:plain

MFC 開発環境のセットアップ

MFC アプリは、「C++ によるデスクトップ開発」を選択するだけではビルドできませんでした。

インストーラの「個別のコンポーネント」タブで、

  • MFC と ATL のサポート (X86 と X64)
  • Windows 8.1 SDK
  • Windows Universal CRT SDK
  • 標準ライブラリモジュール

を追加でチェックして導入する必要がありました。

f:id:kondoumh:20170308061758p:plain

f:id:kondoumh:20170308061815p:plain

Xamarin 開発環境

Xamarin の開発をするには、28GB 程度のディスク容量が必要です。Android エミュレータが 20GB 近くを占めている模様。

f:id:kondoumh:20170308061915p:plain

仮想マシンのディスク容量は 60GB にしてたので、Xamarin 開発環境を整えるには、増やす必要があります。Visual Studio for Mac (元 Xamarin Studio) の方が良さげな印象があるので、macOS ユーザーは for Mac の Community 版相当を待った方が良いかもしれません。

blog.kondoumh.com

[追記] Visual Studio の歴史を振り返ってみました。

blog.kondoumh.com

f:id:kondoumh:20160410130320p:plain

Boot Camp から VMware Fusion に出戻り

Boot Camp でしばらく暮らしてみました。

blog.kondoumh.com

しかし、結局 VMware Fusion の仮想環境に出戻ってしまいました。macOS と同じ Peripherals で Windows 10 を使うという試みは早々に挫折してしまいました。*1

不便だったこと

Magic なデバイスとのコネクティビティ
  • Magic Trackpad でのカーソルの動きが突然鈍くなる
  • Magic Mouse の接続が頻繁に切れる

Magic Keyboard に関しては AppleK Pro for 10 64bit に課金して不満のない状態だったのですが。

macOS だと起動後即座に Magic デバイスと接続しているのに対し、Boot Camp 環境だと1回はタイプ、クリック、タッチが必要というのも地味に面倒です。*2

外部ディスプレイ周り

こちらの方が致命的でした。Thunderbolt - Mini DisplayPort ケーブルで WQHD の外部ディスプレイに接続して使っているのですが、YouTube で動画再生すると 100% の確率でディスプレイが切断されます。メインで使っている Chrome だけでなく、標準の Edge でも同様でした。HDMI 出力では切断されないので、ひとまずこれで回避していました。しかし 1080p の低解像度では不満なのと macOS に戻す時に Thunderbolt ケーブルに差し替えるのも面倒でした。

あと 解像度関係なく OS のスリープ復帰後に 動画の再生スピードが3倍速ぐらいに勝手に上がってしまう症状が。

Boot Camp との決別

以上の不具合は Boot Camp のドライバーの問題なのか Windows 10 の問題なのかよくわかりませんが、今のところ解決困難です。ということで Boot Camp ユーティリティで Boot Camp パーティションを削除。

VMware Fusion 環境再構築

仮想マシンへの移行

VMware Fusion の 7系のライセンスを持ってたのでラッキーなことに macOS Sierra と Windows 10 対応した 8.5 に無償でバージョンアップできました。Boot Camp に導入していた Windows 10 Home Edition 64 bit DSP 版の DVD から ISO イメージを作成 (Disk ユーティリティを使うと簡単です)。インストール & アニバーサリーアップデートを適用。

CPU のコアは2つ、メモリはとりあえず 4GB 割り当て。*3

インストール後ライセンス認証状態を確認したところ、すでに完了しました。Microsoft に電話してアクティベーションを依頼する覚悟はしてたのですが。。論理ユニット数が減っただけだから? 謎です。

仮想マシン設定

VMware Tools をインストールすると、本体ディスプレイ、外部ディスプレイで仮想マシンの画面リサイズ、全画面表示すると、自動的に解像度が変わります。「Retina のフル解像度を使用」はオフにしておくと、仮想マシンの HiDPI モードがオフられて若干パフォーマンスも上がります。*4

ちなみに VMware Fusion には Windows のアプリを macOS のデスクトップでシームレスに動作させる Unity というモードがあるのですが、なんか気持ち悪いので使いません。*5

共有フォルダ設定で、母艦 (macOS Sierra) の Google Drive と Dropbox のフォルダを共有してます。

導入ソフトウェア
  • Office 365 Solo
  • Git for Windows
  • WinMerge

ぐらいです。

Office 365 は macOS 側にも導入してますが、どうしても Windows 版が必要な場合が多いので。Solo のライセンスは Mac 一台で Boot Camp や 仮想マシン使っている場合に最適ですね。

Visual Studio については 2015 を入れても 3/7 に 2017 がリリースリリースされるので、それを待ってクリーンインストールしようと思ってます。

Chrome は導入せず標準の Edge で頑張ります。

Windows での Mac ライクな操作

VMware Fusion だと Mac の設定がかなり引き継がれます。

  • スクロール方向がナチュラル
  • 3本指によるウィンドウ移動
  • ⌘ + C / V によるコピー&ペースト

VMware によるエミュレーションなのできびきびとは動かず、⌘ が Win キーと解釈されメニューが出てしまったりしますが。

まとめ

ということで、ベアメタルな Boot Camp から、VMware の糖衣にくるまれた世界に戻ってきてしまいました。スワイプだけで Windows と macOS を行き来できるのは快適です。

デメリットも当然あって、

  • 動きがもっさりしている
  • 仮想マシンに CPU / メモリ資源を持っていかれる
  • Hyper-V などのハードウェアに近い機能は使えない*6

Visual Studio でエミュレータ使ったりするので動きのもっさりを許容できないと以前は思っていましたが、諦めました。仮想マシンでできないことは 別途 Windows マシンを用意すべきなのでしょう。今のところ予定はありませんが。

www.vmware.com

https://upload.wikimedia.org/wikipedia/commons/8/8e/VMware_Fusion_Logo.png

*1:Windows 用に周辺機器を取り揃えればやっていけなくはないと思いますが、目指していたものとは違うので

*2:おそらく macOS と Magic なデバイス間で特殊なプロトコルでコネクトしているのではないかと思われます。

*3:以前は、Windows 8.1 32bit からアップグレードした Windows 10 32 bit を使ってたので、リソースの割り当てによって多少の違いがあるかもしれません。

*4:Retina のフル解像度にすると Windows が勝手に HiDPI になります。HiDPI 使わなくても本体側で表示している限り、Retina にスケールアップされてるので、違いはあまりわかりません。

*5:X Window System のアプリだとシステムメニューなどは Mac のものが使われるのですが、Unity は Windows のまま。サードパーティ製の悲しさ?

*6:そもそも Home Edition なので、BootCamp でも同じですが。

遅まきながら macOS Sierra に移行

昨年9月リリースされた macOS Sierra、ずっとスルーしてましたが、半年経ったしそろろろいいかなと思い MacBook Pro 13 Retina Early 2015 に導入してみることにしました。

インストール

さようなら OS X

f:id:kondoumh:20170211130803p:plain

わりとあっさり終わりました。すぐに 10.12.3 へのアップデートが降ってきました。

こんにちは macOS

f:id:kondoumh:20170211130827p:plain

導入直後 CPU が高騰してるのでプロセスを見たら photoanalysisd というのが暴れてます。ぐぐって iCloud と写真アプリの同期を解除後、フォトライブラリを移動して OS を再起動、元に戻したら解決しました。

Homebrew パッケージ更新、IntelliJ IDEA や Visual Studio Code の更新も問題なし。見た目 OS X El Capitan との違いは全然感じられません。

Farewell Seil

起動時に Seil が警告ダイアログを出すようになりました。

f:id:kondoumh:20170211130854p:plain

そういえば、Sierra が出た直後 Karabiner が動かなくなったと言ってる人たちがいたなあと思い出しつつ Seil って Windows 用キーボードを使えるようにするユーティリティなので Magic Keyboard にスイッチした今となっては不要と気づきアンインストール。

f:id:kondoumh:20170211130908p:plain

新機能

フォルダの並べ替えが Windows っぽくなるオプションを有効化。これは地味に便利かも。

f:id:kondoumh:20170211131800p:plain

Siri が使えるようになりました。

f:id:kondoumh:20170211192654p:plain

Windows 10 の Cortana さん同様、当面活躍の場がなさそうな気がしますが。

他にも色々と新機能があるみたいなのですが、基本は小さな改善の集積なのではないかと思いました。

Boot Camp

先日からメイン環境を Windows 10 on Boot Camp にしています。

blog.kondoumh.com

この時は El Capitan の Boot Camp で使ってたわけですが、Thunderbolt - Mini DisplayPort ケーブル使って WQHD 解像度で使うと Chrome で YouTube を視聴すると切断されてしまうという不具合があり HDMI の FullHD でしのいでいます。

Sierra の Boot Camp の Windows サポートソフトウェアをダウンロードしてドライバー類を確認してみましたが、特に更新されてない模様。 ちょっと残念。

Windows 10 on Boot Camp で生活する

しばらく Boot Camp の Windows 10 で生活することにしました。

macOS と Windows の切り替えコスト

MacBook Pro 13 Early 2015 で macOS (まだ El Capitan ですが) を普段使っていて、たまに Windows 使うときに再起動して切り替えてます。最近 Windows でまとまった作業をする必要が出てきて macOS と Windows を行ったり来たりするのが億劫になってきました。自分の用途だと VMware Fusion の仮想マシンでは性能が不満という結論が出ているので、Boot Camp か Windows 専用機かということになります。

複数マシン所有のデメリット

では Windows マシンを別途買いたいかというとラップトップは15-20万円コースだし、マザーボード / CPU / GPU / メモリ買ってきて PC 組むのも面倒くさくてもうやりたくない*1

複数のマシンを所有するとそれぞれのマシンの稼働率が下がってしまうし、性能の落ちる Windows ラップトップ で妥協して MacBook Pro のパワーを使えないのはもったいない。

複数マシンを自宅の狭い机で使うには キーボード / マウス / ディスプレイの切替も考えなくてはいけなくなり地獄。

ということで Boot Camp の Windows 10 でも本来の macOS でも切り替えっぱなしで何週間でも使えるようにしていくしかないという結論に至りました。そして両方の環境で Magic Keyboard / Magic Trackpad 2 を他の入力デバイスに置き換えることなく使おうと考えました。

Windows 10 を快適に使うための設定

Magic Keyboard

Magic Keyboard のキータッチとスマートさに身体がすっかり馴染んでしまったので Windows でもそのまま使いたい。Apple Wireless Keyboard は Boot Camp でちゃんと対応されてたはずですが、Magic Keyboard だと「かな」キー /「英数」キーが効かない、'\‘(バックスラッシュ)、’|‘(パイプ)、’_‘(アンダーバー)が入力できない。。とボロボロです*2。現状お金で解決するしかないようです。

AppleK Pro for 10 64bit 概要

AppleK Pro のドライバーをインストールしてライセンスキーを取得すれば Magic Keyboard が完全に動作します。

Magic Keyboard JP は control キーが HHK と同じくファーストクラスな位置にあるのでよいのですが、caps キーも control キーとして使って左小指の肉球で押せるようにしたいです。特に Emacs では重要。これは macOS のようにシステム設定ではできないのでレジストリをいじる必要があります。

あと Windows では macOS のような Emacs リスペクトのキーバインドがサポートされていません。昔は Xkeymacs とか Keyhac などを使ってあがいたもんですが、Windows 標準のキーバインドとのコンフリクトが激しく返ってストレスになるので Emacs 以外では標準に従うことにしました。

ja.osdn.net

Keyhac - Pythonによる柔軟なキーカスタマイズツール - craftware

AppkeK Pro だと fn キーとカーソルキーの組み合わせで、Page Up/Page Down/Home/End をエミュレートできます。あとのカーソル移動は Trackpad で補うことにします。

Magic Trackpad 2

コントロールパネルの Boot Camp 設定でタップによるクリックを有効にします。MacBook Pro Early 2015 と Magic Trackpad は共に感圧センサーの Trackpad ですが、Windows 10 でもちゃんと使えます。ただし、Magic Trackpad の方は突然動きがにぶくなるという謎の症状があるので、Magic Mouse を待機させています。

スクロール方向が macOS と逆なので、レジストリをいじって macOS のナチュラルに合わせました。慣性スクロールは諦めるしかありません。

起動ドライブ

マシン起動時に Option キーでディスクを選択して Windows を起動する方法だと、スリープ開けに macOS が起動してしまいます。コントロールパネルで起動ドライブを Boot Camp のディスクにします。

Windows 10 on MacBook Pro の使い心地

マルチディスプレイサポート

ラップトップとして外部ディスプレイと繋がず使っている分には macOS と遜色ないのですが、マルチディスプレイのサポートは macOS に一日の長があります。

macOS では画面ごとに仮想画面を切り替えられるので使いやすいです。確か OS X Marvericks あたりで今の形に改良されました。Windows 10 はディスプレイをまたがる仮想的なスクリーンとして管理していて、タスクビューで切り替えるとすべてのディスプレイが切り替わります。

MacBook Pro の Retina と Full HD / WQHD ディスプレイを行き来する時、システムバーのボタンが標準の大きさにならないアプリがあります。レガシーアプリには多いようです*3

全画面

macOS の全画面はラップトップで使っている際、スワイプして切り替えるのには使いやすいですが、マルチディスプレイではさほど活躍しません。Windows だと仮想画面でワークスペースをいくつか作り (スワイプは効かないので) control + command + カーソル(左右) で切り替えます。Windows 10 は command + カーソル (上下左右) によるスナップや最大化・最小化が簡単にできるので全画面がなくても不便は感じません。このへんは macOS の方が使いにくいですね。

バッテリーライフ

macOS で使っている時と大差ない印象です。MacBook Pro 13 Early 2015 の CPU は Haswell 世代なのでかなり省電力仕様ですが、Windows 10 はこれまでのバージョンに比べてかなり軽量化・省電力化が進んでるのでしょう。Bootcamp Manager っていうサービスは CPU を占有するので切った方がよいです。

終わりに

細かいところで macOS のような洗練と安定感には欠ける Windows ですが、Ubuntu on Windows が熟成していけば開発環境も macOS から 移行できそうだし、次は MacBook ではなく Windows ラップトップにスイッチできるかもしれません。今から macOS へのロックインを解除できるよう身体を慣らしていくのもありかもしれませんね。

f:id:kondoumh:20160410125845p:plain

*1:ゲームとか VR 目的なら別ですが

*2:本体のキーボードだと問題なく入力できます

*3:iEdit もそうなんですが

ひらくPCバッグmini を購入

最近 iPad Air 2 を常に、MacBook Pro も時々持ち歩くようになり、ビジネスリュックを使ってました。しかしリュックは背負ったり降ろしたりするアクションがどうしても多くなってしまうし、満員電車だと後ろの人に気を使うしし・・とフラストレーションがあります。年末に、以前から欲しいと思ってた「ひらくPCバッグmini」注文しちゃいました。

superclassic.jp

年明けから持ち歩いてます。肩掛けタイプなのでリュックより取り回しが格段に楽。電車の中でも周囲への圧迫感がない。MacBook と iPad 両方入れるとさすがにちょっと重いですが、肩紐の生地が分厚いため荷重がほどよく分散される感じです。

f:id:kondoumh:20161224162315j:plain:w300

開口部のメッシュの部分は、ファスナーが下にあるのが「??」って思ったのですが、ベローンと開いて、小物の出し入れが簡単にできるので「なるほど」と納得しました。

f:id:kondoumh:20161224162349j:plain:w300

電車で膝の上に乗せるといい感じの作業台になり iPad や MacBook がほどよい高さで使えます。出張の時もトランクと別にこのバッグ持っていくと宿泊用の荷物と作業用の荷物をいい感じに分離できそうです。

マジックテープで間仕切りを好きな位置に調整できて、サイフやバッテリチャージャーや入館証など、毎日持ち歩く小物を定位置に入れてすぐに出し入れできるのもよいです。細いものなら弁当箱も余裕で入ります。

あと自立するのがめちゃ便利。リュックだと壁にもたせ掛けるつもりでバランス逆でこけてしまうことがよくあるのですが、そうしたストレスから解放されました。これが一番のキラー機能かもしれません。

ということで、買ってよかったです。