Core Web VitalsのFID から INP に変わったという内容で話してみました。CWVとの付き合い方として参考になれば…！
00:00 OP
02:11 CWVとは
13:09 計測するメリット
22:17 CWVとの付き合い方
26:46 クロージング
1. 3/12 から CWV の指標が FID から INP に変わったよ
2. Web パフォーマンスの話
3. CWV ってなに？
4. FID、INP ってなに
5. FID から INP に変わってどうなるの？
## 3/12 から Interaction to Next Paint(INP) が Core Web Vitals の主な指標に
https://web.dev/blog/inp-cwv-march-12?hl=ja
- First Input Delay(FID)から INP に置き換わる
実際にLighthouseでFIDがINPに変わってる
## レスポンスタイムについてのヤコブニールセンの研究 Jakob Nielsen, “Website Response Times,” (2010)
https://www.nngroup.com/articles/website-response-times/
- 0.1 秒 … 即時に感じられる。キー入力やドラッグアンドドロップなどの Direct Manipulation においては満たしたい時間
- 1 秒 … 遅延は認識しているがユーザーがフローをシームレスと感じられる時間。ナビゲーションで満たしたい基準
- 10 秒 … ユーザーが注意を持ち続けられる時間。これ以上経過すると他のことを考えるようになる。
他の事例からも、Web パフォーマンスはユーザーの生産性と大きく関係してる
## Core Web Vitals (CWV) とは
https://web.dev/articles/vitals?hl=ja
- ユーザー体験に関する指標
- 3/12 以前までは
- FID
- ユーザーがページを表示してから最初の操作(クリック)からブラウザが反応するまでの時間
- 操作性
- Largest Contentful Paint(LCP)
- 最初にページに移動したときに、ビューポートに表示される最も大きなコンテンツのレンダリング時間
- ローディング
- Cumulative Layout Shift(CLS)
- ページが表示されるまでに発生するレイアウトのずれ
- レイアウトの安定性
- 3/12 以降は
- INP
- LCP
- CLS
- それぞれの指標はいずれも Performance API で取得できる
- https://developer.mozilla.org/ja/docs/Learn/Performance/Measuring_performance#%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9_api
- INP で使用する API やプロパティは Chrome のみが対応してる
- https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming
- それぞれの指標は 75%タイルで下記の値以下だと Good、つまり良いユーザー体験が提供できてるって言える
- INP: 200ms
- LCP: 2.5s
- CLS: 0.1
## INP とは
https://web.dev/articles/inp?hl=ja
- FID と大きく変わった点は、ユーザー操作に対してブラウザが反応するまでの時間をずっと計測すること
- FID では最初の操作のみだった
### INP 改善事例
- https://web.dev/economic-times-inp/
- INP が改善されたことで PV が 43%増加
- https://web.dev/redbus-inp/
- INP を改善し、売上を 7%増加させた
## FID から INP になって何が変わるのか
- 個人の感想だけども、より今の Web アプリケーションに即したユーザー体験を計測できるようになったのではと
- 最近の Web アプリは、画面に対してユーザーが操作する部分が増えてる
- 操作に対して実際にユーザーがどんな体験をしているのか、INP によって詳細にキャッチできそう
今回はnus3とReactのフレームワークであるRemixについて色々話してみました
00:00 OP
00:21 イントロ・Remixの概要
03:50 Remixに触れてみての所感
10:53 vs Next.js
23:20 Remixの気になりポイント
28:00 まとめと次回予告
半年ぶりの収録だったので去年の振り返りと雑な会話を収録しつつ、筋肉は大事だという話をしました
今回はnus3とFLEXY主催の「フロントエンドテストはじめの一歩」に登壇した内容を含めて後日談や当日の話題について深掘りして話しています
00:00 OP
00:22 雑談(体調と車)
02:34 今日のテーマについて
04:28 収録の雰囲気
06:53 当日のトークテーマについて
32:04 ED
今回は2023年5月にVercelから発表されたVercel Security, Collaborate, Ecosysteについて喋っていきます
00:00 OP
00:21 雑談
01:07 今回のテーマ
01:48 Vercel Security
- https://vercel.com/docs/security
07:28 Collaborate
- https://vercel.com/docs/workflow-collaboration
- Vercel Spaces
- Visual Editing
23:55 Ecosyste
- https://vercel.com/blog/authentication-for-the-frontend-cloud
- https://vercel.com/blog/nuxt-on-vercel
32:04 クロージングと次回のテーマ
今回は2023年5月にVercelから発表されたVercel Storageという新しいストレージサービスについて喋っていきます
後半でエッジ環境における勘所やVercelのサービスのあり方についても話しています
00:00 OP
00:21 今回のテーマ
01:00 Vercel Storageの概要
- https://vercel.com/docs/storage
07:54 Vercel KV
10:21 Vercel Postgres
18:08 Vercel Blob
20:09 Vercel Edge Config
20:39 Vercel Storageのメリットデメリット
24:19 VercelとCloudflareの連携・Vercelのサービスのあり方
31:28 クロージングと次回のテーマ
今回は僕自身が転職したことを踏まえてnusさんと一緒にエンジニアの転職について話をしていきました
00:00 OP
00:21 雑談
01:30 今回のテーマと近況
06:45 中途だと身構えちゃうよね
09:19 企業文化の話
14:50 今回の応募経路について
18:08 今回の転職活動について
26:16 「40代よわよわエンジニアの転職」から考えるキャリアについて
- https://anond.hatelabo.jp/20230415000359
32:15 クロージング・次回について
このエピソードではChatGPTを使ったコーディングに対しての問題点、リスク要因、技術スキルについて話し合われています。ChatGPTは事前に学習されたデータに基づいて応答を生成するため、バイアスや再学習によるコストについても議論されています。しかしその一方で、個人がGPTを活用する方法や、プログラム開発者が必要とするスキルについての話もしています。また、ChatGPTを使ってコードを生成できるようになるとエンジニアの職務にどのような影響が出るか、これからの時代に備えて求められるスキルに注目し、自分のやりたいことを追求しながら学ぶことについての議論もしています。ChatGPTによってエンジニアの仕事がどのように変わっていくか興味深い話題です。
00:00 OP
00:20 今回のテーマ
05:20 ChatGPTを用いて生成したコードに関する懸念点
09:06 エンジニアリングで長生きする領域についての話題
13:31 ChatGPTを利用する上でのリスク、セキュリティについて、攻撃手法やバイアス
27:50 OpenAIの動向についての話題
30:13 クロージング
本エピソードでは、ChatGPT, GPT-4モデルについて雑感を話しています。GPT-4は、GPT-3とは異なり性能の大幅な向上が期待されるモデルとして、特に日本語においての精度も高くなっています。また、ChatGPTとBingAIなどの違いについても話していて、聞き手は普段の開発や子供たちが今後学ぶべきことなどを考えさせられます。GPTの利用規約や著作権についての問題や、プロンプットエンジニアリングについても言及されています。エンジニア以外の方にも興味深い話題が含まれているため、おすすめのエピソードです。
00:00 OP
00:19 雑談
02:39 今回のテーマ
04:59 GPTによる機械学習とその特徴
06:00 機械学習の問題点とGPT-3・4の違い
11:00 GPT-3.5とGPT-4の精度の違い
13:07 GPT4による精度向上についての話題
15:02 GPT4によるマルチモーダル応答の検証や使用についての話題
17:02 コーディング補完とGitHub Copilot、GPT
19:38 利用規約,著作権,GPT
23:47 Bing AIとプロンプトエンジニアリング
27:56 前半の締めと後半のつなぎ
今回はDenoが出していた記事を軸にWebのレンダリング方式がSSRになっていくかもねぇという話をしました
00:00 OP
00:30 今回のテーマ
06:53 isomorphic javascriptと各フレームワーク
24:51 universal javascriptとそれにまつわる視点
32:39 クロージングと次回予告
[参考] https://deno.com/blog/the-future-and-past-is-server-side-rendering
## 記事の概要
- Deno から Web の過去と未来は Server Side Rendering というタイトルの記事が公開
- 記事の序盤には、これまでの Web アプリケーションの歴史が紹介
- PHP による SSR の例
- 動的な部分はテンプレートエンジンを使ってサーバーサイド側でレンダリングしてた
- ブラウザや JavaScript の機能が拡充したことで、SPA や CSR の流れに
- さらに Web が成熟してきたことで、さまざまなデバイスや帯域幅でアクセスされるようになってきた
- デバイスのスペックや不安定な回線でアクセスされる状況といった状況の中で一貫したユーザー体験を提供するには SSR なのでは
- SSR をサポートする Isomorphic JavaScript なフレームワークが存在する
- Isomorphic JavaScript はクライアント・サーバーサイド両方で JS が実行されるアプリケーション
- Isomorphic JavaScript フレームワークとして Next.js や Remix が挙げられてる
- 昔の SSR との違いでもありそう
- Deno が気に入ってるアプローチは Islands Architecture
- 実際に Deno の Web フレームワークである Fresh が採用している
- 静的な部分はサーバーサイド側で HTML をレンダリングし、動的な部分だけハイドレートする
- HTML のレンダリングはサーバーサイドで行い、その後、イベントハンドラーを HTML 要素にアタッチ
- Deno の場合は Fresh と Deno Deploy でできる
- なるべくクライアントサイド側の JS を減らす機能は各フレームワークから提供されてそう
- [Next.js Server and Client Components](https://beta.nextjs.org/docs/rendering/server-and-client-components)
- SSR がベースな Remix や Qwik
- [Qwik ではユーザーの操作が行われてから JS をダウンロードして実行する Resumable というアプローチ](https://qwik.builder.io/docs/concepts/resumable/)
- [SolidJS も Isomorphic な機能を備えてる](https://www.solidjs.com/guides/server#%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%82%B5%E3%82%A4%E3%83%89%E3%83%AC%E3%83%B3%E3%83%80%E3%83%AA%E3%83%B3%E3%82%B0)
- Cloudflare や Deno Deploy、Vercel、netlify、など Edge 上で JS が実行(SSR)できる選択肢が増えた
今回は前回に話した成人学習の効率を高めるための方法論に続いて、知識を記憶しておく力を高める方法を
知ったかぶり脳科学の側面から深堀りしていきました
00:00 OP
00:30 今回のテーマ
01:14 記憶の種類
07:34 記憶力を高めるには
24:33 エンジニアの開発言語と記憶
26:25 クロージング
# 記憶力を高める
## 記憶の種類
記憶の固定化: 短期記憶から長期記憶に移る過程
短期記憶: 学習から数時間
長期記憶: 学習から1日から生涯保持
（遠隔記憶の一部）遠隔記憶: システムレベルの固定化
短期・長期記憶の一部は海馬に蓄えられる
遠隔記憶は脳の大脳皮質にある側頭葉の側頭連合野に蓄えられる
つまり、遠隔記憶は海馬の記憶障害から切り離される
短期→長期→遠隔はsession storage→IndexDB→RDBのようなイメージ？
## どうやって記憶効率を上げるか？
1. 記憶において睡眠が重要「覚醒時に経験した情報が睡眠中に再生されている」
→ 学習後に安定的な睡眠を行うことで記憶の固定化が促される
2. 記憶は脳の大脳皮質にある側頭葉の側頭連合野に蓄えられる
→ 側頭連合野は五感や、行動動機、心的態度などを統合する
多くの「モダリティ」に働きかけたほうが、記憶が定着しやすい
海馬記憶のうち、何度アクセスされたもの「重要である」と判断
→ 側頭葉に送られて、遠隔記憶として定着する
3. 海馬は加齢やストレスで機能低下する（一方でストレスフリーやエクササイズで神経新生が促進される）
4. 鮮烈な体験により、些細な出来事の記憶が固定化される
→ 些細な出来事と鮮烈な出来事が短い間隔で生じた場合のみ
# 参考
- https://bsd.neuroinf.jp/wiki/%E8%A8%98%E6%86%B6%E5%9B%BA%E5%AE%9A%E5%8C%96
今回は大人になってから学ぶことが多くなった上で、どうやって学習効率を高めればいいかの視点で「アンドラゴジーとペタゴジー」という内容の話をしました
次回の「記憶力をどう高めればよいか」という話につなげています
00:00 OP
00:30 今回のテーマ
03:52 自己認識
06:29 経験
07:41 レディネス
10:06 方向づけ
11:52 動機づけ
14:06 内発的動機づけの強い子どもたちの存在
18:29 自分たちに不足していること
23:38 (雑談) 先生不足問題
25:29 記憶力の話
28:34 クロージングと次回の記憶力の話
アンドラゴジーとは、自己主導的な学習を用いた成人学習理論
# 成人の学習と子どもの学習
## 5つの違い
- 自己概念
- 経験
- レディネス
- 方向づけ
- 動機づけ
### 自己概念
自分がどんな人間であるか？」という問いかけに対して、自身が持っている考え
- 成人の場合
⭕学習者が主導だということを認識してもらえるように設計していく
❌教育者が一方的に情報を発信するだけの教育や、教育者が作り上げたものをただ受けるだけ
- 子どもの場合
一般的な学校教育では受動的な学習が一般的
### 経験
- 成人の場合: 有り
⭕新しく学んだ法則に当てはまる過去の体験を思い出してもらう
- 子どもの場合: 無し
### レディネス
何かを学習する際に必要となる条件や、心身の準備、環境などが整っており、学習の準備ができている状態を表す
- 成人の場合
⭕社会的な役割=職業や役職、職位にフォーカスして学習者の課題を捉える
ex: マネージャーに昇進した人には、「マネジメントを基本から学ぶ」
- 子どもの場合
年齢やカリキュラムにフォーカスする
### 方向付け
「なんのために学習するのか」という学習の目的に関する観点
- 成人の場合
⭕学んだ知識やスキルを活用・応用することで、直近の課題を解決する（逆算的）
- 子どもの場合
「教材の内容を理解する」「テストでいい点を取る」といったことが主な目的
### 動機付け
- 成人の場合: 内発的動機付け
⭕興味・関心・趣向・願望といった人の内側にあるものによる動機付け
- 子どもの場合: 外発的動機付け
「テストでいい点を取って親にほめられる」ことや、「先生や親に叱られない」
## まとめ
成人学習理論とはいえ理論的には「教育者のための理論」の色が強く
学習者の効率を上げる要素は少ない…
# 参考
- https://achievement-hrs.co.jp/ritori/andoragogy/
今回はnus3が参加してきた「BuriKaigi 2023」のあと話をしています
BuriKaigiとは？という話から実際に登壇した際の話や懇親会の内容を喋りました
00:00 OP
00:30 雑談
02:04 今回のテーマ
09:54 (脇道) Astroについて
13:22 nus3の登壇概要
16:21 nus3の発表内容
25:51 懇親会
28:35 クロージング
- 1/21 に BuriKaigi2023 で富山に行ってきました
- 寒ぶりとテクノロジの旬を味わうイベント
- ３レーンあって、参加したいセッションを見に行く感じ
- 色んな分野の人がいた
- オフラインで登壇、懇親会って流れは、はじめてだったけど楽しかった
- 参加してる人の反応を見ながら、発表できるのはよかった
- オフラインの発表慣れの話
- 夜は色んなブリ料理を食べた
- 露天風呂も最高だった
- 聞いた内容
- 自分の発表が最後だったので、自分の発表のことで頭いっぱいだった気がする笑
- フロントエンドの話だと、2022 年におきたフロントエンドの変化、Astro、GraphQL、Cloudflare の話などに参加した
- 自分が発表した内容の話
- タイトルは 10 年以上続くプロダクトのフロントエンド刷新プロジェクトのふりかえり
- ただ、刷新してるだけじゃなくて、巨大なコードベースを機能ごとに分割して影響範囲小さく、明確にしてる
- チームごとに独立した技術選定ができるような構成
- ADR から取り組んだことを振り返った
- 1 年振り返ってみてよかった点とこれから考えていく点
- よかった点: 画面ごとのリリースにより、健全な開発サイクルを回せた
- 考えていく点: 現在の作業が完了しても全体の 2~3 割ほど。スケールさせる方法を考えねば
- 2023 年の個人の抱負
- チームがやってる刷新をなるべくはやく完了させたい
- 難易度が高い機能のフロントエンド刷新に着手したい
参考
- https://speakerdeck.com/yotahada3/10nian-yi-shang-sok-kupurodakutono-hurontoendoshua-xin-puroziekutonohurikaeri
今回は「ソフトウェアアーキテクチャの基礎」という本のイントロをレビューついでにざっくり話しています
00:00: OP
00:30: 今日のテーマ
01:00: アーキテクチャに交わるもの
13:05: 既知の知 / 未知の知 / 未知の未知
16:16: アーキテクチャと交わるもの(続)
23:19: ソフトウェアアーキテクチャの法則
32:32: クロージングと次回予告
- アーキテクチャに交わるもの
- エンジニアリングプラクティス (CICD / テスティング etc..)
- 未知の未知に対するアプローチ
- 既知の知 / 既知の未知 / 未知の未知
- 進化的アーキテクチャ・適用度関数
- 運用とDevOps
- プロセス
- ストラングラーアプリケーションパターン・フィーチャートグル
- データ
- データは寿命が長い
- アーキテクチャの大事な観点の「アーキテクチャ量子」という点においてデータは無視できない
- ソフトウェアアーキテクチャの法則
- ソフトウェアアーキテクチャの第一法則: ソフトウェアアーキテクチャはトレードオフがすべてだ
- アーキテクトが、トレードオフではない何かを見出したと考えているなら、まだトレードオフを特定していないだけの可能性が高い
- ソフトウェアアーキテクチャの第二法則: 「どうやって」よりも「なぜ」の方がずっと重要だ
- アーキテクチャとは、Google で答えを見つけられないものだ
今回は「ソフトウェアアーキテクチャの基礎」という本のイントロをレビューついでにざっくり話しています
00:00: OP
00:30: 雑談
01:15: テーマ
03:48: ソフトウェアアーキテクチャの定義
10:48: ソフトウェアアーキテクトに求められる素養
16:29: 逆T字人財・I字人財・Individual Contributor
26:27: ソフトウェアアーキテクトに求められる素養の考察
29:19: 前半の締めと次回予告
- ソフトウェアアーキテクチャの基礎
- O'Reillyから出ている技術本
- 想定読者はおそらくテックリード以上のある程度ビジネスを含めた観点でソフトウェアエンジニアを全うしている人
- 本の構成として第一部で基礎的な概念を把握し、第二部で具体的なアーキテクチャスタイル（レイヤードやマイクロサービス）を知り、第三部でADRなどのテクニックや交渉・リーダーシップと言った人としてのソフトスキルを学ぶ流れ
- 今回のpodcastではその前段にあるイントロダクションをざっくり舐めていく
イントロ
- ソフトウェアアーキテクトのキャリアパスは曖昧
- ソフトウェアアーキテクチャの定義が曖昧
- ソフトウェアアーキテクチャと言ったらどういうものをイメージする？
- ソフトウェアアーキテクチャの責務は広い
- CI/CD
- ソフトスキル (ライテクングスキルやマネジメント・プレゼン)
- スタイル (分散・モノリス、ドメイン固有)
etc..
- ソフトウェア開発エコシステムの進化でソフトウェアアーキテクチャが常に変化する対象になっている
- ソフトウェアアーキテクチャの定義 [本書における]
- 1. （システムの）構造
- システムを実装するアーキテクチャのスタイル
- レイヤードやマイクロサービス etc...
- 2. アーキテクチャ特性
- システムの成功基準のようなもので一般的には非機能要件というニュアンスもここに含まれる
- 可用性・信頼性、テスト容易性、セキュリティ・耐障害性、スケーラビリティ・弾力性・回復性、パフォーマンス・デプロイ容易性・学習容易性
- 3. アーキテクチャ決定
- どのように構築すべきかのルール
- 共通コンポーネントに切り出すルールやintefaceを仲介させるなど
- 4. 設計指針
- システムのガイドライン（not rule）
- 「非同期メッセージングを利用してパフォーマンスを向上させるべきである」etc..
- ソフトウェアアーキテクトに期待される8つの素養
● アーキテクチャ決定を下す
● アーキテクチャを継続的に分析する
● 最新のトレンドを把握し続ける
● 決定の順守を徹底する
● 多様なものに触れ、経験している
● 事業ドメインの知識を持っている
● 対人スキルを持っている
● 政治を理解し、かじ取りをする
今回は2022年から始まったこのpodcastの取り組みを@nus3と振り返って雑談しています
今回は @nus3 とAWSのre:inventで発表のあったEventBridge Pipesとイベント駆動についてざっくり話しました
# オープニング
00:00 OP
00:29 雑談
02:36 今回のテーマ (re:invent)
# EventBridge Pipes
04:30 EventBridge Pipes
15:12 イベント駆動
24:41 EventBridge PipesからみるAWS
# まとめ
30:39 クロージングと次回の話