關於 python錯誤訊息 ，我們在網路上蒐集到這些相關的討論、資訊與評價

使用了 glom，python 程式碼看起來可讀性變高並且變簡潔了！而且錯誤訊息也比較容易 Debug

https://softnshare.com/glom/

#學習寫程式 #誰可以成為軟體工程師 #小吃貨轉職日記 #個人心歷路程

不知道是否還有人記得，很久以前我問了大家一個問題是，覺得什麼樣的人可以成為軟體工程師。

其實一直以來，我覺得只要會英文的人就可以學會寫程式，就可以成為軟體工程師。

為什麼會這麼覺得呢？

首先，就像是，你覺得誰學會使用電腦是一樣的道理。如果你在三十年前問大家這個問題，可能很多人會覺得，只有念相關科系的人可以學得會。

在我們還在DOS的時代，還在打指令的時代，那時只要會打字，就可以成為文書處理專業。沒錯，那個年代，文書處理是一個科系。

但現在，有誰會去大學念一個科系，只有學打字使用Microsoft Office系列。

當然，軟體工程師也並不是一個容易的職業，就像我之前提過的，這個職業也有很多利與弊，不是像外面形容的那樣，好像坐在電腦前面打打字就可以做的，或者像其他工作那樣，可能學了一技之長可以用很久，這個行業的一技之長，可能很快就過保鮮期了。

回到學習寫程式這件事情，在台灣聽很多人都說，「啊！寫程式就是要有天份啦！」「聰明的人啊！」也看過很多網路上的人在吵，資工vs 資管 vs 非本科系什麼之類的。

最近有朋友問我說，為什麼在台灣的時候學不會，可是來英國以後我就學會了，是因為來英國以後特別努力嗎？

其實你到現在問我學會了嗎？我也不會跟你說我什麼都會。但的確光是coding這點，我覺得在台灣學習跟來英國學習最大的差異還是在，學習的動力上面。

在台灣的時候，其實有點為了學而學，從來沒有思考過自己是否真的有興趣，有時候以為自己其實也滿有興趣的，因為那些東西以前沒有碰過，可是只要碰到一點瓶頸 ，就會開始退縮，覺得好煩喔！這些東西怎麼這麼難，只要上課聽不懂老師在說什麼，就會很不想繼續學。

在台灣除了去資工系修課以外，也有去台大資訊系統訓練班上過課，也有上過一些線上的課程。

幾乎都是同樣的感覺，甚至覺得，自己是不是年紀大了，感覺什麼都學不會，聽不懂，自己好像很笨。

來了英國以後，上課的第一天，老師說，我會用英語授課，而且不會為你們放慢速度，因為你們必須要去習慣。當時覺得自己更不可能聽懂，也不可能學會。

可是我們上課的狀況通常是，一天上課兩個小時，上完以後有兩個小時的實驗課，大家坐在電腦前，老師一個一個看你做的東西，從很小的東西開始學。

我覺得這個應該算是滿關鍵的，就是有沒有動手實作。然後不會的話老師也很耐心的教，此外老師還有另外的課後時間，只要我們有問題都可以去找他。

在實驗課的時候，中間只要卡住，老師也會盡量讓我們自己去思考，而不會直接告訴我們答案，例如會問我們，為什麼你想這麼做，這麼做的原因是什麼。

我記得很久以前在台灣的大學，問了老師一個問題，老師的答案是，你以後就會知道了。當下其實就讓人覺得有點反感，而且後續問老師很多問題，老師也是都這樣，這個以後就會學到了。

我自己算是一個滿會因為老師而喜歡一個科目或不喜歡一個科目的人。就像我小時候很討厭數學課，也是因為不喜歡數學老師。也不是真的不喜歡，就是有一種覺得，反正老師也不在乎我學不學的會，只在意那些學得好的人。

在台灣也聽過很多人說，啊要學會寫程式，數學就要先打好基礎，數學不好怎麼寫程式。可是真的成為工程師以後，在工作上根本沒用到什麼基礎數學啊！

其實在英國也遇過很多數學系畢業的，可是害怕寫程式的人也很多，他們這邊通常學校會有一兩堂課是寫程式，可能學個Python, 像我之前念書的學校，學不好的很多，一些很厲害的大學的數學系，也有人就乾脆放棄那門課，不學，因為覺得很複雜，他們寧願把時間拿去研究純數。

不過現在的電腦，都會幫你做好各種基本數學運算了，大部分現在的程式語言，你要跑什麼線性回歸什麼的都幫你做好了，也想不到什麼時候會用到三角函數之類的，除非你的工作是什麼data scientist 之類，可能要建立複雜的數學模型，或者quant 那類的，不然就算你要做Machine Learning這類的東西，也有很多已經現有的工具，軟體工程師大部分就是拿來跑一跑。

要是你真的是做機器學習相關的研究，人家也不要你軟體工程師，人家要的是資料科學家背景，人家至少要你有個PhD唸完再來，你要至少會讀paper, 寫paper做研究啊!!

如果是醫學相關的軟體，需要有專業技能，人家也要找醫學背景的來，如果是金融相關的，需要有非常多的金融專業技能，當然也是從金融背景的比較容易。

通常軟體工程師，普通的軟體工程師職缺，就是不太會需要太多納些相關的專業領域，他們也願意你進去了再學，你主要需要的是快速學習、適應環境的能力，還有溝通能力，這樣如果跟其他專業領域的科學家、研究員、分析師溝通之類的，至少你可以不會有太多的障礙。

當然，軟體工程師的工作也可以細分成很多領域，像是遊戲產業的軟體工程師，或者IoT產業的軟體工程師，甚至還有像是軟體架構師、軟體分析師、資料工程師之類的，他們可能需要使用到的技能也不一樣，但也不會沒事就需要叫你算個三角函數之類的.........通常你的背景還是在於你對於寫程式的熟悉程度，你會使用那些工具，你是否是個團隊合作的人，能否跟大家一起寫程式。

總之，回到前面說的，所以到底學習寫程式需要什麼，英文真的是很重要的一環，因為程式語言本來就是英文為主，在來就是網路上的資源，也幾乎都是英文為主。還有你寫程式的環境，也幾乎都是英文，像是你使用的工具，回報給你的錯誤訊息也常常可能是英文的。

來英國以後一直在思考的一點，在台灣討論到會不會寫程式，或者學不學的會，通常英文好的話，也可能在閱讀文件方面比較快，可以快速學到一些東西。

語言也不是全部，如果已經在工作的話，工作環境也很重要，學習環境也很重要，在學校如果遇到一個很好的老師，或者有一起學習的夥伴們，也會比自己一個人獨自專研來的快，不過每個人的學習方法不同，更重要的是找到自己喜歡的學習方法。

反正如果你想學的話，也不用管其他人講什麼，想學就學啊！當初我要學的時候，也很多人覺得我不可能學的會或者不可能成為軟體工程師之類的。

其實也不是因為我原本念歷史系的原因，主要就是，大家覺得，我是一個沒有邏輯，邏輯不好的人。還有覺得我是一個三分鐘熱度的人，以及數學指考考了不到30分。這些我也都寫在部落格裡面了，所以一直以來都有在看我文章的人，大概也都知道了。

當時，我大概聚集了所有身邊當工程師的朋友，都覺得不可能會成為工程師的因素吧！但現在我還是做為一個軟體工程師賺錢就是了。

有時候想做什麼就去做，反而是一件比較容易的事情。尤其是學習這種事情，網路上也有很多資源可以學習也不一定需要花錢。

在學校的時候，除了老師給予我一些自信以外，另外也是在英國認識了一些人，給予了一些鼓勵，有些素未謀面的人，也有些一面之緣的人，可能也是因為他們不認識原本的我，所以都覺得，沒有什麼是我不能找到工作或成為軟體工程師的原因。

現在想想，或許這就是初生之犢不畏虎的概念，當初沒有想太多就跑來英國，然後來了以後才開始覺得必須要努力一點才能找到工作，中間也遇到了很多困境，工作以後也曾經想過要放棄當軟體工程師，想要去當個什麼辦公室助理之類的。

也經歷了很多覺得很困惑的時期，雖然自己現在還是滿困惑的。但我覺得如果你真的想要學習或者轉職，只要做好功課(這點真的滿重要的，至少不要覺得只是看別人好像不錯，就決定要去做，至少要衡量一下利與弊)，就可以去做吧！也不用管別人說你適不適合走這條路怎樣的。

每個人適合走的路也不太一樣，還沒走之前都看不到，就算你看身邊的人都怎樣，自己還是自己。

最近 Funliday-旅遊規劃 常發一些精選旅遊回憶的 App 通知給使用者，在去年十一二月的時候發通知 Server 還能撐的了瞬時大流量的 request。

但今年開始發這類通知，總共發了三次，三次都造成 Server 被打掛，而且重開 AP 還緩解不了，瞬間手足無措。大概都要等過了十分鐘左右，Server 才將這些 request 消化完。

這裡就來簡單整理一下時間軸，順便分享一下 Funliday 是如何解決這個問題。

---

* 1/6 1900：系統排程發送精選旅遊回憶的 App 通知
* 1/6 1900+10s 開始：Server 收到極大量的 request
* 1/6 1900+20s：Nginx 出現錯誤訊息 1024 worker not enough，並回傳 http status code 503
* 1/6 1900+25s：PostgreSQL 出現錯誤訊息 could not fork new process for connection (cannot allocate memory)
* 1/6 1900+38s：Node.js 收到 PostgreSQL 的 exception。There was an error establishing an SSL connection error
* 1/6 1900+69s：PostgreSQL 出現錯誤訊息 database system is shut down
* 1/6 1900+546s：PostgreSQL 出現錯誤訊息 the database system is starting up

---

看了時間軸就覺得奇怪，先不論 10s 的時候發了極大量 request，造成 20s 在 Nginx 出現 worker not enough 的錯誤訊息。而是要關注 25s 時的 PostgreSQL 出現 could not fork new process for connection 的錯誤訊息。

Funliday 用了同時可承載 n 個 connection 的資料庫，而且程式碼又有加上 connection pool，理論上根本不該出現這個錯誤訊息。但整個時間軸看下來感覺就是 PostgreSQL 的 capacity 問題，造成系統無法運作。

因為就算將 Nginx 的 worker connection size 再加大 10 倍，只是造成 PostgreSQL 要接受的 request 也跟著被加大 10 倍，但 PostgreSQL 那裡因為 request 變多，原本在 69s 直接關機的時間點只會提早，而無法真正緩解這個狀況。

基於以上狀況，小編就開始回去看自己的程式碼是不是哪裡寫錯了。會這樣想也是覺得 PostgreSQL 應該沒這麼弱，一下就被打掛，一定是自己程式碼的問題 Orz

---

這邊來分享一下自己程式碼的寫法，圖一是原始寫法，在每個 API 都 create 一個 db client instance 來處理該 API 層的所有 db request。這是蠻單純的做法，也是 day 1 開始的處理方式。但有個小問題，就是每個 API 層都要自己 create instance，不好管理，且浪費資源。

後來因為想要做 graceful shutdown 的關係，所以調整了一下 db client instance 的建立方式，用 inject 將 instance 綁在 request 上面，如圖二。這樣只要在 middleware 建立 db client instance 就好，好管理，而且只要有 req 就可以取得 instance，非常方便。而這也是 1/6 時的程式碼，就從這裡開始研究吧。

---

直接切入 node-postgres 的文件，認真讀了一下 pool 有下面兩種使用方式：

1. pool.connect, pool.release：文件寫著 checkout, use, and return，光看描述就應該用這個沒錯。
2. pool.query：適用於不需要 pool 的連線方式，文件上也清楚寫著內部實作是直接 call client.query，所以用了這個方式是完全跟 pool 扯不上邊。

但偏偏小編從 day 1 用的就是第 2 種方式 Orz，雖然看起來應該是寫錯，但也是要修改後實測，才知道是不是真的可以解決問題。

---

如圖三，這是修改後的程式碼。想了一下子，覺得目前在 API 層使用 req.pool.query 還不錯，不想用官方的建議做法：先 create client，然後 query 之後，再使用 release。

如果照官方建議做法，API 層的程式碼會多一堆與商業邏輯無關的程式碼，也不好維護。所以在不想動到 API 層的程式碼，只能使用 monkey patch 的方式來達到這個需求。

monkey patch 可以將原方法利用類似 override 的方式，將整個方法改掉，而不改變 caller 的程式碼，這也是 JavaScript, Ruby, Python 這類動態語言的特性之一，但真的要慎用，一不小心就會把原方法改成完全不同意義的方法了。

所以原本應該要在 API 層實作 connect, query, release 一大堆程式碼，可以用 monkey patch 完美解決這一大堆程式碼。

---

在 dev 壓測後至少 capacity 可以達到原本的 4 倍以上，隔天實際上 production 之後也確實如壓測般的數據，可以承載目前的流量。

其實這篇分享的重點只有一點，文件看仔細才是最重要的事啦！如果沒把文件看仔細，然後開發經驗也不足的話，什麼 RCA、monkey patch 都幫不上忙啦！

---

後記：有夠丟臉，其實完全用不到圖三，只要把圖二的 pool creation 放到最外層就好了，因為 pool.query 的內部實作已經有做 connect, query, release 了。

感謝下面的 Mark T. W. Lin 及 Rui An Huang 的幫忙，實在是太搞笑了 Orz

* Pool 的文件：https://node-postgres.com/features/pooling
* 官方建議寫法：https://node-postgres.com/guides/project-structure
* pool.query 的內部實作：https://github.com/brianc/node-postgres/blob/master/packages/pg-pool/index.js#L332

#expressjs #nodejs #javascript #postgresql

今天做一個網頁讓使用者可以輸入email然後程式要檢查email是否符合格式, 不符合的話要從後台發出錯誤訊息,另外要檢查資料庫是否已經有同個信箱 成功的話會進入下一個成功的網頁
_____________________________________
喜歡這個頻道的節目嗎?
考慮訂閱吧! 每個訂閱對我都是非常大的鼓勵

另外, 有鑑於一些人提到他們比較喜歡在Twitch上看實況所以Twitch也會有同步直播歡迎參考:
https://www.twitch.tv/pedro0930