日常の ToDo 管理を org-mode から Trello に移行した話

プロジェクト管理、文書作成、そして日常におけるタスク管理を org-mode でやってました。

blog.kondoumh.com

org-mode はプロジェクト管理や、文書作成ではすごくワークするのに日常のタスクは一向に片付かないという問題を抱えていました。

プロジェクトや文書執筆はそれなりに時間がかかる難易度の高いタスクの集合であり、タスク間の依存関係も複雑なので、パソコンに向かってじっくり集中して管理する必要があります。対して日常の ToDo は単純なタスクが多く、空き時間に優先度の高い順から片付けていくやり方が向いています。なので、モバイルでサクッと更新できる方が捗るんでは？と思いました。

org-mode はとても素晴らしいのですが、モバイル対応が進んでいません。公式アプリ MobileOrg や Android 専用 Orgzly がありますが、使いこなせず挫折しました。Emacs をスマホやタブレットで使うのは厳しいです(サーバに ssh で繋ぐ必要があるし物理キーボードがないと入力無理だし)。

org-mode 以外の GTD 的ツールにはほとんど馴染みがなかったのですが、ずっと前にサインアップしていた Trello を本格的に使ってみることにしました。Google Keep とかでもよいのかもしれませんが、Trello はあの Stackoverflow の Joel Spolsky 先生のプロダクトですし。

生活関係の TODO を org-mode から Trello に移行してみた。

— MH (@kondoumh) 2017年7月9日

もちろん Android / iOS のアプリがあるので、Nexus 6P / iPad Air 2 にインストールしました。

Trello では、ボード - リスト - カード という3階層構造でタスクを管理します。ボードは Redmine などの ITS におけるプロジェクトに相当すると思います。カードがチケットに相当するタスク。

org-mode のテキストから Trello のリストやカードを作成して使い始めたのですが、なんか違和感が。

• リストが横にしか並べられない (PC のブラウザだけでなく、縦に並べた方が見易いはずのスマホやタブレットでも)
• カードはリスト間をドラッグ&ドロップで移動できるのに全然移動することがない
• そして完了したカードはアーカイブするしかない

ここで、ようやくリストは、カードのカテゴリではなく、カード(タスク = チケット) の状態 (ステータス) として使うべきだったと気づきました。

Trello の使い方間違ってた。ボード - リスト - カード という階層でボードがプロジェクト、カードがタスク(チケット) というのは OK なんだが、リストをタスクの分類として使ってた。実はタスクのステータスとして使うべきだった。つまりカンバン。

— MH (@kondoumh) 2017年7月19日

org-mode からの移行時に、何も考えずリストをカテゴリ(チケットの種類)として使っていたのでした。Trello がかんばん方式を具現化したツールと知っていたはずなのですが。。ツール間のメタモデル変換が脳内でうまくできてなかったということでしょうか。

何を今更な話だけど。。カードを Todo / Doing / Done にしたらうまく回り始めた。カードが横にしか並べられない理由もこれだったのか。

— MH (@kondoumh) 2017年7月19日

このツイートは、カードとリストを間違えていました。

スマホやタブレットでいつでも更新できるのはやはり便利です。思いついた時に ToDo を追加できるし、カードの並び順を優先度として表現してもわかりやすいですし。日常の細々としたタスクが整然と管理できるのは、職業柄か安心感がありますね。

Trello は JIRA で有名な Atlassian に買収されています。

japan.blogs.atlassian.com

Trello は Atlassian に買われたらしいけど、今のところJIRA のフロントエンドじゃなく、プロダクトのラインナップの位置づけみたい。チケット管理システムのビューにもなれそうだけどね。

— MH (@kondoumh) 2017年7月19日

課金すると色々な機能が解除される模様ですが、とりあえずミニマムなフリープランのままでも、個人の日常 ToDo 管理には十分機能してくれてます。

ということで、今更感ありますが Trello 使い始めたという話でした。

Visual Studio 2017 for Mac Community をインストール - Xamarin.Forms アプリを試す

Visual Studio for Mac の正式リリース版を試してみました。

目次

Community 版が正式リリースされていた

昨年 Preview 版が登場した Visual Studio for Mac。

blog.kondoumh.com

今年5月に正式リリースされてたみたいです。ウォッチしてなくて気づいてませんでした。Windows 版同様 Community 版が提供されています。

www.visualstudio.com

インストール

早速ダウンロードしてインストールしてみました。

キャッチーなスプラッシュウィンドウです。

フルインストール。

進行中。それほど時間かからずに完了します。

起動。

プロジェクトのテンプレートは Preview 版と変わらない模様。

Xamarin.Forms などのプロジェクトで Mobile Backend の プロジェクトを追加して Web API を利用するには、.NET Core を別途インストールする必要があります。 ↓ のページにしたがってインストールします。

www.microsoft.com

事前に openssl を導入し、/user/local/lib にシンボリックリンクを作成する必要があります。あとは、ダウンロードした pkg を展開してインストールします。

インストールが終わると、pkg ファイルを削除するか聞いてくれる親切インストーラです。

これで、準備完了です。

Xamarin.Forms アプリの作成

ソリューションの作成

Xamarin.Forms アプリのソリューションを作ってみることにしました。Android / iOS にチェックを入れ、アプリの名前を入力。Mobile Backend にもチェックを入れておきます。

「作成」ボタンをクリック。

プロジェクト構築中。Nuget で何やらいっぱい取得してます。

終わりました。

おもむろに実行ボタンを押してみます。デフォルトプロジェクトは <AppName>.iOS になっており、エミュレータが起動してアプリが実行されました。

Android のプロジェクト (<AppName>.Droid) を実行すると、Android のエミュレータが起動し、同じ Forms アプリが実行されます。

ソリューション構成

ソリューション構成をみると、<AppName> プロジェクトにプラットフォーム共通のコードが配置され、<AppName>.Droid と <AppName>.iOS にプラットフォーム固有のコードが配置されているようです。

プラットフォーム共通のコードは .NET Standard の API のみに依存することになるのでしょう。

docs.microsoft.com

<AppName> プロジェクトの Services には、アプリの CRUD 処理を担うクラスのインターフェース iDataStore が定義され、モック用の実装クラス MockDataStore と REST API を呼び出す実装クラス CloudDateStore が配置されています。デフォルトでは、MockDataStore が使われます。

サービスプロジェクト(<AppName>.MobileAppService) には、サンプルの Controller / Repository / Entity などが配置されています。

Entity のコード。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

namespace SampleFormApp.Models
{
    public class Item
    {
        public string Id { get; set; }
        public string Text { get; set; }
        public string Description { get; set; }
    }
}

Repository の インタフェース。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

namespace SampleFormApp.Models
{
    public interface IItemRepository
    {
        void Add(Item item);
        void Update(Item item);
        Item Remove(string key);
        Item Get(string id);
        IEnumerable<Item> GetAll();
    }
}

Controller のコード。REST API の EndPoint になります。

using System;
using Microsoft.AspNetCore.Mvc;

using SampleFormApp.Models;

namespace SampleFormApp.Controllers
{
    [Route("api/[controller]")]
    public class ItemController : Controller
    {

        private readonly IItemRepository _ItemRepository;

        public ItemController(IItemRepository ItemRepository)
        {
            _ItemRepository = ItemRepository;
        }

        // GET: api/values
        [HttpGet]
        public IActionResult List()
        {
            return Ok(_ItemRepository.GetAll());
        }

        [HttpGet("{Id}")]
        public Item GetItem(string id)
        {
            Item item = _ItemRepository.Get(id);
            return item;
        }

        [HttpPost]
        public IActionResult Create([FromBody]Item item)
        {
            try
            {
                if (item == null || !ModelState.IsValid)
                {
                    return BadRequest("Invalid State");
                }

                _ItemRepository.Add(item);

            }
            catch (Exception)
            {
                return BadRequest("Error while creating");
            }
            return Ok(item);
        }

        [HttpPut]
        public IActionResult Edit([FromBody] Item item)
        {
            try
            {
                if (item == null || !ModelState.IsValid)
                {
                    return BadRequest("Invalid State");
                }
                _ItemRepository.Update(item);
            }
            catch (Exception)
            {
                return BadRequest("Error while creating");
            }
            return NoContent();
        }

        [HttpDelete("{Id}")]
        public void Delete(string id)
        {
            _ItemRepository.Remove(id);

        }
    }
}

ASP.NET Web API のコードですね。このプロジェクトを実行すると、localhost でおそらく macOS 版の IISExpress が起動し、アセンブリが配置され、ブラウザに Swagger のページが表示されます。Swagger も統合されているんですね。

もちろん、API を試すことができます。

Web API との接続

ということで、アプリから REST API 経由でデータを取得したいので、MockDataStore ではなく CloudDataStore で Web API に接続してみます。

<AppName>.MobileAppService の Properties フォルダにある launchSettings.json で URL の設定をします。

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:61407",
      "sslPort": 0
    }
  },
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "api/values",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "MasterDetail.MobileAppService": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "http://localhost:61407/api/values",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

<AppName> の App.xaml.cs で UseMockDateStore を false にして、BackendUrl を設定します。

using System.Collections.Generic;

using Xamarin.Forms;

namespace SampleFormApp
{
    public partial class App : Application
    {
        public static bool UseMockDataStore = false;
        public static string BackendUrl = "http://localhost:61407";

        // 省略
}

Mock じゃないことをわかりやすくするため、Service の Repository の実装クラスのコンストラクタで、2件の データを追加しています。

namespace SampleFormApp.Models
{
    public class ItemRepository : IItemRepository
    {
        private static ConcurrentDictionary<string, Item> _items =
            new ConcurrentDictionary<string, Item>();

        public ItemRepository()
        {
            Add(new Item { Id = Guid.NewGuid().ToString(), Text = "Sharp", Description = "C# is very sharp!" });
            Add(new Item { Id = Guid.NewGuid().ToString(), Text = "dotNet", Description = "dotNet is very cool!" });
         }

iOS アプリを実行してみると、ちゃんと Web API でデータが取得されました。

デバッグ

ソリューション構成にクライアントとサーバを含んで同時に実行できるため、クライアントのコードはもちろんのこと、サーバー側のコードにブレークポイントを設定してデバッグすることも可能です。サーバープロセスにアタッチしてデバッグとかしなくていいので楽ですね。

デバッグ時にクライアントとサーバをプロジェクトのコンテキストメニューで「項目のデバッグを開始する」から実行するのですが、Windows 版のように同時に実行してくれるような構成方法がわかりませんでした。未実装なのでしょうか。

終わりに

Xamarin.Forms をちょっとだけ触ってみました。Android / iOS で動作するクロスプラットフォームアプリ開発を手軽に開始できます。.NET 開発に慣れた人なら違和感なく入っていけそうです。プロダクションレベルのコードを書いていくと、プラットフォームに依存するコードが増えてマルチプラットフォームサポートは大変だとは思いますが。

本家 Windows 版の Visual Studio と同じようにコード作成、デバッグ可能なので、手持ちのマシンが Mac だけっていう人も C# 書きまくれます。 Xamarin 使わない場合でも ASP.NET アプリの開発も可能ですし。

Visual Studio for Mac が本家 Windows 版と同様、末長く提供されることを祈ります。

Android Wear 2.0 on Moto 360 2nd Gen

6/2 の朝、Moto 360 2nd Gen にソフトウェアアップデートが来ました。Android Wear 2.0 が降って来ました。

ディスコンと言われている Moto 360 シリーズですが、ちゃんと最新の OS が使えるのは喜ばしいです。

インストールを始めたのが玄関出る直前だったので、終わるのを待たずに、電車の中でアップグレードを完了。電池が20％ぐらい減ってました。

Moto 360 2nd gen に Android Wear 2.0 が降ってきた。3rd party のアプリとかウォッチフェースは消えた。

— MH (@kondoumh) 2017年6月1日

右にスワイプしてもウォッチフェース変更モードになってしまうので、アプリが消えたかと思いました。アプリの表示は、右スワイプではなく、ハードウェアの竜頭を押すというアクションに置き換えられていました。ウォッチフェースも既存のものは全部ありました。

アプリ選択の UI がグレードアップしています。

単体でアプリのインストールができるようになったみたいです。Moto 360 2nd Gen は Wi-Fi 環境だとストアからアプリをインストールできます。iOS ユーザーも安心ですね。

Google Map まで動くのはすごいですが、使うかなぁ？

Google Assistant も使えるようになりました。「3分後にタイマー」とか言うとストップウォッチアプリが起動し、時間が来たら教えてくれます。ウォッチ型デバイスなので相性いいですね。

Google 日本語入力とかもインストールできたり、メッセージを確認するだけでなくタップで返信とかもできちゃうみたい。とはいえ、小さい画面でそこまでやるかなあ。。。ということでこれまで通り通知確認と活動量計としての利用が中心になりそうですが、ちょっと利用の幅が広がるかもしれません。

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 だし、家族に持たせるにはうってつけのスマートフォンだと思います。

*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 版に降りてきました。

Visual Studio 2013 Community と Language Pack 導入してみた。ちゃんと MFC も使える。C++ でインクリメンタルビルドオプションが効いてない気がする

— MH (@kondoumh) 2015年4月26日

個人的には 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 がサポートされ、スマートデバイスの開発環境の有力候補として存在感出はじめました。

XAML って WPF に始まり、Silverlight -> Windows Phone 7 -> ストアアプリ -> UWP -> Xamarin とプログラミングモデルの遺伝子を引き継いでいる・・いつかアウトブレークするんだろうか？

— MH (@kondoumh) 2017年2月23日

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 さんのコラを貼って終わりにします。

ミラーマンと Visual Studio 2017、完全に一致。 https://t.co/r6n6XBpB3P pic.twitter.com/yxzLWSctY3

— Vim芸人 (@mattn_jp) 2017年3月9日

*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 開発

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

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

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

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

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

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

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

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

Xamarin 開発環境

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

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

blog.kondoumh.com

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

blog.kondoumh.com

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 のスリープ復帰後に 動画の再生スピードが３倍速ぐらいに勝手に上がってしまう症状が。

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

*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 でも同じですが。