「PC&Gadget」カテゴリーアーカイブ

【PC&Gadget】スマホをHUAWEI P20に変更した。

IMG_20181019_152311019_HDR

永らく(といっても2年ぐらいか)使っていた、MotorolaのMoto G4 Plusがいろいろと不具合を抱えてきたので、致命的ではないものの業務のこともありスマホの変更を余儀なくされました。

変更時の条件はいろいろあったものの

  1. 安定して動作すること
  2. (できれば)軽快に動作すること
  3. SIMフリーであること
  4. 技適を取得していること
  5. DSDSであること
  6. 写真がきれいに撮れるとうれしい
  7. 条件を満たせればメーカーはこだわらない
  8. できれば安価であること

が挙げられた条件です。(多いw

中にはややマニアックな条件もあるけど、わからなければググってください。

更新するスマホの候補

さて、そんな条件の中から候補に挙がったのが、HUAWEIのP20 pro、P20、Google Pixel 2、HTC U12+、iPhoneXなど。

いろいろ条件はあげつつも、正直なところ一番重視したい要素は6.の写真撮影性能であり、そんなスマホの写真性能の比較検証を行っているサイト「DxOMark」の評価結果が多分に反映された候補と言っていい感じ。

Home

Home

その候補の中からその他の条件を絞り込むと、P20、P20 Pro、U12+あたりが残り、最終的には予算的な都合で消去法によりP20に決定されたという流れですかね。

ということで、早速購入。
今更汎用OSのAndroid機に特に説明することもないですが、以下のような点が「ほほーぅ」となった点。

  • 顔認証スゴイ(Surface の Helloで体験済みではあるけれど)
  • NFCついてるやん(使い道ないけど<名古屋の地下鉄私鉄ははよNFC対応してくれ>)
  • DSDSちゃんと機能してる!(MotoG4が不具合だっただけ)
  • 細かい機能がたくさんあるー
  • 動作サクサク!
  • うーん、やっぱ写真綺麗だわ!
  • ・・・Nano SIMやん

特に写真については一番期待していたところなので、ちょっとだけ紹介。

HUAWEI P20で撮影した写真
料理の写真

IMG_20181020_112435

撮影中、勝手に食事の風景であることを認識して最適なモードが設定されました。
個人的にはもうちょっとコントラストがある絵がいいのですが、これはこれでいい感じです。
一般的な、SNSへの飯テロ攻撃にはもってこいでしょう。

夜景モード

カメラを起動すると様々なモードがありますが、夜景モードというものもあります。

残念ながらマンハッタンにも香港にも夜景撮影に出かけられないので、通勤途中に撮影した最寄り駅の写真。

背景は田舎ならではの漆黒の闇、手前の駅のホームは本が読めるほどの十分な照明、中央の線路付近はその中間ですが、オブジェクトが赤茶けた砕石というなかなかに難しい状況。

IMG_20181022_191249

↑こちらは標準モードで撮影したもの。
これでも十分きれいに撮れていますが・・・

IMG_20181022_191243

夜景モード。

空は黒く、照明は白飛びせず、かつ中央の砕石もしっかりと粒度を保って表現できています。すごいわー。

ポートレイトモード

IMG_20181027_124032

今時のスマホにはほぼ当たり前のように搭載されているポートレイトモード。

家族でフラっと買い物に出かけたときの休憩中のシーンを何気なく収めただけですが、肌の色彩、明度はしっかりと確保しつつ、程よく背景をぼかしていい感じになっています。

昔は一眼じゃないとこんなの撮れませんでしたよねぇ。
(でもやっぱり一眼で撮ると細かい描写で一眼に軍配が上がる気がします)

アパーチャモード

アパーチャモードって最近のスマホじゃ普通なんでしょうか。
アパーチャモードにすると、いわゆる「絞り」をマニュアルでコントロールできるインターフェイスが現れて、任意の絞り(おそらく疑似的なものですが)で撮影ができます。
技術資料によると、ダブルレンズの視差を利用して測距し、処理エンジン側で再現しているそうです。

ちょっとサンプルが悪く中距離が甘いですが、絞りに相当する設定を極端に振って撮影してみました。

IMG_20181027_095613

アパーチャ値(絞り相当?)0.95。
いわゆる開放な状態です。0.95ってすごいな。
フォーカスは中央の巻貝に当ててあるんですが、手前の二枚貝も20センチ程度しか離れていませんがいい感じでボケています。
ただちょっと遠景のボケがワザとらしいというか、大げさな印象を受けます。

IMG_20181027_095623

反対にアパーチャ値16。
絞り込んだ状態なわけですが、サンプルが良くない。
中央、その周りはいい感じにフォーカスされてますが、さすがに遠景は若干ボケてます。

まぁでもこれだけわかりやすく設定値によって画質に差が出るので、セオリー通りにポートレートや接写は解放で、風景などは絞って・・・なんてことが手軽にできるので面白いですね。

IMG_20181027_095706

中間のアパーチャ値4.0。

個人的にはこれぐらいがいいかな。
食事撮影なんかはもっと開放気味でとってもいいですね。

期待通りのカメラ性能で、大変満足しております。

番外。Nano SIMについて

もともと使っていたMoto G4 plusがMicroSIMだったこともあり、NanoSIMへの変更を余儀なくされました。
本来ならば、通信事業者へ変更申請すべきところだけどそんな悠長なことしていられない。

ということで、例によってSIMをカットすることに。
そもそも標準SIMをMicroSIMにカットして使用していたものを、さらにNanoSIMにカット。

埋め込まれたICを切ってしまわないか心配になるものの、基本的に露出している端子部分以外に回路部分が入っていることはないので、安心してカットしよう。(ただし自己責任で)

IMG_20181021_104130

中央がカットしたSIM。右がDSDSのセカンダリとして使用している格安SIM。(OCN mobileONE)

大雑把にカットしたら、やすりできれいに整える。
特に問題もなく認識し、うまく運用できている。

最後に

本音で言えば、もう1ランク上のHUAWEI P20 proが欲しいところでしたが、予算の関係で断念。

Proとのカメラ性能の差が気になりましたが、結果的には十分満足いく結果となりました。

またちょっと写真が楽しめるかも。

【DIY?】名古屋ハッカソンに参加してきました

41517463_2010415452361231_3341189912941559808_n

モノづくり大好きなみなさん、暑い暑いと怪訝な顔をして温度計を恨めしく観た夏が過ぎ去ろうとしている中、終わってしまうことにやや寂しさも感じているのではないでしょうか。
勝手ですねw

さて、そんな夏の終わりに、名古屋市が主催となっている名古屋ハッカソンに参加してまいりました。
こちら。

NAGOYA HACKATHON開催概要
http://jellyware.jp/nagoyaboost/hackathon.html

本イベントは、名古屋市が取り組む起業家育成プロセスの一環で、他にも様々な起業家支援イベントが開催されています。

起業を目指す方、事業化に向けた新しいアイデアを持っている方など、参考にしてみてはどうでしょうか。

NAGOYA BOOST 10000とは
http://jellyware.jp/nagoyaboost/

IMG_20180908_093521316_HDR

まずは結果から

ハッカソンなので作品に対する評価・審査があるのですが、結論から先に申し上げますと、見事優秀賞をいただくことができました。
嬉しい、わーい。(最優秀賞1点、優秀賞2点)

IMG_20180909_184524576_HDR

そういえば春先に開催された中京テレビのHack-Chuでも優秀賞をいただいたので、今年二つ目の優秀賞です!やった!

が、素直に喜べない理由も。
それは後述。

ちなみに当日名古屋市の大ボスも来てました。

IMG_20180908_102332245_HDR

テーマ

今回の名古屋ハッカソンは、「ヘルステックナゴヤ」が主テーマになっており、さらに協賛企業さんがメインテーマに沿った小テーマを出されていました。

各企業様の事業内容に沿って、独特の小テーマが展開されており、その小テーマを眺めているだけでも楽しかったです。
(中には少々強引な感じもありw)

今回参加時に、介護事業を営む水野さんとチーム参加することを決めていたので、個人的に選択したテーマも介護に関するもの。

・・・違うか。

小テーマは、事前に開催された事前説明会でいくつか発表されており、その際に目に留まった介護に関する小テーマで行こうかな…と介護に関するテーマがあったので水野さんをお誘いしたのでした。

巻き込んでゴメンナサイ。

アイデア

ということで、事前に小テーマが決まっていたので、アイデアは介護に関するものから考えよう!ということで、事前にいくつか挙げておいて、その中から・・・

  • 課題の重要度
  • 実現可能性
  • マネタイズの考えやすさ
  • ハッカソンでのプロトの実現性
  • SWの実装方法
  • 審査員受け
  • ハッカソンだけではない、イベント全体でのテーマ性

など鑑みて、水野さんと数案は決めておきました。
あとは当日の空気など鑑みて、よさげなアイデアを選択する方向で当日に臨みました。

で、当日の流れの中で一つに絞ったのがコレ。

IMG_20180908_150529399_HDR

主に高齢者をターゲットとした服薬管理システムです。
高齢者のみならず、自分のようなサプリメント常用者や子供の服薬管理にも応用できますね。

幸い、参加者ウケも良かったので、介護系全般にピボットする可能性を残しつつ、これを軸に水野さんの案も交えつつチームビルディングすることにしました。

ちなみに、薬の発注からサービス化しているところで、一回の服用単位でパッキングしてくれるサービスというのは既にあります。(アメリカですけど。)

 

チーム

幸いにも参加者投票が多かったので事前に参加者の前で簡単なピッチをすることができ、チームビルディングはしやすい状況にありました。

エンジニアリングは主に私、テーマに沿った発表資料作成は水野さんを主体にするという方向でチームの機軸を決めました。

しかしながらこのチームの弱点は事前にいろいろと情報共有やディスカッションを進めていたこともあり、やや進め方に偏りがあることを感じていたため、意外な視点で新しい要素を提案してくれるチームメンバーが欲しいなと考えました。

テーマが介護ということもあり、介護に係る機会が多い属性が理想的・・・それって女性だよね?ということで、会場内で目についた女性に声をかけまくるという破廉恥なチームビルディングとなりました。

結果、このような素晴らしいメンバーに恵まれました。
いや、偶然の産物なんですが、ホントに素晴らしいバランス。

41445854_2170440363167824_3053580095139610624_n
最高のチームメンバー!

プレゼンテーションチーム

  • 資料作成/統括・・・水野さん
  • 起案/調査・・・渡辺さん
  • 起案/調査・・・吉崎さん

エンジニアチーム

  • サーバサイド/基盤・・・入口さん
  • クライアントサイド・・・諏訪さん
  • ハードウェア製作・・・榊原(私)

綺麗に担当を分けることができ、またそれぞれ技術やノウハウのバランスも良く、最初に大まかに方向性を共有し、役割分担をしたらあとは勝手に作業が進んでいきました!
素晴らしい!

モノづくりの経過

iriguchiandsuwa
エンジニアチームの大黒柱二人

大方作るものと構成は考えていたので、エンジニアリングチーム内での役割分担もうまくいき、前述のように

  • サーバサイド/基盤・・・入口さん
  • クライアントサイド・・・諏訪さん
  • ハードウェア製作・・・榊原(私)

な割り振りにしました。
HWは例によってSeeed社のWio nodeとサーボの組み合わせで薬剤排出部分の制御を行いますので、サーバ側からはWioのAPIを呼ぶだけです。

参考までに過去のエントリーを紹介

Wio node + Azure Logic Appsでお手軽IoT【Wio node初期設定編】

【PC & Gadget】WIO NODE + AZURE LOGIC APPSでお手軽IOT【データ取得編】

自分だけなら、UIをPowerAppsで、基本処理をFlowでサラっと作るところでしたが、各メンバーの得意な分野での実装に任せる方向にしました。幸い実装技術もうまく分かれていたし!

プロト版の目標は

  • 3回程度、実際に薬剤排出するデモができること
  • オマケ機能は、基本ができたら

に絞りました。
発表時間も限られるため、HWを使ったデモはあまり重要視せず実現可能性を示すだけに留めることとしました。
無理してもショーがないし。

IMG_20180908_223643261_HDR

薬剤排出の仕組みは、箱を多数用意してふたを開閉する方式を最初思いついたのですが、蓋の数だけ動力が必要になるため、デモ向けのプロトにしてもやや製作が面倒+100均で売っているピルケースと見た目が似通うためUI/UX的に新しさが無いということで、観覧車のゴンドラに薬剤を載せて、観覧車を一定角度回してゴンドラの薬剤を輩出するという仕組みをとりました。

 

この方式だと、デモ用プロトの範囲だけなら、サーボ一個で動作させられます。(プロト版は観覧車の軸にサーボの軸を直結したので、最大160度しか回らないというデモ限定仕様)
本来はちゃんとステッピングモータなどでやるべきですね。

IMG_20180909_100418367_HDR
サーボの動作異常が見られたので、電源取り直すために小加工。

初日にWio nodeとサーボは持ち込んでいたので、エンジニアチームに簡単な動作デモを見せてAPIを紹介したら、あとは入口さんと諏訪さんにUI~制御周りの実装はお任せしてしまいました。

すぐに近所のイオンに実際のハード部分の資材調達に!
全部100均で揃えました。
紙皿にマヨカップ、フォトスタンドにPPシート、ゼムクリップに押しピンと、まさに誰でも手に入る資材です。

製作の過程はめんどいので割愛して、実際にはこんなものが出来 上がりました。

IMG_20180909_161532728_HDR
正面。

41539683_10216282599439533_948689852562407424_n
背面。

IMG_20180909_161500005_HDR
中身の排出機構。紙皿とマヨカップ、ゼムクリップとフォトスタンド!

中身の観覧車はそこそこに、外装にちょっとこだわってます。
ただ、外装の接着のためのタブがあまりにもみっともない・・・別のうまい接合方法も考え付いたんですが、考え付いたのが外装5割できてからだったのでそのまま進めることに・・・残念。

実際にサーボ接続して、カップに薬剤投入しての初動。
(事務所で徹夜製作して動作テストはしていたんですけどね)

ああああ薬がwww
排出というより拡散になってるwww
原因を確認すると、サーボが想定仕様通り動いてない疑い。
Seeedさん!ということでSeeed社の松岡さんにHELPをお願いしたところ、どうやらサーボ制御用のライブラリにバグがあった模様で、ソッコー対応いただきました。松岡さん超感謝!

で、バグ修正の間に外装が整ってきたので外装付けた状態で再度テスト。

この動作を目指していたので仕様通りと言えば仕様通りなんですが、割とギリギリで調整していたので、思わず声が出ましたw

iOS の画像
なにやら怪しいドーピングアイテムが並ぶエンジニアチームの一コマ。

この時点でかなり時間が迫っていたので、製作はここまでとし、実際のデモは行わずプレゼンの中で動画を紹介する方向に。
本番でモタつくより、その方が確実ですね。

満足はいきませんが、最低限目指すところまでは動作したのでほっとしました。
エンジニアチームの入口さん諏訪さんありがとう!
最高のチームだ!!
(HWに係りすぎて彼らいなかったらホント動いてなかったカモ。)

プレゼンテーション

もう一つの大事な要素、プレゼンテーションは、水野さんをはじめとしたプレゼンテーションチームが最初の目標設定とポイントの共有だけでモリモリ進めてくれました。

時々方向性や数字の確認をされた程度でスバラシイ資料が出来上がってる!
いつもはどっちかというとそっちの役割の方が多かったりするので、チョッピリ寂しくも、とても新鮮でした。勉強させてもらうポイント多かったし。

社会課題の提示の仕方や、裏付けとなる数字の調査や表現、また解決策の提示の仕方も素晴らしかったし、発表時間を上回るチームが多い中、キッチリ時間内に収める構成力、なにをとってもうまくまとまっていて、最高でした!

プレゼンテーションチームの水野さん、渡辺さん、吉崎さん、お前ら最高だよ!!!!!

感謝

今回は私のアイデアベースにハッカソンが進んでいったのですが、HWに必死になりすぎて本当に要所要所しか全体を見てませんでした。

そんな中・・・

  • 資料を作成しながらプレゼンテーションチームを引っ張ってくれた水野さん
  • 水野さんのサポートをしながらいろんな調査をしつつ、助言をしてくれつついいムードメイカーにもなってくれた渡辺さん
  • プレゼンテーションチームが忙しく資料作成する中、年長者二人が手の届かないところにうまくサポートとして入っていただいた吉崎さん
  • エンジニアチームのクライアントサイド担当として、最低限の指示しかしてないにもかかわらず自力で頑張って実装してくれた諏訪さん
  • エンジニアチームのサーバーサイド担当として、(いいかげんで)抽象的な指示を的確に咀嚼して実装してくれた入口さん
  • サーボ制御ライブラリのバグを速攻調査してくれた上に修正してくれたSeeedの松岡さん

皆さんがいてくれたからモノができました!
そして見事優秀賞!本当にありがとうございます!

それからこんな面白いハッカソンを企画・運営していただいた開催側の皆様、お疲れさまでした&ありがとうございました。

41322986_2170440343167826_894842314269130752_n

素直に喜べないところ・・・

最後に、冒頭でちょっと触れた素直に喜べないところ。

上述した、アイデア出しただけで、あとは夏休みの工作レベルのハード作成に必死になってしまっていたところですね・・・
情けない。

Hack-Chuも同じく、インフルエンザとはいえチームメンバーに頼りっきりで実現した優秀賞・・・私の価値って・・・orz

ハッカソンは楽しいぞ!

出るからにはなんらかの賞をもらいたいところですが、ハッカソンって結果はもちろんのこと、そのプロセスから学ぶことがとても多い、貴重なイベントだと思います。

みなさんも、周りでハッカソンが開催されていたらぜひ参加してみて下さい。

エンジニア寄りのイベントに見えますが、エンジニアリングにしか目が向かないわがままで一辺倒なエンジニアをうまく誘導するデザイナーやプランナーの存在もとても重要です。

【PC & Gadget】WIO NODE + AZURE LOGIC APPSでお手軽IOT【データ取得編】

このエントリーは、このエントリーの関連です。

【車DIY】車のエアコンが効かない!!!!!(2)

さて、IoTしてますか?
Office365してますか?
SharePointしてますか?

と、煽りながらのスタートですが、いずれのカテゴリーにしてもそれほど高度な内容ではないので、玄人諸氏はそっとタブの「閉じる」ボタンをクリックがよろしです。

今回は、ずいぶん前にエントリーした本記事の続編とも関連記事とも言うべき内容です。

Wio node + Azure Logic Appsでお手軽IoT【Wio node初期設定編】

以前のエントリーでは、Wio nodeのセットアップについて解説しましたが、本エントリーではセットアップ後、データ取得ができるようになったIoTエッジ(Wio node)からデータを取得し、可視化していく方法を記載しています。

ざっくりいうとこんな感じですね。

  1. Azure Logic appsを利用可能にする。(※1)
  2. Azure Logic apps からWio nodeのAPIにアクセスして、現在の値を取得する
  3. 取得した値をSharePoint Onlineの任意のリストに格納する

※1:Office365のFlowでも可能ですが、今回の要件の場合Flowでは実現できなかったため、Logic  appsを使用しています。(後述)

うーんむ、超簡単。
では実際やってみましょう。

IoTエッジ(Wio node)からの値を取得する

最近IoT関連のデバイスで特にお気に入りなのが、SeeedのWio nodeです。MFTでお手伝いしたからとかそういう政治的な忖度は全くなく、純粋に圧倒的に使いやすいからです。

パッケージを開けて、電源を投入してセットアップすれば、10分後にはWio nodeのセンサに接続されたデータを利用したり、接続された機器を制御できます。
しかもお値段僅か1000円(Wio nodeのみで)。

Wio nodeからのデータ取得(機器制御)は、煩わしいコーディングをすることなく、Seeed社が提供するサーバーに用意されたAPIに、トークンを付与して呼び出すだけ。

反対に、呼び出す頻度やタイミング、呼び出して取得した後のデータの操作はこちら側で用意する必要がありますが、一般的なソフトウェアエンジニアにとって、不慣れなハードウェア操作の煩わしさがなくなるだけでずいぶんと敷居が下がります。

では実際に、値を取得してみましょう。

Microsoft Azure Logic appsから取得する

Micrsoft Azureの利用方法、Logic Appsのセットアップ方法はここでは割愛しますが、要望が多ければ別にエントリー作成します。

Logic Appsがセットアップされて、Logic Apps デザイナー(編集画面)が表示されている状態からWio nodeの値を取得してみます。

2018-08-29_09h07_40

Logic Appsの初期画面から、「一般的なトリガーで開始する」にあるサンプルトリガー「繰り返し」を選択します。

2018-08-29_09h09_26

すると編集画面に遷移します。

2018-08-29_09h14_56

または新規に作成し、トリガーを「スケジュール」で検索して選択します。

2018-08-29_09h16_21

全く同じ機能なのに、見出しが違うものが存在します・・・。
一応どっちでも動作することを確認しています。

Wio APIにリクエストを送る

2018-08-29_09h45_09

Wio APIから情報を取得するために、新しいステップを追加し「HTTP」アクションを選択します。

2018-08-29_09h45_32

「HTTP」にも数種ありますが、シンプルな「HTTP(リクエスト)」を選択。

2018-08-29_09h46_57

いろいろなパラメタが並んでいますが、Wio APIの場合は

  • 方法
  • URL

の二項目だけを入力すればOKです。
方法は「GET」を選択し、URLにはWio APIで表示されるURLを入力します。

2018-08-29_09h59_28

この画面ですね。
(この画面そのものは、前回の記事を参考にアプリから参照してください。)

2018-08-29_09h49_01

最後に、必須ではありませんが該当タスクの名前を変更します。
今回は一つだけなので悩まないんですが、取得するセンサーの数が増えるとホントに困ることになります。

2018-08-29_09h50_07

「Wio nodeからの温度の取得 001」にしました。
こんな感じで、どのセンサーの値からかわかるようにするとよいでしょう。数字で管理も実はやめた方がいいですが。

これで「HTTP」のタスク内での、Wio nodeからの値の取得まではOKです。
ここまでの流れでWio APIに値取得のためのリクエストを投げ、JSONで値が返ってくるところまでが完了です。

JSONを解析する

2018-08-29_09h48_12

続いての処理。
アクションの追加を行い、「JSON」で検索を行うと、「JSONの操作」というアクションが見つかります。
クリックして追加すると

  • コンテンツ
  • スキーマ

の項目が現れます。

2018-08-30_18h28_36

コンテンツは、入力欄をクリックすると現れる「動的なコンテンツの追加」から展開されるダイアログから入力します。

2018-08-29_09h51_34

「Wio nodeからの温度の取得 001」というグループから、「本文」を選択します。
この本文が実はJSONなんですが、それを解析するということですね。

続いて、どのように解析するかを指示してやります。
「スキーマ」に受け取ったJSONのスキーマを設定してやりますが、0からコード書くのはめんどうなので、「スキーマ」入力欄の下にある

「サンプルのペイロードを解析してスキーマを生成する」

を利用します。

2018-08-29_09h59_28

Wio APIのWeb画面には、実際にリクエストを送ってテストする機能まで備わっているので、遠慮なく利用します。
画面上の「GET」ボタンを押すと、実際に接続されたWio nodeから取得した値が表示されます。
(この画面そのものは、前回の記事を参考にアプリから参照してください。)

上手だと下の赤枠内、「Response:」の下ですね。
これをコピーして

2018-08-29_10h01_19

先ほどの「サンプルのペイロードを解析してスキーマを生成する」をクリックして開いたダイアログに張り付け、「完了」ボタンをクリックします。

2018-08-29_10h03_22

すると、「スキーマ」欄に解析されたJSONのスキーマが読みだされます。
うーんむ、超便利。

が、一つここで問題が。
読み取ったセンサーの値によっては、型の判定がうまくいかない場合があるので、一度テストしてみてうまく取得できない場合、肩を変更してやる必要があります。

今回の場合、自動で生成したスキーマでの型は「integer」でしたが、実際は型指定のエラーが発生したため「number」に変更しています。

image

実際のエラー

2018-08-29_10h04_28

型を「number」に変更

これで、リクエスト→値取得までができたことになります。
次以降のステップで、任意のWebサービスなりアクションなりを利用してデータを利用していく形となりますが、今回はOffice365のSharePointで値を収集してみました。

なんというか、使い慣れていて楽なんですよね。

SharePointに値を格納する

SharePoint上には、すでにカスタムリストで「温度測定実験」というデータ格納先を作ってあります。

image

ここにLogic Appsから接続し、値を格納していきます。

2018-08-29_10h09_11

追加したステップで「SharePoint」アクションを検索し、リストから「項目の作成」を選択します。

2018-08-29_10h10_08

「項目の作成」アクションでは、接続先のSharePointのサイトアドレスを求められます。
またサインイン状態にない場合、サインインを求められます。
うまく接続できると、リストの一覧などが表示されるため、該当するリストを選択します。

リストを選択すると、リストに含まれる変更可能な要素が入力欄として表示されるため、値を設定してきます。

今回の場合

  • タイトル
  • 温度
  • 取得時間

が要入力項目です。

2018-08-29_10h07_26

タイトルはとりあえず何でもいいので、今回は「測定値」としました。
次の「温度」」が肝心なのですが、その他のアクションと同じように「動的なコンテンツの追加」から展開されるダイアログから入力します。

2018-08-29_20h41_06

基本的にはこれでOK

2018-08-29_10h22_41

最後にステップ全体を「保存」して終了です。

二つ隣にある「実行」をクリックして、エラーが無いか確認しましょう。うまく動作すれば、SharePointに値が登録されていくはずです。

image

ということで、うまく登録されていますね。

今回のネタ元のエントリーでは、ここからExcel出力してグラフ化しました。

Office365 Flowからの場合

Office365のFlowからの場合でも、大きな手順は変わりません。
ほとんどLogic Appsと同じ感覚で取得できますが、一点だけ異なる点が。

2018-08-29_09h31_39

新たなフローを作成

2018-08-29_09h32_37

イチから作成

2018-08-29_09h33_09 2018-08-29_09h33_35

スケジュールのトリガーを選択

2018-08-29_09h17_33

ここで、10秒ごとのトリガー作成を試みたところ、契約しているプランではこのタイミングの設定はできないとのこと。
私が契約しているのはBusiness Premium のため、E3などならできるかもしれません。

E3で契約しているテナントお持ちの方、誰か試してみてください。

2018-08-29_09h35_10

本当はOffice365で完結させたかったのですが、上記の理由でやむを得ずLogic Appsでの対応となったわけです。
Flowの場合、最低60秒=1分から可能のようです。

ということで終了です。
ちゃちゃっと書くつもりがずいぶんと長くなってしまいました。

そのうち続編書きます。

【車DIY】車のエアコンが効かない!!!!!(2)

さて、先日はエアコンのトラブル対処法(単なる適正な仕様説明)を紹介しましたが、その後も暑さは続き、たしかに冷えるようになったとはいえなんだか満足いく冷たさではありません。

【車DIY】車のエアコンが効かない!!!!!(1)

いわゆるミニバンで、車室内が広いためにエアコンが効きにくい・・・なわけないでしょ。ふつうは車室内の容積に合わせてエアコンの能力設計するし。
とはいえ、小さい軽だから小さいエアコンというほど能力に合わせた設計+製造の幅も広くない(小さいほど能力に対するコストが上がる)ので、デカい車はある程度は冷えにくいというのはありますが。

まずは状態の確認

さて御託はいいとして、感覚的に冷えないのは気になるので、実際エアコンの状態がどうなのかを確認してみます。

が、一般の家庭でにカーエアコンの点検といってもやれることは限られていて・・・

  • コンプレッサを動かしているベルトの張りの点検・・・コンプレッサの動作不良
  • サイトグラスからの気泡の点検・・・ガスの残量チェック

ぐらいのものしょう。

ということでベルトの点検をするも、有意なゆるみは無し。
エンジンをかけ、エアコンを最大風量にセットしてしばし待ち、サイトグラスを確認すると・・・

こりゃアカン。

どの程度アカンのか定量的にはサイトグラスの点検程度ではわかりませんが、良くない状態であることぐらいはわかります。
サイトグラスの中の液化したガスが、白く濁ってボコボコしている状態です。

セオリー通りにやるのであれば、まずは重篤なガス漏れを起こしていないか機器・配管類をリークチェックした後、ガスの充填圧を正確に計測してそれからガス補充となるんですが、もう年寄りだし(金も時間もできればかけたくない)、いきなり一気にエアコン効かなくなったわけではないので重篤な故障は考えにくいし、近所のガススタ行っても同じプロセスだしOKでしょ。
ということで、いきなりガスの補充行ってみたいと思います。(お金と時間ある、高年式のお車の方はディーラーへご相談を!)

エアコンガス補充に必要なもの

必要なものは・・・

IMG_20180817_140248158_HDR

  • ガス(HFC134a:年式によって異なるので要チェック)
  • チャージホース(AmazonでGet)

以上。

オマケとして、やる気とか勇気とかブログエントリーのための計測装置とかカメラとかでしょうか。

参考までに、以下のリンクから購入できます。

ガスの入れ替え手順の確認

そんなに難しくはありませんが、段取り8割。
ちゃんと手順を確認して、道具や作業を管理しましょう。

  1. 安定した作業しやすい場所に車を停める
  2. 低圧側のエアコンガスメンテナンスポートの位置を確認する
  3. チャージホースのガス缶側のニードルが出ていないか確認する
  4. チャージホースにガス缶を接続する
  5. チャージホースを低圧側のポートに接続する
  6. チャージホース内の空気をパージする
  7. エンジンをかけ、エアコンを全開にする
  8. チャージホースのニードルを回してガス缶を開栓する
  9. ニードルを戻してガスを徐々に注入する
  10. プレッシャーゲージ、サイトグラスの様子を確認して、適量注入する
  11. 良い具合になったらエンジンを停止する
  12. チャージホースのニードルを回してガス管を塞ぐ
  13. チャージホースを低圧側サービスポートから外す
  14. 試運転し、異常がないか確認する
場所の確保と作業個所の確認

どんな整備作業も作業場所は屋内の平坦な舗装された場所が望ましいですが、なかなかそういう場所が無いのも事実。
適度に適切な場所を確保しましょう。

今回の作業の要であるエアコンガスのサービスポートですが、車種によってまちまちなため我が家(AZR60G ノア)の場合を紹介します。

IMG_20180820_170758675_HDR

車両向かって右側、バッテリー搭載位置の下にあります。
キャップには「L」の刻印があります。

IMG_20180820_170813246_HDR

また一般的な車両の場合、ガスは以下のような流路で流れていますので、コンプレッサーか、室内から出ているアルミの配管をたどっていくと探せるかと思います。

  1. コンプレッサーで圧縮(低圧→高圧)
  2. コンデンサーで冷却(高圧)
  3. エバポレータで使用(高圧→低圧)
  4. 低圧用サービスポートを通過(低圧)
  5. 1に戻る
実際のエアコンガス補充の作業

実際の作業は動画で見てみましょう。

動画は補充するところまでで終わっていますが、この後

  1. 良い具合になったらエンジンを停止する
  2. チャージホースのニードルを回してガス管を塞ぐ
  3. チャージホースを低圧側サービスポートから外す

という終了プロセスを行っています。
ゲージで見る限り割と適正でしたが、サイトグラスの確認と併用すると200g一本丸ごと入った状態です。

さて、実際に冷えるようになったか確認してみましょう!

効果測定

ガスの補充を行い、作業の完了後の点検を行い、さて試運転!
エアコン全開にしてしばし様子を見てみます!

  • エアコン吹き出し口からの温度・・・冷たくなった気がする!
  • 車室内の温度・・・涼しくなった気がする!!

どっちも感覚かーいw

これではIT屋の名折れになってしまうので、ちゃんと効果測定をしてみたいと思います。

こんなこともあろうかと、充填前にちゃんと温度計測しておきました!

IMG_20180817_140851692_HDR

車室内温度に・・・

IMG_20180817_142600790_HDR

吹き出し口温度・・・

ってアナログかーい!

これでは本当にIT屋の名折れになってしまうので、ちゃんと図りたいと思います。

今回はこちら。

IMG_20180818_151038065_HDR

Seeed社のWio nodeを使って、IoT的な感じで解決したいと思います。
Seeed社のWio nodeについてのエントリー記事はこちらから。

Wio node + Azure Logic Appsでお手軽IoT【Wio node初期設定編】

また、温度計測のためのデータ格納場所のセットアップなどはこちらを参考にしてください。

【PC & Gadget】WIO NODE + AZURE LOGIC APPSでお手軽IOT【データ取得編】

で、取れたデータがこちら。

ちゃんと事前に準備して、施術前、施術後を取得していますよ!
データは10秒ごとに、数値が安定するまで10分~20分計測しています。

2018-08-27_20h34_22

まずは車室内の温度変化から。

作業開始が午後14時と、温度のピークであるところを考慮し、さらに開始条件の均一化の不手際で施術前の温度データの初期段階にやや温度が下がりにくくなっている部分がありますが、それにしても測定開始時0.5度ほどの差が、10分後には2度ほどの差になっています。
十分に効果はあったとみてよいでしょう。

ただ残念ながら、日差しが差し込む社内での2度って結構気休めレベルかも・・・

2018-08-27_20h34_40

では実際に、車室内を冷やしているエアコン送風口の温度はどうでしょうか。
施術前の最低温度が約12度、施術後の温度が約10度。

これまた開始時の条件がそろっていませんが、グラフを見れば効果は”一見”一目瞭然です。
厳密な話をするとやはり前提条件の違いにより、個人的にはちょっと納得できない結果なんですよね・・・。

もうちょっときちんとデータ取りすれば、自分をもっと納得させられたんですが、うーん・・・。

とはいえ結果オーライということで、今回は終了したいと思います。

【PC & Gadget】PowerBI 勉強会 #8に参加してきました。

今日はPowerBI勉強会の日ということで、前日入りして関東界隈の人と親睦含めながら、PowerBIのお勉強をしてきました。

PowerBIとは?て方はこちらをご覧ください。
「PowerBIとは」
https://powerbi.microsoft.com/ja-jp/what-is-power-bi/

今回8回目の開催になりますが、毎回募集開始と同時に100席が瞬殺される人気イベント/コミュニティです。

私はというと、サポート枠(SNS/ブログ)での参加です。
名古屋の運営にもちょっとだけ関わっていたりします。

PowerBI 名古屋勉強会のご紹介と、名古屋のオープンデータを使った名古屋の紹介

さて、今回のPowerBI勉強会も内容盛りだくさん。
以下、セッションやLTなど勉強会の模様を可能な限りお伝えしたいと思います。

PowerBI勉強会を立ち上げたかがたさん

まずはかがたさんからのご挨拶。

WIN_20180602_13_02_53_Pro

PowerBIとはなんぞや?周辺のテクノロジーや製品との連携や、覚えておくべき技術などを説明をしていただきます。
WIN_20180602_13_04_00_Pro

WIN_20180602_13_05_15_Pro

WIN_20180602_13_08_39_Pro

本日の参加者に関する情報を即取得して表示するという、PowerBIらしいデモを交えた前説。
ConnpassのAPI経由で参加者に関するデータを取得して、リアルタイムに更新します・・・ってアレ?w

気を取り直してPowerBIの重要な役割とはなんでしょうか。

WIN_20180602_13_11_57_Pro
1.ビジュアライズ
WIN_20180602_13_12_41_Pro
2 .共有

重要なのは、ビジュアライズされたものを、共有するということ。
むしろ、共有し、理解を深めるためのビジュアライズと言ってもいいのではないでしょうか。
手段の目的化ってよく揶揄されますが、重要ですね。

PowerBIのあらましをかがたさんから説明いただいた後、セッションが始まります。

「セッション内容は参加者の皆様次第!Power BIアンケートでネタ決め!」

小林寿さん

データサイエンティスト(?)の小林さんのセッションです。
なんと、セッション内容を当日冒頭のアンケートから決めてしまおうという野心的な取り組み。

WIN_20180602_13_17_33_Pro

準備の様子が伝わってきます。

データ収集から可視化、分析、判断のスピード化が期待される昨今、とてもためになります。

参加者の皆様によりアンケートから決まったテーマは「データアナリストが語るストーリーテリングとビジュアルの話」。

WIN_20180602_13_26_06_Pro

ストーリーテリングとは、印象的な体験談などの物語を利用して印象付ける手法。
抽象的な話より、具体的な話の方が理解されやすいですね。

WIN_20180602_13_29_49_Pro

さらにデータストーリーテリングとは、具体的なデータを用いて、強く印象付ける手法。

であるから、単なる表データではなく、まずは視覚的にしてわかりやすくすることが大切ですよということのようです。
そこでPowerBIですよ!

その他のポイントとして、以下のようなことが説明されました。
・グラフを先に選ぶのではなく、データに適したグラフを選択しよう
・ビジュアルづくりは5W1Hでしよう
・BIのレポートと普通のレポートの違いを理解しよう
・相手の目線にたって設計しよう

最後に、PowerBIレポートを作るときに気を付けるべきところをまとめられていました。

WIN_20180602_13_48_17_Pro

ところが・・・

せっかくアンケートとって人気コンテンツのセッション始めたのにここで時間が余ってしまうハプニング。

4つのうち2番目にアンケート結果の多かったDAXのコンテンツも発表されていました。

WIN_20180602_13_50_38_Pro

DAXについては割愛しますが、詳しくは下の公開資料をご覧ください!

アンケートから話をいくつも展開する小林さんの底力に脱帽です。(ネタを用意していたなかったわけではなく、4つ用意していたわけなので!)
こういう巧妙な(大胆な?)仕掛けを勉強会に取り入れると、勉強会も楽しくなるし記憶に残るしでいいことずくめですね。

配布資料

「PowerBI + Common Data Service for Analytics + Business Aplication Platfrom 概要」

マイクロソフト/吉田大貴さん

WIN_20180602_14_15_05_Pro

WIN_20180602_14_14_41_Pro

吉田大貴さんのセッションは、大きく分けて三つ、
・PowerBI
・Business Application Platfrom
・Common Data Services
を利用/組み合わせしたアプリ開発とデータ分析について。

まずはアプリの開発環境の進化について
Business Application Platfrom

WIN_20180602_14_18_22_Pro

PowerBI、PowerApps、MicrosoftFlowのような、ノンコーディングでアプリ開発ができる環境が準備されたことで、コードを書けない人でも手軽に本格的なアプリ開発ができるような世界がもうそこに来ています。ホントそうなんですよ!

実際にデモンストレーション。

WIN_20180602_14_26_00_Pro

会社の受付などに設置する、受付代行アプリのデモンストレーション。

WIN_20180602_14_26_29_Pro

アプリはPowerAppsで、データはAzure Blob Storage、Common Data Service、実際の処理はMicrosoft Flowで実現します。
FaceAPI周りの処理でややコード記述が必要ですが、吉田さんの場合1時間ほどで完成するとか。
(うーん、私だと3日はかかるなこりゃ・・・)

WIN_20180602_14_28_45_Pro

これまで多くの人工(にんく)を集めて開発していたアプリケーションを、APIやWebサービス、データストレージの組み合わせで短期間で作れてしまう、ニーズに即応できる環境が驚くほど安価に手に入るんですね。

この事実、なかなかまだエンジニア以外に知られていないのではないかと思います。むしろ非エンジニアに利用してほしいんですが。

今後も要注目なサービス群です!

Common Data Services for Analytics

WIN_20180602_14_41_09_Pro

自分の期待も入れてまとめると・・・「データ分析を驚くほど容易にしてくれるツールとしての機能を含むCDS」というお話だったかと思います。
(思います?!ついていけてないのかよw)

ここでもデモがありましたが、残念ながら実際にリアルタイムで動くデモはタイミングが悪くご用意できなかった様子。スクショで利用方法についてのデモが行われました。

DynamicsやSalesforceといった元々は全く異なるスキーマ、環境にお置かれていたデータが、CDSの共通のスキーマに取り込まれるため、違うデータソースでも統一したビジュアルでのデータの可視化が可能になる。

これはすごいな~。

さらにPowerBi Insights Appsは、その技術を応用してPowerBIを利用した際に、驚くほど容易にデータ分析をしてくれるコンポーネント?サービス?ツール?
データアナリストがいなくても、先に挙げたような一般的なWebサービスであれば自動的に最適なデータを視覚化してくれるというシロモノ。
どんどん便利になりますね。

結構吉田さんが飛ばして説明されたため、ベースとなるテクノロジに対する私の理解が追いついていないところもありうまくまとめきれていません!ゴメンナサイ!
是非是非会場に足を運んでいただいて、直接質問攻めにして差し上げてください!

総合的に、私がいつも口酸っぱくして言う、ユーザー企業でもちょっと(だいぶ)頑張れば、アプリ構築やデータ分析ができてしまうので、ぜひやりましょうと。
毎度SIerやベンダーに高いお金を払ってシステム構築したりしなくてもよくなる世界がどんどん近づいているということですね。

やっと時代が私に追い付いてきた!!!!(ゴメンナサイもう言いません)

「Power BI社内導入まで ~Dynamics NAVと連携~」

クララオンライン/内田さんのセッション

WIN_20180602_15_40_06_Pro

個人的にとても好きなジャンルのセッション。
勉強会って最新の事例やテクノロジー紹介が多いんですが、実は参加者の方も多く求めているんじゃないかと思うのが「事例紹介」なんですよね。

WIN_20180602_15_40_23_Pro

実際営業なんかでお客様先に訪れても、「できることの説明」するよりも「実際あった例」を説明する方がずっと理解が早かったり、求められたりします。(その例が紹介先にハマればなんですが。)

今回はクララオンラインさんへの導入事例をもとに、実際に行ったことなどを紹介されていました。

メインのデータ取得元は最近導入されたERPのDynamics NAV。
PowerBI導入のきっかけは、NAV導入で満足してしまって、データの活用/可視化ができていなかったこと。

また、導入しやすい価格体系やライセンス体系だったことも大きかったようです。

ただし簡単にはいかなかった模様。
(NAVがオンプレなので、クラウドからのデータ接続ができない!など)

WIN_20180602_15_48_15_Pro

それをDynamics NAVに用意されているODataでクリア。
PowerBIのOdataフィードを利用してNAVのデータを取得。
ところがデータ取得が遅い・・・300MBのデータ取得に2時間!

WIN_20180602_15_50_50_Pro

解決策として以下の対応を実施。
・並列読み込み
・セッション上限数の確認
・データのフィルタリング(Odataでのデータ取得時に)

取得速度の問題は概ね解決するもまだまだ効率化の観点で満足せず、次は共有と更新の自働化。
しかし自働化でも困難が。
そんな自働化で引っかかったところでPowrBI王子の救いの手が!

WIN_20180602_15_53_34_Pro

まさにドンピシャなコンテンツ。

WIN_20180602_15_55_19_Pro

事なきを得て、うまくPowerBIを利用したビジュアライズ化を達成できたようです。

導入の結果どうなったのか

・レポート作成や分析に時間がかかっていた
→PowerBIがやってくれる!データ分析に集中できる!
・情報共有ポータルを作成するのにコストがかかっていた
→誰でも便利なツールが作成できるようになった!
・Excelでの共有は、データの新規性、共通性に疑問
→データの一元性が保たれているので、心配無用!
・別の切り口でのデータ分析もしたいが、修正に手間
→PowerBIは自由度が高いため(簡単に変更できるので)
それぞれの部門・部署の自由な視点での分析ができるようになった!

導入のステップについては

ノリが合う人を集めて、勉強会を開催したそう。
ネガティブな人がいるとテンションが下がるので、極力集めないように!とのこと。わかります!

などなど、実際の導入にかかる不安やステップを実例に沿って紹介していただいていました。

個人的には導入の結果にある、高度なビジュアライズを容易にできるため、わざわざ作りこみにコストや時間をかけずにできるところかと思います。

やっと時代が私に追い付いてきた!!!!(ゴメンナサイもう言いません)

 

「グラフ構造のデータモデルをPower BIで可視化してみた」

CData Sotware Japan の桑島さんのセッション

WIN_20180602_16_04_41_Pro

WIN_20180602_16_04_47_Pro
タイトルと

WIN_20180602_16_06_49_Pro
アジェンダ。

まずはグラフ(Graph)とは?ってところから。

WIN_20180602_16_07_49_Pro

日本でなんとなく「グラフ型」がわかりにくいのは解釈が違うからだ!と、モヤついていた方にはありがたい資料。

WIN_20180602_16_09_27_Pro

この図がグラフ型を表すのもっとも最適なもの。

WIN_20180602_16_11_21_Pro

ここでMicrosoftのGraph APIが登場。
これまではRDBでも実現できていると思うんですが、こういうRDBでも実現できそうな構造も、Graph型で再構成して効率化できるという好例なんでしょうか。まだまだ自分の勉強が足りないなぁ。

そして、実際にRDBをGraphっぽく表現する方向へ。

WIN_20180602_16_12_58_Pro

RDBでGraphを表すw
これはすごい・・・想像はするけど実際はやろうと思えないです・・・暇なんですか?(誉め言葉)
さらには、Graph向けのクエリーをRDBのクエリーに置き換えて表現。
これは、Graph型がなぜ今必要とされているか再認識させられる、とても価値のあるアプローチだと思います。ただただ関心。

ここまでが序章。

ここから実際にツール、データ、サービスのリレーションをPowerBIで表現するために調整していきます。

WIN_20180602_16_20_30_Pro

紆余曲折を経て、こんなモデルに!
(経過を見たい方は、是非勉強会にご参加を!)

グラフ型データモデルは新しめのデータモデルですが、これまで特にグラフ型が最適だと思われるようなデータの設計をしてこなかったので、深い理解を得られていなかったってのが正直なところです。

もしかしたらあったかもしれないけど気づけていなかった?

今回は、可視化のために利用するという観点からのお話の組み立ててで、技術紹介とはまた違う形でグラフ型データモデルを理解できたように思います。(そっちかよ)

ももももちろんPowerBIによる可視化についてもとても興味深い内容でしたよ!

というのも、可視化するためのデータソースって基本的に行列で構成されたデータが基本なんですよね。

で、そもそもなんでそんなことを?(さっきの「暇なんですか?」の真意)と思ったら、なるほどCDataさんの接続できるサービスやデータを可視化したり、情報整理するのに必要なんですね!
それはモチベーション高いです。

今回技術的に一番腹落ちが良かったセッションでした。
あとで桑島さんに根掘り葉掘り聞いてみよう。

配布資料

さらにサンプルファイルも公開されています!

「ディスカッション」

Power BI 王子こと、清水優吾さんのセッション

WIN_20180602_17_06_55_Pro

WIN_20180602_17_11_07_Pro

勉強会ではあまり見かけないディスカッション形式!

WIN_20180602_17_07_11_Pro

まずは山手線から始まります。
どんな話かなーと思ったら、簡単なデータも見せ方次第でかっこよく見えるよ!というプレゼンテーション指南!確かに!

そこからは、質問者さんからの質問にPowerBI王子とかがたさん、山田さん、小林さんなどサポーターの方々で回答していくスタイルに。

なかなか質問も出にくい国内の勉強会としては珍しくみなさん活発に質問が飛び交い、大変興味深い内容でした。

個々の細かい内容は割愛しますが、実際の事例の紹介や、本来そこってこだわるべきじゃないよね?というようなアドバイス的なもの、普段のセッションではなかなか聞けない裏話もあり、これまた他のセッションに勝るとも劣らぬ良コンテンツでした。

これは会場に来ないと絶対に損!
なぜなら資料の共有がないから!

次回のPowerBI勉強会の申し込み開始時間は正座して待ちましょう。

LT

LTもなかなかに盛り上がりました。
以下の三名の方のLT。

佐々木さん

WIN_20180602_15_12_34_Pro

データの前処理について。
Excelでダメなデータをどう直し有効利用するかという非常に有益なLT。
神がかり的なExcel操作が印象的でした。

資料も公開されていますよ!

井谷さん

WIN_20180602_15_18_23_Pro WIN_20180602_15_18_34_Pro

可視化系は優秀なPowerBIに任せよう。
Google Data Studioの比較など。
ややデータソースの扱いでGoogleは不便らしい。
その点、PowerBIはデータソースの扱いでかなり使いやすいらしい。

データ共有だけでなくデータ探索でも使えるよ!

岩下さん

WIN_20180602_15_26_00_Pro

・PowerBIは非常に優れたツールだが、フォントサイズの限界がある!(40ポイント)
・では、そのフォントサイズの限界を超えるためにどうするのか
・カスタムビジュアルにInfographic Designerを利用する。
・Infographic Designerなら、限界を超えて、データの向こう側を見ることが可能に!

PowerBIのビジュアライズを強力に補完するお話でした。

さいごに

今回も刺激的な内容がたくさんで大変参考になる勉強会でした。

ただただPowerBIの勉強をするということだけではなく、セッションの構成方法や勉強会そのものをよりよくしていくための手法など、とても参考になりました。

次回の東京開催は未定ですが、名古屋での開催は7月にってことで予定されています。

「Power BI 勉強会@名古屋支部 #2」
https://powerbi.connpass.com/event/90323/

私もフォローしておりますので、名古屋の方はチェックしていてください!

おまけ

私がお手伝いするSharePointの勉強会、JPSPS SharePoint勉強会の第28回開催が来る6月9日(土)、13:00~名古屋/伏見のSCSK様であります。

「[名古屋]Japan SharePoint Group 勉強会 #28」
https://jpsps.doorkeeper.jp/events/74326

まだお席はありますので、名古屋方面の方、また名古屋方面に出張されるかた、ご参加お待ちしております!

新製品開発のご案内~花粉症対策用鼻腔装具「FABLE」~

blog_top

毎年4月1日に精力的に新しい製品を限定的に世に送り出しておりますが、今年2018年4月1日も、めでたく新製品の発表にこぎつけることができましたことをうれしく思います。

一点昨年までと異なりますのは、これまでのような個人ではなく「オモシロインク」という屋号を背負っての発表となったことであります。(今日現在はひーたんの屋号ではありますが)

今後とも末永くお付き合いのほど、よろしくお願いいたします。

なお、製品情報は以下の配布資料拝見いただきますようお願いいたします。

FABLE

Wio node + Azure Logic Appsでお手軽IoT【Wio node初期設定編】

こんにちわ。

先日とうとうインフルBを被弾してしまい、一週間ほど臥せっておりました。この季節ホントいろいろ萎えます。早く夏来ないかな。

さて、そんな冬に差し掛かる昨年秋のころ、SeeedさんからWio LTEという面白いプロダクトのハンズオンが企画され一瞬沸き立ったのですが、その時はそれほどLTEの必要性もなく、またLTEモジュール搭載のせいもあってかややお高めの値段設定もあってスルーしておりました。

が、実はその裏に自分にとってとても要件にフィットしやすいデバイスがすでにラインナップあったことを先日のHack-Chu2018の際に知りました。それがWio node。
巷ではすでに試してみた記事がたくさんあり、ネタ的には今更感がありますが、個人的にちょうどWio nodeの仕様にピタリくる要件があり、あーこれは一度試してみないと!

ってことで試してみました。

Azure 各種サービスとWio nodeでPCを物理制御したい

今回は明確に用途が決まっており、事務所に設置してある特殊用途PC(謎)の・・・

  • 状態監視
  • インターネット経由の電源制御

が目的です。
このPCが結構めんどくさくて、常時動いていてほしいんだけどそこそこの負荷で動いているので時々困ったことにハングアップするという曲者。
ハングアップ状態を検知したうえで、リモート(TeamViewerなりリモデ)での復旧が困難と判断されたときに、電源を強制遮断し再起動するという荒業を担ってもらいます。

構成図はこんな感じ。

matome

AzureのLogicAppsを中心に、いろいろと都合のいいサービスにつなげている状態です。
通常自分が見るUIは、監視用にPowerBIのリポート、緊急時に通知が来たBot経由で電源制御を行うといった感じです。

まずは図の緑枠のWio node単体の動作テストまで。
最終的には、温度センサーからの取得データをAzure上に蓄積し、さらには電源制御をBot経由で実装する予定です。

ということでとにもかくにも物がなけりゃってことで注文しました。今回はマルツオンライン。

https://www.marutsu.co.jp/

で、届いたのがこちら。

IMG_20180302_195911166_HDR

Wio node二つに、温度計測用のセンサーが二つ、電源制御用のリレーが二つです。制御したいPCは3台あるのですが、とりあえず2台でテスト運用してみることに。

Wio nodeの設定

まずはWio nodeをWeb APIから操作するための設定を行います。

これが結構ハマったなぁ・・・

流れはこんな感じ

  1. Wio nodeに電源投入
  2. スイッチ長押しして設定モードに突入
  3. 設定用アプリを立ち上げ設定開始(iOSまたはAndroid)
  4. 設定完了したらREST API叩いてテスト

これだけのはずが・・・当初自宅のWi-fiのセキュリティ設定のまずさもあって苦戦。結局Android版ではNGのまま、iOS版で設定完了。以下その手順

まずはWio nodeに電源投入。
電源用のカプラを用いるか、MicroUSBにモバイル電源を用意する。電源用のカプラに二次電池を搭載した場合、このMicroUSB端子からの充電にも対応する模様。おもしろい。

IMG_20180303_162638742_HDR

Android版設定手順(結局設定完了せず)

Google Playで「Wio link」で検索し、アプリをインストールします。

Screenshot_20180303-162721

上記ではすでに1デバイス登録されていますが、新規登録時は右肩の「+」をクリックします。

Screenshot_20180303-162725

導入するデバイスを選択します。
今回は当然「Wio node」。

Screenshot_20180303-162730

Android版はこのまま「Next」をクリック

Screenshot_20180303-162745

Wio nodeに接続するWi-fiを選択します。

Screenshot_20180303-162750

選択したWi-fiのパスワードを入力します。
(※なぜかこのwi-fiパスワードがうまく通らない瞬間もあった)

Screenshot_20180303-162755

Wi-fi接続が完了すると、該当するWio nodeが表示されるので、クリック。

Screenshot_20180303-162802

AndroidからWio nodeへファームの更新処理が渡されている(と思われる)

Screenshot_20180303-162818

同様にWi-fiのパスワードが渡される(と思われる)
この後、ここまで緩い点滅だった青LEDがはっきりとした短滅に代わるため、Wio node内部ではセットアップができているのではと思われる。
あとはパスワード設定したWi-fi経由でAndroid↔Wio node間で通信が成立すればセットアップ終了と思われるのだが…

Screenshot_20180303-162832

残念ながら何度やってもここで終了。

この時点でコマンドラインツールの存在を知るも、一旦手持ちのiOS機でテストすることを思い立ちiOSで設定実施。

iOS版設定手順(正常に設定完了)

 

 

 

IMG_0678

Android同様右上の「+」から設定開始。

IMG_0679

同じようにWio nodeを選択し

IMG_0680

ただしここでiOS版はちょっと動きが異なる。
Android版は上位接続用のwi-fiの設定が求められるが、まずWio nodeへの接続が必要になる。

しかも、画面の「Goto wifi list」を押しても無情に
「手動でiOSとWi-fi接続してくれ」とダイアログが出るだけ。
仕方がないので、iOSのWi-fi設定からWio nodeを探し出して接続する。

IMG_0682

接続後設定画面に戻って再度「Goto wifi list」をタップすると画面が切り替わり、ようやくWi-fiの接続リストが表示される。

IMG_0683

該当のwi-fiをタップし

IMG_0684

パスワードを入力し「Join」をタップ。

IMG_0685

するとAndroid版と同じようにWio nodeに接続しセットアップを開始するのだが・・・・

IMG_0686

あっけなく設定が完了する。
この時の青LEDの動きはAndroid版と同じなので、検証は必要だがAndroid版の場合、セットアップ後のキャッチアップがうまくいっていないのでは?と思われる。

IMG_0687

すでに一つ目のセットアップが完了しているが、二つ目も無事登録された。(両方とも、Android版で設定→NG→iOS版で設定→OKという流れ。)

 

コマンドラインツール

上記のパターンでiOS版を用意できない場合は、コマンドラインツールも用意されている。

今回はテストしていないが、八方塞がった場合はお試しあれ。

https://github.com/Seeed-Studio/wio-cli

REST API

すでに長くなっているけど、ここからが本番。

Wio nodeの最大の便利ポイントが、Seeed社が運用するクラウドサーバ経由で、セットアップしたWio nodeの操作ができること。
しかもわかりやすいREST API経由。

自分のWio nodeデバイス固有のアクセストークンが含まれたURLを、各デバイスに用意された仕様に基づいて投げてやると・・・

Screenshot_20180303-231318

こいつの場合はリレーの制御。
ON=1なのでパラメタ設定して「POST」。

Screenshot_20180303-231332

ほどなくしてレスポンスあり。
例によってJSONなので、PG処理も簡単。

IMG_20180303_005602791_HDR

実際のHWの動き。
バッテリーに接続されたLEDが、リレーON(1)で点灯。
(基板上の小さなLEDもONしているのがわかる)

IMG_20180303_005616504_HDR

リレーOFF(0)を送ってやると、OFFになる。

ネット経由ということもあり若干の遅延はあるものの、数秒あるかないか。今回の用途では十分なレスポンス。

初期セットアップに手間取ったものの、そこから動作検証まではものの3分。これは便利。

次回は、温度センサーからの測定値をAzure経由で処理する。

追記

ということで、続編書きました。

https://shinya.nagoya/2018/08/30/wioazure002/

PowerBI 名古屋勉強会のご紹介と、名古屋のオープンデータを使った名古屋の紹介

こんにちは。
データ大好き榊原です。

先日こんなエントリーがありました。
「コンサルタントだった頃学んだ「議論がうまい人」とそうでない人の5つの差異」
(http://blog.tinect.jp/?p=45811)

この中で、「2.議論のうまい人は、「事実」からスタートする」
は非常に重要と考えておりまして、いろんな人と話をするときに結果を求めないただの雑談の中で「で、ソースは?」

とついつい口をはさみ嫌われるのが常態化しております。
2018年は寛容に生きたいと思います。

データ扱うならば、やはりその筋の方と相まみえないとということで今日はこちらに寄稿しております。
「Microsoft Power BI Advent Calendar 2017」
https://qiita.com/advent-calendar/2017/power-bi

名古屋でようやくPowerBI勉強会です!

永らく名古屋の勉強会の閑散さを嘆いておりますが、名古屋でやってほしい勉強会の一つ「PowerBI勉強会」をようやく名古屋でも開催できることになりました。

本家「Power BI 勉強会」
https://powerbi.connpass.com/

誘致に関して尽力いただいた名古屋主催:I社のY氏、本当にありがとうございます。

また、開催にあたりご快諾いただいた「PowerBI勉強会主催」のK氏、またS氏には厚く御礼申し上げます。

気になる開催日ですが、現在の予定では以下の通りです。

  • 日時:2018年2月10日(土)13:00~17:00(時間は前後します)
  • 場所:名古屋駅付近

※正式な情報は追って上記勉強会サイトにて行います。

東京の開催では毎回多くの受講者を集め、前回の第6回では105名の定員に対して117名の応募という人気・白熱ぶりです。
https://powerbi.connpass.com/event/69605/

初の名古屋開催、名古屋ってどんなところ?

ということで、初の地方開催である名古屋はどんなところなのか、さっそくPowerBIを使ってビジュアライズしてみようと思います。

利用したのは名古屋市の提供するオープンデータ。
このデータから、名古屋についてみてみましょう。

おっと?一筋縄にはいかない?

市町村の提供するデータなので、フォーマットは整っているものとしてまずは何もせずに取り込んでみました。

取り込んだのはこちらの情報
「年齢別人口(全市・区別) 、人口ピラミッド」
(http://www.city.nagoya.jp/shisei/category/67-5-5-7-0-0-0-0-0-0.html)

うーんむ・・・
全然だめですね・・・(ある程度は予測済み)
PowerBIでビジュアライズするにあたり、前段階としてデータを整頓するという作業がどうしても必要になってきます。
今回はそこのところを対応しつつ、名古屋の紹介をしたいと思います。

PowerBIで利用するための元データの修正

元データをExcelで開くとこんな感じです。
image
結果から言うと、以下の編集を施しました。

  1. 不要な見出し列(1~2行目)の削除
    →正しく列情報が取得できない
  2. 西暦のフォーマット変更
    →シリアル値を正確に取得してくれない
  3. 一部年度データの削除
    →取得範囲が異なり正規化できない
  4. 軸ラベルの付与
    →軸を基準としたソートができない
「1.不要な見出し列の削除」

取り込むデータはこんな感じになっており、データの注釈が1~2行目に記載されています。
これはPowerBIに取り込む際に邪魔になるので、削除します。

2017-12-26_06h14_18
列情報が正しく取り込めない


元データを削除する。

「2.西暦のフォーマット変更」

部分的に正しくシリアル値に変換してくれていましたが、そもそも年度別でフォーマットそのものが異なる箇所があったので、置換しました。

2017-12-26_06h19_27
「-」を「/」に置換し、フォーマットを統一しました。

「3.一部年度データの削除」

年度により、年齢分布の丸め方が異なっていたので、2004年以前のデータ、それから2017年も10、11月のデータを削除しました。
こういったところからも長寿化の傾向が見られますね。
2017-12-26_04h54_59

2017年10月から分類が増えてる!!!

「4.軸ラベルの付与」

グラフの軸にしたいデータが正規化されたデータではなく、年齢ごとの分類情報なので、そのまま取り込んだだけではきれいにソートしてくれません。いろいろ試してはみたのですが元データのままではうまくソートができなかったため、やむなくラベルにNoを振ることになりました。(なんかいい方法ないですかね?)

2017-12-26_06h27_32
頭の数値でソートされるため・・・
0~
10~
15~
20~
100~
105~
というような、よくあるダメなソート状態になってしまう。

2017-12-26_04h59_51
PowerBIに落とすとこんな感じに・・・こりゃあかん。

ということで、やむなく01~項番を振ります。
2017-12-26_06h33_18

これでこうなります。

2017-12-26_05h06_32
それっぽくなりました。
(さらに元データから総数をフィルタし、2017年9月でフィルタした後、階層別の降順でソートしています)

やっとで名古屋の紹介

ということで出来上がったのがこちら。

2017-12-26_05h13_13

男女別に見た年齢別人口構成比と、男女別人口比、年度別の人口推移を表示しています。

年齢別の構成比からは戦前~戦中世代の男女構成比に偏りがあるなーとか、ベビーブーマー強ェ!とかわかると思います。

私が興味深かったのは、年配で男女構成比がずいぶん偏っているにもかかわらず、2017年9月の男女構成比がほぼ50:50になっているところ。
やはりなんらか自然の力が働いていいるんでしょうか。

今回は紙面の都合上ここまでですが、機会があれば、この身近な名古屋のオープンデータを使ってPowerBIの勉強ができたらと思います。

今回の場合は、データの整頓に30分ほど苦戦した後うまく取り込めたら、グラフの表示部分についてはほんの数秒でできてしまっています。
ご存知の通り、この辺のビジュアライズ化の容易さががPowerBIのとてもいいところなんですが、元データがしっかり成形されていればいけないよ・・・というお話でした。

それでは、名古屋のPowerBI勉強会でお会いできること楽しみにしております!

Google Homeから適当にしゃべってLUISに自然言語処理させ、カレンダーに予定を登録させるというお話(其の一)

しばらくぶりのブログでございます。

ネタはいろいろあるんですが、ついついクオリティにこだわりすぎるあまりまとめきれず・・・

言い訳は見苦しいのでさっさと本題に参りましょう。

今回は、「Cogbot! – Cognitive Services, Bot Framework, Azure ML, Cognitive Toolkit(CNTK) Advent Calendar 2017」
のためのエントリーでございます。

https://qiita.com/advent-calendar/2017/cogbot

ということで、最近話題の機械学習についてのエントリー。
技術屋といいつつ全然技術屋らしくないことばっかり普段ボヤいているので、今回はちょっと頑張ろうかと思います。

最新のGoogle HomeとGAしたてのLUISで最先端!

今回の主役は「LUIS」。

正式には「Language Understanding Intelligent Service」といいます。
2017年12月13日にGAを迎えたばかりの、ホットなサービスですね。

何をしてくれるかというと、人間が投げかけた普段話している文章を、全体の文脈や文章の中に含まれている単語などから意味を理解し、理解した意味に沿って解析してくれるというものです。

(やってくれるのは文章の解析までで、その後何をするかはこちらで用意してやる必要があります。)

例えば・・・
明日の天気を知りたい場合、丁寧に言えば
「明日の名古屋の天気を教えてください」
でしょうが、実際に人との会話の中ではもっとフランクに

  • 「明日の天気教えて。名古屋の。」
  • 「明日の天気知ってる?」
  • 「明日天気どうかな」
  • 「明日名古屋晴れるかな」

といろいろです。

これまでのITサービスでは、このような自然な言葉の”揺らぎ”を吸収することができず決まった言葉でサービスに投げかける必要がありました。

それを解決し、自然な口語でコンピュータと対話できるようにする技術・自然言語処理が「LUIS」なのです。

今回は、このLUISを使って、もう一つ話題のGoogle homeから投げかけた言葉を解釈してカレンダーに予定を登録するという仕組みを作ってみたいと思います。

ここまで前置き。

LUISは人間とコンピュータの間の翻訳家みたいなもの

さて、全体の構成はこのようになります。

image

メインとなるLUIS以外にも様々な要素が絡んでますが、それを一つ一つ説明していると大変なので、本日は主にLUISの部分について解説していきます。

LUISは・・・

  1. 予定登録のためのいい加減な文章のテキストデータ(※インテント)を入力とし
  2. 予定登録のために必要な、日時や場所、予定の内容などの情報(※エンティティ)に分ける

ことをやってくれます。

※インテント 平たく言えば文章(特定の回答を持つ文章群)

  •  天気予報の回答を求める文章
  •  時刻の回答を求める文章
  •  ただの挨拶

※エンティティ 平たく言えば単語(特定の意味を持つ単語の集合)

  •  駅名(名古屋、大阪、東京、福岡、札幌)
  •  天気(晴れ、曇り、雨、雪、槍)
  •  時間の概念(今日、明日、何日、何時)

なので、LUISを利用する場合・・・

  • 自分が何を求めたいのか
  • ユーザーのどんな要望に回答させたいのか

を明確にすることが重要になります。

今回は「予定の登録」ということに的を絞っていますが、一般の人が想像するような賢いAI・・・
マルチなBOTを作ろうと思うと、無限のインテント登録とエンティティ登録が必要になります。
これはすごく大変。

自然言語処理の難易度をわかりやすいかどうかは別として例えてみると・・・

1.あいさつ・・・・容易

2.特定の回答・・・まぁまぁ容易
(天気予報とか、時刻の回答)

3.特定のジャンルのチャットボット(アニメで例えれば「四畳半神話大系」に関するBot)・・・やや困難
(ジャンルに関するインテントの準備とエンティティの準備がソコソコ多い)

4.広いジャンルのチャットボット(ガンダムに関するBot(作品は単発だが壮大なシリーズ構成))・・・かなり困難
(ジャンルに関するインテントの準備とエンティティの準備がかなり多い)

5.かなり広いジャンルのチャットボット(アニメ全般)・・・滅茶苦茶困難
(ジャンルに関するインテントの準備とエンティティの準備が半端なく多い)



100.人間のエミュレーション(無限大)

これを自動的にやる手法としては、昔よくあった人工無能のように、わからない質問に「それはなに?」と質問に質問で返して学習でしょうか。

今時な手法としては、不明な質問群を再帰的にAIに食わせて自己学習させていく感じでしょうか。夢は膨らみます。

ということなので、インテントとエンティティの材料集めの仕方や攻略アルゴリズムを得た人が勝ちということですね。

それをさらにAIに処理させることによって指数関数的に賢くなれるということになります。
もうこれは数多くこなしたほうがいいに決まっているので、やるなら早くやったほうがいいということです。

では予定登録のLUISを実装してみましょう

閑話休題。

では早速今回のケースを実装してみたいと思います。

LUISの基本的なサービス利用方法については、以下のブログがこんなブログより大変ためになるので是非参考にしてみてください。

LUIS 入門(Cognitive Services – 2017年12月版 – 1/2)
http://beachside.hatenablog.com/entry/2017/12/07/000000

LUIS 入門(Cognitive Services – 2017年12月版 – 2/2)
http://beachside.hatenablog.com/entry/2017/12/11/140000

お話は、LUISのサービス利用準備が整い、アプリを作る手前の画面から始まります・・・。

2017-12-23_00h38_45
「Create new app」をクリックし

2017-12-23_00h40_07
「Name」には任意のアプリ名を入力します。
「Culture」はかならず”Japanese”を選択しましょう。
「Description」はアプリに関する説明です。特に入力は不要です。
入力できたら「Done」をクリック。

2017-12-23_00h40_19
入力した通りのアプリが作成されたことを確認しましょう。

インテントの登録

2017-12-23_00h49_08
早速インテントを登録していきます。
エンティティから入力しても良いですが、まずは人間が発話する自然な文章を片っ端から入力していくのが良いのではないかと思います。
エンティティに引っ張られず、よい例文がたくさん並ぶと思います。

2017-12-23_01h02_30
こんな感じで、スケジュールの登録に必要な文章を入力していきます。
例文はちょっと整いすぎてますね・・・
もっと表現をバラしたほうが、最終的な学習精度が良いと思います。

この時点ですでに、名詞や助詞などに文章が区切られています。
単語の間に微妙にスペースがあるのが分かり、カーソルで単語にフォーカスすると単語ごとに[]で分割されていることが分かります。

エンティティの登録と関連付け

2017-12-23_01h04_20
続いてエンティティを登録します。
エンティティはエンティティの要素を一つ一つ登録してくのではなく、エンティティを包括する種類・カテゴリを登録します。

2017-12-23_01h04_35
例では「場所」のエンティティを登録しています。
これは、インテントの中にある「名古屋」や「半田」といった地名をまとめるエンティティです。

2017-12-23_01h07_22
同様に、スケジュールにおいてどんなことをするのかという「予定の内容」というエンティティを作成します。
今回のケースでは「打合せ」や「ミーティング」「出張」などがこれにあたります。
ちょっと例が悪く、このエンティティは相当な量を登録しないと精度が上がらなさそうですね・・・。

2017-12-23_01h09_19
さてここで一旦、インテントの中にある単語とエンティティをひもづけてみましょう。

文章の中にある地名に相当する単語をクリックすると単語の下に
「Browse prebuilt entities」
「予定の内容」
「場所」
と、登録したエンティティが表示されるので該当するエンティティをクリックして関連付けを行います。

2017-12-23_01h09_31
関連付けが終わると、エンティティ名に置き換わります。

2017-12-23_01h11_12
同様に「予定の内容」エンティティも関連付けます。

2017-12-23_01h13_37
エンティティに登録したい語句が複数の単語にまたがる場合、最初の単語をクリックした後登録したい単語までカーソルを移動し、末尾の単語でもう一度クリックすることで連続した単語でエンティティに登録することもできます。2017-12-23_01h13_51
出来上がりはこんな感じ。

が、これも非常に多くのパターンを登録しなければ精度は上がらないと思われます。
可能な限りエンティティは小さくまとめるようにしたほうが良いかと思います。

2017-12-23_01h16_20
ということで場所と予定の内容のエンティティの関連付けができました。

日付に関するエンティティの問題

肝心な日時が残っていますが、これが実はなかなか大変・・・。

LUISには、多くの方が利用するようなエンティティに関しては、学習済みの多くのプリセットエンティティが用意されており、日時についても相当するものがあります。

それが「Datetime」です。

2017-12-23_03h16_14

認識精度が高いことを期待して当初このPrebuiltエンティティを使っていたのですが、日本語で表現される日時のフォーマット(2018年1月22日15時など)はうまく認識してくれず、月だけエンティティ化されたり、時間だけエンティティ化されたりと最後まで癖がつかめませんでした
(諸先輩方、よい方法あったら教えてください)

故に最終的な結果もあまり芳しくない状態になってしまっています。無念。

2017-12-23_01h21_08
ということで、とりあえず日時の範囲だけでも正確に取得するために「日時」エンティティを作成し、関連付けしました。
このぼんやりとしたエンティティ・・・エンジニア的にはなんとも歯がゆいところであります・・・。
(推奨フォーマットはISO 8601 format)

インテントとエンティティの登録が終わったら学習させよう

2017-12-23_01h25_40
さて、インテントをいくつか(※)登録しエンティティとの関連付けが終わったら、登録したインテントをもとに学習させます。
画面右上の「Train](電車じゃない)をクリックします。

※長い文章、複雑な文章ほどインテントを多くしたほうが精度が上がります。

2017-12-23_01h26_04
学習が始まり・・・・

2017-12-23_01h26_11
学習が終了しました。

2017-12-23_01h26_24
では実際にきちんと認識してくれるか試してみましょう。
「Test」ボタンをクリックします。

2017-12-23_01h27_53
テスト用に文章を試すことができる入力フォームが現れるので、インテントを登録したように文章を入力してEnterキーを押します。
すると反転した文章が表示されます。
反転した文章の右下「Inspect」をクリックすると、入力したテストデータの解析結果を見ることができます。

今回は日時、場所、予定の内容について、日時のみ正確でした。
(個人的に内容は”パーティの打ち合わせ”まで認識してほしい・・・が登録インテント数が少ないので難しい)

2017-12-23_01h29_46
失敗した文章はインテントに登録し、エンティティの関連付けを行います。
これを繰り返して精度を上げていきます。
LUISはAPIも公開されているので、判定スコアの低い結果については自動的に学習用のインテントに取り込んで、管理者にエンティティ付けを行わせるようにすることで効率的に解釈の精度を上げていくことができるように思います。

2017-12-23_01h30_31
リトライ。正確に認識してくれました。
(インテントまんまだからそりゃそうでしょ・・・)

外部連携のためにアプリを公開

さて、ある程度学習とテストを繰り返したら、公開しましょう。
今回はこれだけでは終わりません。
入力はGoogle Homeからもらい、処理した後カレンダーの登録を終えなければいけないのですから!!!!

2017-12-23_01h31_18
画面右肩のタブ「PUBLISH」をクリックし、「Publish to production slot」をクリックします。

image
インテントの登録後学習が十分でないと、グレーアウトしてボタンが押せなくなっている場合がありますが、その場合は再度学習させましょう。

2017-12-23_01h31_30
公開プロセスが進み・・・

2017-12-23_01h31_33
公開プロセスが完了しました。

これで外部のサービスからも利用することができるようになりました。

2017-12-23_03h39_05
この時、後々サービス間での関連付けに必要になるKey情報をコピーしておきます。

2017-12-23_03h00_50_2
現在終わったのはこれだけ。
紙面の都合で、その他の部分は改めて別のエントリーとします。
(そもそもここまでの手順って、上述のブログであったような・・・orz)

Logic Appsで全体の処理の実装

さて、ではその他の仕組みと連携させましょう。
AzureのLogicAppsで全体を組み立てていきます。

2017-12-23_01h34_55
LogicAppsの手前、Google Homeから取得する、解析元になる文章は、WebHookでIFTTTから取得します。
そのあとの変数とか日時データの取得は苦し紛れの対応なので、とりあえず無視してください。
みなさんはもっとスマートな実装を目指しましょう。
(いい方法あったら教えてください)

2017-12-23_01h36_14
LUISの設定は、アクションの登録から「LUIS」で検索して「LUIS – Get prediction」を選択します。

2017-12-23_01h37_04
まずはどのLUISサービスに接続してアプリを利用するのか判別するために、先ほどコピーしておいたKey情報を「API Key」エリアに入力します。
「接続名」は任意の文字列でOK。
「作成」をクリックします。

2017-12-23_01h40_41
「LUIS – Get prediction」アクションが作成されると、また入力フォームが現れます。
「App Id」はクリックすると、Keyに紐づく先ほど作成したLUISアプリが表示されるので、選択するだけです。
「Utterance Text」は解析させたい文章・文字列なので、Webhookから送られてきた文章を指定します。
(本来はその他の処理も考えてJSONで送りたいところですが、今回は簡潔にするためプレーンテキストで送っているため本文をそのまま処理しています。)
「Desired Intent」は、処理させたいインテントを指定することができます。
前処理で確実に「予定の登録」インテントで処理することが分かっている場合はプルダウンから「予定の登録」を選択しても良いですが、通常はデフォルトの「Desired top scoring intent」が良いでしょう。

インテントが複数登録されていた場合、文章の解析中に判定されたスコア(最も適切なインテントである確率)が一番高いインテントが自動的に利用されます。

LUISの処理登録はこれだけです。

続いて、処理後の値をカレンダー登録させるための処理を設定します。

LUISで処理後は、以下のようなJSONが返っていています。

{“query”:”2018 年 1 月 22 日 16 時 名古屋 で 打ち合わせ”,”topScoringIntent”:{“intent”:”予定表の登録”,”score”:1.0},”intents”:[{“intent”:”予定表の登録”,”score”:1.0},{“intent”:”None”,”score”:0.008573224}],”entities”:[{“entity”:”2018 年 1 月 22 日 16 時”,”type”:”日時”,”startIndex”:0,”endIndex”:19,”score”:0.916193664},{“entity”:”名古屋”,”type”:”地名”,”startIndex”:21,”endIndex”:23,”score”:0.99994874},{“entity”:”打ち合わせ”,”type”:”予定の内容”,”startIndex”:27,”endIndex”:31,”score”:0.9998853}]}

2017-12-23_01h44_26
Logic Appsが解釈してオブジェクトごとに分けた結果

この中で必要なデータは、解析後のエンティティのカタマリなので、「Entities Array」を「For each」アクションでエンティティのアイテムごとに取得し、エンティティのtypeで判別してそれぞれ予め準備しておいた、エンティティに対応する変数へ格納します。
(もうちょっとスマートにならんかなコレ・・・)

2017-12-23_01h43_01

で、準備できたエンティティのデータをようやくカレンダーに登録します。

2017-12-23_01h44_43
が、ここで問題が・・・。
Google Homeからやってくる日付データはまんま日本語の文字列です。最近はある程度のフォーマットでまとまっている場合、うまいことパースしてくれるシステムもあるのですが、Logic Appsではそれがうまくできず、取得した日付データを用いてのカレンダ登録は断念しました。ぐぬぬぬ無念・・・

LUISを使うことが主テーマなので、自然言語処理で得られた日付のエンティティデータを後続処理でISO 8601規定に則ってフォーマットしてからGoogleのAPIに投げるなどしないといけないですね。

お恥ずかしながら、今回は現在時刻で「仮登録のスケジュール」として登録し、あとで予定表を手動で治すというクソオペレーションでお茶を濁すことと相成りました。
絶対直してやる。
(「終了時刻」と「開始時刻」の”デフォルト開”とか”デフォルト閉”は現在時刻の取得アクションから取得したデータを投げてるだけですスミマセン)

ということで、一通りの処理が作成できたのでテストです。
(例によって細かいチューニングはありますが・・・)

今回の動画で実際に取得したEntities Arrayのデータ。

Entities Array
[
{
“entity”: “2018 年 1 月 22 日 16 時”,
“type”: “日時”,
“startIndex”: 0,
“endIndex”: 19,
“score”: 0.916193664
},
{
“entity”: “名古屋”,
“type”: “地名”,
“startIndex”: 21,
“endIndex”: 23,
“score”: 0.99994874
},
{
“entity”: “打ち合わせ”,
“type”: “予定の内容”,
“startIndex”: 27,
“endIndex”: 31,
“score”: 0.9998853
}
]

で。登録された結果です。

2017-12-23_02h20_08

肝心の日付が・・・

さて、長くなりましたので、一旦本日はここでお開きといたします。

LUIS前後のLogic Appsの処理の解説や、日付処理のリベンジはまた改めてやりたいと思います。

長い時間お付き合いいただきありがとうございました。

 

【PC&Gadget】今週末は第26回SharePoint勉強会

de:codeの次のイベントはコレ!

今週末は、大阪にてJPSPS第26回SharePoint勉強会が開催されます。
日時 : 2017/5/27(土) 13:00~18:30(12:30から受付開始予定です。)
会場 : SCSK株式会社 様 北浜オフィス セミナールーム
大阪府大阪市中央区北浜1-8-16 13F
大阪証券取引所ビル

まだ若干席に余裕があるようなので、関西方面の方はぜひ!

お申込みはこちら

[大阪]Japan SharePoint Group 勉強会 #26
(https://jpsps.doorkeeper.jp/events/59733)
[大阪]Japan SharePoint Group 勉強会 #26

告知用チラシ

告知をお手伝いいただけるというご親切なお方はこちら是非ご利用いただき、社内などご掲示ください。
告知用チラシ(pdf版 JPSPS26大阪開催案内0518 )