https://blog.techbridge.cc

TechBridge 的文章

  1. 程式設計 Programming
前言 只要你是個前端工程師,或是曾經開發過前端專案,相信對 source map 都不陌生,不管你常用的 bundler/generator 工具是什麼,幾乎都有完整的 source map 支援,甚至有各種選項可以配置,但是你知道 source map 的原理嗎?它是怎麼產生的?它又是怎麼幫助我們從 bundler/generator 產生的程式碼中找出對應的原始碼,讓我們方便除錯呢? 這些問題我也不太清楚,雖然大致上的原理稍微思考一下都能夠猜個八九不離十,但對於實際運作細節從來沒有探討過,因此這週末利用了點時間稍微研究一下,記錄在這篇文章跟大家分享。 Source Map 是什麼 簡單來說,source map 就是儲存了原始碼與編譯後程式碼的對應關係之檔案,讓你在開啟 Devtool 時,能讓瀏覽器透過載入 source map 的方式幫助你定位原始碼位置,方便下中斷點除錯。 以目前的瀏覽器實作來看,都是只有在打開 Devtool 的時候,才會根據它獲取的 source map url 資訊來載入 source map,不會影響網站載入速度與一般使用者的體驗。 提供瀏覽器 source map url 的方式有兩種,一個是將其寫在編譯後程式碼檔案中,也是大多數現在 bundler/generator 的做法: 另一種則是透過特殊的 http header,讓瀏覽器在 request 你的 javascript 檔案時,能夠從 header 欄位中找到 source map url […]
  1. 程式設計 Programming
前言 只要是開發 JavaScript 相關的專案,我的起手式通常都是 ESLint + Prettier,如果你沒有聽過這兩套的話我稍微講一下,Prettier 是幫你格式化程式碼用的,用了之後不必再跟其他人爭論到底要不要加分號,if 區塊的 { 要不要換行,一行最多到底能幾個字。只要用 Prettier,就是讓它幫你全權決定(雖然也有設定檔可以調整就是了)。 這其實對團隊滿有幫助的,因為程式碼格式可以統一,要空幾格也可以統一,在基本的 coding style 上面會長差不多。而 ESLint 雖然也有些跟格式相關的部分,但更多的是寫程式時候的一些 best practice,例如說使用變數前要先宣告、不會更改的變數用 const 之類的,這已經脫離了格式的範圍。 所以 ESLint 搭配 Prettier,就可以讓整個 codebase 的品質有最低限度的保障,至少不會出現排版很慘烈的狀況。而使用 ESLint 時最多人搭配的規則應該就是 Airbnb JavaScript Style Guide,裡面有每一條規則的詳細解釋。 之前在寫 code 時我突然想到一個地方好像很適合用 ESLint,就嘗試了看看,發現要做一個「堪用」的 plugin 比想像中簡單一些,就以這篇文章記錄一下過程跟心得。 問題背景 當時碰到的狀況是這樣的,在專案裡面我們用 react-i18next 來管理 i18n 相關的東西,一段程式碼可能會長得像下面這樣: 使用 useTranslation 可以拿到一個 function t,把 key 丟進去之後就可以得到翻譯後的字串,而背後對應到的會是多個語言檔: 這就是 i18n 的基本原理,語言檔加上對應的 key,就可以根據不同語言顯示不同的文字。看起來雖然簡單,但 i18n 比較麻煩的事情之一就是當你有參數的時候,在這邊就先不多提了。 而我們通常不會把所有翻譯都放在同一個檔案裡面,會用 namespace 去切分,至於要怎麼切就看專案,有些可能根據頁面分,有些根據使用到的地方,例如說上面提到的 […]
  1. 程式設計 Programming
前言 在程式設計和軟體開發的圈子中,有幾本經典的書籍即便 在資訊科技快速變遷的時代中仍歷久彌新(你第一個在腦海中浮現的可能是人月神話等書)。上次為讀者們介紹的是筆者最近又重新閱讀的 Joel on Software 約耳趣談軟體這本書(有中文譯本,但已停止出版),這次我們接著介紹續集 More Joel on Software 約耳續談軟體。More Joel on Software 約耳續談軟體,主要是討論軟體開發人員的職涯規劃和發展以及軟體企業的經營管理等議題。兩本都是值得軟體開發人員一讀的好書。 在介紹這本書的內容之前,我們先來介紹這位作者 Joel Spolsky。有些讀者可能沒有聽過 Joel 的大名,但事實上 Joel 是知名程式設計問答平台 Stack Overflow 和看板軟體 Trello 的共同創辦人,也曾參與 Microsoft 的 Excel 應用開發,同時也是早期非常知名的技術部落客和作者,特別的是他後來移居紐約開創事業而非傳統的加州矽谷灣區,同樣跳脫了一般人的思考框架。 書中的內容主要是整合 Joel on Software blog 部落格的內容並額外新增一些新的主題。書中使用輕鬆詼諧的文筆介紹軟體開發人員職涯發展和軟體企業經營管理的相關議題討論,除了有些技術探討的章節外不會覺得太過生硬。接下來本文會摘錄一些書中重要的內容和觀念以及加入筆者個人自己的一些心得進行分享。 給未來開發人員的提醒 有可能是因為本書有許多內容是從網站上整理而成,在內容排序上各自章節分別獨立,沒有特別的次序排列。給未來開發人員的提醒這個主題不是放在書中的最前面,但若能在從開發者個體出發再邁向人力資源管理和軟體開發管理會比較有循序漸進的感受。當然這個主題主要是給還是學生的讀者但也適合已經成為開發人員的讀者再次回顧和反思。 學習如何溝通寫作:溝通寫作能力是作者一再強調的基礎能力。對於程式開發人員來說,寫出良好的程式和文件其實是一體兩面的事情,寫程式和寫文件一樣不單只是自己要能看得懂,重點是要讓其他工作人員也能理解並閱讀。此外,在進行一個軟體專案時,時常會需要非同步的溝通,此時文字表達能力就變得十分重要。 學習 C 語言:雖然目前有許多新的程式語言不斷推陳出新,但學習 C 語言會讓我們更理解電腦軟硬體間的互動關係和底層的運作原理。 非專業的領域課程不要一開始就排斥:學習不同領域的事物對於建立領域知識和理解這個世界會有幫助。 修習會有大量程式實作的課程:唯有透過不斷實作才能磨練好程式設計這項技能。 學習個體經濟學:雖然經濟學和技術實作沒有太大關係但卻是解釋這個世界運作的重要理論基礎之一,可以幫助我們去增加個人附加價值並理解這個世界。 去找一個程式實習工作:只有在真實環境下才能理解軟體專案管理和軟體開發流程和課程理論的差異並從真實的軟體開發中鍛鍊開發除錯能力。 持續學習:技術變化日新月異,唯有保持持續學習的心態才能在軟體開發領域持續進步。 人力資源管理 軟體開發的本質是人,如何尋找並管理好軟體開發人員一門重要的課題。然而開發人員往往不喜歡被管理和約束,也很容易對於不當的管理方式和不舒適的開發環境進行反彈。書中提到常見的幾種管理方式以及優缺點提供我們參考借鏡。 指揮與控制管理方法:由上而下的管理模式,看似井然有序,然而卻隱藏著許多風險。例如:第一線的工程師和客戶支援工程師往往比上層管理者更了解產品細節和客戶需求。但透過指揮與控制管理往往會造成微管理(micromanage)以及與實際市場和問題脫節等問題。 經濟管理法:透過額外的激勵獎金或是報酬來激勵開發人員。看似短期有效但若是時常使用外部誘因來激勵成員,等到外部因素消失後就會造成動力不足等問題。 認同管理法:授權並讓開發人員認同以及營造良好的開發環境是比較推薦的管理方式,但在實際實行上也會有許多挑戰,重點還是讓成員能敞開心胸一起討論怎麼樣的環境和管理方式是適合組織運作。 軟體開發管理 軟體開發管理從開始規劃設計專案到真正開工到維護及客戶支援(support)是軟體開發管理常見基本的流程循環。作者建議開發人員和專案管理人員需要具備大局觀,在開發軟體專案前一定要確認好需求再開始寫程式,並權衡投入的資源的商業價值取捨。例如:若是沒有用的功能,產品的使用介面再好,也沒有人會使用。 […]
  1. 程式設計 Programming
前言 前端狀態管理方式百百種,但大致上可以分為兩類: 一種是與 UI view library 綁在一起的,以 React 為例,React state、Context API 與去年剛推出的實驗性套件 Recoil 就屬於這種,主要將狀態資料存在 React tree 中。 另一種則是 view-layer agnostic library,資料存在外部 store,讓你可以套用在任何 UI framework 或 view library,如最常見的 Redux、Mobx 等。 再往下細分可以用 Mental modal 分為:Flux、Proxy 與 Atomic 等三種狀態管理邏輯,其中 Flux(Redux)與 Proxy(Mobx)算是出來比較久的,而 Atomic 則是隨著 Recoil 的推出而興起,今天就是想來了解一下 Atomic 的概念是什麼,建構在其上的套件用起來是如何。 但是,今天我想介紹的不是 Recoil,而是一個與 Recoil 採用同樣概念,但 API 與整體 bundle size 小非常多的 Jōtai。 minified […]
  1. 程式設計 Programming
前言 知道 CTF 這東西很久了,但直到前陣子才真正去參加了線上辦的 CTF 比賽,不過因為會的東西有限,只能打 web 題,或是剛好有涉獵的 misc 題。雖然本來就覺得 CTF 很有趣,但實際去玩了以後收穫比我想像中的還多。 身為一個前端工程師,知道各種前端相關的知識十分合理,然後又因為看得文章夠多,所以除了一些新的特性以外,平時比較難有那種:「哇!居然可以這樣」的感覺。但在用心打 CTF 的兩個假日裡面,我獲得了數次這種感覺,而且是:「哇靠!!!!居然可以這樣嗎!!!」,明明就屬於前端的範疇,但我卻從來都不知道還可以這樣。 我認為前後端工程師去打 CTF 的 web 題,可以補足前後端相關的知識,而且這種知識是你平常在工作中或是生活中很難獲得的,但卻在資訊安全的領域很常見。想要防禦,就必須先知道怎麼攻擊。 因此這篇就稍微分享一下 CTF 是什麼,該如何參加,又該怎麼解題。 什麼是 CTF 其實可以先參考這兩篇文章: 跨出成為駭客的第一步,來打打看 CTF Web 吧! Day1: [Misc] What is CTF ? 不免俗地還是要講一下 CTF 的全名 Capture The Flag,奪旗。而現在講 CTF 指的應該都是以拿到「flag」為目標的遊戲或是比賽之類的。其實底下還有細分不同種模式,這篇講的會是最常見的 Jeopardy 模式,只要拿到 flag 然後在網站上送出,就可以拿到這題的分數。 而這個「flag」通常會是一個字串,帶有特定格式讓你能區分出來它是 flag。flag 可能會藏在各個地方,例如說圖片裡面啦,或者是機器內的某個檔案之類的,而你的目標就是找出這個 flag,就獲勝了。 對我來說這模式其實並不陌生,大家以前有玩過「高手過招」嗎?在高手過招裡面雖然不是以拿到一個固定的 flag 為目標,但「找到前往下一關的方法」其實就跟 […]
  1. 程式設計 Programming
前言 在程式設計和軟體開發的圈子中,有幾本經典的書籍即便在資訊科技快速變遷的時代中仍歷久彌新(你第一個在腦海中浮現的可能是人月神話等書)。這次要為讀者們介紹的是筆者最近又重新閱讀的 Joel on Software 約耳趣談軟體這本書(有中文譯本,但已停止出版)。事實上,這本書還有一本續集 More Joel on Software 約耳續談軟體。Joel on Software 約耳趣談軟體,主要是談論軟體專案管理以及人才培訓與軟體創業經營的議題,而約耳續談軟體主要是討論軟體開發人員的職涯規劃和發展等議題。兩本都是值得軟體開發人員一讀的好書。 在介紹這本書的內容之前,我們先來介紹這位作者 Joel Spolsky。有些讀者可能沒有聽過 Joel 的大名,但事實上 Joel 是知名程式設計問答平台 Stack Overflow 和看板軟體 Trello 的共同創辦人,也曾參與 Microsoft 的 Excel 應用開發,同時也是早期非常知名的技術部落客和作者,特別的是他後來移居紐約開創事業而非傳統的加州矽谷灣區,同樣跳脫了一般人的思考框架。 書中的內容主要是整合 Joel on Software blog 部落格的內容並額外新增一些新的主題。書中使用輕鬆詼諧的文筆介紹軟體開發和專案管理的相關議題討論,除了有些技術探討的章節外不會覺得太過生硬。接下來本文會摘錄一些書中重要的內容和觀念以及加入筆者個人自己的一些心得進行分享。 如何打造良好的軟體開發環境? 作者在開頭導讀用一個有趣的虛構小故事點出許多軟體開發人員在職涯中時常會遇到的難題:在公司組織內要繼續當一個獨立貢獻者(Individual Contributors)還是轉作管理職? 引言中一位技術優秀的軟體工程師在面對主管去高空彈跳受傷後接任管理者的角色,每天工作大部分時間面對的不再是單純的技術問題、程式碼和學習新的技術,而是大部分的時間要應付西裝筆挺的 BD、業務、奇裝異服的設計師以及高層老闆等牛鬼蛇神,更別提的是每天開不完的例行會議和團隊成員的 1-1 meeting 以及績效考核評比。 此時許多開發人員會不禁內心吶喊:為何不能只專心寫好程式就好? 優秀的軟體開發者要成為同樣優秀的專案管理者需要補足額外的技能(例如:商業知識、產品思維、心理學和領導管理能力等) 如果你真的無法逃避成為專案的管理者又不想落入彼得原理 Peter Principle的窠臼當中,不妨用約耳測試(Joel Test)當作一個檢視目前團隊中軟體開發品質作為努力的方向(雖然作者提出這個觀點年代是在西元 2000 年左右,但目前來看仍有許多參考價值,不得不佩服作者的一些前瞻的眼光)。以下摘錄一些書中重要的內容以及加入筆者個人自己的一些心得進行分享。 你有使用原始碼控制系統嗎?使用版本控制系統可以更容易讓團隊協作或是確保程式碼的保存。換成今日的說法:你們團隊是否有在使用 Git 等版本控制工具呢? 你能用一個步驟建出所有結果嗎?意思就是說,你們團隊需要花多少步驟和時間可以從原始碼部屬可以推出的產品?若是每次要推出產品總是要經過 20、30 個步驟,那若出現緊急狀況一定雞飛狗跳。換成今日的說法:你們團隊是否有使用合適的 CI/CD 和 Container 等自動化整合和部屬及雲端服務工具呢? […]
  1. 程式設計 Programming
前言 很多人可能會認為前端工程師對於美感都有一定的水準,甚至應該要會一點點設計,但現實中應該有很大一部分的前端工程師跟我一樣,其實負責處理狀態管理居多,對設計沒有太多的著墨。 雖然現實是如此,我個人還是非常喜歡欣賞網路上大神們透過 CSS、Web API 所創作的東西,今天就來分享幾個我這陣子看到覺得蠻有趣的 WEB 特效與技巧! Motion blur 忘了是從哪裡看到這個網站 – Motion Blur Scrolling Demo,驚為天人,雖然看了其實眼睛會不太舒服,但特效實在太酷,無法大聲斥責。 作者的程式碼公開在此:motionblur,我把一些看來是作者嘗試做的優化拿掉,擷取重點來解釋,大家也可以到 CodeSandbox 查看程式碼與把玩 Demo 不過要注意一點,這個特效只有在電腦版的 Chrome 與 Edge 上表現最好,firefox 還 ok,Safari 則是完全崩潰,電腦或手機都無法呈現效果。 原理解析 從名稱應該就能看出端倪,既然是 motion “blur”,自然會想到 CSS 的 filter:blur() 屬性,blur() 接受單一數值,例如:5px,不能是百分比,數值越大越模糊: image source: MDN – filter 模糊是有了,但 blur 的模糊感覺跟範例中的 motion blur 好像有點差距,要讓畫面在上下捲動時,有拉長模糊的感覺才對,這種整片均勻模糊的樣子似乎不太對呀? 要解開這個謎題,得先提到一個可能較少為人知的知識:像 blur 這種 filter-function 的屬性大多都有對應的 svg-filter,透過 svg-filter 你就能更細緻的調整參數。使用方式則為在你想要套用 filter 效果的 DOM 元件上,用 filter: url() 來指定 svg 的 id,e.g.: 以 blur(5px) 來說,其內部是用高斯函數的標準偏差值(stdDeviation)來決定畫面上多少 pixels 會互相交錯融合,對應的 svg 為: […]
  1. 程式設計 Programming
前言 說身為一個前端工程師,理所當然會知道很多與前端相關的知識,像是 HTML 或是 JS 相關的東西,但那些知識通常都與「使用」有關。例如說我知道寫 HTML 的時候要 semantic,要使用正確的標籤;我知道 JS 應該要怎麼用。可是呢,有些知識雖然也跟網頁有關,卻不是前端工程師平常會接觸到的。 我所謂的「有些知識」,指的其實是「資訊安全相關的知識」。有些在資訊安全裡面常見的觀念,雖然跟網頁有關,卻是我們不太熟悉的東西,而我認為理解這些其實是很重要的。因為你必須懂得怎麼攻擊才能防禦,要先知道攻擊手法跟原理,才知道該怎麼防範這些攻擊。 在正式開始之前,先給大家一個趣味題目小試身手。 假設你有一段程式碼,有一個按鈕以及一段 script,如下所示: 現在請你嘗試用「最短的程式碼」,實作出「點下按鈕時會跳出 alert(1)」這個功能。 舉例來說,這樣寫可以達成目標: 那如果要讓程式碼最短,你的答案會是什麼? 大家可以在往下看以前先想一下這個問題,想好以後就讓我們正式開始吧! 防雷............. DOM 與 window 的量子糾纏 你知道 DOM 裡面的東西,有可能影響到 window 嗎? 這個行為是我幾年前在臉書的前端社群無意間得知的,那就是你在 HTML 裡面設定一個有 id 的元素之後,在 JS 裡面就可以直接存取到它: 然後因為 JS 的 scope,所以你就算直接用 btn 也可以,因為當前的 scope 找不到就會往上找,一路找到 window。 所以開頭那題,答案是: 不需要 getElementById,也不需要 querySelector,只要直接用跟 id 同名的變數去拿,就可以拿得到。應該不會有比這個更短的程式碼了(有的話歡迎留言打臉我QQ) 而這個行為是有明確定義在 spec 上的,在 7.3.3 Named access […]
  1. 程式設計 Programming
前言 在軟體工程師和程式設計的工作或面試的過程中不會總是面對到只有簡單邏輯判斷或計算的功能,此時就會需要運用到演算法和資料結構的知識。本系列文將整理程式設計的工作或面試入門常見的程式解題問題和讀者一起探討,研究可能的解決方式(主要使用的程式語言為 Python)。其中字串處理操作是程式設計日常中常見的使用情境,本文繼續將從簡單的字串處理問題開始進行介紹。 要注意的是在 Python 的字串物件 str 是 immutable 不可變的,字串中的字元是無法單獨更改變換。 舉例來說,以下的第一個指定字元變數行為是不被允許的,但整體字串重新賦值指定另外一個字串物件是可以的: 執行結果: 常見問題 字串轉整數 Problem: String to Integer (atoi)Implement the myAtoi(string s) function, which converts a string to a 32-bit signed integer (similar to C/C++’s atoi function). The algorithm for myAtoi(string s) is as follows: Read in and ignore any leading whitespace. Check if the next character (if not already at the end of the […]
  1. 程式設計 Programming
前言 年末年始很適合來回顧過去展望未來,2020 對我們這代人來說絕對是難以忘記的一年,面對 2021,希望我們繼續保有對生活的熱情,享受生命的每一刻美好。 2021 的第一篇文章不談生硬的技術、不寫長篇的教學文,我想分享一下在 2020 的最後一個 quarter 中,公司團隊所嘗試的 self-improvement 計畫,討論它為我們帶來的好處與是否適合大家嘗試導入。 何謂 self improvement 計畫?又為何重要? 這個計畫實際上是由我們團隊新進主管所提出的,他認為,除了完成工作上交付的任務外,持續去精進專業能力是我們工程師的一種生活方式,這點相信毋庸置疑,大家都在推廣要撰寫部落格、參與開源專案、製作 side project 等等,這都是為了精進我們的專業能力。 然而,生活不是只有這個面向,工程師也需要照顧家人、培養各種嗜好?,以及享受其他生活美好;或更簡單點,維持你的 mental health。 若要在下班後的時間,同時完成這所有的事情,著實是相當困難。 因此他提出的 self improvement 計畫就是希望能建立一個框架,讓這一切從理想狀態變成現實。 相信大家都聽過 Google 著名的 20% time,也就是能利用上班時間的 20% 來做自己想嘗試的專案,無論是否直接跟工作有關聯。 所謂的 self improvement 計畫就是類似的概念,利用每個 sprint 的 20% 時間來增進自我,差別在於執行的專案必須要能夠幫助到你在工作上的成長。 以一個 sprint 兩個星期來說,總共十個工作天,20% 的時間等同於每個 sprint 必須騰出兩天的時間給團隊成員執行自我精進計畫。 沒錯,這等同於在要求公司對員工進行投資,但其實你仔細想想是非常合理的,畢竟當你精進了專業能力,公司當然也會受惠,更別提在過程中你的產出可能就已經直接對公司帶來正面影響,像是你可能在過程中幫忙製作了增進大家效率的開發工具等等。 不過說是這樣說,一切還是很理想化,因此在真正執行這個計畫前,團隊內部是進行不少討論的,尤其是需要說服 PM 們認同這項計畫的好處,因為這是有可能會影響到公司專案的時程。 實際運作方法 Self […]
  1. 程式設計 Programming
前言 部落格需要顯示發佈時間,餐廳網站要顯示訂位時間,拍賣網站則是要顯示訂單的各種時間,無論你做什麼,都會碰到「顯示時間」這個很常見的需求。 這問題看似簡單,不就是顯示個時間嗎?但如果牽扯上「時區」的話,問題就會變得再更複雜一些。以時區來說,通常會有這幾個需求: 網站上的時間需要在某個固定時區顯示,我在美國跟在台灣要在網站上看到同樣的時間 網站上的時間會根據使用者的瀏覽器設置不同,我在美國跟在台灣看到的時間會不一樣 PM 根本沒想過這問題,只考慮到當地的使用者,所以暫時不用擔心這個 而這還只是顯示的部分而已,還有另外一個部分是與後端的溝通,這個我們可以待會再提,但總之呢,要正確處理時間跟時區並不是一件簡單的事。 在最近這一兩份工作剛好都有碰過相關的問題,因此對這一塊有點小小心得,就寫了這一篇來跟大家分享一下。 先從 timestamp 開始談起 要談時間,我比較喜歡從 timestamp 開始談起,或講得更精確一點是 Unix timestamp。 什麼是 timestamp 呢?你打開 devtool 的 console 然後輸入:console.log(new Date().getTime()),出來的東西就是我們所謂的 timestamp。 而這個 timestamp 指的是:「從 UTC+0 時區的 1970 年 1 月 1 號 0 時 0 分 0 秒開始,總共過了多少毫秒」,而我寫這篇文章的時候得出來的值是 1608905630674。 ECMAScript 的 spec 是這樣寫的: 20.4.1.1 Time Values and Time Range Time […]
  1. 程式設計 Programming
前言 在軟體工程師和程式設計的工作或面試的過程中不會總是面對到只有簡單邏輯判斷或計算的功能,此時就會需要運用到演算法和資料結構的知識。本系列文將整理程式設計的工作或面試入門常見的程式解題問題和讀者一起探討,研究可能的解決方式(主要使用的程式語言為 Python)。其中字串處理操作是程式設計日常中常見的使用情境,本文繼續將從簡單的字串處理問題開始進行介紹。 要注意的是在 Python 的字串物件 str 是 immutable 不可變的,字串中的字元是無法單獨更改變換。 舉例來說,以下的第一個指定字元變數行為是不被允許的,但整體字串重新賦值指定另外一個字串物件是可以的: 執行結果: 常見問題 尋找唯一字元 Problem: First Unique Character in a StringGiven a string, find the first non-repeating character in it and return its index. If it doesn’t exist, return -1. Examples: 題目意思為輸入為一個字串,回傳第一個唯一(沒有重複)的字元索引位置,若沒有的話回傳 -1。可以假定字串只包含小寫字母。 Solution 字典比對法 class Solution: def firstUniqChar(self, s: str) -> int: # 建立一個字典儲存字元出現次數 count_dict = {} # 迭代所有字串中的字元進行字元出現次數統計 for […]

登入

歡迎加入 Miracoup
方便的閱讀是您能感受到的第一件事。
加入 Miracoup