Technote

by sizuhiko

初夏のJavaScript祭 in サーキュレーションビル ForPro で Polymer3.0 の LT をしました

5/19に開催されたJavaScript祭りに参加しました

今回もためになるセッションが多く、とても良いイベントでした。 いつもと同様にLT枠へ申し込み、この半年でおきたPolymerのアップデートを発表しました。

通常のセッションで 実践ES Modules というのがあったのですが、予想外に Web Components の話をたくさんしてもらえたので、LTでは基本的な話には触れずにスムーズにできたのは助かりました。

今年もGoogle I/O 2018が終わった後(昨年もGoogle I/Oの直後)だったということもあり、その発表をふまえた内容にできました。 Polymerとはどうなるのか?Polymer3.0はどういった課題を解決するのか?ということを中心に話しました。

Polymer はどこへ向かうのか、5/28 には Polymer.co-edo で、Google I/O の動画を見ながら語る会をやります(予定)ので、ぜひ参加ください!

会場の サーキュレーションビル ForPro は、BEAMS のオフィスを射抜きで使わせてもらったということで、オシャレ感が半端なかったのですが、 原宿駅からの移動が竹下通りを抜けていくので、ライフが半端なく削られました。 おっさんに原宿はつらい…

Polymer.co-edo day 2018 春 を開催しました

4月に予定していた今年4回目(通算で13回目)となるMeetupは、Polymer Japan主催の Web Components Cafe by Polymer Japan と重なってしまったため中止となり、このG/Wに Polymer.co-edo day 2018 春として開催することになりました。

Web Components Cafeでは「PolymerによるWeb Componentsの開発」というタイトルで発表もしましたので、スライドをリンクしておきますね。

Polymer.co-edo day って付くと、秋もやりそうじゃないですか!?(もしかしてやるかもね)

Polymer.co-edo day とは

私が1日 Co-Edoにいるので、Polymerのことについて話したり、質問受け付けたり、ワークショップやったり、一緒にお酒飲んだりw、Polymer/Web Componentsについて、何でもやるよ!の1日です。気軽に参加ください。

お好きな時間に来て、帰って も大丈夫です。 GW予定ないけど、もくもくしたい、Web Componentsさわってみたいなど、私と一緒に作業をしませんか?

ということで、連休にもかかわらず2名の方が参加してくれました。ありがたい!

非エンジニアの方ですが、コミュニティにもJOINしてもらった午前中の参加者と、Polymer.co-edoの常連さんが午後に来てくれて、ぼっちの時間も少なく楽しい1日でした。

やった/話した内容は以下のようなことです

  • Polymerとは?のプレゼン
  • どのように現在のビジネスにマッチさせるか
  • Wordpress の Polymer プラグインがあるらしい?!
  • どこから学んでいけば良いか?
    • Google Mapとか Codelabs にあるのが良いね!
  • Polymer 3がリリースされるってよ
  • CMS構想
  • 次回Polymer.co-edoはリリース記念イベント!?
    • Google I/O 終わったあとだし、動画見ながらのイベントになるかも
  • そろそろハンズオンやりたい(3系でやる?)

次回の Polymer.co-edo は

5/21(月)を予定しています。

Polymer 3のリリースはGoogle I/O の翌週と告知されているので、ナイスタイミングだと思っています。 みなさまの参加をお待ちしております。

明日の開発カンファレンス2018を開催します

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

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

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

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

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

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

2018年のみどころ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最後に

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

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

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

Polymer.co-edo meetup #12 を開催しました

今年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 などでのアナウンスをお待ちください。

Polymer.co-edo meetup #11 を開催しました

今年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 helpbower help などを実行して、コマンドが正常にインストールされているか確認しましょう。

自動テストのしくみ

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

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

テストスイートの書き方は、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つです。

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

  • 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-ifdom-repeat などデータバインディングの結果としてDOMの構造が書き換わる場合、変更は非同期で実行されるため、必ず flush が必要です。 私もプロダクション開発のテストコードでは、頻繁に flush を使うことがあります。

それ以外のテストのTIPS

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

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

FAQ

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

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

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

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

次回は

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

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

さいごに

写真忘れなかったw!

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