SAIKURON 13.Ned

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，基本上不能跳著流動 ...

beingness : 對某種身分的採用或選擇。 好不容易週末有個休假，悠閒的在家裡過了一天，突然心有所感，來與大家分享一下。 上週我們一位開保時捷GT3的客人來店閒聊，聊到我想買Porsche Design的鏡框，原價台幣13XXX，他說他可以拿到很好的價錢，好到讓我馬上想請他拿，感謝他的熱心，後來我想到，請他拿鏡框他會不會留一筆佣金？雖然這並不重要，因為我還是能拿到比市面上便宜很多的價錢，後來我想了想，他應該連1元也不會留，他開價值快一千萬的GT3，年收人逼近一千萬，幫忙拿鏡框又不是他的本業，只是純粹朋友之間的幫忙，拿了反而降低他自己的格調，因為他的beingness是有千萬價值的專業經理人。 常聽到同事幫客人拿一些汽車相關的配件，進價五百，報客人一千，進價五千，報客人八千，全車拉桿，進價一萬五，報客人兩萬五，貼隔熱紙一萬五，報客人兩萬五，有些人連幫忙朋友與親戚都要抽一大筆，幫忙拿配件抽佣金，這樣作並沒有什麼不對，只是抽佣金也要看程度，當業務沒有創造足夠的價值時，抽這麼多會造成一種狀況，就是當付錢的人知道他買東西被業務海削一筆，他會不再相信這個業務，這也是一般人對汽車業務的看法，不老實，無所不用其極想向客人A錢。常常聽這些人在嘴邊掛著，賣車都沒賺錢，所以賺取一些配件的差價來貼補，重點來了，因為他認為自己的beingness是很難賺錢的業務，所以一定要賺取這些配件的差價來過活。各位看倌看出差異了嗎？ 當一個人採用千萬價值的經理人的beingness時，那個人就會作千萬價值經理人會作的事，所以那個人會ㄧ直是千萬價值的經理人。 當一個人採用四處撈油水賺錢業務的beingness時，那個人會覺得一定要多撈一些，所以那個人會是一直需要四處撈油水才能賺錢的業務。 由此可看出一個人的想法決定他採用的beingness，一個人採用的beingness決定他的成就有多大。 我會採用頂尖銷售員的beingness，你呢？

話說下午正準備打電話給客人時，明知客人目前買車不急，也知道不能一直聊車子的話題，畢竟不是每個人都對車經很有興趣，但是不打又不行，要跟客人建立ARC就靠不斷的接觸與聯絡，突然一個想法就蹦了出來，ARC三角形不知道聽了數千數萬遍，A是親和力，R是真實性，C是溝通，那我打電話過去就先禮貌的問候＋溫和的聲音來個A，然後再談客人相關的事物(工作，家庭，小孩，娛樂，興趣)，再加上完整的溝通週期來獲得C，ARC就建立起來啦！阿我不就已經在雪梨學過很多遍，本來就知道啦！至於有哪些R可以談，那就靠對客人提出問題就可以知道可以用什麼來當作R，雖然有時問題好像有些唐突，只要保持很好的A，那對方的反應也不會差到哪去。 馬上打個幾個客人，果然談得很順，哈哈，事情就是那麼簡單，今天才在大會演講聽到一句話，不溝通就會形成質量留在心靈裡，所以把對客人的想法溝通出來果然就輕鬆許多囉！有話就說，這種感覺真好！ 車經：有關於汽車的所有話題，包含性能，品牌，小道消息等等。