文章

顯示從 5月, 2023 起發佈的文章

[工作經驗] 為何同事(自己)寫的程式碼總是很醜?

-
圖片
Code 可讀性低又到處重複的話，經常導致 bugs 不斷發生。一旦我們用 git blame 發現是同事幾年前寫的 code，就會想說為什麼這麼醜? 但如果是自己寫的，就...沒辦法啦，以前不知道在想什麼亂寫的。真的可以這樣想嗎? 沒辦法寫出 Good Code 的阻力 要怎麼寫出好的 code? 有些原則我們都可能聽過:  KISS , DRY , YAGNI , SOLID , 甚至是 CRISP ，一定還有一大堆我沒列出來的原則，這些都是不錯的 building box，但是老是有一些現實因素干擾著我們: 時間緊迫 隔天就要 release 的程式，user 今天臨時才發現一個很嚴重的 bug 要修。但仔細一看其實是簡單的小錯誤，但又發現要改的 code 剛好可以 refactor 達到 DRY，我們會怎麼做? 當然要 DRY，於是改了大概一百行程式碼 還是改發生錯誤的那一行就好，避免 refactor 又製造不可預期的 bug 但其實這並不是二分法，大多時候我們會評估時間還有程式碼的複雜度。有可能折衷一下： refactor 20 行信心高的 code，發個新 issue 等到下次 release 再去 refactor 剩下的 80 行 code。 不熟悉 寫程式的怎麼會不熟悉? 但一個大型 project 通常都是分工的，我們如果剛好是新進員工，或是剛踏進同事負責的領域，周圍一定圍繞著我們不熟悉的程式碼，這時我們也不敢大刀闊斧地更改同事已經寫好的程式碼。 有時候更慘，寫這段 code 的人已經離開公司，或剛好休長假，但目前要做的 issue 就剛好需要你改同事的程式碼，這時候我們可能只會追求 correctness，把其他 principles 全部拋於腦後，寫出醜到爆的程式碼，但至少功能正確。 Legacy code 也常常是我們都不熟悉的範圍，甚至是當初寫這段 code 的同事也早就忘記他當初為何這樣寫了。 太複雜 當 issue 非常複雜，牽扯到一些困難的 algorithm，但已經有明訂的 design spec 的時候，實作時才發覺是不是另外一種寫法比較好，但如果發生問題我們就很難清楚地知道到底是 design spec 有問題，還是因為我們自作聰明亂改? 與其給自己找麻煩，還不如就乖乖照著 spec 走。 當可以寫 Good Cod...
發佈留言
閱讀更多

[工作效率][Linux] 指令完成寄信通知我，讓我先去看劇?

-
圖片
有些再簡單不過的指令像是 mv, cp, rm 遇到檔案一多的時候有時候可以跑好幾分鐘，甚至一小時以上。我也不曉得他什麼時候會跑完，30 秒? 10 分鐘? 2小時? 都有可能。 手邊也暫時沒其他工作可以平行進行的話，也只能放著讓他跑。 但時不時就會好奇他跑完了沒，一直來回切換視窗，或是去忙別的事卻一直跑回房間看螢幕。這時候我們就會很想要讓他跑完時通知我們。 Sequential Commands 最簡單的方法就是與其執行一個指令，不如執行 multiple commands，讓前面指令跑完就跑通知用的指令，我們這邊以 sleep 當作一個跑很久的指令： sleep 10; notify_me 要注意的是這裡最好用 ; 把指令串起來，最好不要用 &&，因為 && 一定要前面的指令成功 (return zero exit code)，後面的指令才會執行，我們最好別太把握前面的指令跑到一半一定會不會發生錯誤。 通知的媒介 至於通知的指令要用哪種方式，我就有試過以下的方式： 播放聲音通知 在 VNC 視窗傳送通知到 VNC 桌面 (e.g., notify-send) 用第三方工具傳送通知 (e.g., Slack, Teams) 寄送 email 通知 但實際用過之後才發現一些缺點。聲音很容易因為人不在房間就沒聽到；VNC 視窗傳送就限制你只能在 VNC 視窗跑指令，而且人沒盯著螢幕也很容易錯過；第三方工具看起來最棒，但有時因為第三方工具或網路不穩就是會沒送到通知。 寄信+手機 app 還是最可靠 最可靠的還是透過簡單的指令像是 mail, sendmail, mutt 等工具來寄信。不過 IT 要先設定好信箱，但公司通常都會有。 於是我們就可以在 .bashrc 寫一個 function，例如我們可以使用 mutt 來當作寄信的工具: # Send an email with only the subject # # Examples: # mail2me # mail2me "Command finished" function mail2me() { local -r subject="$1" mutt -s "${subject}" ...
發佈留言
閱讀更多

此網誌的熱門文章

[試算表] 追蹤台股 Google Spreadsheet (未實現損益/已實現損益)

-
圖片
在 Dcard 上發了一篇文結果引起超多網友回應想要看試算表，我就來整理一下我追蹤台股用的 Google 試算表給大家。 這個試算表我目標是以 "簡單" 為主，底下我也會講解公式的運作原理，希望大家能以此試算表輕鬆擴充自己想要的功能。 功能 未實現損益 (Unrealized Gain/Loss 表) 不管同一支股票是不是有部分已經賣出，只要你還持有未賣出的股票這邊都看的到。 已實現損益 (Realized Profit/Loss 表) 我過去的績效如何? 在這個表一目了然。 未實現損益: 詳細資料 (Unrealized Stats 表) 我還持有多少股? 每股市值多少? 每股的成本是多少? 在這個表可以快速追蹤。 手機友善 (Mobile Friendly) 我為了在手機上也可以快速看我想看的資訊，把 "Unrealized Gain/Loss" 做成比較窄的版型。 只要下載 Google Sheets app 打開試算表就可以了。 Google Spreadsheet 連結 Google Drive 連結 Stock Tracking 使用方式 請先點 "檔案" -> "建立副本"，copy 一份試算表到你自己的 Google Drive 將 "Current Price" 表單中填上你想要追蹤的股票代號和名稱 將 "Transactions" 表單中刪除範例資料，但請務必留下第 2 列 (因為有公式)，然後慢慢往下填入你的資料 Step 1: 檔案 -> 建立副本 Step 2: 新增/刪除股票代號和名稱 (紅框圈起處)，灰色底欄位代表有公式 Step 3: 在 "Transactions" 表填入資料到白色底欄位 (紅框圈起處)，灰色底欄位代表要讓公式自動計算 未實現損益的正確算法 其實在發 Dcard 文之前我自己也像 另外一個表單 犯了同樣的錯誤，就是只有在股票全部賣光光 (持有 0 股) 後計算的未實現損益才會正確。還沒全部賣光怎麼辦? 難道就不顯示了嗎? 飲料的例子 只要股票中途賣出一部分，目前還持有部分股票的話，感覺計算就突然變得很複雜。但不用怕，我們來用飲料當作股票舉個超簡單的例子 (1 杯=1...
閱讀更多

[Side Project] 互動式教學神經網路反向傳播 Interactive Computational Graph

-
圖片
成品 互動式網頁連結:  Interactive Computational Graph 微積分課經典的範例 df/dx sin(x) / x: 2 個 inputs, 1 個 output, 沒有 hidden layer 的 fully connected neural network: 為何要做這套工具 以前在學 machine learning 的時候覺得最難理解的部分就是 backpropagation，也就是神經網路到底是怎麼用數學來做訓練的。 我們知道神經網路就是長這樣子: Source: Wikipedia 但實際上每個 neuron (圓圈圈) 裡面有許多基本的數學運算，像是 sum 還有 activation function: Source:  Neural Networks and Machine Learning 當我們把所有東西綜合在一起，腦袋就會打結，到底 chain rule 是怎麼在這麼複雜的神經網路之間套用的? 就算了解基礎也很難相信實際上到底怎麼運作的。我又沒有要真的使用的話，網路上的教學就覺得看看就好 Source:  A Step by Step Backpropagation Example 但決心要了解 backpropagation 細節之後，不少教學都提到了 computational graph，從基礎的數學運算當作 nodes 來去理解似乎是比較簡單的方式。 後來找到了這篇文章  Calculus on Computational Graphs: Backpropagation  把 chain rule 講解的簡單至極，於是就在想，為何我不做一個網頁，讓大家可以自由地組合想要的 graph，然後看一下 chain rule 是怎麼流通的。 失敗作經驗 在做這次 side project 前，其實早在一年前我就開始作另一個 side project 是想展現神經網路的訓練過程。名稱叫做 explain-derivatives，是被 TensorFlow 的一個網頁 A Neural Network Playground 啟發的。 但由於一開始欠缺規劃，想到什麼就加什麼功能進去，造成架構一直修改，最後由於程式碼架構太過複雜就放棄了。 這個 project 是用 Cy...
閱讀更多

[插件] 在 Chrome 網頁做區分大小寫的搜尋

-
圖片
寫軟體的時候最常用到的功能就是上網查 API 文件，但是常常會遇到一個困擾就是，搜尋的文字在 Chrome 裡面是不區分大小寫 (case-insensitive) 的。有的時候是還好，多按一些 F3 就找到了，可是有時候實在是太多大小寫的東西混在一起，這時候我們有一些快速的解法: 用 Firefox 搜尋 (Firefox 的搜尋框裡面預設就提供有 match case 的功能了) 開 DevTools 按 Ctrl + Shift + F 進行全部東西的搜尋 (不過大概會發瘋) 用插件的解法算是意外發現的，原本只是在找有沒有可以用 regex 搜尋的插件，沒想到意外發現  regex 的插件也是可以拿來做區分大小寫 (case-sensitive) 的一般搜尋。 用 Chrome Regex Search 來做區分大小寫的搜尋 先裝好 Chrome Regex Search 之後，按 Ctrl + Shift + F 或是點工具列的圖示，打上想找的文字就可以了。 例如我最近在看 Qt QTextCursor 的文件，但是我只想找 "cursor"，很不幸的如果用 Chrome 預設搜尋他會把一大堆 QText Cursor 也會找到: 如果用 Chrome Regex Search 就會侷限在小寫的 "cursor": 用 Regex 的陷阱 如果你不知道 regex 是什麼，那你很有可能會發現在搜尋一些含特殊符號的東西會搜尋到怪怪的東西，不然就是搜尋會失敗。 這是因為 regex 本來就是偏工程師在用的東西，有一些符號是有特殊涵意的，所以如果搜尋的字包含以下任何特殊符號記得要在前面加一個反斜線 \ ( ref ): . + * ? ^ $ ( ) [ ] { } | \ 例如我想搜尋 1+1=(2-1)+1*1 ，那其實要打 1\+1=\(2-1\)\+1\*1  才會正確找的到。 是不是很麻煩? 不過如果你要找的東西有特殊符號的話，其實用一般 Chrome 的搜尋通常是不會有太多搜尋結果的，那就用一般搜尋就好。 Chrome 什麼時候要支援大小寫搜尋? 其實上面弄了那麼麻煩，還不如開個 Firefox 搜尋更快。那我就滿好奇，這麼基本的功能怎麼 Chrome 一直都沒做? 找了一下才發現 Super User 有人...
閱讀更多