我覺得要能夠寫好程式有幾個要點： 有個明確的需求，像是研究題目或想做些有趣的專案 寫出簡單會動的版本，先不用考慮太多複雜的設計 找一些可以優化目前程式的知識 最重要的是要拿自己的程式碼來改改看 重複 3-4 第三點需要一點靈感，像是看一些文章、影片，或是從一些經典的書來搜索。可以先選不會太複雜的來下手，重點是看完要能夠實際運用到手上的程式碼，改過之後就會更有印象。 我每次都會推薦從 Clean Code 這本書開始，裡面提到的改變都是一些看起來微不足道的東西，像是變數命名跟註解之類的，但累積起來會提升很多開發上的效率。 從書裡面的關鍵字可以往外延伸到其他更多的書，像是重構、敏捷開發之類的。實際上一開始列的那四點都可以從軟體工程的相關書籍中找到一些影子。 非常推薦博碩與歐萊里出版社的書，可以去天瓏書局網站上面逛逛，如果覺得買書很貴可以網路上找關鍵字，也是有很多線上資源可以參考。

VS Code 越來越完善了，幾乎可以整個從 Pycharm 轉移過來。目前收集的 plugin 開始變多，想開一篇來紀錄一下不錯的插件。 Darcula Theme 把 Pycharm 的深色主題移植過來。 Remote Development 因為我都是用網路連一台 Linux 工作站做遠端開發，這個可以讓程式在遠端執行。他一次會裝三個套件：SSH、Container 跟 WSL，如果不想全裝也是可以只選 SSH。 Live Share 如果想要遠端請教別人程式怎麼改，但不想用 TeamViewer 把整個桌面傳給別人看，可以用這個討論程式碼。 Python 讓 VS Code 可以 Debug Python 的程式碼，還有 Jupyter Notebook 支援。寫 Python 程式前 VS Code 會要求你裝，不然 VS Code 就真的只是個 Notepad。 Pylance 就是把 VS Code 變成 Pycharm 等級 IDE 的神奇玩意，可以自動補完程式碼、自動排版、查找來源等。 vscode-pdf 渲染 PDF，這樣就不用到外面開 GMT 畫出來的圖。 Excel Viewer 拿來解析很大的 .csv ，不然有時候會看到眼花。 Live Server 寫 html 存擋後會自動更新瀏覽器上的頁面。 Docker...

以前看到開源專案上面貢獻程式碼都是大神，遲遲不知道怎麼下手加入討論，很怕一個外行人去攪人家的局很不好意思。  今天分享一下貢獻開源的經驗，讓想要貢獻程式碼的朋友們可以跨出第一步。 前情提要 最近在 Scipy 上面看到一個 document 令人混淆的地方，花了一陣子研究原始碼發現是參數順序對不上的問題，雖然自己把問題繞過去了，但想說順便把這個 issue 反應給 Scipy 的開發者，確認 issues 裡面沒有人開過相關的主題，就來自己開一個吧～ 提交 Issue Issue 其實應用範圍很廣，從回報 Bug 到提供新想法都可以。 每個成熟的開源專案都有自己的 issue 模板可以套，照著裡面的空格填入就好。這次用 Bug 回報，主要要寫的就是敘述問題並重現錯誤，如果知道解法也可以順便附上。 Github 所有的文章是用 markdown 寫的，可以加入超連結、文字 highlight 等。 編輯的時候可以 Preview 看效果 開發者回覆 發了 issue 後過幾天會有開發者團隊開始分流，本來以為那些藍色標籤要自己貼，但實際上只有開發者可以貼。分流後會有對應專門的開發者來回覆，有時候也會有其他社群的人參與討論，有共識後就會請你去改程式碼然後發 Pull Request。 開發規範 改之前要去看他們的 Development guide，通常在原始碼根目錄的 CONTRIBUTING.md 裡面或他們網站上的開發者專區，Scipy 詳細的規範發 PR 時會再提醒一次。 Scipy 會對 commit 的內容與 PR 的名字做規範，例如文件相關的更改要在開頭加上 DOC:，他還會給你一個清單提示你該做什麼。 動手改 code 要改程式碼前要先把原本的程式碼 Fork 過來 正常來講應該要 clone 下來改，自己先在本機跑完測試再 push 到自己的 fork 上，但因為 scipy 有點太大只是要改個 docstring 要 clone 很久，所以就直接在 Github 上面改。改個 docstring 應該不太會報錯 (吧?...

如果想要用 Linux 除了灌雙系統外還有麼方法呢？ 假如你是用 Windows 10 專業版 / 企業版的話，有個不錯的選擇喔~ 就是在 Windows 下面裝一個內建的 Ubuntu 第一步 確定Windows的版本 是 Windows 10 專業版 / 企業版 版本更新至 1709 以上可以安裝 WSL 1，版本為 2004 以上可以安裝 WSL 2 兩者差別簡單來說就是 WSL 1 為 Windows 核心包裝成 Linux ，WSL 2 為 Linux 虛擬機，詳細差異可以看這篇 Comparing WSL 1 and WSL 2，如果要在上面安裝 Docker，建議安裝 WSL 2 是中央大學學生如果沒有專業版的話，學校有提供企業版可以安裝喔~ 請參考中央大學授權軟體去下載與開通 第二步 開啟”開發人員模式” 找不到開發人員模式的就去”更新與安全性”找 第三步 打開 Linux 功能 去 “程式與功能” 裡面找 “開啟或關閉 Windows 功能”，將 “Windows 子系統 Linux 版” 打勾，之後會要求重開機...

台北分校位於三重群光大樓的 12, 13F。 交通資訊為捷運先嗇宮站(橘線) 一號出口出去後左轉，然後左轉光復路一段。 接著一直走約 15 分鐘就會在右手邊看到很高的群光大樓。 不建議騎 Ubike，一方面搶不到車，另一方面停車地方距離大樓也有一段距離，不如直接走方便。      沿路有許多早餐店。 但過了這家 7-11 後就要走一段距離才會有吃的。 路上還有 Gogoro 換電站。 接近大樓還有一些流動餐車可以選。 大樓外。 大樓一樓有許多桌子，因為 9 點才能上樓，太早來可以在這裡先坐著等或吃早餐。 電梯前有門禁，搭電梯都需要刷卡才能按樓層，能到 1, 2, 3, 12, 13F 一般教室為開放式環境，每 8 人一桌。 桌子中間有插座與 USB 充電，wifi: Ai Academy 密碼 1~8，另有 chicony-guest 可以申請臨時帳號。 旁邊是助教辦公室。 有幾個會議廳可以線上預約使用。 有廁所跟飲水機。 另外有沙發區可以閒聊。 13F 還有咖啡機跟微波爐可以使用。 三樓是國際會議廳，整個會議廳是狹長形的，由五台投影機同步投影。 二樓是員工餐廳，有咖啡廳跟自助餐。 自助餐秤重低消 50 元，飯湯吃到飽，上面這樣 81 元。 也有一些配好的便當，65 元。 再來是一些線上資源，都要透過學號與密碼才能登入： 課表與講義：整個課程規劃是看影片與 PPT 為主，自己進度自己抓，不懂就問助教。講義不會一次放上去，會開放約一周的進度。 Gitlab：這個是他們自己架的 Gitlab，跟官方的沒有同步。 Mattermost：是一個自架聊天室，可以在上面問問題，學校也會在上面廣播一些事情。這東西有手機 app，這樣就不用一直開著分頁怕沒收到訊息。 Hub：練習用的硬體，每人有配到一張 1080ti GPU 的額度 (48,000 元的學費很多都在這RRR)，到後期做專題 3~5 人可以一起合開多 GPU 的伺服器。...

如何將 Windows 上的 Ubuntu Terminal 連動到 VS Code 中? 6/30 更新：現在 VS Code 有一個統一的外掛 Remote Development 可以使用，底下有個Remote – WSL 會幫你管理預設的 WSL 版本。 安裝 Remote Development：  打開 Powershell ：  輸入 `wsl -l` 將目前安裝的 Linux 版本列出來：  利用 `wsl -s ` 選擇要變成預設的 Linux 版本。  回到 VS Code 後按下左下方的連線按鈕，選擇 Remote-WSL: New Window。  會看到新視窗右下角變成 WSL 就成功了。 

Docker 是個好用的虛擬服務技術，可以快速將開發環境建立在其他電腦上，例如 Tensorflow 就有提供官方的 Docker image。但是如果想要用 Pycharm 遠端開發，會發現沒辦法直接跟遠端主機中 Docker container 內的 python 溝通。這時就得將 Container 的 SSH 服務安裝起來，讓 Container 直接可以對外連線，這樣對 Pycharm 而言就像是在另一台遠端主機上開發一樣。 如何將 container 的 port 22 暴露出去利用網際網路連線呢？ 參考資料：Dockerize an SSH service 首先我們要建立一個名為 Dockerfile 的空白文件，以下是官方的 Dockerfile 範例： <pre class="brush: bash; highlight: [5]; title: ; notranslate" title=""> FROM ubuntu:16.04 RUN apt-get update && apt-get install -y openssh-server RUN mkdir /var/run/sshd RUN echo 'root:screencast' | chpasswd RUN sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config # SSH login fix....

自從加入實驗室後有了新桌機，隨著待在研究室的間拉長，也就越來越少有使用筆電的需求，但還是有像 Workshop 這種非用筆電不可的場合。在這之中買了一台 15 吋的 Chromebook 刷 Ubuntu 用了一陣子，也嘗試了非常克難的用 iPad pro 遠端 Windows 桌電，但總體來說都算是實驗性質的替代方案。 在簡化的 iOS 下並不能做太多的事情，Ubuntu 做基本的文書又不太合適，最後還是希望回到筆電的懷抱，並想藉這個機會入手 Mac ，以學習另一個廣泛使用的作業軟體 OS X。不然每次有人拿 Mac 來問問題都很尷尬，因為我能做的也只是幫忙再 Google 一遍。 從去年開始期待入門款的 Macbook Air 翻新，但今年的發表會卻令人失望。256g 的價格高達 45,900元，決定改買一樣是 256g 的 Macbook Pro 13 no Touch Bar，而且剛好官網整新機的價格只要 40,600元，一怒之下就刷下去了!!!  現在在宿舍終於不用拿 iPad 接藍芽鍵盤打字了XD  最一開始買的 Smart Keyboard 還壞掉不能用…

前篇 Clean Code 簡單原則 中，談到寫出好的程式碼有兩個方法：一個是一開始就寫出乾淨的程式碼，但在對整個程式架構都不明瞭的情況下，就得寫出完美的程式碼非常困難；另一個則是靠重構程式碼，透過一次次等價交換小塊程式碼，讓其慢慢變得更乾淨。 重構是什麼？ 重構就是一種在不改變程式外在表現的前提下，將其程式碼變得更容易閱讀，且更容易修改。 通常聽到重構，可能會聯想到大興土木的變革，其實不然。重構是一種寫程式的小習慣，是每次動手寫新程式前都會做的事情，有點像是打掃房間一樣，每次進房看到有髒亂的地方就順手整理一下，維持房間的乾淨整齊，而不是等到東西都堆滿地，想要放一張新的桌子都沒地方可以擺。 另外，重構可以幫助我們慢慢形塑整個系統，讓軟體一直貼近實際需求。以往瀑布式開發一開始精心規劃的架構，拆成一塊一塊後分批完成，最後統合起來形成整個系統。但需求一直在改變，從規劃到釋出軟體經過了一年以上，到時市場趨勢已經不是當初規劃的那個樣子，會造成極大的風險。  隨著敏捷開發的出現，人們開始縮短開發週期，加快取得使用者的回饋，以利調整方向，但這會造成程式碼必須頻繁的修改。  改動就會有風險，在開發的過程中需要利用**兩頂帽子**的設計方式：「重構」與「添加新功能」。重構確保所有功能不被更動的前提下，利用每次的等價交換，重新思考如何將程式碼分拆成小塊容易維護的樣子，並將區塊間的相依性降低，之後再來添加新功能。 講了這麼多，重構到底要怎麼進行呢？先有程式碼好壞的概念後，找到程式碼中不好的地方，用查表的方式替換成新的形式，代換完後測試一下程式，觀察結果是否與更改前一致，若一致就可以再尋找其他地方進行重構或添加新功能。 在 重構─改善既有程式的設計 這本書提到一些程式碼的壞氣味： Duplicated code 重複的程式碼 Long method 過長函式 Large class 過大類別 Long parameter list 過長參數列 Divergent change 發散式變化 Shotgun surgery 散彈式修改 Feature envy 依戀情結 Data clump 資料泥團 Primitive Obsession 基本型別偏執 Switch Statements 可怕的 Switch Parallel inheritance hierarchies 平行繼承體系 Lazy class 冗員類別 Speculative generality 夸夸其談未來性 Temporary field 迷惑的佔時欄位 Message chains 過度耦合訊息鏈 Middle man 中間轉手人 Inappropriate intimacy 狎暱關係 Alternative class with different interfaces 異曲同工的類別 Incomplete library class 不完善的程式庫類別 Refused bequest 被拒絕的遺贈 Comments 過多的註釋 在大話重構這本書中提供了一些較簡單的方向：...

在介紹 Clean Code 之前，想想為什麼會寫出糟糕的程式碼呢？可能是趕進度，也有可能只想早點下班，甚至是連好壞程式沒概念。也有人說程式會動就好了，花這麼多時間讓程式碼變整潔，不是很沒效率？ 程式會動就好這件事聽起來很美好，但是需求一直在改變，今天寫好了一個程式後，使用者用了一段時間一定會想要加點新的東西進去，這時如果是糟糕的程式碼，得花非常多時間搞懂之前做了什麼，才能下手改程式碼。 有人統計過閱讀程式碼與寫新的功能所佔的時間約為 10 : 1，由此可見，原有的程式碼越難懂，就得花越多時間在理解程式的原意，開發的時間也就拖得越長。另一件頭痛的事是，如果程式碼糾結在一起，很難保證改了一段程式不會影響到其他區域，到時候改了一個錯誤，出現更多的錯誤，就會沒完沒了。 我們了解到寫出雜亂的程式碼，會導致程式越來越難維護，隨著時間的推移，程式碼產出會慢慢趨近於零，到時候不得不放棄這團糾結不清的系統。但事情往往沒這麼簡單，舊系統經過了時間的考驗，修了無數的錯誤，在重起爐灶時不太可能將所有條件考慮進去，導致新系統不堪使用。 要怎麼避免這種兩難事情發生呢？有兩個方法： 一開始就寫出整潔的程式碼，但新手往往不夠熟練能第一次就寫出乾淨的程式碼，可以先了解好程式碼的方向，慢慢培養寫程式的品味。 重構程式碼，利用代換等量的程式碼讓程式解耦，並利用測試驗證重構的正確性。這主題可以獨立成一篇：淺談重構。 這裡列出 Clean Code 書中幾個簡單的原則，剩下較難或繁瑣的觀念，例如物件、類別、錯誤處理、系統架構 … 等，可以等程式功力更熟練時再回去詳讀： 命名 要讓名稱確實表達意圖，絕對不要用 aaa, a1, a2 這種完全不知道意圖的名稱，至少讓人一眼看出變數代表的意義，例如：traceStartTime 或是 traceCount。 名稱避免誤導，像 O 跟 0，I 跟 l 跟 1，或是 dirToTheDataBase 跟 dirToTheDataManager 這種太相似的變數。 不同的變數，意圖應該要有明顯的區別，像是 fileDir 與 dataPath 實際上是指同一件事情，不應該有兩個變數做重複的事，若有這種情況必須重新思考程式架構。 名稱要可以唸得出來，在互相討論程式碼時才比較有效率，不要有 genyyyymmddhrmnss 這種無法發音的名稱，generationTimeStamp 會更好。 盡量使用大家都熟悉的名稱，課本公式上常用的代稱就可以使用，像寫極座標時，用 r, theta, phi 就是可以接受的命名。 函式 函式盡量越短越好， 超過螢幕可以一眼看完的函式，在閱讀上一定會有困難，所以函式大概控制在 20 行以內。 函式只做一件事情，如果裡面非常複雜，通常可以拆成更多的小函式。 函式內只有一層抽象概念，太細節的功能就包給更小的函式，需要統合的功能就交給更大的函式。 函式通常是做一個動作，所以用動詞開頭命名會比較適當，像 getTimeTable 或是 isDataContinuous。 函式輸入的參數越少越好，最好是零個，一個次之，兩個就不太好了，盡量避免三個以上，超過要用類別將變數包起來。但是非常直觀的變數數量，例如 plot3D(x, y, z) 直覺上告訴我們需要輸入三個變數，就可以接受。 註解...