github private repository も無料で CI テストできるので[wercker](http://wercker.com/)を使うことが多いです。  
プロジェクト立ち上げ時に設定した後、安定すると放置になる設定周り。ついつい忘れてしまうので、自分用メモ。  
フロントエンドエンジニアでも CI テストできる最小構成です。



## ベースは Node 用の基本構成

まず、自動テストは Node.js で行うようにしていると思うので、Node 用の基本設定をベースにするのがいいと思います。

[wercker - docs - Nodejs](http://devcenter.wercker.com/docs/languages/nodejs.html)

```yml
box: nodesource/trusty
# Build definition
build:
  # The steps that will be executed on build
  steps:
    # A step that executes `npm install` command
    - npm-install
    # A step that executes `npm test` command
    - npm-test

    # A custom script step, name value is used in the UI
    # and the code value contains the command that get executed
    - script:
        name: echo nodejs information
        code: |
          echo "node version $(node -v) running"
          echo "npm version $(npm -v) running"
```

## Node バージョン指定

Node のバージョンを指定したい場合の設定方法。  
`box`で指定できます。Docker hub のコンテナを指定できるので、[Docker hub 上の Node の OFFICIAL REPOSITORY](https://hub.docker.com/_/node/)を指定しておきます。バージョン指定はよく間違えるのですが、`node:4.2.2`とします。`@`じゃないです。

```yml
box: node:4.2.2
```

## bower を使うには

フロント側のライブラリを bower から取得しているプロジェクトは、テストの前に`bower install`しておく必要があります。  
`build`フェーズにて bower をグローバルインストールして、`bower install`できるようにしておきます。permission で怒られるので`--allow-root`を忘れずに。  
(このあたりは独自で box 作成しておくと不要になりそうです。)

```yml
build:
  steps:
    #  npm install -g でbowerをインストールする
    - script:
      name: install npm -g
      code: sudo npm install -g grunt-cli bower

    # bower install
    - script:
      name: install bower
      code: bower install --allow-root
```

これで`package.json`の script の test にテスト用のコマンドが指定されている場合は`- npm-test`すれば OK です。

## おまけ

### CI テストはヘッドレスブラウザを使いましょう

ローカルは実ブラウザを使ったテストしている場合は、ヘッドレスブラウザを使いましょう。  
ヘッドレスブラウザは[PhantomJS](http://phantomjs.org/)が代表的です。だた、v1.0 系はモダンブラウザとの compatibility の問題があるため、v2.0 以降を使った方がいいです。

CI でも実ブラウザを使いたい場合は、wercker で頑張るより、お金を払って[Sauce Labs](https://saucelabs.com/)使った方がいいと思います。

### テスト結果を hipchat で通知する

テスト結果を hipchat などで通知したい場合は、`build`フェーズの`after-steps`で行います。  
hipchat の integration の例は公式サイトにあります。

[wercker - docs - Hipchat notifications](http://devcenter.wercker.com/docs/notifications/hipchat.html)

例）

```yml
build:
  # 省略。。。

  after-steps:
    - install-packages:
        packages: sudo gawk
    - hipchat-notify:
        token: $HIPCHAT_TOKEN
        room-id: $HIPCHAT_ROOM
        from-name: wercker
        on: failed
```

(※)`$HIPCHAT_TOKEN`と`$HIPCHAT_ROOM`は wecker で定義した環境変数です。

## まとめ

これで最低限の CI テストができるようになりました。  
初めてだと少し苦労する点があるので、まとめてみました。

### 実際の wercker.yml

`wercker.yml`はこちらに置いておきます。

https://gist.github.com/mitsuruog/ee724841d81c6ecab5e9

### 参考資料

もっと頑張りたい人向け。

- [Wercker の仕組み，独自の box と step のつくりかた | SOTA](http://deeeet.com/writing/2014/10/16/wercker/)
- [Github のプライベートリポジトリでも無料で使える CI、Wercker を使って rails new から Heroku のデプロイまでやってみる | mah365](http://blog.mah-lab.com/2014/01/08/rails-wercker-heroku-deploy/)

werckerでフロントエンドをCIテストする

一手間必要だったのでメモ。  
長いので Salesforce Lightning Design System(以下、SLDS)とします。



## 元ネタ

こちらの内容とほぼ一緒です。

Webpack config example · Issue #127 · salesforce-ux/design-system  
https://github.com/salesforce-ux/design-system/issues/127

## 手順

webpack をあまり触り慣れてない人向けのメモ。

### SLDS を npm install する

```
npm install --save @salesforce-ux/design-system
```

### index.scss の追加

SLDS は sass で作られているので、`index.scss`で SLDS の本体を`@import`するようにします。  
これを webpack で処理して、`style.css`として出力していきます。

```scss
@import "~@salesforce-ux/design-system/scss/index.scss";
```

### webpack.config.js の設定

webpack で css を扱うためにいくつか loader が必要です。まだの場合はインストールしておいてください。

```sh
# 各種ローダー
npm install --save-dev file-loader style-loader css-loader sass-loader
# 途中sassをコンパイルするために
npm install --save-dev node-sass
# webpackで処理したcssをファイル出力するために
npm install --save-dev extract-text-webpack-plugin
```

`webpack.config.js`にて`scss`を処理するようにします。

```js
var ExtractTextPlugin = require("extract-text-webpack-plugin");

module.exports = {
  entry: "./entry.js",
  output: {
    path: __dirname,
    filename: "bundle.js",
  },
  module: {
    loaders: [
      {
        test: /\.scss$/,
        loader: ExtractTextPlugin.extract(
          "style-loader",
          "css-loader!sass-loader"
        ),
      },
    ],
  },
  plugins: [new ExtractTextPlugin("style.css")],
};
```

これで、SLDS が`style.css`に含まれるようになります。

### アプリケーションへの組み込み

アプリケーションへの組み込みは webpack のエントリポイント(この例だと`entry.js`)で、`index.scss`を呼び出すと OK です。

```js
// entry.js
require("./index.scss");
console.log("Hello Salesforce Lightning Design System!!");
```

最後に`index.html`で webpack で出力された`style.css`を利用すれば OK。

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Document</title>
    <link rel="stylesheet" href="./style.css" />
  </head>
  <body>
    <script src="./bundle.js"></script>
  </body>
</html>
```

### font ファイルのロード(追記:2015/01/03)

上の方法では SLDS の font が正しくロードできず、font ファイルのリクエストがすべて 404 エラーになっていました。

まず、`webpack.config.js`の`module.loaders`に file-loader を追加して、font ファイルをコピーするようにします。

```js
var ExtractTextPlugin = require("extract-text-webpack-plugin");

module.exports = {
  entry: "./entry.js",
  output: {
    path: __dirname,
    filename: "bundle.js",
  },
  module: {
    loaders: [
      {
        test: /\.scss$/,
        loader: ExtractTextPlugin.extract(
          "style-loader",
          "css-loader!sass-loader"
        ),
      },
      {
        test: /\.(ttf|eot|svg|woff(2)?)(\?[a-z0-9]+)?$/,
        loader: "file-loader?&name=/assets/fonts/[name].[ext]",
      },
    ],
  },
  plugins: [new ExtractTextPlugin("style.css")],
};
```

これで、`/assets/font`以下に font ファイルがコピーされるようになりましたが、  
SLDS 内部の font 指定が絶対パス指定されているため、このままでは font が webpack で処理されません。

`index.scss`にて SLDS 内部の Sass 変数を書き換えて、webpack で処理できるようにします。

```scss
// SLDS内部で使われているfontのpath設定
$static-font-path: "~@salesforce-ux/design-system/assets/fonts/webfonts";

@import "~@salesforce-ux/design-system/scss/index.scss";
```

font の絶対パスの件は本家に似たような Issue がありますので、Sass 変数の置き換え作法は、今後のためにも知っておいた方がよろしいかと思います。

Compiling index-ltng.scss results in CSS that does not load salesforce fonts · Issue #71 · salesforce-ux/design-system https://github.com/salesforce-ux/design-system/issues/71

これで font も読み込むことができました。  
めでたし、めでたし。

## まとめ

あくまで最小構成です。  
React.js を触っていると webpack を使うことが多いのですが、ちょっとしたサンプルであれば`bower`か`CDN`の方が楽ですね。

webpackでSalesforce Lightning Design Systemを使う

あけましておめでとうございます。  
昨年は 5 月に Salesforce 界隈の会社に転職しました。  
多くの新しい出会い刺激を頂き有意義な 1 年でした。今年も引き続きご指導のほどよろしくお願いします。



## 2015 年の振り返り

昨年は、幾つか新規 IoT 案件に関わることが出来ました。

（前職）団体旅行向けの Beacon を使った点呼サービス。管理画面を Angular で作成したのは、懐かしい記憶です。

近距離無線：みんなのてんこ  
http://service.cresco.co.jp/tenko.shtml

（現職）建機の稼働監視。D3.js を使って建機の稼働状況を可視化。D3.js 辛かったですｗ。

News ＆ Trend - 東急建設が「建機 IoT」、環境対策と配置効率化目指す：ITpro  
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/083100328/

前半は少しフロントエンドっぽいことできたのですが、  
後半は社内で最も大所帯のチームでリーダー業(仕様の伝書鳩)をやっております。  
フロントエンドとは関わりのないこともあり、苦難の連続で大変貴重な体験をさせてもらってます。

他には、いくつか知り合いの勉強会の手伝いをしたり、社内勉強会でフロントエンド系の話をしたり、現職では会社初の社外勉強会を行ったりしてました。

express 実践入門  
https://gist.github.com/mitsuruog/fc48397a8e80f051a145

Angular2 で Todo アプリを作るハンズオン  
mitsuruog/angular2-todo  
https://github.com/mitsuruog/angular2-todo

第 1 回 FlectMeetup MEAN スタック＋ Heroku で Web サービスを作ろう！ - Flect | Doorkeeper  
https://flect.doorkeeper.jp/events/29804

それから、Airbnb のスタイルガイドの翻訳を ES6 版に更新したり、いくつかの OSS リポジトリにパッチを送ったりしてました。  
個人的にはプロダクトにも Babel を使うようになり、一気に ES6 化した年でしたね。

Javacript-style-guide by mitsuruog  
http://mitsuruog.github.io/javacript-style-guide/

## 2016 年の抱負

2016 年どうしようかと思ってた矢先に TL に流れて来たのがこれでした。

あの有名な「生きがいを見つけるためのベン図」はどこから来たのか？  
http://giantech.jp/2015/06/04/what-origin-is-the-purpose-diagram/

図を拝借します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/purpose_venn_diagram_ja.png)

あーそれそれ。「生きがい」求めてた。  
いままでモヤモヤしていたものが言語化できてスッキリした瞬間でした。

今年こそは「生きがい」を感じれる場所、見つけたいですね。

January, 2016

werckerでフロントエンドをCIテストする

webpackでSalesforce Lightning Design Systemを使う

2015年の振り返りと2016年の抱負