[隨筆] 日本短期研究一個月的簡單紀錄

說到博士研究生涯，完全沒出過國的機率很低，國內的大學也有機率會提供碩博士有短期出國研究(不是交換學生)的補助讓你可以出國深造。雖然這個補助說實在的比起國外的生活費還有大學註冊費之類的實在不夠看，其實教育部也有所謂的千里馬計畫是補助你長期出國研究 (我印象中是至少要 10 個月) 的經費，而且這經費其實不低，一個月有 5 萬台幣供你使用，說實在的就算是不夠用還需要自行貼補，但這也很大程度的降低負擔，其實是真的滿不錯的 (雖然我個人對於那個申請流程感到十分繁瑣與厭倦...)。我當初會想念博班也有一小部分 (真的是滿小的一部分...) 是因為可以有常常出國的機會，就到目前來說，確實有達到我當初的期望。

話是這麼說拉，出國幾次之後對於出國的感想除了可以看到一些在臺灣見不到的東西之外，對於一個生性就怕麻煩的人來說，出國還真的是麻煩到有剩的一件事，特別是窮學生想出國必定得想辦法生出補助之類的，看到那些補助辦法的規定什麼的，真的會想把各種知道的髒話通通罵出來...well，所以其實現在對於出國沒啥感想，大多剩下把事情盡快地辦完之後回國懶散的休息當阿宅 XDD

這次會出國短期研究一個月起因來自於老闆到日本學者參訪 2 個月後，在那邊接洽的實驗室談好了一個計畫。在講這個計畫前，先來簡單講一下日本那邊的教授制度：日本那邊的制度跟臺灣差異其實很大，首先教授的名額是有限制的，要升上教授前必須要先有教授退休；其次，副教授還有助理教授這些都會掛在一個正教授底下，而這些由同一個教授率領的團隊會共享所有資源。印象中，在日本那邊的教授主要負責的會比較像是接洽計畫、找實驗室的經費與研究方向之類的，底下的副教授跟助理教授大概就會是負責管理實驗室的運作。像我這次去日本，管理實驗室機器的就是一個副 (?) 教授。所以他們那邊一個實驗室其實都會挺大的，運作方式也會跟台灣這邊的實驗室差異相當大，研究主題也因此會相對廣泛。

在上一段提到的那個計畫，當初老闆跟那邊的實驗室接洽完之後，回國後老闆正式的找了一個碩班的學弟跟他們開始合作，合作的方式是他們那邊會提供他們在設計上遇到的困擾以及想要解決的方案；而我們這邊則是根據他們的問題將解決方案自動化。說穿了，其實可以把他們那邊當成 designer，而我們這邊就是設計 CAD tool，我們要做的就是把他們本來必須反覆人工處理的事情通通自動化，如此而已。聽起來好像很簡單，就是一般 EDA 在搞的事情，不過我一直覺得這個領域最麻煩的地方就在於你很難避免去觸碰到業界的商業機密所衍伸的各種保密措施。像我們這次做的計畫，如果不拿業界實際的製程資料來做，那麼整個研究計畫會變成問題過度簡化，得到的結論也會因此不切實際無法實際運用；相對的，因為用到了業界實際的製程資料，這就導致要合作、重製與驗證實驗上窒礙難行。沒錯，這就是當初我們要合作時遇到的最大困擾：我們無法存取他們的製程資料，所以有些他們設計上遇到的困擾我們這邊無從了解並處理；如果只套用我們這邊能存取的製程資料來設計，兩邊溝通上常常會出現雞同鴨講或設計處理上無法套用的問題。畢竟，不同公司的製程資料如果一樣，我看那些公司彼此之間就先開始搞保密防諜跟上法院了，我們要拿來做研究也必定通通暫停 (攤) 尼們看看當初梁孟松跑到三星後弄出了多大的風波就知道 XD。

結果，當初搞了幾個月之後，整個計畫宣布終止，因為完全弄不下去 XD，老闆也因此在前陣子寫了個計畫準備去日本來個一個月的超短期研究，目的就是要把當初這個不得不中止的計畫弄出點成果並畫下句點。然後因為這計畫的研究方向跟我目前的研究有關，所以我就被抓來了 XD 如果要問我說這次短期研究有甚麼最重要的心得...大概就是這個吧：

千千萬萬不要欠技術債，不然他哪天陰魂不散的找上你時你會死得很難看 (咚—)

以上，切身之痛...所以當你欠下技術債時，趕快丟給下一個倒楣鬼就好 (欸)

不過這次來日本剛好遇上櫻花季 (雖然比往年慢了不少) 以下有圖有真相

這張是在我宿舍前面的櫻花樹，剛好在我住的最後一周開始開花

這張是在大阪城公園拍的，櫻花樹下的步道還真的滿有 fu 的

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

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

不過這反倒讓我在思考一件事：究竟是我平常不太說話會讓人感覺有壓力；還是單純突然間反差太大讓他覺得不尋常阿？因為其實我平常就是那副死樣子 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，其他類型的應該會有截然不同的綱要