こんにちは、三宅です。
今回は、Salesforce Lightning Design System (SLDS) について、フロントエンドエンジニアの視点から掘り下げてみたいと思います。

その前に、少し SLDS についての説明を。 Salesforce は 8 月末に、Lightning Experience を発表しました。
Lightning Experience は、Salesforce1 プラットフォーム上でモバイルアプリケーショをコンポーネントベースの UI で構築できる Salesforce1 Lightning Framework をデスクトップの Web ブラウザまで拡張したものと言えます。
10 月の Winter '16 のリリースで利用できるようになり、モダンで Salesforce1 モバイルアプリのデザインと一貫性のあるデスクトップ UI となるようです。

SLDS は、Lightning Experience のユーザインタフェースにマッチしたアプリケーションを開発する際に利用できる CSS フレームワークです。
Force.com では Visualforce や Force.com Canvas を用いて独自の UI を持つアプリケーションを開発することができます。
従来は CSS フレームワークを使うにせよ、独自に CSS を記述するにせよ、Salesforce 自身の CSS との衝突に気をつける必要があったり、デスクトップとモバイルでプラットフォーム自体のデザインが異なる中で両者で違和感のないデザインとしなければいけないなどの苦労がありました。
Lightning Experience と SLDS でそういった苦労が解消され、より容易にユーザにとって統一感のあるデザインのアプリケーションを開発することが可能となるでしょう。

Pure CSS フレームワーク

有名どころの CSS フレームワークとして、Bootstrap、Material-UI、Pure などが挙げられます。
SLDS は Pure と同様に、CSS のみで実装されたフレームワークとなります。

Bootstrap や Material-UI は JavaScript も含んだフレームワークで、CSS ファイルと Script ファイルを読み込むだけで簡単にモーダルダイアログやドロップダウンメニューなどのインタラクティブなコンポーネントを利用することができます。
SLDS にもモーダルダイアログなどのコンポーネントは用意されていますが、それをユーザのアクションに表示するなどの処理は自分で実装する必要があり、Bootstrap などと比較して利用する際に少し手間がかかります。

しかし、JavaScript フレームワークとともに利用する際に、CSS のみのフレームワークであることは有利に働きます。
AngularJS や React 上で Bootstrap を利用しようとすると jQuery による DOM 操作の部分が JavaScript フレームワークと競合し、Bootstrap の実装を参考に自分で実装する必要であったり、Material-UI ではそもそも React の利用が前提となっていたりします。
シングルページアプリケーションなど複雑なフロントエンドアプリケーションを開発する際に、JavaScript フレームワークの制約がないこと、インタラクションを自分たちの実装で制御できることは大きな利点と言えるでしょう。

SASS を用いたカスタマイズ

SLDS のダウンロードには、CSS ファイルやアイコンなどのアセットに加え、SASS のソースコードが含まれています。
フレームワークで利用するカラーやフォントサイズ、スペースなどの値が、「/scss/design-tokens.scss」に全て変数として定義されています。

$color-brand: rgb(21, 137, 238) !default;
$color-brand-dark: rgb(0, 112, 210) !default;
$font-size-x-small: 0.625rem !default;
$font-size-small: 0.875rem !default;
$font-size-medium: 1rem !default;
$font-size-large: 1.25rem !default;
$font-size-x-large: 1.5rem !default;
$font-size-xx-large: 2rem !default;

上記は定義されている変数の抜粋です。
全ての変数は !default とともに定義されているため、SLDS の index.scss をインポートする前に任意の変数の値を定義することで、簡単にカスタマイズすることが可能です。
Salesforce コミュニティでは独自のブランドカラーを定義することができるため、それらのブランドカラーを適用した SLDS フレームワークをコンパイルすることができます。
ただ、全ての変数に直接値が定義されているため、一つ一つ値を設定する必要があります。Bootstrap のように、カラーパレットで一括で変更できるようになっていればよかったのですが。

コンポーネント志向

SLDS は徹底したコンポーネント志向に基づいて設計されています。
AngularJS や React、それに Web Components でも見られるように、コンポーネント化はフロントエンドの大きな流れです。

AngularJS や React は、JavaScript で UI コンポーネントの機能を定義し、それをアプリケーションの様々な箇所で再利用可能とするような思想に基づいて作られています。
そのようなフレームワークを利用する際に従来のページごとや特定のコンテナに依存した CSS の定義をしていると、重複したスタイル定義が発生したり外側のスタイル定義の影響を受けたりし、再利用性や保守性が大きく損なわれることとなります。

CSS にはネームスペースやスコープが存在しないため、命名規約などでコンポーネント志向の設計を行うこととなります。
SLDS では、BEM に似た設計に基づいてコンポーネントが定義されています。
Components > Cards を例に確認してみます。

.slds-card {
  padding: 0;
  border-radius: 0.25rem;
  background-clip: padding-box;
  background-color: #f4f6f9;
  border: 1px solid #d8dde6;
}
.slds-card + .slds-card {
  margin-top: 1rem;
}
.slds-card__header {
  padding: 0.75rem 0.75rem 0.25rem;
}
.slds-card__body {
  padding: 0.5rem 0;
}
.slds-card__footer {
  padding: 0.25rem 1rem 0.5rem;
}
.slds-card .slds-tile {
  margin: 0.5rem;
  padding: 0.5rem;
}

.slds-card で Card コンポーネントの定義を行い、ヘッダやフッタなどのパーツを、.slds-card__header のように __ で続けて定義しています。
Card コンポーネントが内包するコンポーネントのカラーやフォントサイズなどの定義はここでは行われていません。
リンク先のマークアップのように、.slds-media や .slds-text-heading--label などのより具体的なコンポーネントを定義してスタイリングが行われています。
独自のデザインの Card を作りたい場合は、既存のコンポーネントを組み合わせたり、内包する新たなコンポーネントを定義します。
このような設計とすることで、アプリケーション全体のデザインの一貫性を保ちつつ、容易に拡張や修正が可能となります。

今回は、Salesforce Lightning Design System をフロントエンドエンジニアの観点で紹介してみました。
AngularJS や React などメジャーな JavaScript フレームワークの思想や、Web Components の仕様策定が進んでいることをみても、UI のコンポーネント化は今後さらに進んでいくことが予想されます。
特に CSS に関しては、これまでとは考え方を大きく変える必要が出てきます。
SLDS は Salesforce Experience の UI を容易にデザインできるツールであると同時に、コンポーネント志向に基づく CSS 設計のよいお手本であると言えます。
コンポーネント志向の CSS 設計に興味のあるデザイナやプログラマは、SLDS を使うだけでなく、どのように定義されているか実装を覗いてみるだけでも勉強になると思います。

はい、どうも。 最近、HerokuConnectをつうじてSalesforceにも興味を持ち始めたおっぴーです。

ある特定のプラットフォームに縛られた技術を利用することを、「ベンダーロックイン」と称して遠ざかりたくなるものなのですが、ロックインされると結構、便利で快適というのもまた事実。

本日は、SalesforceとHerokuにどっぷり使って楽をしたい！HerokuConnectを使ってみたい！とお考えの方が、「でも、これってどうなるのかな？」という点について、動作確認をした結果を踏まえてご紹介いたします。

最初に結論

• datetimeの扱いはUTC固定なので要注意
• ファイルや画像は連携できないので別途仕組みが必要
• 価格が謎
• 以上を考慮したうえでも簡単なので利用する価値は十分

日本語はうまく扱えますか？

大丈夫です！ HerokuPostgresとSalessforceはともにUTF-8で文字列のデータを管理しています。 文字コードそのものは扱いの難しい要素でありますが、双方がおなじ文字コードを採用していれば複雑な考慮は不要ですね。

レコードの削除や 項目の値の削除は連携できる？

できます！

たとえば、HerokuPostgresでレコードを消したけど、Salesforce上ではレコードが残ってしまわないか？ その逆は？ その心配は不要です！ レコードをそのものを削除した場合も連携中の項目の値を削除した場合も、それぞれその情報が連携されます。 ただし、双方のデータの更新が反映されるのはRead/WriteModeのみですので、連携設定はちゃんと行いましょう。

バッチ処理のような連携は可能？

たとえば、毎週土曜日の深夜1時から一括でデータをHerokuからSalesforceに連携したい（もしくは、その逆も）。

残念ながらできません！

HerokuConnectは一定の間隔で、SalesforceとHerokuPostgresのデータ連携を行うためのサービスです。 間隔は2分から60分までの間で設定できますが、スケジュール管理機能はありません。

このため、毎月1日、毎週土曜日に、や毎晩午前2時になどの定期的な連携を行うことはできません。

日付（Date）もしくは日付・時間（DateTime）はちゃんと連携できる？

日付は大丈夫ですが、日付・時間は残念がら。。。

HerokuConnectとSalesforceでは、datetimeをUTC固定で扱います。

このため、日付・時間をHerokuで更新する場合は、datetimeをUTCで扱うよう注意しましょう。 たとえば、HerokuPostgresのデータを利用するアプリでは、datetimeをJSTに変換して表示し、登録・更新時はUTCで扱うよう注意が必要です。

データ連携でエラーが発生したらどうなるの？

連携しているHerokuアプリに追加されているmemberとcollaboratorにエラーメールが送信されます。

メールアドレスは、Herokuアカウントのメールアドスレスになります。 できれば

• アラート送信先のメールアドレスが設定できるようになる
• 送信したくないアカウントを選べる

ようになると嬉しいですね。

SalesforceのAPI利用制限は本当に関係ないの？

ありません！

現状の画面では、連携時にAPIをどれだけ消費しているか、をみることができます。 が、これはAPI利用制限がHerokuConnectにも適用されていた時の遺産のようなものでしょう。

既存のテーブルとオブジェクトを連携したいんだけど？

非常に残念ですができません。

たとえば、HerokuPostgresに既存のusersというテーブルがあるとします。 このusersというテーブルにたいして、Salesforceのカスタムオブジェクトのサービス利用者（仮にServiceUserとしましょう）のユーザー名を連携させたい、というケースはあるでしょう。

しかしながら、これはできません。

データ連携を行う際には、連携対象のSalesforceのオブジェクト専用テーブルがHerokuPostgres上に作成されます。 上記の場合は、serviceuser__cというテーブルが新たに作成され、データ連携を行うためには、このテーブルを介する必要があります。

このため、Herokuでusersのユーザー名を変更した場合には、serviceuser__cのユーザー名も変更しなければならない、という動きになります。 うーむ。。。おしい。。。

SalesforceのSandbox環境やProduction環境にはつなげるの？

できます！

HerokuConnectの設定時に、Production、Sandbox、CustomDomainの3つから選択可能です。 Herokuの環境も、本番、ステージングをわけておけば、それぞれの環境でHerokuConnectを利用したアプリケーションを動作させることができます。 こうすることで、リリース前のテストもしっかり出来そうですね。

メモ&添付ファイルは連携できる？

コメントをいただいたとおり、Attachmentオブジェクトの選択が可能であることを確認しました。

確認不足で誤記載をしており、失礼いたしました！

主従関係のレコードをHerokuでインサートできるの？

可能です。

詳しいやり方はドキュメントに記載されています。

機会がありましたら、このブログで方法についてご紹介いたしますが、外部IDを主オブジェクトに定義することで、連携が可能になります。

連携時にデータの変換はできる？

これはできません。

たとえば、こんなことがやりたいですよね。

顧客の購入金額にあわせて、ユーザーランクを決定している場合に、 Salesforceでは金額をもっていて、HerokuPostgresでは金額は扱いたくないのでランクコードとしてA、B、Cの文字列として渡したい、という場合。

こうした変換を行う場合は、あらかじめにSalesforceのオブジェクトに変換結果をもっておき、これを連携するという方法になりそうですね。

でも、お高いんでしょう？

無料で利用できるdemoでは、10000行までの相互のデータ連携が可能です。

それ以上の利用の場合は、有償版の利用が必要になりますが、営業さんへのお問い合わせとなるようです。 このため、正確な価格は謎、です。

現状、無料で利用できるdemoは、あくまでも事前検証や開発に利用するものと考えられますが、10000行も連携できれば、十分かも知れませんね。

ということで

HerokuConnectにまつわる疑問について一問一答でした。 これはどうよ？というご質問があるかは、ぜひご連絡ください。分かる範囲でお答えします！

あと2015/09/10に第1回FlectMeetupを開催します！

普段、フレクト社内で行われている勉強会の雰囲気で、外部の方と一緒にお勉強してお酒を飲みたい！という思いで企画したものです。

予定があう方は是非、ご参加ください！

https://flect.doorkeeper.jp/events/29804

herokuブログでは初めまして。@ucmskyです。

まず最初に告知ですが。前の記事でも紹介したとおり、9月10日に弊社で勉強会を開催します。

第1回FlectMeetup MEANスタック＋HerokuでWebサービスを作ろう！

内容はMEANスタックのハンズオンですので、node.jsに興味のある人は是非。

rigepoleの簡単な紹介

さて、今日紹介することですが、その前に。

皆さん、herokuでもridgepole使いたいですよね？ 使いたいですよね？（震え声

ところで、ここでridgepoleって何？　という人はこちらをどうぞ。

クックパッドにおける最近のActiveRecord運用事情

平たく言うと、クックパッドの中の人が開発したgemです。

通常、railsで開発を進める場合、DBのスキーマを変更する場合ですと、各変更毎にmigratenファイルを生成し、変更内容を記載します。変更内容はカラムの変更（追加削除更新など）と、逆に差し戻す場合の逆の手順（カラムを追加した場合は削除し、変更した場合は変更前の状態に戻すなど）を記載します。

こうすることで、変更と差し戻しをrakeで制御するのですが、あまりスキーマの変更を容易に出来る仕組みではありません。

ところが、ridgepoleはテーブルの情報を記載したスキーマファイルを読み取り、DBの情報と差異がある部分だけを直接DBに適用することが出来るので変更コストを減らすことが出来ます。

さて、ridgepoleですが、heroku上でも使うことはできるでしょうか？　結論から言うと可能です。

$heroku run ridgepole  -e config/database.yml ...  

$heroku run bash
$ridgepole -e config/database.yml ...  

（9月4日追記）
heroku runから呼び出す場合は、以下のようにクォーテーションで囲むと使えます。

後述のようにrakeタスクを登録する手間を省きたい場合はこちらの方法も可能です。

(dry runの例)

$ heroku run "bundle exec ridgepole -c config/database.yml \
 -E production -f config/Schemafile --apply --dry-run"

herokuでの使い方

便利な方法として、rakeタスクに記述して、rake経由でridgepoleを呼び出すという方法です。

$bundle exec rails g task ridgepole  

で lib/tasks/ridgepole.rake が生成されるので、こちらのページの内容に従って編集します。

【Ruby】【Rails】手間な実行コマンドはRakeタスクに書いて行くようにした。

エクスポートのコマンドはheroku上では意味が無いですが、ローカルで使う分には便利です。

デモ

では実際に変更されるのか試してみます。今回はこちらのrails apiのサンプルを使って、実際にmigrationファイルを生成しないでスキーマ変更ができることを確認してみます。 途中まではサンプル通りに作り、そこからridgepoleによってスキーマを変更するまでを行います。 スキーマ変更はローカル→herokuの順に行います。

因みになぜrails apiかというと、rails5で標準搭載されると以前ginza.rbで話題になった時に軽く触ってみていたので。

サンプル

確認で使ったrailsとrubyのバージョンは以下の通りです。サンプルのrailsのバージョンは3系ですが、4でも問題なく動きます。

ruby 2.2.2 / rails 4.2.3

今回はpostgresを使うので作成時にdオプションを付けます。

$rails-api new todo -d postgresql  

作成されたらGemfileを編集します。

gem 'ridgepole'
group :production do
  gem 'rails_12factor' # herokuで必要
end

後はサンプルの通りに作りこんでいきます。

取り敢えず一旦サンプルの通りに作ったら、herokuにデプロイします。

$heroku login
$heroku create flt-simple-todo
$git init
$git add .
$git commit -m "first commit"
$git remote add heroku https://git.heroku.com/flt-simple-todo.git
$git push heroku master
$heroku run rake db:migrate

余談ですが、最後の heroku run rake db:migrate が好きなherokuのコマンドです（あくまで初回のみ）。

ridepoleによるマイグレート

さて、ここからがridgepoleを使った場合のマイグレーションです。 上で書いたとおりにridgepoleを呼び出すタスクを生成します。

スキーマファイルを生成してみます。

$bundle exec rake ridgepole:export

するとconfig/Schemafileが生成され、以下のような内容になっていると思います。

create_table "tasks", force: :cascade do |t|
  t.string   "name"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
end

ご覧のとおり、テーブルの定義が記載されています。 ではこのファイルを編集し、herokuにデプロイするところまでやってみます。

create_table "tasks", force: :cascade do |t|
  t.string   "name"
  t.string   "title" #<==タイトルを付けてみる
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
end

まずローカルで適用します。

$bundle exec rake ridgepole:apply

本当に増えているのか動作確認も含めて行うので、諸々編集します（追加したカラムを含めて表示編集できるような内容であれば特になんでも構いません）。

こんな感じで反映されていればローカルでは成功です。

では続いて肝心のherokuでの動作確認をします。

その前に以下の注意点が有ります。

注意点

heroku上でridgepoleからDB(PostgreSQL可)に繋ぎに行く場合、config/database.ymlの接続情報が正しく設定されていないと接続できません。

何を当たり前のことを、思われるかもしれませんが、herokuの場合、config/database.ymlの設定を読み飛ばすという仕様になっています。

参考 https://devcenter.heroku.com/articles/rails-database-connection-behavior

The config/database.yml file no longer generated for applications using ActiveRecord 4.1+

接続のための情報は環境変数「DATABASE_URL」から設定します。

DB名　DBNAME
ユーザ名 DBUSER
パスワード DBPASS
DBホスト名 DBHOST
ポート DBPORT

production:
  <<: *default
  database: <%= ENV['DBNAME'] %>
  port: <%= ENV['DBPORT'] %>
  username: <%= ENV['DBUSER'] %>
  host: <%= ENV['DBHOST'] %>
  password: <%= ENV['DBPASS'] %>

(9月4日追記)
環境変数「DATABASE_URL」が設定されている場合は、以下の設定にすることで、特に追加の設定は必要無いみたいです。

production:
  url: <%= ENV['DATABASE_URL'] %>

設定できたらもう一度デプロイします。

git add .
git commit -m "ridgepole deploy"
git push heroku master

ではデプロイ後、ridgepoleによるマイグレートを行います。

heroku run rake ridgepole:apply

こんな表示になっていて上手く動いたら完了です。

お疲れ様でした。

こんにちは、なかやまです。

今日はイベントのお知らせをさせてください！

来週木曜日に、FLECT初の社外勉強会を開催することになりました！

MEANとHerokuを使ったアプリ開発をやりますよ。

受付はDoorkeeperまで。

第1回FlectMeetup MEANスタック＋HerokuでWebサービスを作ろう！

ところでMEANってなんですか？

いつも笑顔な弊社社員にこっそり聞いたところ・・・俺の書いたブログをみてくれ！とのことでした。

HerokuにMEANアプリをデプロイする

 フロントでは市民権得たかなーという感じの子らしいです。

そして注目されているよう！

どんなことしている人だったら馴染みやすいのか聞いてみました。

Node.jsとかjavascriptを使ってる人には、馴染みやすいそうです。

MEETUPでは初心者サポートするよ！

アプリに関しては基本コピペで作れるようにするとのこと。

社員で素振りイベントをやりましたが、Windowsで初めてアプリ開発する場合は、インストールに時間がかかりました。

開発環境をつくるのも一人だと躓いてしまうところが多いかと思いますが、FLECTスタッフがきっちりお手伝いいたします！

今回はNode, git, mongodbは事前インストールしてください。

不安な方は18:30〜インストールのお手伝いしますよ！

第1回FlectMeetup MEANスタック＋HerokuでWebサービスを作ろう！

日時：2015-09-10（木）19:00 - 22:00

場所：東京都中央区京橋 2-13-10 京橋MIDビル 2F 株式会社フレクト

→アクセス

都営浅草線 宝町駅 A2出口 徒歩1分

銀座線 京橋駅徒歩3分
有楽町線 銀座一丁目駅徒歩6分
東京駅 徒歩11分

会社の１階には、ミニストップがあります。

エレベーターで２階に上がってもらうと、すぐそこに入り口があります。

当日はプロジェクターを使って、わいわいやる予定です！

おまちしてます！

こんにちは、徐々に涼しくなってきて活力を取り戻しつつある浅野です。

今日は、Heroku Postgresにまつわる小ネタ

1. Heroku Postgres の Rollbackの意図がわかった気がした
2. 環境変数 DATABASE_URLが変更不可になった

の2つを紹介します。

Heroku Postgres の Rollbackの意図がわかった

Heroku Postgres のロールバックがどんなものかは過去に紹介しております。 ここでも指摘している通り、誤解を招きやすい名前ですよね。

このロールバック、こんな風に理解すれば確かにロールバックだ、と納得するのではという気付きがありました。

これ、 heroku releases:rollback (アプリを過去のリリースバージョンに戻す)とセットで使う想定でロールバックの名前が与えられたのでは、と思ったのです。

「本番環境に意図せぬ状態のアプリをデプロイしてしまった時に、DBスキーマのマイグレーションも動いてしまった」という状況で、 アプリを安定版に戻すには heroku releases:rollback、DBを安定版のスキーマ/データに戻すには、postgresql の rollback機能を使用する と思えば腑に落ちる名前だなと。

と思ったら、公式の Heroku Postgres Rollback に

just as heroku releases:rollback allows you to roll back to an older deployment of your application.

って書いてありました…。

環境変数 DATABASE_URLが変更不可になった

アプリにHeroku Postgresアドオンを追加した時に自動的に付与される環境変数 DATABASE_URL の値が変更できなくなりました。(と同僚のおっぴー先生に教えてもらいました)

DashBoardからこの環境変数の値を変更して保存すると、以下のようなエラーメッセージが表示されます。

複数の Heroku Postgresを使っていて、主となるDB(DATABASE_URLの環境変数で接続できる)を切り替える時にダッシュボードから環境変数を直接変更していたから非常に困る、と思った方にはこちら。 heroku pg:promote コマンドをお使いください。

上記のケースを除くとDATABASE_URLの値を任意の値へ変更できて嬉しいことあるっけ？と思いつつも、変える必要のない値を変更できなくなると一層安心して使えますね。こういう地味な改善、素敵です。

こんにちは、Swift 2.0 と watchOS 2 が気になっている三宅ですが、今回も Node.js についてです。

Node.js のアプリケーションといえば MongoDB というイメージが強いですが、従来の RDB を利用したい場面も出てくると思います。
とくに Heroku では Heroku Postgres がオフィシャルで提供されており、 PGBackups や Fork などの便利な機能を利用することができます。
そこで今回は Node のアプリケーションで RDB を使う際に便利な、次の 3 つのプラグインを紹介したいと思います。

1. Sequelize
2. Sequelize CLI
3. Epilogue

Sequelize

Sequelize は PostgreSQL をはじめ、MySQL や MariaDB、SQLite へのアクセスを提供する Node.js のライブラリです。

sequelize/sequelize

オブジェクトとテーブル間の関連の定義を行う ORM 機能、モデルの定義に基づくテーブルの自動生成、トランザクションなどの機能を提供します。
また、モデルへのアクセスやテーブルの操作などは Promise ベースのメソッドで提供されており、Node のプログラミングスタイルとマッチしていて違和感なく利用することができます。

npm でインストールすることができ、各 DB へアクセスするためのライブラリを合わせてインストールするだけで使い始めることができます。
以下は PostgreSQL で利用する場合のコマンドです。

$ npm install --save sequelize
$ npm install --save pg pg-hstore

開発も活発でドキュメントも詳しく、安心して利用することができると思います。
Seqeulize

Sequelize CLI

継続的な開発やチーム開発などでは、データベースのマイグレーションの管理が重要となってきます。
Sequelize 単体でも定義されたモデルに基づきテーブルを変更する機能は提供されていますが、バージョン管理などを行うことはできません。
sequelize/cli はデータベースへの変更をコードとして定義し、バージョン管理を容易にするためのコマンドラインツールです。

$ npm install -g sequelize-cli

gulp や Grunt と同様に、コマンドを利用するためにグローバルにパッケージをインストールする必要があります。
Heroku などグローバルにインストールできない環境ではローカルにインストールし、node_modules/.bin 以下の実行モジュールを指定してコマンドを実行してください。

Seqeulize CLI では、マイグレーション定義に基づくマイグレーションの実行、モデルの作成と対応するマイグレーション定義の生成などを行う事ができます。

$ seqeulize init

上記のコマンドでモデルを定義するディレクトリや DB 接続の設定を行うファイルが生成され、CLI の機能を利用する準備が整います。

モデルの作成は以下のように行います。

$ sequelize model:create --name User --attributes first_name:string,last_name:string

/models 配下に user.js が作成されるのとともに、/migrations の下にマイグレーションのためのコードが記述されたファイルが生成されます。
そして、以下のコマンドでマイグレーションを実行します。

$ seqeulize db:migrate

DB には自動的にマイグレーションの実行履歴を管理するためのテーブルが作成され、実行されたマイグレーションの履歴が管理されます。
これらのファイルをバージョン管理する事で、データベースも含めアプリケーションを任意のバージョンに戻す事ができ、またアプリケーションのデプロイ環境の切り替えが容易になります。

Epilogue

dchester/epilogue は Express や Restify のアプリケーションに対し、 Seqeulize のモデルに基づく REST API を作成するためのライブラリです。

var epilogue = require('epilogue');

epilogue.initialize({
  app: app,
  seqeulize: seqeulize
});

var userResource = epilogue.resource({
  model: User,
  endpoint: ['/users', '/users/:id']
});

上記のコードで、Seqeulize で定義した User の REST API が作成されます。
モデルとエンドポイントの指定が必要となるため、モデルの数が多くなると煩雑になってしまうのですが定型的なエンドポイントの名前で構わないのであれば、以下のコードで一気に作成する事ができます。

// 英単語の複数形を取得する事ができる npm ライブラリ
var plural = require('plural');

// Seqeulize が作成した models ディレクトリへのパス
var db = require('../models');

// Resource オブジェクトを保持するオブジェクト
var resources = {};

Object.keys(db.sequelize.models).forEach(function(modelName) {
  var apiName = plural(modelName.toLowerCase());
  var resource = epilogue.resource({
    model: db[modelName],
    endpoints: ['/api/' + apiName, '/api/' + apiName + '/:id']
  });
  resources[modelName] = resource;
});

Seqeulize によって作成される models/index.js は定義済みのデータベース接続情報によって作成された Seqeulize のオブジェクトを保持するオブジェクトをエクスポートしています。
seqeulize オブジェクトは定義されたモデルをモデル名をキーとした models オブジェクトを保持しているので、そのオブジェクトをもとに REST API を作成します。
上記の例では、モデル名を小文字にして複数形にした上で、/api/{models} の形で REST API を作成しています。

開発の初期段階などで、とりあえずモデルの CRUD を行うための API を用意したいときなどには有効かと思います。

今回は Node で RDB を利用する際に便利なライブラリを紹介しました。
MongoDB と mongoose の組み合わせはよく紹介されていますが、もちろん、RDB も利用することができます。
今のプロジェクトでは Express + Seqeulize + Heroku Postgres の組み合わせで開発を進めています。
その際に気づいたことがあれば、またこの場で共有できればと思います。

こんにちは、なかやまです。

前回に引き続きキャラクターを使って、Herokuにデプロイするところをお絵かきしてみたいと思います！

前回（【Herokuお絵かき】Herokuってな～に？）、

じーちゃんにアプリを作るならHerokuがおすすめだよと言われました。

#2.Herokuにデプロイする

たろうはPlay Framework(以下play)をつかってデプロイすることにチャレンジするようです。

がんばれたろう！

じーちゃんの教えにより、まずはローカル環境でちょっとだけ動くプログラムを書いてみることになりました。

やる気いっぱいのたろう。

・ローカル環境を作る

Macをつかって開発環境をつくるようです。PVM(Play Version Manager)入れて、playをインストールして、、Eclipseの準備も整ったようですよ！

ローカル環境を作るのも結構大変。

たろうがんばれー！

playをEclipseの設定ファイルを生成する

https://www.playframework.com/documentation/ja/1.2.x/ide

・gitの設定

ローカル環境でプログラムが動いたら、次はgitにコミットします。

・Herokuの設定

Herokuアカウントの作成と、Heroku Toolbeltのインストールを行いましょう。

・Herokuにデプロイする(git push heroku master)

Herokuにデプロイしますよ！いけーー！

Herokuではgit pushを確認すると、Dynoに展開するためのslugという塊を作ってくれます。

あわせてgitにコミットされたファイルを見ながら、どの言語・フレームワークを使っているから、このビルドパックを使う、ということもHerokuが判断してくれます。

playだと「/conf/application.conf」ファイルがあるのでplayだね!となるわけです。

ビルドパックを自作することもできるそうです。

参考）HerokuのSlugとその動き

指定されたライブラリのダウンロードなど、コンパイルが行われます。

コンパイルに成功するとslugという塊ができます。

このslugですが、サイズがあまりにも大きい場合にはデプロイできないので注意しましょう。

すばやく展開するためにも、サイズは小さいほうがよいです。

https://devcenter.heroku.com/articles/slug-compiler#slug-size

slugの作成に成功すると、指定された数のDynoが起動します。

100Dynoだといっぱいです。

ローカル環境のモジュールをデプロイできたようですね。

ですが、playのバージョンが1.3でデプロイされてしまったようです。。

ローカル環境では1.2で動いていたのに、なぜだろう？

ビルドのログはActivityタグから確認ができますよ。

ビルドパックの説明をみると、定義ファイルにバージョンを指定しない場合はデフォルトの1.3が指定されると書いてました。なるほどなるほど。

設定ファイル（dependencies.yml ）にバージョンきちんとかいてみましょう。

https://github.com/heroku/heroku-buildpack-play

モジュールに変更があった場合は、再度gitのコミットと、git push heroku masterをしましょう！

・heroku run bash

run bashコマンドを使うとDynoにアクセスできます。

ここではインストールされたplayのバージョンを聞いてみました。

正しいバージョンでインストールできたようです！よかったねたろう！

・おたより

そういえば、おたよりが届いてました！２通目です！ありがたや。

前回のHeroku説明について「あってますよ」というメッセージをいただきました。

ありがとうございますー。

フィードバックいただけるとうれしいです。m(_ _)m

おたより（なかやま直通）

はい、どうも。 中2日、2連投のおっぴーです。

タイトルですべてを要旨は全て言い尽くしておりますが、HerokuでもっともパワフルなDynoであるPerformanceDyno、いわゆるPXDynoのパフォーマンスが向上しました。

もともと6GBだったメモリが14GB、ディスクもSSDになったということです。

さらに嬉しいのはお値段が据え置き（っぽい）ということろで、無償のアップグレードと考えられます。

Herokuを利用しているとダッシュボードなど、少しずつ改善されている部分もあるのですが、こうした大きなアップグレードを聞くとやはりうれしいですね。

Herokuの公式発表は下記のURLで見られます。

https://devcenter.heroku.com/changelog-items/690

すでにPXDynoを利用しているユーザーは、72時間以内にあらたなPXDynoに切り替わるようです。 こうしたアップグレードが簡単なところもPaaSの良い所ですね。

「とくに2XDynoとPXDynoの間を埋める性能の新Dynoの登場があるとうれしい」（弊社、浅野）という意見もありますので、今後もさらなる進化を期待しています。

参考情報

• Dyno Typeの性能比較表

はい、どうも。 最近の朝食はもっぱらクリーム玄米ブランのおっぴーです。 さくさくと食べごたえがあり、冷たいアイスコーヒーとの相性抜群。 夏バテや朝の忙しから、朝食をついつい抜いてしまうあなたにおすすめの組み合わせです。

ということで、今回はおすすめのHeroku謹製のアドオンHerokuConnectのご紹介です。 約1年前からGAとなっているアドオンであり、SalesforceとHerokuのデータ連携を行えるという便利さは理解されているものの、なかなか情報を手に入れることが難しい印象ですが、今年の2月からdemoというプラン名で無料で使えるようになっておりました。

また、最近はHerokuConnectで利用するSalesforceのAPIのCall数は利用回数には加算されないという発表もされるなど、さらにHerokuとSalesforceの親和性を高めてくれる、個人的にはとても注目しているアドオンです。

今回は基本的な使い方ついて、ご紹介したいと思います。

作業自体は簡単なものの、かなり（がんばって）丁寧に記事を書いた結果、少々長くなってしまったので、先に3行で結論を。

• HerokuPostgresにデータ連携をするSalesforceのオブジェクトのテーブルが作られます
• SaleforceとHerokuPostgresの双方向のデータ登録、更新が可能です
• 上記の設定はとっても簡単です

herokuアプリの作成

まずは、herokuアプリを作ります。 今回は、heroku-connect-flect-demoという名前のアプリを作成します。 ちなみに、herokuアプリ名は世界中で一意である必要があるので、実際に試される際は適宜、変更してください。

heroku create heroku-connect-flect-demo

HerokuConnectの追加

さて次は、HerokuConnectを追加します。 今回は無料版として、demoというプラン名を指定して登録をします。

heroku addons:create herokuconnect:demo --app heroku-connect-flect-demo

追加に成功すると、下記のようなメッセージが表示されます。

Creating smiling-stably-8670... done, (free)
Adding smiling-stably-8670 to heroku-connect-flect-demo... done
Setting HEROKUCONNECT_SCHEMA, HEROKUCONNECT_URL and restarting heroku-connect-flect-demo... done, v3
Use 'heroku addons:open herokuconnect' to finish setup
Use `heroku addons:docs herokuconnect` to view documentation.

表示されているコマンドを実行すると、HerokuConnectの設定画面が開かれます。

heroku addons:open herokuconnect --app heroku-connect-flect-demo

おっと、まずはHerokuPostgresを追加しないといけませんね。

ボタンを押して追加もできますが、HerokuPostgresをコマンドから追加しましょう。

heroku addons:create heroku-postgresql:hobby-dev --app heroku-connect-flect-demo

追加が完了したら、登録中の画面の「Refresh」を押して登録を続けましょう。

画面がリフレッシュされると追加したHerokuPostgresの情報が表示されます。

その下に、Enter schema nameとありますがこれはSalesforceのオブジェクトの情報をHerokuPostgres上で管理するために作成されるSchema名を入力し、決定する項目です。 今回はそのまま「salesforce」にしておきましょう。 では、次の設定画面に進むため「Next」ボタンをクリックしましょう。

Saleforceアカウントの作成

次に進むとSalesforceアカウントとの接続設定を行う画面が表示されます。 が、そのまえにSalesforceアカウントを作成し、連携をおこなうカスタムオブジェクトを作成しましょう。

今回は、無料で利用できるSalesforceのデベロッパーアカウントを作成します。 まずは、https://developer.salesforce.comに接続し、「サインアップ」のボタンをクリックします。

つぎに必要情報を入力し、契約内容に同意を示すチェックをいれたら、「サインアップ」ボタンをクリックします。

下記の画面が表示された登録は完了です。 表示されているメッセージに従い、入力したメールアドレスにメールが届いているか確認し、アクティベーションしましょう。

連携用(テスト用)のカスタムオブジェクトの作成

作成したSalesforceアカウントにログインし、カスタムオブジェクトを作成します。 画面右上の「設定」をクリックし、左端に表示される項目から「作成」→「オブジェクト」をクリックします。

その後、「新規カスタムオブジェクト」をクリックすると独自のオブジェクトが作成できます。 ちなみにSalesforceに馴染みのない方に大雑把な説明をしますと、SalesforceのオブジェクトはRelationalDatabaseでいうところのTableとほぼ同義のものと捉えていただくとわかりやすいかと思います。

今回はHerokuConnectのテストに利用するオブジェクトのため、単純にHerokuConnectTestという名称でオブジェクトを作成します。 必要な情報を入力して、「保存」をクリックするとカスタムオブジェクトの作成は完了します。

次に、作成したカスタムオブジェクトのHerokuConnectTestにカスタム項目を追加します。 カスタム項目を追加するには、「カスタム項目&リレーション」で「新規」をクリックします。

項目の属性としてSalesforceではさまざま用途に合わせて選択できますが、今回は単純にテキストを選択します。

次に項目名と文字列の桁数を定義します。 今回は「testText」という項目名で 最長の文字列長の255文字で定義しましょう。

次は、項目にたいする権限の設定を行います。 Salesforceには、「プロファイル」というユーザーをグループわけを行う概念があり、この「プロファイル」単位に今回、作成した項目についての「閲覧も修正(登録含む)もできない」、「閲覧のみ可能」、「閲覧も修正(登録含む)も可能」の3つから選択する画面です。

今回は、ブログ用のデモなのですべてのプロファイルにたいして「閲覧も修正(登録含む)も可能」にしていますが、実運用においては、用途に合わせて慎重に決める必要がある項目です。

最後に、作成している「testText」項目をどのページに表示するか、という選択を行います。 ここでは「HerokuConnectTest」オブジェクトを作成した際に、同時に自動で作成されるページに表示することを選択します。 選択しない場合は、どこにも表示されず値の登録などもできないので、このまま表示されるように設定し、登録を完了します。

以上でカスタムオブジェクトの作成とカスタム項目の追加が完了です。 さて、HerokuConnectの設定にもどりましょう！といいたのですが、もう少しだけSalesforceで作業を行います。

カスタムタブの作成

カスタムオブジェクトを作成し、そのオブジェクトにたいしてカスタム項目を追加しただけでは、Salesforce上でオブジェクトの編集はできません。

そのためにはカスタムタブ、という独自のタブを作成する必要があります。 画面の左から「作成」→「タブ」をクリックします。

表示された画面にはいくつかの「タブ」についての種類が表示されます。 今回は「カスタムオブジェクト」のタブを作成するため、「カスタムタブ」の新規作成を行います。 カスタムタブの左に表示されている「新規」をクリックしましょう。

次にタブの詳細を選択します。 色々入力する必要はありますが、今回のデモで重要なのはオブジェクトの欄で上記で作成した「HerokuConnectTest」を選択することです。 選択をし、「タブスタイル」も適当に選択したら「次へ」をクリックして先に進みましょう。

ここでもカスタム項目と同様にプロファイルにたいしてタブの操作を可能にするかどうかの選択を行う画面が表示されます。 ここもカスタム項目と同様にすべてのプロファイルにたいして操作を許可します。

最後に作成したカスタムタブをどのアプリケーションから利用できるようにするか、を選択します。 このアプリケーションという概念ですが、これはSalesforceが提供する様々な機能へアクセスをおこなうためのタブをグループ分けするものと考えて良いと思います。 添付の画像では、「セールス」や「コールセンター」などの名称のアプリケーションがご確認いただけると思います。 これらは「標準アプリケーション」と呼ばれるもので、Salesforceが標準で提供するアプリケーションです。

今回は、これらのどのアプリケーションにたいしても、作成しているカスタムタブが追加されて問題はないので、すべてのアプリケーションから利用可能にして登録します。 ということで、「保存」をクリックして作成を完了します。

完了すると、カスタムタブが追加されているのが確認できます。

設定は以上で完了です。 が、ついでに「HerokuConnectTest」オブジェクトのレコードが作成できるか、確認してみましょう。

追加された「HerokuConnectTest」タブをクリックすると、画面が切り替わり「新規」というレコードを作成するためのボタンが表示されますので、そのボタンをクリックしましょう。

入力項目に適当な値を入力し、「保存」をクリックするとレコードの登録は完了です。 ちなみに「HerokuConnectTest」という作成した覚えのない項目が必須入力の項目として存在していますが、これは、オブジェクトを作成するときに自動で作成される項目です。 一意の値である必要もなく、レコードのID（SalesforceはオブジェクトIDと呼びます）は別に生成されて保存されているため、IDのような存在でもありません。 検索結果の表示などで利用される値です。

以上で、Salesforceの設定も完了しました。

HerokuConnectの設定

Salesforceへの接続設定

さて、HerokuConnectの設定の続きです。 HerokuConnectからSalesforceへの接続を行うための認証の途中でしたね。 まずは、接続先にSalesforceの環境を選択しましょう。 「Production」、「Sandbox」、「CustomDomain」と3つの選択肢が表示されますが、今回は「Production」を選択します。 ちなみにSandboxはSalesforceのステージング環境、CustomDomainはSalesforceを独自ドメインで運用している際にもちいる選択肢です。

選択したら右上の「Authorize」ボタンをクリックしましょう。

「Authorize」をクリックするとSalesforceへの接続認証を行うために、ユーザー名とパスワードの入力を求められます。 HerokuConnectで接続したいSalesforceアカウントのユーザー名とパスワードを登録し、ログインボタンをクリックします。

HerokuConnectにたいしてSalesforceへの接続をふくめた権限を与えてよいか、が問われますので、「許可」ボタンをクリックしましょう。

認証が完了すると、HerokuConnectのダッシュボードが表示され、HerokuConnectを利用して接続しているHerokuのアプリケーション名とSalesforceのユーザー名が確認できます。

さて、いよいよSalesforceとHerokuPostgresの接続、Mappingを行いましょう。 画面左下にある「Create Mapping」をクリックすると画面が設定画面へと切り替わります。

画面にはズラッとSalesforceのスタンダードオブジェクト（Salesforceが標準で提供するオブジェクト）とカスタムオブジェクトが並びます。 お目当てのオブジェクト名を、画面の右にある検索ペインを利用して絞り込むと簡単に探せます。 お目当てのオブジェクト、今回は上記で作成したHerokuConnectTestオブジェクトを接続する対象としてクリックします。

ReadOnlyModeとRead / Write Mode

表示されている画面がHerokuConnectのメインとも言える画面です。 SalesforceのオブジェクトとHerokuPostgresのTableの結びつけやデータの連携の設定を行います。

画面を眺めつつ、すこしHerokuConnectと考え方と操作の結びつきについて説明をします。 HerokuConnectにはReadOnlyModeとRead/WriteModeという2つの概念があります。 Salesforce→Herokuのデータ反映をReadOnlyModeと呼び、それにくわえてHeroku→Salesforceのデータ反映を行うことをRead/WriteModeと呼びます。

ですので、これらのモードは、モードそのものを指定するというよりは、Heroku→Salesforceのデータ反映を行うことを選択する(画面の「Write to Salesfore any updates to your database.」にチェックをつける）と、Read/WriteModeを選択したことになるのです。

画面では、「Write to Salesfore any updates to your database.」にチェックをつけているため、Read/WriteModeの選択をしています。

また、前後しますがSalesforceからHerokuPostgres（画面では「Salesforce→Database」と表示されていますが）の設定では、ポーリングをするか、Streaming APIを利用するかのどちらかが選択できます。 ポーリングはHerokuからSalesforceへ、Salesforce側のオブジェクトのレコードに変更がないか問い合わせを行うモードで、Streaming APIはSalesforceのオブジェクトに変更があった場合、即時でHerokuPostgresにデータを連携させる動きを行います。 ドキュメント（少々、古い気がするのですが。。。）では、Streaming API の利用を推奨しているので今回は、こちらを選択しています。

最後に、連携する項目についての選択を行います。 これについては説明は不要でしょう。連携が必要な項目にチェックをつけましょう。 今回は、上記で作成した「testText」と標準項目の「Name」を選択しています。

以上の設定をおこなったのち、「Save」をクリックするとHeorkuConnectの設定は完了です。

完了するとマッピングの情報に行が追加されていることが確認できます。 また、余談ですがこの画面ではSalesforcのAPIの利用量も確認できます。 が、APIの利用量については気にしないで良いはずなので、今後はなくなるかもしれませんね。

以上で、HerokuConnectを利用したSalesforceとHerokuPostgresの接続作業は完了です。

少し時間がたつと設定内容にしたがってSalesforceからHerokuPostgresにデータ連携がおこなれ、その結果がグラフに表示されているのがわかります。

HerokuPostgresの確認

さてさてこの状態でHerokuPostgresはどのような変化が起きているでしょうか。

まずはHerokuPostgresに接続してみましょう。

heroku pg:psql --app heroku-connect-flect-demo DATABASE_URL

接続が完了したら、上記で作成した「salesforce」Schemaの状態を見てみましょう。

\dt salesforce.*;

上記のコマンドを打つと、Schemaで定義されているTableの一覧が表示されます。 複数のテーブルがあるのですが、今回、詳細な説明は割愛させていただきます。 注目は最下部にある「herokuconnecttest__c」テーブルです。 HerokuConnectでデータ連携の設定を行うと、SalesforceのAPI名がすべて小文字で定義されたテーブルが作成されるのですね。

では、その「herokuconnecttest__c」テーブルにデータが連携さているかを見てみましょう。

select * from salesforce.herokuconnecttest__c;

上記をコマンドを実行すると下記のように連携されたデータが見ることできました。

ということで、無事、HerokuConnectのダッシュボードで確認できたように、データがHerokuPostgresに反映されていることが確認できました。

ほんとにお手軽

このブログを書くにあたっては、いちいちキャプチャをとっていたので時間がかかったのですが、HerokuもしくはSalesforceのどちらかの操作に慣れている方でであれば、この作業は30分もかからず完了できるはずです。

それだけお手軽にSalesforceとHerokuのアプリケーションでデータが活用できるとなると俄然、利用の検討の余地が出てくるというものです。

さらに、大事なことなので二回言います。 HerokuConnectによるSalesforceのAPIコール数は、APIの利用上限数には加算されません。 一度、連携させてしまえば利用制限を気にすることなく、CRMのデータを活かしたWebサービスの構築も可能になってしまいます。

今度は、といいつつなかなか続編を書かないのですが、HerokuConnectについてはさらに、詳細の利用方法を現在まとめております。

次回の更新では、更に踏み込んだ操作や動き、実際の利用の際の考慮点についてなども書いてみたいと思います。

Wercker v2でHerokuっぽい環境を作ってテストを動かす

こんにちは、浅野です。

今日は、Dockerに対応したWercker v2(Ewok)でHeroku+Postgresqlっぽい環境を作ってテストを実行するまでの手順を紹介します。

言語は相変わらずJavaです。(Java8+Gradle)

Werckerとは

Werckerは、TravisCIやCircleCIのようなCIサービスです。 無償プランでGithubのPrivateリポジトリがビルドできるため、Flectではよく使用されています。

Wercker v2

元々はBoxと呼ばれる独自の実行環境を使っていたのですが、V2からは実行環境にDockerHubのイメージを指定するようになっています。

テストを実行するDockerイメージを作る

HerokuがDockerをサポートしたこともあり、DockerHub上にHeroku謹製のcedarイメージがあります。 これがそのまま使えるかと期待したものの、上手くいきませんでした。

原因は、heroku/cedar:14 に標準インストールされているJDKが 1.7.0_79 だったためです。 なので、 heroku/cedar:14 をベースにJDK8入りのイメージを作ります。

こんなDockerfileで作ったイメージをDockerHubへ登録します。 (DockerHubのここのタグ0.2にこれで作ったDockerイメージが置いてあります)

FROM heroku/cedar:14

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update
RUN apt-get -y install software-properties-common python-software-properties
RUN add-apt-repository -y ppa:openjdk-r/ppa
RUN apt-get update
RUN apt-get -y install openjdk-8-jdk

RUN update-alternatives --set java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
RUN update-alternatives --set javac /usr/lib/jvm/java-8-openjdk-amd64/bin/javac

wercker.ymlを書く

ここにテストを実行するための環境・テストの実行ステップを定義します。

ベースイメージを指定する

先ほどDockerHubにUpしたDockerイメージをBoxに指定します。

box: yuasano/heroku:0.2

Postgresqlを追加する

次にHeroku Postgresqlアドオン相当のものを追加します。Werckerでは外部サービスを追加する時は serviceを使います。 これは以下のようになります。 POSTGRES_USERは省略可で、省略した場合はpostgresユーザが作られます。

services:
   - id: postgres
     env:
       POSTGRES_PASSWORD: YOUR_PASSWORD
       POSTGRES_USER: YOUR_NAME

詳しくは公式ドキュメントを参照してください。

DB接続用の環境変数 DATABASE_URLを定義する

次に、HerokuPostgresで追加される環境変数DATABASE_URLを定義します。 これは、実行時に動的に決まる値なので、以下の環境変数群(どうもpostgresqlのDockerイメージがこういう環境変数を使うよう)を使って生成します。

POSTGRES_ENV_POSTGRES_USER=YOUR_NAME
POSTGRES_ENV_POSTGRES_PASSWORD=YOUR_PASSWORD
POSTGRES_PORT_5432_TCP_PORT=5432
POSTGRES_PORT_5432_TCP_ADDR=172.XX.X.XX

この値を組み合わせてDATABASE_URLを定義する手続きを、buildステップの最初に記述します。

build:
    steps:
        - script:
            name: set DATABASE_URL env
            code: |
                export DATABASE_URL="postgresql://${POSTGRES_ENV_POSTGRES_USER}:${POSTGRES_ENV_POSTGRES_PASSWORD}@${POSTGRES_PORT_5432_TCP_ADDR}:${POSTGRES_PORT_5432_TCP_PORT}/postgres"

Gradleのテストを実行するステップを作る

次に、 set DATABASE_URL envスクリプトの後にGradleのテストタスクを実行するステップを追加します。

- script:
    name: run test
    code: |
        ./gradlew test

これでWerckerV2の上で、Heroku+Postgresqlに近い環境でJava8+Gradleのテストが実行できるようになりました。

最終的に出来上がった wercker.yml は以下のようになります。

box: yuasano/heroku:0.2

services:
   - id: postgres
     env:
       POSTGRES_PASSWORD: mypage
       POSTGRES_USER: mypage

build:
    steps:
        - script:
            name: set DATABASE_URL env
            code: |
                export DATABASE_URL="postgresql://${POSTGRES_ENV_POSTGRES_USER}:${POSTGRES_ENV_POSTGRES_PASSWORD}@${POSTGRES_PORT_5432_TCP_ADDR}:${POSTGRES_PORT_5432_TCP_PORT}/postgres"
        - script:
            name: run test
            code: |
                ./gradlew test

Heroku謹製のcedarイメージがDockerHubに置かれて、よりHeroku環境に近い環境でテストができるのは安心ですね。(Cedar14がベータの頃にHerokuにデプロイした時だけ動かない機能があって、原因がCedar14側だった経験があるので...)