本地端做好的網頁要讓大家都能看到就需要上傳到雲端，現今社會有很多種方式可以實現，研究之後發現這種服務還真不少，爬文整理吸收過後，大致可以分為以下這幾種： SaaS全名是Software as a Service，中文叫軟體即服務，我理解成所有的應用程式，每一個app都算在裡面，可能會有一個免費版可以使用，也可以付費來享受完整版，由於只需要連網路，其他什麼都不需要準備，所以可以當作是種使用門檻最低的雲端服務形式。 PaaS全名是Platform as a Service，中文叫做平台即服務，服務提供了開發環境，讓開發者不需要再自己去建立，這樣可以專注於應用程式的開發而不必擔心底層的基礎架構，這種模式包括開發工具、資料庫和其他基礎組件，減輕了應用程式的管理負擔，對新手開發者比較友善，所以網路上爬文對於剛碰部署的朋友們都建議從PaaS服務下手。 IaaS全名是Infrastructure as a Service，中文叫做基礎架構即服務，顧名思義雲服務模式中最基本的一環，提供了所有開發者所需基礎架構，同時也讓開發者不需要準備任何硬體也能開發，高手境界，擁有高度的自由性跟擴充性，配置相當的彈性 ...

網頁中常常在進去到真正內容之前，會先跳出一個「我不是機器人」的區塊，像是這樣： 可能是要驗證目前是不是真人在使用，只要勾選完後就可以正常前往，比較進階一點的可能會出現一個九宮格，問裡面哪一些圖裡面有車，答對了就可以進去，亂選就進不去。 專案中會用到，原本以為蠻複雜的但其實文件寫得很清楚。 接下來紀錄我在實作這個需求的脈絡。 確認需求reCAPTCHA 其實是有分版本的，v2 以及 v3，v3 是目前最新的。差別在於說 v3 是採取分數的方式，所以使用者不用點擊按鈕了，不然的話 v2 時，還是要點擊一個「我不是機器人」的按鈕，取而代之的是運行在後台，從後台來判斷是不是機器人。 v3 等於說 google 會自動判斷你這個人進到這個網站會給你多少分，然後後台可以去控制幾分才能進到這個網頁裡面。 v2 是用問題來驗證要求。v3 是用分數來驗證要求。 假如說需求是會希望看到「我不是機器人」的選項可以選擇 v2，想要更方便讓使用者不要有負擔的話可以選擇 v3，這邊我是選擇 reCAPTCHA v2。 註冊 reCAPTCHA確認好需求好在寫程式之前，要先去 reCAPTCHA 的官網去註冊，ht ...

IIFE 的全名是 immediately-invoked function expression。 是在 JavaScript 中可以立即執行的函式，我個人比較少在實作上去使用到這個技術，但也是重要的概念。 可以立即執行代表著三件事情。 不需要去命名，既然可以馬上執行了，代表不需要一個名字來在之後呼叫它。 不需要透過呼叫，如第一點提到的。 無法在程式外再次執行。 實際上的寫法就是宣告完函數之後就直接執行，使用的方式就像是現在畫面上的圖片，用一個括號把函數括起來後，再接一個。 也可以使用帶參數的方式。 像是這樣： 123(function () { console.log("hi vic");})(); 回到今天的問題，JavaScript 中的 IIFE 還會用得到嗎？ 我個人覺得大部分情境下不太需要。 因為我覺得當初設計出 IIFE 的主要目的是在於模擬一個局部的作用域，防止污染，污染的意思是作用域裡面的變數不會影響作用域外面。 因為在 ES6 之前只有 function 的作用域(var)，但在 ES6 之後引入’let’跟’con ...

前言淺拷貝和深拷貝是在處理物件和陣列時非常重要的概念， 了解它們的差異可以幫助我們選擇最適合的複製方式，以滿足特定的需求和性能要求。 用此篇來紀錄，如果是現在的我，會怎麼來理解淺拷貝與深拷貝。 JS 有分成基本型別跟物件型別基本型別(Primitive) ⇒ 如：number、string、boolean、null、undefined。 純值的部分都含括在裡面，包括數字、字串、true、false。 基本型別不會碰到淺拷貝與深拷貝的問題。 原因是因為，複製給變數值，就直接賦值，新複製的不會影響原本的。 用實際程式碼來解釋： 這樣不會有大太問題，但是物件型別就沒辦法有相同效果。 物件型別(Object) ⇒ 包括 陣列、物件、函式。 用陣列的方式做例子： 會發現修改了 array2，array 也會被改變。 其實原因是指向問題，物件型別跟基本型別，在傳遞參數的方式不同，導致變數指向記憶體的位置也會不同形式。 型別的不同，會影響指向基本型別，在賦值傳遞參數時是「 複製值 (value) 」。 物件型別，在賦值傳遞參數時是「 複製地址 (address) 」。 pass by value ...

前言今天主要講的會分成兩個部分，分別是 offset 系列 client 系列 然後這兩種都會個別擁有Left、Top、Width和Height。 但今天如果我想獲得元素本身的寬度時，知道是要Width，但是要用 offset 系列還是 client 系列是會讓人感到困惑的。 會遇到的問題像是說：offsetLeft 跟 clientLeft 差在哪裡？offsetTop 跟 clientTop 差在哪裡？ 以下直接列出我整理後的重點。 Width / Height offsetWidth / offsetHeight 是「元素本身」的寬度/高度 (包括 border) clientWidth / clientHeight 是「元素本身」的寬度/高度 (不包括 border) 可以發現其實這兩者只差在有沒有包括border。 Left / Top offsetLeft / offsetTop 是元素本身相對於母元素的水平/垂直距離。 clientLeft / clientTop 是元素 ...

需求情境網頁上碰到區塊或是全部列印的需求時就會使用到列印的功能。 這篇會寫很簡單，因為我遇到需求沒有很複雜。 我自己是在 vue3 的專案中，需要去列出商品的資料，所以只需列出一部分的區塊就好，而不是全頁列印。 我最初找的方式我找的是vue3-print-nb這一個 vue3 列印套件。 官方文檔： https://github.com/Power-kxLee/vue-print-nb 其實會發現很簡單，只需要加入v-print就可以達成需求。 但後來發現原生就能做到這件事情，也能不用套件完成。 瀏覽器內建的列印功能其實最簡單的列印，其實就是在當前頁面中按下右鍵就有列印的選項。 程式的話，就是以下這串指令就可以完成： 1window.print(); 但可能很多人在此處會發現一些問題。 你只想印某些區塊，但是發現全部都印進去。 印出來的畫面怎麼都沒有樣式？ 這其實是因為說，原生列印功能還需要的其他設定。 設定 @media print有寫過 css 的人應該對 media 不陌生，除了在做 rwd 時會用到，其實在規範列印樣式時也同樣需求這個語法。 1234/* 一般樣式*/@m ...

前言起因是體驗過睡很少的滋味，發現睡很少的這件事情會讓大腦及身體產生一些debuff的效果，各種負面效果會纏身，那我就開始想說那我睡很多的話是不是反而可以獲得增益效果。 所以前一陣子拿自己去做實驗，每個睡眠時間都親自嘗試，網路上有很多結論，說人要睡多久有一個固定的公式，但我覺得那可能是適用在別人，卻不一定適合自己，還是得自己嘗試看看。 睡與繼續睡首先實驗進行時要先確保沒有睡不著的問題，及良好的睡眠品質，所以晚上都會開冷氣，睡前確保沒有蚊子，晚上睡覺前不使用 3c 產品，適度做運動或是喝一杯熱牛奶。 我想要判斷出差異的部分： 記憶力 專注力 反應力 受壓力反應 最先從以下幾個時間開始做嘗試，每個都嘗試一段時間，大致上是幾個禮拜。10 小時，12 小時，14 小時，16 小時。 10小時：大約是從晚上 10 點到早上 8 點的概念，大腦有點脹脹的感覺，但整體來說精神是好的，一段時間記住這個感覺後，我把這個睡眠的綜合(上述四項)分數定為 10 分，性價比的分數為 10 分，當作一個基準點的概念。 12小時：晚上 10 點到早上 10 點的概念，ㄧ段時間後發現我的上午已經快消失了，起床時不 ...

vite 是 vue 的作者尤雨溪所開發的，為了改善開發者的體驗而生。 vite 嚴格來說不是純打包工具，更像是一種建構工具。 vite 的核心概念： 快速熱更新 快速冷啟動 熱更新 => 在不重新加載整個頁面的情況下，去即時做修改。冷啟動 => 預建構 + 開啟時準備。 這兩個功能不僅僅存在於 vite，而是 vite 進一步優化了熱更新及冷啟動的時間。 webpack 出現時就已經擁有了熱更新及冷啟動的概念，在當時環境已經算是很快速及方便的工具，但放在現在來看，等待要好幾十秒就會讓人覺得太久了。 而 vite 就帶來了更快的開發速度及優化整體的流程。 vite 的出現其實不是為了要取代掉 webpack，webpack 也沒有辦法變得像是 vite 一樣，因為兩者的核心概念本就不同。 webpack 的核心是先打包再去建立環境，主軸會是放在打包這一塊。 vite 則是不打包，在開發環境時，不會做打包這件事情，只會在最初的時候去進行預建構之後存放在本地端，之後如果有需要去修改的其他地方時，會利用原生 ESM 的機制，等於說把一部分打包的任務交給了瀏 ...

目前正在進行一個案子，裡頭有一項需求是「多國語言系統」，就是前端界面要有多國語言的選項可以去做選擇，預設是繁體中文，但也要能切換成英文、日文這樣，之前沒做過對我來說是一種新的挑戰。 這次專案所使用的是vue3 + vite的形式，所以使用載入的是 Vue-i18n。 照著下方參考來源第一篇做是沒問題，使用方法不難，但其實我在研究中有所誤解的地方，跟沒辦法一時就弄懂的部分，有跟一些前輩們進行交流，在這邊做個紀錄。 概念網站上的多國語系其實會分成兩種，一種是data，另一種則是layout。 這邊的data指的是網頁上那些動態的資料，比如說像是我blog中一篇篇的新文章，而layout則是指網頁本身靜態的東西，像是我blog最上方的搜尋、首頁、文章總覽。 現在打開fb或是youtube，選擇切換語系，假設是選擇切換成英文版本，但就會發現並不是所有的東西都變成了英文字，可能裡面內容的本身、自己的名字不會跟著變成英文版本。 所以說假如內容也需要多國語系時，那麼文章的內容本身，也需要依照多國語系寫好幾份，並不是寫好一個中文版本就能用像是google翻譯翻全部，有那麼簡單就不需要做多國語系的功能了 ...

這種技術本質是一種優化，不是必需品，今天若只處在一個先求有再求好的環境時，比較不會考慮到這種技術，但假設已經有寫出基本的程式碼，後來想要節省效能，避免伺服器負擔過大的話，那這種技術就值得導入跟實際應用。 本次研究的主角: Debounce，中文名字叫做防抖，我研究時在網路上有查詢到的定義如下， 12無論用戶觸發多少次的事件，對應的回呼叫函數只會在事件停止觸發觸發指定事件後執行也就是n秒後在執行該事件，若在n秒內被重複觸發，那就會重新計時。 Throttle，中文名字叫做節流，我研究時在網路上有查詢到的定義如下， 12無論用戶觸發事件多少次，附加的函數在給定的時間見個內只會執行一次n秒內只運行一次，若在n秒內重複觸發，那只會有一次生效。 防抖(Debounce)理解我自己的理解會先從字面上解讀，防抖意思就是為防止抖動的意思，那思考什麼時候會不停抖動，我想像是使用者的手一直不停抖動，而這在操作網頁上會造成問題，假如今天有一個按一次買 100 個物品的按鈕，手抖的阿伯只想買 100 個，所以他想要按一次就好，但是他的手就是會抖個不停，所以在按個過程中一個不小心就多按了好幾下，結果就變成計 ...