「JAMSTACK Meetup #1 with microCMS」に参加してきました
- JAMSTACK Meetup #1 with microCMSに参加してきました。
| タイトル | 発表者 |
|---|---|
| Janstack × microCMS実装編 | 柴田さん(microCMS) |
| Nuxt.js + microCMS + Netlifyでコーポレートサイトをリニューアルした話 | カンボさん(Re:Build) |
| WordPress（Shifter）をHeadlessCMSにした自社サイトをGridsomeとNetlifyで作ってる話 | 阿部さん(necco) |
| Jamstack で開発してすると、今までのつらみ😇がなくなって、ちょっとコストも下がる話 | shota_coffeeさん |
| GitHub Actionsで始めるお手軽Jamstack | 西畑一馬さん(トューアール) |
Janstack × microCMS実装編
- 柴田さん(microCMS)
Jamstackとは
Jamstackのいいところ
microCMSとは
- 日本製HeadlessCMS
- 技術構成
- AWS Amplify
- サーバーレス
- React
microCMSのいいところ
- 開発者と非開発者が使うけど双方に使いやすく
- GUIでAPIを作成
- 項目を選択して入力フォームを作る
- 入力して投稿した内容をAPIで取得できる
- 権限管理もできる(有料プラン)
- APIの構成(記事の入力フォーム)の作成までできる権限
- 記事の投稿だけできる権限
- 記事の下書きのみできる権限
- 画像の加工もURLで対応できる
- サイズとか
Jamstackの実装(Nuxt)
- 主な静的サイトジェネレーター
| Rest API | GraphQL | |
|---|---|---|
| React系 | Next.js | Gatsby |
| Vue系 | Nuxt | Gridsome |
- 動的なコンテンツ
- ビルド時にAPI叩いてURLを生成
- ブログ記事一覧をとってきて、みたいな感じ
まとめ
- Jamstackは速くてセキュアで安い
- microCMSすごい
- 実装はちょっとむずい(SPA詳しければできちゃう)
Nuxt.js + microCMS + Netlifyでコーポレートサイトをリニューアルした話
- カンボさん(Re:Build)
JAMstackの実装
- コーポレートサイトをJAMstack化
- レスポンス速度が向上
- Nuxt + Netlify + microCMS
- NuxtをNetlifyにデプロイ
- ビルド時にmicroCMSを叩いてデータを取得
- GitLabのmasterにプッシュされたら自動でビルドデプロイ
- microCMS
WordPress（Shifter）をHeadlessCMSにした自社サイトをGridsomeとNetlifyで作ってる話
- 阿部さん(necco)
Jamstackのいいところ
- コンテンツとフロントエンドの開発を分離できる
- 非エンジニアがどんどんコンテンツを更新できる
構成例
- Shifter
- Gridsome
- Vueベース
- GraphQL
- Netlify
- ホスティング
- Gridsomeをビルド
Jamstack で開発してすると、今までのつらみ😇がなくなって、ちょっとコストも下がる話
- shota_coffeeさん
CMS導入事例
- JS
- Nuxt
- Next
- API
- microCMS
- markdown
- hosting
- Netlify
- Firebase
- 変更可能性のあるものは全てAPIにする
- 編集者はコンテンツを気軽に変更できる
- 開発者は何も待たずにサクサク開発できる
- コミュニケーションコストが大幅に下がった
GitHub Actionsで始めるお手軽Jamstack
- 西畑一馬さん(トューアール)
Gatsbyのいいところ
Jamstackのデプロイフロー
「Mercari x Merpay Frontend Tech Talk vol.4」に参加してきました
- Mercari x Merpay Frontend Tech Talk vol.4に参加してきました。
| タイトル | 発表者 |
|---|---|
| Pros and Cons of SSR and JAMStack | @_sskyu |
| NoCode で CMS と連携するデザインツールを作っている話 | @miyaoka |
| TypeScriptで型安全に入門したい | @atsuco_02 |
| Web Assembly と画像・動画 | @Leonardo_engr |
Pros and Cons of SSR and JAMStack
- @_sskyuさん
SSRパフォーマンス
nuxt generate(JAMStack)
- nuxt generate
- NuxtでhtmlをSSR時ではなくビルド時に生成する
- 課題
JAMStackに移行
- キャッシュレスキャンペーンでJAMStackに移行
- 2019/10/1-2020/6/30に出してるキャンペーン
- 移行手順
- JAMStack環境作る
- 旧版と並行稼動
- 社内のみからアクセス
- 本番にデプロイ
- テスト
- 本番有効化
- 切り替え
- JAMStack環境作る
- staticなファイルなので全てFastlyで配信
- 以前はk8s上のNodeから配信
- URL
- 旧版と同じオリジンにおいた
- 新版のURLにネームスペース付けた
- そのままだとassets読み取れないけど相対パスで指定するようにして解決
Pros and Cons
- SSR
- サーバを運用してる
- オンコール体制
- スケールアウトでコスト増
- JAMStack
- 静的なassetを配信するだけなのでオンコール不要
- ぺらいちなサイトに向いてる
- 管理画面のようなサイトは不向き
- 静的なassetを配信するだけなのでオンコール不要
- パフォーマンスの比較記事
NoCode で CMS と連携するデザインツールを作っている話
- @miyaokaさん
Studio
- GUIでWebページが作れるサービス
- やってるユーザの操作に応じてstate更新して画面に反映してるだけ
- 操作してる人からするとGUIだけで画面が作れちゃう
- 課題
- 静的なサイトはこれでできる
- 動的なデータの概念がないので動的なサイトが作れない
動的ページを作る
CMSと連携
- zero configで使えるようにしたい
- 独自で作った
- CMSで作ったコンテンツをデザインに注入できるように
TypeScriptで型安全に入門したい
- @atsuco_02さん
型安全に入門したい
- 型安全の良さを理解したい
環境構築めんどくさそう
- CodeSandboxで環境構築いらず
TypeScriptって何者？
JSとTSの方の違い
- JSにも型ってあるよね
- JS
- 実行時に型を判別
- 自動で型変換される
- TS
- 実行前に型を判別
TSの型の良さ
- 型を明示的なので可能な操作が明確
- 暗黙的な変換がされない
- コンパイル時にある程度エラーがわかる
Web Assemblyと画像・動画
- @Leonardo_engrさん
JavaScriptだけで画像加工
- wasm-imagemagick
- あまりメンテされてない
- PWAのアプリが増えてきている
- 画像加工のような処理もクライアント側でやりたい
- ImageMagickにできることならだいたいできる
- 画像を比較してdiff出せたりする
JavaScriptだけで動画をエンコード
- ffmpeg.js
- あまりメンテされてない
- スマホの処理性能上がってきてる
- リアルタイムで画像にエフェクトとかアプリだとでてきてる
- WebWorkerと組み合わせて使えるように用意してくれてる
「#webbundle_study」に参加してきました
webbundle_studyに参加してきました。
| タイトル | 発表者 |
|---|---|
| Web Packaging: Web Bundles | @horo |
| WebPackaging Spec | @jxck |
Web Packaging: Web Bundles
- @horoさん
Web Packaging
- Webリソースをひとまとめにする技術
- W3Cで検討されている仕様
- その中にWeb Bundles
Web Bundles
- HTTPリソースをまとめるための仕様
.wbn- 近くにいる人にwbnをシェアすることもできる
- アプリで
- USBで
- ファイルがローカルにあるので表示がはやい
Web Bundleの作り方
- goのコマンドライン
- gen-bundle
- npmライブラリのwbn
Subresources Web Bundles
- linkタグでwbnからとってくると指定できるようになる
- htmlごとbundleするのではなくcssとかjsだけbundleするようなシーン
Page Web Bundle
- 同一originでなくても同一originのようにロードできる
- アセットがたくさんあるような場面で使うイメージ
Save as Web bundle
- ページを右クリックからwbnで保存できるようにする
- 印刷して保存するような雰囲気
- cacheにアクセスしたりとかはできない
TWA
- PWAをPlayストアにAndroidアプリとしてあげられる
- 動きとしては特定のURLを開く
- 課題として初回アクセス時オフラインだと表示できない
- Web Bundleでかいけつできるのではないか
WebPackaging Spec
WebPackaging Spec
- SXG
- Web Bundles
- Loading
Web Bundles Spec
- どういう風にbundleが動くかしか定義してない
- arrayをcborというフォーマットでバンドルする
- index/response/signetureなどどこに入ってるか決まってるから全部パースしなくても欲しい情報をとれる
- zipとかだとそういうことできないからわざわざwbnを使ってる
- どのaccept-type来たらどのcontent-type返すかとかハンドリングできる
- 多言語用意しておいてaccept-languageによってどれ返すか制御したりとかが想定ユースケース
- 配布することも考えると多言語全て入れておいた方がいいかもとかっていう話も
- bundleしてる各ファイルに対して署名しないといけない
Serve Web Bundle
- HTTP
Content-Type: application/webbundle X-Content-Type-Options: nosniff
「年の瀬に振り返る Figma & React コンポーネントでのサービス開発」に参加してきました
| タイトル | 発表者 |
|---|---|
| Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方 | 伊東 将太 |
| 2019年の Atomic Design コンポーネント設計 | 原口 渉 |
| パネルディスカッション | 横井 麻里乃 / 小林 春彦 |
Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方
- 伊東 将太さん
FigmaでUIコンポーネントを運用
- どんなコンポーネントがあるか視認性を高めたい
- 操作感を確かめられるようにしたい
- AtomicDesign
- Atomsはデザイナー
- それ以降は実装しながら
- デザイナーとフロントエンドエンジニアの協業が楽になった
運用していく中で
- 前に似たようなコンポーネントあったような・・・
- UIコンポーネント集はFigma
- どういう目的でどういう画面で使われてるかを見られるドキュメントがない
- ガイドラインはあるけどその背景が書かれたものがない
デザインシステム
- デザイン原則
- ガイドライン
- カラーパレット
- アイコン
- パターンライブラリ
Storybook
- コードでデザインシステムを可視化できるのがいい
- より本番に近い状態
まとめ
- プロダクトの方向性を明確にして開発効率/一貫性を向上したければ取り入れる価値ありそう
2019年の Atomic Design コンポーネント設計
- 原口 渉さん
マークアップ
コンポーネント推進PJ
共通コンポーネントの反映
- せっかく用意してあるのに使われていないページがあった
- 同じコンポーネントｗｐそれぞれで実装しているため修正もれやデザインのばらつきが起きる
- 共通ライブラリを変更したら利用者も更新されるようにした
- プライベートなnpmリポジトリ化してる
コンポーネントの粒度と命名規則の策定
- 明確に決めてなかったので作業者によってばらついていた
- 似た見た目でもコンポーネントを分ける
- 再利用性は副次的なものと考えた
- OrganismsとMoleculesの基準
- 単体で意味を成せばOrganisms
- 命名規則
- Page名を接頭辞につける
課題管理フローの策定
- JIRAで可視化
プロダクトとStorybookの状態が異なる
- 本番だけ反映されてStorybookが更新されていないことがあった
- storiesのファイルを先に書くようにした？
- 定期的にチェックするようにした
まとめ
- デザイナーとエンジニアで共通の認識を持つことができた
- デザイナーと連携とりやすくなった
パネルディスカッション
- 横井 麻里乃さん
- 小林 春彦さん
なぜAtomicDesign
組織的なコンポーネント運用の課題
- リリース優先でコンポーネントをきれいに運用することは後回しになりがち
- Atomsだけはきれいに管理すると決めている
- 同じ設計ルールで誰でも作れるようにする工夫が必要
- 自動化とか仕組み化をしていきたい
なぜFigma
「【We Are JavaScripters! 3周年記念】 WeJS Festival !」に参加してきました
- 【We Are JavaScripters! 3周年記念】 WeJS Festival !に参加してきました。
- WeJSの3周年記念のイベントに参加してきました
- 自分が初めてWeJSに参加したのも2017年7月に開催された9thなのでもう2年以上前です。勉強会に行き始めたころなので懐かしいものです。
| 発表枠 | タイトル | 発表者 |
|---|---|---|
| 初心者LT | はじめてのユニバーサルJavaScript | @りゅーそう |
| 初心者LT | A story about making a cli twitter client with typescript | @azawakh |
| 初心者LT | styled-components の ` ←について | @kimizuy |
| 初心者LT | 逆算して考える広告ライブラリ | @ta__ho |
| 初心者LT | Node.js/serverlessでおこなうDX改善 | @Ayami Otani |
| 通常LT | おさらいVue Composition API | Morita_Masatoshi |
| 通常LT | Lighthouse CI入門 | @yinm |
| 通常LT | Reactの歴史 | @mqtsuo02 |
| 通常LT | 執筆の進捗を支える技術〜Could RunでBot作ったらとても便利だった件〜 | @kyasbal |
| 通常LT | angular歴3ヶ月がAngularと本気で向き合ってみた | @EmiYaegashi |
| Demo LT | PlayCanvasでできたこととデモ | @sushucorn |
| Demo LT | TensorFlow.jsとobnizで作る笑顔あふれる職場 | @boiyama |
| Demo LT | Ma_gician ＜Vue にはできないこと(2)＞ | @StewEucen |
| Demo LT | 今日から始めるWeb USB | @takanorip |
| Demo LT | Joy-ConをJavaScriptでプレゼンリモコンにした話 | @mascii_k |
| Short Session | Introduction to ReasonML | @Naturalclar |
| Short Session | JSXでつくる宣言的プレゼンテーション | @mottox2 |
| Short Session | JSでの時間の使い方の話 | @chikoski |
| Long Session | Behind the scene | @brn227 |
| Long Session | Babel plugin を作って AST と Babel を学ぶ(ライブコーディング) | @mki_skt |
Introduction to ReasonML
- @Naturalclarさん
Reason
- State of JS 2018
- 半分は聞いたこと無い
- 使ってる人の満足度は高い
- Reactの作者Jordan Walkeが作っている
- Ocamkを別のSyntaxで書いたもの
- 強力な型
- BuckleScript
- JSにトランスパイルする
- 特徴
- JSのように書ける
- React書ける人は馴染みやすい
- 利点
- ビルドが高速
- 規模が大きくなっても数秒
- バンドルサイズが小さい
- 結果が自明なものはトランスパイル時に変換してくれる
- Prettier完備
- もともとはReasonのフォーマッターが優秀でそれをJSでも使えるように作ったのがPrettier
- 型安全性
- エラーメッセージがわかりやすい
- ビルドが高速
- gentype
- tsxを生成したりできるライブラリ
- 徐々に移行したいときはこれを使うといい
- reason-react-native
- reason-native
JSXでつくる宣言的プレゼンテーション
- @mottox2さん
KOBIT
- GoogleAnaryticsと連携するとPowerPointのレポートができるサービス
- PowerPointはzipされたxmlの集合体
- レポートなのでmarkdown to pptxでは表現できない
課題
- コードから生成後の見た目が想像しづらい
- JSXで宣言的に書く
- 座標計算が大変
- ReactNativeのようにFlexboxレイアウトで考えたい
- Yoga
- JSXからSketchを生成するReact Sketch.appを参考に
仕組み
- react-test-renderer
- JSXをObject化できる
JSでの時間の使い方の話
- @chikoskiさん
JavaScriptの実行タイミング
- どんな順番で呼ばれるの？
- addEventListener
- requestAnimationFrame
- requestIdleCallback
EventQueue
- タスクはキューにたまっていく
- キューの中の処理でスタックがたまっていく
- いろんな処理が全て同じキューに溜まっていく(メインスレッド)
- Chromeのdevtoolsのperformanceでタスクキューを見れる
実行の順序
- Dont yield
- 普通のJSの処理
- Microtask
- awaitとか
- requestAnimationFrame
- Inter-frame
- requestIdleCallback
- CPUが暇な時に動く
Worker
- 全部メインスレッドでやるのをやめようという話もある
- UIスレッドをわける
- Worker
- EventQueueをもう1つ作る
- 並列に実行される
- コンストラクタの第2引数に
{type: module}でESModulesも使えるようになる - postMessageはJSオブジェクトなら渡せる
- コピーして渡される
- 処理時間は無視できる程度
- コピーして渡される
- Comlink
- postMessageを抽象化してくれる
- SchedulingAPI
- 無限ループを書きたい時
- priorityを設定できるようになる仕組みも考えられている
- それを使えばブロックしないようにできる
Behind the scene
- @brn227さん
Scriptのクリティカルパス
- HTMLをparse
- リソースをfetch
- V8が実行
Resource Fetch
Scriptタグの種類
- ClassicScript
- 普通のscriptタグ
- ModuleScript
- ESModleに対応したscriptタグ
- import/exportを解決できる
- Async
- scriptタグの順番待ちが発生しないロードも実行も非同期
- Defer
- ロードは非同期だけど実行は順番を待つ
Connection
- HTTP1.1だと同時接続数の上限がある
- 大抵のブラウザは6まで
- なので非同期で同時にたくさん取りに行っても上限を超えると待たされる
- HTTP2だと1つのコネクションで複数のやりとりできるので解決される
Fetching
- ブラウザキャッシュがあるかチェック
- ETag
- リソースに対して一意に発行されるハッシュ
- Cache-ControlとETagを組み合わせてキャッシュを使うか決める
- ServiceWorker
- リクエストをインタラプトできる
- ChacheStorageに入れておいてそれを返すことができる
- ETag
最適化
- Preload
link rel=preload- 事前にリソースをリロードさせておける
- Compress response
- gzipではなくBrotliを使うと更に圧縮率高められる
- CDN
- 地理的に近いところから取得
- webpackプラグイン
- Workbox
- sw-precache
- Code Splitting
- 必要なものだけを取得できるように
Futuer
- HTTP/3 Quic
- Transport層を置き換える
- Priority-hints
- linkやscriptにimportance属性が追加される
- highがついてれば優先的に取得する等
- WebBundle/WebPackaging
- Webのコンテンツを1つにパッケージングして配信
- 画像でも動画でも全部
- request/responseとか証明書とかも
- Webサイトまるごとpackagingして配信して使える
- Webのコンテンツを1つにパッケージングして配信
Parsing
- fetchしたscriptをASTに変換するフェーズ
- parse処理は重い
- ページする度に全部parseしてるとおもすぎる
- 最初は関数と行数だけparseしておく
- 呼び出されると関数の中身までparse
- parseも全部メインスレッドで動いている
- parseが始まった段階でHTMLの表示がとまる
- deferとかasyncをつけると変わる
Streaming
- Streamingで逐次取得しながらparseする
bundle size
- 50-100KB目安に分割するとよい
- モバイルとかも考えると
- CPU/メモリ使用量がかかる
Transpile
- 古いブラウザようのコードは新しいブラウザにとっては無駄なコード
- ブラウザに応じて調整すると無駄なものを減らせる
JSON.parse
- objectにこれをつけておくと遅延してparseされるのではやくなる
Polyfill
- CoreJS全部入れちゃったりすると無駄が多すぎる
- polyfill.ioを使って必要なものだけにするといい
Futuer
- Binary AST
- ASTで直接配信する
- ブラウザごとに共通仕様ができればいける
Babel plugin を作って AST と Babel を学ぶ(ライブコーディング)
- @mki_sktさん
AST
- Abstract Syntax Tree
- 抽象構文木
- プログラムの構造を示したデータ
- JSではJSON
- 仕様はESTreeに準拠
- AST Explorerを使うとJSのコードがどう変換されるか見られる
Babel
- JSのコンパイラー
- もともとは6to5だった
- ES6 to ES5
- そこからいろんな機能が追加されていった
- 新しい構文で書いたJSを古いブラウザでも動かしたい時に使う
構文変換
- TS/JSX/JSなど -> Babel -> JS
- 変換のフェーズ
- Parsing
- Transformation
- Code Generate
Parsing
@babel/parser- コードをparse関数に通すとJSONで出力される
- acorn
- 軽量なJS parser
- webpackで使われてる
Code Generate
@babel/generate- ASTをJSに変換する
Transformation
@babel/traverse- constとletをvarに変えるといった変換を行う