[Life Note] - WebConf Taiwan 2023 技術研討會 Part 2

發表於 更新於 分類於 ， ， 文章字數： 8.9k 所需閱讀時間 ≈ 8 分鐘

Introduction & 前言

Webconf Logo

經歷了十年，Webconf 又重啟了一次會議，這次場地在 台北張榮發國際會議中心，這是一個什麼會議呢？

『WebConf 不僅僅關注過去，還關注網頁的未來趨勢和新興技術，並提供業界趨勢及發展方向，以協助企業更好地了解未來網頁發展的方向。』 - 引述官方網站的話，基本就是介紹這數十年以及現在還有未來網頁相關的議題。

接下來筆者將會將所聽到一些比較有趣的內心紀錄在此處，有興趣的歡迎繼續看下去。

這篇是第二天的心得紀錄

由於議程的進行方式為一個時段為四十到四十五分鐘不等，一個時段同時會有三個講者，所以只能挑一個議題進去聆聽，下面筆者會說自己挑了哪些議程進去聽，主要偏前端。

Summary & 摘要

本次紀錄不會太過詳細紀錄每個講者講過的話及內容，但會把筆者覺得有意思的點記錄下來，更詳細的內容可以直接參考官方提供的 『共筆』

會議也有提到這次有跟講者們討論過後，決定以不論影的方式進行，故後續只有共筆紀錄演講過程。

scheduleOne

scheduleTwo

筆者將有去聽的議程用紅框圍起來，如果有同步聯播的，就會三廳的人一起聽到，不會分場次。

時間 議程內容
09:00-09:45 淺談 Vue.js 的狀態管理模式
09:55-10:05 引言
09:55-10:40 鳳‧極意？！
10:50-11:35 從零打造前端效能監測系統
11:45-12:30 藝術界線超進化-從創作到實踐，探索生成式藝術與前端互動技術的共舞
午餐時間
13:30-14:15 資訊架構設計新體驗：在需求情境中運用領域事件分析描述結構化內容
14:25-15:10 無密碼時代降臨！使用 Passkeys 打造無密碼驗證服務
15:20-16:05 酷！玩！啥鬼CSS！
16:15-17:00 Beyond Technology 技術之外 - 從個人身心安頓到人類福祉追求

淺談 Vue.js 的狀態管理模式

今天第一場選的 Kuro 大的 Vue.js，相信這位講者是大多人接觸甚至沒接觸過 Vue.js 都可能會聽到的名子。

鳳梨

這場內容主要談的是鳳梨(Pinia)，為什麼會叫 Pinia 呢？可以參考官方網站的介紹：

Pinia (pronounced /piːnjʌ/, like “peenya” in English) is the closest word to piña (pineapple in Spanish) that is a valid package name. A pineapple is in reality a group of individual flowers that join together to create a multiple fruit. Similar to stores, each one is born individually, but they are all connected at the end. It’s also a delicious tropical fruit indigenous to South America.

Vue3 其實也出來一陣子了，雖然可以向下相容 Vue2，但有許多的工具也在推陳出新，這次 Kuro 帶來的是 Pinia 這套工具的介紹。

說 Kuro 是傳教士真的不為過，每次來都要推銷東西啊

如果有使用過 VueX 或者寫 React.js 的夥伴有使用過 **Redux(聽說也漸漸式微了？！)**，可能可以比較好理解，這套就是一個狀態管理庫。

其中要解決幾點問題

  • props與events 一層一層傳遞
  • event-bus 跨元件事件傳遞(請忘記它)
  • project-inject 跨層級傳遞(必須在同一條元件樹上)

Project-inject 依賴注入 或 提供注入 可以參考官方文章
使用 React.js 的夥伴可以理解為 useHook，的改念

而 Pinia 也想要解決一些 VueX 的痛點，例如 TypeScript 的額外設定比較麻煩，VueX 的 Store 也無法直接使用 Composable

鳳‧極意？！

鳳 也就是 html form

這位講者滿厲害的，光看他的簡報就可以發現。

小吐槽，用 Chrome 無法正常開啟 QQ

內容講了很多，但都是關於 Form 的應用，甚至是使用者體驗都可以透過很基本的原生 JS 或者 HTML 達到，簡單介紹 Form element，<input />(date, rang, checkbox, radio) 的檢查及方便的使用，原生支援。

Use Case One

首先講者用了兩個簡單的 Use Case 來介紹怎麼透過 Form 就能做到這些強大功能，第一個為圓餅圖，第二個則是 Video 的 Control bar 透過 range input。

而我們大部分的人做網頁應該都會用到 :hover，其實可以先透過 @media (hover: hover) 來判斷裝置是否支援，像是行動裝置就不需要，這時候就不會吃到裡面的變數。

@media (prefers-color-schema: dark) 也能快速做到黑暗模式；focus-visible vs focus: 前者是只有在用鍵盤操作 tab 去 focus 時才會觸發；最後我們應該盡量避免做出合成獸這種東西，像是 checkRadio 或是 radioButton。

在一些 Input 我們也會放上 Icon 去讓使用者點擊後跳出像是日曆或者顏色選擇器之類的東西，我們可以透過 showPicker() 去達到，有更好的使用者體驗。

在數字輸入框我們可能會透過框架的幫助取對數字加一減一，但如果原生我們可以透過 stepUp() 及 stepDown() 去達到，不需要再用 document 的語法去取出值變化後再塞回去。

Attribute

最後需要善用 attribute 的方式去檢查輸入內容是否正確，input 有許多的 attribute 可以使用，詳細可以參考 MDN。

以前 PM 可能滿常會提 Input 我要帶有搜尋功能，現在透過 input(type=“list”) 可以輕鬆達到。

重點節錄

重點節錄

從零打造前端效能監測系統

從零打造前端效能測試

這場內容非常之精實，我覺得應該直接貼上 Summer 大的逐字稿給大家看。

離題想說一下， Summer大 跟 莫大 是我來這次講座一直非常想聽的講者之一，原因不外乎自己一路一直都是純前端工作者，工作內容離不開切版串接 API 太遠，但時常的會讓我自己想到我還會什麼？像是奶綠茶大提到的，如果今天 JS 像 Flash 一樣，說掰掰就掰掰了呢？

故對於切版串 API 之外，又不會離前端太遠的東西我都非常有興趣，而這次講者提到的內容也讓我有了一些方向可以去研究。

會碰測試的人不外乎寫程式一陣子開始會注重到效能或者功能是否正常的人，講者則是提了之前在 Loading 太久的例子當作開場白。

講者提到我們會有一系列的各種 unit test、integration test 或 e2e test 的自動化測試的 test case，但我們不會將效能測試放入其中，也可能我們每次修改功能或 Bug 後又出現了。

如何做測試

如果要將效能測試融入其中，這是講者覺得最合適的方式。

Sentry

這套測試就是講者這次會提到的核心內容，主要能監控兩種我們可衡量的效能指標

  • Loading Performance 載入效能
  • Rendering Performance 渲染效能

該套件也提供了 API 甚至介面可以讓使用者得知一些效能指標。

遺憾的是前面有提到理想情況是發生事情可以發出通知即時告訴我們，而這項功能在 Sentry 是需要付費的，但是講者提到另一套工具可以做到通知的功能且免費。

Sentry VS New Relic

New Relic 比較像是 **APM (application performance monitoring)**，它還提供來自不同 region 存取網站的選項。

突然發現，Relic 一直存在我手機的頁籤裡面，但是一直沒有去深入研究過，實在是像是 Ruddy 老師說的，囤積知識啊…

藝術界線超進化-從創作到實踐，探索生成式藝術與前端互動技術的共舞

吳哲宇

這場是由 老闆來點寇汀 的吳哲宇來演講的，其中技術層面沒有深入提到太多，但講者有說了滿多他之前的作品。

由前端延伸到藝術去也是講者一直在思考前端還能應用在哪些東西上面，所以中間說了滿多應用層面的東西。

而在講者稱自己為生成式藝術家之前，在許久之前就在網路上教學很多前端互動框架及庫了，例如 p5.js、Canvas 甚至透過 WebSocket 實作出可以與人互動的藝術裝置。

Profile

有興趣的夥伴可以直接到講者的 Youtube 去看看看，滿精彩的！

午餐時間

便當

中午便當

  • 疲勞 -1
  • 飢餓程度 -1
  • 快樂 +1

資訊架構設計新體驗：在需求情境中運用領域事件分析描述結構化內容

資訊架構投影片

時常畫面與需求都是我們開始一個專案或者功能的起頭，而大部分的循環都會卡在 PM 請你先弄畫面，而你想先確認功能是什麼，才能做出有邏輯的畫面。

討論與爭鬥

上面圖片有些許被擋住了，但應該其實大家都看過這個梗圖；其實大部分時候我們需要的是輔助討論的圖像溝通方法而非精美畫面。

架構需求

講者使用餐廳比喻，我們需要食材、工具，之後經過加工流程，才能誕生出結果；有時候討論會專注在功能需求方面，但往往我們卻很少討論內容(資訊)哪裡來，需要為什麼需要？

需求膨脹會成為資訊垃圾場

要有一個好的廚房流程，我們需要先整理我們的餐具，我們總不能使用各種不同的餐具去承裝我們要供應給客人的食物吧？

用餐具來比喻 資訊收納（關於分類、收納、整理）：

  • 資訊整理 先從觀察基本單位開始，準備餐具
  • 再開始收納餐具
  • 舉例會場擺設，把收納好的一整組餐具開始擺設

長榮海運我沒買到

好的分類像是海運貨櫃一樣，可以省掉許多不必要的成本。

釐清需求及具體化需求

具體化需求

使用案例預約訂位來示範怎麼具體化需求（規劃時需要一位對專案是比較熟的），我們需要熟悉需求的人來跟我們討論，而我們可以將需求具體化，方便確定後續我們都在同一個頻道上對話。

內容模型的討論情境，請對方回答一些細節情境，順便看一下過程合不合理；我們也可以特用真實的假資料，假資料拿來測試設計的架構對不對。

最後沒有畫出 Mock-up 就能產出需求圖，但其實重點一直都是需求方需要有想法，沒有明確想法的想法，只是一個飄渺的目標，你怎麼做客戶都不會滿意的啦！

畫出架構圖是重要的（例如類似 DB 的設計圖），情境的方案探討是很重要的，我們可以從簡單的情境延伸到複雜的情境。

無密碼時代降臨！使用 Passkeys 打造無密碼驗證服務

PassKeys

這場非常實用，有興趣的夥伴可以看看講者的簡報。

現今我們使用的服務越來越多，也會產生出無數服務有無數密碼需要記憶，但這麼多密碼，真的安全嗎？

WebAuthn(Web Authentication)

WebAuthn

這是 FIDO 聯盟與 W3C 聯合提出的驗證標準，利用非對稱金鑰的方式進行驗證，類似於我們在 Git 上使用的 SSH 密鑰。

五分鐘小教室不囉唆直接上圖：

教學一
教學二
教學三

這種方式優點是密鑰會直接存在你的裝置上，在登入時你還是需要開發商提供的方式去驗證，例如 iPhone 就是 FaceID、Mac 使用 TouchID…等等。

而且使用了這種方式，像是微軟就比較激進一點，他會直接把你的密碼從 DB 移除，而 Apple 及 Google 還是會存一份，防止你的私鑰真的不見。

缺點顯而易見，就是裝置壞了或是不見了，你密碼就不見了，但相對的，以往我們太多密碼也會寫下來或者存在硬碟裡，不見就不見了，筆者自己的長輩就是如此，通常密碼都不會記得的。

SigUp 及 SignIn

註冊

我們可以透過簡單的程式碼做到註冊裝置，讓我們的網站也能存有使用者的 Public Key：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
const publicKeyCredentialCreationOptions = {
  challenge: Uint8Array.from(
    "challenge from server", (c) => c.charCodeAt(0)
  ), // 從伺服器產生的隨機字串，避免[重播攻擊](https://zh.wikipedia.org/zh-hk/%E9%87%8D%E6%94%BE%E6%94%BB%E5%87%BB)
  rp: {
    name: "FullStackLadder",
    id: "fullstackladder.dev"
  }, // relying party 資訊，通常也就是驗證伺服器的資訊，id 需要與網域名稱相符，避免釣魚網站的攻擊
  user: {
    id: Uint8Array.from("User Id", (c) => c.charCodeAt (0)), name: "mike@fullstackladder.dev",
    displayName: "Mike Huang",
  } // 目前要註冊裝置的使用者資訊
  pubKeyCredParams: [{ alg: -7, type: "public-key" }], // 指定允許使用的簽章演算法，目前有幾種演算法可以拿取你的私鑰去算出是不是正確的，為 -8(Ed25519) -7(ES256) -257(RS256)
  authenticatorSelection: {
    authenticatorAttachment: "cross-platform"
  }, // (非必要)用來限定可以使用的驗證氣來源
  timeout: 60000, // 註冊流程到期時間(毫秒)
  attestation: "direct", // 是否要回傳驗證氣資訊給伺服器
};

const credential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions,
}); // 產生公鑰及相關認證資訊，這些資訊可以存到服務端的 DB

產生的相關認證為下：

1
2
3
4
5
6
7
8
9
PublicKeyCredential = {
  id: 'ADSU11KQmbqdGtpu4sjseh4cg2TxSvrbcHDTBsv4NSSX9...', // 產生的認證 ID
  rawId: ArrayBuffer (59), // 也是認證 ID，只是為 [binary 格式(二進制文件)](https://zh.wikipedia.org/zh-hant/%E4%BA%8C%E8%BF%9B%E5%88%B6%E6%96%87%E4%BB%B6)
  response: AuthenticatorAttestationResponse {
    clientDataJSON: ArrayBuffer(121), // 瀏覽器與驗證氣之間傳遞的資料
    attestationObject: ArrayBuffer(306), // 驗證器相關資料，包含公鑰等資訊
  },
  type: 'public-key'
}

登入驗證

驗證我們可以透過下面的方式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
const publicKeyCredentialRequestOptions = {
  challenge: Uint8Array.from(
    "challenge from server", (c) => c.charCodeAt(0)),
  allowCredentials: [
    {
      id: Uint8Array.from(
        "credential id",
        (c) => c.charCodeAt(0)),
      type: "public-key",
      transports: ["internal"],
    }
  ], // (非必要)允許使用的驗證資訊，可用來限定登入裝置
  timeout: 60000, // 登入流程的到期時間(毫秒)
};

const assertion = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions,
}); // 取得註冊的裝置資訊，以及相關簽章結果

產生的相關認證資訊為下：

1
2
3
4
5
6
7
8
9
10
11
12
PublicKeyCredential = {
  id: 'ADSUIlKQmbqdGtpu4sjseh4cg2T×SvrbcHDTBsv4NSSX9...',
  rawId: ArrayBuffer(59),
  response:
    AuthenticatorAssertionResponse = {
      authenticatorData: ArrayBuffer(191), // 用來完成這次驗證的裝置資訊(注意：不會包含公鑰資訊)
      clientDataJSON: ArrayBuffer(118),
      signature: ArrayBuffer(70), // 由驗證器私鑰產生的簽章資訊，Client 端根據特定規則產生簽章，Server 端使用已註冊的公鑰驗證簽章
      userHandle: ArrayBuffer (10), // 由驗證器提供的額外使用者資訊
    },
  type: 'public-key'
}

Library

Library

而現在有許多的套件都有提供這種驗證方式，不用自己手刻，有興趣參考程式碼可以看一下講者的簡報，挺有趣的，而筆者自己則找到了 Corbado 這套套件，相信不久後會越來越多服務商提供這種登入方式，既簡單又快速。

Demo

有興趣者夥伴可以直接 Clone 講者的 Code 下來玩。

下午茶時間

下午茶時間

其實兩天都有，但是第一天的不知道為什麼數量比較少，去的時候很多東西都被夾光了

  • 疲勞 -100
  • 飢餓程度 -100
  • 快樂 +100

酷！玩！啥鬼CSS

AMOS

Amos！有學習過 CSS 的人大概都會聽過他，這場不外乎就是講了一些必用甚至是新穎的 CSS，其中重點摘要為：

  1. 邏輯屬性
  • Block inline 屬性
  1. 首字放大
  • first letter
  1. 父層選取器
  • :has()
  1. 媒體查詢
  • @container 可以不必使用 @media
  1. 級聯層
  • @layer 改變順序 上蓋下 後蓋前

2023 新穎 CSS
2023 新穎 CSS 附上英文字

前面除了講者自己回顧之前做過的一些閒暇時做的作品(真的很屌)，有興趣可以參考他的 Youtube - 金魚都能懂系列

Beyond Technology 技術之外 - 從個人身心安頓到人類福祉追求

Beyond Technology

這場真的是技術之外的心得談，人常說家有一老如有一寶(筆者不是在攻擊講者)，非常有道理，因為他們身上蘊含的都是智慧，而這些智慧是經過生活及歷練孕育出來的。

講者提出三個規劃，讓你的人生不會太過的焦慮也能感到幸福：

  1. 過去 - 感恩
  2. 現在 - 安頓
  3. 未來 - 目標

Conclusion & 結論

這是第二天的內容，其實筆者覺得每一場會議時間太過剪短，以致於一些比較深入的東西很難聽到，但不能否認這整個會議的目標就是暢談這十年以及最近的 Web 趨勢，理所當然會是心得居多。

而講者需要技巧，聽者也需要技巧，如何整理收納並吸收這些知識就是我們聽者需要做的，不過常聽演講的夥伴應該也能知道，如何區分一位好的講者，聽聽他是不是照著 PPT Show 出來的東西念就對了，好的講者應該是更應該把精力放在如何把觀眾帶入到他自己的觀點中，透過講者得角度帶領聽眾去理解及獲得他想傳遞的東西。

結果統計

最後還是要感謝主辦方主辦這麼一場很精彩的會議，但我想現在是個言論自由的國度，有些東西還是可以說出來的吧，是吧？！

我覺得有幾點是會議之後可以改善的

  1. 場地太小 - 很多比較熱門的議程，過多的人去聽，導致很多人需要站著(雖然有人會不認同，但請繼續往下看)
  2. 時程太緊湊 - 每一個議程時程大約都只有 40-45 min，個人覺得太短，很多東西都只是被皮毛帶過(雖然有人會不認同，但請繼續往下看)
  3. 分流同時段進行卻沒有錄影回放 - 雖然主辦方有說過他們在開始前有問過講者，是不是不錄影，他們演講會比較自然，最後他們採用不錄影的方式，但一個時段有三個議程，我想要三個議程都聽到，這時候只能挑其中一個，剛好如果你又是選擇障礙者，會很困擾(雖然有人會不認同，但請繼續往下看)
  4. 這點講出來可能會被噴，但看完這點請繼續往下看 - 紀念品太過簡單(雖然有人會不認同，但請繼續往下看)

好，說完缺點來說說為什麼吧。

首先主辦方有提到他們十年前有舉辦過，而他們吸取不好的教訓去改善，保留好的東西，他們有提到之前也有發生人太多導致很多人需要站著或坐著，但這次竟然又發生了，我想如果有這種情況，應該是一開始就能避免，因為人數及位子是一開始就能掌握的，而非賣超過的票，然後讓觀眾忍耐一下，畢竟這場會議也是不便宜啊。

再來是時程太緊湊，雖然有人覺得人的精力只能專注在幾十分鐘內，太長的話你根本專注不下去，但舉例來說，有一場會議筆者想聽 K8s 的議程，但整場幾乎都是在聽他們為什麼要導入，怎麼導入(沒有太多的實作舉例)，然後他們解決了啥，個人覺得像是花錢去聽了公司就會有的技術心得分享會，聽同事試圖說服我他之前用過什麼很好用，然後要我導入，但請我自己去開官方文件來研究。

第三點是分流進行沒有錄影，還是那點，我覺得花了錢了，應該是能取得最大的效益，當然你也許會秉持著熱情，或者不同的看法，我都尊重，但是我覺得講者及參加者應該都需要被尊重，而非講者統一決定了之後，讓參與者直接接受做法，我不確定是前是不是有什麼地方有公告，但至少在報名流程上我沒有看見(歡迎打臉我，我就是說說自己的想法)，如果今天我是免費近來聽，那我尊重！

最後一點是紀念品的部分，其實說到這邊可能會有人覺得，啊你不就花錢想當大爺，但說真的我今天不是去做公益，我覺得花了錢，我就會有預期心理，而沒有得到你的預期報酬，你當然會有不滿足的地方，不然怎麼會有消基會呢？不然你怎麼不跟老闆談理想呢？對吧！

雖然前面說了很多缺點，但其實我也只是想要做到 Ruddy 老師說的，你覺得操作者體驗不好？那就說出來啊，你不說，怎麼會有人知道呢！

自己期許下一屆的 Webconf 會更好，我還是很感謝主辦方辛苦主辦這一切，但你知道的，完美並不完美，如果這世界都只有一種聲音，就不正常了是吧。

另外筆記內容可能不是那麼正確，可以參考官方提供的 共筆，裡面記錄的很詳細。

參考網站