SAIKURON 13.Ned

來源： http://paulhammant.com/blog/branch_by_abstraction.html 接下來就看看Branch By Abstraction有多厲害，實際看下來，的確是一套很有用的方法，簡單來說，就是把整合的工分散到每日的開發中。但是要實行有一些現實的問題需要克服 當我要新加一個Feature，會改動3個Class，這3個Class可能所有Module都要參考，而且與其它Module的Code綁很緊，要抽成Abstraction要改動的地方也是會很多，根本就是翻了。 就算我做好抽象層，把所有Module參考到這三個Class的地方改為呼叫抽象層，這樣還是對Code有變動，也是有可能對產品造成衝擊。 如果這3個Class的修改連介面都換掉，整個Class改頭換面，煥然一新，原來的使用流程已經不在，就算有抽象層當緩衝，還是免不了對產品造成衝擊。 這些現實的問題，我想是可以克服的，第一就是要有完整的Test，Unit Test，Integration Test，UI Test，但是如果Test不夠完整，可以使用這招嗎？我想答案是肯定的，但是要邊做邊補Test。而沒有任何Feature Branch，大家都只看Trunk，也就是mainline，這件事對目前的我而言，簡直就是美麗的夢境！我自己參與的產品就有遇到這種狀況，目前是分支一個Branch來做，如果用Branch By Abstraction，新的東西就可以不用等好幾個版本之後才進mainline，也不用擔心如果合併回mainline，到底會是怎麼樣的地獄。如果我有機會參與決策，我一定直接就這麼搞。 另一點作者提到除了Release之外，完全沒有其它Branch，這點我還是有點存疑，除非有一套機制讓Developer拿著Commit去取得認證，保證不會Break掉任何東西。不然Developer自己一個人做測試還是有限，如何保證不Break mainline？如果一個產品的開發編制如下： 100個Developer 分成15個Team，有的Team人多，有的Team人少 25個Component，從Web UI，Mobile UI，Database，Domain，Infranstructure..... 有跨Component，跨Team修...

原文：  http://paulhammant.com/2013/04/05/what-is-trunk-based-development/   讀過了Perforce官方的mainline model的文件，又看到Google與Facebook都使用TBD，以及我自己在開發上遇到的問題，讓我想看看TBD到底如何可以幫助我們解決這些工程上的問題，看起來作者非常反對feature branch，而我自己親身經歷的感受也的確，要開feature branch，除非能做到Perforce官方推薦的經營方式，不然不只Merge會有災難，開發時也是災難連連。以人性角度來說，假設我做componentA，如果有10個feature branch都有componentA，那每個branch有問題我都要去看，我修了一個componentA的問題，由於每個branch分支出去的時間點不同，其它branch有的可能有，有的可能沒有這個問題，那我怎辦，只能等著人家來報問題，那我的時間很多都花在解這些Branch的問題上。如果採用的是TBD的概念，我只要保證trunk沒問題就可以了。或許在code撰寫方式上需要花很多工，但是我只需一次工，也可以將焦點集中在一個地方。對於我這種普通人，這是比較人性化的工作方式。 甚麼是TBD 一個軟體開發的分支模型，也被稱作mainline 同一個產品開發的所有人員共享一個Repository，有一個trunk，單一Developer或是Developer團隊可以有自己的private branch，所有修改最後都會回到主幹 只有在Release時才會有官方的分支，一般Developer不能對Release Branch作動作，只有Release Engineer可以更動Release Branch，當Release Branch完成它的任務，就會被砍掉。 Google與Facebook都採用這種分支模型 有需要Release才Branch Release之後的branch，就不會有大的更動，只有Release Engineer會進行將挑選Commit合併到Release Branch的動作 多一個Release Engineer的帽子 Bug先在trunk修好，之後把Commit合...

http://www.infoq.com/minibooks/domain-driven-design-quickly 什麼是DDD 參與角色：Domain Expert，Analyst，Developer 產品：Domain Model，Software Design Domain：一個會實際存在，被使用的系統。不同的系統有不同的運作邏輯、流程、資料。也是軟體要幫助的對象。Ex：銀行、書籍管理、進銷貨、股票交易，電信，這些是原來就有系統存在，軟體可以幫助這些系統運行。而像是遊戲、作業系統、這些原來沒有存在的系統，軟體就是把系統行為建構起來的基本組件。 Model：把實際存在，運作的事物抽象化就是Model，Ex：經濟模型、數學模型、物理模型...等，Model不是一個特定的圖，Model是一個idea，Model不只是Domain專家的知識，Model是一個嚴格組織與挑選過的，對於Domain專家的知識的抽象化。Model可以用圖來表示，可以用code來表示，可以用文字來描述。對於開發人員而言，Model就代表Domain。 Software Develop花太多的時間在code上，他們認為軟體就只是Object與Method。 建立Model的最主要目的，就是要拿來溝通。 Software Design可以說是整間房子的藍圖，Code Design算是實際蓋房子的方法。 Design Pattern就是Code design的一種方法 Waterfall的缺點就是作到最後沒人敢動 Agile的方式的缺點就是一開始沒有作周詳的設計 To be or not to be? Domain專家講的一定都對？No，Domain專家的語言不見得可以直接拿來做軟體，所以要問清楚，再作Modeling，Model也會不斷做修改。 DDD的目標就是透過與Domain專家溝通，作對應Domain的Mode，再根據Model，來作出Software Design，讓Design可以與Domain對應，而且讓參與製作產品的所有人，都可以透過Model這個共通的語言來溝通 The Ubiquitous Language Software developers腦袋裡面裝的就是Classes，Methods，演算法，Pa...

Asset Bundle工作流程及人物換裝實例 - 劉剛 Unity內部的資源有兩種(斯斯有兩種?)： Resources：有10年歷史，儘量用Asset Bundle Asset Bundle：暱稱AB，現今Unity處理資源的中心 AB選項的差異 透過Web Player下載Asset Bundle的Cache需要收費，在iOS，Android的Cache不需收費。--->手持遊戲卯起來用!!! 瀏覽器本身也有Cache，為什麼要用Unity的Cache？ 因為存在Cache裡面是解壓狀態，下次調用不需再解壓一次，大省CPU時間。 Unity會管理Cache大小，壓縮檔案解壓後會丟掉。 Browser就只能存壓縮狀態的Asset Bundle，而且位置每種Browser都不同。-->有付錢有差 AssetBundle.CreateFromMemory：大多數用在對內容作加解密，無法Cache，也就是每次執行都要下載一次，Script也可加密 AssetBundle.CreateFromFile AssetBundle.Load與Application.Load的差異，Application.Load只能Load StreamAsset裡面的東西。 每開一個www用來下載AssetBundle，就要用掉8MB的Buffer，所以www下載完要作以下動作來清掉那8M： WWW.Dispose AssetBundle.Unload(false) Resources.UnloadUnusedAssets AssetBundle可以作Dependency!!! BuildPipeline.PushAssetDependencies，把資源推進去 BuildPipelinePopAssetDependencies，把資源彈出來 假設Push以下資源：A，B，C，透過Push&Pop，可以產生3個Packege，C依賴B，A，B依賴A，A獨立的Asset Bundles，完全不會重複包資源！ 在一個Prefab裡面會有Mesh，Material，Shader，Texture，Script，都應該分開包，Load的時候再按照順序Load回來，再配合上Cache機制，已經下載過的Asset...

http://www.csdn.net/article/2013-09-03/2816811-Agile-development-JIRA-Atlassian X的，這篇真的太妙了，JIRA不過是一個isssue tracking system，扯到敏捷很合理，因為JIRA內含可以執行敏捷流程的設計，不過扯到李小龍，還真是拉的非常遠！不過講的其實很有道理~ When one has no form, one can be all forms; When one has no style, he can fit in any style. 無招勝有招、這不是說不用去學招式，而是學了招式要體會它的意義，不要被招式所侷限。所謂設計範式與一些程式技巧就是我們搞軟體的招式吧，當學了夠多招，而且體會它的意義的時候，就不會拘泥於用哪一招，雖然很難想像寫code時像水一樣變幻自在的感覺，不過聽起來蠻有道理的！菜鳥如我，透過這段話至少知道如果學的招在戰鬥時沒辦法使用，就爽快的不要用吧！ All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns. Scrum、XP、Lean、RUP是軟體開發的戰略Pattern、Design Pattern是軟體開發的戰術Pattern、Refactor，Language最佳語法是軟體開發的接近戰Pattern，不同領域都有不同的Pattern，每個都有它的界限，真正使用起來，限制還不小，那要學嗎？學！當我們進到Pattern裡的時候，才有機會看到Pattern外面的The Truth！ If you spend too much time thinking about a thing, you'll never get it done. 需要想很多的複雜方案，直接就送去領便當！附帶一提，看到這句話，讓我困擾多月的問題得到了一個清晰的答案！搞軟工與寫程式也是一樣，如果要弄一個遙遙無期的架構，不如以一個可接受的形式先把User Story作出來，把bug處理掉才是王道，再不行，把User處理掉，那就是霸道！不管是王道還是霸道，就是要簡單~ Make at least one de...

看到浪潮之巔裡面敘述Google對人才的需求標準，一流的工程師能作10個二流工程師的事情，二流工程師能作10個三流工程師的事情，也就是說，一個一流工程師可以作100個三流工程師的事情，更重要的是，三個臭皮匠勝不過一個諸葛亮，根據一直工作到現在的經驗，我自己證實這是真的，那我在哪一流呢，所以有了以下分析。 不入流的工程師：連自己遇到的問題都沒辦法好好解決，只能作一些日常維護或簡單開發工作。剛出社會， 或是出社會很久但是都作不好的人。 三流的工程師：可以處理自己遇到的問題，但是不想，或是沒有能力，持續讓自己的能力或是開發的系統成長進步。我看到大部份的工程師都屬這類，會抱怨，但不主動學新東西，會有一些想要進步的想法，但是礙於自己的技術與堅持不夠，能作到的有限。 二流的工程師：能夠持續的進步，學習新技術，不斷的改善自己開發維護的系統，應用新技術或新觀念到自己的架構上。我以及在Ruckus的工程師大部分就屬於這個區間，可以積極的學習與使用各式各樣的技術來處理問題，而且可以規劃比較完善的架構，但英文好不好還是會有一個程度上的差異。 一流的工程師：自己就可以作新的技術，新的框架，新的標準，環境沒有就生一個出來。能夠主導大型Open Source專案的人，或是在各公司主導規劃架構，設計創造新架構的人。 頂尖的工程師：進Google，Microsoft，Blizzard，等世界級軟體公司。或是創造能夠影響地球的系統。大師級人物，不用多說，能處理很低階的系統細節，也能開發改變世界的系統，或是寫出可以成為人類進步基石的演算法。 今生今世，或許沒辦法到頂尖，一流也應該沒問題吧！話說回來，其實第幾流好像也不重要，不過是拿來茶餘飯後閒聊一下，能夠幫助自己的公司，作出叫好又叫座的產品，才是最重要的目標！

distributed even if your workflow isnt distributed is the new centralized. Git靠在檔案裡面記錄的內容來維護自己的狀態，Daemon看使用者的位置在哪個容器，就對哪個容器作事情。 目錄名稱有.git就是裸容器 用檔案內容經過SHA1產生唯一ID，長度為160bit，只需比對ID，就可得知檔案是否相同 用ID的前16bit做目錄名稱分配，避免同一目錄檔案過多，造成效能低下。 160bit的SHA1 ID不只用在內容，Git內部的資料結構，全部都使用SHA1，blob，tree，commit，tag，全部都有自己的SHA1 ID。架構簡潔，容易了解。 整個系統的資料結構，只有blob、tree、commit、tag，非常簡單。 同一個檔案，如果做了更動，ID就會不同，也會將內容存成一個新的blob，相較於其他SCM是記錄檔案變動，較耗空間。所帶來的好處更多? 不以檔案系統的檔名與路徑來決定內部管理資料結構，避免與檔案系統內容綁死，像是改名，追蹤歷史，都以ID來判斷。 只要檔案內容不改變，不管是更名，分支，搬移，複製，全部都不需要再多一份檔案。 透過維護Tree Object把所有git相關設定放在容器根目錄底下，避免四散設定檔 沒有所謂daemon或是Servcie，全部都是有需要才執行功能，功能執行根據容器的內容來處理。這樣省記憶體，省CPU時間。 本來想說要是檔案有好幾百萬，那光是開個tree就會很耗記憶體，搜尋與比對檔案內容是否相同，也非常花時間。Git的tree裡面可以有tree，所以tree裡面的內容會因檔案的樹狀結構而分散，除非極端的狀況，同一個目錄就幾百萬個檔案，不然一般的使用狀況，tree檔案的內容應該都很小。 是不是多個專案都應該放在一個容器裡面？在Ruckus用Perforce是這麼做，在網龍用Subversion是分開，在Git裡面應該是?因為在Git裡面的branch都是以容器為單位，commit物件也是追蹤容器，所以如果多個專案在同一個repository內，沒有辦法區分出各專案的歷史。而Perforce與Subversion都是以檔案為單位，可以用資料夾來區分歷史，所以可以把多個Project放在同一個Repositor...