コンテンツへ移動

Pitalium ExplorerをDockerで動かす

先日Pitaliumがmavenに登録されたことで使い始める敷居がぐっと下がりました。そこで前回はPitaliumがMaven対応したのでDockerと組み合わせて使ってみる | hifive開発者ブログとして、PitaliumをDockerベースで試す方法を紹介しました。

Pitaliumの動作自体はDockerで完結しますが、その結果ファイルを確認するPitalium Explorerはこのままでは使えません。Pitalium ExplorerのためにJavaやTomcatをセットアップするのは面倒ははずです。そこでDockerを使ってPitalium Explorerを簡単に試せるようにしましょう。

Dockerfileについて

最初に答えを書いてしまうと次のようになります。

ベースになるのはlibrary/tomcat – Docker Hubです。公式イメージなので安心です。そしてDockerの中でPitaliumのZipファイルをダウンロードして展開、その中にあるPitalium Explorerのwarファイルを展開して設定ファイルを書き換えます。それをTomcatのwebappsフォルダに配置します。

ビルド

Dockerfileをダウンロードしたら、ビルドを実行します。

$ docker build . -t pitalium-explorer:latest

これで完了です。

使い方

Pitalimの結果ファイルがあるresultsフォルダと同じ階層に移動してDockerを実行します。

$ docker run -it --rm -p 8888:8080 -v $PWD/results:/usr/results pitalium-explorer

これで results フォルダがDockerコンテナの/usr/resultsに配置されます。このディレクトリはPitaliumの設定ファイルで指定しています。

Webブラウザで http://localhost:8080 を開くとPitalium Explorerの画面が表示されるはずです。

Pitalium Explorer

結果の確認も特に問題なく行えるでしょう。

Pitalium Explorerの結果確認


Dockerを使っていますのでローカルの環境を汚すことなくセットアップが行えます。PitaliumをDockerで使う際には、ぜひこの方法でPitalium ExplorerもDocker化して使ってみてください!

Pitalium(hifiveリグレッションテストライブラリ) – hifive

Web Componentsを使いやすくするためのライブラリまとめ

まだ今ひとつ流行りきらないですが、Web Componentsは今後のWebにおいて広まっていく技術の一つです。コンポーネント化することで再利用性を高めるのはもちろん、各コンポーネントの独立性が高くなることでデザインの影響範囲を限定したり、公開されているWeb Componentsを利用しやすくなります。

今回はWeb Componentsを使いやすくするためのライブラリを紹介します。

Stencil

Stencil

StencilはIonicによって開発されています。TypeScriptとJSXを組み合わせているのが特徴になります。ブラウザはIE11からサポートしています。以下のようなTypeScriptを書きます。

import { Component, Prop } from '@stencil/core';

@Component({
  tag: 'my-first-component',
  styleUrl: 'my-first-component.scss'
})
export class MyComponent {

  // Indicate that name should be a public property on the component
  @Prop() name: string;

  render() {
    return (
      <p>
        My name is {this.name}
      </p>
    );
  }
}

そして利用する際のタグは以下のようになります。

<my-first-component name="Max"></my-first-component>

Stencil

MUI

MUI

Googleのマテリアルデザインガイドラインに沿ったCSSフレームワークです。React/Angular/Web Componentsに対応しています。例えばボタンは以下のようなタグになります。

<mui-btn color="primary">Button</mui-btn>

MUI – Material Design WebComponents Framework

Bosonic Web Component

Bosonic

ダイアログやドロップダウン、タブ、ツールチップなど様々なUIコンポーネントをWeb Componentsとして提供しています。実用性の高いコンポーネント集となっています。

Bosonic Web Component

Polymer Project

Polymer

Polymerを使うとShadow DOMやマテリアルデザインを使ったWeb Componentsを手軽に使えるようになります。 Polymer.Element を継承して作ることで、Web Componentsを用いた処理が書きやすくなるようです。

Welcome – Polymer Project

SkateJS

SkateJS

PreactやReact、LitHTMLなどと組み合わせて使えるライブラリになります。コード例は以下のようになります。

import { props, withComponent } from 'skatejs';
import withPreact from '@skatejs/renderer-preact';
import { h } from 'preact';

class WithPreact extends withComponent(withPreact()) {
  static get props() {
    return {
      name: props.string
    };
  }
  render({ name }) {
    return <span>Hello, {name}!</span>;
  }
}

customElements.define('with-preact', WithPreact);

skatejs/skatejs: SkateJS is a web component library designed to give you an augmentation of the web component specs focusing on a functional rendering pipeline, clean property / attribute semantics and a small footprint.

X-Tag

X-Tag

Microsoft社がサポートするWeb Componentsライブラリです。Web Components APIに準拠して使えます。タグをラッピングすることでイベントハンドリングやフラグメント作成なども行えるようになります。

X-Tag – Web Components


Web ComponentsはUIフレームワークでは使われ始めていますが、個々の部品というレベルにおいて提供されることは希なようです。使えるWebブラウザは広まっていますが、レガシーなブラウザへの対応で躊躇してしまうことが多いでしょう。そうした点において、Web Componentsライブラリを採用すれば、IE9あたりから対応できるようになります。

また、素のWeb Componentsでは良い書き方が分かりづらいかも知れません。ライブラリの提示する方法に則っておくことで利用しやすいWeb Compnentsが書けるようになるでしょう。

Webブラウザ上でディープラーニングを体験できるライブラリまとめ

ディープラーニングというと計算量が多く、GPUを使って動作するイメージがあります。WebブラウザにはWebGPLがあり、そこではGPUが使えます。それもあって、Webブラウザ上で使えるディープラーニングライブラリが増えてきました。今回はそれらをまとめて紹介します。

TensorFlow.js

Googleの開発するTensorFlowをWebブラウザ上で実行できるようにしたライブラリです。TensorFlowで作られたモデルを動かすこともできます。

TensorFlow.js

sukiyaki

東京大学内で開発されているディープラーニングライブラリです。サンプルとして手書き認識のデモが公開されています。

mil-tokyo/sukiyaki: Deep Learning Library for JavaScript

Keras.js

KerasのモデルをWebブラウザ上で動かせるようにしたライブラリです。

Keras.js – Run Keras models in the browser

Synaptic

SynapticはJavaScript向けのディープラーニングライブラリで、Node.jsで学習させてWebブラウザ上で利用すると言ったことができます。

cazala/synaptic: architecture-free neural network library for node.js and the browser

WebDNN

Tensorflow、Chainerなどに対応したディープラーニングライブラリです。Keras.jsよりも高速に動作するとしています。

MIL WebDNN

ml5js

TensorFlow.jsをラッピングして、より手軽に使いやすくしたライブラリです。芸術家や学生、クリエイティブな人たちを対象としており、プログラミング能力をそれほど必要とせずに使えるようです。

ml5js · Friendly Machine Learning For The Web.


Webブラウザ上で学習して実行するというのはあまり現実的ではないでしょう。TensorFlowなどであらかじめ学習しておき、そのモデルを利用するのが理想的です。モデルデータがあまり大きいのもまた現実的ではないので、リソースを使いすぎずに使える範囲での利用が求められるでしょう。

Angular/React/VueでのPWAの始め方

今回は有名どころのWebフロントエンドフレームワークにおけるPWAの導入方法です。結論から言えば、新規アプリであれば導入は難しくなさそうです。

Angular

Angular CLIを使うのが基本です。まずAngular CLIをインストールします。

ついでAngularアプリを作成します。

そして作成したAngularアプリの中で、 @angular/pwa を追加します。

これでPWA対応が完了します。なお、開発用サーバの時点ではmanifest.jsonは確認できません。 ng build でビルドする必要があります。

React

幾つかのテンプレートがPWAに対応しています。一番手軽なものとしては、 create-react-app コマンドによるものです。

これで使えるようになる create-react-app コマンドで作ったReactアプリはPWAに対応しています。

これでPWAが使えるReactアプリができあがっています。なお、yarn startyarn build のどちらでもmanifest.jsonが生成されています。

他にもpaulhoughton/react-pwapaulhoughton/preact-pwalocalnerve/react-pwa-referenceといったテンプレートが作られています。

Vue

VueはVue CLIを使ってアプリを作成することが多いでしょう。

まずプロジェクトを作成します。

プロジェクト内で vue add を実行します。

これでPWA対応が完了です。なお、Vueアプリの場合も開発サーバではmanifest.jsonが確認できません。ビルドした際だけ表示されます。


最近のWebフレームワークであれば、PWA対応はとても簡単になっています。バージョンが古いこともある既存のプロジェクトにおいては導入は難しそうですが、新規開発であればPWAの導入はさほど難しくないでしょう。

PWAにおけるキャッシュの更新方法

PWAで一番厄介な問題と言えばキャッシュではないでしょうか。開発中などで、キャッシュを更新したい時にできなかったり、キャッシュを読み込んでしまって修正が反映されずにバグ解決に時間を取られるかも知れません。

そこでちょっとしたTipsを紹介します。

Service Worker登録時の工夫

それは registration.onupdatefound を仕込んでおくということです。このメソッドはService Workerが更新されているかどうかを検知してくれます。もし更新されている場合は、updateメソッドを使って更新できます。

ボタンで更新する

キャッシュをクリアしたい時のためにボタンを用意しておきましょう。unregisterメソッドを使えば一旦Service Workerを解除してくれるので、再読み込みすれば改めて登録し直してくれます。

キャッシュされているスクリプトなどを更新する

Service Workerを使っている場合、JavaScriptやスタイルシートの変化を検知してアップデートする方法は恐らくなさそうです。何らかのアクションが必要になります。

例えばボタンを使う場合には以下のように、Service Worker側にメッセージを送ります。

そしてService Worker側でキャッシュを取得し直します。やっていることはインストール時と同じです。

これでキャッシュの読み込み直しが完了します。ボタンを押さなくとも強制的に取得し直すといった仕組みでも良いかと思いますが、特定のURL(コンテンツなど)に限ったり、Service Workerが更新された時に限ると言った工夫は必要でしょう。


キャッシュによって表示を高速化するService Workerですが、使い方を間違えるとユーザビリティが大きく損なわれる可能性があります。キャッシュすべきコンテンツとしない方が良いコンテンツを見極めて、上手に運用しましょう。

LighthouseでのPWAにおけるチェック項目について

サイトがPWAに正しく対応しているかどうか計測する際にはGoogle Chrome拡張のLighthouseを使うのが基本です。今回はProgressive Web App Checklistで提示されているPWAのチェックリストに沿って、どういった項目がチェックされているのかを紹介します。

HTTPSになっているか

WebサイトがHTTPSに対応しているか、さらにHTTPにアクセスした際にリダイレクトするかチェックします。

タブレットやスマートフォンに対してレスポンシブに対応しているか

スマートフォン向けにデザインを変えるのではなく、レスポンシブWebデザインであることが基本です。

アプリに関係するURLがすべてオフラインに対応しているか

トップページだけPWAといった状態ではなく、クリック先も含めてPWA対応しているかが問われます。

Add to Home Screenに対応したメタ情報が指定されているか

いわゆるmanifest.jsonに絡んだ話です。アプリ名やアイコンなどが指定されている必要があります。

3G環境でも10秒以内に表示されるか

遅いサイトはPWAとして不向きです。3G環境でもユーザにストレスを与えない速度での表示が求められます。

クロスブラウザで動作するか

Google Chromeだけでなく、Firefox/Safari/Edgeにも対応している必要があります。

ページ遷移がネットワークをブロックしていないか

ページ遷移時のアニメーションによって表示がもたつかないことを求められます。

すべてのページがURLを持っているか

URLがユニークになっており、そのURLにアクセスした際に適切な情報が表示されることが望まれます。

高度な制約

さらに細かく見ていきます。これらはLighthouseでチェックできないものもあります。

サイトがGoogleでインデックス化されているか

Googleのインデックス状況をチェックして、すべてのページが望ましくインデックス化されている必要があります。

Schema.orgで定義されているメタデータが設定されているか

インデックス化に関係しますが、必要なメタデータが設定されていなければなりません。

FacebookやTwitterなどのOpen Graphが設定されているか

シェアされる際に必要なOGPが設定されているか確認されます。

Canonical URLが設定されているか

pwaでは独自のクエリ、ハッシュタグを設定することがあります。そのためCanonical URLによってシェアするURLが指定されていることが望ましいです。

History APIを使っているか

ページ遷移に物理ボタンやキーボードショートカットでも対応するHistory APIが使われている必要があります。

ページ遷移が滑らかに行われているか

ページ読み込みが再度全コンテンツのレンダリングではなく、スムーズなアニメーションによって行われているのが望ましいです。

リストページから詳細ページに移動してバックボタンを押した時、リストを再現して表示されるか

History APIに関連しますが、リストの最上部に戻るのではなく、クリックした場所に戻ってくるのが望ましいです。

キーボードがテキスト入力欄を覆ってしまわないか

ソフトウェアキーボードを表示した際に入力欄を隠してしまわないように注意しましょう。

コンテンツが容易にシェアできるか

Web Share APIを使ったりして、コンテンツのシェアが手軽にできるのが望ましいです。

アプリのインストールプロンプトが過剰ではないか

PWAとしてアプリインストールは必要ですが、それが過剰になっているとユーザビリティが下がります。

キャッシュが使われてるか

Service Workerによるキャッシュを効率的に使って、高速な表示を実現します。

プッシュ通知の送る内容などをユーザに提示しているか

プッシュ通知はスマートフォンアプリと同様、否応なく表示されるべきではありません。

プッシュ通知の有効化を過度に求めていないか

こちらも上記と同様です。

プッシュ通知は関連性があり、タイムリーかつ正確なものになっているか

送る内容に関する注意喚起です。

プッシュ通知をオフにする方法を提供しているか

オフにする方法が提示されていないことが多く、ユーザを混乱させるでしょう。

Credential Management APIを提供しているか

認証のAPIです。

Payment Request APIを提供しているか

決済のAPIです。Eコマースなどでは必須でしょう。


ここに挙げたものはベースラインとなっています。プッシュ通知などは運用にまで踏み込んだ内容になっています。ぜひ全体をチェックリストとして、ユーザビリティの高いPWAを目指してください。

PWAの manifest.json で実現できること

PWA(Progressive Web App)では manifest.json というファイルが肝になります。このファイルの有無と Service Worker 、そして manifest.json の記述内容によってアプリとしてインストールできるようになります。

今回は manifest.json の中でも、ぜひ知っておきたい設定を紹介します。

テーマカラーが指定できる

アドレスバーの部分をブランドに合わせたカラーリングにできます。

metaタグで <meta name="theme-color" content="#317EFB"/> といった形で指定するか、 manifest.jsontheme_color を指定します。

最初に表示するURLを指定できる

manifest.json にて start_url として最初に表示するURLを指定できます。例えば index.html?pwa=true として、JavaScriptでパラメータを読み込むことで、PWA専用の画面構成に作り替えるといった操作もできます。

起動時のスプラッシュスクリーンが指定できる

manifest.json にて background_color を指定し、かつ 512x512pxのアイコン(PNG)を指定することで、起動時にスプラッシュスクリーンが表示できます。

ホーム画面にアイコンを設置できる

manifest.json の icons にて192x192pxのアイコンを用意するのがベストとされています。Webサイトをアプリのようにインストールすると、その際のアイコンとして使われます。

背景色が指定できる

manifest.json の background_color にてコンテンツが表示されるまでの背景色を指定できます。起動時にはスプラッシュスクリーンが表示され、その後最初の表示が行われるまでの画面遷移がスムーズになります。

アプリ名が決められる

manifest.json の name にてアプリとしてインストールされた際の名前を指定できます。なお、iOSでは名前はデフォルトであり、ユーザが変更できます。 name が長い場合には short_name を代替として利用します。

起動方法を指定できる

manifest.json の display にてアプリの立ち上げ方を決められます。 fullscreenstandalonebrowser の3パターンがあります。


manifest.json の設定によって、インストールされる際の細かな挙動を変更できます。よりアプリらしく、よりユーザビリティの高い仕組みを提供するためにカスタマイズしてください。