Technote

みなさんスマートホーム使っていますか？ これからはスマートホームの時代ですね（棒）

ということで、今日本では一番売れているというGoogleHomeのアプリを(Actions on Googleを使って)作ってみようと思うと以下の選択肢があります。

• Dialogflow
  • GUIから音声対話を構築してアシスタントアプリを作成する
• Smart home
  • IoT機器（家電）を操作するアシスタントアプリを作成する（昔の呼び名で言うところのダイレクトアクション）
• Actions SDK
  • SDKとコマンドラインを使ってアシスタントアプリを作成する
• Converse.AI
  • Dialogflowと似ているけど違うサービスでアシスタントアプリを作成する
• Trivia
  • トリビアアプリを作るためのテンプレート
• Personality Quiz
  • クイズアプリを作るためのテンプレート
• Flash Cards
  • アシスタントアプリ学習用のフラッシュカードテンプレート

まぁおおよそは、以下から選択するわけですが、違いがあります。

• Dialogflow（構文解析/機械学習機能がある）
• Actions SDK（構文解析などは自分でやる必要がある）

後者はガチで、前者は簡単にサービスを開始できます。 この記事は、前者のDialogflowについて書いていきます。

Dialogflow

もともとは Api.ai というサービスで Google が買収しました。

参考記事：Googleに買収された自然言語対話プラットフォーム「API.AI」が「Dialogflow」に名称変更！

GoogleHomeのアプリは以下のような流れで実行されます。

1. GoogleHome（マイク）
2. Googleアシスタント（音声→テキスト = Speach to Texxt = STT）
3. Dialogflow（構文解析/学習）
4. Webhook（必須ではないけど、独自のロジックを書くなら呼べる）

で、来た道を戻り、

1. WebhookまたはDialogflowからテキストを返却
2. Googleアシスタント（テキスト→音声 = Text to Speach = TTS）
3. GoogleHome（スピーカー）

で私たちは音声を聞くことができるのです。

Dialogflow単体でいうと、Googleアシスタントだけではなく、LINEやSlackのBOTも作れます。

※より詳しく何ができるのかは QiitaのDialogflowタグ記事一覧 を参照ください。

Dialogflow API

DialogflowにはAPIがあり、主な利用用途は以下のとおりです。

• GUIを使わずにCLIから操作できる
  • クライアントアプリを作る
  • アプリの設定を自動化する
• Webhookのインターフェース

現在の安定板はV1ですが、V2がbeta1として存在しています。

V1とV2の違いは公式サイトに書かれています。

また、DialogflowにはEnterprise Edition(現在はベータ版)というのがあって、商用アプリを作る人にはきになるところです。 Dialogflowの割り当てと制限を見るとわかるように、Standard Edition（無料版）には制限があります。 ただし制限だけに限っていうと、先ほどのV1とV2の違いページに書かれているのですが、

Note: These quotas are not applied to requests coming from Google Assistant integration used with Standard Edition agents.

Googleアシスタント経由で使っている分には、Standard Editionでも制限はないということです。

なぜV2を使うのか

たとえば以下のような作業はV1ではできません

• Dialogflowプロジェクト設定のimport/exportを自動化する（デプロイを自動化するのに必要）
• Enterprise Editionにとにかく加入して安心したい？（Enterprise Editionは V2 API が必須です）
• LINEやSlackのBOTを作りたいけど、制限を解除したい

また、DialogflowのWebhookアプリを作るのには、以下の2つから選択します。

• JSONを直接やりとりする
• Node.jsの公式ライブラリを使う

当然、後者の方が簡単にアプリを作成できるので、宗教上の理由でNode.js使いたくないという理由がなければ後者の方が良いですね。 ただしリンク先のGitHubみればわかりますが、現時点は

Please note that Dialogflow v2 is not currently supported by this client library.

ということです。

とりあえず作ってみた

いろいろなことがあって、現時点V2使わないといけないかもしれない。 でもV1にも簡単に戻れるようにしたい、みたいな「ふわっとした」状況ってあるじゃないですか。

Dialogflowのデプロイも自動化したいよね、とか。

ということで簡単に「お試し」できるように、リクエストとレスポンスのJSONをV2/V1変換するミドルウェアを作りました。 ミドルウェアにしたのは簡単に取り外せるようにするためです。

• NPM: dialogflow-fulfillment-v2-middleware
• GitHub: dialogflow-fulfillment-v2-middleware

V1のアプリは以下のようなコードになります。

const { DialogflowApp } = require('actions-on-google');
const welcome = require('./actions/welcome');

const actionMap = new Map();
actionMap.set('input.welcome', welcome);

const dialogflow = new DialogflowApp({request: req, response: res});
dialogflow.handleRequest(actionMap);

V2のアプリにしたい場合は、エントリポイントのJSだけを変更して、以下のようにすることを想定しています。

const { DialogflowApp } = require('actions-on-google');
const connect = require('connect');
const dialogflowV2 = require('./dialogflow-fulfillment-v2-middleware');
const welcome = require('./actions/welcome');

const actionMap = new Map();
actionMap.set('input.welcome', welcome);

const app = connect();
app.use(dialogflowV2.v2to1());
app.use((req, res) => {
  const dialogflow = new DialogflowApp({request: req, response: res});
  dialogflow.handleRequest(actionMap);
});

app(request, dialogflowV2.v1to2(response));

connectというミドルウェアレイヤーを使って、DialogflowのWebhookアプリでミドルウェアを使えるようにしています。 これはGoogle Cloud Functionsを使った場合の想定で、AWS Lambdaを使った場合は、expressとか使うと思うので、expressのミドルウェアとして差し込んでもらえれば大丈夫です。

• v2to1() V2リクエストをV1リクエストに変換するミドルウェア
• v1to2(response) V1レスポンスをV2レスポンスに変換するラッパー

2つのAPIがPublicになっています。

さいごに

JSONを変換するだけの簡単な実装ですが、手元のアプリではV2に切り替えてもうまく動作しました。

まだテストコードとかないので、Pull Requestお待ちしております（もちろんそのうち書く予定ですが…）。

うまく動作しない！などあれば、Issueで報告ください（日本語でOK）。

今年最初の Polymer.co-edo ミートアップ を開催しました。

今回の議題は

今月のテーマは、どうやって Web Components を作りはじめたら良いか？です。 自分たちが作ってみたい Web Components はあるものの、どうやって作り始めて良いかわからないといった悩みを解消できる会になれば良いと思っています。

ということで、まずは最近のPolymer/Web Componentsを取り巻く動向から解説しました。

• Custom Elements が HTML5.3に入る見込み
• Polymer で Custom Elements を作るとき、どのスタイル（バージョン）で記述するか

最近のPolymer/Web Components を取り巻く状況

まずHTML5.3に入るかどうかについては suikawiki - HTML 5.3 からリンクされている2つのissueに注目してみることができます。

• Custom Elements in DOM · Issue #14 · w3c/dom
• Incorporate Custom Elements in HTML directly? · Issue #955 · w3c/html

Web Components を支える技術（仕様）のうち HTML Import でなく Script Module になる Polymer 3.0 からは、3つ以上のブラウザーが実装を持っている状況になるので標準仕様の後押しになっていると考えられます。

Polymer での記述スタイルについては、先日Polymer公式ブログに掲載された The future of elements / What we’re doing with Polymer elements, what we aren’t doing, and why. が参考になります。

現時点で Polymer が提供しているコアエレメントのソースコードを見てみてください。ほとんどは Polymer 1 の形式（ES6クラスを利用しない）です。これは Polymer 2 でも利用可能なハイブリッド形式と呼ばれるものです。一方 Polymer 3 用には 3.0 preview のようなブランチが用意されていて、現時点 Polymer 3 preview 版はこちらを参照するようになっています。

例えば paper-input エレメントでは

• https://github.com/PolymerElements/paper-input はハイブリッド形式
• https://github.com/PolymerElements/paper-input/tree/3.0-preview は3.0形式

になっています。

上記ブログにも書かれているとおり、なぜ ES6 形式を提供しないのか？という問いに関しては

Polymerのユーザーに、Polymer 1.0からPolymer 2.0と3.0へのスムーズなアップグレードパスを提供する必要がありました。

と書かれています。これは互換性や移行可用性について、フレームワーク開発者がとても配慮してくれていることがわかります。

2.0のエレメントは、Polymer 1.0と2.0をブリッジする最小限の変更となるように設計されており、ユーザーがアプリケーションを簡単に2.0へアップグレードできるようにしました。 同じ理由から、3.0のエレメントは、既存エレメントを自動変換したES6モジュールで提供されます。 引き続き 2.xと3.xのエレメントはサポートされ、次世代のエレメントを計画しています。

3系の自動変換については、次のセクションでも詳しく書かれています。

エレメントのメンテナンスは、チームにとって重要な作業です。現行のエレメントはハイブリッド形式とし、Polymer modulizerを使用して3.x形式に自動変換することで、 単一のコードベースからPolymerの3つのバージョン(1.x, 2.x, 3.x)をサポートできます。これによりチームの時間を新しいエレメントの開発に割り当てることができます。

つまり私たちが Custom Elements を作るときも同様に、ハイブリッド形式で開発し、3.0へは modulizer を使って変換したコードを用意することでコードベースを1つに保つことができます。

私たちは何を作るのか？

Custom Elements の作成は旧来でいうと jQuery のプラグインや UI ウィジェットを作る作業に似ていると思います。 そこで今回参加したメンバーからは以下のようなアイデアが出ました

• 郵便番号から住所を検索する入力ボックス
  • これについては gold-zip-input というエレメントがありますが、 An input element that only allows US zip codes なのでそれの日本版になります
• 天気予報ウィジェット
  • これについても paper-weather というエレメントがありますが、マテリアルデザインでない Yahoo天気予報 みたいな見た目の天気予報が日本っぽいという意見がありました
• DatePicker
  • あるあるなんですが、なぜかどのプロジェクトでも作ってしまうエレメントがこれですね
• フォーマット表示
  • 日付／金額など日本でよく使う表示形式に対応したエレメントがあったら良いよね、という意見がありました。これも既存のエレメントにもありますが、より日本の開発者が使い易いスタイルだと良いよねという意見がありました

また Custom Elements は、エレメント名にプレフィックスが必要となります。これについては

• jp-
• coedo-
• edo-

みたいなアイデアが出ているので、実際のエレメントを作る段階で決めたいなと思っています。

How To

ちょっと時間がなくなってしまったので、簡単におさらいしました。

• GitHubにリポジトリを作る
• エレメントを作る
• webcomponents.org に登録する
  • 手順は Publish element を参考にする

次回は

2/26(月) の予定です。Doorkeeperのコミュニティページに今年の予定も書いてあるので参考にしてください。

今後は、実際に今回アイデア出ししたエレメントを作っていきたいと思います。 また Custom Elements を作るのに大事な

• 単体テスト
• デモページ

の作り方もワークショップ形式で進めていきたいと思うので、ぜひ参加ください。 新しいエレメントのアイデアも募集しています。

さいごに

写真撮り忘れたので、次回からは最初に撮ろう…

あと、コミュニティとイベントの拡散用に connpassのインベントページも作ったのですが、これがconnpassのイベントカレンダーや検索結果に出ないので、解決方法知っている人がいたら教えてください…

2017年は、ほとんどアウトプットできなかったので、2018年はBlog書くぞーと思っていたのに、もう23日です。どうも…

さて、皆さんは虹が好きですか？

• 雨が降っていたけど、晴れて虹が出ていた。キレイだねー
• ダブルレインボー珍しい
• ラルクの虹…

とか、まぁ良いイメージあるじゃないですか。 でも マッキントッシュ/Macintosh （通称 Mac）では 虹 は最悪なイメージです。 Windows をお使いの方だと 砂時計 なわけですが、それよりも 虹 になるときは邪悪で、ほぼフリーズに近いです。

またあいつがやってきた

当方は MacBook Pro(13-inch,2017)、機種IDでいうと MacBookPro14,1 を使っています。本記事執筆時点の最新版は MacBookPro14,2 です。

半年ぐらい前か、頻繁にMacがフリーズすることがあって、そのときは Docker for Mac が「応答なし」状況になっていたので、よく「Docker不安定だわー」とつぶやいていました。

そうしたら親切なフォロワーさんが「それ Docker for Mac Edge でしょ。安定板は大丈夫ですよ」と教えてくれたので、ここ最近はフリーズとはおさらばしていたのです。

しかし年が明けて、頻繁にフリーズするようになりました。 仕事にならん…

どうやって死んでいくか

何か操作（特に重いわけでもない）をやっていると、ファンがものすごい勢いで回り始めて、Macは熱くなり、なぜかネットワークインターフェースを使用するプログラム（ブラウザ、Twitterクライアント、Slack、Dockerなど）から「応答なし」になっていきます。次第にマウスポインターはレインボーになり、何も反応しなくなります….

このころ、1日に3回ぐらい、4日間連続ぐらいでフリーズしていたので、イライラMAXになっていました。

オマエか！？

アクティビティモニターを起動したかったのですが、WiFiタブがあるためなのか開けなくて、その状況でどのプロセスが悪さをしているのかわかりませんでした。 そこでずっとアクティビティモニターを起動しっぱなしにして、検証してみることにしました。

何回かのフリーズでは、うまく確認することができなくて「これMacの不良？」と思っていたのですが、ついに原因と思われる挙動を発見しました。

mdworker がCPUを独占している・・・・

そうそしてすぐググりましたよ（残念ながらMacはフリーズしていたので、Androidで）。 「Mac mdworker」みたいなキーワードで検索したところ Macが熱暴走するときの原因と対処法 というサイトが見つかりました。

原因は Spotlight ？

そういえば、よく熱暴走する前に npm install とか git clone/pull 、 composer install 、 docker build とか実行していたなぁと。新しいファイルが見つかると Spotlight がサーチを始めて悪さをするのでしょうか？

とりあえず Spotlight でドライブをサーチしないように Macintosh HD (SSDなのにHDとはコレいかに？みたいなツッコミどころですが…) を対象外に追加します。 私は Spotlight まったく使っていないので気になりません。

と、ここで Finder のサイドバーに Macintosh HD が表示されなかったので Macintosh HD(ハードディスク)をデスクトップ・Finderに表示する方法 macOS Sierra というサイトを参考に追加しました。

どうなったか

それから約1週間、ファンが回りまくることもなくなり、虹も見なくなりました。 作業自体は何も変わっていないので、効果があることは間違いないでしょう。

まぁ今までなんでならなくて、突然新しいMacでなるのかなぁ？ そして、なぜ WiFi に関するプロセスから「応答なし」になっていくのかは不明ですが、CPUとWiFiのチップが近くて熱暴走が伝搬する？とか思い、分解記事を読んでみました。

新型「MacBook Pro 13インチモデル」の分解・修理は極めて難しいことがiFixitの分解レポートで判明 で見ると、WiFiチップの位置は数字の3か4のキーの裏あたりでしょうか？USB-Cに近い位置です。 赤枠になっているCPUにすごい近いわけではないのですが（まぁ遠いわけでもないけど）。

ともかく 虹 が出なくなって、快適に開発を続けております。

最後に、今年はBlog書くよー

2017/7/15 に行われたPHPカンファレンス関西2017に参加してきました。

昨年に続いて参加

今年は場所がGRAND FRONT OSAKAという、梅田にできたすげービルのカンファレンス会場になっています。これは豪華！ しかもなんか最近どこもホテルが空いてなくて、仕方なく高いホテルへ、こちらもそれなりに豪華….（なんとかならんのか）

今年も上半期はとにかく忙しく、スライドやデモが直前の完成となってしまったため、新幹線の中とホテルでリハーサル。時間はだいぶヤバそう（なんといっても本当は1時間の内容なのだ）だが、どこの説明に時間がかかるかはわかったので、当日の雰囲気からスキップできそうだったら…という気持ちに。今年から使っているプレゼンポインターも不安の1つだ…

夜はスピーカーとスタッフの前夜祭から、コミュニティ前夜祭と合流しての2次会へと流れ、日付が変わった頃ホテルに戻りました。その後、3次会、4次会があったとかないとか…（これ去年のコピペのままですwww）

PHPカンファレンス関西2017

昨年同様3トラック+スポンサーブースで、会場はどこも広かったものの、人気コンテンツに集中するのは仕方がないですね…。それと朝一番の基調講演に参加者が多かったのもびっくりしました（割と東京のカンファレンスとか午後から来る人も多い）。 参加できたセッションは

• [基調講演] PHPの現場から
• PHPにおけるDSL
• Robo を使ったモダンなタスク管理（自分のセッションです）
• 現代におけるプロダクト開発とPHPを選定するワケ
• LT

昨年よりPHP成分多めな気がしました（私が見たところだけかもしれないですが…）

印象的だったことを振り返っておきます。

• 会場がすごい（かっこいい＆おしゃれ）
• いつもより初心者多め？（最初に質問なかったけど、雰囲気で）
• 若手が多い（昨年もおもったが）
• @shin1x1 の基調講演と、 @Potato4d のPHPを選定するワケが、現在のPHPを取り巻く環境についてズバリと攻めていて、すごいと思った

イベントの後は懇親会、二次会、三次会の順に巡りホテルに戻りました（去年のコピペで今年も同じw）。

Roboについて発表しました

なんかPHPの話したの久しぶりな気がします。

最近タイトルで釣らないことに決めているのと、裏のセッションが確実に人気セッションと予測できたのですが、やっぱりその通りとなりました…（気持ち的には残念）。

スライド見ても、お題しか書いてないので、見ても伝わらないと思いますので、トーク用のカンペから抜粋して解説します。

まずタスクランナーとは「タスクを定義し実行することをコンピューターに任せる」ということから自動化と強く関係しているので、最初に自動化やDevOpsの話をしました。 「参加者の中で何か1つでも自動化している人？」という問いに3割ぐらいしかいなかったのは、比較的想定の範囲です。なぜかというと、春先に開催した明日の開発カンファレンスのパネルで同じ質問をして、そのぐらいだったので…

今回は何から自動化するといいよ、という話はしませんでした（時間の余裕がない）が、とにかく静的解析だけでもやるといいですよ。Robo使うと楽になると思います。

で、Jenkinsは2.0からパイプラインでフローを書けるようになったので、実際にJenkinsfileでタスクは自動化できます。ただJenkinsfileは1つのタスクしか流せないし、うまくいかないときローカルで再実行してみようと思っても、そうはいきません。そこでCI環境でもローカルでも動かせるタスクランナーの出番があると思っています。

で、これまではどうしてきたか、というと Phing （セッション中ではファイングと言ってしまいましたが、フィングの方が正しいと思うので修正します）ですね。 でもXMLの定義は学習コストが高いし、仕組みも古いのでカスタムタスク作るのもつらいです。OSSで公開されているタスクとか、標準で用意されているタスクの多さは魅力の一つだとは思いますが。

で、現場ではPHP以外の言語で書かれたツールを使っているケースもあるんじゃないかと思います。特にNode.js系のツールは使われていることが多いかと。 もちろんPHPがバックエンドのAPIだけ（HTMLレンダリングしない）で、フロントエンド全部Node.jsみたいなケースはリポジトリも分かれているし、必要ないかもしれないです（後述のComposer Scriptだけで良い）。ただまだまだサーバサイドレンダリングのWebシステムはたくさんあります。そこで、そういったツールも同じ言語でやれたら良いよね、ということで、ComposerやRoboの出番だと思っています。

Composerは、もうデファクトと言ってもいいPHPのツールで、依存関係を管理するツールです。以下の代表的な特徴があります。

• コンポーネントをインストールする
• コンポーネントをソースコードから利用する：オートロード
• コンポーネントのバイナリーを実行する：スクリプト

Composerのスクリプトは、もちろんカスタムスクリプトをPHPクラスで定義できるのですが、本来は after install などのフックように考えられているので、タスクランナーとしてはちょっと足りません。

そこで、Roboと組み合わせてみましょうということです。

ここからはデモになります。リポジトリの README に詳しい説明が書いてあるので、そちらを見ながらコードを動かしてみてください。

PHPカンファレンス関西2017デモプログラム

裏話

セッションがちょうど30分かかって、質疑応答の時間作れなかったので、もくもくスペースに居るので、質問ある人は聞きに来てください、という Ask for Speaker にしてみたのですが、誰も来ませんでした（実は寂しかった）。 たまたまそのときLT（当日募集）と懇親会LTの内容が書き出されていて、懇親会LTが1枠空いている状況になってました（本編キャンセルで懇親会から1枠移動したため）。

で、それとは関係なく昨年の思い出と、以下の進捗を @tanakahisateru さんに報告していたら、懇親会LTやったら？みたいな話になり、やりました!

@sizuhiko 作ったらいいですか (お約束

— 田中ひさてる (@tanakahisateru) 2016年7月18日

スライドは勢いで5分ぐらいで作ったものなので、まぁ良いとして、実際に作ったものが以下になります。

https://github.com/polyester-cms/polyester

これはまだプロトタイプ版で、できも良くないのですが、今後ちゃんとした仕組みでやっていきたいと思っています。

大阪を堪能

最終日は恒例の ねぎ焼き やまもと へ。 今年も東京のPHPerを3人引き連れ、梅田エスト店にやってきました。 そのあと @hamaco とビール飲みに行って、聖地タイガースショップで買い物をして帰京しました。

さいごに

今年もPHPカンファレンス関西楽しかったし、たくさんの刺激をもらいました。ありがとうございました。

7/8と7/9に開催された IEEE Tokyo Young Professionals hackthon で CHIRIMEN コミュニティとして協力してきました。

CHIRIMEN コミュニティでは、このような活動に興味のある方の参加をお待ちしております！ チューターの方が事前講習会でやった内容を十分に把握していてくれたので、私たちはほとんど座っているだけでした。

2日間のtwitterまとめ

アイデアソンのやり方や、今の学生がどんなことを考えているかなど知れて、とても楽しかったです（日本酒も美味しかったなーw）