kondoumh のブログ

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

macOS 環境を最新化

Sierra は今年の初め頃導入してました。

blog.kondoumh.com

High Sierra はパスワードなしで root ログインできてしまうバグが出てたりしてたので、このまま年を越してもいいかなと思ってましたが、奥さんの MacBook Pro (Late 2012) がまだ OS X Yosemite で盛んに更新を促されるようになったので、見切りでアップデート。APFS への移行、アプリ設定の保持など特に問題なかったので、自分の MacBook Pro (Early 2015)も行くことに*1

事前に brew のパッケージは最新化してからインストールしました。

あっさりと完了*2

f:id:kondoumh:20171210112539p:plain

APFS にも引っ越し完了。

f:id:kondoumh:20171210112918p:plain

APFS の恩恵でストレージのステータス表示も心持ち速い?

f:id:kondoumh:20171210113049p:plain

普段使いのソフトウェアも問題なし。Sierra にアップデートできてるからか詰まる所もありませんでした。

開発ツールも最新化しておきます。

Xcode

f:id:kondoumh:20171210114841p:plain

IntelliJ IDEA

f:id:kondoumh:20171210114859p:plain

Visual Studio Community 2017 for Mac

f:id:kondoumh:20171210114916p:plain

最後に VMware Fusion で運用している Windows 10 です。VMware Fusion も起動するたびにアップグレードを促されてうざくなっていました。仮想マシンの Windows 10 は一足前に Fall Creators Update を適用済みです。

VMware Fusion を2年ぶりにアップグレードし Version 10 に。High Sierra と Windows 10 Fall Creators Update に対応済みと謳われています。

f:id:kondoumh:20171210113725p:plain

仮想マシンのマイグレーション、VMware tools の更新が行われ、最適化された模様です。

Visual Studio for Mac とともに、本家 Visual Studio も更新されています。

blogs.msdn.microsoft.com

こちらも更新しておきます。

f:id:kondoumh:20171210115609p:plain

ということで、年内に今年のソフトウェアアップデート作業を終えることが出来ました。

*1:普段は奥さんのマシンが2世代ぐらい前の OS になってるのですが、今回は先行して頂きました。にしても5年前のマシンですが、全く問題なく現役です。

*2:近年 OS の更新時でもデータのバックアップとか頑張って取らなくなってしまってます。

ストック情報サイトを Tumblr から Scrapbox に移行した話

Tumblr での運用

3年近く前、Tumblr にストック情報サイトを構築しました。

blog.kondoumh.com

stock.kondoumh.com

ブラウザで気軽に更新でき、ページの見栄えもそれなりで、タグ付けも簡単、API で可視化も可能…ということでわりと満足して使ってました。

しかし、記事の編集機能に関しては結構不満がありました。

Tumblr のエディタは OS 標準のキーバインドを乗っ取ってしまいます。macOS だと Emacs ライクなキーバインドが使えるはずなのに効かなくて書いてて突っかかります。

ダッシュボード(タイムライン)にモーダルでオーバーレイされるダイアログ内でのエディタのため、長文を書くのに向いていません。

Tumblr では Markdown が使えるのですが、画像挿入の GUI はリッチテキストモードでしか提供されておらず、Markdown モードで画像を挿入するには、最初にリッチテキストモードにしておいて画像をインラインでアップロードし、その後 Markdown モードに切り替えるとアップロードされた画像の URL が使えるというハックめいた操作が必要です。

元来 Tumblr は他サイトの画像や文章を引用してキャプションや出典など簡単な情報を付加してポストすることに特化したサービスです。したがってゼロから文書を作成するというユースケースのサポートは薄く、エディタや Markdown は二級市民扱いなのでした。

とはいえ、他に目的に合うサービスもなくて数年間使い続けてました。

Scrapbox への移行

Scrapbox は去年ぐらいから存在は知ってました。Dropbox の Paper と同様なモダンな Wiki かなという印象でした。最近 Scrapbox にブログを移行したりする人をちらほら見かけます。Scrapbox のプロジェクトの見た目は Tumblr のアーカイブ画面を思わせます。それで、ストック情報サイトを移行すればいいのではないかと思いつきました。

まずは、ガジェットに関する記事を Tumblr から Scrapbox に手動コピペで移行してみました。

WYSIWYG 編集可能

Scrapbox は閲覧モードと編集モードがシームレスな WYSIWYG 編集を可能にしており、Tumblr を始めとする一般的なブログツールの、編集 -> プレビューの繰り返しステップが不要です。画像やリンクなどの要素はインラインで編集状態になり、カーソルが移動すると閲覧モードになります*1。記事を読み返しながら気になったところをすぐに修正できるのがいいですね。他の人のページでもインライン編集モードで記法を確認できて参考になります。何しろ書くことの心理的障壁が低くなります。

同一タグの投稿がリアルタイムにリンクされる

記事内に #tagname を書くだけで、同一タグの既存の投稿がダイナミックにリンクとして出てきます。既存記事へのリンクも簡単に貼れます。 これも Scrapbox のキラー機能と言えるでしょう。

Emacs キーバインドを有効化できる

Edit Profile -> Extension で Emacs Key Binding を指定すれば、有効化されます*2。 プラグインで拡張できるため、拡張機能が充実してくればさらに快適な執筆環境が構築できそうです*3

画像の挿入が簡単

画像の挿入は、ファイルのドラッグ&ドロップでも、クリップボード経由でも簡単にできます*4。Gyazo サービスと連携しているようです。

gyazo.com

Markdown よりもシンプル
  • 箇条書きはインデントのみ
  • Table 書式もインデント + tab のみ*5*6
  • 見出しは * が多いほうが上位となり、既存の Wiki 記法の逆

独自マークアップも、これぐらいシンプルであれば、ヘルプを開く頻度が低くてちょうどいいです。

blog.kondoumh.com

Markdown には、URL のリンクはありますが、Wiki では普通のサイト内の他ページへのリンクはないため、Square branckets ([]) によるマークアップも妥当なところかと。

数式機能

今回、使ってないですが、TeX 記法で数式も扱えます。

増井先生からメンション頂きました。

API / 拡張

Scrapbox にも投稿タイトルや本文を取得する API が公開されていますが、タグを取得する API があるといいなと思います。

scrapbox.io

ブックマークレットなど色々な使いこなし Tips が纏められています。

scrapbox.io

プロジェクト単位の投稿管理

Scrapbox にはプロジェクトという単位で投稿を管理できます。ストック情報サイトでは、Gadget, Software, Portfolio というメジャータグを混在ポストしてました。Scrapbox ではテーマごとにプロジェクトを作った方が管理しやすく、ポータルも見やすくなりそうということで、個別にプロジェクト化することにしました。

scrapbox.io

プロジェクト内の投稿を一つ選んで Pin at home しておくと、プロジェクトのページ情報を oEmbed として取得してブログ等に埋め込み可能になります。

手動以外の移行方式

Scrapbox は JSON によるデータインポートが可能ですが、Tumblr はデータエクスポート機能がないので、今回は手動コピペしました。プロジェクトの Settings -> Page Data から Scrap to <プロジェクト名> という名前のブックマークレットが取得できます。これを使うと Web ページのリンクや選択範囲のテキストを引用として取り込むことができます*7

纏め

ということで Tumblr よりも書くことそのものが格段に快適で楽しい Scrapbox に移行しました。まだ全投稿を移したわけではありませんが元サイトの更新は止めて徐々に更新していこうと思います。

*1:他の人の投稿でも同じ動きをしますが、編集権限がなければ内容を上書きする心配はありません。

*2:Windows では C-n が 新規ページを開くコマンドに負けてしまいますが

*3:現状でも十分快適ですが。

*4:クリップボード経由の実装は画像の URL を使っているのか、イメージをそのままアップロードしているのかまでは調べていませんが。

*5:作った表は CSV ファイルとしてダウンロード可能です。

*6:Excel や既存の Wiki などからクリップボード経由で貼り付けても簡単に作表できます。

*7:現状では画像まで取り込むことはできないため、移行には適していません。

iPad Air 2 での iOS 11 マルチタスキング

(*)本記事公開時 iOS のスライドオーバーをピクチャー・イン・ピクチャー(PiP) と誤記していました。コメント指摘により修正しました。

iPad Pro + iOS 11 の記事はたくさんあると思いますが・・

インストール

9月22日 iPad Air 2 にも iOS 11 が降ってきたので早速インストールしました。

f:id:kondoumh:20170929061253p:plain:w400

インストール当初電池の減りが激しくなったなと思ったらこんな記事が。

gigazine.net

Spotlight のインデックス作成などがバックグラウンドで動いていたのかなと思いました。今は落ち着いているようです。

iPhone SE より非力な A8 chip 搭載の Air 2 は二級市民ということ? とちょっと悲しくなったのですが iOS 11.0.1 がリリースされたタイミングで A7 chip の iPhone 5s にインストールしてみたら普通にサクサク動いてます。あれ? と思って Air2 も 11.0.1 にアップデートして視覚効果を戻したら iOS 10 並みにの動きに戻ってました。パフォーマンスチューニングされたっぽいです。よかった。

Dock の進化

iOS 10 までの Dock は配置できるアプリの数が固定でしたが、iOS 11 からは macOS の Dock 同様多くのアイコンが置けて、置いた数に合わせて伸縮するようになりました。iPhone は 5s でしか確認できてないのですが、これは恐らくiPad 限定の機能だと思われます。

Dock とリニューアルされたコントロールセンターは iPad のマルチタスキングにおいて欠かせない役割を担っています。

11 リリース直後は、Dock がスムーズに出るアプリとそうでないアプリがある気がしました。例えば、Chrome だと中々出なかったような。11.0.1 では解消されているようです。

スライドオーバーとスプリット

iOS 10 までは画面右からスワイプすると スライドオーバー(Slide Over) 中のアプリ (またはスライドオーバー可能なアプリ候補) が出てきてそのままスプリット状態にもできました。

iOS 11 では macOS 的な Dock の登場によりかなり操作性が変わりました。右からのスワイプもできますが、Dock からマルチタスク可能なアプリをドラッグして スライドオーバーまたはスプリットさせることができます。iOS 10 までのスライドオーバーはメインのアプリの右にサブのアプリが部分的にかぶさる感じで、サブのアプリの操作しかできませんでしたが iOS 11 ではオーバーレイというかフローティングして左右に移動させることができますし、メインのアプリも操作出来ます。スライドオーバーとスプリットの切り替えも簡単です。

Dock には常時配置してるアプリと最近使ったアプリのアイコンがありますが Dock にないアプリは スライドオーバー / スプリットできないので、一度起動して最近のアプリに入れるなどの操作が必要です。

スプリット非対応アプリ

Ingress のような全画面のゲームアプリなどは、スライドオーバーにもスプリットにも対応していません。ポータルハックしながら、Twitter のタイムライン眺めたりしたいのですが・・

(10/19 追記: Ingress アプリに Twitter アプリのスライドオーバーは可能でした。)

スプリット不可のアプリもありますが、ちょっとわかりにくくなっています。

Google 製の iOS アプリは当然のことながらスプリット対応が遅れています。マルチタスクを活かすには 普段使いのアプリを対応アプリで固める必要がありますが、Google のサービスに依存しまくっている身としてはちょっと辛いものがあります。

スプリット状態の維持

スプリット状態は、2つアプリのどちらかを単独で起動しても維持されていますし、コントロールセンターのサムネイルでもわかるので、作業の復帰が楽です。

f:id:kondoumh:20170924230320p:plain

一度スプリットしたアプリのペアは明示的に解除しない限り維持されます。

スプリットが有効なアプリのペア

わかりやすいのは、Safari と Twitter アプリの組合せでしょう。Twitter のタイムラインを追いながら、ツイート内のリンクを Safari で読めます。PC なら当たり前の操作ですが、iPad で画面切替がなくなりなぜそのページを閲覧したのかというコンテキストが維持されるのは新鮮です。今後は iOS の Safari をデスクトップ版 Safari のように使うことも可能になっていくのかも。

Twitter のように、Safari をダイレクトに呼んでくれるアプリとの相性が良いです。Feedly や Pocket はタスクバーから 「Safari で開く」しないといけないのでそれほど快適ではありません。

iOS 11 の記事でよく紹介されているメモアプリと写真アプリをスプリットして、ドラッグ&ドロップで写真をメモに貼るというシナリオは確かに実行可能ですが、常にスプリットを維持するほど多用することはなさそうです。

Facebook アプリと Messenger アプリをスプリットできればいいのですが今のところ未対応でした。

以前の記事で書いたように技術書の電子書籍を参照しながらターミナルアプリやエディタアプリを使うというのも有効でしょう。

blog.kondoumh.com

ファイルアプリ

「iOS でもファイル操作が可能になった」という触れ込みのファイルアプリですが、iCloudDrive と対応アプリを使っていないとあまり活躍の場がなさそうです。ローカルのフォルダ構造を晒すアプリも自分が使っているものには、Zip 解凍のユーティリティぐらいしかありませんでした。

現在のところ OneDrive や Dropbox などストレージサービスのアグリゲーションアプリとしての利用に止まっています。これは対応アプリの増加に期待するしかないのでしょう。

アプリ切替からワークスペース切替へ

iPad アプリがスプリット対応していけば、アプリの組合せでワークスペースを作り、コントロールセンターでワークスペースを切り替えるという使い方が一般化していくのではないかと思います。

コンテキストスイッチは人間にとって負荷が高いので、iPad のような大画面デバイスではスマートフォンと同じような画面切替は極力なくすべきなのでしょう。

iPad では、大画面を活かして左側にファイル選択のような補助的なペイン(領域)・右側にメインで操作するペインを配置したレイアウトのアプリが多いですが、今後はスプリットした時にも情報量を減らさず、ワークスペースを構成しやすいような UI が推奨されていくのではないでしょうか。

iOS 11 の登場により iPad は PC 代わりになる・・ところまでは全然行っていませんが、2つのアプリを連携させるという基盤ができたということは言えると思います。

My Gadgets Mid 2017

去年の春先の様子。

blog.kondoumh.com

Phone

Nexus 6P を1年半以上使い続けています。Ingress 活動をしてると日中に1回充電が必要ですが、まだバッテリーはそれほどヘタっていないようです。 Android Nougat も 7.1.2 になりました。時々ハングアップしてしまうことがありますが。

Android はスクリーンにアイコンだけじゃなくウィジェットを置けるのがいいですね。Calendar , Play Books , Pocket Casts , Amazon Music のウィジェットを使っています。

有機 EL ディスプレイの視認性は素晴らしく、Play Books で Manning の ePub を読むのが捗ります。iPad Air 2 を持ち歩くようになったので、スクリーンサイズ的にカニバってるのですが、Nexus 6P の方が利用比率が高いです。

Android Pay に対応して欲しかったですが、もう諦めました。

当面買換え予定はないですが、奥さんの iPhone SE を見て4インチに回帰したい気持ちも出てきています。やはり大きい電話はポケットに収まりが悪く、手にもフィット感がないので。SE の次世代機は必ず発売されると踏んでいるので Apple Pay 対応したら出戻るかも。

Watch

Moto360 2nd gen を購入後1年以上使っています。

blog.kondoumh.com

チャコールの皮バンドは傷んでしまったので、バンドを2回ぐらい交換してます。

ステンレス製に変えたら金属アレルギーが出ちゃいました。

黒革のに変えました。

Android Wear 2.0 にアップグレード。

blog.kondoumh.com

Google Assistant 対応が目玉ですが、腕に向かって話しかけるのはちょっと抵抗があり、使いこなせずにいます。

目下のところ金属アレルギーの症状が治まるまで家で待機中です。Nexus 6P のセンサーで Google Fit が活きてるので活動量計として必要不可欠というわけでもないことに気づいてしまいました。iPhone SE とかにスイッチするとさらに利用頻度が下がりそうですが。。

また秋頃から使ってみます。

Tablet

iPad Air WiFi -> iPad Air 2 Cellular にアップグレードして10ヶ月ぐらい。Cellular 版は WiFi 版とは別物であることを実感しています。

blog.kondoumh.com

電池がほとんど減らないことも iPad の驚異的なところです。充電に気を使うことなく常時接続環境を持ち歩けることはありがたいです。

iPad でコードを書くことはあまりありませんが、帰省や客先訪問、帰社して会議に参加するときなどは、物理キーボードで使っています。iOS の物理キーボード設定で Caps Lock を日本語入力をトグルできるので英語キーボードでもストレスはありません。

このキーボードは Nexus 6P とペアリングしても ⌘ + Space で日本語入力 On/Off できて意外と使いやすいです。

Apple は iPad Pro を ラップトップ PC の置き換えにしようとしている感じですが、ウィンドウシステムとファイルシステムが今のままだと難しい気がします*1。でも iPad は色々と便利で重宝してます。

PC

MacBook Pro 13 Early 2015 を引き続き使っています。

ほとんどデスクトップ機として運用。ディスプレイはまだ WQHD の ASUS PB278Q です。入力デバイスは Magic シリーズで固めています。

Windows での開発環境は BootCamp に挫折し VMware Fusion に落ち着いています。

blog.kondoumh.com

macOS Sierra にアップグレード。

blog.kondoumh.com

ハイエンドなゲーミング PC にも興味ありますが、長距離移動が増えてきたので Surface Laptop や ThnikPad X270 とかも気になっています。

まとめ

ということで、去年春との差分は時計が増えたのと iPad のグレードアップでした。1年半前とさほど変わっていないですが iPad の活躍シーンが増えた気がします。

*1:iOS 11 ではファイルを扱うアプリが搭載される模様ですが。

日常の 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 先生のプロダクトですし。

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

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

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

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

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

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

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

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

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

japan.blogs.atlassian.com

課金すると色々な機能が解除される模様ですが、とりあえずミニマムなフリープランのままでも、個人の日常 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

インストール

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

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

f:id:kondoumh:20170716144830p:plain

フルインストール。

f:id:kondoumh:20170716144933p:plain

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

f:id:kondoumh:20170716145007p:plain

起動。

f:id:kondoumh:20170716145052p:plain

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

f:id:kondoumh:20170716145623p:plain

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

www.microsoft.com

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

f:id:kondoumh:20170716150025p:plain

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

f:id:kondoumh:20170716150040p:plain

これで、準備完了です。

Xamarin.Forms アプリの作成

ソリューションの作成

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

f:id:kondoumh:20170716151317p:plain

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

f:id:kondoumh:20170716151559p:plain

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

f:id:kondoumh:20170716151638p:plain

終わりました。

f:id:kondoumh:20170716151717p:plain

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

f:id:kondoumh:20170717005749p:plain

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

f:id:kondoumh:20170717010152p:plain

ソリューション構成

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

f:id:kondoumh:20170717015216p:plain

プラットフォーム共通のコードは .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 も統合されているんですね。

f:id:kondoumh:20170717013203p:plain

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

f:id:kondoumh:20170717013303p:plain

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 でデータが取得されました。

f:id:kondoumh:20170717012538p:plain

デバッグ

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

f:id:kondoumh:20170717013538p:plain

デバッグ時にクライアントとサーバをプロジェクトのコンテキストメニューで「項目のデバッグを開始する」から実行するのですが、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%ぐらい減ってました。

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

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

f:id:kondoumh:20170604214535j:plain

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

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

f:id:kondoumh:20170604214612j:plain

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

f:id:kondoumh:20170604215815j:plain

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