こんにちは、三宅です。
今回は、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分

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

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

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

おまちしてます！