使用vimdiff來解決git merge conflict

使用vimdiff來解決git merge conflict 最近同時家裡用筆電跟辦公室用桌電，在兩個地方使用git/github來管理程式作業，這兩個東西加起來根本神物，本來要用隨身碟同步的東西，現在可以用git直接完成。

關於git的基本介紹我就不解釋了，網路上隨便一找就有一堆資源，例如右邊友站連結，作者比我強30dB的JJL blog，裡面有git的基本使用方式；作者當初則是看參考資料一的progit來學git。

作者遇到的問題是：有時候檔案在github上的檔案已經更新，本地的檔案也有修改過，這時候若想要git pull的話會產生conflict，這時候就需要把本地的檔案刪掉重新clone使用merge來解決衝突，偏偏作者手殘常常把檔案merge成連<<<, >>>都保留下來的檔案，相當麻煩；這次好好的研究一下怎麼用vimdiff作為merge的工具，在這裡記錄一下。

首先呢，我們可以先設定vimdiff為git default的mergetool

git config --global merge.tool vimdiff

為什麼？沒辦法，用vim就是潮(誤)

那麼來merge吧，輸入

git mergetool

這時候應該會打開vimdiff，然後產生左上角、中上、右上、下四個視窗，說明如下：

左上：local：顯示本機的檔案內容，現在這個git資料夾的版本

右上：remote：顯示遠端，你要merge的分枝

中上：base：顯示上面兩個分枝的基部的內容

下：merged：顯示merge的內容，也是是包含了那堆<<<<<<, >>>>>> 的版本，我們的目標就是把下面這個修到我們希望的版本。

截圖：

到了這裡就開始解衝突啦，事實上不單是git，平時如果有兩個很像的檔案要合併，也可以用vimdiff開啟來解，使用的指令是這些：

[c：跳到上一個衝突點

]c：跳到下一個衝突點

:diffget，從某個視窗取得內容

:diffput，把內容丟去某個視窗

可以用:help do, :help dp查怎麼用，不過兩個指令的基本格式是：

:[range]dp|do bufspec

如果是雙方比較，那就沒什麼好說的，do/dp的對象就是另一個視窗的內容，這時候只要在衝突點在一般模式下用dp,do即可。但如果是現在這種3方比較時，就沒辦法這麼方便，而是要直接輸入:diffget/put bufspec來操作(可以打diffg, diffpu來少打幾個字，不過有差嗎=w=)

以上圖為例，我們游標停在下面的衝突點上，要使用remote的視窗內容。

這裡bufspec(用哪個視窗的內容)有兩種指定方式：

1. 先用:buffes，確認remote那個視窗編號，我是4號，因此用 :diffget 4

2. 用關鍵字，這個超強，用 :diffget REMOTE (因為git自動命名暫時檔名為 XXXX.REMOTE.yyy, XXXX.BASE.yyy, XXXX.LOCAL.yyy)即可。

如此就會套用remote的內容了，經過幾次套用之後，畫面可能會變得有點亂，這時候可以用 :diffupdate來重新產生diff的格式。

用上面的步驟，就可以快速的完成解衝突的工作，做完之後，在下面的合併檔存個檔離開吧。

參考資料：

1. progit download:

http://git-scm.com/book

2. vim wiki about git vimdiff:

http://vim.wikia.com/wiki/A_better_Vimdiff_Git_mergetool

3. vim help:

Type in vim :help diff

面對核四，我的意見

反對核四大遊行登場，將反對核四的行動帶上另一波高峰，隨著愈來愈多的名人、學者加入連署，反對聲浪也愈來愈高。網路上已經有很多關於核電的文章，在此就不需要再重覆了，只想在這裡表達一下我的意見。

最近看到一些文章，認為這個政府必須提供配套方案，而不是將責任丟到反核民眾身上；我完全同意，但另一方面，我並不認為「人民沒有義務去理解事情背後的充分知識，解決方案在政府，但政府應該幫忙人民，人民也應該自己去了解，解決方案所帶來的後果。」
比如說現在政府要穩定台灣供電，提出的解決方案是核能四廠，後果包括可能的風險及低放射性核廢料的問題，因此政府可能會不斷測試核電廠的安全性和在蘭嶼建造處置場，這是穩定電能解決方案會帶來的後果，所謂解決方案，無非就是在現有的技術限制、成本、效益內達到妥協。
今天大家反核能，要求關閉所有核能電廠，無論是新設火力機組以致電價大漲，這是政府回應廢除核能四廠，為了降低用電需求而提出的解決方案；聽起來是在恐嚇，可是這也是現實，如果有又安全又便宜的廢電方式我會不要嗎？可是台灣天生能源不足，如果人民不體認這點，抗議完回去繼續過著浪費電的生活，政府漲電價又抗議，批台電肥貓，罵死所有至今努力維持台灣不斷電的員工，這樣你要政府怎麼做？
所有方案背後都有妥協和限制，如果要大家正視方案背後的限制和技術的極限，這也算是恐嚇，大概所有的解決方案都不必提了，只要矇著眼聽著自己人的高談闊論，然後鬥死所有正視現實的人。
舉個例，下面資料一新聞報導，因為手機訊號極弱，接電話必須走到街上，然後直批中華電信服務品質；可是，當初就是因為該鄉鎮反對在家門前設定基地台，電信公司設不下去，害怕基地台帶來致癌的風險。這是電信公司的錯？還是民眾自己不清楚後果？因為射頻的極限就是在那，你不能兩手一攤，叫電信業者做出不用基地台的手機，因為技術上做不到，電信業者說：「再拆基地台訊號就會低到不能使用」，這是恐嚇，還是叫你睜眼正視現實？
其實隨煤、油、天然氣價格的變化，台電早就處在虧錢狀態，由政府出錢維持如此低的電價，使用更多的再生能源，情況只會更糟；我可以認同民眾反核的理念，但我不認為民眾可以什麼都不用理解，抗議完就拍拍屁股沒我的事，因為即便是集體，在盲目下決策也不一定就是正確的。

最後最後，我只想說： 為什麼我們需要核能、火力？因為它的能源密度夠大，網路上轉載很多再生能源的「替代方案」，一眼就看得出是在胡扯，在屏東種點太陽能就可以超過一座核能電廠？幫忙消耗太陽能板廠的產能過剩還差不多；又或者，直接說用電量跟備用容量率相減，然後說台灣沒有缺電問題；這些只會讓我覺得你沒先了解過問題，或者你根本懶得正視技術的現實，我不管你反核擁核，拜託不要再轉這種一看就非事實的文章了。

相關資料
1.千戶手機沒訊號 放塑膠袋掛騎樓等電話
http://www.youtube.com/watch?v=58k2T9IgXfA

題外話，啊現在電信公司提出新的解決方案，幫你們裝了強波器，這下你倒不怕電磁波了？只有一樓收得到就說明它的電磁波是有多集中。

ADS小電路模擬設定

個人用ADS喜歡把電路的小塊小塊變成一個個模組(component)，比如說device建成一個模組，matching network建成一個模組，dc bias 的bypass電路建成一個模組。
這樣做的好處有：
1. 主電路不會太複雜，各個元件的關係十分清楚。
2. 要換掉元件十分容易，例如要把matching network從理想元件換成EM的S2P檔，只要改模組裡的接線即可。
3. 要對模組內的元件做微調時，可以清楚知道在微調哪個部分的元件，這在元件數多時很好用。
另一方面，這樣做也有幾個問題：
1. 大電路的模擬無法求得電流等資訊，即無法計算功耗，因此需要將dc線拉出來，造成電路稍加複雜。
2. 大電路的模擬設定會和小電路的相衝突，進行模擬時要將小電路的模擬關掉。

第2點煩人之處在於，大電路模擬和小電路模組行為的確認，幾乎都是要做的，例如DC bias 一定要加上bypass電路來隔離電源的雜訊，會先對bypass電路進行設計，進行S parameter模擬，確認頻帶內設計OK，再將bypass代入大電路中，這時候麻煩來了，ADS並不允許多重的模擬設定和模擬終端(term)，此時要先將小電路的模擬設定和終端給取消掉，否則會產生重複的模擬設定；如果後來需要再次確認bypass的設計，就要再打開小電路的模擬設定和終端。
看device S2P也是，先在模組內模擬，確認device行為正常之後，要在大電路模擬，就需要進到read S2P的電路設計，把其中的模擬關掉；如果要換device，也要重開。
這樣每次來回的開關小電路的模擬設定，一是麻煩，二是徒然浪費時間，最後還容易做錯，實在不太聰明。

寒假個人自學了DesignPattern，前幾天突然從Design Pattern類似的概念，想到第二個問題的一個解法。 只要把bypass的implementation(電路架構)做成一個電路設計，bypass的模擬設定(interface)則做成另一個設計，這個模擬設定和大電路都各自包含bypass的implementation，要修改bypass，就到bypass模擬設定裡去tune，而大電路仍能正常模擬。
這樣一來，無論我要做大電路模擬或是調整小電路，都不需要再去開關小電路的模擬設定跟終端，可以簡省工作的時間，提升設計效率，看來沒事看看DP等其他領域的東西，也會有些收獲。

工作站passwd整理

最近開始涉入系上的Linux 工作站管理，這個工作最重要的就是耍廢維持工作站的穩定，及提供系上同學放心的用Linux進行模擬等工作。
每個學期定時的，會有新的同學加入，這時候就要幫大家設立新的帳號，很幸好會用Linux工作站的人不多，第一個原因是做電路的人佔比本來就比較少一點，第二個原因是大家自己的電腦好像都比工作站還要強，畢竟實驗室裡有一位光華商場的供貨中盤商，什麼i7-3770, E3記憶體插到32G的，哪天出現E5的電腦我都不驚訝了。

好像有點離題，總之是要幫大家建立帳號嘛w。
當然因為使用者不多，手動加也是OK，但老話一句：Working hard, after you know you are working smart，管帳號要怎麼smart管？
因為我們的server大約有400多位使用者，依照各不同的教授或管理員帳號分為26個群組。
其實可以很簡單的用script的方式，adduser, chown, chgrp, mkdir等，大量新增使用者，不算太難。
但因為我希望在passwd裡面，不同群組的使用者資料能連在一起，這樣有新人加入才能快速找到這位教授有多少學生，給予新生連號的UID編號。
後來發現這個有個簡單的解法，利用bash的sort即可輕鬆解決。
Sort -t: -k3 -n passwd
依序表示：用 : 為分割字，取第3個分段(GID)為key；key是一個數字，不是字串；這有點類似python sort指定key的味道，沒那麼威猛，但短小精幹，處理事情綽綽有餘，瞬間就完成passwd的排序。

Design Pattern

最近小弱弱版主在看設計模式(design pattern)相關的書，寫一下我對它的感想。

我認為design pattern中相當重要的是繼承和polymorphism的概念：
繼承讓我們能定義一個基礎的型別，然後依據不同類型的物件，都繼承自這個基礎型別
Polymorphism則允許我們利用基礎型別的pointer，依據執行時指向的物件來取用它的資料。

從design pattern來看，Polymorphism有兩個最重要的功能：
1. 也就是上面提過的，是在執行期決定要執行哪個function，只要用父代的pointer去access繼承產生的子代，就可以視生成哪個物件來取用它的function，這也是一般教polymorphism時會提到最基本的用處，相信設計師都很清楚了。
2. 第二個功能延伸自第一個，利用polymorphism給予我們執行期時的彈性，延伸出來的是，在設計、修改時保有彈性（也就是Design Pattern），把每個不相干的部分給分開，讓我們不必要每次要新增功能、新增新的物件時，都要進到Implementation的層次做修改，浪費許多時間在尋找該加上新功能的地方；另外也能減少增加新東西時，因為相依關係而要重新編譯的部分。
事實上我認為第二個功能的重要性遠高於第一項，設計的彈性增進工作效率，才能將Object oriented的火力全面發揮出來。

說個自己想，沒什麼用的例子：
比如說我們要寫個選角色的程式好了，每個角色都有一個主要的招式master spark之類
所以說，最簡單的寫法就先設定一個基礎的角色：class character，內含一個main_spell()
然後各個角色繼承這個character.h，定義自己的main_spell()裡面要幹什麼，這時候所有角色的介面就一致了，可以用一個character的pointer來操作每一個角色的功能。
但這樣做其實不夠好，如果今天我們希望有些角色的main_spell不要動作怎麼辦？然後每個人招式又都不一樣？
我們可以打開每個角色的原始碼，然後重載(overload, 這個翻譯=w=)main_spell()
可是如果我們要加上10個角色呢？
所以Design Pattern就會要求，不止character，連main_spell也要是一個base class，不同的招式則是繼承它後修改，character則包含一個main_spell的pointer，用polymorphism的方式取得不同招式；如此一來，可以很方便的加上新的main_spell，只要新增main_spell的class即可，在character的介面卻完全不需要更動， 在維護跟更新上會更有效率。

這個composition over inheritance應該算是最基本的design pattern的概念了，Design Pattern所教的，就是過去神級的設計師，針對許多設計上的問題提出適當的解決方案(雖然感覺就是愈會變動的地方就會加上更多虛擬層，或是愈切愈細)，據說在STL裡面用上許多Design Pattern，如果小弱弱板主學有心得再上來獻醜。

參考資料：
1. Head First Design Pattern:
http://shop.oreilly.com/product/9780596007126.do
會用google的可以在後面加上pdf
2. http://sourcemaking.com/design_patterns
包山包海的Java/C++ source code