「Roppongi.js #6」に行ってきました。
こちらに行ってきました。
株式会社メルカリ 東京支社オフィスで行われたイベントで、なかなか規模の大きいものでした。
六本木周辺に生息していませんが、取引先のお客さんが六本木にあるおかげで月イチペースで行くことがあるので、なんとなく仲間意識を持って参加してきました。
メルカリさんのところに初めて行きましたけど、六本木ヒルズ内にあるのはなんか良いですね。
以下、各セッションのメモです。
スライドが共有されていたものは埋め込んであります。
- SET 活動のすすめ @urahiroshi
- WebAssembly のこれまでとこれから by @fnwiya
- Vue.js を v0.11.0 から v2.5.16 にあげようとしている話 by @iidaapp
- TypeScript and immutability by @brn0227
- プロトタイプを越える React Native by @timakin
- JavaScript はコンパイル言語か by @ariaki
- Universal package.json by @れこ
- 親に向かってなんだその z-index は！！ by @ojisan
- おわりに
SET 活動のすすめ @urahiroshi
SET: Software Engineer in Test
カイゼン活動に近い。
メルカリでは CircleCI を使っている。
push ごとに Storybook をデプロイする。
これらはブログに書いているみたい。
テスト・リファクタリングもやっている。
どう実施するかだけでなく、どう検証するかまで面倒を見る。
SET 活動は、機能に対する実装やバグ修正を行わない、という制約をつけるだけ。
これを成約付ければロールを設けなくとも、個人やチームで意識的に活動できるかもしれない。
メリット
- 視点を変えることが出来て、アプローチの幅が広がる
- 新しいスキルセットが身につくかもしれない
- スケジュール駆動で傷ついた心を浄化できるかも
- 組織の強みになる
- 開発プロセスの問題をすくい上げられる
- 問題に気づいた人＝対応する人ではない
- 問題に気づいた時に、その対処について相談できるメンバーがいるのは強み
WebAssembly のこれまでとこれから by @fnwiya
WebAssembly の登場は、2015年6月17日。
それまで Mozilla がやっていたことを、いろんな企業を巻き込んで再スタートさせたやつ。
モダンなブラウザはほとんど対応済み。（IE を除く）
Start work on next-MVP Steps.
なんと、まだ GC は対応していない。
これによって対応できていない言語もある。
JS を置き換えるものと言われることがあるが、どちらかというと親和性が高いもの。
JS と協調して、良いグラデーションで利用されることを目的としている。
また、ブラウザに依らない実行も目的としているらしい。
IoT とか。
Vue.js を v0.11.0 から v2.5.16 にあげようとしている話 by @iidaapp
そのためにビルド環境を構築した話がメイン。
- bower の除去
npm + npm-scripts で良くね？
ってことで、bower.json を見ながら npm i した。
- grunt の移行
deprecated が多すぎて、つらい。
npm-scripts で良くね？
ってなった。
で、webpack で良くね？
ってなった。
- Vue.js のアップデート
vue-migration-helper というのがある。
公式でも移行ガイドがあるので、そのへんでごりごりやっていく。
TypeScript and immutability by @brn0227
Immutability とは、変更不可能性のこと。
TS や JS はだいたい Mutable である。
変更不可であることによって、参照透過性（関数が値を変更しない）し、副作用が起きないので、プログラムを簡潔にする。
immutable.js は TS と相性が悪い。
特に入れ子の Record を型で表現しようとすると、immutable な型とそうでない方を二重定義しないといけないつらみ。
immer は PlainObject を immutable にしてくれるので使いやすい。
内部的にはプロキシを使っていたりするらしい。
でも class が使えないので、振る舞いをもたせる場合は Object で我慢。
TS で表現するには、readonly を使うか、ConstArray, ConstMap を使う。
readonly はプロパティが読み取りのみであることを宣言できるが、オブジェクトの中身は変更できちゃう。
プロトタイプを越える React Native by @timakin
React Native を業務で使おうとすると、なんだかネガティブみたい。
学習コストやメンテナンスコストで渋られたり、ネイティブでしか実現できない機能が出てきたら？ とか、コミュニティが未成熟なんじゃないの？ とか。
でも Airbnb とか Facebook が本番採用しているで。
メンテナンスについて。
React Native 自体のバージョンアップはきついけど、基本は大丈夫みたい。
JS としてのメンテナンスコストはあるかもね。
コンポーネントの適切な細分化とか。
技術的な天井。
リアルタイム通信、ARKit とか、そういうネイティブとのブリッジが発生するのは渋いかも。
採用面。
ネイティブ経験者なら一週間あればできるで。
React に苦手意識があってもできたらしい。
フォーム入力。
React Native の v0.56 だと一文字ずつ確定しちゃバグあり。
v0.54 まで落とすか、最新の v0.57 に上げるしかないみたい。
課金機能を作るなら React Native IRP が有能。
Android も iOS も両方対応しているみたい。
他のプラグインは片手落ちが多くてツラミ。
JavaScript はコンパイル言語か by @ariaki
みんなだいたい JS はインタプリタだと思っている。
でも、会場の中でちゃんと調べた人はいない。
JS は JIT コンパイラを持っている。
インタプリタはあるし、コンパイラもあるので、どっちの側面もあるので、最適化している。
なので、どっちでも良い。笑
Universal package.json by @れこ
react-native と browser での書き方を混ぜてかけるが、ブラウザで実行時、React Native 実行時でマージ結果が異なるようになる。
RN-Web は環境的には Webpack なので、React−Native の方を使いたくても使ってくれない。
node.js はブラウザじゃないから、一緒くたにしちゃだめだよーって話。
親に向かってなんだその z-index は！！ by @ojisan
やっぱり CSS の話。
z-index + position = 怪奇現象
大きい z-index を使うと親のほうが強くなるので、個が飛び出てこないので良い。でも大人げない。
Stack context
z-index の影響範囲と考えて良い。
これをうまく使えば、子がどんな z-index をもっていても閉じ込めることが出来る。
言い回しが絶妙で面白かった。
何度も会場で笑いが起きるシーンがあって楽しかったし、内容もためになったので、これから ojisan のセッションを見かけたらわくわくするかもしれない。
おわりに
メルカリさんのところだと、最初から缶ビールや缶チューハイがフリーで提供されていて、途中の休憩時間でお寿司が振る舞われていました。
また、各席がテーブル付きの椅子になっていて、PC を使うのにも適している環境で素敵すぎました。
こういうイベントは、イベント終わりの懇親会が楽しくて良いですね。
その時に知り合った人と、六本木のスタバに行って濃い話をできたのも印象深かったです。
Roppongi.js は、六本木周辺の企業とコラボして開催しているそうなので、興味のある企業の方がいたら是非。
