[隨筆] 被迫回顧過去的程式...這是一個羞恥 play 的感覺 Orz

當初做這題目時我剛升碩一，雖然大學時代有去比過程式競賽那些的，但說實在的，這些競賽對於建構大型軟體其實是一點幫助也沒有 XD 就算有軟體工程這些課可以修，不過說實在的，修課是一回事，實際要用時就會發現只要沒有實際操作過，就算有修過課也是個屁

簡介 std::function (C++11 後的新功能)

std::function 是個 C++11 引入的新東西，作用有點類似 C 的 function pointer，不過為了考量 C++11 引入的新功能，效果上更加的一般化，使用範圍可以比 function pointer 更廣泛。

[筆記] steam controller (steam 控制器) 在 windows 7 上安裝驅動程式失敗

最近因為想用手把玩黑暗靈魂，也剛好發現台灣有人代理了 steam 控制器，評價貌似不差，而且習慣後好像甚至可以取代滑鼠操作，於是就趁著特價入手了，然後就發生了 win 7 自動安裝驅動失敗的問題 = =

[C++] 不定數量的樣本參數 (variadic template)

在很早已前的 C 就有提供不定數量參數 (variadic argument) 的功能了，比方說像 printf/scanf 系列的 function，他們能接受數量不固定的參數。而 C++11 把這個功能也放到 template 來用了，所以現在也有 variadic template 的功能，有些資料的關鍵字是 parameter pack，不過其實內容是一樣的。

[C++] 關閉特定程式碼區塊的 unused parameter 警告

部分的 C++ compiler 可以在 function 有參數沒有被使用到時給出警告，像是 g++ 可以透過 -Wunused-parameter 開起這項功能 (印象中有包含在 -Wall 裡)，雖然這類的警告可以在編譯階段就發現一些潛在問題，不過偶而還是會造成一點困擾：對，就是使用既有的 library 時。這時候如果可以只把一些確定沒有問題的警告關掉，對於像我這樣有強迫症的人來說心情會好很多。

[筆記] 英文學術論文的寫作注意事項

最近被老闆要求將要投稿的論文送去給專門編修英文學術論文的機構把英文的用詞、句型等改得更加符合學術論文的要求，所以這邊就統整一些收到的回應當作紀錄了。因為我投稿的論文寫作風格一定會是 IEEE 或 ACM，所以下面所寫的部分只適用這兩種寫作風格要求，不能套用到其他寫作規範上。

1. 前飾詞 (prefix，像是 pre 或是 non 這種用來修飾用的) 跟後面被修飾的形容詞/副詞通常不需要連字號 (hyphen, -)，比方說 pre-assigned 可以直接寫成 preassign。例外：用大寫來寫的字 (比方說 proper noun)，縮寫或是數值

2. 當想要用連字號連接 2 個詞行程複合詞時，結果其中一個已經有連字號的時候，把連字號改成 en dash (好像也是叫連接號，差異點在於 hyphen 比較短，en dash 比較長)。比方說要把 user-friendly 跟 aware 連接的時候可以寫成 user-friendly–aware，這樣就會知道這個詞是由 user-friendly 跟 aware 組成的。可以注意 hyphen (-) 跟 en dash (–) 的差異

3. 避免在句子的開頭使用 besides，容易有歧意 (學術寫作要求語意清楚單一不混淆)，建議改用 in addition

4. 在句子一開頭使用語氣承接、轉折用的副詞後面要用分號，像是 thus, hence, therefore, 這一類的副詞。比方說 Thus, ... Hence, ... Therefore, ... 

5. 如果要用來描述依據經驗去做某件事可以用 empirically

6. due to 只用在放在 be 動詞後面或是用來形容放在他前面的名詞 / 代名詞，除此之外都用 because of 

7. 避免使用 issue，因為 issue 的語意比較模糊，依據情境改用 category, challenge, concern, difficulty, hindrance, obstacle, problem 或者是 situation 這類語意比較明確的字詞

8. IEEE 的風格可以直接要引述 reference 時 citation 可以直接用編號 (像是 [1])，而且可以直接當成句子的主詞；反之，ACM 的風格就必須要把作者名字跟年份直接寫出來

9. IEEE 的風格在不論在寫圖片的說明文字還是引述圖片編號時都是直接用縮寫 fig. 而不是寫成 figure，ACM 風格則是引述時要寫成 figure，圖片的說明文字才能用縮寫 fig.

10. 如果要在句子中把所有情況一一列舉時，不能用 including 或是 such as，可以用 i.e. 或是 namely

11. 延伸第 10 點，使用 e.q. 或是 i.e. 時要用刮號 () 包住，像是 (e.q. blablabla)

12. 如果 () 中還有 ()，外層的 () 要改用 [] 變成 [()]

13.不要用 one 當句子前面講的某個物體的代名詞，比方說

A routable cell may turn into an unrouta one.

這邊的 one 建議直接改成 cell 避免混淆

14. 在列舉時 A, B, C, ..., X, and, Y，在列舉時 and 連接倒數第二個 (X) 跟最後一個 (Y)，倒數第二個 (X) 後面也必須要有逗號。這個叫作 "serial" 或是 "Oxford" comma

15. First, second, third 這種一一列舉用的副詞不需要後綴詞 (ly) 寫成 firstly, secondly, thirdly

16. 避免使用比較模糊不清的 based on，除非是接在 be 動詞後面，可以改用 on the basis of

17. 標題 (title, headings, captions) 開頭的定冠詞 (definite article) 通常可以省略

18. 避免使用 since 來講事情的 "原因"。since 是用在描述事情的先後順序 (也就是時間關係)，直接使用 because, although, whereas

19. 運算元 (像是 AND, OR) 這類在描述時字體是小型大寫字，而不是直接用大寫

20. IEEE 的風格在表格 (table) 編號是用羅馬字

21. 避免使用 "the former ... the latter ..."  這個句型，直接把所指涉的物體寫出來比較清楚

22. 建議不要使用 on the other hand 這個比較口語的用法

這篇先寫注意事項，之後再來整理常用句型，這感覺就累了 Orz

[C] Interpret Declared Type

有些徵軟韌工程師的公司在面試 / 筆試時好像很喜歡出一些很長又很難解讀的型態宣告，然後請你用 typedef 改寫
比方說：

void ** (*d) (int &,    char **(*)(char *, char **)); 

[EDA] Standard Cell Layout Design Guideline

筆記一下在畫 standard cell layout 時要注意的幾點事項，不過因為我做的主要是 digital high performance standard cell，其他類型的應該會有截然不同的綱要

[python] 限制 subprocess 的 CPU & memory 使用量

暑假到了，又一批要進入研究所的新生要來報到，由於實驗室的傳統是所有新生都要接受 programming training project，而我們實驗室的 training 是老闆會幾篇經典的論文要新生實做出來，雖然標準年年都會調整，不過今年老闆明確的說他要檢查新生寫的程式，然後通過的標準除了要檢驗結果的正確性，也要檢查執行時間 & 記憶體使用量。而這次的 training project 老闆指定其中一題要把我現在做的東西切割一小塊出來讓他們實做看看，所以這次我必須要寫一個 verifier 去做自動化的驗證

[隨筆] 學術與實務間的巨大差異

做了幾年研究，從碩班做的單一面項的研究，到現在博班做一個領域的研究，雖然還不敢說已經能不負眾望的承接 "博士" 這個稱呼，但確實有比較了解所謂做研究這檔事。即便是對於有經歷過完整碩士研究的人，我想我還是有更深一層的體認的。不過我想這也是正常的，畢竟對於只有兩年，其中有大約一年的心力幾乎都要投入修課所以只剩一年的時間，的碩士研究生來說，一年內要能完整做出一個學術研究，要嘛題目很單純，要嘛老闆很仁慈，不然就是運氣不錯很快的就找出突破點，如果不是運氣那通常只有在該領域已經浸淫多年有些心得的人才有可能辦得到，否則老實說一年內要能做出有突破性的學術研究說實在有點短。所以近幾年 (以前我就不知道了) 碩士研究我覺得教授們大部分都是把重心放在訓練學生如何做一個學術研究，至於成果應該只要別太糟都沒事的，畢竟只是來混碩士學歷的學生很多。

通常在碩士訓練中，老闆都會給一個研究方向讓學生找出自己想做的題目，有的甚至會直接指定題目 (恩，我知道有的教授會裝死，畢竟我認識的教授中就有這種 XD)。如果最後題目是自己決定的，而且老闆也有用心指導的話，姑且不論題目本身是否具有實務上的價值，那或多或少也會經歷過一段找出具有學術研究價值的研究題目。不過當過研究生的人一定知道，就算沒當過研究生的可能也有聽過：很多研究其實一文不值 (如果是碩士論文那機率更高 XD)。舉凡像是論文中提出來的論點是假議題到實務上根本不可行 ... 等等，一篇論文就算能被刊在優質期刊/會議上，最後經不起檢驗的也所在多有，特別是審稿者不見得熟悉投稿者所做的方向 (想必有很多研究生都曾經幫教授審過論文吧 XD)。當然，如果做得是純理論的研究就沒道理拿實務上的困境來檢驗，不過因為我自己的研究領域是 EDA，不考慮現實的可行性實在說不過去，所以偶而會對於為了發論文而做的研究感到不能諒解。當然，有些是為了畢業或是為了升等之類的現實困境而不得不為之，但也會為此感到悲哀。

比起其他研究生，我比較幸運的地方碩班與博班期間都接了業界計劃，而且都是具有學術價值且是有實務上困境的題目。不過也正因此會發現有相當大量的學術論文一旦搬到實務上來其實都很不堪一擊。原因其實也不難猜，學術論文對於實驗結果要求的是證明提出來的方法是確實有效的，所以只要能做到這點就是個成功的實驗。而讓學術論文不堪一擊的實務上困境有很大因素來自於學術研究上不會想去處理的細節，也可以說是就算做了也不會提升論文價值的麻煩困擾。這類因素輕則降低實驗宣稱的成效 (但不減低學術價值，因為可能只是一些不常出現的特例，也沒有討論的必要性)，重則我認為是能從根本上否定一篇論文的。當然有時是來自於資源的問題，畢竟有些實務上的困境，特別是做 EDA 這行的，沒有業界實際的經驗與資源輔助，只靠學界自身的資源要做出能同時兼具學術價值與實務價值的研究是真的有難度的。比方說先進製程相關的研究有一大堆內容是業界機密，如果不知道那些機密還真不會知道自己做的研究到底有沒有用 (不過這幾年發現有接露出來的還只是冰山的一角，還有一大堆不能說的秘密 XD)。這也是很多人問我未來是否要當教授時我一律回應我要先去業界打滾幾年再說，畢竟老是待在象牙塔裡對於從事這領域來說實在不是件好事。

不過這幾年最有感的地方應該還是投論文吧，特別是當你發現自己辛苦了老半天也用了業界的資料做了套應該還滿完整的實驗，卻比不上一篇很會說但沒啥參考價值的論文時，那沮喪感確實是滿大的。但最近靜下心來想根本原因何在時，我想除了我自認能用 "過往的相似研究均無法解決一個實務上的困境" 來說服審稿者外，我發現會議論文的審稿者其實更喜歡看到一些新穎的題材，我想有部分原因應該跟會議中可以跟發表者互相討論這類新穎的題材，順便從中找出一些做研究的靈感有關，不過這點確實提醒了我行銷故事的重要性。

 下一個研究題目已經開始了，但是望著寥寥無幾能用的參考論文，說實在的還是會覺得相當無力阿。有些論文即便方法沒有參考價值，提出來的問題與論點確實有其參考價值，但也有為數不少根據已知的問題提出的新方法看似比舊方法好，但實際要套用就發現一大堆問題 (攤)