codemonkey

http://www.playcodemonkey.com/

fMBT project

https://01.org/zh/fmbt/documentation/fmbt-documentation

[轉] 神奇畫線數學

http://goo.gl/J1bqot

WEK資源 / WEKA references

WEKA資源:

l   http://supercharles888.blog.51cto.com/609344/1358756

l   http://ithelp.ithome.com.tw/profile/share?id=20083470

l   http://mooc.guokr.com/course/939/Data-Mining-with-Weka/

l   http://www.cnblogs.com/htynkn/archive/2012/03/29/weka_1.html

l   http://www.dotblogs.com.tw/k458850/archive/2014/01/14/140037.aspx

l   http://www.ibm.com/developerworks/cn/opensource/os-weka1/

l   http://www.ibm.com/developerworks/cn/opensource/os-weka2/

l   http://33tsai.blogspot.tw/2008/03/weka.html

l   http://123android.blogspot.tw/2011/12/weka.html

l   http://120.105.184.250/lwcheng/data_mining/data_mining_tools/ExplorerGuide-3.5.5_zh_tw.pdfhttp://www.slideshare.net/butest/weka-tutorial?next_slideshow=1

l    

關於 Ailge 軟體開發流程的疑惑

感覺又是個換湯不換藥的學術口號

撇開所謂的傳統軟體開發流程，一樣都是人、事、物

只是重心不同、比例不同、名稱不同
Product backlog -> Sprint backlog (Stories) -> Task -> Task board 
(Requirement / Spec -> R&R / Break down / Schedule -> Task / Subtask / Task management system)

頂多是讓部分流程重疊，達到部分加速的效果，但 side effect 有多少卻不知道
因為這世界上不是只有軟體行業，跨單位、跨領域、跨功能的任務，Agile 如何應付?
再來一個新人，加入新的元素，又可以定義出新的架構或流程
以一個 PM / 老闆的傳統思維，用原本的方式進行 Agile，徒增痛苦而已
再來一個 Sprint 中不能變更需求，在某些公司這是天大的笑話。 
誰要當豬? 誰要當雞? 當雞過勞了，錢還是讓豬在領

唯一稍微可以看的就是 Swimlane 的 Task board
一直強調"傳統軟體開發"，根本是個幌子。人的智慧和經驗是會累進改變的，團隊與專案發展的方式，不會完全照著所謂的"傳統軟體開發流程"去走，Agile 只不過是自然的演變 + 名詞定義。用最簡單的 PDCA 就可以解釋 event cycle

Stand up meeting 並不是敏捷測試特有的方式，其他非軟體產業一樣也有相同的方法

除非明確從 Agile 方法得到好處，大幅縮短開發時間與提升成果品質

要不然根本沒什麼特點

如果能大幅得到好處，也代表這單位之前的流程、概念、方法、技能也太爛了吧

好比說畫圖，Agile 只是再去定義哪個配色成分要多少、油畫筆刷要多粗、水彩畫筆刷要多粗、什麼顏色要刷幾次...知識這東西，是一個過程、一個方法、一個價值，Agile 只不過是針對這個知識作取樣和量化，沒什麼差別

另外 Agile 對系統測試部分似乎沒有明確的定義，而且不同產業測試的方法也不同

不可能全部自動化，假想提出這套想法的，應該比較合適於 Web 和網路系統的人
另外也甚少看到大家討論 Issue / Bug 在 Agile 流程中的處置

Agile 四個核心，可以假想就是創始者碰到的困境，所以才針對這四項提出 Agile核心價值。

1. 個人與互動: 這是人的問題。也是管理的問題。程式開發模組跟模組間、開發與測試間、上游與下游、研發與製造、etc. 所以強調這點毫無意義，因為這是整個過程中，本來就應該處理與解決。

2.  交付可行軟體: Agile 若沒有一個系統架構師，依照短周期開發的精神，很容易造出歪離規格的產品。雖然可以透過 requirement 與開會來修正。正本溯源，根本就是 requirement 不明確造成的問題。另外你會拿 source code 給老闆和客人說，這就是我的技術文件嗎? 我想被丟去 ISIS 捅屁屁比較快。

3. 客戶合作: 這個沒救。有錢就是大佬的暴發戶精神是不可能被消滅的，永遠被教導客戶至上，根本就不在同一個討論基準點。

4. 隨著變化做出反應: 這叫勞民傷財。一週一build已經夠累了，現在是一天一build，若一天數build，請問誰要累死

在台灣不同工同酬的壓榨體制內，換個 Agile 不過就是代表繼續用低薪，壓榨出員工更大的產值，老闆利潤 double，員工一無所獲。員工不是電腦，不是靠個 cloud computing / Virtualization / Grid computing 就可以無限制的持續並行付出

Agile 提倡的精神是以人為本，說到底，還是拼命的去完成任務，哪裡以人為本?
Agile 的 PO 決定優先權，團隊決定工作時間，在台灣能嗎? 老闆一句話勝過一切，老闆的爽度決定一切，更慘的是，老闆若一切以客戶為尊，我看也不用 Agile 了，不管做什麼東西，最好就是一個月完成，喔不，最好是 1us 就能產出一個產品是最棒的

[轉] inside - Infographic

http://www.inside.com.tw/2011/04/29/infographic-how-to

Scrum study

Product

Project

Backlog (Activity, Requirement)

Sprint (Status, Priority)

Story (Task)

Task (Sub-Task)

 

Dashboard (Main page)

Kanban (Statistic page)

Chart (Burnup, Burndown, Lead time, Hours, Points, History, Timeline, Cumulative, Stacked)

Epic story

Iteration plan

Planning Poker

Swimlanes (Story vs Sprint)

 

 

Nice Tools:

         ScrumDo

         iceScrum