[隨筆] 原來不說話會讓旁人有股莫名的壓力

前幾天跟朋友出遊時，因為不小心聊得太開心，結果好像刺激到朋友很在意的事情。被警告了之後想說該好好平靜一下，於是之後的幾天也都一直保持著很安靜的狀態，沒想到反倒讓朋友誤以為我是不是為了什麼事情在生氣了 (汗)

不過這反倒讓我在思考一件事：究竟是我平常不太說話會讓人感覺有壓力；還是單純突然間反差太大讓他覺得不尋常阿？因為其實我平常就是那副死樣子 XD 特別是不想說話時會想辦法禮貌性的句點別人 (所以這時候如果有人不識相一直找我講話我真的不會給他好臉色)

然後我真的不太會找話題...Orz

[隨筆] 被迫回顧過去的程式...這是一個羞恥 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 去做自動化的驗證