Read, Feel and Write

不做定址防禦:不判斷容器大小，直接引用例如vdData[2]=2;在前面完全沒有判斷vdData的size到底有沒有大於2。 不作指標確認：使用指標完全不判斷這指標是不是空的。 很低級的錯誤，我也常犯。但是這兩種錯誤充滿著即時行情，多到你會認為這是種風格，而不是錯誤XD。

這篇作者說他自己額外研發出的工作，常常不得公司的青睞，仔細想有幾個原因 額外做的工作為其他部門的業務。雖然他認為他開發出的功能或想法領先市場一兩年，但是卻可能影響他人的利益。 所作的方向與頂頭上司認知不同，不認為有價值。 雖說主管或許會喜歡屬下不只做分內的事，如果能更進一步做一些額外的事更好，但是從這個作者的經驗來看，就算多做也不一定是件好事！就像作者做的事，可能可以幫助其他部門增加效益，但是撈過界，這種政治不正確讓他嚐到苦頭。自己自行研發出的功能，主管沒興趣，等到市場出現類似的功能後，被人搶先商機才得見天日。這種都要靠外部的市場壓力，來弭平內部阻力的創新政策。再怎樣雄心壯志的人都會失望吧！ 之前看過google，他內部有一個創新模式，我覺得很棒，應該可以解決這些問題，google他們工程師有個很有名的20％自由運用時間，每週有20％的時間可以去做他們想做的事情，但是可以做的事情也是有限制的，他們會有一個pool，裡面放著經過認定可以做的專案，每個人都可以提出自己的創新想法，經過審核後就可以放入這個pool裡面，每個人可以依據自己的興趣選擇pool裡面的專案來做。 以我們的情形或許沒有辦法像google一樣豪氣，可以犧牲20％的產能來創新，但是不一定要花工作的時間，可以利用自己額外的時間，使用這樣的方法，我想有幾個好處。 讓想做額外研發的人，有條明確的路，不會政治不正確，至少做出的案子也是上司所認同的。 推廣創新，每個人都可以提出自己特殊的想法，不會囿於一隅，這樣的創新才會多元，不會僅受到少數幾人的影響。 做自己認為有價值的事。既然是自己選的專案，就算不是自己想出的專案，也是自己有興趣的，這樣的工作，會最讓人有生產力。 相信有很多功能是市場需要的，但是因為時程/人力需求，排不上專案時程內，但是如果工程師本身有興趣，願意花額外的時間做，或許會收到奇效。 沒時間壓力的技術評估專案可以納入此塊，讓工程師用自己的時間做評估，沒成效也無妨，不影響成本。 當然，做額外的事也應該有相對應的獎勵，管理者應依據額外專案的完成度，與功能成效給予適當的獎勵。例如多了這個功能，讓業務多賣了幾戶，那麼做此功能的工程師，是不是也可獲得部份分紅，或者此功能讓頻寬費用下降20％，這節省的費用是否可以當成紅利呢？當然獎勵的前提是把本分做好，原本做的專案不能delay，且品質在一定的等級以上，才有資格...

左聯：順勢進場，遇到回檔。 右聯：逆勢進場，給你破底。 橫批：有夠倒楣。 這是最近交易的寫照。 連續經歷兩次股災，希望有成長到。 不過這次沒有比上次椅強慘，連四根打不開的慘烈我看我在也不會買這種股票了。 不過這次也夠倒楣的，當跌破停損線，停損後，馬上拉回10%，嚴重的被耍了。 這次的失敗不堪回首，不太想寫交易價格，看了就心痛。 主要有幾個教訓， 1.大盤已經往下了，破季線了，沒什麼消息，就閃吧。 2.接完刀子，反彈後，要記得停利快閃。 3.當初的買的原因已經消失，沒漲就閃吧，不要凹啦。 4.嚴守移動停利。 5.想做波段，就不要想以做長線心態玩，會死人的。 6.到處有機會，要四處的找機會，也要衡量這個機會的風險。 7.沒有好的股票今天沒買就失去機會的，好好評估再下手。

三從一大 ，即“從嚴、從難、從實戰出發、大運動量訓練”的簡稱，是中華人民共和國競技體育的主要訓練原則之一。 form wiki 這是從小說慶餘年學到的名詞，看到與泳最近轉換跑道，突然覺得這口訣非常適合。如果我要訓練兩年前的我，我會怎麼安排，先來基本的。兩個禮拜內，寫一個小畫家。完全符合三從，因為到現在要我不看書，寫小畫家也是有點難度，然依照review制度，看code，短時間完成，以符合從嚴，當然因為GDI是即時行情的重點之一，這是從實戰來講。 再來的大運動量練習，自然是來自於大量的Debug，像這次α第一周，一個禮拜解28個bug，包含一些模擬不出的bug，保證功力大增。當然Debug的code還是得review，新人寫的code可不能check in。 我深信這是一個好用且合理的程式設計師快速養成手法。

基本上這次開發沒有加太多班，主要的原因可能是有些預估要比較花時間的部份，像右鍵選單，在後期因為繼承的方法，加快了開發速度，剛開始的時候，在開發底層報價和走勢圖的部份，花的時間比預估的長很多，一度以為並不樂觀，但是底部架構好，接下來畫面部份很快就完成了。在以後類似功能評估時，在底層應該多估一點時間，而其繼承的畫面花的時間應該也會相對少一點。這次時間較上次充裕，測試也較充足，感覺上Bug應該會比較少。這次開發也有幾項心得，依好壞種類分成二大項： 幾個常犯的開發錯誤： 修改底層類別，未檢查繼承類別的相關方法，造成繼承類別功能錯誤。這很難避免，每次都會自己提醒自己，甚至盡量繞過不要改底層類別，Bug總是在想不到的地方產生，實在想不出較有效率的解決方法，只能小心的檢查了。 依語意開發，而非自以為替換實際行為。右鍵許多功能原意等同於其相當的快捷鍵，原本的開發方法是右鍵功能同樣使用快捷鍵呼叫的方法，沒想到卻造成許多無法預期的意外，尤其是MFC MessageMap指標函式的關係，造成繼承失效。最後解決的方法還是送出postmessage，來模擬呼叫。 在可行性評估時，未了解真正的需求。現在回頭看，當初做可行性評估時，做的許多測試程式，和現在用的有很大的不同。不知是當初對需求認知有誤還是需求有改變，有很多時間浪費掉了。 不要將與其他DLL不相干的資訊紀錄在共用include檔中。之前在IMODMenu.h加入了幾個沒有要給其他DLL共用的資料，卻造成IMUI介面改變，其他所有相關的DLL都要重Build，一直到很後面才發現這個錯誤，浪費了很多時間。 記住引用其他DLL時常出現的錯誤。這次花了不少時間浪費在設定上得錯誤，一開始以為程式碼有錯，一直link不到，後來才知道setting處都沒設好，才出現這些錯誤。 測試計畫的撰寫應與開發並行，測試計畫這次是排在開發一個段落後才開始撰寫，容易造成開發途中可能想到要在什麼特殊情況下測，但是後來反而忘了測。理論上應該先應規格書寫一個初版，開發途中再改版，最後單元測試還得再改一次，這樣可能比較不容易漏東漏西。 這次用的幾個開發策略，下次可以延伸引用， 在部份大功能最後加個重構程式碼的WBS，其實重構我是邊開發邊做，不一定是整個完成才做，因為通常開發到一半，整個最適的架構已經成型了，後期也改不了多少，反而多估的WBS，在解決變動的需求或當初沒發現...

昨天下午接到一個要作投資介紹的電話，想想當時沒什麼bug，就去聽看看。下去一看，就看到兩位美女，眼睛登時亮了起來，根據判斷應該是一個老鳥帶一個菜鳥，跟我作介紹的那位美女真的很正，那天早上我還在感嘆，最近上班路途都看不到什麼美女。好久沒跟這種等級的美女談話了，感覺真的很爽，就算是被推銷也很爽。其實這分保單，很適合我，我一直想將一部分的資金丟進這種固定收益的投資裡，裡面提得利率很吸引我，當然我知道不可能年年有那麼多分紅，不過他的固定收益看起來有5%，還不錯。 其實我覺得她跟我推銷的話術，對我完全沒有用，因為從她推銷講的幾個重點，從準備退休預期資金、不受景氣循環影響的投資、此保單可隨時提領利息的優點等，其實都不是很吸引我。可是她應該看出我的眼睛充滿著微笑，沒辦法太久沒跟美女談話了，無論講什麼我都會很高興。不吸引我的原因： 從退休金額這點來說，以我的生活費計算出我的退休基金，但我的生活費實在太低了，算出來只要五百萬，她也很訝異我的生活費如此的低，其實原因在於，剛出社會的年輕人，不花這麼少怎麼存的到錢。我覺得她如果聽到我的生活費用那麼低，她應該猜得出我是單身，沒有女友要供養，花不了什麼錢，其次不應該從我現在的生活費來計算，應該以合理的費用來計算，例如從房租15000+生活費10000+醫療費5000+娛樂費5000這樣較合理一般的生活費用一個月要35000，在乘以12月然後乘以20年再乘以通貨膨脹率約1.2，所以退休金大概要1000萬以上，數字多起來是不是好一點。但其實數字的多寡都不會吸引到我，因為這不影響這項保單的本質，它能替我賺多少錢，對我而言這才是重點。 不隨景氣循環影響的投資，聽起來好像不錯，但事實上，根據這分保單三項重要利益來看，每月儲蓄利息，到期利息，分紅，除了到期利息不受景氣影響外，另外兩個其實還是受影響，儲蓄利率是隨著銀行利率變動的，這也是隨著景氣來變化的，分紅指的是富邦的投資獲益，如果富邦賺錢分紅自然多，但是景氣不好，賺的錢還有像去年那麼多嗎？終究來講，事實上只有一項不受景氣循環的影響，便是到期利息收益，這部份啊不就跟銀行定存一樣嗎？就算定存利率是浮動的，但是定存與活存的利率差不多就和這個到期率一致嗎，這利率其實隱含著通貨膨脹率啊。所以不隨景氣循環影響，再我眼裡並不成立。 可隨時提領利息，嗯這大概算第三個我記得的優點吧，其實也不是什麼優點，利息其實不多，只是...