別讓make的頻率過快，gc不是隨時都在作用

我以為使用俱有gc的語言，就可以為所欲為的配置記憶體（反正有gc在後面擦屁股）。但是從Ｃ寫系統程式上來的經驗告訴我：真的有這麼好嗎？雖然抱持著懷疑，但還是先下手寫點code吧。

於是我開始寫go，不疑有他、放心的make([]byte,hugeSize)，直到最近的案子中，需要模擬5萬條長連線到一臺測試機器。只送出了幾千個連線請求後，就被OOM Killer 關心了。code大概是這樣：

for {
        bigArray := make([]byte, 1024*1024*10)
readFromTcp(bigArray)
}

debug 之後讓我發現不要在一個for迴圈裏面make，尤其是我的測試需要跑5萬個迴圈，雖然每次回圈的make只用來讀取一次，但是gc並不會“瞬間”就把剛剛沒用到的記憶體清掉。因此，要善用每一次的make，盡可能地重複使用它。

bigArray := make([]byte, 1024*1024*10)
for {
readFromTcp(bigArray)
}

另外，參考 io.Copy() 裡面的實作方式，是在回圈之外先make一個小塊的記憶體，再用回圈的方式去將資料全部複製。

buf := make([]byte, 32*1024)

for {

nr, er := src.Read(buf)

if nr > 0 {

nw, ew := dst.Write(buf[0:nr])

if nw > 0 {

但，如果 io.Copy 頻繁的呼叫（1024次/s），記憶體以近32M/s的速度消耗，又該怎麼辦？可能就不能使用io.Copy，而是自己管理記憶體了。

有人提出以buffer pool搭配channel來明確(explicit)的還回記憶體，來減少make的頻率。在記憶體未使用完前，讓gc有機會工作。http://blog.cloudflare.com/recycling-memory-buffers-in-go

[]byte 轉型 string 必須注意 []byte 的長度

常常需要從 []byte 轉換到 string，來使用 string 的功能。

但是必須注意的是 []byte 並不一定是以 0x00 結束，如果就直接轉型到string，而直接使用strings的一些函式。“有時”就會造成不可預期的結果。像是我要從socket讀取資料，先建立了一個BUF_SIZE的[]byte array，這個大小是2M Bytes。

read_buf := make([]byte, BUF_SIZE)
byte_count, err := conn.Read(read_buf)
log.Println("Receive ", byte_count, " bytes\n", string(read_buf))

跑到Println的時候，發現而且ssh連線幾乎沒有反應。找了又找，後來發現到是Println花很久的時間。我才意會到，原來golang還是要處理結束字元。所以[]byte轉換string的時候，必須要知道byte的長度。因此Println改成下面代碼就解決了問題

log.Println("Receive ", byte_count, " bytes\n", string(read_buf[:byte_count]))

駭埕市

         第一次參加hackthon的我，懷著赤子之心去參加了這個駭埕市的活動。從題目的挑選、組隊、討論、田野調查、轉換題目，一直到最後面得到了第一名。這2天的活動就好像是自己開了一間公司的過程，一個隊伍(公司)最後能否獲得評審(客群)的青睞，其實從題目(產品)定位就決定了這間隊伍是站在哪一個位階。

         位階並不代表失敗與否，而是隊員們、員工們需要付出的勞力程度，大家要多拚才能達到一樣的獲利水平。我們這一隊"呱"花了非常多的時間在決定題目，大約3個小時的田野調查來打翻我們在冷氣房裡的決策。我們一直環繞著 Target Audience(TA) 的需求：

1. 大稻埕的零售
2. iBeacon
3. 需要影片
4. 需要能運作的App

我很幸運地參加到了4個學生有備而來的隊伍，因此他們的組合基本上已經符合了3,4的需求，剩下的只有題目的選定了。而題目的選定必須要在幾個小時內就能實做出來。

         題目或是產品必須要環繞在解決TA的問題，TA是最後買單的一群人。產品最後能不能獲利，並不是產品有沒有人做過，也不見得是單價過高，而是有沒有找到TA遭遇到的問題。2天的比賽題目就訂在那邊不會變。相較於開公司來說，可怕的是TA可能是會變的！我的意思不是TA本身會變，而是公司裡的人會變。因為技術達不到而變、因為預算燒光而變、因為人力而變。正是這麼多的因素會改變TA，新創公司才這麼有挑戰性....又....或者說是風險性...。

我認為一間新創公司能否抓到最準確的TA，你的員工必須是TA的一部分。