WEWE x 知識 x 學習 x 筆記

 前言 在我工作的團隊中，幾個月前我們改變了我們使用svn的方法，加入了feature branch的概念，就是每開發一個新的功能就需要從主幹開一個branch出來做開發，以免開發中的功能影響到其他人的作業(bug fix ...)。我們在改變規則的時候討論了很多次，原本以為規則已經很OK了。殊不知，才是惡夢的開始。 老舊的branch 有些功能branch分出來之後，此功能可能初步開發完成，尚未測試完成。但因為專案時程與需求變動的關係，導致這個功能的優先順序降低，所以不能跟著下次的release出去，且被assign更緊急的工作，這個feature branch 從主幹分出來太久，之後要merge回主幹可能會有一大堆衝突與問題。而你也沒辦法保證被svn auto merge後的結果一定是正確的，這個時候問題就來了。 如何解決老舊的feature branch? 我找了一些資料，這篇stackoverflow上是跟我一樣的問題 Subversion Branch/Trunk Best Practice - keeping Branch Up-to-Date? ，其中提到的我覺得OK的做法有幾點: 常常把主幹的code merge到你的feature branch，也就是說常常更新你的feature branch，就像每次開發前要update code一樣(好像有點爛，不過這好像已經是最好的辦法了 主動教你的團隊如何把code merge做好，且誰做更動的就應該由更動的人做merge的動作 我也覺得要常常更新feature branch，但為時已晚ㄎㄎ，我還是需要merge一大堆change，解決一大堆衝突，慘兮兮。既然都要做了順便提一下如何 Keep your feature branch up to date. 有人有更好的辦法歡迎留言告訴我。 Keep your feature branch up to date. SV作法其實很簡單，就是把主幹merge到branche就好。 Keeping a Branch in Sync Svn book - Branching and Merging  > Keeping a Branch in Sync Without Merge Tracking Su

最近在辦公室用centos寫code， 常常在用tab 補齊指令時，找不到東西就逼逼叫 很吵，所以就去找了一下怎麼處理想不到意外的簡單 pcspkr (PC speaker) 這個是一個kernel module預設會載入，用來控制那個主機板上機歪的警示音撥放器   記得要切換成root權限 使用lsmod確認你的這個module是否有被載入(有被載入才會叫) lsmod | grep pcspkr 使用rmmod卸載那個module rmmod pcspkr 就OK了 如果想在以後開機後都不要讓他載入就編輯 /etc/modprobe.d/blacklist   在這個檔案加入 blacklist pcspkr 把pcspkr加入黑名單，以後在開機時就不會被載入了 參考網址: http://thedaneshproject.com/posts/how-to-disable-the-beep-in-linux/

    這三個月下來，從中心同事的身上學到不少東西，這些都是他們累積下來的經驗，讓我收穫良多，謝謝他們。工作已經將近三個月，有很多的心得，職場、寫程式都有不少心得，今天先從程式談起好了，以前在學校無論是寫作業，接case，算一算也寫了不少程式，但真正工作寫大型的軟體後。發現產品跟之前寫的程式完全不一樣，要考慮的事情也多了很多，我從程式的設計、開發、測試三個部份來說好了。 設計   之前寫程式雖然知道事前的設計很重要，但都是粗略的想一下就著手進行開發了，往往在開發完成要使用的時候遇到需要改很大的問題，額外又多花很多時間修改。看書上寫多多紙上談兵，設計的修改往往比成式的修改省時，但那時沒甚麼感想。現在外面工作之後，才真正在實務上遇到，我們花很多時間在討論新的功能如何實做，以及會遇到各式各樣的問題都事先預想，怎樣跟其他組整合才不會影響到原本的功能，甚至討論到快吵起來。不過最後討論出來的東西雖然稱不上完美，但也非常好了。而且在我們的team中，大家的設計都是往right things to do 的方向想，也會兼顧目前的時程，我覺得非常的好。有非常多的人事物值得我學習。 開發前多想一點多考慮一點，以後的修改與錯誤就少一點。 開發 開發的部分也有很多跟以往經驗不同的地方，最讓我印想深刻的就程式的容錯性，因為我們開發的是儲存系統，上面儲存的的是重要的資料，所以容錯性非常重要，在這常常需要考慮到，系統crash後再啟動，資料是否能正確的被保留下來，系統是否能正常運作，在這個部份我是完全的新手。但在我們組內，每個人開發都會考慮到容錯性，還有錯誤還原等問題，這是我不足的地方，也是我在這裡努力的方向。程式的效能也是一大的考量，之前再開發教學網站就有預到類似的問題了，這種問題處理起來也蠻累人的。在工作之後，這個問題也是每天會討論到的問題，希望在這裡可以學到這方面的經驗。不過在這邊的開發也有一些問題，文件的不足(我之前想到公司學的就是開發的文件化)，由於我們中心也才成立第三年，很多流程制度等也還不夠成熟，很多都是藉由大家的努力持續在改善中，文件我想過一陣子開發的進度不那麼忙的時候就會被注意到了，到時候就做中學吧。還有一個很大的不同，就是以前很少開發multi-thresad的程式，這邊幾乎都是，所以在除錯上的困難度對我來說很高，我有找一個同步問題找一個禮拜的經驗= =

最近在學習unit  test如何撰寫 所以上google找了一些資料 看到一篇文章 http://www.artima.com/weblogs/viewpost.jsp?thread=126923 A Set of Unit Testing Rules  -  Michael Feathers 作者在文章中提到幾點不能被稱作unit test的測試 It talks to the database 與資料庫連接 測試之中需要對資料庫做讀寫查詢的動作 It communicates across the network 測試之間透過網路對談 測試之中元件的溝通需要透過網路 It touches the file system 使用到檔案系統 測試之中需要做檔案的讀寫存取 It can't run at the same time as any of your other unit tests 不能與其他的單元測試同時執行 單元測試之間無法獨立執行 you have to do special things to your environment (such as editing config files to run it) 在測試時必須作特殊的設定 每次測試都需要做特殊的設定 以上作者提到的點，雖然不是不應該測試，但是在Unit test中，重要的目的是，獨立力測試各個元件的正確性，與其是否達到目的。所以對於資料庫、網路、檔案系統的操作應該需要被獨立在測試外，由整合測時時來做測試，才可以確保測試真正個核心是在元件本身，也就是說可以獨立問題的所在。舉例來說，對於需要讀寫檔案做處理的原件，如果單元測試出錯，又沒有把檔案的操作獨立，這樣的一來單元測試無法幫助你分辨是你的元件出錯或是檔案的讀寫出錯，這樣單元測試的幫助就不大。假如你有利用Mock object的技術把與元件與外部元件的操作獨立，這樣一來就能較精確地抓住問題所在。 所以今天的結論是，單元測試，必須確定測試的是元件的邏輯，是獨立的測試，必須將與其他元件的溝通切的乾淨清楚，才能有效的對元件做獨立的單元測試，幫助找到正確的問題，至於如何把元件之前的溝通切的乾淨清楚，又是另一個課題了。

最近想要試做一個 語音轉文字的小程式 流程 -> 上傳錄音檔案->利用線上的語音辨識API->辨識出文字並回傳 我找到了google的語音辨識api ((chromium 瀏覽器 speech input程式中找到的) 但她只接收 flac的音檔格式 所以需要再找轉檔的api 找到了 一個線上轉檔的網站 http://www.online-convert.com

進入virtualbox的安裝目錄 cd C:\Program Files\Oracle\VirtualBox 執行指令設定port 的 nat轉換 VBoxManage.exe modifyvm myvm  --natpf1 "guestsshh,tcp,,8000,,80" VBoxManage.exe modifyvm myvm  --natpf2 "guestsshh,tcp,,2222,,22"  上面指定把本機的 8000port轉至vm 的 80port  把本機的 2222port 轉至 vm 的 22port