繼上一篇 Electron Window Auto Scale By Monitor 回顧之前遺留下在 dev 端的 side effect（無法跟產品端一樣在不同解析度螢幕下做個別縮放），想花點時間研究一下能不能同時也在 dev 端達到一樣的效果。 function initWinUrl(win: BrowserWindow, url: string) { if (is.dev && process.env['ELECTRON_RENDERER_URL']) { win.loadURL(`${process.env['ELECTRON_RENDERER_URL']}${url}`) } else { win.loadFile(join(__dirname, `../{url}`)) } } 問題

1. 北極星指標（NSM） 北極星指標（North Star Metric, NSM）是一個企業或產品的關鍵指標，用來衡量長期成長和用戶價值。它能幫助團隊對齊目標，確保所有策略和行動都圍繞最重要的業務驅動因素展開。 公式：NSM = 用戶價值 × 長期事業成長（User Value × Long-Term Business Growth） 核心指標（Key Metrics）：基礎（Base） → 基礎衡量標準，如總用戶數、流量、營收 廣度（Breadth） → 觸及範圍、市場滲透率，例如新用戶增長、註冊率 深度（Depth） → 參與度、價值創造，例如活躍率、用戶平均使用時長 2. 用戶基礎指標（User Base）

1. 資料庫（Database） 一種結構化的電子化數據集合，可用於存取、管理和檢索資訊。 📌 範例： 關聯式資料庫（SQL）：MySQL、PostgreSQL、Oracle、SQL Server 適用於：銀行系統、ERP、CRM 非關聯式資料庫（NoSQL）： MongoDB、Cassandra、Redis

工作了幾年，也跟社群脫鉤有一段時間，很久沒有參加技術研討會了，不過這次也是收穫滿滿，有見到很多之前只會在網路上看到的高手們，也有種粉絲看到偶像的感覺，還有遇到前同事非常開心，所以有挑幾個喜歡的講師作為分享。 433FCD02-965E-4B2C-B81C-4A609F14098F Summer。桑莫。夏天 從我大三開始實習，鑽研相關前端網頁的知識的時候，google 問題時，出現首頁的文章都是她寫的，之前還在FB留言過：『我是從小看妳的文章長大的 X) 』，去的同事還問我跟 Mosky 比較喜歡哪個，我沒有猶豫就是選 Summer！❤️。 DC524448-7712-4C46-BFA9-79F24755CAD2 USPACE 郭丞哲 很久之前在前端社團就常常看過他發文，也是鑽研前端領域很深的大神，這幾年開始轉型成 Head of Product 後，看他分享產品業務開發的心路歷程也是非常棒。（而且我以前網路上賣 PS4 遊戲片還不經意賣給了他，真的是非常有趣的回憶，他當時還問我遊戲好玩嗎？ 🤣） 6B4548B9-6794-49A1-853E-9013FEDC86C4

Electron Window Auto Scale By Monitor 最近工作上開始接觸到 Electron，覺得跟以前寫 Web 感覺非常不一樣，然後有接到一個略微困難的需求就是 ... 需要在現有產品上增加跨螢幕時，可以根據不同解析度縮放產品視窗。 乍看下好像直接使用 Electron 自己的 ZoomFactor 就可以了，但要前置一些事項 image 大綱

704. Binary Search 之前面試有考刷題，所以有刷過一陣子題目（不過都是Easy就是了），所以想紀錄之前紀錄一些基礎題。 Given an array of integers nums which is sorted in ascending order, and an integer target, write a function to search target in nums. If target exists, then return its index. Otherwise, return -1. You must write an algorithm with O(log n) runtime complexity. Example 1: Input: nums = [-1,0,3,5,9,12], target = 9

94. Binary Tree Inorder Traversal Given the root of a binary tree, return the inorder traversal of its nodes' values. Example 1: Input: root = [1,null,2,3] Output: [1,3,2] Explanation: image

What does role="button" mean ? 最近在寫 React Styled Component，有一個需求是 ListItem 本身可以點擊事件，及ListItem裡頭的 Button 也能被點擊事件，那時也沒多想就很單純使用Button 包 Button 去解決。 const ListItem = () => { const click1 = () => { console.log("click1"); }; const click2 = () => { console.log("click2");

Use setinterval in React - 20241010 最新更新修復了精度差問題 Use setinterval 忽略的精度差問題 最近工作上在寫Timer相關功能，有需要在 React 中，使用setinterval，但寫完後有發現到計時器好像會停留在倒數一秒時停住了，覺得哪裡怪怪的。 後續問了查了下資料跟同事詢問才發現不得了，這是因為在 React 中，每次組件重新渲染時，所有的變量和函數都會重新定義。當你在 useEffect 中設置 setInterval 時，這個 setInterval 函數會捕捉到當前渲染時的 seconds 值，這也包括 setSeconds 函數的閉包。 問題原因 在 useEffect 的第一次執行中，setInterval 捕捉了初始渲染時的 seconds，這可能是 0，所以定時器沒有正確運行。即使 seconds 更新，定時器回調函數仍然使用的是最初的閉包值。 簡單調整的作法

Use setinterval 忽略的精度差問題 繼上一篇 Use setinterval in React 我們將 setinterval 封裝成 hook 去做使用。但在使用上時，我們原本的做法是通過與 startTime 進行比對來決定是否達到預期的延遲時間（delay），然而這種方式忽略了每次執行時產生的微小差距。這些差距會累積，導致最終的計時結果變得不準確，最終執行時間漸漸鈍化。 image 為了解決這個問題，我們新增了一個 accumulatedTime 變數，用來記錄每次執行後所遺漏的時間，並在下次執行時與 startTime 進行時間差的 diff。這樣的改進確保了即使 setInterval 自身的精度存在偏差，計時仍能保持準確，尤其是在長時間運行的情況下。 這種方式有效地提高了 setInterval 的時間精度，避免了時間鈍化，並使其在需要高精度計時的場景中表現更穩定。 Poo Poo Code

Node.js 中的 Math.random 真的隨機嗎 ? 在 JavaScript 中，Math.random() 是一個經常使用的函數，用來生成隨機數。 然而，許多人並不知道它實際上不是生成真正隨機的數字，以及為什麼它被視為偽隨機數生成器。 身為設計系對於這種複雜數學甚麼的我是看了就頭痛X) 偽隨機數生成器 偽隨機數生成器是使用一個初始值種子(預設數字)來生成一系列數字。這些數字的生成過程是確定性的，這意味著如果你從相同的種子開始，生成的數字序列會是完全相同的。 生成隨機數的一般步驟：

Mock Server Worker 基於 service worker 驅動起來 mock api 服務，並掛載在現有的 vite 環境下，執行 run dev 時就會起起來 Verison "msw": "^2.3.1", "vite": "4.5.0", Install # 0. - yarn install yarn add msw -D

Promise.all 實作 Promise.all 是一個用於並行處理多個 Promise 的方法，它會在所有傳入的 Promise 都完成（resolved）後，回傳一個包含所有結果的 Promise。 如果其中任何一個 Promise 失敗（rejected），Promise.all 也會立即失敗並返回那個單獨錯誤。 poo-poo code function customPromiseAll(promises) { return new Promise((resolve, reject) => { let results = []; let promisesLength = 0;

Promise.race 實作 Promise.race 是 JavaScript 提供的一個方法，用於競賽多個 Promise，並返回第一個完成（無論是解決還是拒絕）的 Promise 的結果。這意味著，無論哪個 Promise 最先完成，Promise.race 都會使用該 Promise 的結果來解決或拒絕它返回的新 Promise。 Promise.race 的實現原理也和事件循環（Event Loop）的工作機制緊密相關。以下是運作過程及其在事件循環中的各個階段。 Promise.race 的實現原理 創建外層 Promise：Promise.race 返回一個新的外層 Promise，這個 Promise 的狀態由傳入的 promiseArray 陣列中的任意一個 Promise 首先被解析（fulfilled）或拒絕（rejected）來決定。 遍歷 promiseArray 陣列：

針對 mui-datetime-picker 整合 react-hook-form、yup、ts (踩雷 由於我們使用yup關係早知道上TS就用Zod了，驗證date的型別只能辨識new Date，如果要使用dayjs則會有型別上衝突，但又不想為了dayjs去定義新的型別規則在yup上，使用datetime-picker時候又需要dayjs 所以邏輯上我們先在外層定義的data、type全都使用new Date格式 使用datetime-picker時，預設值則在用dayjs包起來注入 當交互資料改變時，再拋出 date格式資料回 form 裡面，形成一個健康的循環。 格式對了、驗證也掛起來了、資料也正常回傳了，全家都歡樂 package.json 版本

Git 資料夾大小寫拼寫錯誤，晚了一步 在開發有時會遇到資料夾大小寫錯的問題，但遇到的當下最好直接 git mv <file> <directory> 盡快處理好，如果沒有就會變成很慘... 在某天開發的時候，發現自己資料夾大小寫有問題，但一開始不疑有他的想說直接換掉就好，殊不知幾周後發現了兩份一樣的Code只有大小寫資料夾不一樣，那這時很單純就是把錯的文件砍掉就好。 結果意外發現兩邊資料夾的git tracking已經被綁在一起，所以無論怎麼改git只會統一辨識一種(最早寫錯的版本)，這時你在寫 PS C:\Users\Desktop\project\src\pages> git mv -v pageA PageA Rename from 'src/pages/pageA' to 'src/pages/PageA' failed. Should I try again? (y/n) y Rename from 'src/pages/pageA' to 'src/pages/PageA' failed. Should I try again? (y/n) y ...

Mercurial 一個不同 Git 管理工具 前幾天有在社群上看到一個議題是 為什麼Meta不使用Git，所以有去了解一下另一個不同的Git冷門工具 Mercurial（水銀）。 Mercurial 開發者：Mercurial 是由 Matt Mackall 在 2005 年開發的。 開發動機：Mercurial 的開發是為了解決 BitKeeper 停止對 Linux 社區提供免費版本控制工具的問題。當時，BitKeeper 是 Linux 內核的主要版本控制系統，但因為許可問題，開發者需要找到一個新的分散式版本控制系統。Mercurial 被設計成一個易於使用且高效的替代品。 開發語言：Mercurial 主要使用 Python 開發，這使得它在編寫和維護上相對簡單。 設計哲學：簡單性和性能是 Mercurial 的核心設計理念，旨在提供一個易於上手且功能強大的版本控制系統。 歷史背景對比

jsconfig.json 和 tsconfig.json 都是用來定義專案中 JavaScript 和 TypeScript 編譯和編輯器行為的配置檔案。 主要區別用途和作用的對象: jsconfig.json: 主要用於 JavaScript 專案，配置編輯器（如 VS Code）對 JavaScript 專案的開發時的提示字樣。不涉及 TypeScript 編譯器的配置。 tsconfig.json: 主要用於 TypeScript 專案，配置 TypeScript 編譯器的行為以及專案的結構和編譯過程。 編譯器選項: jsconfig.json: 包含的 compilerOptions 主要影響編輯器的功能，例如程式提示、跳轉等。雖然有些選項與 TypeScript 類似，但它們不會影響實際的編譯過程。 tsconfig.json: 包含的 compilerOptions 用於配置 TypeScript 編譯器的具體行為，例如目標 ECMAScript 版本、模組解析策略、類型檢查嚴格性等，直接影響編譯結果。