Inside Frontendに参加してみました。

ゴリゴリのフロントエンド要素が強い内容にも興味はあったのですが、できれば今の仕事にも活かせるような内容を持って帰れるほうがいいなと思い、デザイン関連のものを見てみました。

基本的にはCの部屋にへばりついてました。

以下、資料がupされてるものに関しては、個人的によかったなと思うところをとかAMAであがってた内容を書いていきます(詳細はスライドを見たほうが絶対いい)
＊極力聞いた言葉をそのまま転用するようにしてますが、間違っていたらすみません。
＊全部はとてもじゃないけど拾えない。そろそろgoogle docsに音声入力か・・・

Seminer A-1 : TypeScript: Why and how we adopted it at Slack

Felix Rieseberg
シニアエンジニア @ slack
もともとは OSSエンジニア from マイクロソフト

発表内容

Slackにtypescriptを導入した話

Introduction

Battlefield1 is written by react typescript
Electronをベースに作られているslackだが、C++のモジュールで書かれているものもあるとのこと
アプリがクラッシュすること、クラッシュしてもログがでない(?)ことに対して危機感

巨大なコードhandlingする必要がある

ドキュメントをまとめたり、jsDocを書いたりするがだめだった(信用できない)
More js More worries
vanillaは勉強必要

typescriptを導入

typescriptのいいところ

jsのsupersetだから、変える必要がない(筆者注釈 : jsで書いていたものがそのままtsで使える)
editorのサポートがいい
npmでのインテグレーションができる
型制御
他のモジュールと共有できる

js -> tsに変換する

hoge.js -> hoge.ts - editor上でエラーがわかる - 実行する前にわかる - tsconfi内、jsへのコンパイルで es6 と設定すればClassとして書いたものをがes6のClass表記でかかれ、 es5 と設定すればclosureを用いてよしなに変換されていた(といったかんじのデモがあった)

typescriptを導入してみて

もともとslackではtypescriptを多用するつもりはなかったが、そっちで書いていったほうがいいよねとなった
editorのオートコンプリートが強い
意外と簡単にtypescriptを使えるようになった
クラッシュの危機感が低くなってよい
コードの書き方が多少汚いPRを混ぜてしまっても、クラッシュは一旦しないだろうという安心感がある
tslintがまだ弱い

SEMINAR A-2 : Introduction to Lucet

Adam Foltzer

発表内容

Lucetの紹介

github.com

いろいろメモしてきたけど、WebAssembly まわりの知識がなさすぎてちゃんと書き連ねる自信がないので割愛。
こちらの記事が参考になりそうだなと思いました。

efcl.info

SEMINAR C-3 : デザインエンジニアとフロントエンド

Shinichi Kogiso

speakerdeck.com

pickupしたい点

デザインエンジニアという職種に対してまだまだ認知度が低い(UXエンジニアやデザインテクノロジストといった別呼称があったりも)
デザインエンジニアはデザイナーとフロントエンドの架け橋となり、開発を円滑に進めていくポジション
専門性とスピードが求められる
違う景色(社内だけでは得られない経験等)を見続けることがだいじ

AMA

app2.sli.do

デザインエンジニアの職能とかワークフローが曖昧。どう振る舞うか

-> デザイナー側やフロントエンド側に足を運び、なにか困ってないかを聞いたりして、手助けする。

意見の対立とかのコミュニケーションを取るか

-> Slackだけだと温かみがない
共有会をしてちゃんと双方向のやりとりを促す
インフラ系はあまり興味がなかったりするところに対してはちゃんと説明してあげる

若くしてデザインエンジニアを名乗れるか?

-> 可能だと思う。各会社で新卒から採用してたりする(かも)
募集かけたらくるのでは？(取る側の話) 好奇心がある人が向いている気がする

デザインエンジニアのあとのキャリア設計(その後どうなるか)

-> フルスタックエンジニアかディレクターとかになるんじゃないかな

「なんでもできるようだけど、何が得意なの？」となることがある
弱い人が多気がするけど、なにかひとつ「これ強い」って言えたほうがいいよね

コンポーネント設計に対してデザインからの文脈とエンジニアからの文脈があるけど、どう考える/どう対処する

デザインとしたら1pxのズレや、アニメーションの違和感があったりとか。
エンジニアからしたら、なんでこれ分けるの？これいらなくない？
-> デザイナーはsketchとかでアニメーションをつけて見せたりして齟齬をなくす

実装時のコンポーネント分割と、デザインのコンポーネントの分割がずれるときは？
-> 資料とか作ってちゃんと説明する。命名規則で困ったらそれも都度MTG

デザインエンジニアと名乗るには？

-> ある特筆した能力がある上で、もう一つ能力がある、ってなったときに名乗ったらいいのでは？

副業とかに時間のバランスは？

-> 平均2~3時間、土日どちらかにがっつり時間をとる。

レガシー環境をvueなどを入れて改善したいが・・・

-> チームのモチベーションはあがる
売上とは関連するかどうかは怪しいよね
空きを見て順次導入していくほうがいいのでは。

なんでデザインエンジニアになったのか(どういう思いか)

-> 両方やりたかった

SEMINAR C-4 : いちからデザインシステムを作ってみて学んだこと

Kengo Haruno

speakerdeck.com

pickupしたい点

「componentの名前付けで時間がかかる」ところに対して、「そのcomponentの役割から名前を考える」ということと「全員が納得するまで議論」する(というところがひとつ模範解答だと考える)
将来的にCSS フレームワークとして提供できるよう、またデザイナーがわかりやすいようにsassでcssを書く
フロントエンド側(実装都合)がわかる人がコンポーネント作成のところに入ることで、「hover時のアクション」といった平面のデザインだけでは気づきにくい動的なところまで事前に調整することができた
デザインシステムは巨大なプロダクトなので、部分的にはじめるのでもよいかもしれない