Technote

昨年に続き 明日の開発カンファレンス を1週間後の 4/17(火) に開催します。

明日の開発カンファレンスとは？

公式サイトの開催趣旨を引用します。

「明日の開発カンファレンス」では、開発の効率化に取り組むエキスパートの生の声を伝えます。そして、一歩、二歩、三歩先にどのような事ができるか、実際の現場にどのように導入するか。開発リーダのみなさまや開発リーダを目指すエンジニアのみなさまに、実現可能な情報を共有できる場を提供したいと考えています。

プログラムも、各分野に精通した運営メンバーが「今現場に求められているもの」の中で もっとも聞きたい話 を、各分野のエキスパートに登壇を快諾いただきました。 昨年に続き、参加したみなさまが 明日からのヒント を持ち帰って、現場の改善に役立つようなイベントになると信じています。

なお、名前が長いので、通称は アスカン という名前になっています。みなさまも愛着をもって「アスカン」と読んでもらえると嬉しいです。

2018年のみどころ

ものづくりを変える開発者ファーストの４つのカイゼン

デンソーさんのアジャイル開発事例は、今年のデブサミ2018や、他のイベント、Webの記事などで見たり聞いたりしたことがあるのではないかと思います。

ですが、ここはアスカンです。より現場の声が聞きたいんです。

そこで、今回は現場のチーフエンジニアである、佐藤 義永さんに登壇いただき 開発者の視点から具体的な取り組みとその効果 を紹介していだたけることになりました。 楽しみですね。

クラウド労務サービス「SmartHR」を支える開発チームの作り方

急成長中のクラウド労務サービス「SmartHR」。 プログラム選定をした神戸さん曰く まだ他で話を聞いたことがないが、絶対に話を聞きたい人 芹澤 雅人さんに登壇いただきます。

成長するサービスの中で、どのように対応してきたか、また、今後どのような開発チームを作っていきたいか について発表していただきます。 自社サービスを作っている人にとって、とても参考になる話、見逃せないですね。

新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた

フューチャー株式会社の齋場 俊太朗さんには、エンタープライズ開発の現場で 先進的なツール と 今までのやり方や文化 をうまく結びつけるために、どのような工夫をしたかを発表していただきます。 これから開発リーダーを目指すエンジニアがとおる現場の改善。 エンタープライズの現場の、こういった発表は他ではなかなか聞くことができない内容になっています。

カイゼン・ジャーニー 〜たった一人からはじめて、「越境」するチームをつくるまで〜

午後最初のセッションは カイゼン・ジャーニー の著者である 市谷 聡啓さん に、 どのようにして自分の場所（開発現場）を変えていくのか について発表していただきます。 会社のトップダウンでアジャイルを導入できるケース、スタートアップで改善を続けていけるケース、などありますが、 一人から 改善をはじめなくてはいけないケースが多いのではないか？と思っています。 このセッションのテーマは そう、変化は「たった一人から」でも始められます です。

こちらも、今年のデブサミ2018や他のイベントなどで、見たり聞いたりしたことがあるのではないかと思います。 アスカンでは他のイベントよりも発表時間をドーンと拡大して80分枠で、ジャーニーを語ってもらいます。

サーバーレスいいとこどり

サーバーレス という言葉で最初に思いつくことは何でしょうか？ 多くの現場で導入が進められていたり、導入が検討されているのではないかと思います。

AWSのコミュニティでは知らない人はいない、株式会社セクションナイン 吉田 真吾さん を中心に、 サーバーレスの現場で活躍する 中山 桂一さんと(サーバーレス薄い本でも有名な)仲山 昌宏さんに登壇いただき、 サーバーレスを現場に導入するにあたり直面する課題について、対策のアイデアや視座 を紹介していただきます。 ここだけの話が聴けるチャンスです！

リアルストーリー：「うちのカイハツ、セキュリティやばい」からの脱却シナリオ

最後のセッションは、セキュリティです。 OWASP Japanチャプターリーダーでもある岡田 良太郎さん、 サイボウズ株式会社 伊藤 彰嗣さん、 Vulsの開発者でもある神戸 康多さんが、 ゲストを迎えて 現場の生々しい話を根掘り葉掘り聞きまくる トークセッションです。 どうすればセキュア開発・運用など実現しうるのか について、アスカンでしか聞けない深イイ話、見逃せません。

最後に

もうすでに 119名(4/10 23:00現在) の方に申し込みをいただいていますが、まだ残席あります。 イベント後には懇親会 アスカンナイト も開催されますので、登壇者／参加者でイベントの感想や、明日からどうやっていくかを議論するのも良いと思います。

Peatixイベントサイト よりイベントチケットを購入できます。

アスカンまであと一週間。 よろしくお願いします。

今年3回目となる Polymer.co-edo ミートアップ を開催しました。

今回の議題は

日本発！？のWeb Componentsを作ろう！ということで、一度ブレストした内容を詰めていきたい

ということでPolymer.co-edo meetup ＃10 を開催しましたで、一度上がった案をベースに議論をしました。

本題の前に

ちょうど少し前、Polymerの公式ブログにPolymer 3.0: Latest previewという記事がアップされました。 こちらの記事は英語ですが、Chromeで開いて日本語に自動翻訳すれば、英語が苦手な方でも問題なく理解できるようになっていますので、ぜひご覧ください（最近の自動翻訳すごい！）。

ちょうど1つ前の記事が preview-12 では、こうなるよ、という話だったのを前回の #11 で話していたので「Polymer.co-edo の開催に合わせて記事がアップされるなんて、なんて親切なんだ」と勝手に妄想してますw

また、先日行われた templateinstantiationstudy のハイライトや感想も話しました。

Polymer.co-edo では何をやっていきたいか

ということで、本題に戻るのですが、始めて参加される方がいたので、コミュニティ/勉強会として何をやっていきたいか、というのをおさらい。

• 日本発の Web Components を開発/発信したい
• Web Components の開発フレームワークとして Polymer を推したい
• Polymer を学ぶ人が気軽に来て学習/相談できるコミュニティにしたい（ハンズオンするとかも）

Polymer で Web Components を作る意味として、個人的な想いを少し話しました。

Webサイトを作るとき、昔からフレームワークやライブラリは、どんどん変わってきました。 その中でライブラリの中心にいたのが jQuery だと思っています。もちろん今でも使われているし、 サイトに簡単な部品を設置するには jQuery だったり、それをベースとした Bootstrap ライブラリを使ったりします。 しかし、それらはモバイル端末で見ると十分なパフォーマンスを得られなかったり、他のフレームワークと衝突してしまう、といったことがおきたりします。

Web Components は、ブラウザの低レベルのAPIを使うことで、フレームワークを超えて部品を共通化することが可能だと思っています。 もちろん部品を組み合わせることでアプリケーションになることも可能です。 今日 Shadow DOMなどのWeb Componentsの要素単位で見れば、主要フレームワークで利用可能な（標準サポートされている）ものもあります。 ですので、そこでPolymerがという話ではなく、同じ会社でもプロジェクトによっては使うフレームワークが違っていたりすることはあるし、 OSSでUI部品を公開するとき多くの人に使ってもらうには、特定のフレームワークに依存した形でなく webcomponents.org で共有するエコシステムみたいなのができたら良いなと思っています。

このような視点で考えると、作るもののアイデアが jQueryやBootstrap であったものを置き換えたり、どこかのサイトで表示されているものを模したものだったりするなぁというのは、自然な流れに感じています。

#10で出たアイデアのおさらいと、新しいタグのブレスト

#10 で出たアイデア以外に何かないか、新しい人も来ていたので、もう一度ブレストしました。 まずあたりをつけたのが、日本のサービスでAPIを公開しているところはないか？それを使ってタグが作れないか？というところです。

そうすると意外とAPIって開いてなかったり、開いていてもサイト上で使うものだったりして、利用規約が Web Components に向いていない（サイトにバナーなどを埋め込んでくださいなど）ことがありました。 こういった利用規約は、Web Components 自体に入ってなくても良いような気がしますが、カスタムタグを利用する人に、どうやって守ってもらうかとか難しいなぁと。

で、LINEの共有ボタンとかないねーとか、有り体な話題で終わるかと思っていたころ、1つの発想転換がありました。

今回採用した新しいアイデア

埋め込みタグ です。昔 jQuery とかでリンクにホバーすると、サイトの概要がポップアップされるようなものがあったのは覚えています。 また、hatena とか使うとき、他の hatena 記事へリンクを貼ると、埋め込みタグ表示にできたりするじゃないですか。 埋め込みタグがあるサービス、例えばTwitterやSlide系のサイトは良いのですが、自分のブログなどに埋め込みタグがないサイトのリンクとして 埋め込みタグをつけれたら便利 というものです。

旅行に行ったブログを書くとき、レストラン行ったら食べログサイトの埋め込みタグを入れたいかもしれないし、ホテルや観光スポットの公式サイトの埋め込みタグを入れたいかもしれないです。 単なるリンクよりも良いですよね！

まずはじめにプロトタイプとしては、直接サイトのHTMLをもってきて meta タグの OGP を埋め込みタグ風に表示する（つまり自分のサイトに Facebook の共有表示を埋め込む感じ）のを目指します。 HTMLだけならテキストでそれほど容量もないし、画像ほど重くはないと思っていますが、サービスとして探して見たら意外となかったりしたので、OGP情報だけをキャッシュするサービスを併せて作っても良いかなーとも思っています。

これ自分のブログにも埋め込みたいし、早く使いたいですw

次回は

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

また、春と秋に1回ずつハンズオンもやりたいと思っています。 Doorkeeperのコミュニティページ のメールか、Facebookグループ Polymer Japan などでのアナウンスをお待ちください。

今年2回目となる Polymer.co-edo ミートアップ を開催しました。

今回の議題は

Web Componentsを作るにあたり、いくつか必要な開発ツールがあるので、その解説と体験がメインになります。

ということで、必要なツールと、その使い方／書き方について学習しました。

• polymer-cli の使い方
• polymer test を使ってみよう

開発環境をととのえる

ちょうど少し前にYouTubeのGoogle Chrome DevelopersチャンネルにBuilding an Element in Polymer 2という動画シリーズ1から5がアップされました。 こちらの動画は英語ですが、字幕をONにして日本語に自動翻訳すれば、英語が苦手な方でも問題なく理解できるようになっていますので、ぜひご覧ください。

今回はBuilding an Element in Polymer 2: Install Tools & Initialize Project (Part 1 of 5)が議題とマッチしていたので、一旦ビデオを見ならが進めました。

はじめに polymer-cli をインストールしましょう。

$ npm install -g polymer-cli

動画の中でも言っていますが、いろいろなものが入るので、結構時間がかかります。

次に bower をインストールします。

$ npm install -g bower

polymer help や bower help などを実行して、コマンドが正常にインストールされているか確認しましょう。

自動テストのしくみ

Polymer はテストコマンドとして polymer test を用意しています。 このコマンドは、polymer-cliのリポジトリでソースコードを読むとわかりますが、このコマンドはweb-component-testerへのエイリアスとなっています。

web-component-tester は Polymerチームによって開発されていますが、Polymer用というわけではなく、Web Components をテストするために既存のテスティングフレームワークを統合したものです。 READMEにも書いてあるとおり、フロントエンドやNode.jsでは馴染みのある、以下のようなツールを使って構成されています。

• Mocha as a test framework.
• Chai assertions.
• Async to keep your sanity.
• Lodash (3.0) to repeat fewer things.
• Sinon and sinon-chai to test just your things.
• test-fixture for easy fixture testing with <template> tags.
• accessibility-developer-tools through a11ySuite for simple, automated Accessibility testing.

テストスイートの書き方は、Mocha でテストを書いたことがあれば、それほど違和感はないと思います。 Web Components をテストするのに、追加されているのが test-fixture で、テストするエレメントのテンプレートを複数定義しておき、テストで必要な時だけDOMへ追加できます。

またWebサイトはアクセシビリティにも配慮すべきなので、a11ySuite で自動的に問題がないかどうかを検証できます。 参考サイト：Webアプリのアクセシビリティを追求せよ！「インクルーシブ」なマークアップを議論しながら学んでみた

web-component-tester はブラウザを起動してテストを行います。Web Componentsはブラウザの上で動作することを確認することが重要だからです。 しかし、さまざまなブラウザやOSのバージョンマトリクスを用意するのは困難です。 そこでSauce LabsのようなマルチOS/マルチブラウザで動作できるSaaSを利用するのが良いでしょう。 テスト困難はお金で解決できます。 web-component-testerでは、そのためのプラグインが標準で用意されているので、Sauce Labsならすぐに利用できます。 私はBrowserstackを使いたい！、という場合は、Browserstack用プラグインがOSSで公開されているので、試してみてください。

また、テストで起動するブラウザは、自動的に判定されるので、特定のブラウザだけ実行したい場合などは、wct.conf.json というファイルを作ってREADMEを参考に設定します。

もちろんCIでの実行にも配慮されていて、 Gulp や Grunt から実行するインターフェースも用意されています。

テストを実行してみる

実際にどうやってテストが実行されるのか、既存のエレメントで確認しました。 利用したエレメントは、以下の2つです。

• PolymerElements/paper-progress
• PolymerElements/gold-email-input

どちらも、以下の手順でテストを実行できます。

• git clone する
• clone 先にディレクトリを移動
• bower install を実行
• polymer test を実行

端末にインストールされているブラウザが自動的に起動して、テストが実行されます。 起動したブラウザは、2ペインになっていて、左側にテスト中のDOM、右側にはテスト結果が表示されます。

既存のエレメントから、基本的なテストの書き方を学ぼう

それぞれのリポジトリのテストコードを読んで、テストコードの書き方を学びます。

まず、どちらのリポジトリも、ルートディレクトリに test というディレクトリがあります。 web-component-testerはデフォルトで、このディレクトリ名を利用するので、よほどのことがない限りこの名前を利用します。

次に test ディレクトリには index.html と、それ以外のテストファイル（複数でも、サブディレクトリでも）を配置します。 まず index.html が読み込まれるので、テストスイートを初期化します。 ほとんどの Web Components で書き方はコピペで良く、変更が必要なのは title タグと、以下のテストスイートに列挙するファイルの一覧だけです。

    WCT.loadSuites([
      'basic.html',
      'basic.html?dom=shadow'
    ]);

重要なこととして、web-component-testerは、デフォルトでは Shadow DOM をOFFにしてテストを実行します。つまり 1行目の basic.html は Shady DOM でテストが実行されます。 もし、Shadow DOM でもテストしたい場合は、2行目のようにパラメータを追加する必要があります。

テストヘルパーの役割

実際のテストコードを見ると、以下のようなテストヘルパーをインクルードしています。

<script src="../../iron-test-helpers/test-helpers.js"></script>
<script src="../../iron-test-helpers/mock-interactions.js"></script>

テストヘルパーを導入すると、テストコードを書くのが容易になります。 代表的なヘルパーメソッドを紹介します。

• flushAsynchronousOperations : Custom Elements のライフサイクルコールバックを強制的に実行します
• forceXIfStamp : dom-if を利用しているとき、データバインディングで変更された値の再描画を強制的に実行します。通常はライフサイクルコールバックに入り、非同期で書き換わります
• pressSpace : 指定したエレメント上でスペースキーが押されたことをエミュレーションします
• tap : 指定したエレメントでタップ操作をエミュレーションします

これらの操作は、ヘルパーなしに書くと冗長だったり、それだけで疲れてしまうものですが、ヘルパーを利用することでタグ本来の挙動を確認することに集中できます。

また、paper-progress のようにCSSアニメーションを利用する Web Components のテストでは、asyncPlatformFlush を使っています。 このメソッドは web-component-tester で定義されていますが、現時点では DEPRECATED なので、 flush を利用することが推奨されています。

flush は flushAsynchronousOperations と似ていますが、コールバックで呼び出されるか、同期実行になるかが異なります。 公式ドキュメントでは flush を利用するように書いているので、flushを使って書いた方が良いでしょう。 dom-if や dom-repeat などデータバインディングの結果としてDOMの構造が書き換わる場合、変更は非同期で実行されるため、必ず flush が必要です。 私もプロダクション開発のテストコードでは、頻繁に flush を使うことがあります。

それ以外のテストのTIPS

今回はこのあたりで終了時間が少なくなったので、公式ドキュメントで案内されているテストの書き方について、いくつか解説しました。

• エレメントのメソッドをスタブする方法
• エレメント自体をスタブする方法
• Ajaxのテスト方法

これらは実際にテストを書くと必要になるので、TIPSとしてリンクを残しておきます。

FAQ

サーバーサイド言語の単体テストは、メソッドを実行して戻り値などを検証するけど、Web Components はプロパティで値を指定して、描画後の状態を取得して検証するの？

基本的には、そのような解釈でも問題ないです。 ただし Web Components にはメソッドも定義できるので、こちらはサーバサイドのテストと同様に記述することも可能です（実際そういう需要があるかは別として）。

仮想環境を使っていると面倒

たしかに web-component-tester はブラウザを起動して Selenium(Web Driver)を使ってテストするので Vagrant や Virtualbox を使った開発環境ではやりずらいです。 なるべくホストOSの環境で開発するのがオススメです。

次回は

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

いよいよ、実際に今回アイデア出ししたエレメントを作っていきたいと思います。 今後もワークショップ形式で進めていきたいと思うので、ぜひ参加ください。 新しいエレメントのアイデアも募集しています。

さいごに

写真忘れなかったw！

ワークショップの解説をしている私と参加者、という雰囲気です。

Polymerで作ったWeb Componentで string 型以外の属性を使う場合のTIPSをいう記事をQiitaに投稿しました。

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

ということで、今日本では一番売れているという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）。