「JAMSTACK Meetup #1 with microCMS」に参加してきました

  • JAMSTACK Meetup #1 with microCMSに参加してきました。

re-build.connpass.com

タイトル 発表者
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とは

  • Webサーバに依存しないサーバーレス
  • 事前にビルドした静的ファイルをCDNで配信
  • APIはJS経由で呼び出す

Jamstackのいいところ

  • 静的ファイルをホスティングするだけでいい
  • APIコールはビルド時のみ
  • 高セキュリティで高パフォーマンス
    • 静的ファイルをCDNで配信するだけだから

microCMSとは

  • 日本製HeadlessCMS

microcms.io

  • 技術構成
    • AWS Amplify
    • サーバーレス
    • React

microCMSのいいところ

  • 開発者と非開発者が使うけど双方に使いやすく
  • GUIAPIを作成
    • 項目を選択して入力フォームを作る
    • 入力して投稿した内容を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
    • APIのクエリがいろいろあってドキュメントも親切(日本語)
    • APIのレスポンスのプレビューも見られる

WordPress(Shifter)をHeadlessCMSにした自社サイトをGridsomeとNetlifyで作ってる話

  • 阿部さん(necco)

Jamstackのいいところ

  • コンテンツとフロントエンドの開発を分離できる
  • 非エンジニアがどんどんコンテンツを更新できる

構成例

Jamstack で開発してすると、今までのつらみ😇がなくなって、ちょっとコストも下がる話

  • shota_coffeeさん

CMS導入事例

  • JS
    • Nuxt
    • Next
  • API
  • hosting
    • Netlify
    • Firebase
  • 変更可能性のあるものは全てAPIにする
    • 編集者はコンテンツを気軽に変更できる
    • 開発者は何も待たずにサクサク開発できる
  • コミュニケーションコストが大幅に下がった

GitHub Actionsで始めるお手軽Jamstack

  • 西畑一馬さん(トューアール)

Gatsbyのいいところ

  • GatsbyのImage
    • 画像をいろんな形式いろんなサイズにビルドしてくれる
    • LazyLoadしてる間スケルトン出してくれる

Jamstackのデプロイフロー

  • 一連の流れ
    • pushしてコンテナでクローンビルドされてデプロイされる
  • コード管理
  • CI
    • GitHub Actions
    • GitLabCI
    • CircleCI
    • Jenkins
  • ホスティング
    • Netlify
    • now
    • S3
    • FirebaseHosting
    • GitHub Pages
  • プレイヤーが多くてややこしい

「Mercari x Merpay Frontend Tech Talk vol.4」に参加してきました

  • Mercari x Merpay Frontend Tech Talk vol.4に参加してきました。

mercari.connpass.com

タイトル 発表者
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パフォーマンス

  • キャンペーンページのSSRのパフォーマンスがでない
    • NuxtでSSRしてる
  • Podをスケールして負荷に耐えていた(20Pod)
    • 単純なLPを配信したいだけなのに...
  • 負荷試験してみた
    • コンテンツの量でrpsに差が出た
    • SSRしない範囲を増やすと多少改善できた

nuxt generate(JAMStack)

  • nuxt generate
    • NuxtでhtmlをSSR時ではなくビルド時に生成する
  • 課題
    • nuxt generate時にuseragentがとれない
      • ios/android/web/appのwebviewで画面が違う
      • navigator.userAgentSSR時はとれない
      • v-showisAndroidとか使えばSSR時はotherになるけどクライアント側で正しい値取れて画面出せる

JAMStackに移行

  • キャッシュレスキャンペーンでJAMStackに移行
    • 2019/10/1-2020/6/30に出してるキャンペーン
  • 移行手順
    • JAMStack環境作る
      • 旧版と並行稼動
      • 社内のみからアクセス
    • 本番にデプロイ
      • テスト
    • 本番有効化
      • 切り替え
  • staticなファイルなので全てFastlyで配信
    • 以前はk8s上のNodeから配信
  • URL
    • 旧版と同じオリジンにおいた
    • 新版のURLにネームスペース付けた
      • そのままだとassets読み取れないけど相対パスで指定するようにして解決

Pros and Cons

  • SSR
    • サーバを運用してる
    • オンコール体制
    • スケールアウトでコスト増
  • JAMStack
    • 静的なassetを配信するだけなのでオンコール不要
      • ぺらいちなサイトに向いてる
    • 管理画面のようなサイトは不向き
  • パフォーマンスの比較記事

developers.google.com

NoCode で CMS と連携するデザインツールを作っている話

  • @miyaokaさん

Studio

  • GUIでWebページが作れるサービス
  • やってるユーザの操作に応じてstate更新して画面に反映してるだけ
    • 操作してる人からするとGUIだけで画面が作れちゃう
  • 課題
    • 静的なサイトはこれでできる
    • 動的なデータの概念がないので動的なサイトが作れない

動的ページを作る

CMSと連携

  • zero configで使えるようにしたい
    • 独自で作った
  • CMSで作ったコンテンツをデザインに注入できるように

TypeScriptで型安全に入門したい

  • @atsuco_02さん

型安全に入門したい

  • 型安全の良さを理解したい

環境構築めんどくさそう

  • CodeSandboxで環境構築いらず

TypeScriptって何者?

  • TSはJSにコンパイルされるスーパーセット
  • コンパイル前に型チェックが行われる
  • 値に対して型が決まると実行できる操作が明確になる=型安全
    • 型があると操作が限定される=>意図せぬエラーが防げる

JSとTSの方の違い

  • JSにも型ってあるよね
  • JS
    • 実行時に型を判別
    • 自動で型変換される
  • TS
    • 実行前に型を判別

TSの型の良さ

  • 型を明示的なので可能な操作が明確
  • 暗黙的な変換がされない
  • コンパイル時にある程度エラーがわかる

Web Assemblyと画像・動画

  • @Leonardo_engrさん

JavaScriptだけで画像加工

github.com

  • PWAのアプリが増えてきている
    • 画像加工のような処理もクライアント側でやりたい
  • ImageMagickにできることならだいたいできる
  • 画像を比較してdiff出せたりする

JavaScriptだけで動画をエンコード

  • ffmpeg.js
    • あまりメンテされてない

github.com

  • スマホの処理性能上がってきてる
    • リアルタイムで画像にエフェクトとかアプリだとでてきてる
  • WebWorkerと組み合わせて使えるように用意してくれてる

「#webbundle_study」に参加してきました

  • webbundle_studyに参加してきました。

web-study.connpass.com

タイトル 発表者
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の作り方

www.npmjs.com

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 コンポーネントでのサービス開発」に参加してきました

spacemarket.connpass.com

タイトル 発表者
Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方 伊東 将太
2019年の Atomic Design コンポーネント設計 原口 渉
パネルディスカッション 横井 麻里乃 / 小林 春彦

Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方

  • 伊東 将太さん

FigmaでUIコンポーネントを運用

  • どんなコンポーネントがあるか視認性を高めたい
  • 操作感を確かめられるようにしたい
  • AtomicDesign
    • Atomsはデザイナー
    • それ以降は実装しながら
  • デザイナーとフロントエンドエンジニアの協業が楽になった

運用していく中で

デザインシステム

  • デザイン原則
  • ガイドライン
  • カラーパレット
  • アイコン
  • パターンライブラリ

Storybook

  • コードでデザインシステムを可視化できるのがいい
    • より本番に近い状態

まとめ

  • プロダクトの方向性を明確にして開発効率/一貫性を向上したければ取り入れる価値ありそう

2019年の Atomic Design コンポーネント設計

  • 原口 渉さん

マークアップ

コンポーネント推進PJ

共通コンポーネントの反映

  • せっかく用意してあるのに使われていないページがあった
    • 同じコンポーネントwpそれぞれで実装しているため修正もれやデザインのばらつきが起きる
  • 共通ライブラリを変更したら利用者も更新されるようにした

コンポーネントの粒度と命名規則の策定

  • 明確に決めてなかったので作業者によってばらついていた
  • 似た見た目でもコンポーネントを分ける
    • 再利用性は副次的なものと考えた
  • OrganismsとMoleculesの基準
    • 単体で意味を成せばOrganisms
  • 命名規則
    • Page名を接頭辞につける

課題管理フローの策定

  • JIRAで可視化

プロダクトとStorybookの状態が異なる

  • 本番だけ反映されてStorybookが更新されていないことがあった
    • storiesのファイルを先に書くようにした?
    • 定期的にチェックするようにした

まとめ

  • デザイナーとエンジニアで共通の認識を持つことができた
  • デザイナーと連携とりやすくなった

パネルディスカッション

  • 横井 麻里乃さん
  • 小林 春彦さん

なぜAtomicDesign

  • photoshopのファイル数が150超
    • 管理しきれなくなった
  • もともとデザイナーとエンジニアで別リポジトリで同じようなもの管理してた

組織的なコンポーネント運用の課題

  • リリース優先でコンポーネントをきれいに運用することは後回しになりがち
    • Atomsだけはきれいに管理すると決めている
  • 同じ設計ルールで誰でも作れるようにする工夫が必要
    • 自動化とか仕組み化をしていきたい

なぜFigma

  • いろいろ変遷してる
    • コミュニケーションがしやすいからFigmaにした
    • Figmaにコメント書くとSlack連携できるように

「【We Are JavaScripters! 3周年記念】 WeJS Festival !」に参加してきました

  • 【We Are JavaScripters! 3周年記念】 WeJS Festival !に参加してきました。

wajs.connpass.com

  • 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で宣言的に書く
  • 座標計算が大変
  • JSXからSketchを生成するReact Sketch.appを参考に

仕組み

  • react-test-renderer
    • JSXをObject化できる

github.com

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に入れておいてそれを返すことができる

最適化

  • 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して配信して使える

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のコードがどう変換されるか見られる

astexplorer.net

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に変えるといった変換を行う

ライブコーディング

github.com