チームスピリットデベロッパーブログ

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

仕事が捗るスタンディングデスクのススメ

こんにちは id:ts-yokouchi です。

皆さんは仕事環境にはこだわりを持っていますか?

私は椅子にかなりのこだわりを持っています。
自宅ではリモートワークに備えてStealCaseのLeapチェアを購入し(新古品で10万くらいしました)、 会社でもオカムラのチェアをバリバリ前傾姿勢仕様にカスタマイズして使用しています。
そもそもPC作業に向く前傾姿勢に対応した椅子やセッティング(長いので以下略

ただ、こだわりを発揮した後に気づいたのですが、私は座り仕事に向いていないという弱点が発覚しました。

仕事中うとうとする問題

やる気を燃やしながら仕事を始めたとしても、お昼後や室内温度が高めになっている時など、どうしても眠気が襲ってくるポイントは発生してしまいます。
(※真面目に仕事はしています)

特に私は比較的涼しい地方の出身ということもあり、室温による「あったか〜い、ねむ〜い」現象に弱い体質です。
(※真面目に仕事はしています)

良い椅子は座りごこちも良いため、上記誘惑と一緒になって私を苦しめるのでした。
(※真面目に仕事はしています)

最強のソリューション

上記問題を解決する最強のソリューションを最近導入しました。

それは

スタンディングデスク」です。

現場

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

こちらが最強の「スタンディングデスク」です。

独立したデスクを想像した方ごめんなさい、手作りスタンディングデスクです。

弊社SalesforceMVP 、倉谷に送付されてきたSalesforceグッズを梱包していたダンボールを使用しています。
SalesforceMVPに導かれしダンボール、「MVPダンボール」はスタンディング作業において面積・コスパ共にパーフェクトです。

このダンボールで仕事をしていればやがてMVPになれるような気がします。

また接続している外部ディスプレイはさすがにそのままの高さで使うことができないため、 程よい厚み面積の技術書で高さを若干かさ上げしています。 優れた書籍に支えられたディスプレイで仕事をしていると、根拠のない自信が湧いてきます。

PC自体は鼻セレブクラスの高級ティッシュボックス(強度が良さそう)を3つトライアングル型に配置した台座を作成して使用しています。

ただし、このような高さ調整も完璧ではなく、足を大股に開いて自分の身長を調整しています。

効能

  • 仕事中全く眠くなくなった
  • 帰りの電車で寝なくなった
  • しばらく注目されつづけた

眠くなくなった、というのが一番大きなポイントです。
仕事場で立ちながら眠ることができる器用な人はなかなかいないと思います。
(いたら面白いので教えてください。)

2つ目に関しては全くの予想外だったのですが、前は帰りの電車内で疲労からうとうとしていました。
スタンディングデスクを始めてから適度な筋肉の緊張が良い影響を与えたのか寝なくなりました。

ただし、スタンディングデスクをしたから痩せるといった効果は今のところでていません。
体への負荷はそこまでではないのかもしれません。

眠くなくなったのは良いことですが、疲れてる時はやる気がでなくて作業ができないという現実をマジマジと実感することになりました。
立ちによって肉体的消耗には対処できたのですが、精神的消耗もあるのです。
これに関してもエナジードリンクを注入することによってある程度対処できることがわかってきました。

最後に関して、執務室の入り口近くに席を置いているためか、部屋に入ってきた人にやたら話しかけられまくる時期がありました。
僕個人としては人見知りだから辛かった単純に真面目に作業改善を行なっているわけで「やめてくれ〜」という気持ちもありましたが、人は慣れるもので今では誰も気にしていないみたいです。

 体の痛み

スタンディングデスクを導入後、効果が上がって喜んでいましたが、一点大きな問題が浮上してきました。

足裏が死ぬほど痛いという悩みです。

1日立ちっぱなしだと、夕方には足裏の激痛でまともに立っていられないほどです。 これに関してはすこしお高い中敷を靴に敷くことである程度改善しました。 クッション性の高い運動靴などに履き替えるのもアリかなと思います。

スタンディングデスクは無理しない、少しづつ導入していくことが大切です。

スタンディングデスクに慣れた今では全くこの痛みに悩まされることはなくなりました。

まとめ

眠気に気を取られて作業になかなか集中できないという方はスタンディングデスクの導入で大幅な改善が見込めると思います。
高級なデスクを購入しなくとも、ぜひお手持ちのダンボールで試してみてください。

その際はくれぐれも無理しないようにしてくださいね。

※ 7/12追記

卓上ダンボールやキャビネット上など過酷な状況で作業を強いられてきたスタンディングデスク難民ですが、
それっぽいスタンディングデスクが追加されました。

写真は id:a-kura の様子です。

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

TeamSpirit の承認プロセス(1段)を簡単にデプロイする

こんにちは、チームスピリットの倉谷(id:a-kura)です。
今回は、誰得なのか分からないような TeamSpirit の Tips を紹介させてもらいます。

「Salesforceの承認プロセスの設定って面倒…」と思ったことはありませんか?

画面から設定できるので便利なのですが、TeamSpiritをインストールするたびに何度も同じような設定を繰り返すのは時間の無駄です。
「承認プロセスもパッケージに含めてくれればいいのに!」なんて声も聞こえてきそうですが、残念ながら承認プロセスはパッケージに含めることができません。

しかし、そんな皆様に朗報です!

続きを読む

TeamSpirit×Salesforce DG MeetUp 参加レポート

こんにちは。チームスピリットの中平(id:y_nakahira)です。

ホワイトデーの3/14(火)、Tokyo Salesforce Developer Groupとの共催でこちらのイベントを開催しました。 teamspirit.connpass.com

今回はその参加レポートを簡単にご紹介したいと思います。

プロダクト開発を加速するチームとそれぞれの役割とは

f:id:y_nakahira:20170317112020j:plain

会の前半は、セールスフォース・ドットコムCTO 及川さんによる「プロダクト開発を加速するチームとそれぞれの役割とは」をテーマにしたご講演でした。

会社の成長に伴いメンバーが増え、開発手法をアジャイルに切り替えた話や、その運用についてはSalesforce上のアプリケーションを利用して使っている話など、セールスフォース・ドットコム社の具体的な取り組みを例にお話しいただきました。

弊社の開発プロセスもアジャイルで進めているのですが、特に違うと感じた点は、よくあるアジャイルという型に運用をはめていくのではなく、アジャイルの型を自分たちに合うようにカスタマイズして運用している点でした。

実際にどこをカスタマイズしているのかという具体的な話はお伺いできなかったのですが、型にとらわれる必要はなく自分たちの運用に合わせてカスタマイズしていけばいいんだ、と思えたことは収穫でした。

そして、セールスフォース・ドットコム社が実際に利用しているアプリケーションはAppExchangeに公開されており、なんと無料で利用できるそうです。(太っ腹・・!)

Agile Accelerator - Salesforce Labs - AppExchange

これからの時代に市場価値が高まるエンジニアのキャリアとは

f:id:y_nakahira:20170317112035j:plain

会の後半は、セールスフォース・ドットコムCTO 及川さん、セールスフォース・ドットコム シニアディベロッパーエヴァンジェリスト 岡本さん、TAOドライブ エンジニア米井さん(Salesforce MVP)、そして弊社の倉谷(Salesforce MVP)の豪華な4名によるトークセッション。

エンジニアとしての今後のキャリア形成について各々持論を展開いただき、また、質問者からも具体的な質問が出るなど大変盛り上がりを見せました。

セッションを通して印象に残ったのは、

  • 今までの経験 + 新しい境地 = ユニークなキャリアになる
  • 自分が情熱を持って取り組めるもの・作り出していきたいものを意識して探す

また、全員に共通していたのが

  • アウトプットを増やすためにインプットをどんどん増やしていきたい

という姿勢でした。

これからの時代を生き抜くためには日々インプットを増やし、アウトプットを出していくことが大切で、それがいつか自分のユニークなキャリアを形作っていくのだなと感じた、とても学びの多いセッションでした。

懇親会

懇親会はピザで乾杯でした。 f:id:y_nakahira:20170317112046j:plain

登壇を終えた倉谷もアストロ君とこの笑顔。 f:id:y_nakahira:20170317141308j:plain

ご登壇いただきました皆様、誠にありがとうございました!!

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