TeamSpirit Developer Blog

チームスピリット開発者のブログ

Lightning Design Systemをカスタムビルドする

f:id:ts-yokouchi:20170228141831j:plain

みなさまこんにちは id:ts-yokouchi です。
先週末はSwitchを予約し損ねており憂鬱でした。(この、ゼルダやりたさ)

むしゃくしゃしたのでブログを書くことにしました。
みなさんバリッバリCSS書いていますか?え?カイテル?嬉しいです。

弊社はSalesforce Platformで動作するプロダクトを開発しており、
Lightning Design System(以下LDS) を利用したプロダクト開発を進めております。

LDSはフルスタックなUIフレームワークとしての側面があり、アプリケーション構築に
必要な要素は網羅されていますが、細かいカスタマイズは必要となってくるところ。

今回はLDSをプロダクトに合わせてカスタムビルドする方法をまとめます。

戦略

LDS自体はSassで記述されており、各UIのパラメータ(色やマージン等)は変数で管理されています。
今回は変数をオーバーライドすることにより、カスタムビルドをおこないます。

なお、参考として以下のリポジトリにビルド環境を作っておきましたのでどうぞ。

Design Token

f:id:ts-yokouchi:20170228190846p:plain

引用: https://www.lightningdesignsystem.com/design-tokens/

さてLDSを構成する変数ですが、Design Tokenという名称がついております。
Design Tokenには以下の要素が含まれており、カスタマイズ可能となっております。

  • color
    • text color
    • background color
  • font
    • family
    • weight
    • size
  • opacity
  • line height
  • spacing ( margin, padding )
  • radius ( 角丸 )
  • size ( weight, height )
  • shadow
  • time ( animation )
  • media query ( responsive )
  • z-index

Design Token自体はSassにロックインされて定義されている概念ではなく、 Salesforceプラットフォーム上で別途利用することが可能です。詳細はドキュメントをみてください。

おそらくSalesforce上でカスタマイズして利用する方が正攻法な気もしますが、
今回はローカル開発などを想定して Design TokenをSass上で編集し、LDSをローカルにカスタマイズビルドする方法をご紹介します。

ビルド

やっていきましょう。

(具体的なコマンドなどはリポジトリのREADMEをみてください。)

ディレクトリ構造

.
├── node_modules
├── build
└── src
      ├── _design_token.scss
      └── style.scss
gulpfile.js
package.json

srcnode_modules をgulpに通して build へコンパイルします

Sass

style.scss を少し覗いてみましょう。

@charset 'UTF-8';

//
// Customize variables
//
@import 'design_token';

//
// Import Lightning Design System
//
@import '../node_modules/@salesforce-ux/design-system/scss/index';

design_token には前述のDesign Tokenの設定を、その後でnpmからインストールしたLDSを読み込んでいます。
LDS側のDesign Tokenは下記のような記述になっており、先読みして上書き が可能です。

$mq-x-small: 320px !default;

!default は未定義であれば変数を定義するという意味です。

Gulp設定

var gulp = require('gulp');
var runSequence = require('run-sequence');
var clean = require('gulp-clean');
var sass = require('gulp-sass');

gulp.task('clean', function(){
  return gulp.src(['build/**/*', '**/*.gitkeep'])
    .pipe(clean());
});

gulp.task('copy', function(){
  return gulp.src(['node_modules/@salesforce-ux/design-system/assets/**/*', '!node_modules/@salesforce-ux/design-system/assets/styles/**/*'])
    .pipe(gulp.dest('./build/assets'))
});

gulp.task('sass', function (){
  return gulp.src('src/**/*.scss')
    .pipe(sass().on('error', sass.logError))
    .pipe(gulp.dest('./build/assets/styles'));
});

gulp.task('default', function(){
  runSequence(
    'clean',
    ['copy', 'sass']
  );
})

こちらは特筆して書くことはありません、普通の設定ですね。 copy タスクの中で、node_modules/@salesforce-ux 内にあるアセットファイル群から CSSを除いてアイコンやフォントなどを取り出しています。

Bootstrapとの違い

さて、Lightning Design Systemは Design System の名前からもわかるように、Salesforceプラットフォームに 特化したものです。 高い汎用性を持っているBootstrapとは若干毛色が違います。 あくまでBootstrapはCSSフレームワークなのです。

ドキュメント

第一にLDSはドキュメントが非常に豊富です。Getting Start には Developer向け、デザイナー向けの二つの入口が準備されており、それぞれコーディングスタイルからデザイン方針まで非常に手厚い解説がなされています。

このドキュメントを一通り読むだけで、LDSと調和したUIを構築するために必要な知識を手法と思想の両側面から網羅できるのではないでしょうか。

設計思想

また、あるドメインに特化した姿勢はCSSの設計にも表れています。

f:id:ts-yokouchi:20170227235635p:plain

http://getbootstrap.com/css/#buttons

写真はBootstrap 4 のドキュメントより引用していきました。

.btn-primary (色によって表されるボタンの役割)と disabled (ボタンの状態) によって、 最も重要ではあるが、操作が現在有効でないボタン の視覚表現が可能になっています。

役割と状態の組みあわせは自由で、例えば .btn-success という役割と disabled を併用することができ、 OOCSS(オブジェクト指向CSS)の恩恵をフルに得ることができます。

ですがLDSでは、似たような組み合わせの .slds-button--successdisabled は併用することができません。
もちろん記述自体は可能ですが視覚表現に表れてこないのです。

そもそも success の使い道としては、ある処理の実行結果が成功した時に、ユーザーに確認のOKを求める場合などでしょうか?
disabledが必要となるケースはあまり多くなさそうですね。

こういった思い切りの良さが反映されているデザインなのだと私は推測します。

まとめ

さて、ビルド方法および中身の設計について簡単についてご紹介したLDS、 徹底的にSalesforce wayに 乗りに行く 場合は非常に真価を発揮するシステムだと感じました。

LDSを利用する場合は、デザインシステムから逆算して全体を設計していくフローを踏んでみてもいいかもしれません。
Salesforce上のユーザー体験を維持することは極めて容易になると思います。
制限を受け入れることである程度の品質は担保されるはずです。

次のプロジェクトではLDSをバリバッリ使うことを検討してみてはいかがでしょうか。

UIは任せろー

    ∧_∧
   (゚ω゚ )
バリバリC□ lヽlヽ
   /  (   )
   (ノ ̄と  |
      しーJ
  Nice Consistency(すてきな一貫性)!

ここまで記事を書いて CSSをほとんど書いていない という事実に気づいた私です。シクシク

宣伝

来たる3月14日19時より、「TeamSpirit × Salesforce DG Meetup 」と題しまして勉強会を開催することになりました。 今回はなんとセールスフォース・ドットコムのCTO及川氏を迎え、濃いお話が聞ける期待大です!

参加申し込みは下記connpassから行っておりますのでお待ちしております。

teamspirit.connpass.com

Salesforce Developers Meetup #14 に参加しました

こんにちは、エンジニアの山崎 id:dackdive です。
最近は「あいつは JavaScript エンジニア」「JIRA おじさん」などと揶揄されています。

さて、前回の新年会に引き続き、今年 2 回目の meetup が 3/1(水) に開催されました。
いつも LT 登壇するのにいっぱいいっぱいで参加レポを書くことができていなかったのですが、今回は純粋な参加者として楽しんできたので
内容を簡単にブログで紹介しようと思います。

今回はいつものリリースノート輪読会に加え、技術セッションという形での発表が2つもあってどちらも非常に興味深かったです。

リリースノート輪読

遅刻しちゃったので前半聞けず、印象に残っているところをいくつか。

API まわり

フレクトさんチームから Chatter API、REST API、Bulk & Tooling API の紹介。 普段の業務では API を直接叩くことがないので、このへんの動向をさらっとおさらいできるのは助かります。
個人的には REST API の Composite リソース が便利そうで気になりました。

スライド資料はこちら。 Spring'17リリースノート輪読会 API By フレクト

Lightning Component

ここは印象の残ったことを箇条書きで。

  • Locker Service、公式ブログ のコメント欄が非常に盛り上がっているみたい
  • Lightning Data Service は引き続き開発者プレビュー。Apex なしでデータ操作できるのは簡単なアプリケーションには良さそう
  • エラーメッセージがわかりやすくなり、デバッグしやすくなった(リリースノート
  • <lightning:avatar> など、基本コンポーネントも充実してきた
  • 動的選択リストでアプリケーションビルダーの選択リストにApex経由で取得した値をセットできる(リリースノート

技術系セッション①Locker Service の現状

資料はこちら。
http://mino0123.github.io/slides/20170301-meetup.html#/

Locker Service とは何か、どういう仕組みになっているのか、という説明から現在の動向まで詳しく紹介いただき勉強になりました。
最後、「結局 Locker Service は使えるのか」という問いの答えが「微妙。」だったのは非常に説得力があります。。。

フルスクラッチで JS を書く分には問題ないかもしれないが、React など 3rd Party ライブラリを使おうとすると依然として問題は起きそう、またそれらのライブラリの最新のバージョンにどこまで追随してサポートしてくれるのか、が懸念ということですね。

技術系セッション②Apex/Visualforce のセキュリティ診断ツールについて

Salesforce のセキュリティチームのマラットさんという方が登壇してくださいました。
PMD Apex というツールを使って Apex や Visualforce の脆弱性をローカルで検出する方法を、デモを交えて紹介。
PMD 自体は Salesforce に依存しないコードの静的解析ツールで、サポートしている言語の一つとして Apex がある、という感じです)

ここで言う脆弱性とはたとえば、

public class MyClass {
}

のように with sharing または without sharing キーワードのないクラスだったりとか、
FLS チェックしない状態でのオブジェクトの CRUD 処理などを例として挙げてました。

その流れで

というのは知らなかったので勉強になりました。

またデモでは、Atom (エディタ)と PMD Apex を組み合わせ、エディタ上にリアルタイムでチェックしていて
これは ESLint っぽくて便利だなと思いました。
(写真撮っておけばよかった)

LT & 懇親会

懇親会では、ちょうど当日 Salesforce MVP に選ばれた弊社エンジニア倉谷のちょっとしたお祝いムードに。 食事もいつものピザではなく寿司です。

f:id:dackdive:20170301203637j:plain:w320

お祝いの シャンパン スパークリングワインを手にする倉谷。
おめでとうございます!

f:id:dackdive:20170301203506j:plain:w320

そんな倉谷の LT はまさかのマラットさんの PMD Apex ともろかぶり、、、
ということでかつてない疾走感での LT となりました。

資料はこちら。

マラットさんは Atom でしたが、LT では Visual Studio Code のプラグインの紹介もしていました。

と思ったらそれっぽいのありました。
https://github.com/vim-scripts/pmd.vim/blob/master/plugin/pmd.vim

おわりに

というわけでセッション内容、懇親会ともにいつもよりちょっとだけ特別感のある今回の meetup でした。
次回は何か LT で登壇できるよう今からネタを探そうと思います。

また、今月 3/14(水) に弊社と Developer Group の合同イベントを開催します。

本日より募集開始してますので、興味を持たれた方はぜひご参加下さい。

あともくもく会も今月のどこかで開催したいねーという話をしてまして、詳細は Tokyo Salesforce Developer Group の Meetup グループ でご案内すると思いますので、お楽しみに。

思い立ったら即実行、ランチ勉強会をおこないました。

f:id:ts-yokouchi:20170301145316j:plain

みなさまこんにちは

フロントエンドエンジニアの 横内です。 id:ts-yokouchi

突発ランチ勉強会が弊社で開催されました。

デイリーミーティングにて先日行われたInside Frontendの録画を見よう!という声が上がりまして、有志を募ってゆる〜くランチ勉強会を実施することになりました。

f:id:ts-yokouchi:20170301145330j:plain

発起人 id:dackdive の美味しそうなお弁当をご査収ください。

動画を流していた最中はみなさん食事をとりながら動画にじっと集中していました。 無言のランチ…ちょっと周りからしたら異様な光景かもしれません(笑)

動画を見た後は発表にでてきた技術の深堀りや、弊社開発の現場と比較など、 活発に議論をかわしました。

仕事とは違った場所で技術を語らうのはとても新鮮でした。
来週の開催も期待しています!

チームスピリットではランチにワイワイ技術の話ができるエンジニアを募集しています。

それでは!

2/9開催 CI/CD NIGHTレポート!

f:id:ts-yokouchi:20170213102412j:plain

みなさま、こんにちは
2月より株式会社チームスピリットにJOINしました id:ts-yokouchi です。

弊社では一般公開のエンジニア向け勉強会を不定期で開催しております。 2/9にトレタさん、一休さんと CI/CD をテーマに共催の勉強会を開催させていただきまして
なんと 初回20名の参加枠に80名近くの参加応募 をいただくことができました! 界王拳並みに増席させていただき、当日も天気が悪いにもかかわらず、
多くの人にお集まりいただきましてありがとうございました!

teamspirit.connpass.com

Jenkinsのプロダクションビルドを誤ってポチるという苦い経験のあるワタシですが
自分はフロントエンド領域がメインであり、 あまりCI/CDに関する前提知識がない状態でしたが、 とても面白い発表ばかりで、レポートさせていただきます!

発表

トレタアプリのCI/CD環境

Keiichi Inoueさん(株式会社トレタ)

「CI/CDは大人のピタゴラスイッチ」楽しみながらやっているとのコメントが印象的でした!
CircleCIは環境構築手順をcircle.ymlにコード化できるため、Jenkinsと比べ秘伝のタレが生まれにくいんですね。

入門としてCircleCIを触ってみるのもいいかな、と思いました。
(2017年2月現在、Freeプランがあるみたいです。)

ReactとSeleniumの幸せな関係

Akira Kuratani(株式会社チームスピリット)

弊社Kurataniの発表です。スライドが途中急にFancyなデザインになります。

最近のHTMLはJavaScriptから動的に生成される関係で、 フレームワークに依存した構造になることも少なくありません。 テストを円滑に構築するにはそれを見越してDOMを設計していく必要があります。

コーダーとテスターがお互いに歩み寄りを意識しなければtestableなHTML にはなりにくいというお話でした。

デプロイ完全自動化から1年で起きたこと

Masaki Iizakoさん(株式会社一休)

一休さんにおけるCI/CD周りの改善、チームとして取り組むためにやってたことを発表いただきました。 組織が拡大してくにあたりグループで取り組んでいく必然ができたことと、 必要十分を見極め、改善を繰り返していくことが大切なのだそうです。

また
「Qiitaに資料を作って、共有した気になってはいけない」

個人的にとてもグサっとくる言葉でした。

CircleCI の結果をSlack通知してみる

Yusuke Nakahiraさん(株式会社チームスピリット)

弊社Nakahiraによる、CircleCIによるESLint/Slack連携の発表です。

ざっくりいうとPRをフックにESLintを実行し、GitHubの該当行へコメントした上でSlackへ通知 という環境を構築したお話でした。

なんとSlack連携に関しては10分くらいでできてしまったそうで、 CircleCIについては環境構築自体のハードルがかなり低いというのは 嬉しいポイントだなと思いました!
(おそらく何回も試行錯誤するわけですからね…)

iOSアプリ開発のCI/CD環境と ユビレジでのtry

Noritaka Kamiyaさん(株式会社ユビレジ)

「iOS、デプロイ環境を作るなら 今が旬 」 突然のパワーワードに全て持ってかれてしまいましたが、
毎年プラットフォームの変更に煽りを受けるiOS界隈では、最適なCI環境もコロコロ変わってしまうそうで、 年一回の変更後、その年のノウハウが溜まってくるのがちょうど今の時期なのだそうです。

みなさん!今、今ですよ。iOSのデプロイ環境作るなら!

テストとデプロイだけがやりたいことですか?

Soutaro Matsumotoさん(株式会社アクトキャット)

アクトキャットさんが開発されているSideCIのご紹介いただきました。

SideCIはコードレビューに焦点を当てたプロダクトで、 Lintの自動実行とプロダクトに合わせた柔軟なルールを簡単に書けるというのが 特徴だそうです。

後者はQuerlyというgemで実現しているそうで、Githubに公開されているますので チェックしてみてください。

Querly

あと、「強い気持ちがあれば Lint指摘を無視できるボタン」は非常に興味深かったです。

ios/android app_build/test pipeline

Masashi Kurita さん (DeNA Co., Ltd.)

定量的な分析からテスト戦略の立案、実行効果測定までをお話しいただきました。

メトリクスを使ったPDCAサイクルはとても説得力があり、具体例を教えて いただけたのはとても勉強になりました。

ところでご紹介いただいたスマートフォン検証システムのSTF
どっかで触ってみたいとず〜っと思ってます。

フレクトでのSphinx CI

Shun Saitoさん ( 株式会社フレクト )

中身とは直接は関係ないですが、自分、スライドのデザインにとても感銘を受けました。 伝えるためのデザインとクオリティが両立していてお手本にしたい!と思う資料でした!

内容は

  • エンジニアが楽しくかけるドキュメント作成
  • ビジネス的に価値のあるドキュメント作成

をCIによって自動化するというものでした。 他の方とは全く違った切り口の発表でとても面白かったです。

まとめ

CI/CD環境については特に「コレ」といったデファクトスタンダートがあるわけではなく、 例えばCircleCIに関しては扱うのは比較的容易でも、コスト/速度面などでトレードオフがあり、 チームに合わせて技術選定をしていく必要がありそうです。

特にiOSについては環境構築についてかなりの試行錯誤が必要そうですね。

他にも、属人化しやすいという面があり、

  • 迫り来る秘伝のタレ化とどう戦うか?
  • どうナレッジを共有していくか?
  • チームとして取り組んでいくには?

という点を意識しないといけないのではと感じました。

アプリケーションエンジニアからすると、普段CI/CD周りについて悩むケースはほとんどないと思いますが、
プロジェクト全体に影響するものですから、意識していかなければいけないものではあります。

これを機会に自分も、まずはプライベートでデプロイ職人(?)の第一歩を
踏み出してみようかと思います。

なお当日の様子はハッシュタグ #cicd_night からもご覧になることができます。

参加してくださった皆様、誠にありがとうございました!

※写真はライブペインティング(トイレ地図アート)の様子です。 f:id:ts-yokouchi:20170213094210j:plain

React.js LT勉強会(忘年会)を行いました!

こんにちは。
株式会社チームスピリットの古川(id:furukawa-hisakatsu)です。
既に一ヶ月前の内容となりますが、React.jsの勉強会(忘年会)を行いましたので当時の会場の状況等を報告します。

今回行ったこと

この度は新しい試みとしてReact勉強会を行わさせていただきました。
行った内容としては著名な方が数十分話すような内容ではなく、各人10分程度のLightningTalkとなります。
発表内容としても自分が触ってみて感じたこと報告や、自社ではReact.jsをこのような形の実装を行っている等
初めて触ってみた方や既にバリバリ使っているという方、初心者~実務向けの内容となります。
(私も今回LTにて発表しました!)

会場の様子

f:id:furukawa-hisakatsu:20170130013609j:plain

今回は初めての内容ではありますが、30人近い人数が集まって下さいました!
お話を聞いてみますとReactに関しても名前を知っている方から実際に使った事がある方まで、参加してくださいました。
(今回の資料も初心者向けから中級者向けまでを用意しておりましたため問題はございません!)

発表しました資料

各資料の詳細は割愛させて頂きますが、許可をいただきました資料を公開します。 初心者が初級者になるまで(株式会社ACCESS 笠原様)

reactを使ったアプリ開発の流れ(株式会社ACCESS 梅田様)

みんなにやさしいlazy loadと Reactそしてredux-observable(エムスリー株式会社 富岡様)

何故Reactは凄いのか(株式会社チームスピリット 湊)
資料のリンク

React Storybookを触ってみる(株式会社チームスピリット 山崎)

サンプルTodoから見るReact,Flux,Redux(株式会社チームスピリット 古川)

次回の勉強会

次回の勉強会は別のテーマとなり、CI/CD勉強会となります。
内容としては何らかの成果物の実装と言うよりは、 成果物の品質を担保するためのテスト手法、それを自動化するためのツール等を触ってみたり等の内容となっております。 既に参加枠はオーバー状態となっておりますが、LT枠はまだ余っておりますため、是非ご参加の程よろしくお願いします。

Tokyo Salesforce Developer Group 2017新年会に参加してきた

こんにちは。 株式会社チームスピリットの倉谷 (id:a-kura) です。

Introduction

久しぶりのブログになりますが、2017年1月25日(水)に開催された Tokyo Salesforce Developer Group 2017新年会 に参加 & LT してきましたので、簡単にレポートさせていただきます。

今回のイベントは、新年会ということでがっつりしたセッションというよりは、軽めの LT + 懇親会(寿司)での開催でした。普段より懇親会の時間を長く取ることができたので、いろいろな方を話すことができました。

Trailblazer パーカーを着て働き方改革に邁進するアストロくんは、イベントの LT でいただきました。ありがとうございます!

f:id:a-kura:20170127103653j:plain

Lightning Talks

正式なイベントレポートは参加者有志の方に譲ることとして、弊社エンジニアの LT だけふりかえります。

SWTT2016 ミニハックをふりかえる

山﨑のLT。

SWTT ミニハックにチャレンジし、全問回答したにも関わらず、賞品をゲットできなかった追悼的なやつです。

毎年いろいろな機能を使いこなす必要のある Mini Hack ですが、印象に残った課題とその琴線に触れたポイントを紹介してもらっています。

LINE Messaging API を利用した課題などは Hot な話題でした。課題ではあらかじめアプリケーションが用意されています。私もやってみましたが試してみる分には想像したよりも簡単にできました。

今年は事前に Web サイトから課題が確認できたので、今でも見ることができます。興味がある課題があれば、ぜひチャレンジしてみてください。

Advent Calendar ふりかえり〜ただし、Qiita に限る〜

私の他力本願な LT 。

せっかくなのでランキングを発表したいと思い、Qiita のいいね数でランキングしてみました。 今年は、2記事にいいねが集中しており、どちらの記事も非常に面白かったです。

ただし、サブタイトルにあるように Qiita ではないブログに投稿してもらったものについては、カウントできないので対象外にしています。 よって、外部のブログで書かれた注目を集めた記事は、今回のランキングに反映されていません。どれも力作揃いなので一度眺めてみてもらうとよいと思います。

弊社エンジニアも何名か書いていますので、探してみてください。

Social Gathering

懇親会でいろいろな方とお話させていただきましたが、今年は Lightning Experience がキャズムを越えて本格的に普及し始める年になる予感がします。

Salesforce の方々(米国開発チーム含め)が本気であることはもちろんですが、Lightning Experience の機能も充実してきています。新規に導入については、Lightning Experience を選択されるお客様も増えてきており、活用事例としても揃ってきてます。

これまでは Classic(Aloha) との機能比較で採用するかどうかが語られてきました。しかし、機能的な差は徐々に埋められています。

また、昨年の Dreamforce で登場した AI「Einstein」がこの流れを大きく変える可能性があります。Einstein の利用開始が、どのタイミングかは分かりませんが、Einstein が利用したいという理由で Lightning Experience を導入する、またそれに備えて移行しておく、という流れが出てくると感じました。

Conclusion

今年も無事新年会を開催でき、2017年も始まった感じがします。

「イベントに参加してみたい!」という方は、Tokyo Salesforce Developer Group に参加しておくと、イベントの案内を受け取ることができます。

直近では、2017年3月1日(水)に Meetup #14 が開催される予定です。

では、今年も Developer Group を盛り上げるために微力を尽くそうと考えておりますので、どうぞよろしくお願いいたします。

宣伝

来たる2017年2月9日(木)弊社にて CI/CD の勉強会を開催します。ご都合がよろしければ、ご参加ください。

teamspirit.connpass.com

Salesforce World Tour Tokyo2016ミニハックの解答例を公開します

みなさんこんにちは。
株式会社チームスピリット エンジニアの山﨑(id:dackdive)です。

このたび、弊社の技術ブログをはてなブログに移行しました!
(以前は TeamSpirit 魂のブログ に投稿していました)

記念すべき初回の記事は昨日、一昨日に行われた Salesforce World Tour Tokyo の話をさせていただきます。

私も昨日は終日参加させていただきましたが、開発者向けゾーンも年々盛り上がりを見せている気がします。

f:id:dackdive:20161214110305j:plain

f:id:dackdive:20161214150236j:plain

ところで、こういった Salesforce の年次イベントでは恒例となっていますが
今回もミニハックという開発者向けクイズがありました。

https://developer.salesforce.com/ja/worldtour2016/minihacks

  • 今回は事前に内容を公開
  • 正解者には抽選で豪華景品が当たる!
  • 1問正解で抽選券1口なので、解けば解くほどお得

ということで、私も豪華景品をゲットすべく挑戦してみました。
せっかくですのでその内容を以下のリポジトリで公開しています。

すべて、Force.com Migration Tool を使ってデプロイ可能な状態にしております。

以下、各課題の簡単な解説です。


課題1 - 出張申請を楽にする

毎回登場する、いわゆるポイント&クリックツールだけを使用してアプリケーションを構築しよう、というお題です。
Salesforce プラットフォームへの幅広い知識が問われ、私が最も苦手とする分野でもあります。

  1. 予定額が700ドルを超える出張申請は、承認が必要となるため、申請者の上司に自動送信する必要があります。

をどう実現するかがポイントでしょうか。私はプロセスビルダーを使用しましたが、他にやり方あるのかな?


課題 2 - オールインワンシステム

「外部データベースシステム」から Salesforce Connect を連想できれば簡単ですね。
(Salesforce Connect については Trailhead のこのモジュール をやるとよさげ)

わからなかったこと

外部データソースを作成する際、「種別」で「Salesforce Connect: OData 4.0」を選ぶとうまく同期できなかったので、何も考えず「Salesforce Connect: OData 2.0」を選択してしまいましたが
判断する基準とかあるんでしょうか。


課題3 - Visualforceのデザインを変更する

参考ブログ の通りにやるだけ、かと思ったら
独自 namespace を追加した Lightning Design System を適用するためにコードを一部修正する必要があったり
そもそも元のコードの createAccount() に相当するロジック部分がまるっとなかったりで
意外とやることが多い課題だったように思います。

勘のいい方は参考ブログに貼られている Demo Page のコードをブラウザの開発者コンソールで開いて
createAccount() 部分をまるっとコピーして楽をしたのではないでしょうか。(私だけ?)

なお、今回 CRUD 処理は参考ブログと同じく Remote Objects を利用しています。
単純なオブジェクト操作を行うページであれば、Apex の実装不要で実現できるので便利ですね。

それから、これは参考ブログを読んで初めて知りましたが
Force.com サイト という機能を使うと Visualforce ページを一般公開できるんですね。
私も自分で作ったページを公開してみましたが、こんな感じです。
http://yama-swtt16minihacks-developer-edition.ap2.force.com/

公開する際は、静的リソースのキャッシュを「公開」に設定することに注意。

f:id:dackdive:20161215104558p:plain


課題4 - Lightningを使った取引先責任者検索

ベーシックな Lightning Component のお題。
いつぞやの Salesforce Lightning コンポーネントチュートリアル とほとんど同じ内容だったので、
取引先名で検索しないといけない ことさえ注意すればほとんどコピペでいけたはず。

私は、せっかく取り組むので Lightning 基本コンポーネントと Lightning Data Service を使って実現できないかなと思ったんですが
<lightning:input> タグが onChange イベント時に event.target.value で値を拾うことができなかったり
Lightning Data Service は複数レコードを扱うようなタグは今のところなかったようなので
結局どちらも断念。オーソドックスな作りとなりました。
(課題1 で作った Lightning Design System の静的リソースを利用して見た目だけはそれっぽくしましたが…)

f:id:dackdive:20161215105355p:plain


課題5 - Herokuアプリケーションを使ってみる

サンプルコードが Python というだけで諦めた 方も多かったのではないでしょうか。
Python は良い言語です。大丈夫、怖くない。

ただ、参考ブログ のセットアップ周りの内容が Python 未経験者には敷居が高いんじゃないかなーという印象です。
実際ローカルで動くようにしなくてもクリアできますしね。

本番環境の DATABASE_URL をコピーしてローカル開発でも本番環境の DB を使う、というのは知らなかったなあ。


課題6 - APIを使いこなす

  1. RESTリソースを更新して、取引先責任者の説明の項目を「アクティブでない取引先責任者」に更新できるようにしてください。

の自由度が高く、皆さんどういう実装をしたのか気になります。
私は Id を PUT で送ると説明欄だけ更新するようなメソッドを作りました。

@HttpPut
global static void deactivate(Id contactId) {
    RestRequest req = RestContext.request;
    RestResponse res = RestContext.response;
                                                          
    Contact contact = new Contact(Id = contactId);
    contact.Description = 'アクティブでない取引先責任者';
    update contact;
}
わからなかったこと
  1. サンプルコードと同様に、認証には、ユーザー名とパスワードの代わりにセッションIDを使用して、組織のREST APIを呼び出し、ソリューションをデモできます。

と記載がありながら、私はセッションIDの取得部分は Force.com REST API 開発者ガイド

curl https://login.salesforce.com/services/oauth2/token -d "grant_type=password" -d "client_id=myclientid" -d "client_secret=myclientsecret" 
    -d "username=mylogin@salesforce.com" -d "password=mypassword123456"

と同じように、ユーザー名とパスワードを使ってしまいました。
少なくともターミナルなどの環境から実行する場合、セッションIDを取得する処理については仕方ないのかな…?


課題7 - LINE株式会社からの課題 - LINE Messaging APIを使ったLINE Botの構築

流行りの Bot です。

サンプルコードを Heroku にデプロイした後、/salesforce にアクセスするところまではたどり着いたものの
以下の認証コードをどこで送信すればいいかわからなくてつまづいた方も多そう。

f:id:dackdive:20161215133716p:plain:w320

Bot との 1 on 1 トークは制限されるようなので、普通にグループに Bot を招待してあげて送信すればよかったんですね。
またその際、Bot のグループトーク参加を許可しておくことも忘れずに。
私はこれでしばらくハマりました。

f:id:dackdive:20161215134400p:plain


おわりに

というわけで、ミニハックの内容を一通り紹介しました。
気になる課題についてはぜひリポジトリのコードを読んでみたり、実際にデプロイして動かしてみたりしていただければ。

f:id:dackdive:20161214190045j:plain

帰り際、最後にぽつんと残された巨大アストロ君。
心なしか 全問正解なのに抽選会で見事に1つも当たらなかった 時の私と同じ目をしています。