Rejectcon 2018（builderscon tokyo 2018 番外編）に行きました
Rejectcon 2018（builderscon tokyo 2018 番外編）に参加してきたので、ざっくりと勝手にまとめてみました。
その｢s｣を付けるために ─ はてなブログHTTPS化の軌跡
ざっくり
- Mixed contentsの発生
- 独自ドメインが使える
- ユーザーが発行した証明書を預かりたくない
- Let'sEncryptのおかげで解決できた
- 絵文字記法の発見
- 絵文字は他サービスがhttpで画像を提供しているものだった
- はてなプログ側で配信するようにした
- 他社のサービスを利用している状態だと撤退されたときとかにてんやわんやになる→そもそもよくないよね
- テスト
- QAシートの用意
- サポート部に記入してもらう
- 考慮漏れとかここで気づくことができた
- 証明書の技術選定
- AWSのやつだと結果的にブログの要件にあわない
思ったこととか
HTTPS化の話だけでなくて大事なことを再認識できる内容でした。 - 外部サービスとの連携について自サービスで利用できるようにするか否か。という視点は大事 - 問題を解決するために段階を踏んで対応するのは大事 - 社内のエンジニア以外の多数の人に使ってもらって考慮漏れをなくすの大事 - 証明書の技術選定は大事
デザインシステムを導入してUIに秩序を取り戻す
ざっくり
- 画面やプロダクトの増加、UI・ トレンドの変化、デザイナーの入れ替わり
- UIの統一感を保つの大変
- デザインシステムを導入して解決する
- ブランド表現としての見た目や振る舞いのクオリティを確保
- 開発&メンテナンスの効率UP
- デザインアウトプットの効率UP
- デザイナーとエンジニアのコミュニケーションコストの低減
- React Nativeでさまざまなプラットフォームのプロダクトでデザインを統一しやすい
- CSSは使えないがWebはReact Native for Webで対応していく
- わかりやすいドキュメントを作る
- doczというサービスでReactのデザインコンポーネントを簡単にドキュメント管理している
紹介されてたツールとか
Adele 各社、各プロダクトのデザインシステムが公開されているサイト
Lona LonaのGUIでコンポーネント作るといろんなプラットフォームでネイティブに動くコンポーネントを自動生成する（まだ不完全）
Microsoft/reactxp MicrosoftがSkypeをReactでクロスプラットフォームに開発したときに作られた。 React Nativeでのクロスプラットフォームの参考になる。
docz
.mdxというmarkdownとjsxを組み合わせた入力方式で、ドキュメントを書く感覚でReactコンポーネントを描画できる
思ったこととか
自分が開発しているのは今はWebだけのサービスなのでCSSでなんとかなっているけど、画面間のデザインの統一やデザインの管理には課題を感じていたのでデザインシステムの導入を考えたくなった。 Reactでデザインコンポーネントを作っていこうと思っていたけど、いっそのことReact Native for Webに切り替えるのもいいなと感じた。
Rails + Vue.jsでUIリニューアルしてみた
ざっくり
- フロントエンドのリニューアルでjQueryで作り込まれていたものをVue.jsで作り変えた話
- フロントエンドに強い人でなければReactよりはVueがとっつきやすい
- コンポーネント思考で開発効率が上がった
ドメイン駆動Vuexで複雑さに立ち向かう 実践StorybookでVuexに立ち向かう
紹介されてたツールとか
Storybook コンポーネントのカタログを作成・管理できるツール https://github.com/storybooks/storybook
思ったこととか
StorybookでUIコンポーネントを管理しながら開発できるのはデザイナーと共通認識を持ててよさそう。 デザインシステムとStorybookの使い分けの話はなかったけど、導入のために調べてみようかと思った。
新しい技術書出版サービスの作り方
ざっくり
- プロダクト開発のお手本のような話
- キーワード
- ゴール・ダイレクテッド・デザイン
- ユーザー、ステークホルダーのゴールを達成するデザイン
- ゴールは3種類
- ライフゴール（人生において達成したい・どう生きていきたいか）
- 感情的ゴール（サービスをどういう気持ちで使いたいか）
- ファンクショナルゴール（上記2つのゴール達成のために必要な機能）
- 事情通にもインタビューする
関連
思ったこととか
@7ganoさんの話術がまず面白かった。プロダクト開発の根幹を学ぶことができた。 インタビューとゴール設定はしっかりしておかないとプロダクトの軸が決まらないなー。と改めて考えた。
DAO を目指す Ethereum 技術者コミュニティ「Hi-Ether」の挑戦
ざっくり
- Hi-EtherというEthereum コミュニティを中心とした話
- Gakuseiという学生であることを証明するサービスをブロックチェーンで作った
- ブロックチェーンは世界共通で使えるので世界中の学生証明ができる
関連
Ethereum 開発者向けコミュニティを作ったよ Gakusei
思ったこととか
ブロックチェーンは全然わかっていないけど、改ざんができないから学生証明とか身分証明で使えるなら個人の履歴管理にも有用だよねと思ったり。 でも隠したい闇歴史もあるよねと思ったり。
フロントエンドエンジニアが考えるべき事は沢山ある
ざっくり
- Webサイトの三大品質
- パフォーマンス
- アクセシビリティ
- セキュリティ
- フロントエンジニアに求められることはたくさんあるけど、すべてはユーザー体験の向上のため
- ページパフォーマンス改善
- パフォーマンス改善で売上が上がるわけではなく、機会損失・マイナス要因を抑える
- 日々の計測が必要
- 計測し続けていないといつから遅くなったのか、原因がなんなのかわからない
- 推測するな計測せよ
- フロントエンドアーキテクチャ
- jQuery、React、Vueいろいろあるが導入や切り替えを目的にしないように
- 導入理由を説明できるのならチーム次第で導入していく
- アクセシビリティ
紹介されてたツールとか
contrast ratio 背景色とフォントカラーのコントラスト比を計測してくれる
思ったこととか
パフォーマンス計測は単発でやるより継続しないとダメだなと思った。大変そうだけど。 コントラストを計測するという発想は今まで持っていなかったので今後は意識していきたい。
入社から二ヶ月経ってわかった SmartHR 開発のつらいところ
思ったこととか
面白楽しくつらい点を紹介されていて会場は大盛り上がりでした。 ペーパーワークを代替していこうという苦労が最近の自分の境遇から想像しやすかった😇
Rails+ReactなSPAサイトでのSEO
ざっくり
思ったこととか
SSR大変😑
Wantedly の機械学習プロダクト開発を支える機械学習基盤
ざっくり
- プロダクト開発のために機械学習を使っている（名刺画像読み取りロジックとか）
- ユーザー同士のつながりを推定するロジックに使っている
- 機械学習プロダクトを支えるための機械学習基盤を整える
- データ基盤（BigQuery+S3+Analytics）
- 学習環境（GPU Instance+SageMaker）
- 評価管理（script/evaluate+ev）
- デプロイ（k8s+GPU cluster）
- 計測（ログ収集+A/B test(効果検証)）
思ったこととか
機械学習そのものはわかっていないけれど、プロダクトでの利用は十分あるので基盤整備の参考になりそうでした。
FiNCにおけるFault Isolationの取り組み
ざっくり
- マイクロサーピスでの障害の局所化の話
- タイムアウト、Circuit Breaker、Bulkhead → 全部Envoyで解決（インフラ面は）
- アプリケーション側は安全に機能低下できる対策が必要
- あるサービスが落ちたときに関連サービスはどうすべきなのか
- すべてがダメになるより一部がダメになったほうがよいのか、すべてダメにしたほうがよいのか（ビジネス理解も必要）
思ったこととか
マイクロサーピスにしたときのアプリ側の障害時の振る舞いはフロントエンドの人も認識しておかないとプロダクトが死ねるなと思った。 外部サービスとの連携している場合にもこの考え方は当てはまるよね。
エンジニアが起業し自社サービスを立ち上げるまで、そしてその後
ざっくり
- あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える の記事にない裏話
- kibelaの誕生秘話
関連
あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える
思ったこととか
お金と縁は大事。 クックパッド出身の人は話が面白い。
The Five F'ing Questions You Should Answer In Your Proposals
Rejectcon 2018 from lestrrat
www.slideshare.net
ざっくり
- builderscon主催者が語る、なぜ採用されなかったのか。
- プロポーザルの書き方、要点のレクチャー
思ったこととか
プロポーザルの書き方、考え方は普段の仕事でも応用できる内容でためになった。PRとかissueでも考え方は同じかなと。
