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

kondoumh のブログ

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

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 がほどよい高さで使えます。出張の時もトランクと別にこのバッグ持っていくと宿泊用の荷物と作業用の荷物をいい感じに分離できそうです。

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

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

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

2016 ふりかえり

今年も残り僅かとなりました。恒例のふりかえりエントリーです。

Job

フレームワーク開発 (.NET)

前半は、昨年から継続して .NET の業務アプリフレームワーク開発。機能開発は昨年暮れまでにほぼ完了しており、年明けから結合テストの傍らリファクタリング漬けの日々 (コード凍結が中々できず・・) 。性能チューニングやメモリリークの特定と修正、アプリ開発開始に伴う追加要望対応とバグフィクス、テストドライバーの改善、アプリの結合試験環境作成や保守用ドキュメント作成・・とフル回転。怒涛のプロジェクト進行によるハードワークで何回かバーンアウトしてました。

多くのコードを設計書から自動生成し、標準で縛り、開発者がロジックを書く部分を極力限定するという、いい意味で統制のとれたアーキテクチャでした (try catch も書かせません)。

性能チューニングでは、起動処理の並列化や通信の圧縮といった通常の対応はもちろん、クラスを JIT ではなく CompilerServices でプリコンパイルしておくなど、打てる手は打ち尽くすという感じでした。RDB の1000列のテーブルの更新を数秒以内に終わらせることが求められました。そんな DB 設計を許容するということ自体がありえないと思いましたが、兎にも角にもフレームワークとしては非機能要件を満たしたのでした。

フレームワーク開発が本格化してから約10か月、採用された UI コンポーネントの品質が低かったり、仕様追加が激しかったり、コードが複雑化して保守が難しくなったりといろいろと大変でしたが、経験豊かな力量ある .NET エンジニアがフルパワーで戦ってくれたおかげでなんとか乗り切れました。

.NET による開発の知見も色々と得られました。リリースに関しても、Jenkins の .NET 系プラグインや PowerShell プラグインを駆使してかなりのオートメーションを実現できました。

6月で無事卒業。

フレームワーク開発 (Java EE)

7月からは一転 Java EE の業務アプリフレームワーク開発現場に着任。ここではプロダクトコードはメンバーに任せ、仕様調整、設計レビュー・コードレビュー、チケット管理、各種自動化をやっています。

Java だと Spring や Hibernate などデファクト技術で構築することが多いので、ド標準の Java EE (JSF / CDI / JPA) には正直馴染みが薄いです。情報も少ないですし。メンバーはライブラリの実装までみて問題解決できるレベルなので開発自体はさしたる問題もなく進んでいます。やはりうちは Java 中心の技術者集団なのだと改めて思いました。

Java 8 はお初です。Lambda / (Parallel)Stream / Optional など Functional な言語機能が取り込まれて、フレームワークのコードもかなり様変わりしてます。

blog.kondoumh.com

エンプラシステムのアーキテクチャ構築・フレームワーク開発に携わって長いんですけど、お客様の事情を理解してモノを作るというところ(要約すると要件定義)で毎回苦労してます。このプロジェクトでは、まだアプリの開発は始まっていません。先は長そうです。

Writings

業務用

会社の宣伝活動も兼ねて ITmedia エンタープライズで連載させていただきました。

blog.kondoumh.com

モデリングの話は最近少ないので、一周回って新鮮に受け止められたのではないかと思います。自分としては最終回で UI の設計プロセスについて語れたのがよかったです。

はてなブログ

はてなダイアリー時代から10年以上続けてきて、今年はアイキャッチ画像も気を使うようになりましたし、広告を消したいという動機ではてなブログ Pro にアップグレード、サブドメイン使うようにしてみました。結果、更新のモチベーションに繋がっている気がします。iPad ネタが多かったですね。今後も引き続きソフトウェアやガジェットについて書いていくんだろうと思います。

Qiita

.NET の小ネタを2件ほど投稿してました。

qiita.com

qiita.com

Personal Development

iEdit

今年は初めてリリース0回。2年近く放置したので窓の杜からも消えました・・。シナリオ作ってる人がいまだに使ってくれてるようなので Electron と d3.js あたりを使ってクロスプラットフォームアプリへと式年遷宮したい気持ちはあります。

社内アプリ

社内業務支援アプリを構想中。プロトタイプの作成に取りかかっています。

昔も稼働が空いた時、同僚と SFA アプリを作りました。しかし営業支援ツールなのに VPN でしか使えず、保守工数も取れず、定着化・改善のサイクルに持って行けませんでした。今回はモバイルファースト・クラウドファーストなアプリにして改善サイクルを回したいです。お客様に DevOps の話してる時に自分達でやってないと説得力ないですしね。運用もやるつもりです。

サーバーサイドは Java 技術者が多い社内事情を考慮して Spring Boot。DB はとりあえず H2 で良いかなと。ドメインモデルを Astah で作りました。RESTFul API の設計を Swagger 使ってやるべく環境構築。全文検索も Solr とかで実装したいところ。

UI は React / Mithril / Riot.js あたりで迷っています。いずれにしても SPA で行くつもりです。

Gadgets

持ってるものは去年とさほど変わってなくて、Android Wear の時計買ったのと iPad リニューアルぐらいです。

Moto 360 2nd gen

時計 & 活動量計 & 通知デバイスとしてすっかり生活に溶け込みました。

blog.kondoumh.com

スマートウォッチの市場はシュリンクしていて未来はないという予測も出ています。時計をつける習慣がなく、スマートウォッチだから使い始めた自分のような人も多いと思うのですが。

jp.techcrunch.com

市場のシュリンクを裏付けるかのように年末モトローラのスマートウォッチ撤退のニュースが。

forbesjapan.com

でも Google はまだやる気のようです。

www.forbes.com

Android Wear 2.0 は単独でアプリのインストールができるようです。スマホのコンパニオンデバイスではなく、独立したガジェットとして発展していくという未来はあるのでしょうか。

iPad Air 2 Cellular

3年間使った Wi-Fi 版 Air とお別れして、Cellular 版 Air 2 に乗り換えました。

blog.kondoumh.com

通勤のお供に漫画リーダー、Ingress 端末、コーディング環境と幅広く活躍してくれます。MacBook Pro を持ち歩くときのテザリング端末としても優秀。iOS の進化は引き続き見守っていこうと思っています。

Nexus 6P

Nexus 6P は引き続き愛用してます。

blog.kondoumh.com

この記事を書いた時はまだ iPad Air 2 を入手しておらず、生産活動にも活用しようとしてました。

夏に Nougat がリリースされました。目玉機能の一つであるマルチウィンドウは日頃全く使わないです。Android タブレットだったら使いそうですね。

その後 Pixel が発表され、Android 7.1.1 がリリース。UI がかなりブラッシュアップされた感じです。ホーム画面でアプリアイコンを長押しすると機能のショートカットメニューが出るようになりました。iOS の 3D Touch 的な機能ですが、これも今の所全く使ってないですねえ。

多くのサービスを Google に依存しているため利便性が高い Nexus ですが、Pixel の登場でディスコンになってしまいました。Pixel の日本発売は未定ですが、FeliCa 使える iPhone に回帰する可能性もありますね。iOS も Android も差がなくなっているし Android のフラグシップモデルと iPhone の価格差も縮まっているし。iOS で不便なのは Chrome をデフォルトブラウザにできないことぐらいなので。

MacBook Pro

13-inch Early 2015 を使い続けています。macOS Sierra は未導入です。今年のモデルチェンジ、Touch Bar はともかく USB-C オンリーとかマシンパワーがアップしてないとか信者じゃないと厳しそう。あと2年ぐらいは今のモデルでいけそうな気してます。

VR とか AI で GPU パワーが使いたいならゲーミング PC がよさそうですね。ツクモが Razer Blade 扱い始めてます。スリムなゲーミングノートよいかも。

getnews.jp

VR グラス

Cardboard のヘッドセット買いました。スマホの装着がけっこう面倒 (留め金がキツめで Nexus 6P に傷がつきそう) なので数回使って埃かぶってます。

blog.kondoumh.com

Android 7.1.1 で Nexus 6P も Daydream 対応になったし日本でも発売してほしいですね。スマホの装着が楽そうでリモコンもついてるし OS がサポートしてるのは大きいと思います。

vr.google.com

Oculus Rift や PlayStation VR が発売され VR 元年と話題になりました。パーソナルコンピューティングを変えるポテンシャルを持ちつつあるようです。

SFマガジン 2016年 12 月号 [雑誌]

SFマガジン 2016年 12 月号 [雑誌]

Fire TV Stick

Amazon プライムに入りました。

MacBook や iPad でプライムビデオ観てましたが TV CM で音声認識リモコン見て買ってしまいました。Chromecast だと対応してないというのもありました。

http://stock.kondoumh.com/post/153171945022/amazon-fire-tv-stick
stock.kondoumh.com

Magic Trackpad 2

キーボードもマウスもパッドも Magic シリーズで揃えてしまいました。

blog.kondoumh.com

Software

Microsoft プロダクトの話題が多かったですね。

Bash On Ubuntu On Windows

Windows 10 Anniversary Update の目玉です。 インストールしてブログ書いただけで、本格活用には至っていません。普段はやはり macOS です。

blog.kondoumh.com

Visual Studio Code

統合ターミナルも入ってきて完成度が高くなりコードエディタの決定版になりました。

blog.kondoumh.com

Visual Studio for Mac

とうとう macOS でも使えるようになった Visual Studio (というか Xamarin Studio ですが)。

blog.kondoumh.com

今年は仕事で Xamarin にも少々関わりました。Windows の Visual Studio 2015 での Xamarin 開発は環境構築の敷居が (ハードウェア的に) 高い印象でしたが Mac 版はネイティブな Xamarin Studio ベースだけあってスムーズですね。ASP.NET Core も Java EE 並みの存在になっていくかもしれません。NET Standard の範囲でコードを書いておけばポータビリティ高そうです。

docs.microsoft.com

Emacs

25.1 にアップデート。org-mode だけは手放せない感じです。

blog.kondoumh.com

VS Code がメインになったので、不要になったパッケージや設定をダイエットしてます。

Emacs も「ソフトウェアの死」を迎えつつあるのでしょうか。

qiita.com

Coda for iOS

数年前購入したきりになっていて、今年になって活用方法を発見した web 開発ツール。機能凝集性の高い IDE として VPS クライアントとして iPad で使っています。

blog.kondoumh.com

PowerShell

今まで積極的に使おうとはしてなくて今年になって愛用者になりました。Jenkins のプラグインがあるのが助かります。

blog.kondoumh.com

Windows 10 では PowerShell が標準のコマンドシェルに置き換えられるようなので、今のうちから慣れておくとよいと思います。

fossbytes.com

DOS 互換のコマンドもエイリアス定義されているから、通常の使い方ならあまり困らないと思います。それにしてもようやく cmd.exe / BAT ファイルとおさらばできるのは喜ばしいですね。あとはコマンドヒストリとかキーバインドとかフォント表示とかいろいろ改善してほしいですが。

IntelliJ IDEA

買ったきりで活用が進んでいませんでしたが、Java の検証コード作成とかで時々起動するようになりました。社内アプリのサーバーサイド開発でも使う機会が増えそうです。Ultimate では Spring Boot がサポートされてて楽ちんです。

www.jetbrains.com

Super Mario Run

年末に公開されました。やり込みがいありそうです。アプリ内課金しました。

supermariorun.com

Services

Slack

これまで使う機会がなかったのですが、遅ればせながら社内プロジェクト用にサインアップ。IRC や Lingr からの進化を目の当たりにしました。

slack.com

常駐先では Slack クローンの Mattermost を導入して朝会や業務連絡などの専用チャネル使ったり、Jenkins の自動テスト結果通知 Bot とか Excel ファイルや Redmine チケットの更新通知 Bot 作ったりと、もはやなくてはならないインフラになってます。

Mattermost

来年は、カンバセーショナル UI が来るらしいです。

medium.com

Slack の API 使って協調作業できるアプリを作りたい気持ちになっています。

ConoHa

VPS サービス。メモリ 512MB なら \630/month で VPS を維持できます。Ubuntu 16.04.1 LTS で運用中。

www.conoha.jp

Stackoverflow

US オンリーですが新サービス Documentation がいい感じです。

Moto Body

活動量計が iPhone 5s のモーションセンサーから Moto 360 に移行したため Fitbit にデータが溜まらなくなり、Moto Body アプリに移行しました。Fitbit のデータは一応ローカルにダウンロードしました。モトローラはスマートウォッチ撤退なので、サービスも間もなくシャットダウンされるでしょう。Pebble を買収した Fitbit に戻るか Google Fit にしておくか悩ましいところです。

Moto Body | Motorola

Ingress

Ingress は今年で4周年。自分は2年と数ヶ月ぐらいやってます。年末登場した Luminarie メダルは Silver でした。野良エージェントとして細々と活動してます。現在 LV11。11月の AP 2倍キャンペーンでかなり稼いだのでメダルがあと2つ金になると12なんですがノルマがなかなか厳しい。今は、なるべくミッションやるようにしてます。

charingress.tokyo

ねこあつめ

ひたすら餌を補充して、時々ねこ画像をツイートしています。あいことば登録が日課です。

Pokémon GO

インストールして1週間ぐらいでアンインストール。自分には Ingress の方がなじみました。

Amazon Music

Google Play Music を解約して、プライムで利用できる Amazon Music に移行しました。Podcast 聴いてる時間が長いので Amazon で充分かと。昔 CD からリッピングして iTumes ライブラリで管理してた音源がバックアップもろとも消失してショックでしたが、もうあまり気にしないことにしました。音楽はストリーミングで十分かなぁ。

Kindle Unlimited

こちらはお試し期間から1か月延長して利用して解約。あまり読みたいのがなくて。

Mixlr

Rebuild.fm ライブが Mixlr で配信されるようになったのでサインアップ。リスニングオンリーです。

mixlr.com

おわりに

今年も客先でフル稼働だったので、来年はもう少し個人および社内プロジェクトへのコミット比率を上げていきたいなあ。

それではよいお年を。