Morning Girl

Web API, Windows, C#, .NET, Dynamics 365/CRM etc..

Postman Documentation / API Network が便利だよ！

Postman API REST

この記事は「Postman Documentation / API Network が便利だよ！ 」ということを言いたいだけの記事です。

Postman Documentation / API Network とは？

Postman には Webベースのドキュメントを公開する機能があります。

learning.getpostman.com

作成すると以下のような見やすい API リファレンス と APIテスティング が行えるWebSiteが自動的に作成されます。

もちろん、Postmanコレクションも取得して、ローカルのPostmanで実行することも可能です。

docs.api.getpostman.com

f:id:sugimomoto:20200114111813p:plain

ちなみに、私の観測範囲で、このPostman Documentation を使ってAPI ドキュメントを公開している日本のクラウドサービスは「Bカート」さんくらい。

https://docs.api.bcart.jp/

f:id:sugimomoto:20200114111943p:plain

ちなみに、Postman では生成したドキュメントをPostmanの サイト上で公開・共有できる仕組みを提供しています。

それが Postman API Network です。

f:id:sugimomoto:20200114112624p:plain

現在、470種類ほどのAPIが公開されており、APIドキュメントの参照、Postman Collectionの入手が可能になっています。

f:id:sugimomoto:20200114112749p:plain

APIを検証する時、Postmanコレクションを毎回手作業でがつがつ作るんですが、予めこういうサイトで公開されていると、すごく楽で助かります。

最後に

パブリックなAPIは、みんな Postman API Network で API documentを公開してくれればいいのに！！！

Postman Collectionは OpenAPI SpecやRAMLからも取り込めるので、敷居は低いと思うんですが。

PowerApps / PowerAutomate カスタムコネクタを Postman コレクションから作成する

Postman PowerApps PowerAutomate API REST CData API Server

前回の記事では OpenAPI（Swagger）Specからカスタムコネクタを作る方法を解説しました。

kageura.hatenadiary.jp

今回は Postman コレクションからカスタムコネクタを作成する方法を見ていきます。

docs.microsoft.com

  • Postman とは？
  • 対象のAPI
  • 出来上がるもの
    • Postman コレクションサンプル
    • Postman コレクションのエクスポート
    • カスタムコネクタの作成
    • アプリの作成
  • おわりに
  • Tips
    • 応答に利用できるレスポンスを予め加えておく
    • 動的URLを構成したい場合どうするの？
続きを読む

OpenAPI（Swagger）Spec から Postman Collection を生成すると楽にAPIテストができる

Postman CData API Server

Postman で API を実行するのは結構手軽にできるんですが、エンドポイントが多かったり、URLパラメータやヘッダーを逐次、ドキュメントから持ってくるのは結構面倒です。

もし、そのAPIがOpenAPI（Swagger） Specを公開していたら、それを取り込むと簡単にPostmanコレクションを生成できます。

OpenAPI Spec って何？

ここを参照しましょう。

OpenAPI Specification（OAS）は、ソースコードへのアクセス、追加ドキュメント、またはネットワークトラフィックの検査を必要とせずに、人間とコンピュータの両方がサービスの機能を発見して理解することを可能にする、　　プログラミング言語に依存しないREST APIの標準的なインターフェイス記述を定義します。

引用元：https://github.com/OAI/OpenAPI-Specification

対象のAPI

今回対象にするAPIは私が以前作成して、パブリックに公開している O'Reilly Book List API です。作り方はこちら を参照してください。

f:id:sugimomoto:20200114111206p:plain

以下のURLからOpenAPI Specをダウンロードできます。

http://decodeapiserverdemo.azurewebsites.net/api.rsc/$oas

取り込み方

取り込み方は簡単です。Postmanを立ち上げて、「Import」ボタンをクリックし

f:id:sugimomoto:20200114111211p:plain

事前にダウンロードしておいた、OpenAPI（Swagger）Specのファイルをドラッグ・アンド・ドロップするだけです。

f:id:sugimomoto:20200114111215p:plain

あとはTeamで共有するかどうかと、コレクションを作成するかどうかを決めて、Nextをクリックすれば完了です。

f:id:sugimomoto:20200114111221p:plain

以下のようにコレクションが生成されて、

f:id:sugimomoto:20200114111226p:plain

手軽にAPIを試せる状態が整います。

f:id:sugimomoto:20200114111233p:plain

Reference

learning.getpostman.com

PowerApps / PowerAutomate カスタムコネクタを OpenAPI（Swagger）Specから作成する

PowerApps PowerAutomate OpenAPI Swagger CData API Server

最近、少し PowerApps / PowerAutomate のカスタムコネクタ周りについてまとめていました。

現在何種類かの作り方があるんですが、それぞれの特徴を捉えるために、何回かに分けて記事にして行こうと思います。

  • PowerApps / PowerAutomate カスタムコネクタって何？
  • 現在カスタムコネクタがサポートしている作り方
  • OpenAPI（Swagger）って何？
  • OpenAPI（Swagger）で公開されているサービス
  • 対象のAPI
  • 出来上がるもの
    • OpenAPI（Swagger）Specのダウンロード
    • カスタムコネクタの作成
    • カスタムコネクタを使ってみる
  • おわりに
続きを読む

自分のはてなブログの投稿状況データをPowerBIで可視化する：CData XML ODBC Driver

Hatena AtomPub API ODBC XML Power BI

先日公開した以下の記事で書いたのですが、自分のはてなBlogでどんな投稿をしているかPowerBIで可視化してみました。

kageura.hatenadiary.jp

最終的にできあがったのは以下のようなレポートです。

f:id:sugimomoto:20200105231417p:plain

この記事ではこのようなレポートを作成するためのデータ取得方法について解説していきます。

その前にちょっとAPIの解説

はてなBlogにはいくつか外部からはてなBlogにアクセスするためのAPIが提供されています。

最初２つのAtomやRSSはおそらく使ったことがある方も多いと思いますが、Blogの更新状況を取得するためのAPIプロトコルです。

AtomPubはAtomのように外部からBlog記事を参照できる機能はもちろんですが、記事の登録や更新にも対応しているのがポイントとなるAPIです。

最後のoEmbed APIはこちらの解説記事がわかりやすいかと思いますが、名前の通り外部コンテンツへの埋め込みおよびその記事の参照用に特化したプロトコルです。

今回APIとして必要な要件は、過去の全記事に関する情報が参照でき、かつカテゴリ情報も取得する必要がありました。

そして、実はその要件を満たしたAPIは「AtomPub」一択です。

前２つのAtomとRSSは参照用としては優れているのですが、最新の記事参照のみに特化しているため、ページネーション、つまり過去記事の参照ができません。

oEmdedは参照するためにどの記事を参照したいか、といったURLが必要となるため、言わずもがな。

AtomPubはページネーションをサポートし、カテゴリも取得できるので、今回のようなユースケースにはうってつけのAPIとなっていました。

実装方法

それでは実際に実現する方法なのですが、この記事でははてなBlogデータをAtomPub経由で取得するためのコネクタを使うので、特にプログラミングの要素は出てきません。

なので必要なものは、以下の「CData XML ODBC Driver」と

XML ODBC Driver - ODBC | ODBC Drivers | ODBC Connection | ODBC API

XML ODBC Driverを通じてはてなBlog AtomPubに接続できるようにするための設定ファイルだけです。

github.com

あとは分析用に Microsoft Power BIを使いました。Tableauなどでも同じ用に実施できると思います。

powerbi.microsoft.com

API Keyと接続URLの取得方法

それでは実際にデータの取得を行っていきたいと思いますが、AtomPub APIは接続するために「接続用URL」と「API Key」が必要となります。

はてなBlogの管理画面から「設定」→「詳細設定」に移動

f:id:sugimomoto:20200105231432p:plain

AtomPubにルートエンドポイントとAPIキーの情報があるので、これを利用します。

f:id:sugimomoto:20200105231444p:plain

設定ファイルをダウンロード

次に接続用の設定ファイルをダウンロードします。通常設定ファイルは「CData XML Driver」用で都度カスタマイズする必要があるのですが、今回は私が作成してしまっているので、以下のURLからダウンロードして利用できます。

github.com

上記URLから「HatenaBlogFeeds.rsd」というファイルをダウンロードし、任意のフォルダに配置（例：C:\CData_REST\Hatena）します。

f:id:sugimomoto:20200105231451p:plain

CData XML ODBC Driverのインストールとセットアップ

続いて「CData XML ODBC Driver」をインストールします。有償の製品ですが、30日間のトライアルバージョンがあるので、今回はそれを利用します。

以下のURLから評価版をダウンロードし

http://www.cdata.com/jp/drivers/xml/odbc/

f:id:sugimomoto:20200105231457p:plain

ダウンロードしたexeファイルを実行して、セットアップを行います。

f:id:sugimomoto:20200105231507p:plain

セットアップ完了後、DSN構成画面が表示されるので、以下のように必要な情報を入力します。

f:id:sugimomoto:20200105231513p:plain

以上で下準備は完了です。

PowerBI からはてなBlog AtomPub APIに接続

それではPowerBIに はてなBlogのデータをロードしてみましょう。

PowerBIを立ち上げて、「データを取得」をクリックし

f:id:sugimomoto:20200105231520p:plain

「ODBC」接続を選択します。

f:id:sugimomoto:20200105231527p:plain

先程設定したDSN名を選択して「OK」をクリックすると

f:id:sugimomoto:20200105231533p:plain

以下のようにはてなBlogのデータがフラット化されて取得できるテーブルが選択できるようになっています。これを読み込みます。

f:id:sugimomoto:20200105231538p:plain

以下のような感じでデータが取得されました。設定ファイルが自動的にAtomPubのページネーションもするようになっているので、過去の全記事を取得してくるようになっています。

f:id:sugimomoto:20200105231544p:plain

あとはこのデータを使って、PowerBIの機能でビジュアライズするだけです。

f:id:sugimomoto:20200105231555p:plain

その他：カテゴリの取り方

ちなみに、デフォルト状態のカテゴリ情報は以下のようにカンマ区切りになっているのですが、

f:id:sugimomoto:20200105231603p:plain

これだとリレーショナルなデータになっていないので、うまく可視化できない部分が出てきますよね？

これを以下のようにBlogIDとリレーションされた形式にする方法もあります。

f:id:sugimomoto:20200105231612p:plain

方法は簡単で、まず元になっているクエリを複製し、適当に「Category」といった名前に変更、IdとCategoryTerm以外の列を削除します。

f:id:sugimomoto:20200105231619p:plain

次に「列の分割」から「区切り記号による分割」を選択し

f:id:sugimomoto:20200105231626p:plain

「コンマ」の区切りごとで列を分割します。

f:id:sugimomoto:20200105231631p:plain

以下のようなデータができあがるので、この項目を選択して、「列のピボット解除」を実行します。

f:id:sugimomoto:20200105231636p:plain

すると以下のようにIDに各カテゴリがリレーションされた形のデータができあがります。「属性」列は最終的に消してしまっても大丈夫です。

f:id:sugimomoto:20200105231651p:plain

f:id:sugimomoto:20200105231658p:plain

2019年の活動棚卸しと2020年の方針をまとめてみる

コラム PowerBI Dynamics 365 API

あけましておめでとうございます！

去年に引き続き2019年も活動の棚卸しと2020年の方針をまとめてみようと思います。

kageura.hatenadiary.jp

ちなみに、去年はちょっと手軽にExcelで済ませてしまったので、今回はしっかりとPowerBIでやってみました。

2019年の棚卸し

Blogの状況

一応私は自分自身のBlogと会社のBlogの両方で記事を投稿しているのですが、とりあえずメインのMorningGirlの投稿状況を見てみます。

去年は43件とちょっと少なめとなったのですが、今年は51件と2015年に次ぐ件数となり、結構精力的にBlog活動ができました。ただ、月別の投稿件数を見ると1月が14件と圧倒的なのに、それ以降が伸び悩み。

f:id:sugimomoto:20200103155713p:plain

カテゴリはAPIが2018年と変わらないですが、ZOZO前澤社長のツイート収集などをしたことや、JJUGでの登壇をまとめた記事を書いたことなどもあって、TwitterやJavaのコンテンツが増えていることがわかります。

あとは意外とDynamicsに関する発信もしていたなと思ったり。PowerBIの方が多いかなというイメージでしたが。

PVベースでは前年比意外と伸び悩み。14%増に留まりました。人気記事の傾向を見ると、2018年に投稿したRESTとはなんぞや、MongoDBやRedisの事始め記事が強いのがよくわかります。このあたりは確かにあまり書いてなかったなぁと思ったり。

f:id:sugimomoto:20200103155722p:plain

ちなみに今年一番はてなブックマークがついた記事は「無料の API 自動生成ツールを使って、Excelファイルから REST API を生成してみる：CData API Server」でした。199ブクマ。

kageura.hatenadiary.jp

タイトル的に伸びるかなと思っていましたが、想定以上に大きな反響があってよかったです。

次にブックマークが多かったのは「500万件を超えるTwitter のリツイート データを取得・分析する方法　-Twitter Premium Search API を実際に使ってみてわかった嵌りポイントとその対策-」

かなり挑戦的な取り組みだったと個人的にも思っていたので、よかったなーと思っています。

bit.ly

  • 会社のBlog

ちなみに、会社のBlogには「33件」投稿していました。自分のBlogと併せてトール「84件」だったので、来年は100を目指してもいいかもですね。

www.cdatablog.jp

SNS・Twitter

Blogは伸び率がそこまででもありませんでしたが、ツイッターは結構頑張っていたみたいでした。ツイート数だけでも、去年の2倍くらい。そこまで意識していたわけでも無いので意外でした。

f:id:sugimomoto:20200103155732p:plain

ただ、後述の勉強会への参加数が大きく伸びていたので、それに伴うツイート数の増加が大きな要因ではないかなと見ています。

あと、APIに関するツイート数が1000を超えていたのはいいですね。関連のニュース・トピックに関しては積極的に発信していくようにしましたが、去年に比べて3倍の発信量でした。

勉強会・コミュニティ

個人的に一番大きく変わったなーと思ったのは、勉強会・コミュニティに対する参加・登壇状況でした。

2018年が22参加でそれでも結構多いなと思っていたのですが、2019年は36個になっていました。

プラス、それよりも登壇数の大幅増加が凄まじい。2018年5個だったのに、2019年が19と3倍強に。

f:id:sugimomoto:20200103155742p:plain

もうちょっとちまちまLTをしているのかなと思いきや、実はメイン登壇がほとんどで、そこもまたびっくり。

ちなみに表には出していないのですが、主催イベントも合計5個と、よくやったなーと改めて思います。

なお、仕事の登壇も「3件」ほどあったので、トータル「22件」発表していたようです。

Youtube

途中からやり始めたYoutubeは合計5つとまだまだこれから感。

基本的にイベントの登壇を編集して公開しているだけだったので、視聴数的にもこんな感じかなというところに留まりました。

f:id:sugimomoto:20200103155750p:plain

イベントの配信は2回ほど行いましたが、GoProでの配信はそれなりによかった感です。

来年はもう少し仕事としてもうまく活用していきたいと思っています。

API

今年もいろんなAPIを触って、CData Driverとコラボレーションしていきました。

いくつか公開している、CData Driverでのプロトタイプは公開していないものも含めてトータル20個近く作ったみたいでした。

公開しているメインどころは以下のようなサービスです。

PostmanのAPI検証を行ったコレクションもトータル49個と多くなっています。2018年からの差分は取っていないので、このあたりは来年の伸び率もウォッチしていきたいところですね。

2020年に向けて

Blog

Blogの投稿はイベントへの参加と併せてもうちょっと伸ばしたいところです。登壇をスライドで済ますだけでなく、記事にもしておくサイクルが2019年は確立できたかなーというところなので、そこは引き続き同じ用に注力。

API検証記事＋反響が良かったAPI公開記事を別データソースや別シナリオ・クライアントとのコラボレーションで増やして、トータル60くらいを目指せればというところでしょうか。

コミュニティ

登壇は引き続き頑張っていきたいところですが、量的には今の数くらいがやれる範囲かなとも思ったりです。

それよりも、BlogやSNS・Youtubeによるアウトプットの質を高めて行く感じかなとも考えていたりですね。

SNS・Twitter

Twitter の投稿は今まで通り、API注力で。もう少しシナリオペインで、発信していきたいところ。そこまで2019年で意識してツイートしていたわけでも無いので、API検証と併せて1500ぐらいは目指せるんじゃないかなと思ったりです。

Youtube

Youtubeはもうちょっとちゃんとやろうと思ったりでした。

今までは勉強会での登壇を記録したものベースでしたが、そもそも勉強会やイベント登壇前にランスルーをするので、それをYoutube用にキレイに編集して公開していきたいなと考えています。

トータル12本（月1）くらいかなー。

API

個人的に今年一番注力したいのはここですね。

存在を知っていながらも、まだ API 検証が済んでいないものは以下の通りかなーと。このあたりを引き続きCDataも含めてコラボレーションしていきたいところなので、2019年は20件でしたが、2020年は40件ほどを目標にしていく心づもりです。

その他

Blazor の取り組みは個人的に大きなターニングポイントでした。今まで個人としてWebサービス・アプリを公開したことが無かったんですが、私自身が持っているスキルをうまく活用しながら公開できることもあり、この辺を組み合わせて何か面白いアプリを作って、公開していければなと。

kageura.hatenadiary.jp

VS Code Snippet も私が今までやっていたものとは大きく違った取り組みでした。拡張機能開発にも興味があるので、会社の製品とも組み合わせて何か公開できればとも画策したり。

kageura.hatenadiary.jp

Dynamics + PowerPlatformは、社内でCDSを使おうかなーとも考えていることもあり、APIと組み合わせた取り組みを発信していければなと考えています。

Blazor で API Explorer を作って色々悩んだお話 ＃GyutanKaigi2019

Blazor C# API

先週土曜日に仙台で開催した「牛タン会議2019」でBlazorについての発表をしてきました！　今回はその内容をもうちょっとまとめて、Blogとして公開したものになります。

speakerdeck.com

vsuc.connpass.com

ちなみに、この記事は Blazor アドベントカレンダー 12日目です。めちゃくちゃ遅くなってごめんなさい・・・orz

qiita.com

こんなものを作ってみた

実は私、ちょうど2ヶ月ほど前から Blazor を触り始めたんですが、なんて素晴らしい！　　JavaScriptのフレームワークが苦手な私でもこれならなんか作って公開できそうだ！（思い違い）　と感激していました。

そこで、当時開発でよく悩んでいたスマレジのAPIを手軽に実行できるアプリを作ってみたのです。

f:id:sugimomoto:20191217212509p:plain

スマレジ API はすごく柔軟な機能を提供していて、数多くの操作、リソースをコントロールできるのですが

f:id:sugimomoto:20191217212518p:plain

API リクエストの仕様がちょっと独特かつ、項目が多いので気軽に試すのが難しいかなーというAPIでした。

f:id:sugimomoto:20191217212525p:plain

なので、Facebookや Microsoft が公開しているような API Explorer を作って公開しちゃえば、このつらみから開放されるのではないか！？　と考えたのです。

そして作ってみたのがこんな感じのものです。

https://cdatajbuilds.s3-ap-northeast-1.amazonaws.com/sugimototest/smaregi.gif

まだ手直し真っ只中ですが、以下のAzure Web Apps で公開しています。（低料金プランとSignalIR未設定のためか、ちょっと重い・・・）

https://smaregiapiexplorer.azurewebsites.net/

さて、なんとか自分がイメージしていたものが動くところまでは至ったのですが、そこで色々とぶつかっていたので、それを共有したいと思います。

私が遭遇した課題 その1

このAPI Explorer を実装する上で、一番の課題だったところは、一番の機能的ポイントでもある、動的なテーブル形式のInputフォームでした。

f:id:sugimomoto:20191217212534p:plain

スマレジ APIは各カラムのフィルターを柔軟に書けるようになっている反面、この部分のリクエストをJSONで書くのがなかなか大変だったので、この部分の実現が一番の肝でした。

ただ、この動的なInputフォーム動的であるが故に、Blazorの強力なバインディング機能でプロパティに値をバインディングできない（できないよね？　できたら教えて下さい）！

バインディングできないと、値のとり方がわかんない！

私の試みた解決策 その1

まあ、しょうがない。それじゃあDOM APIにアクセスして、動的に取ってくればいいんでしょ？　と考えたので Blazor で DOM APIにアクセスするライブラリはなーんだ？　と探したわけですが

FAQ · aspnet/Blazor Wiki · GitHub

Q: Can I access the DOM from a Blazor app?

You can access the DOM through JavaScript interop from .NET code. However, Blazor is a component based framework that minimizes the need to access the DOM directly.

（あなたはBlazor で DOM にアクセスできるよ！　そう、JavaScript ならね！：意訳）

JavaScriptか・・・！

Blazor では JavaScript 相互運用機能（Interop）という、.NET MethodからJavaScriptを呼び出す機能が備わっており、この機能でJavaScriptが取得したDOM APIのデータをJSONなどの形式にまとめて、レスポンスとして .NET 側に返す機能が備わっています。

docs.microsoft.com

できる限り、JavaScriptを書きたくなかった私ですが、ここで諦めてHTMLテーブルのInputをなめて、JSONを返すJavaScriptMethodを書き、対応することにしました。

私が遭遇した課題 その2

しかし、ここでも躓きます。JavaScriptでDOM APIにアクセスして、テーブルの情報を取得することはできました。

ただ、Blazorは各Inputやバインディングの値が変更された際に、DOM要素をレンダリングし直します。

docs.microsoft.com

その結果、JavaScript 相互運用で非同期処理をしていることにより、リクエスト生成ボタンをクリックする（JavaScript が DOM の値を取得する）前に、Blazor が DOMを初期状態に書き換えてしまい、値が取得できないということが発生。

取得できていても非同期処理がレンダリングのタイミングがずれて、裏の変数では値を保持しているのに、レンダリングしている値と一致しないということまで発生しました。

私の試みた解決策 その2

結局私が最終的に試みたアプローチは、テーブルInputが変更される度に JavaScriptで値を取得して、テーブルを構成するためのListプロパティに逐次差し戻し、最新化するというものでした。

以下の「columnInput」がテーブルを構成するための要素をすべて保持しており、

                <BSTable IsSmall="true" IsBordered="true" IsStriped="true" Class="overflow-auto" style="max-height: 200px;">
                    <BSTableHead>
                        <BSTableRow>
                            <BSTableHeadCell>Select</BSTableHeadCell>
                            <BSTableHeadCell>Id</BSTableHeadCell>
                            <BSTableHeadCell>ColumnName</BSTableHeadCell>
                            <BSTableHeadCell>ColumnName(J)</BSTableHeadCell>
                            <BSTableHeadCell>ColumnType</BSTableHeadCell>
                            <BSTableHeadCell>ConditionType</BSTableHeadCell>
                            <BSTableHeadCell>ConditionValue</BSTableHeadCell>
                            <BSTableHeadCell>Description</BSTableHeadCell>
                        </BSTableRow>
                    </BSTableHead>
                    <BSTableBody>
                        @foreach (var column in columnInput)
                            {
                        <BSTableRow>
                            <BSTableCell>
                                <BSBasicInput Class="form-control-sm" InputType="InputType.Checkbox" Value="@column.Select"></BSBasicInput>
                            </BSTableCell>
                            <BSTableCell>@column.No</BSTableCell>
                            <BSTableCell>@column.Name</BSTableCell>
                            <BSTableCell>@column.JapaneseLabel</BSTableCell>
                            <BSTableCell>@column.Type</BSTableCell>
                            <BSTableCell>
                                <BSBasicInput Class="form-control-sm" InputType="InputType.Select" Value="@column.ConditionType" @onselect="@SetColumnInput">
                                    <option></option>
                                    <option>=</option>
                                    <option>like</option>
                                    <option>&lt;</option>
                                    <option>&lt;=</option>
                                    <option>&gt;</option>
                                    <option>&gt;=</option>
                                </BSBasicInput>
                            </BSTableCell>
                            <BSTableCell><BSBasicInput Class="form-control-sm" InputType="InputType.Text" Value="@column.ConditionValue" @onchange="@SetColumnInput"></BSBasicInput></BSTableCell>
                            <BSTableCell>@column.Description</BSTableCell>
                        </BSTableRow>
                            }

                        @if (columnInput.Count == 0)
                            {
                        <tr>
                            <td colspan="8">No Records</td>
                        </tr>
                            }
                    </BSTableBody>

                </BSTable>

SelectボックスなどのInputが操作されるたびに、JavaScriptが値を取り直しています。

        public async void SetColumnInput()
        {
            columnInput = await JSRuntime.InvokeAsync<List<ColumnInput>>("tableDataManager.getTableValues");
        }

これにより、テーブルを構成しているオブジェクトの値を最新に保つようにしています。

Blazor でアプリを作る上で感じたポイント

と、ここまで私の課題と解決アプローチをお話してきたのですが、これが「まっとうな」「ベスト」といえるアプローチに行き着くことができていない、というのが正直なところです。

なので、この発表をした牛タン会議では、最終的に会場に居る素晴らしいMS MVP の方々へ「どうしたらよかっただろう？」というのを聞く！　というが本来の目的だったのですが

f:id:sugimomoto:20191217212547p:plain

ちょっと会場の時間が押していたこともあり、なくなく断念となりました（泣

というわけで、せっかくなので、このBlogでもヒドイコードを晒して対応アプローチを募ってみたい、と思っています。

github.com

ちなみに、私がこの経験を通じて得た教訓は「できる限り値はバインディングするに限る。直接的なバインディングなのか、間接的なバインディングに問わず」というものでした。

（こんなBlogでいいのだろうか。）

おしまい