Posts

前言 最近用 Hugo 重新架了新的部落格，部落格本身是一個 git repo，但 Theme 的資料夾的內容是另一個 git repo，導致在不同電腦想要同步部落格內容時，遇到 Git Submodule 的議題，是一個實務開發上較少遇到的情境，所以順手紀錄一下操作記錄． 何謂 Git Submodule？ 使用 Git Submodule 的情境是在開發專案時資料夾內有第三方 Library 或你正單獨開發並被多個父專案使用的子專案，此時你想要將兩個專案視為獨立的，但又希望可以在其中一個專案使用到另一個專案的內容． Git Submodule 其實就是一個巢狀的 Git 檔案結構，他會幫你把專案內某個子資料夾視為 Library 處理，不會受到主專案的 Git 操作影響． 以下是我遇到 Git Submodule 的情境： 我的部落格資料夾內含有 Theme 主題，部落格資料夾是父資料夾，而 Theme 是子資料夾，因為他參照的是另一個第三方的 git remote url，也就是一個第三方維護的靜態主題專案，未來我可能會需要同步他上面最新的更新，或是切換到他專案某個時間的 commit，這時候我就需要將他視為和我部落格是不同的專案，但彼此卻又需要被互相引用，這時候 Git Submodule 就可以很好的幫我解決這個問題． 實戰演練 為了模擬巢狀的 Git 結構，在 GitLab 上分別建立一組父子專案，父專案名稱是 Parent，子專案名稱是 Child．建立好之後，分別 clone 到本地端的 parent 和 child 資料夾． . ├── child │ └── README.md └── parent └── README....

前言 前陣子開發時，遇到 Node.js 上傳檔案到某個 file storage 時的問題，後來深入研究了一下上傳檔案時的 Content-Type: multipart/form-data，順手記錄一下，也透過常用套件 multer, busboy 的原始碼來驗證這些機制的存在。 何謂 boundary? 網路世界中，HTTP 協定定義了 Content-Type 標頭檔來規範資料傳遞的格式， 其中表單(Form)提交是很常見的情境，而表單提交的 Content-Type 主要有三種，並寫在 form 的 enctype 屬性裏頭: application/x-www-form-urlencoded multipart/form-data text/plain 第一種 application/x-www-form-urlencoded 會被表單轉換成 url 帶上 query params 的格式，例如: ?name=Madi&age=20，使用 & 符號作為參數的分隔符(Delimiter)。 第二種 multipart/form-data 就是本篇文章要探討的主角，他也有類似 application/x-www-form-urlencoded 的分隔符 &，但是是使用 boundary 作為分隔符，在上傳檔案的 Request Header 都可以看見它的存在，而主要目的就是透過這個分隔符來區分不同格式的資料，例如圖片、檔案、影片…等等。 boundary 可以是任意符合 ascii-7 的字元，可以自己定義他的值，但開頭需要兩個 hyphen(連字號-)，且長度須限制於 70 字元以內。當送出請求的 Content-Type 是 multipart/form-data時，強制規定必須帶上 boundary才能成功派送，但若是使用瀏覽器來發送，他會自己幫我們帶上一組 boundary。 例如，底下寫個簡單的 fetch，帶上 local 的某個文字檔 <script> const formData = new FormData(); formData....

前言 最近因為工作需求碰到地理空間搜尋與儲存的技術，其中包含 PostGIS 這個 PostgreSQL 實作的地理物件函式庫，裏頭涵蓋各地區座標系統的 SRID(Spatial Reference Identifier)，令人欣慰的是台灣地區常用的 TWD97 與 TWD67 兩種座標系統也涵蓋如此，但在實作過程發現 TWD67 的座標點位有高達數百公尺的誤差，追溯源頭後意外發現，原來是 PostGIS 內的參數設定有誤，解決之後就順手紀錄一下踩坑的過程。 座標參考系格式 - WKT vs proj.4 vs SRID 開始以前要先提一下地理知識，因為地球是圓的不是平的，所以要將一個橢圓形的物件投影到紙面上勢必會有投影扭曲的問題，而為了降低投影扭曲的影響，學術上有很多轉換方式，包含等面積投影、等角投影(麥卡托投影)…，但不管選用哪一種投影都只能降低扭曲的幅度，並不存在絕對好的投影方式。 為了描述座標參考系(CRS, Coordinate Reference System)，訂了幾種常用的描述格式，包含: WKT(Well-Known Text): 是一種描述點、線、多邊形、幾何形狀的文本格式，例如: POINT(121.5 22.5)，相較於其他格式更 human-readable。 舉例來說，Google map 使用的坐標系 WGS84 的 WKT 格式: GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]] 在 PostGIS 中被應用在 spatial_ref_sys 表內的 srtext 欄位中 proj.4: 是另一種描述投影的文本格式，例如: +proj=tmerc +lat_0=0 +lon_0=121 +k=0.9999 +x_0=250000 +y_0=0 +ellps=aust_SA +units=m +no_defs，用幾個參數如橢圓角度、基準、長度單位…來定義投影的方式。 Proj.4 是開源社群常用的地圖投影資料庫，據我所知 PostGIS 和 GDAL/OGR 這些軟體都直接或間接的使用到 Proj.4 資料庫 在 PostGIS 中被應用在 spatial_ref_sys 表內的 proj4text 欄位中 SRID:...

前言 兩年前曾經用 GitHub Page 的靜態網站搭建一個部落格，當時沒有想太多，只希望能快速有個部落格來寫寫文章記錄碰到的各種坑，但因為 GitHub 上的內容都是公開的(畢竟是開源的)，又可以讓人隨意下載，想了一下決定重新搭建部落格，也就有了這篇文章的誕生。 部落格選擇 開始搭建部落格之前有做了一點研究，整理網路上大家對部落格的看法如下: Medium 這個大家都知道，甚至平常看到很多技術文章都是寫在 Medium 上，但好像因為付費牆的一些因素，導致滿多技術寫手紛紛出走，想了一下，我覺得想要有一個客製化的部落格，不想被綁定在某個平台上，所以果斷放棄 Medium 這個選項。 Wordpress Wordpress 我沒有用過，但一直以來都知道他聲勢浩大，尤其是在 CMS 的生態系中更是霸主，算是很成熟且市占率很高的軟體，甚至很多接案的人都會用 Wordpress 快速做出不錯的網站，但對於只是想要寫寫文章的我來說，Wordpress 還是稍嫌複雜了一點。 GitHub Page GitHub Page 是我第一次建立部落格使用的選項，這是 GitHub 推出的靜態網站代管服務，對於簡單的網站如: 履歷、介紹…等等算是不錯的選擇。而且 Github Page 不需要租 server 和買 domain name，碰不太到環境建置，只要會用 git push 上去，就會有一個 GitHub 提供的 https://<name>.github..io 的 url，例如我之前的部落格: https://dysonma.github.io 一切看似美好，但其實 GitHub Pages 也有一些 限制: 資源空間只有 1GB 上限 每月的流量限制是 100GB 每小時只能 build 10 次 另外，有一些靜態網站產生器提供快速建立一個靜態網站，還含有很多主題可以選擇，例如: Hugo, Hexo, jekll，這些都是用 markdown 語法就可以寫文章。對我來說，主題看起來很不錯，使用上也很方便，所以納入考量。 談談 Jamstack 看了這麼多選擇後，查到這十年間的前端生態演變出一種叫 Jamstack 的名詞。...