- JSConf JPに参加してきました。
- 2日目の参加メモです
タイムテーブル
| 時間 | タイトル | 発表者 |
|---|---|---|
| 11:00- | 時間はただの幻想である… JavaScriptにおいては | Jennifer Wong |
| InversifyJSを用いたレイヤードアーキテクチャの構築 | 奥野 賢太郎 | |
| Vue.js で D3.js を使ったインタラクティブなデータの可視化 | Shirley Wu | |
| 11:30- | ストリームの人生 | Dominic Tarr |
| Build and scale multiple Voice application by using TypeScript | Hidetaka Okamoto | |
| 13:00- | Web の体積 | Jxck |
| 正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終 | Masato Nishihara | |
| パスワードは90年代の代物だ | Sam Bellen | |
| 13:30- | JavaScript, Rust and Wasm Walk into a Ramen Shop ... | Irina Shestak |
| Migration from React Native to PWA | ohbarye | |
| npm i -g @next-and-beyond: Building the future of package management | Claudia Hernández | |
| 14:15- | JSConf Panel Talks | Jan Lehnardt and Yosuke Furukawa |
| GraphQLを用いたECサイトにおけるパフォーマンス改善 | 澤井宣彦 | |
| Minimum Hands-on Node.js | 栗山 太希 | |
| 14:45- | 悪用された npm パッケージの分析 | Jarrod Overson |
| JavaScriptのままでTypeScriptを始める | 高梨ギンペイ | |
| 15:30- | Browser APIs: 知られざるヒーロー達 | Rowdy Rabouw |
| Your benchmark may not guide a real application performance | Tetsuharu OHZEKI | |
| 16:00- | Anatomy of a Click | Benjamin Gruenbaum |
| JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned. | 榊原昌彦 | |
| Recruit Speed Hackathon | 新井 智士 | |
| 16:45- | AIとJavaScript による生物認識 | Jonny Kalambay |
| 大規模アプリケーション開発でのElm実践 | 海老原 圭吾 | |
| 17:15- | Pika: レジストリの再創造 | Fred K. Schott |
| 最新のWeb技術でIoT開発をする | 木戸 康平 |
InversifyJSを用いたレイヤードアーキテクチャの構築
- 奥野 賢太郎さん
密結合とは
- 修正を加えた時にその影響箇所が見つけづらい状態
- 予期しないところに影響が及ぶかもしれない状態
- DBの構造
- 外部サービス
- APIの構造
- 画面の構造
- 例
- 画面の入力フォームの構造のままテーブル設計してしまった
- 画面の構成変えたけどDBいじる余裕ないから無理やり対応することに・・・
- 抽象化する中間の層が必要
レイヤードアーキテクチャ
- DDD
- Domain Driven Design
- MDD
- Model Driven Development
- Repository
DIP
- InversifyJS
- DIの機能を提供するライブラリ
- constructor injectionできる
- TypeScriptで書いた方が相性が良い
- TSyringe
- Microsoft製
- InversifyJSと同じ感じのやつ
- 好みではあるけど登壇者はこっちの方が好き
- レイヤーごとにmodel objectを用意する
- バグが起きたときの影響範囲がわかりやすいように寿命を短くするとよい
- value objectを作るようにする
- バリデーションはconstructorで
- knex
- ORMapper
Build and scale multiple Voice application by using TypeScript
- Hidetaka Okamotoさん
スマートスピーカーのバックエンド
- 音声/言語処理系の知識がなくても開発できる
- Webhookの開発と同じような感じ
- SlackやLINEのbotに近い
- 文脈を覚えておくためにDBも持っておくことが多い
Alexa開発
- ask-adkを使う
- スキルが増えると起こる課題
- スキルが増えるとLambdaも増えるからruntimeの更新など面倒
- 同じような処理がいろんなスキルに存在してしまう
- 多機能な1スキルか単機能な複数スキルか
- 単機能なスキルの方が使いやすい
- でも見つけてもらうのが大変かも
- ServerlessFrameworkを使うと便利
- 全部yamlで管理できる
- runtimeのアップデートなども設定かえるだけ
まとめ
- VUIはWebhookライク
- in/outのフォーマットが一定のためTS相性良し
- 汎用FWがまだない
正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終
- Masato Nishiharaさん
背景
- Node6を使ってたが2019/4にEOL
- Node8は2019/10にEOLだったので一気に10に
- 10のEOLは2021/4
やったこと
- Node変更差分確認
- 依存パッケージの変更差分確認
- 全機能テストを複数回
パッケージの差分
- 依存ライブラリのリリースノート全部見たりするのは現実的でない
- Node10に対応しているか明記していないものもあった
- =>全機能テストで動けばよいとすることに
全機能テスト
- ブラウザバリエーションもあるので大変
- 1回目で不具合を出して対応して2,3回目もやった
リリース後
- CPU100%にはりつくトラブル
- スレッドの切り替えをする処理が多発していた
- Nodeはシングルスレッドじゃないのか？
- 内部的にはマルチスレッドで動くところもある
- libvuの中でマルチスレッドを利用している
- このケースでは原因はDBサーバだった
- 障害のあったサーバからDBサーバへのアクセスが遅延していた
まとめ
- こまめに上げるようにするとよさそう
- コアな部分だけでも自動テストはあった方がいい
Migration from React Native to PWA
- ohbaryeさん
React NativeからPWAへ
なぜReactNativeだったか
BYOD化
- 端末を用意してインストールして渡してた
- 端末配布をやめてBYOD化することにした
- Android版の提供も始めることにした
マルチプラットフォーム対応
パッケージ管理
ビルドデプロイシステム
脱ReactNativeの選択肢
- PWA
- Nativeで書き直す？
- Flutter
- => ブラウザで見たいという要件もあったのでPWAで
- React使った
通知
WebViewで苦労したこと
- キャッシュのレイヤーが増えることに注意
- WebViewのキャッシュを無効化するメソッド用意したりとか
PWAで供料したこと
テスト
- cypressでintegrationテスト書いてる
- ReactNative時代はスナップショットテストとかやってた
運用してみて
- Webなので即時反映されるのでいい
まとめ
- チームメンバーのスキルセットにあった技術選定が大事
- 開発できる = 運用できるではない
- モバイルアプリに近い体験要求されてもWebでもできるかも
GraphQLを用いたサイトにおけるパフォーマンス改善(ECサイトを題材に)
- 澤井宣彦さん
背景
- 歴史が長くページ遷移が遅い
- 全社のリブランディング
- ページ遷移の改善
- 技術スタックの改善
リニューアル
パフォーマンス改善
計測
- 実機で行うテスト
- 合成環境で行うテスト
- PageSpeed Insighrsを使った
ボトルネックの特定
- ChromeのAudit
- Opportunitiesの改善項目
改善
フロント側の改善
- レンダリングを妨げるリソースの除外
- テキスト圧縮有効化
サーバ側の改善
QueryとSchemaの改善
- ページングのない配列のrequest
- 関連するレコードが全件取得されるので性能が劣化
- ページングをつけて件数指定する
- schemaのlinterで未然に防げそう
- 全く使ってないデータを取得している
- queryを消せばよい
- なぜ画面に紐付いてないqueryが書かれてしまうか
- FragmentとColocation
- Fragment
- queryを部分的に切り出したもの
- 再利用できる
- 部分定義できる
- Colocation
- Fragmentを集約して1つのqueryにまとめる
- Reactコンポーネントの階層とqueryの階層をあわせるようにする
今後
- Cacheの活用を検討
- リアルタイム性が低いコンテンツもある
- ゲストユーザは同じものが基本的に表示される
- CDNのレイヤーでHTML/responseどちらもできるはず
JavaScriptのままでTypeScriptを始める
- 高梨ギンペイさん
TypeScriptのいいところ
- JSのスーパーセットであること
- 型を持つこと
Typed-JavaScript
- JavaScriptにコメントで型をつける
- 完全にJavaScript
- これでtscを動かせる
型がつくと何ができるようになるか
- バリデーションできる
- 関数を呼ぶ時にどんな引数を渡さないといけないか？
- ドキュメント見る？
- 動かしてみる？
- 型があればすぐに分かる
- エディタが対応してればその場でわかる
- 関数を呼ぶ時にどんな引数を渡さないといけないか？
- エディタの補完がきく
- 自分で作ったAPIの補完も型を用意しておけば補完される
- 標準関数なんかもググらなくてもその場で候補がでる
- リファクタリングがしやすい
- 変数名後から変えたり型を後から変えたり
- 変更漏れがあればコンパイルエラーになってくれる
使い方
- tsconfig.json
- allowJsをtrueで
.js対象になる - checkJSをtrueでjsもチェック対象になる
- noEmitをtrueで型チェックだけするようになる
- checkJSをfalseにしてチェックしたいファイルにコメントで
@ts-checkつけるでもいける
- allowJsをtrueで
まとめ
- Typed-JavaScript
- JavaScriptにコメントで型を書くとtscが動く！
Your benchmark may not guide a real application performance
- Tetsuharu OHZEKIさん
ソフトウェアのパフォーマンス
ベンチマーク
JSの最適化
- 一度の実行だと数ミリsecで差がわかりづらい
- じゃあ数万回実行しよう
- =>それでいいの？
- 何度も実行されるとJSVMが複数レベルで最適化してくれる
- その処理は何度も呼ばれるような処理なのか？
どのように改善を進めるか
- プログラムを速くするには遅くなるようなことをやらないことが重要
- CIとしてベンチマークを計測して継続してプロットするといい
- 容易に起動できて再現可能であるようにする
- 細かい上下は必ず起きる
- 長期での傾向をチェックする
まとめ
- パフォーマンスを改善するにはリアルなシナリオが必要
- 闇雲に測定するのではなくリアルなシナリオに基づくこと
- ベンチマークテストをテストケースの1つとして追加し実行できるようにすること
- まずはどのように使われていてどのように速くなると嬉しいのか調べるところから
JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned.
- 榊原昌彦さん
Capacitor
- Webでアプリを作ってWebViewで表示できる
- ネイティブの機能にアクセスできる
- デスクトップアプリとしても作れる
Capacitorの使い勝ったあ
@capacitor/core@capacitor/cli
iOS
- SwiftをどうやってHTML/JSにつなげるのか
npx cap init- WebViewを100%表示されるものができる
- Poddileでnode_modulesの中から引っ張ってきてる
- HTML/JSがどうやってSwiftにアクセスしているか
- ブリッジがwindowオブジェクトに値を埋め込んでる
- Androidもだいたい同じ
