成就更好的自己 (Page 5)

成就更好的自己

Sign in Subscribe

成為更好的 DApp 平台，EOS 也許還有一段路要走

Source: http://labs.eostitan.com/#/resources/?resource=cpu&period=72&n=1 2018年10月17日，EOS 的 CPU 危機爆發：普通用戶無法進行轉賬操作，甚至連賬號本身都失活，需要「充值重啓」；而大量 DApps 也不得不「關閉運行」來避免CPU資源緊缺之下的雪崩。當初以「快」出名的EOS，終於「癱」的比以太坊還嚴重。不需要礦工費的「免費」EOS，營造了 DApp 生態大爆發的假象，只是當抵押 2000 個EOS僅僅能換回1.3秒的CPU後，無 CPU 可用，或者說用不起，成為了普通人在這場遊戲中，遇到再一次的難堪。

寫在交易所上線之後

轉換跑道滿兩個月了，交易所也在最近上線，藉機說說自己這段時間的工作感想。我想從我個人一直以來推崇的文化/精神說起： 1. Freedom and Responsibility 自由與責任就是太極的陰與陽，如果沒有責任心，那自然而然的就會有更多的規定來約束你；反之，團隊重視的是產出，捨棄繁文縟節來約束你的自由。大家是為了總冠軍而聚在一起的，在 COBINHOOD，同事間的相處更像是隊友，每個人清楚地知道自己在球場上應該扮演的是什麼角色，防守出現漏洞就盡可能的快速補位；不應該是家人關係，家人是那些你必須不求回報付出幫助的人。 2. Talk is Cheap. Show me the Code. 不斷地無意義開會容易淪為空談，我們不是思想家或是哲學家，我們是實幹家，面對任何質疑就是透過實證支持你的論點，不看苦勞而看功勞，任何無法落實到程式碼上的想法都是空談。每個人都需要捲起袖子，弄髒雙手。每次的進攻，持球者可以自己做出正確的判斷，而不只是依賴教練給的戰術指示，避免了時間不浪費在無效的會議之上。 3. Move Fast and Break Things.

Wi-Fi NAN：鄰近感知網路

Wi-Fi NAN：鄰近感知網路

有幸在 2014 年五月份時候，代表瑞昱參加 Wi-Fi NAN 協定的開發，規格書與相關與 API 如今也已公開於世，藉由這次 Android O 發佈 Wi-Fi NAN 的這次機會，來複習整理我的陳舊記憶。時隔三年多，Wi-Fi NAN 在 Android 8.0 初登場 2017/08/21 Google 發佈 Android 8.0（Oreo），除了對使用者比較有感的改動（如： picture-in-picture）之外，底層的新功能也不少，無線鄰近感知網路就是其中之一。無線鄰近感知網路，規格中的全稱是 Wi-Fi Neighborhood Aware Networking（NAN），後來

iPad Pro 的七天，失敗

五年前 iPad 剛面世不久的時候看過一系列文章[1][2]，不受地點的工作與生活方式令人神往，當時買了 iPad 就嘗試跟他做一樣的配置，試著用與他相同的方式旅居世界各地寫程式，多麼美好的生活！嘗試了一段時間，最後放棄的主要原因是遠端 VPS 的響應速度跟本機落差太大，次要原因則是因為工作地點還是固定的，沒有足夠吸引人的理由讓我只透過 iPad 而不是 Macbook 工作。不過從智慧型手持裝置面世之後，Thin Client 的概念依然埋藏在我心底深處，直到我電腦壞掉的這天... [1] http://yieldthought.com/post/12239282034/swapped-my-macbook-for-an-ipad [2] http://yieldthought.com/post/31857050698/ipad-linode-1-year-later 五年後的今天，iPad 硬體規格升級了，也有了更輕便的實體鍵盤，比起藍牙鍵盤反應更快、更方便攜帶，也沒有電力問題；隨著 Office 移植到

寫在中國宣判 ICO 死刑之後

寫在中國宣判 ICO 死刑之後

ICO 亂象就在 2017 年 9 月 4 日下午三點，由中國人民銀行聯合中央網信辦、工業和信息化部、工商總局、銀監會、證監會、保監會，共七個部會在官網上發佈了「關於防範代幣發行融資風險的公告」，宣判了 ICO 的死刑。這段時間區塊鏈（尤其是 ICO）的發展非常有趣，未來可能再也看不到這般 ICO 榮景，作為記錄，我將之前我所見的 ICO 亂象整理在以下投影片，不在文章中贅述。 ICO 亂象 from 曜瑋歐發行中與已完成的 ICO 無一倖免代币发行融资是指融资主体通过代币的违规发售、流通，向投资者筹集比特币、以太币等所谓“虚拟货币”，本质上是一种未经批准非法公开融资的行为，涉嫌非法发售代币票券、非法发行证券以及非法集资、金融诈骗、传销等违法犯罪活动。

繼雲計算之後，霧計算再起 - 談談 P2P CDN

繼雲計算之後，霧計算再起 - 談談 P2P CDN

（Photo Credit: https://www.polarising.com/fog-computing/) 雲漂浮在天空之上，霧則更貼近地面，透過這種十分形象的名稱，霧計算（Fog Computing）將數據、（數據）處理和應用程式集中在網路邊緣的設備中，而不是幾乎全部保存在雲中。這意味著計算從距離用戶較遠的數據中心（雲）拉回到了你我身邊的設備（霧），也可以是頻寬你正使用的電腦。霧計算，是雲計算的延伸概念，也被稱為邊緣計算（Edge Computing），此名詞由 Cisco 首創。霧計算 = 去中心化的分散式計算霧計算可以理解為新一代的分散式計算，使網際網路的計算模式從中心化遷移至去中心化。霧計算延伸並擴大了雲計算的網路計算模式，將網路計算從網路中心擴展到了網路邊緣，從而更加廣泛地應用於各種服務。霧計算有幾個明顯特徵：低延時和位置感知，更為廣泛的地理分佈，適應移動應用。註：霧計算是個新名詞卻不是個新概念，在過去這概念被人稱作： * P2P ad-hoc networking * Grid Computing * Mesh

[讀書筆記] 誰在團隊搞破壞

破壞什麼？理想中的團隊要快速做出決策，在有限的時間內高效率地完成工作。而團隊的破壞者指的是干擾團隊運作、浪費工時、降低效率的那些人。在《誰在團隊搞破壞》一書中，條列了團隊的八種破壞者： 1. 凡事都要問主管：堅持每件事都必須經過正式管道請示，決不允許為了迅速執行決策而抄捷徑 2. 長篇大論話當年：發表演說，毫不遲疑提出適當的愛國言論。一有機會就滔滔不絕、長篇大論，用冗長的故事與個人經驗來闡述重點。 3. 每次都說再討論：盡可能把所有事都推給委員會，進一步研議與考量。並試圖壯大委員會，規模絕不少於五人。 4. 東拉西扯沒重點：抓到時機就馬上提出毫不相干的議題。 5. 斤斤計較幾個字：對訊息、會議記錄或決議的用字遣詞爭論不休。 6. 決定之後又重來：重新提起上次會議中的決議，企圖對之前的決議是否明智進行翻案。 7. 過度謹慎怕犯錯：講道理，也要求團隊成員講道理。提倡謹慎，唯恐因倉促而造成日後的難堪與爭執。 8. 遲遲無法做決定：擔心任何決策的正當性。質疑深思熟慮後的行動是否合乎權限，是否會與某個更高階層的政策相抵觸。培養低破壞文化的四個重點

持續集成的實踐：基於容器的微服務架構設計

持續集成的實踐：基於容器的微服務架構設計

（同步發表於 Cepave Blog）敏捷開發關鍵的一環：持續集成隨著軟體開發複雜度的不斷提高，團隊開發成員間如何更好地協同工作以確保軟體開發的質量已經慢慢成為開發過程中不可迴避的問題。尤其是近些年來，敏捷軟體開發逐漸成為顯學，如何能在不斷變化的需求中快速適應和保證軟體質量顯得尤其重要。持續集成（Continuous Integration）作為敏捷開發重要的一步，其目的在於讓產品快速迭代的同時，盡可能保持高質量。每一次程式碼更新，都要通過自動化測試來檢測程式碼和功能的正確性，只有通過自動測試的程式碼才能進行後續的交付和部署。它倡導團隊開發成員必須經常集成他們的工作，甚至每天都可能發生多次。而每次集成都是通過自動化的構建來驗證，包括自動編譯和測試，從而盡快地發現集成錯誤，讓團隊能夠更快的開發產品。持續集成的特點 * 週期性的自動化過程: 從拉取程式碼、編譯構建、運行測試、結果記錄、到測試統計 * 需要有專門的集成伺服器來執行集成構建，常見的如：Jenkins, Travis CI * 需要有程式碼托管工具支持，如：Git, SVN 持續

Excel, SpreadSheet 試算表中的 Evaluation 實現方式

儲存格 Evaluation 的使用情境自己的記帳習慣，為了能清楚記錄費用明細又不需要在備註上面打太多字，我通常不會直接在 Excel 記上最終的消費金額，而是記錄算式搭配簡單的說明。像是以下兩種情境： 1. 匯款花了台幣 1014 元。如果直接寫 1014 元我事後無從得知這筆費用是否包含手續費。而如果寫的是 1000+14 很清楚地知道這筆費用已涵蓋了手續費。 2. 出差花了人民幣 100 元。如果寫的是 100*4.89，我們就可以很清楚看出當日匯率是 4.89，花的是人民幣不是台幣。 Excel 是支援儲存格內運算的，不過必須填入 =1000+14 而不是 1000+14。這樣的寫法就會讓算式不可讀，只剩下運算後的結果，每筆費用明細需要到各自的儲存格才能查看。若能有公式幫忙做 Evaluation 同時顯示消費明細並且自動計算得出運算結果，可以大大提升記帳的效率，也不需要在備註中寫太多冗餘的文字。按照這樣的思路尋找解決方法，

以 Docker for Mac 搭建開發環境

以 Docker for Mac 搭建開發環境

以前 Mac 上的 Docker 之前 Docker 就可以在 MAC 上面使用，但是實在太麻煩了，需要安裝 Boot2Docker, VirtualBox, Docker-Toolbox，實際上的體驗也遠不如 Linux 版本的。如：每次重開機都需要執行以下命令，啟動也很花時間，在開發過程中，IP 需要透過 docker-machine 查詢，使用 Docker 開發失去了很多彈性： docker-machine start default eval $(docker-machine env default) Vagrant 的虛擬網路也因為如此，後來我改用了 Vagrant 作為開發環境。Vagrant 中的 private_network 可以讓 VM 中的網路環境與外部隔離，再也不需要預先決定好端口的映射關係，也不需要擔心端口被佔用的問題。

將部落格從 WordPress 遷移到 Ghost

寫習慣 Markdown 之後，WordPress 對於現在的我來說已經過於臃腫了，即便有外掛可以支援 Markdown，非原生的體驗還是有差。資料的備份與網站的管理也造成了我不小的負擔，隨著工作佔用的時間越來越多，部落格還是維持簡單就好。因此下定決心把用了很久的 Dreamhost WordPress 搬到自己的 VPS 上面維護。過程有點繁瑣，順手記錄下來，希望可以幫到有同樣需求的人。安裝 Ghost Ubuntu 安裝步驟如下： curl -L https://ghost.org/zip/ghost-latest.zip -o ghost.zip wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.31.1/install.sh | bash nvm

為什麼他們最後決定改用 Go 重寫了？

（同步發表於 Cepave）現今這個時代的網站已經很少單純只用 HTML 完成，為了處理動態資料，除了前端的展現，我們還需要由後端幫忙處理資料，目前主流的網頁語言與框架有： * PHP – Laravel * Python – Django/Flask/Falcon * Ruby – RoR * Node.js – Express/Salt * Go – Beego 沒有一個框架是完美的。但是我們可以發現有越來越多的人/公司逐漸選擇向 Go 靠攏： * From Python to Go: migrating our entire API * How We Moved Our API From Ruby to Go and Saved Our Sanity * Farewell

以 Go 語言快速實作 HTTP GET/POST API

(同步發表於 Cepave) 維基百科中提到：目前在三種主流的Web服務實現方案中，因為REST模式與複雜的SOAP和XML-RPC相比更加簡潔，越來越多的web服務開始採用REST風格設計和實現。 … 符合 REST 設計風格的 Web API 稱為 RESTful API。它從以下三個方面資源進行定義：直觀簡短的資源地址、傳輸的資源、對資源的操作。那麼我們要如何使用 Go 語言原生的函式庫建立簡單的 Web Server 提供 GET/POST 接口呢？讓我們透過 Hello World 的範例來說明。建立 HTTP Server 接收請求 1. 透過 http.HandleFunc("/", callback)，我們可以定義 callback 函式所要負責的 URI。 2. 呼叫 http.Request.

RenderScript 之外的另一個選擇：FilterScript

快速複習，RenderScript 是什麼？想了解細節可以回顧一下以前的文章。簡單來說，RenderScript（以下簡稱 RS）的作用就如同 OpenCL 一樣，是個可以同時處理計算與繪圖的程式語言。差別在於 RenderScript 是 Android 獨有的，OpenCL 卻與 OS 無相關，根據 PowerVR 的說法，OpenCL 要針對一個新的硬體新增 API 相當不容易，得透過各軟硬體的供應上同意並且投票通過才可以進行。反之，Google 身為純軟體公司的角色就比較中立，目標只有設法減輕應用程式開發者的負擔，所以可以快速地針對各硬體廠商的需求做出反應。 RenderScript 不夠好嗎？ The initial top-down approach has led to some confusion among developers regarding the level

來看看那些令人稱羨的企業文化與員工福利

尊重研發人員的企業文化？從一間公司的環境，我們大概就可以推測這間公司的企業文化、以及對於人才的重視程度。舉例來說，到了一間生產線旁辦公室，我們可以預期在這邊工作就是要確保生產線上不出差錯，產品可以順利生產；到了傳統的辦公大樓中，伴隨高高的隔板、獨立的主管辦公室與停車位，我們可以想像這裡是階級化管理的組織，要當的是謹守本分的螺絲釘。這篇文章中也提供了三個不錯的指標以判斷一間公司是否尊重工程師文化？ 1. **公司的決策流程？**欲開發的產品以及開發週期是大家說了才算，而非少數人可以任意決定的。 2. **是否尊重軟體開發文化？**有時候寫程式是需要天時地利人和的，時間很難估算。這一點必須被理解。 3. **是否重視基礎設施？**高生產力來自於優良的基礎設施（如：程式碼架構、通訊/編譯/測試/佈署系統)，但這些與產品相比之下，常常容易被認為是不必要且可忽略的。讓你感覺不像在工作的工作環境提到令人稱羨的員工福利，多數人第一時間可能會想到 Google, Facebook, 等公認有著最佳工作環境的大公司(註)。不過也不是只有矽谷的網路公司一支

Python 函式的參數傳遞方式：Passed by assignment

典型的參數傳遞方式有二種： * Pass-by-value: 複製參數的值傳入，所以原參數內容不會被影響。 * Pass-by-reference: 傳入參數的參考，會影響原參數內容。還有少數程式語言使用以下兩種傳遞方式： * Pass-by-name: 將傳入的參數視為變數名稱或是字串，概念類似 string evaluation。 * Pass-by-value-result: 又稱 copy-in, copy-out，不直接傳入變數的參照，反而是將其複製一份傳入參照，最後再把結果指派回原先的變數。如果以上四種就可以解釋完 Python 的參數傳遞方式，那或許也不需要寫這篇文章了（笑）。嚴格來說，Python 並不屬於以上四種傳遞方式，但是觀念上都是互通的，在這之前，我們必須先了解何謂 Immutable/Mutable。 Immutable Object and Mutable Object Immutable 代表物件產生後就不可以被修改，反之 Mutable 則是可以被修改。舉例來說 Python 中 numbers, boolean

func(void)：C 與 C++ 函式宣告的小差異

最近編譯遇到一個錯誤訊息 warning: function declaration isn’t a prototype，程式碼大概是像這樣： hello.h 1 2 3 4 void foo() { printf("Hello World!\n"); } hello.c 1 2 3 4 5 int main(int argc, char**argv) { foo(); return0; } 這樣的程式碼應該再單純不過了，怎麼會說我的函式宣告(Declaration)並不為一個原型(Prototype)呢？深入了解 ANSI C 才知道原來這與語言的發展史有關。函式的宣告(Declaration)

白手起家，不到 25 歲成為千萬富翁的感覺是什麼？

在 Quora 上有上問道：「白手起家，不到 25 歲成為千萬富翁的感覺是什麼？」，這個問題沒想到真的吸引了不少千萬、億萬富翁匿名回覆。回答非常精采，我們或許無法年紀輕輕就成為千萬富翁，但至少可以看看他們成為千萬富翁後的感受。註一：原文中是寫百萬富翁，但文中以台幣換算，故為千萬富翁。註二：以下部分內容使用原回答的第一人稱描述。富有後的改變？年輕時賺到大錢是個很特殊的感覺。瘋狂購物不會因為價錢而汗流浹背，可以買棟豪宅、買台名車、大啖美食，或是選個高級飯店好好度假，甚至可以招待那些無法負擔這些消費水準的朋友一同享樂。不必擔心要存多少錢才足夠負擔小孩的教養費、退休後的生活以及昂貴的醫藥費，如果從這些角度來看，成為千萬富翁的確是一件很棒的事情。除此之外，開始花錢做自己想做的事，例如：學習義大利語，跳騷莎，像專業攝影師學習攝影，學習烹飪。最後驚覺原來這些事情只需要比平均略高的薪水就可以完成了，而千萬的財富對他們而言，其實也不多。有了錢，就會發現原來自己的財富無法擁有私人飛機，而生命才是人生中最重要的，擁有得越多，越是害怕失去，而這樣的財富也沒有辦

時數的迷思

回憶起以往聽上榜學長們分享心得時，多數都會強調他每天讀多久多久的書，台下學弟們聽得熱血握拳，好似只要跟學長花一樣多的時間讀書，最後就可以考取自己心目中的名校。工作後，大家改為談論工時。當聽到他人薪資福利比自己好，難免會以工時自我安慰。花很多時間最後卻名落孫山的，總是抱怨那是別人運氣比較好；花很多時間卻得不到相對報酬的，總委屈地認為他該領得比別人多。在我看來，比較這些時數完全沒有任何意義。一天讀書 12 小時，但你不知道他打盹、分心、發呆佔了多少時間；一天讀書 4 小時，但你不知道他大學四年來打下的基礎有多深厚。工作到凌晨二點才下班，但你不知道他幾點上班、下班前有沒有其他業外活動；工作到晚上六點就下班，但你不知道他六點上班且工作時心無旁騖。強調讀書時間的在我看來無非是想炫耀自己天資聰穎、或是告訴大家他不是靠運氣上榜的。而常常把工時掛在嘴巴上的，大概也真的只剩工時可以說嘴。當效率好的人被迫長時間工作，代表工作量分配不均、不然就是苦力活居多得用時間來換。最慘的情況就是當主管無法分辨部屬的績效時，導致效率較好的人也只好為了考績而留下。工作時數長容易讓人產生倦怠感。文化與風

深入了解 Unicode 文字與符號的編解碼

(圖片取自維基百科) 1987 年 Unicode 誕生至今已經高達近八成的普及率（若包含 ASCII）。跟文字有關的都得處理編解碼問題，設計 Unicode 的野心就是要能表示含全世界的文字符號。（如：Chinese (中文) 到 Russian (русский) 以及 Arabic (العربية) 與其他表情符號）。在 Unicode 誕生之前的世界電腦是在美國被發明的，自然而然最初只需要簡單的符號、數字、以及二十六個英文字母，因此最初被普遍使用的字符集就是 ASCII。而 7-Bit 的 ASCII 隨著電腦的普及逐漸發現有些符號與文字無法表示後，加上電腦並不需要有第八位元的錯誤檢查碼，所以 IBM 將其擴展為 8-Bit 的 EBCDIC。但這始終停留在英美國家，東方世界所使用的漢字系統 CJK(Chinese, Japanese, Korean) 完全只能使用自己定義的字符集，而歐洲國家也同樣如此。

iPhone 5 與 Galaxy Note3，誰高誰下？

使用 iOS 以來算算也差不多五年了，難免有點膩（尤其是 iOS7 用久了還容易頭暈）。最近剛上市的 Galaxy Note3 不論功能或外觀皆非常吸引我，對一直以來都是用小螢幕手機的我，也算是一個突破性的嘗試吧！因此就決定把小弟我的第一次開箱->評測->關箱文就獻給 Note3 了！（部分圖片來自 mobile01 上圖文並茂的開箱文）機如其名：高質感的筆記本 151.2 x 79.2 x 8.3mm 加上 168g 的規格徹底推翻了我們對於大螢幕手機的刻板概念，實際拿在手上不但一點負擔都沒有，還因為表面積大，所以有很輕的錯覺。除此之外，Note3 的可拆換背蓋終於一改以往廉價的塑膠感，改用合成皮革，這皮革背蓋不但耐彎質感還很好！搭配那窄邊框與大螢幕，彷彿手上就真的拿著一本筆記本。美得令人讚嘆的面板！ 5.7吋 1920×

為什麼好的學歷總是容易獲得主管們的青睞？

![](http://www.expressuniversitydegree.com/content/images/2013/05/79194190-portrait-of-a-mid-adult-man-holding-an-ace-gettyimages.jpg) [三種工程師](http://st-threath.blogspot.co.at/2013/06/an-engineer.html?m=1)這篇文章提到了第一類的工程師：*寫程式的人*：> 這種類型的人單純的只是為了工作、功課、任務而寫程式，雖然職務名稱叫做工程師，但是寫程式對他們來說只是獲取成績、金錢的工具，寫程式對他們來說枯燥無味，但為了生活，他們繼續產出他們的程式碼。他們喜歡簡單的任務，最好是一看到就知道要怎麼做，最好有別人的程式碼可以直接套用。而當他們的程式可以過關，他們就開心的回家睡覺去，連一秒都不想看到程式碼。根據我自己的感覺，大公司裡頭大約有 80% 是屬於這類的工程師(看看微軟自己人怎麼說)。對於他們來說，寫程式這件事除了工作以外不具備任何意義，工作後還會繼續鑽研的少之又少。份內工作完成就好，其餘的

2013 WWDC 心得後記

這是第二個沒有 Jobs 的 WWDC，但是開始售票後 71 秒門票就通通售罄！今年比起去年真的精采許多！整理一下今年特別吸引我的部份： OS X Mavericks OS 10.9 不再用動物命名而改為加州地名：Mavericks，此次改版最主要的更新就是以下省電機制： 1. **Timer Coalescing：**CPU 運算是非常耗電的，Mavericks 中將許多頻繁的低階處理匯集一起一次做完，避免 CPU 頻繁動作。 2. **App Nap：**大家在使用電腦時，通常是多個視窗同時被開啟，如果這些視窗包含了動態網頁或是影片，就只針對最上層的視窗做運算處理，畢竟使用者永遠只會看見最上層的畫面。 3. **Safari Power Saver：**在 Mac OS 上 Flash 相對更耗費資源，所以預設就先不載入。 4. **Compressed Memory：

非自願性干擾 - 在辦公室工作效率低落的主因

![](http://www.cartoonstock.com/lowres/bve0221l.jpg)自從看過 [Rework](http://talk.ernestchiang.com/2010/10/rework-part-1.html) 之後，Jason Fried 幾乎就變成我的偶像了，非常欣賞他提出的許多看法，一針見血卻相當中肯實用。這已經是多年前的影片了，工作後再看一次感觸更深了，以下整理出影片重點，有空的話還是極力推薦花個十五分鐘把影片看完。辦公室的目的老闆為了讓大家努力工作，以及「看不到人如何知道他在工作？」「在家充滿誘惑容易分心」這類的理由要求大家在同一個地方工作，所以才有辦公室的存在。即使如此用心良苦，但當你問起這些人想把事情作好，第一個會想到的地方是什麼？通常他們的回答都不是在辦公室中，這跟辦公室的目的不是相背而行嗎？為何會導致這種狀況？非自願性干擾現在社群網站非常發達，所以有些公司甚至會屏蔽掉 Facebook 這類的網站，但這很荒謬，逛了就不會想工作？！因為上社群網站其實就跟十幾年前的 Smell Break

使用 Git 管理 SVN Repository

說了再多 Git 的好處，如果開發團隊依舊繼續使用 SVN 的話，也只能望之興嘆？ Git 最大的特色就是分散式系統，因此可以離線操作，再借助 git-svn 的幫助，我們開發的時候就可以完全的使用 Git，只有在 Check in/out 才需要使用 SVN。以下整理出我個人常用的指令： Check-out SVN Repository 1. git svn init http://svn/trunk/ProjectName 2. git svn fetch -r REV_NUM 3. git gc 因為 SVN Repository 可能非常龐大，如果不是需要全部的歷史提交資訊，我們可以直接指定從哪版 revision