SAIKURON 13.Ned

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...

描述軟體開發的理想世界 在理想世界我們只有一個版本，沒有bug，有足夠的時間開發，開發不會延遲。但是現實世界並非如此，所以我們有了軟體版本控制系統，我們有了分支。 限制分支的數量，把分支看成一個一個stage(development、QA、Beta test、Live)，來處理短周期Release，避免分支過多，不管Release再怎麼短，Release Branch只會有三個(所以並不會限定development branch)，這個作法稱為staging codeline。 從mainline中分支出development分支，來處理不同開發者，不同團隊開發延遲或是錯誤的程式碼造成無法Release的問題 除非開發者的成果可以正常編譯且功能正常，否則不會進mainline，達成mainline可以維持在理想狀態不斷前進 用Map(地圖)、Protocols(協定)、Convention(公約)、Etiquette(禮讓)來讓Branch可以被管理， Ex：道路 codeline=觀念 branch=實作 codeline分支出來的起源稱為baseline 沒有baseline就稱為mainline aka=also known as tofu scale：越上面越硬(可測試，接近Release，也就是穩定)，越下面越軟(不穩定，離Release遠)，這個等級代表改變codeline的風險程度。mainline在中間的位置，每個codeline的tofu scale相對於mainline，注意：親子codeline可以表示相對硬度，兄弟codeline只能跟baseline比較 staging codeline與tofu scale在mainline上合體，形成可以兼顧Release與development的分支策略 以map方式表達分支狀態，處理兄弟codeline表示的問題，表達Change該如何流動 使用Change Flow的策略，完成把所有Change Flow全部匯流到mainline的理想，所以mainline只會穩定的成長 Change Flow只能在codeline與它的baseline之間流動，所以一個codeline的改變只能流到baseline，基本上不能跳著流動 ...