人月神話

這本書其實有點老舊了，舉的例子都老到不行，不過讀起來還是覺得相當中肯。

我覺得凡是在開發軟體的開發者，管軟體開發的管理者，開軟體公司的老闆，都可以從這本書裡獲益；總括來說，開發軟體跟開發軟體系統，是完全不同的問題，前者是技術，關係的是個人工程師的熟練度；後者卻是管理，關係的是一群工程師如何溝通。

簡單的軟體大部分的軟體工程師都能寫出來，但，軟體系統需要在不同平台上測試過、需要完整的文件說明、需要讓內藏的錯誤儘可能的被找出來，這當中的工夫是以倍數在算的；如果算上每個工程師間的溝通成本，缺乏管理能讓大型團隊一事無成，這也是本書名的來由：「人月」並不是衡量軟體系統開發難度的好指標，我們都知道一個工程師寫一個月和三十個工程師寫一天，所能得到的東西是完全不一樣的。

每一章，作者都針對一個軟體系統開發的管理要訣進行說明：如何組成有效率的團隊、架構設計師的重要、團隊要如何溝通、文件怎麼管理……。可以算是作者在大型系統開發打滾多年之後總結出來的武功祕籍，一步步讀來，除了吸取作者字字珠璣的告誡，也讚嘆作者在那電腦還是珍貴資源的年代，就能完成如此大型的系統開發，網路上也有不少人整理出書中的重點，可見Heresy blog，有第一到十二章的整理（我也很好奇為啥十二章之後就沒整理了lol）：
https://kheresy.wordpress.com/2011/03/22/the_mathical_man_month_p1/
https://kheresy.wordpress.com/2011/03/25/the_mathical_man_month_p2/
https://kheresy.wordpress.com/2011/04/01/the_mathical_man_month_p3/

本書的第十六章是一個頗具話題性的章節：沒有銀彈

這裡的銀彈不是指金錢，而是指在對付可怕的狼人(軟體系統專案)時，大家總希望可以出現神奇的銀彈可以讓狼人一槍斃命，但作者認為：沒有，這世界上就是沒有銀彈，沒有任何突破能讓軟體系統的生產力大幅提升一個數量級；想要弄好一個軟體系統，好好規劃、實行才是正途，就像想要對付狼人，好好改造、把它萌化才是正途。

作者的論點是，因為軟體就是如此複雜的工作，現在的進步例如引入高階語言、物件導向、分時(time-sharing)、人工智慧等等，都只是處理軟體附屬上的困難，沒有直指本質的複雜核心，當附屬的困難被解決了，本質的困難仍未解決，人們在創作、溝通、理解軟體上，仍然有著無法解決的本質困難，而附屬困難並佔不到軟體開發的9/10以上。

詳細內容可見：
http://zh.wikipedia.org/wiki/%E6%B2%A1%E6%9C%89%E9%93%B6%E5%BC%B9

我個人的看法是沒這麼悲觀，以十年來看，軟體開發也許沒有十倍進步，但長久看下來，我們的軟體生產力仍然進步神速。

現今的高階語言，也許可以用C++的standard library 為濫觴，為常用的複雜架構定下一個標準，現在要寫出複雜結構的程式碼遠比過去容易，也更不容易出錯；安全、多執行緒方面，新一代的高階語言如AZ大神推薦的Golang，最近在研究的Rust等，都針對這方面進行了補強。直譯式語言讓原型(prototype)建立更容易，展示程式概念也更加輕鬆寫意，在各種平台上也能有同樣的表現。

對測試、自動化產生code 都有更好的支援，servo用python 去剖析規格文件，自動產生出幾萬行的程式碼；網路提供的服務，例如issue tracker, git, CI測試、文件控管，林林總總的服務，程式碼的生產、測試、管控遠比過去強大得多。

十年也許太短，把「沒有銀彈」的尺度拉開，軟體本質的複雜性問題仍然被解決中，隨著軟體解決問題的能力不斷上升，我個人樂觀的覺得，我們生產軟體系統的生產力，仍然有超過一個數量級的提升。

－－

引用本書開頭的一段文字，大意是這樣的：雖然程式設計師很辛苦，要不斷在軟體系統的焦油坑裡掙扎，永遠解不完的bugs，被客戶刁難，被上司責怪；但軟體還是有光明的一面，把腦中想像的東西實作出來的成就，解決問題的快意。儘管走在軟體的路上有苦有樂，總的來說，樂趣還是多於苦難。

儘管前途崎嶇，崎嶇的路上，我們還是會笑著走過去。

一本讓我頗有共鳴的書，推薦給所有正在焦油坑裡掙扎的軟體開發者們(喂)。

Rust struct, impl, trait

前言：最近被強者我同學呂行大神拉去寫Servo (https://github.com/servo/servo)
用的語言是Rust(http://www.rust-lang.org/)，是個非常年輕的語言(2012年出現)，另外有一個老一點的Golang(2009)，基本上目前中文找不到什麼資料，就算是英文的文件本身也不太完整Orz

想說文件這種東西，只要不是亂寫愈多愈好，就在這個blog 上寫一點Rust 相關的文件，等寫多了好整理起來；基本的rust 像什麼函式怎麼宣告、if 格式之類我就不寫了，那個自己翻一翻就會了。

我出身是C/C++, Python，所以解釋角度也比較偏這樣的語言。

－－

這篇介紹Rust裡的集合物件: Struct, impl 跟trait

struct在rust 裡跟C++/Python的class一樣，是物件的集合跟函式的集合，不過rust 採取的方式是用 struct A / impl A的方式，把集合的物件跟函式分開。

所以在Rust 裡很常看到這樣的寫法：

struct Car
{
   Speed: int  
}  
   
impl Car {  
  fn run(&self){  
    println!(“my speed is {:d}”, self.Speed);  
  }  
}  

一個struct 比較像C裡的struct，補上impl 就變成C++裡面的Struct/Class

同時如果我們要提供一個共同的介面(interface)呢？例如我要Car跟People都實作run 這個函式，在Rust 裡這東西可以用trait 來實作，首先先實作trait，然後就可以對struct實作trait，這東西很像java 裡面的，例如：

trait movable {  
  pub fn run(&self);  
}
  
impl movable for Car{  
  fn run(&self){  
    println!(“my speed is {:d}”, self.Speed);  
  }  
 }  

之後就可以明目張膽(?)的呼叫Car.run()了

更多內容請見：
http://rustbyexample.com/trait.html
http://tomlee.co/2013/05/traits-structs-and-impls-in-rust/

用youtube開Hangout直播

最近看到watch people coding 這個網站，也真有不少人在上面開實況寫code，覺得滿有趣的，也應該自己來開個實況試試。 目前開實況知名的有Twitch ，這方面有點難搞，目前linux 沒有這方面完整的解決方案，只能用一些程式來解決，相關網址在此： https://wiki.archlinux.org/index.php/Streaming_using_twitch.tv
不過我沒有twitch 帳號，懶得申請；帳號多開一個是一個麻煩

所幸我們有另一個解決方案：用Youtube開直播。
在youtube 右上角自己大頭貼的地方，可以進到「創作者工作室」，影片管理員內就有「現場直播」可以開，不過它要跟手機連線驗證，等於是告訴google 你的手機號碼，大家連結前請多想三分鐘；打開後它會直接用google hangout 開直播，不用特別裝其他程式。

打開後大概會長這樣：

左列有一些工具可以選，例如螢幕分享，可以指定某一個視窗做為直播的內容，例如直播寫code用的終端機或者你的webcam，目前看起來沒有混成螢幕的功能，也就是不能像其他直播一樣，畫面上還會有一個webcam 的影像；也可以開右邊的訊息視窗，不過那個跟youtube 直播頁面上的訊息沒有同步。
按開始播送後就會開始直播了。

不過我覺得直播寫code 本身就有一個問題，直播遊戲的時候，遊戲是比較簡單的東西，今天打東方是躲子彈，明天打東方也是躲子彈，看直播可能可以看一些閃躲的技術；可是寫程式不是，中途插進去的話會不知道那個人是在寫什麼，直播也很難表示出設計師在背後的架構設計，設計概念，很容易變成看一個人在打字，那樣的話直播寫程式一點意義也沒有。

用python讀入agilent (keysight) binary file

故事是這樣子的，最近拿到一些透過Agilent示波器（好啦你喜歡叫他Keysight也可以）讀到的資料，要對裡面的數字做分析，由於資料極大時他們會用自家的binary格式存檔案，要讀出資料分析就比較麻煩。
他們自家網站是有提供……程式來分析，可惜是用matlab寫的…
What The F.. Emmm, Ahhh, Ahhh, 沒事
總之我看到這個東西就不爽了，俗話說人活著好好的為什麼要用matlab。恁北想用python沒有怎麼辦，只好自幹啦。

其實整體來說滿簡單的，只是把matlab code 用python 寫一篇，python又比matlab 好寫很多。
比較值得提的只有一個，分析binary就不能不用python的struct，相關的內容可見：
http://yodalee.blogspot.tw/2014/03/python-structdex-file-parser.html

這次我再加上用namedtuple來處理，整體會變得很乾淨；例如它一個波型的header格式是這樣：

int32 headerSize
int16 bufferType
int16 bytesPerPoint
int32 bufferSize

那我就先定義好namedtuple跟struct的format string:

from collections import namedtuple
bufHeaderfmt = “ihhi”
bufHeaderSiz = struct.calcsize(bufHeaderfmt)
bufHeader = namedtuple(“bufHeader”, "headerSize bufferType bytesPerPoint bufferSize")

再來我們讀入檔案，直接寫到tuple裡，就可以用名字直接存取值，例如我們要跳過header：

bufHdr = bufHeader._make(struct.unpack(bufHeaderFmt, fd.read(bufHeaderSiz)))
fd.seek(bufHdr.bufferSize, 1)

是不是超簡潔的？一個晚上就寫完了=w=

人生苦短，請用python。

原matlab 網址
http://www.keysight.com/main/editorial.jspx?cc=TW&lc=cht&ckey=1185953&nid=-11143.0.00&id=1185953

原始碼在此，不過我覺得是沒什麼人會用啦orz
https://github.com/yodalee/agilentBin

Translate Qt translation file (.ts file) using Python and Google Translate

Pyliguist

A python script translates Qt ts file by google translate

Recently I'm working on project Qucs. This project only has a little group of developers.

The program got about 3000 entries need to be translated, which, however, no one wants to translate them. To translate them manually is a very hard, and time-consuming work. It makes me think of using Python to translate these text automatically.

Luckily, there do have an automatic tool: Python Goslate package.
It's very simple to use, just create a goslate object. Then you can call function translate to translate the text, like this:

>>>go="goslate.Goslate()
>>>go.translate(“worship”, “zh-tw”)
崇拜

I write a little script “PyLinguist” in Python, which use Python “xml” to parse Qt translation file. Then use Python package “Goslate” to translate the text.

It takes 30 seconds to translate 200 entries in test file, which is much faster than translate manually. Though there is some problem. For example it translate “Help” into “Save me” in Chinese, but generally it works.

The source code is here:
www.github.com/yodalee/PyLinguist