好忙的民國100年

99年，9月：得知懷孕，開始計畫成家事宜。
99年，10月：在苗栗被一個阿罵撞，還說要告我...。
100年，1/23：於台北國際飯店結婚。
100年，2/28：於高雄富苑餐廳補請。
100年，3月：北高工作大抉擇。
100年，4月：找房子，看是要租還是買。
100年，5月：找到房子了，自己找輕隔間、油漆、水電、鋁門窗、搬家，真的超累的...。
100年，6月：5/31兒子出生。
100年，7月：終於....有一個家了，有一個字，累...。

系統架構設計的開始

從零開始的時候，系統架構設計分為幾種方式：

1.分析Use case：

從需求面去設計一個系統的架構，常用的工具是use case。也就是從use case去分析出所需要的架構。要盡量知道所有的use case，需要使用activity diagram以及state chart來尋找出符合需求的use case。然後一個接著一個地去分解出子系統，並依樣畫葫蘆尋找子系統中的use case。一個主系統中單獨的一個use case可以分解出一些存在於子系統中的use case，而這些子系統中的use case正是滿足主系統中的單一user case。如果系統很大，子系統中還可以再分解出子系統。如果使用package，可以將某個(些)use case以及跟它相關的actors, activity diagrams, statecharts, and sequence diagrams通通打包起來，並賦予package名稱以便管理。

沒有版本管理，情況三

情況三：

FAE：ㄟ~Magic，上次QA發行後的版本，客戶那邊發生一些問題耶。你可不可以給我更早以前的

版本。然後給客戶更新試試看會不會當。

Magic：(心想)靠杯...忘記備份那時候的code了...。這之前又改了一堆東西，要我怎麼回溯阿....只能找小叮噹了...

Ans:如果有使用版本管理軟體，絕不會發生這個問題，因為你能夠找出送測當下所有的code，並將之抓出，然後建構出當時的環境。如果發現到舊版本不會有這個新版本的問題，那就知道可能有人改出side effect。此時就可以發揮版本管理的威力，因為你能夠利用revert之類的功能，將某些檔案回溯到某個版本，如此就可找出是誰的包。否則到時一定又要上演羅生門的戲碼，不僅沒有效率，又會降低團隊的士氣。

沒有版本管理，情況二

情況二：

喇叭主管： 我排定下禮拜要送測，請Magic蒐集大家的code，建置好系統送測。

Magic： 好。

其他人： ...。

------------------送測前一個禮拜----------------

Hero: Magic~~我改好了xxbug，幫我更新一下

Apple: Magic~~我上次給你的那個code幫我復原一下，我搞錯了不好意思...

Doramon: Magic~~我換了你新給我的環境會掛掉耶...

------------------送測前1天----------------

Apple: Magic~~我改好了xxbug，幫我更新一下

Hero: Magic~~我上次給你的那個code幫我復原一下，我搞錯了不好意思...

Doramon: Magic~~我換了你新給我的環境會掛掉耶...

------------------送測前1小時----------------

Doramon: Magic~~我改好了xxbug，幫我更新一下

Hero: Magic~~我上次給你的那個code幫我復原一下，我搞錯了不好意思...

Apple: Magic~~我換了你新給我的環境會掛掉耶...

------------------送測後----------------

Doramon: Magic~~我改好了QA測到的xxbug，幫我更新一下...

Hero: Magic~~我改好了QA測到的xxbug，幫我更新一下...

Apple: Magic~~我改好了QA測到的xxbug，幫我更新一下...

Magic: 老闆~~我要辭職!!我這禮拜一值在幫其他人放檔案、回覆、測試，連到送測前一秒鐘都還要我更新!!我每分每秒都要專注在copy檔案，中途還不能被打斷!!甚至無法上廁所!!你是要搞死我阿!!我也有bug要解阿!!可不可以找工讀生來做這件事阿!!

喇叭主管： 那請大家前一天就給Magic 穩定的code，不準再改!!

Ans：讓我來告訴你結果，就算叫主管規定最後一天就要給穩定的code，也不可能執行的。因為總是會有人最後一秒發現bug，然後拜託Magic包版本。Magic會不包嗎? 包了，累死。不包，被幹死，說見死不救。於是喇叭主管就只能眼見Magic背著黑鍋離開，換下一個人來發行軟體。喇叭主管之所以喇叭，就是拿不出任何辦法解決Magic的問題。

我來幫Magic解決...Magic需要安裝一個版本管理的server，並且教大家如何將各自的code自己放到server上，不再透過Magic去copy、管理。Magic只需要在發行的前一分鐘，將所有的code抓下來，然後建構出大家都已經放到server上的版本來跑即可。這樣子Magic就不會累死了。

沒有版本管理，情況一

情況1： 當您遭遇到同事常常會跟你哀說：

Magic :Hero你剛剛給我的fw會當機耶!!

Hero :我這邊都不會阿!!Magic你要不要再試一次阿。

Ans: 這種問題常發生，問題不外乎就是建構環境沒有同步，此時你需要寫一套工具，可以快速的將對方的版本跟你的同步。此工具需要將環境所需要的資料、執行檔，建構出跟你的一模一樣，然後將你負責的執行檔部份，在run time時期能夠顯示你的版本名稱，如此才能在對方的環境中，證明你負責的部份在你的控制範圍內。否則你的程式在對方的環境跑，根本無法知道他跑的是不是你剛剛摳給他的。還要用比對軟體來比對，這簡直是非常累人的。如果用版本管理軟體，就可以在執行期間印出版本，然後對照版本管理軟體所記錄的歷程，是否的確解掉bug。一定要這麼做，你才能脫離夢靨。

版本管理

在嵌入式系統開發過程中，有很大的部份是軟體開發。有很多人在做嵌入式系統相關產品時，完全不會想要做版本管理。不做版本管理，是你正在演奏專案失敗的序曲。因此我在這一年的工作中，深深的感受到版本管理的重要性。我在此大概分享一下為什麼版本這麼得重要。我這邊舉一些您在專案中可能會遇到的問題，那就代表你要快點使用版本管理軟體。

詳解ttysnoops

前言：
ttysnoops是一個監視文字console的一個小工具，如果在embedded system開發環境，通常是使用com port或是使用telnet ssh之類的方法去做溝通。但是如果你的機器並不在你身邊，你卻想要知道你寫的程式過得怎樣，一個人在遠方是否有什麼異狀，想要知道它輸出的訊息?
這時該怎麼辦? 這時就會需要用到ttysnoops了。

原理：

ttysnoops 需要在執行login之前先被執行。ttysnoops執行時，如同ssh一樣，會先開一對/dev/ptm、/dev/pts/x。

然後會用execv來執行login，並且使用dup2來轉移login的stdio到/dev/pts/x上面，如此一來ttysnoops就可以利用對應的/dev/ptm來做存取。

解析source code：

ttysnoops會先開啟一個/dev/ptm，kernel會自動生出一個/dev/pts/0出來，find_ptyxx中，ttyfd可能是/dev/pts/0，dup2將ttyfd複製給stdio。 如此一來，這個行程(ttysnoops的子行程)的所作所為就會反映到/dev/pts/0，而不會在stdio上，又/dev/pts/0對映到/dev/ptm，因此ttysnoop可以讀寫/dev/ptm來達成與(ttysnoops的子行程)溝通。所以ttysnoops稍後會有一個處裡，也就是查看ptyfd(/dev/ptm)若有資料，會寫到ttysnoops的stdio，來讓使用者以為一切都很正常。

因此稍後執行login以後，它所顯示的東西會寫到/dev/pts/0上面，而不會顯示在stdio上，又因為父行程(ttysnoops)繼續執行去監視ptyfd(/dev/ptm)，就會感覺是直接跟login直接溝通，但其實資料流已經透過ttysnoops攔截下來了。如果有一個client連進來後，ttysnoops又會fork出一個子行程，然後它會開啟一個/var/spool/ttysnoops/0這個named socket，然後再一次使用dup2將stdio導向到這個socket，如此一來，login的所作所為就有兩個行程會知道了，ttysnoopys以及連進來監視的client。

使用情境：

1. 當執行login以後，login會輸出login:的字樣，提示輸入帳號

2. 此時login只會寫到ptyfd上面，因此ttysnoop會將這個字串讀出並寫入自己的stdout

3. 這時候本機上就顯示login:了

4. 如果本機上打字進去，會由ttysnoop先收到，收到以後就寫給ptyfd，然後login就會去做後續工作....
5. 這時，有client登入了，登入以後，如果ttysnoops從ptyfd讀出東西，就會輸出給他自己的stdout，當然就也會輸出給authfd

6. 若是client打字進來，authfd收到以後，因為他對應到ttysnoops的stdio，所以ttysnoops也會從他的stdin收到字串，收到以後就會使用write寫給pthfd

下載連結：

http://sysd.org/stas/node/35