dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

HubotをES2015で書いてHerokuにデプロイする

今さらながら Slack bot を作りたくて、フレームワークHubot を選んだ。
Hubot はそのままでは CoffeeScript で書く必要があるんだけど、ES2015 もやっと覚えたばかりなのに CoffeeScript の勉強はしたくない。
ということで、ES2015 で書くための手順をメモ。

デプロイ先は Heroku です。

Hubot のインストール

まずは 公式ドキュメント の通りに Hubot スクリプトのひな形を作成する。

# Node.js はインストール済みとする
$ npm install -g yo generator-hubot
$ mkdir hubot-es2015
$ cd hubot-es2015
$ yo hubot
                     _____________________________
                    /                             \
   //\              |      Extracting input for    |
  ////\    _____    |   self-replication process   |
 //////\  /_____\   \                             /
 ======= |[^_/\_]|   /----------------------------
  |   | _|___@@__|__
  +===+/  ///     \_\
   | |_\ /// HUBOT/\\
   |___/\//      /  \\
         \      /   +---+
          \____/    |   |
           | //|    +===+
            \//      |xx|

? Owner zaki-yama <shingoyamazaki00@gmail.com>
? Bot name hubot-es2015
? Description A simple helpful robot for your Company
? Bot adapter slack
   create bin/hubot
   create bin/hubot.cmd
   create Procfile
   create README.md
   create external-scripts.json
   create hubot-scripts.json
   create .gitignore
   create package.json
   create scripts/example.coffee
   create .editorconfig
                     _____________________________
 _____              /                             \
 \    \             |   Self-replication process   |
 |    |    _____    |          complete...         |
 |__\\|   /_____\   \     Good luck with that.    /
   |//+  |[^_/\_]|   /----------------------------
  |   | _|___@@__|__
  +===+/  ///     \_\
   | |_\ /// HUBOT/\\
   |___/\//      /  \\
         \      /   +---+
          \____/    |   |
           | //|    +===+
            \//      |xx|

なんか色々ファイルが作成されました。

$ ls -al
total 64
drwxr-xr-x   13 yamazaki  staff   442  7 12 18:23 ./
drwxr-xr-x    5 yamazaki  staff   170  7 12 18:22 ../
-rw-r--r--    1 yamazaki  staff   197  5 20 06:45 .editorconfig
drwxr-xr-x   12 yamazaki  staff   408  7 12 18:37 .git/
-rw-r--r--    1 yamazaki  staff    39  5 20 06:45 .gitignore
-rw-r--r--    1 yamazaki  staff    24  7 12 18:23 Procfile
-rw-r--r--    1 yamazaki  staff  7904  7 12 18:23 README.md
drwxr-xr-x    4 yamazaki  staff   136  7 12 18:23 bin/
-rw-r--r--    1 yamazaki  staff   213  7 12 18:23 external-scripts.json
-rw-r--r--    1 yamazaki  staff     2  7 12 18:23 hubot-scripts.json
drwxr-xr-x  113 yamazaki  staff  3842  7 12 18:23 node_modules/
-rw-r--r--    1 yamazaki  staff   662  7 12 18:23 package.json
drwxr-xr-x    3 yamazaki  staff   102  7 12 18:23 scripts/


Babel のインストールと設定

ES2015 で書き、ES5 にトランスパイルするため Babel をインストールする。

$ npm install --save babel-cli babel-preset-es2015

通常、Babel などのアプリケーション本体で使われないパッケージは --save-dev を使ってインストールするが、
Heroku でデプロイしたときに devDependencies は自動的にインストールされない ため、dependencies に保存されるようにしてます。

つづいて、.babelrc を作り、以下を記述。

{
  presets: ["es2015"]
}

さらに package.json に npm script を定義する。

// 抜粋
"scripts": {
  "build": "babel src --out-dir build",
}

src, build のフォルダ名は自由です。


スクリプトの作成とビルド

準備ができたので、スクリプトを書いていく。
src/index.js (ファイル名は任意)に以下のように記述する。

module.exports = (robot) => {
  robot.hear(/すし/, (res) => {
    res.send(':sushi:');
  });
}

「すし」と入力したら Slack 上で寿司アイコンを返すだけの単純なスクリプト

保存したら、先ほどの npm script でビルドする。

$ npm run build
> hubot-es2015@0.0.0 build /Users/yamazaki/workspace/hubot/hubot-es2015
> babel src --out-dir build

src/index.js -> build/index.js

build ディレクトリ以下にファイルが生成されました。


Bot 起動用のコマンドを編集する

デフォルトでは、bot の起動は

$ ./bin/hubot

だけで済むが、今回は --require オプションでスクリプトが格納されているディレクトリを指定する。

$ ./bin/hubot --require build

デプロイ先に Heroku を使う場合は Procfile も編集しておく。

web: bin/hubot -a slack --require build

-a slack は Slack と連携するために必要)

bot の動きを Slack から試してみる場合は、事前に Slack の Hubot 設定ページから HUBOT_SLACK_TOKEN をコピーし

f:id:dackdive:20160713144815p:plain

.env に記述した後、

$ heroku local web

コマンドを実行する。

f:id:dackdive:20160713145028p:plain

ちゃんと動いてるようです。


Heroku にデプロイする

最終的に Heroku にデプロイするときは、以下の作業が必要です。

postinstall という npm script を追加する

参考:https://devcenter.heroku.com/articles/nodejs-support#customizing-the-build-process

postinstall というスクリプトは、Heroku にデプロイ後に自動的に走るスクリプト
デプロイ後に Babel によるビルドが実行されるようにする。

"scripts": {
  "build": "babel src --out-dir build",
  "postinstall": "babel src --out-dir build"
}


本番環境の環境変数にも HUBOT_SLACK_TOKEN を設定する

f:id:dackdive:20160713150224p:plain

画面を開くのが面倒な人は

$ heroku config:set HUBOT_SLACK_TOKEN=...

というコマンドを実行するか、.env ファイルから設定する以下の方法が便利です。
Herokuで本番環境の環境変数(config vars)を.envファイルで設定する - dackdive's blog


環境変数 HUBOT_HEROKU_KEEPALIVE_URL (とタイムゾーン)を設定する

external-scripts.json を見ると、hubot-heroku-keepalive が指定されている。
これは、Free dyno で bot がスリープしないようにするための Hubot スクリプトらしい。

そして、このスクリプトが正しく動作するためには HUBOT_HEROKU_KEEPALIVE_URL という環境変数が設定されている必要があるそうなので、設定する。

# Heroku アプリケーションの URL を指定すれば良い
$ heroku config:set HUBOT_HEROKU_KEEPALIVE_URL=https://[your-heroku-app].herokuapp.com/

# 以下のように、ワンライナーで指定することもできる
$ heroku config:set HUBOT_HEROKU_KEEPALIVE_URL=$(heroku apps:info -s  | grep web-url | cut -d= -f2)

その他の変数については以下の通り。詳しくは README の Configuration 参照。

  • HUBOT_HEROKU_WAKEUP_TIME : Bot を起動する時間。デフォルト 6:00
  • HUBOT_HEROKU_SLEEP_TIME : Bot をスリープする時間。デフォルト 22:00
  • HUBOT_HEROKU_KEEPALIVE_INTERVAL : Bot を定期的に起こす間隔。デフォルト 5 分間隔

おおむねデフォルト通りで良さそうに見えるが、WAKEUP_TIME および SLEEP_TIME は Heroku アプリのタイムゾーン(デフォルト UTC)に従うので、以下のようにタイムゾーンJST に設定しておいた方がよさそう。

$ heroku config:set TZ=Asia/Tokyo


(2016/08/23 追記) Heroku Scheduler というアドオンを追加する

上述した hubot-heroku-keepalive というスクリプトだけでは不十分だった。
スクリプト自体は dyno が スリープしないように 定期的にアクセスするためのものなので、
HUBOT_HEROKU_SLEEP_TIME から HUBOT_HEROKU_WAKEUP_TIME の間で dyno がスリープしてしまうとそれ以降スリープしっぱなしになってしまう。

そのため、HUBOT_HEROKU_WAKEUP_TIME に合わせて dyno をスリープから復旧させる必要がある。
これには hubot-heroku-keepalive の README に書いてあるとおり、Heroku Scheduler というアドオンを使う。

アドオンは管理画面からインストールするか、ローカルで以下のコマンドを実行する。

$ heroku addons:create scheduler:standard

インストール後に heroku addons:open scheduler を開くと設定画面が開くので、新規でジョブを追加して以下のように設定する。

f:id:dackdive:20160823084253p:plain

中央のスクリプトには

$ curl ${HUBOT_HEROKU_KEEPALIVE_URL}heroku/keepalive

を入力する。

また、NEXT DUE は UTC で入れる必要があるので要注意。(キャプチャだと日本時間の 9:00 に起こす)


その他

1) 起動時のログに

INFO /Users/yamazaki/workspace/hubot-es2015/build/index.js is using deprecated documentation syntax

と出力されている。
調べてみると、Description: などの冒頭のコメントがないとこのログが出力されるそう。
参考:Hubotでusing deprecated documentation syntax - Qiita

というわけで、試しにビルド前の JS にコメントを追記してみたけど
ビルドすると冒頭に 'use strict' が追加されてしまい、1 行目からコメントがないとこのログは消せないよう。

ビルド前
// Description:
//   My first slack bot
//
// Commands:
//   hubot すし - return sushi icon
module.exports = (robot) => {
  ...
ビルド後
'use strict';

// Description:
//   My first slack bot
//
// Commands:
//   hubot すし - return sushi icon
module.exports = function (robot) {
  ...

今のところ特に困らないので、とりあえず諦める。


2) (解決) 同じく起動時のログに

ERROR hubot-heroku-alive included, but missing HUBOT_HEROKU_KEEPALIVE_URL. `heroku config:set HUBOT_HEROKU_KEEPALIVE_URL=$(heroku apps:info -s  | grep web-url | cut -d= -f2)`

と出ている
確認したところ external-scripts.jsonhubot-heroku-keepalive というライブラリが指定されていて、README を読む限り HUBOT_HEROKU_KEEPALIVE_URL という環境変数を指定する必要があるみたい。


3) デフォルトで作成される scripts ディレクトリは不要になったので削除した。一緒に、hubot-scripts.json も deprecated のようなので削除。
(起動時に以下のログが出ていた)

WARNING Loading scripts from hubot-scripts.json is deprecated and will be removed in 3.0 (https://github.com/github/hubot-scripts/issues/1113) in favor of packages for each script.


GitHub


リファレンス

Emoji Prefixに学ぶgitのコミットの分け方

こちらの記事を読んで。

http://memo.goodpatch.co/2016/07/beautiful-commits-with-emojis/

この記事では、Emoji Prefix というコミットメッセージに関するルールについて紹介している。
どんなルールかというと、「コミットメッセージの先頭には、コミットの内容に合った Emoji をつけましょう」というものらしい。

Prefix に使える Emoji の種類をルール化し、コミットメッセージにはいずれかの Emoji を必ずつけるように徹底することで
コミットの内容がわかりやすくなるだけでなく、粒度も揃うという効果が期待できるようだ。

以下、記事から引用。

最も期待している効果は、コミットが綺麗になることです。 開発の現場では「インデントの修正と機能の修正を同じコミットにしないでください 😭 」といった悲痛な叫びをよく耳にします。 Emoji Prefixのルールでは「インデントの修正と機能の修正」を同時に表すEmojiが定義されていないので、Emoji Prefixに従ってEmojiをつけるためにはコミットを分ける必要がでてきます。 このように適切に定義されたEmoji Prefixを使うことで、ごった煮コミットが作られにくくなり、ある程度機械的にコミットの粒度を揃えることができます。 コミットが綺麗になればコードレビューの時間を節約できたり、歴史を追いやすくなるのでとても嬉しいことですね🎉

なるほどー面白いなーと思いつつ、そういえば社内でも「コミット分けろっていうけど、じゃあ適切なコミットの粒度ってなんなんだ」という議論がちょうど起きていたので
この Emoji Prefix のきっかけとなった(と、記事では書かれている)Atom のコントリビュートガイド にはどんな種類の Emoji が定義されているのか、気になって確認してみた。


Atom での Emoji Prefix

ref. https://github.com/atom/atom/blob/master/CONTRIBUTING.md#git-commit-messages

英語が怪しいが、おおむねこういう内容だという認識です。

  • 🎨 :コードのフォーマットや構造を改善した
  • 🐎 :パフォーマンスを改善した
  • 🚱 :メモリリークを修正した
  • 📝 :ドキュメントを書いた
  • 🐧 :Linux 環境固有の問題を修正? (fix something on Linux)
  • 🍎 :Mac 環境固有の問題を修正?
  • 🏁 :Windows 環境固有の問題を修正?
  • 🐛 :バグを修正した
  • 🔥 :コードやファイルを削除した
  • 💚 :CI に関する修正
  • ✅ :テストを書いた
  • 🔒 :セキュリティ関連
  • ⬆️ :dependencies (依存ライブラリ?) をアップグレードした
  • ⬇️ :dependencies をダウングレードした
  • 👕 :lint の警告を remove した (lint で警告されていたところを修正した、の意?)

また、Emoji 以外のガイドとしては

  • 現在形を使う(Added feature でなく Add feature。英語のコミットメッセージでよく言われるやつ)
  • 命令形を使う(Moves cursor to... でなく Move cursor to...、のように3単現の s とか不要。これもよく聞く)
  • 1行目は72文字以下
  • issue や PR へのリファレンスはふんだんに (liberally) <- #xxx を多用しなさいってこと?
  • ドキュメントの変更だけの場合、[ci skip] を含める


所感

ぱっと見で思ったこととしては

  • 先頭1文字でコミット内容がだいたいわかる、というのは良いと思う
    • コミット内容に応じて [Tag] をつけようかという話が社内であったので、それより圧倒的にスマートになる
  • OS 固有の修正のためにそれぞれの Emoji を用意してるの面白い。が、自分達のプロダクトでは必要ないだろうなー
  • あくまで個人的な感想だけど、直感的にわかりづらい Emoji がいくつかあるような。。。
  • いずれにしてもこんなに種類あると意味を覚えてらんなさそう

実際には、記事を書いてくださった Goodpatch さんがやられているように
これをそのままマネするのではなく、チームに合った独自ルールを定義することになるんでしょう。

気になったのは、「機能改善」とかでひとつの Emoji にしてしまうと
内容は分けられるけど粒度はものによってはばかでかいコミットになってしまわないかなーというところ。
これも、チームとしてのコミット粒度に対する考え方によるんでしょうね。
(粒度を揃えるというよりも「1つのコミットで1つのことをやる」を徹底させる目的と捉えた方が適切か)

自分のチームに合ったルールを作る、という部分に難しさはあるが、それなりに効果がありそうなので検討したい。
好き嫌いあるけど、メッセージが華やかになるのいいすね。


おまけ

記事に Tips として書いてあるコミットテンプレートという機能が地味にすごい。

reveal.jsで外部Markdownファイルを読み込む

いつも忘れるのでメモ。
index.html 内に直接書くのではなく、別途用意した Markdown ファイルをスライドにしたい。

body に以下のように記述する。

<body>
    <div class="reveal">
      <div class="slides">
        <section data-markdown="./index.md"
                 data-separator="^\n\n\n"
                 data-separator-vertical="^\n--\n"
                 data-separator-notes="^Note:">
        </section>
      </div>
    </div>
    ...
</body>

こうすればスライドの内容は index.md というファイルに書くことができる。

ページの区切りは data-separator で指定することができて、上の例では改行 3 つ分としている。
--- にすると MarkdownGitHub で見たときに区切り線でいっぱいになるので避けた。

また、このように外部ファイルを読み込む場合はそのまま index.html を開いてもだめで
ローカルサーバーを起動する必要がある。

f:id:dackdive:20160629210349p:plain

Failed to get the Markdown file ./index.md. Make sure
that the presentation and the file are served by a HTTP server
and the file can be found there. NetworkError: Failed to
execute 'send' on 'XMLHttpRequest': Failed to load 'file:///
Users/yamazaki/workspace/reveal.js-template/index.md'.

どんな方法でサーバーを起動してもいいんだけど、面倒なのとその他の設定もよく忘れてしまうのでテンプレートを作った。

Node の http-server を使っている。

ES2015時代のJavaScriptテストツールまとめ

最近になって JavaScript を勉強中です。
ES2015 と React にもちょっとずつ慣れてきましたが、テストについては Karma とか mocha とか名前は聞くけど何が何なのかよくわかってなかったので、軽く整理してみます。


JavaScript テストツールの大まかなカテゴリ

JavaScript のテストツールは、だいたい以下のようなカテゴリに分類することができます。

  1. アサーションライブラリ
  2. テストフレームワーク(テスティングフレームワーク
  3. テストランナー

以下、それぞれについての説明と、代表的なライブラリを見ていきます。
★は個人的にこれを使おうかなと思ったやつです。


1. アサーションライブラリ

テストの一番重要な部分である、「A は B である(assert A === B)」を検証する(ためのメソッドを提供する)ライブラリ。
代表的なものとして、以下があります。

Node.js の標準 assert

Node.js 自体にも assert モジュール があるようです。

expect.js
  • Redux の examples のテストで使われているのはこれ
  • メソッドとしては expect() のみ
chai
  • mocha の Introduction で使われているのはこれ
  • メソッドとしては should(), expect(), assert() がある
power-assert
  • テスト界隈で有名な t_wada さんが開発したライブラリ
  • 厳密に言うとアサーションライブラリではないらしい
  • メソッドとしては assert() のみ
  • Node の assert と比べ、テスト結果として出力される情報がわかりやすい
  • 参考:5minで分かるpower-assert


2. テストフレームワーク

テストを実行するためのツール。
テストフレームワークに従った書き方でテストを書き、実行するとテスト結果を確認することができる。

代表的なものは以下。

mocha
  • Redux の examples のテストで使われているのはこれ
  • テストスイートに相当するものを describe で、テストメソッドに相当するものを it で書く
  • サンプル
import { expect } from 'chai';
import add from './my-add-function';

describe('add() の機能', () => {
  it('1 + 1 は 2 になる', () => {
    expect(add(1, 1)).to.equal(2);
  });

  it('負の数も扱うことができる', () => {
    expect(add(-1, 1)).to.equal(0);
  });
});
Jasmine


3. テストランナー

先ほどのテストフレームワークだけでもテストを実行することが可能ですが、
テストランナーを使うと様々なブラウザ環境でテストを実行させたり、テスト結果やカバレッジを見やすい形式で出力することができるそうな。

代表的なものは以下。

Karma
testem
  • 名前だけ聞いた。現在も流行っているのかどうか不明


番外編

上記の3カテゴリにはあてはまりませんが、それ以外に有名なライブラリをいくつか。
これらはいずれも以下の記事で紹介されており、一通り読むとどんなものか知ることができます。React のテストの書き方を学ぶ上でも大変良い記事です。

Sinon.js
(React 限定)Enzyme


まとめと TODO

調べる前はなんでいろんなものを組み合わせて使う必要があるのかわかってませんでしたが、それぞれ役割が異なるんですね。

各ツールについてはなんとなく理解できたので、
次は実際に karma + mocha + power-assert という組み合わせで、ES2015 で書いた React/Redux アプリのテストを書いてみようと思います。

リファレンス

AsciiDocによる継続的ドキュメント開発〜1.インストールと基本的な使い方

はじめに

ドキュメントを書くための言語としておそらく今一番ポピュラーなのは Markdown だと思いますが、
かっちりした仕様書やユーザーマニュアルなど、より本格的なドキュメント作成にはやや機能不足と感じることがあります。

私も以前、ドキュメントを Gitbook で作れないか検討したことがあったんですが
表を書くのがめんどくさかったり、図のキャプションなどに対応していなかったことから断念しました。

そこで、今回は Markdown よりも表現力の高い言語として知られる AsciiDoc を試してみます。
AsciiDoc は O'reilly でも採用されているほか、Pro GitJavaScript Promise の本 などの非常に完成度の高い技術ドキュメントが AsciiDoc で書かれています。

(参考記事)
テクニカルライティングの未来を先取り ー Asciidoc フォーマットと GitHub を使って技術書 Pro Git を共同執筆 — Japanese Official — Medium
JavaScript Promiseの本を書きました | Web Scratch

やりたいことは色々とあるんですが、まずはインストールと基本的な使い方を学ぶところまでやってみます。

参考書籍

この書籍を読みながら勉強中です。
本屋でざっと流し読みした感じ、AsciiDoc で書いたドキュメントを GitHub で管理したり、校正ツールや CI を導入したりと
自分のやりたいことがそのものずばりって感じです。


インストール

Asciidoctor という AsciiDoc の Ruby 実装をインストールします。 AsciiDoc のリポジトリ を見ると HTML などに変換するプロセッサーも用意されているようですが、
実際に AsciiDoc を HTML や pdf に変換するためのプロセッサーは Asciidoctor の方が一般的のようです。

ブログを書いた時点での Ruby のバージョンは以下です。

$ ruby -v
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin14]
$ gem -v
2.4.5.1
$ bundle -v
Bundler version 1.12.5

インストール方法は、普通に

$ gem install asciidoctor

を実行するか、または Gemfile を用意し

source 'https://rubygems.org'
gem 'asciidoctor'

と記述した後、

$ bundle install

を実行します。

$ bundle install
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Resolving dependencies...
Installing asciidoctor 1.5.4
Using bundler 1.12.5
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.

インストールすると asciidoctor というコマンドが実行可能になります。


基本的な使い方:HTML, pdf, epub の作成

さっそく何かドキュメントを書いてみます。
拡張子は .adoc または .asciidoc にします。

= はじめての AsciiDoc ドキュメント

これは AsciiDoc で書かれたドキュメントです。

== セクション

``=`` から始まる行はセクションの見出しになります。 +
``==``, ``===``, ... のように `=` を重ねるとレベルが1つ下がります。

== テーブル(表)

.テーブル見出し

|=======================
|Col 1|Col 2      |Col 3
|1    |Item 1     |a
|2    |Item 2     |b
|3    |Item 3     |c
|=======================

CSV 形式で書くこともできます。

[format="csv"]
|======
1,2,3,4
a,b,c,d
A,B,C,D
|======

== ソースコード

[source, javascript]
----
export default class MyComponent extends React.Component {
    render() {
        <div>Hello, World!</div>
    }
}
----
HTML への変換

HTML への変換は、asciidoctor コマンドを実行するだけです。

$ ls
sample-doc.adoc
$ asciidoctor sample-doc.adoc
$ ls
sample-doc.adoc sample-doc.html

生成した HTML はこちら。

f:id:dackdive:20160614013736p:plain

デフォルトのスタイルでもイイ感じですが、ソースコードが色付け(シンタックスハイライト)されてませんね。

ソースコードシンタックスハイライト

http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#source-code を読むと、
ファイルの先頭で source-highlighter という変数を定義する必要があるようです。
また、シンタックスハイライト用のプラグインをいくつかの選択肢の中から選んでインストールする必要があります。

今回は coderay を選択します。

$ gem install coderay

でインストールした後、.adoc ファイルの先頭に以下を追記します。

:source-highlighter: coderay

この状態で HTML に変換すると、シンタックスハイライトが有効になります。

pdf への変換

HTML 以外の形式への変換は、別途プラグインをインストールする必要があります。
Converters の項を参照)

pdf については asciidoctor-pdf をインストールします。

$ gem install asciidoctor-pdf

コマンドが asciidoctor-pdf になること以外は HTML の時と変わりません。

$ ls
sample-doc.adoc sample-doc.html
$ asciidoctor-pdf sample-doc.adoc
$ ls
sample-doc.adoc sample-doc.html sample-doc.pdf

生成した pdf がこれです。

f:id:dackdive:20160614023314p:plain

フォントなど、スタイルで気に入らない部分があるかもしれませんが CSS で調整可能のようです。これについてはまた今度。

epub への変換

epub については asciidoctor-epub3 をインストールします。
参考:How to Convert AsciiDoc to EPUB3 with Asciidoctor | Asciidoctor

まだ試せてないので今後の課題として。


(おまけ)エディタの設定

最後に、AsciiDoc を書きやすくするためにエディタも設定しておきます。
Atom の場合、公式ドキュメント
http://asciidoctor.org/docs/editing-asciidoc-with-live-preview/#atom
にあるように、以下2つのプラグインをインストールすると良さそう。

asciidoc-preview を入れると(Mac の場合)cmd + Shift + A でプレビューを表示させることができます。便利。

f:id:dackdive:20160614204519p:plain

一方、私は普段 Vim を使ってるんですが、Markdown ではできたプレビュー機能を提供するプラグインは見つからず。

参考:[vim]vimでmarkdownをリアルタイムプレビューできるようにする - dackdive's blog


触ってみた感想

Markdown ではネックだった表が CSV 形式で書けたり、ちょっと調べた感じだと図のキャプションに対応していたりと
Markdown では対応できなかったところをカバーしてくれそうな印象。

ただ、以前 Gitbook 調査していて gitbook-cli を使ったときは

$ gitbook serve

みたいなコマンドでローカルサーバーが立ち上がり、以後、ファイルの変更を検知して常に最新の HTML を表示することができていたんですが
Asciidoctor 単独だとそういった機能は提供していないので、gulp タスクなり Makefile なりでそのあたりも自分で作る必要がありそうです。


今後の予定

今後、こういったことをできるようにしていきたいです。

  • epub 形式に変換する
  • ローカルでドキュメントを書くときはローカルサーバーを起動し、自動で HTML 変換する
  • RedPen や textlint などの文法チェックツールを使用する
  • Travis CI などの CI ツールで GitHub にコミット時に自動的に文法チェックを実行する
  • CI の一環で、最新のドキュメントの HTML 版が常にどこかにデプロイされるようにする

とりあえず、今後も色々と機能追加していくと思うので、コードを GitHub に上げておきます。

[git]複数のcommitをまとめてcherry-pickする

ちょいメモ。

別ブランチのコミットを他のブランチにも適用するときに便利な cherry-pick コマンドですが、
複数のコミットをまとめて cherry-pick してしまいたい時がたまにあります。

そんなとき

$ git cherry-pick [cherry-pick の始点となるコミット]..[cherry-pick の終点となるコミット]

というように、A..B という指定のしかたでコミット A からコミット B までの一連のコミットを cherry-pick することが可能です。

が、注意点として、始点となるコミットは 実際に cherry-pick したいコミットの1つ前 を選ぶ必要があります。

以下、例。

$ git branch -a
* master

$ git log
commit 63ca256a5f806c8b237c3ff5c872debc0be12359
Author: zaki-yama <xxx@gmail.com>
Date:   Mon Jun 6 17:22:35 2016 +0900

    first commit

$ git checkout -b foo

# 略: foo ブランチ上でコミットを進める

$ git log
commit 738b8de617497b37bc47c06ce9fa9f676c256b61
Author: zaki-yama <xxx@gmail.com>
Date:   Mon Jun 6 17:23:39 2016 +0900

    commit 3

commit bee000f8a765367fe489302b064f856b2e1b259a
Author: zaki-yama <xxx@gmail.com>
Date:   Mon Jun 6 17:23:12 2016 +0900

    commit 2

commit d4baa931f1d2c3259c45109b880b9222a592c61f
Author: zaki-yama <xxx@gmail.com>
Date:   Mon Jun 6 17:22:59 2016 +0900

    commit 1

commit 63ca256a5f806c8b237c3ff5c872debc0be12359
Author: zaki-yama <xxx@gmail.com>
Date:   Mon Jun 6 17:22:35 2016 +0900

    first commit

$ git checkout master

# commit 1 ~ commit 3 までを master に cherry-pick したい
# 1) 始点に commit 1 を指定した場合
# conflict する...
$ git cherry-pick d4baa931f1d2c3259c45109b880b9222a592c61f..738b8de617497b37bc47c06ce9fa9f676c256b61
error: could not apply bee000f... commit 2
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

# 2) 始点に commit 1 の1つ前を指定した場合
# 正常に cherry-pick できる
$ git cherry-pick 63ca256a5f806c8b237c3ff5c872debc0be12359..738b8de617497b37bc47c06ce9fa9f676c256b61
[master 2326872] commit 1
 Date: Mon Jun 6 17:22:59 2016 +0900
 1 file changed, 1 insertion(+)
[master 85d0cd2] commit 2
 Date: Mon Jun 6 17:23:12 2016 +0900
 1 file changed, 1 insertion(+)
[master 3299797] commit 3
 Date: Mon Jun 6 17:23:39 2016 +0900
 1 file changed, 1 insertion(+)

$ git log
commit 3299797bf2964b6c728eb268255e34eee5877dd0
Author: zaki-yama <xxx@gmail.com>
Date:   Mon Jun 6 17:23:39 2016 +0900

    commit 3

commit 85d0cd22f4d962b8b6c670dd0894874049437343
Author: zaki-yama <xxx@gmail.com>
Date:   Mon Jun 6 17:23:12 2016 +0900

    commit 2

commit 2326872f0c80c9b2dd83200ba039aba0ceef9b9f
Author: zaki-yama <xxx@gmail.com>
Date:   Mon Jun 6 17:22:59 2016 +0900

    commit 1

commit 63ca256a5f806c8b237c3ff5c872debc0be12359
Author: zaki-yama <xxx@gmail.com>
Date:   Mon Jun 6 17:22:35 2016 +0900

    first commit

Summer '16 開発者向けWebセミナー のメモ

Summer '16 開発者向けWebセミナー | Salesforce Developers

割とちゃんと観た。

UI の新機能(Lightning Experience)

  • ホーム画面のカスタマイズ
  • Lightning App Builder で作ったページが(ようやく)LEX とモバイル両方で使用可能 f:id:dackdive:20160603154909p:plain

  • オブジェクトの日付項目からカレンダーの予定を作成可能

  • レポートのフィルタリング

Apps の新機能(Sales, Service, Mobile, Wave)

Sales Cloud

  • 取引先責任者と複数の取引先の関連づけを許可
    • Contact.Account.Id ができなくなり、AccountContactRelation が追加(連結オブジェクト?)
    • データモデル変更になるのつらい...
  • Lightning ボイス(日本ではまだ)

Wave

  • CSVExcel 形式でのダウンロード
  • SAQL、集計関数の拡張

Mobile

  • オフライン機能(公開パイロット)
    • S1 for Android 9.0 で提供、S1 for iOS(予定)

Identity とセキュリティの機能拡張

  • テンポラリ認証コードの生成
    • 2要素認証を利用するユーザがデバイスを忘れたりしたときに、一時的に認証コードを発行
    • このコードを生成するだけの PermissionSet が追加
  • ユーザ切り替えの簡素化(LEX のみ)
    • 設定項目あり(セッション)

一般的な開発の新機能

  • Lightning プロセスビルダー
    • 複数条件でのアクション実行が可能
      • 1個目の条件を満たした場合、そこで処理をやめるか次の条件に進むか選べるように

f:id:dackdive:20160603154333p:plain

  • 制限つき選択リスト(正式リリース)
    • 選択リストの選択肢にある値以外は API 経由でも登録できなくするやつ
  • Flow REST API
  • イベントモニタリング
    • Wave App として
    • 別途契約が必要
  • セッションベースの権限セット(開発者プレビュー)
    • 特定の種類のセッションでのみ有効な権限セットを割り当て

Apex

  • UI からテスト結果の確認(LEX のみ)
    • 開発者コンソールと同じ
  • getPopulatedFieldsAsMap()

f:id:dackdive:20160603154924p:plain

Visualforce

  • LEX での Visualforce の使用が GA に
    • 使えない機能もあり
    • まだスタイルが自動で当たるわけではない

Lightning Component

  • アクセスチェックエラーの強制
    • <aura:component access="global"> とかちゃんとつけようねという話

その他

  • LEX の IE11 のサポート終了
  • Chatter デスクトップ終了