こんちには、買い出し担当の倉谷(id:a-kura)です。
みなさん、料理してますか？ 自宅での話ではありません。会社での話です。
料理はエンジニアリングであり、サイエンスです。
つまり、料理はエンジニアが取り扱うべき対象のひとつです。我々エンジニアがまかない料理を作ることは自然な流れになります。
では、今回のまかない “スマホカツ” についての実験レポートをどうぞ。
たまたま調達できた美味しいパンと Anova と電気フライヤーで調理したスマホカツが合うかを検証することを目的とします。
“スマホカツ” とは、断面がスマートフォンくらいあるトンカツのことです。
この実験を通して、Anova と電気フライヤーで美味しいスマホカツが作成できるか、肩ロースとヒレはどちらがパンに合うか、などを確認します。
続きを読むこんにちは 
id:ts-yokouchi です。
皆さんは仕事環境にはこだわりを持っていますか？
私は椅子にかなりのこだわりを持っています。
自宅ではリモートワークに備えてStealCaseのLeapチェアを購入し（新古品で10万くらいしました）、
会社でもオカムラのチェアをバリバリ前傾姿勢仕様にカスタマイズして使用しています。
そもそもPC作業に向く前傾姿勢に対応した椅子やセッティング（長いので以下略
ただ、こだわりを発揮した後に気づいたのですが、私は座り仕事に向いていないという弱点が発覚しました。
やる気を燃やしながら仕事を始めたとしても、お昼後や室内温度が高めになっている時など、どうしても眠気が襲ってくるポイントは発生してしまいます。
（※真面目に仕事はしています）
特に私は比較的涼しい地方の出身ということもあり、室温による「あったか〜い、ねむ〜い」現象に弱い体質です。
（※真面目に仕事はしています）
良い椅子は座りごこちも良いため、上記誘惑と一緒になって私を苦しめるのでした。
（※真面目に仕事はしています）
上記問題を解決する最強のソリューションを最近導入しました。
それは
「スタンディングデスク」です。
こちらが最強の「スタンディングデスク」です。
独立したデスクを想像した方ごめんなさい、手作りスタンディングデスクです。
弊社SalesforceMVP 、倉谷に送付されてきたSalesforceグッズを梱包していたダンボールを使用しています。
SalesforceMVPに導かれしダンボール、「MVPダンボール」はスタンディング作業において面積・コスパ共にパーフェクトです。
このダンボールで仕事をしていればやがてMVPになれるような気がします。
また接続している外部ディスプレイはさすがにそのままの高さで使うことができないため、 程よい厚み面積の技術書で高さを若干かさ上げしています。 優れた書籍に支えられたディスプレイで仕事をしていると、根拠のない自信が湧いてきます。
PC自体は鼻セレブクラスの高級ティッシュボックス（強度が良さそう）を３つトライアングル型に配置した台座を作成して使用しています。
ただし、このような高さ調整も完璧ではなく、足を大股に開いて自分の身長を調整しています。
眠くなくなった、というのが一番大きなポイントです。
仕事場で立ちながら眠ることができる器用な人はなかなかいないと思います。
（いたら面白いので教えてください。）
２つ目に関しては全くの予想外だったのですが、前は帰りの電車内で疲労からうとうとしていました。
スタンディングデスクを始めてから適度な筋肉の緊張が良い影響を与えたのか寝なくなりました。
ただし、スタンディングデスクをしたから痩せるといった効果は今のところでていません。
体への負荷はそこまでではないのかもしれません。
眠くなくなったのは良いことですが、疲れてる時はやる気がでなくて作業ができないという現実をマジマジと実感することになりました。
立ちによって肉体的消耗には対処できたのですが、精神的消耗もあるのです。
これに関してもエナジードリンクを注入することによってある程度対処できることがわかってきました。
最後に関して、執務室の入り口近くに席を置いているためか、部屋に入ってきた人にやたら話しかけられまくる時期がありました。
僕個人としては人見知りだから辛かった単純に真面目に作業改善を行なっているわけで「やめてくれ〜」という気持ちもありましたが、人は慣れるもので今では誰も気にしていないみたいです。
スタンディングデスクを導入後、効果が上がって喜んでいましたが、一点大きな問題が浮上してきました。
足裏が死ぬほど痛いという悩みです。
1日立ちっぱなしだと、夕方には足裏の激痛でまともに立っていられないほどです。 これに関してはすこしお高い中敷を靴に敷くことである程度改善しました。 クッション性の高い運動靴などに履き替えるのもアリかなと思います。
スタンディングデスクは無理しない、少しづつ導入していくことが大切です。
スタンディングデスクに慣れた今では全くこの痛みに悩まされることはなくなりました。
眠気に気を取られて作業になかなか集中できないという方はスタンディングデスクの導入で大幅な改善が見込めると思います。
高級なデスクを購入しなくとも、ぜひお手持ちのダンボールで試してみてください。
その際はくれぐれも無理しないようにしてくださいね。
※ 7/12追記
卓上ダンボールやキャビネット上など過酷な状況で作業を強いられてきたスタンディングデスク難民ですが、
それっぽいスタンディングデスクが追加されました。
写真は 
id:a-kura の様子です。
こんにちは。チームスピリットの中平(
id:y_nakahira)です。
ホワイトデーの3/14(火)、Tokyo Salesforce Developer Groupとの共催でこちらのイベントを開催しました。 teamspirit.connpass.com
今回はその参加レポートを簡単にご紹介したいと思います。
会の前半は、セールスフォース・ドットコムCTO 及川さんによる「プロダクト開発を加速するチームとそれぞれの役割とは」をテーマにしたご講演でした。
会社の成長に伴いメンバーが増え、開発手法をアジャイルに切り替えた話や、その運用についてはSalesforce上のアプリケーションを利用して使っている話など、セールスフォース・ドットコム社の具体的な取り組みを例にお話しいただきました。
弊社の開発プロセスもアジャイルで進めているのですが、特に違うと感じた点は、よくあるアジャイルという型に運用をはめていくのではなく、アジャイルの型を自分たちに合うようにカスタマイズして運用している点でした。
実際にどこをカスタマイズしているのかという具体的な話はお伺いできなかったのですが、型にとらわれる必要はなく自分たちの運用に合わせてカスタマイズしていけばいいんだ、と思えたことは収穫でした。
そして、セールスフォース・ドットコム社が実際に利用しているアプリケーションはAppExchangeに公開されており、なんと無料で利用できるそうです。(太っ腹・・！)
Agile Accelerator - Salesforce Labs - AppExchange
会の後半は、セールスフォース・ドットコムCTO 及川さん、セールスフォース・ドットコム シニアディベロッパーエヴァンジェリスト 岡本さん、TAOドライブ エンジニア米井さん(Salesforce MVP)、そして弊社の倉谷(Salesforce MVP)の豪華な4名によるトークセッション。
エンジニアとしての今後のキャリア形成について各々持論を展開いただき、また、質問者からも具体的な質問が出るなど大変盛り上がりを見せました。
セッションを通して印象に残ったのは、
また、全員に共通していたのが
という姿勢でした。
これからの時代を生き抜くためには日々インプットを増やし、アウトプットを出していくことが大切で、それがいつか自分のユニークなキャリアを形作っていくのだなと感じた、とても学びの多いセッションでした。
懇親会はピザで乾杯でした。
登壇を終えた倉谷もアストロ君とこの笑顔。
ご登壇いただきました皆様、誠にありがとうございました！！
みなさまこんにちは id:ts-yokouchi です。
先週末はSwitchを予約し損ねており憂鬱でした。（この、ゼルダやりたさ）
むしゃくしゃしたのでブログを書くことにしました。
みなさんﾊﾞﾘｯﾊﾞﾘCSS書いていますか？え？ｶｲﾃﾙ？嬉しいです。
弊社はSalesforce Platformで動作するプロダクトを開発しており、
Lightning Design System（以下LDS） を利用したプロダクト開発を進めております。
LDSはフルスタックなUIフレームワークとしての側面があり、アプリケーション構築に
必要な要素は網羅されていますが、細かいカスタマイズは必要となってくるところ。
今回はLDSをプロダクトに合わせてカスタムビルドする方法をまとめます。
LDS自体はSassで記述されており、各UIのパラメータ（色やマージン等）は変数で管理されています。
今回は変数をオーバーライドすることにより、カスタムビルドをおこないます。
なお、参考として以下のリポジトリにビルド環境を作っておきましたのでどうぞ。
引用: https://www.lightningdesignsystem.com/design-tokens/
さてLDSを構成する変数ですが、Design Tokenという名称がついております。
Design Tokenには以下の要素が含まれており、カスタマイズ可能となっております。
Design Token自体はSassにロックインされて定義されている概念ではなく、 Salesforceプラットフォーム上で別途利用することが可能です。詳細はドキュメントをみてください。
おそらくSalesforce上でカスタマイズして利用する方が正攻法な気もしますが、
今回はローカル開発などを想定して Design TokenをSass上で編集し、LDSをローカルにカスタマイズビルドする方法をご紹介します。
やっていきましょう。
（具体的なコマンドなどはリポジトリのREADMEをみてください。）
.
├── node_modules
├── build
└── src
├── _design_token.scss
└── style.scss
gulpfile.js
package.json
src と node_modules をgulpに通して build へコンパイルします
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 は未定義であれば変数を定義するという意味です。
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を除いてアイコンやフォントなどを取り出しています。
さて、Lightning Design Systemは Design System の名前からもわかるように、Salesforceプラットフォームに 特化したものです。
高い汎用性を持っているBootstrapとは若干毛色が違います。 あくまでBootstrapはCSSフレームワークなのです。
第一にLDSはドキュメントが非常に豊富です。Getting Start には Developer向け、デザイナー向けの二つの入口が準備されており、それぞれコーディングスタイルからデザイン方針まで非常に手厚い解説がなされています。
このドキュメントを一通り読むだけで、LDSと調和したUIを構築するために必要な知識を手法と思想の両側面から網羅できるのではないでしょうか。
また、あるドメインに特化した姿勢はCSSの設計にも表れています。
http://getbootstrap.com/css/#buttons
写真はBootstrap 4 のドキュメントより引用していきました。
.btn-primary （色によって表されるボタンの役割）と disabled (ボタンの状態) によって、
最も重要ではあるが、操作が現在有効でないボタン の視覚表現が可能になっています。
役割と状態の組みあわせは自由で、例えば .btn-success という役割と disabled を併用することができ、
OOCSS（オブジェクト指向CSS）の恩恵をフルに得ることができます。
ですがLDSでは、似たような組み合わせの .slds-button--success と disabled は併用することができません。
もちろん記述自体は可能ですが視覚表現に表れてこないのです。
そもそも success の使い道としては、ある処理の実行結果が成功した時に、ユーザーに確認のOKを求める場合などでしょうか？
disabledが必要となるケースはあまり多くなさそうですね。
こういった思い切りの良さが反映されているデザインなのだと私は推測します。
さて、ビルド方法および中身の設計について簡単についてご紹介したLDS、 徹底的にSalesforce wayに 乗りに行く 場合は非常に真価を発揮するシステムだと感じました。
LDSを利用する場合は、デザインシステムから逆算して全体を設計していくフローを踏んでみてもいいかもしれません。
Salesforce上のユーザー体験を維持することは極めて容易になると思います。
制限を受け入れることである程度の品質は担保されるはずです。
次のプロジェクトではLDSをﾊﾞﾘﾊﾞｯﾘ使うことを検討してみてはいかがでしょうか。
UIは任せろー ∧_∧ (ﾟωﾟ ) ﾊﾞﾘﾊﾞﾘＣ□ lヽlヽ / ( ） (ノ￣と | しーＪ Nice Consistency(すてきな一貫性)！
ここまで記事を書いて CSSをほとんど書いていない という事実に気づいた私です。ｼｸｼｸ
来たる3月14日19時より、「TeamSpirit × Salesforce DG Meetup 」と題しまして勉強会を開催することになりました。 今回はなんとセールスフォース・ドットコムのCTO及川氏を迎え、濃いお話が聞ける期待大です！
参加申し込みは下記connpassから行っておりますのでお待ちしております。
こんにちは、エンジニアの山崎 
id:dackdive です。
最近は「あいつは JavaScript エンジニア」「JIRA おじさん」などと揶揄されています。
さて、前回の新年会に引き続き、今年 2 回目の meetup が 3/1(水) に開催されました。
いつも LT 登壇するのにいっぱいいっぱいで参加レポを書くことができていなかったのですが、今回は純粋な参加者として楽しんできたので
内容を簡単にブログで紹介しようと思います。
今回はいつものリリースノート輪読会に加え、技術セッションという形での発表が2つもあってどちらも非常に興味深かったです。
遅刻しちゃったので前半聞けず、印象に残っているところをいくつか。
フレクトさんチームから Chatter API、REST API、Bulk & Tooling API の紹介。
普段の業務では API を直接叩くことがないので、このへんの動向をさらっとおさらいできるのは助かります。
個人的には REST API の Composite リソース が便利そうで気になりました。
スライド資料はこちら。 Spring'17リリースノート輪読会 API By フレクト
ここは印象の残ったことを箇条書きで。
<lightning:avatar> など、基本コンポーネントも充実してきた資料はこちら。
http://mino0123.github.io/slides/20170301-meetup.html#/
Locker Service とは何か、どういう仕組みになっているのか、という説明から現在の動向まで詳しく紹介いただき勉強になりました。
最後、「結局 Locker Service は使えるのか」という問いの答えが「微妙。」だったのは非常に説得力があります。。。
フルスクラッチで JS を書く分には問題ないかもしれないが、React など 3rd Party ライブラリを使おうとすると依然として問題は起きそう、またそれらのライブラリの最新のバージョンにどこまで追随してサポートしてくれるのか、が懸念ということですね。
Salesforce のセキュリティチームのマラットさんという方が登壇してくださいました。
PMD Apex というツールを使って Apex や Visualforce の脆弱性をローカルで検出する方法を、デモを交えて紹介。
（PMD 自体は Salesforce に依存しないコードの静的解析ツールで、サポートしている言語の一つとして Apex がある、という感じです）
ここで言う脆弱性とはたとえば、
public class MyClass { }
のように with sharing または without sharing キーワードのないクラスだったりとか、
FLS チェックしない状態でのオブジェクトの CRUD 処理などを例として挙げてました。
その流れで
FLSチェックすればCRUDも考慮されるので、基本はFLSチェックだけすればいい。なるほど。
— Shingo Yamazaki (@zaki___yama) 2017年3月1日
というのは知らなかったので勉強になりました。
またデモでは、Atom （エディタ）と PMD Apex を組み合わせ、エディタ上にリアルタイムでチェックしていて
これは ESLint っぽくて便利だなと思いました。
（写真撮っておけばよかった）
懇親会では、ちょうど当日 Salesforce MVP に選ばれた弊社エンジニア倉谷のちょっとしたお祝いムードに。 食事もいつものピザではなく寿司です。
お祝いの シャンパン スパークリングワインを手にする倉谷。
おめでとうございます！
そんな倉谷の LT はまさかのマラットさんの PMD Apex ともろかぶり、、、
ということでかつてない疾走感での LT となりました。
資料はこちら。
マラットさんは Atom でしたが、LT では Visual Studio Code のプラグインの紹介もしていました。
PMD Apex、AtomでもVSCodeでもエディタから実行できるらしい。あとはVimだけか…
— Shingo Yamazaki (@zaki___yama) 2017年3月1日
と思ったらそれっぽいのありました。
https://github.com/vim-scripts/pmd.vim/blob/master/plugin/pmd.vim
というわけでセッション内容、懇親会ともにいつもよりちょっとだけ特別感のある今回の meetup でした。
次回は何か LT で登壇できるよう今からネタを探そうと思います。
また、今月 3/14(水) に弊社と Developer Group の合同イベントを開催します。
本日より募集開始してますので、興味を持たれた方はぜひご参加下さい。
あともくもく会も今月のどこかで開催したいねーという話をしてまして、詳細は Tokyo Salesforce Developer Group の Meetup グループ でご案内すると思いますので、お楽しみに。
