隨手記

時間 2019-11-11

標籤隨手简体版

原文原文鏈接

2013-08-21html

二級結構真是一個很好的結構，用在 IPv4 地址管理上，就是 CIDR；用在 UNIX/LINUX 的用戶管理上，就是組和用戶的概念，能夠用來作權限控制；用在網絡服務上，服務提供者組能夠作負載均衡；再加上版本號的話，就是構建/發佈的命名規則，例如 maven 中的 group 和 artifact 的概念。node

2013-08-23linux

若是你的程序會被他人使用，最好提供一個指南(tutorial)文檔，其中包含一個簡單、完整、易於理解的例子（如，以用戶登陸、請假申請爲例），若是可以用講故事的方式來進行描述就更棒了。git

理解一個系統，最好先感性，後理性；先脈絡，後細節。程序員

2013-09-04github

用習慣了 Git，如今的項目用 SVN，感受二者的差距就出來了。首先，若是斷網了，則 SVN 沒法提交本地修改；其次，SVN 的 merge + commit 操做之後，只能看到 commit 的日誌，被 merge 進來的分支的歷史所有丟失了，只能看到 commit 操做的修改歷史。golang

2013-09-05web

logback 配置文件的思惟模型原來是這樣子的：Logger 是咱們的某個小頭目（能夠有多個，可是 Root Logger 有且只有一個），Appender 是真正輸出日誌的幹活兒的，必須先成爲某個日誌控制器小頭目的小弟（經過 appender-ref 指定）而後才能開始幹活。
mongodb

2013-09-15docker

問：計算機的模型是什麼？

答：存儲 + 計算

問：爲何存儲是個問題？

答：

• 服務器必須邏輯上是不宕機的

• 服務器能夠宕，可是狀態必須維持
• 存儲是狀態的維持者
• 狀態維持很是麻煩，因此須要把存儲從業務中抽象出來，讓業務系統不用爲維持狀態煩惱
• 抽象的結果
– 中間件產生
– 一般是某種你們熟知的數據結構
• 字典（KV）、文件系統（FS）、隊列（MQ）等等

問：存儲爲何會成爲互聯網服務？

答：

• 技術門檻愈來愈高

– 品質要求更苛刻
• 數據只是存下來已經不行了，還要存多份以防止丟失
• 數據只是存多份已經不行了，還要在丟失副本的時候及時恢復以防止丟失
• 光是保證數據不丟已經不行了，還要數據時時都在線，不能出現服務不可用，服務任何環節都不能有單點故障
– 擴展能力成爲問題
• 互聯網的用戶愈來愈多
• 單用戶在線的數據愈來愈多

• 服務外包取代技術外包

– 運維難度愈來愈大
• 服務愈來愈複雜，就算有相應的開源軟件，看管軟件的運行過程，以保證服務的健康運行，也已是巨大的負擔
– 競爭愈來愈激烈
• 巨頭橫行
• 大量的同質化產品
• 如何讓本身跑得比別人快？創業者須要善假於物。

問：服務器端軟件的性能瓶頸在哪裏？

答：I/O，包括磁盤 I/O 和網絡 I/O

問：服務器端軟件的 I/O 瓶頸的解決方案是什麼？

答：

1) Go 語言使用了閉包 + 協程，而非使用異步回調（許式偉在《Go 語言編程》一書中的解釋是，使用異步回調對程序員的心智負擔太大，程序的邏輯被 I/O 切割而碎片化，對象的生命週期也很難管理）

2) Node.js 使用了異步回調，即 event loops, callbacks, closures and non-blocking I/O

2013-09-17

UNIX 有幾個統一性的理念或象徵，並塑造了它的 API 及由此造成的開發風格。其中最重要的一點應當是「一切皆文件」模型及在此基礎上創建的管道概念。總的來講，任何特定操做系統的開發風格均受到系統設計者灌注其中的統一性理念的強烈影響——由系統工具和 API 塑造的模型將反滲到應用編程中。

在 UNIX 中，低價的進程生成和簡便的進程間通信使衆多小工具、管道和過濾器組成一個均衡系統成爲可能。

UNIX 提倡把程序分解成更簡單的子進程，並專一考慮這些子進程間的接口。這至少能夠經過如下三種方法來實現：
1）下降進程生成的開銷。
2）提供方法（shellout、I/O 重定向、管道、消息傳遞和套接字）簡化進程間通訊。
3）提倡使用能由管道和套接字傳遞的簡單、透明的文本數據格式。

真實世界裏的編程，其實就是管理複雜度的問題（例如，下降系統的總體複雜度，下降程序員的心智負擔）。

2013-09-24

每當本身迷茫或者自滿的時候，就會想一想若是是本身所敬仰的人處於一樣的場景，會怎樣應對，而後，心境平和、「stay hungry, stay foolish」。

2013-09-25

A little bit upset..., not prepared to protect myself from those who are unreliable and to always have a backup plan.

EDA（以業務爲核心的事件驅動架構） + CQRS（讀寫分離） + SOA（服務要自治）【注：這裏的事件是業務層面的事件，而不是技術層面的事件】

2014-02-26

139K goroutines 支撐 68K 活躍鏈接，每一個鏈接有兩個goroutine ，由於net包的write和read是阻塞的，只能是1:2。這條推特的意義在於，證實了了GOLANG的併發模型，解決了服務器端的 C10K 問題，並且是突破了 10K ，達到了 68K。

2014-05-13

Android：現實世界的購物平臺

越過各類軟件更新的小樹葉，咱們所看到的是Google辛勤栽種的一整片森林。將定位功能（包括離線地圖）與行爲識別、文字廣告和強大的即時購買聯繫到一塊兒，不難看出Google正將這廣告平臺推向更廣闊的現實世界，直接裝入了人們的口袋之中。

2014-05-17

《beego失落的手冊》：http://go-talks.appspot.com/github.com/beego/tutorial/zh/beego/beego.slide#1

2014-05-22

http://confreaks.com/events/gophercon2014

2014-05-23

GO語言國內小站集錦：

http://studygolang.com/topics/node22

http://bbs.go-china.org/

http://sudochina.com/

http://www.golangtc.com/

2014-05-27

摘自《SteveY對Amazon和Google平臺的吐槽》

因此，有一天，Jeff Bezos下了一份命令。固然，他老是這麼幹，這些命令對人們的影響來講就像用橡皮槌敲擊螞蟻同樣。這個命令大概是2002年，我想偏差應該是在正負1年內 —— 這個命令發佈的範圍很是地廣，設想很大，讓人眼珠子鼓出來的那種，這種驚訝程度和其餘的命令相比，就好像你忽然收到公司給你的獎金同樣讓人驚訝。

這份大命令大概有以下幾個要點：（陳皓注：這裏是本篇文章的要點！若是這真是Bezos發出來的，那麼太讚了，Bezos徹底就是一個系統架構大師啊，那但是2002年左右啊。做者調侃Bezos徹底是正話反說啊）

1) 全部團隊的程序模塊都要以經過Service Interface 方式將其數據與功能開放出來。（陳皓注：Service Interface也就是Web Service）

2) 團隊間的程序模塊的信息通訊，都要經過這些接口。

3) 除此以外沒有其它的通訊方式。其餘形式一律不容許：不能使用直接鏈結程序、不能直接讀取其餘團隊的數據庫、不能使用共享內存模式、不能使用別人模塊的後門、等等，等等，惟一容許的通訊方式只能是能過調用 Service Interface。

4) 任何技術均可以使用。好比：HTTP、Corba、Pubsub、自定義的網絡協議、等等，均可以，Bezos無論這些。（陳皓注：Bezos不是微控經理嗎？呵呵。）

5) 全部的Service Interface，毫無例外，都必須從骨子裏到表面上設計成能對外界開放的。也就是說，團隊必須作好規劃與設計，以便將來把接口開放給全世界的程序員，沒有任何例外。

6) 不這樣的作的人會被炒魷魚。

在接下來的幾年，Amazon內部轉變成面向服務架構SOA(Service-Oriented Architecture)，在這華麗轉身的過程當中，他們學到了至關巨多巨多的東西。我在的那個時候，世界上就有不少不少的關於SOA的學術文檔，但在Amazon的那種超大規模的面前，世間的這些文檔就好像告訴印第安納瓊斯（陳皓注：電影奪寶奇兵男主角）過馬路前要先看看兩邊有沒有來車同樣沒用，Amazon的研發工程師們在這個過程當中發現了不少不少的問題，並從中學到了不少。下面只是他們這些問題中的滄海一粟：

pager escalation（陳皓注：生產線上問題的尋呼系統）變得比較困難，由於ticket可能會轉過來轉過去（陳皓注：ticket就是處理問題的工單），只到轉了20次，都找到真正能解決問題的團隊和人。若是每個呼叫都花去團隊的15分鐘的響應時間，那在找到真正的團隊以前，幾小時就已通過去了，除非，你能建造出不少不少的腳手架，測量標準和報告。

每個和你的相關團隊忽然間均可能成爲一個潛在性的DOS攻擊者。沒人可讓事情有進展，直到在每個Service裏放上配額（quota）與節流閥（throttling）的機制。

監控與QA是被統一了。若是你不進行一個大規模的SOA，你就不會這麼去想。可是，等到你的Service說，「是的，我還好！」，但實際狀況多是，服務器裏惟一能正常運做的功能就是一個快樂的機器聲音在呼叫你：「我很好，收到，收到」。爲了要確認整個服務能正常運做，你須要對Service的每個部分都去Call一下。這個問題會以遞歸的形式地出現，直到你的監控系統可以全面性地系統地檢查全部的Services和數據，此時，監控系統就跟自動化測試QA沒什麼兩樣了，因此二者完美的統一了。

若是你有上百個Services，並且你的程序只能經過由這些Services來跟其餘團隊的程序作溝通，那麼，沒有一套Service發現機制的話，你就不能找到這些Service。因此，你得先有一套Service的註冊機制，這也是一個Service。因此，Amazon有一套全體適用的Service註冊機制，以例能夠經過反射機制來找到Service，並知道Service的API，以及是否可用，在哪兒。

調試其餘人的代碼以調查問題變得很是的難，幾乎都不可能，除非有一套全面性的標準的方式，他能夠在可被調試的沙盒裏運行全部的Services。

上面這些只是極少數幾個例子，在Amazon在進化的過程當中，Amazon遇到這樣的問題可能一打甚至數百個，Amazon都一一學習和總結了。對於把Service外部化甚至還有不少幾乎沒有人會想到的很是生僻的東西，固然，也不會有你想像的那麼多，Amazon都學到了。把業務組織成Service讓團隊學會了不能相信對方，就如同他們不能信任公司之外的程序員同樣。

當我在2005年中期離開Amazon加入Google時，這個努力進化的過程還在進行時中，但那時已經至關的先進了。從Bezos頒佈法令的時間到我離開的時候，Amazon已經把文化轉變成了「一切以Service第一」爲系統架構的公司，今天，這已經成爲他們進行全部設計時的基礎，包括那些毫不會被外界所知的僅在內部使用的功能。

那時，若是沒有被解僱的的恐懼他們必定不會去作。我是說，他們今天仍然怕被解僱，由於這基本上是那兒天天的生活，爲那恐怖的海盜頭子Bezos工做。不過，他們這麼作的確是由於他們已經相信Service這就是正確的方向。他們對於SOA的優勢和缺點沒有疑問，某些缺點還很大，也不疑問。但總的來講，這是正確的，由於，SOA驅動出來的設計會產生出平臺（Platform）。

是的，這就是Bezos的法令要達成的目標。他之前（如今也是）一點不關心各團隊是否好，也不關心他們使用什麼樣的技術，實際也不去管他們如何運做他們的業務，除非團隊開始把事搞砸。可是，Bezos比絕大多數的亞馬遜人都很早很早就領悟到，Amazon必須成爲一個平臺。

若是是你，你會想到要把一個在線賣書的網站設計成爲一個有擴展性，可程序化的平臺？你真的會這樣想嗎？

嗯，第一件Bezos領悟到的大事是，爲了銷售書籍和各類商品須要的基礎架構，這個基礎架構能夠被轉變成爲絕佳計算平臺（Computing Platform）。因此，如今他們有了Amazon Elastic Compute Cloud（亞馬遜彈性運算雲平臺EC2），Amazon Elastic MapReduce，Amazon Relational Database Service（亞馬遜關係數據庫服務），以及其餘可到AWS aws.amazon.com查獲得的一堆Service。這些服務是某些至關成功的公司的後臺架構，好比我我的喜歡的 reddit 是這一堆成功公司的其中一個。

另外一大領悟是，他知道他們不可能永遠都創造出對的東西。我認爲，當Larry Tesler說他媽媽徹底搞不懂怎麼使用那個該死的網站時，Bezos的某根筋被觸動了，固然，我也不清楚究竟是誰家母親，這可有可無，由於沒有人的母親可以會用那個該死的網站。事實上，連我這個在那工做超過5年的人都以爲Amazon網站的接口使人膽戰驚心。

我並非很肯定Bezos是如何領悟到的——領悟到他不能創造出一個產品能適用於全部的人。不過，怎麼來的這不重要，重要的是他的確領悟了。這種事有一個正式的術語，叫Accessibility，這是計算機世界中最最重要的事情了。

最！重！要！的！事！

若是你在內心面在想「哼？你是說，像盲人和聾人那種Accessibility嗎？」，那麼，你不是惟一這樣想的人，由於我已經知道有不少不少像你這樣的人：這種東西對大家這種人來講是不可能有正確的Accessibility，因此這事你還不能理解。固然，不能理解也不是你的錯，就像眼盲，耳聾，或是其餘行動不便的殘疾人，這些也不是他們的錯。當Software——或ideal-ware——若是由於某些緣由不能被存取或使用，那麼，這就是軟件或是那想法的錯了。這就是Accessibility failure。

就如同生命中那些重大的事同樣，每一個事都有一個邪惡的雙胞胎姊妹，它在幼年都受到父母的溺愛，如今它已經成長爲同等強大的復仇女神（是的，Accessibility有不僅一個復仇女神），這個復仇女神叫安全性（Security），他們在一塊兒老是爭執不休，冤家一對。

不過，我會和你爭論Accessibility要比安全性來的重要多了，由於零Accessibility就意爲着你根本沒有作出產品來，而若是安全性爲零，你仍然仍是能夠有一個某個程度上成功的產品，譬如說Playstation Network。

那三件Amazon比Google強的中的最後一件事是，Google很不會作平臺（Platform）。咱們就不懂什麼是平臺。咱們就根本不知道平臺的內涵。大家其中一些人明白，可是大家是少數派。在Google過去這六年來，越清楚這一點就越讓我痛苦。我曾有一線但願，來自Microsoft和Amazon，以及近來Facebook的競爭壓力，會讓咱們全體人都清醒過來，並開始打造咱們公司的Service。不是那種特製的或半生不熟的，而是多少和Amazon的相似的那種：一次到位，真正的，沒有做弊或是欺騙，而且把它放在最高優先級的位置。

但實際上卻不是，這個事被放在了好像是第10仍是第11位，或是第15位，我不知道，反正是至關低。只有少數幾個團隊嚴肅地看待這個事，但大多數的團隊不是從沒有思考過這個事，就是隻有一不多的人很鼠目寸光地在看待這個事。

對大多數的團隊來講，只要是讓他們以提供給別人那種可程序化的方式存取他們的數據與運算的方式來開發軟件，就算幾個小小的粗糙的Service，對他們來講也是翻天覆地。他們大部分人都認爲他們在作產品，但他們只是在提供那些悽慘粗糙的Service。回去看看前面我所列的那些部分的Amazon學到的東西，而後告訴我，哪個粗糙的Service能讓你有超凡脫俗的產品。迄今爲止，就我所知，一個也沒有。就算是這些粗糙的東西很不錯，不過這就好像要汽車的時候，你卻只有汽車的零件。

沒有平臺的產品是沒用的，再精確一點，去平臺化的產品老是被平臺化的產品所取代。

Google+是咱們徹底失敗的不懂Platform最明顯的例子，從最高層的管理層（嗨，Larry、Sergey、Eric、Vic，大家好）一直到最最底層的員工（嘿，你）都不懂。咱們所有通通都不懂。平臺Platform的黃金守則是Eat Your Own Dogfood（吃你本身的狗食——本身都要用本身的平臺）。Google+這個平臺是個杯具的過後抄襲者。咱們在發佈它的時候徹底沒有任何API。我查了一下，目前也只有少得可憐的API。Google+的一個團隊的成員在發佈API時告訴我這個事，我問：「這是Stalker API（用來偷窺內部數據的API）嗎？」，她鬱悶地說，「是啊」。個人意思是，我那只是個玩笑話，可是，不，咱們提供的惟一的API就是取得某人的信息流，因此，我想我把玩笑開到本身頭上了。

Microsoft知道「狗食守則」至少有20年了。這已經成爲他們世世代代文化的一部分了。不能是你吃人類的食物而給你的開發人員們喂狗食。那樣作只會是爲了短時間的成功而掠奪了平臺長期價值。平臺就是要你考慮得長遠。

Google+就像膝跳反射，一種短視的的東西，是基於覺得Facebook其偉大產品的成功做出的錯誤判斷。但那不是爲何他們能成功的東西。Facebook的成功是由於他們創建了一個可讓外界在其上上面開發的產品羣。因此對Facebook對每一個人來都不同。有些人把所有時間花在「Mafia Wars」上，有些人則是花在「Farmville」（開心農場）。那裏還有成百上千個不一樣的高質量的時間消耗類的遊戲，因此，人們老是能夠在那裏找到他們想要的。

咱們的Google+團隊看了看說：「哎呀，看來咱們須要一些遊戲，讓咱們去找一些人來爲咱們寫些遊戲吧」。你是否開始看到這樣的的思考有多麼不靠譜了嗎？問題在於咱們試圖在預測人們想要什麼，而後推出產品給他們。

你不能這麼作。真的不能。也不可靠。在這個世上，甚至在整個計算機的歷史上，只有極少數幾我的可以這麼幹，Steve Jobs是其中一個。可是咱們沒有Steve Jobs。對不起，咱們真的沒有。

Larry Tesler有可能說服了Bezos相信他並非Steve Jobs，但Bezos意識到他不須要成爲Steve Jobs也能提供給全部人好的產品：你們感到容易使用的接口與工做流。Bezos明白他只要有讓第三方開發人員來作的平臺，這些東西天然就會有的。

我要向一些人道歉，這些人會以爲我所說的是再明顯不過的了。是的，的確是巨明顯的。只是咱們沒有去作。咱們沒有領會平臺，咱們也沒法領會到Accessibility。這二者原本就是同一件事，由於平臺會解決Accessibility。而平臺就是Accessibility。

是的，Microsoft領會到了。並且大家也像我同樣知道Microsoft他們對這些東西只知其一;不知其二。那是由於他們可以瞭解平臺徹底是他們商業上意外性的副產品，是他們一開始的業務就是提供平臺。因此他們在這個領域有着三十多年的經驗。若是你去看看 msdn.com，並多花點時間瀏覽一下，假設你之前從沒去看過，你等着被嚇到吧，由於那裏面的東西但是多得不能再多。他們擁有成千成千成千個API。他們擁有一個超巨大的平臺。說實話，太巨大了，由於他們要霸佔一切，但至少他們作了。

Amazon也領會了到了。Amazon的AWS(aws.amazon.com)至關的驚人。去看看吧，四處點一下。使人羞恥吧。咱們今天什麼都尚未。

很明顯Apple也領會到了。他們作了在基礎上不開放的選擇，具體來講是移動平臺。可是他們明白什麼是Accessibility，而且他們知道如何燃起第三方開發團體的力量，並且他們吃本身的狗食。你知道嗎？他們的狗食作得很好吃啊。他們的APIs比Microsoft的要乾淨不知道多少倍，並且是遠古的時候就這樣了。

Facebook也領會到了。這正是讓我所擔憂的。這使得我不得我擡起懶惰屁股寫下這些東西。我恨寫Blog。我恨……Plus（指Google Plus）無論怎麼稱呼它，反正在Google+上發表長篇大論，就算這是個糟糕的地方，可是你仍是但願Google能成功.我真但願！個人意思是，Facebook想挖我，並且很容易就去了。但Google是個人家，因此我堅持我這個小小的家庭干涉，就算你不舒服。

等到你爲Microsoft與Amazon提供的平臺感到神奇後，固然，我想也你可能會被Facebook嚇到（我不敢去看，由於我不想讓我太沮喪），讓咱們回頭看看 developers.google.com 。是否是有很大的差異？咱們的這個平臺看起來像是你家小學五年級的侄子搞出來的東西同樣——讓一個小學五年級的學生，試着爲一個強大的的平臺公司去設計平臺，就像像咱們問這個小學生：「若是這家公司什麼資源都有，那你會作出個什麼東西來？」同樣。

這裏請不要誤解我——我知道一個事實，dev-rel 團隊爲了發佈這些API曾經不得不去「搏鬥」。據我所知，這個團隊很不錯，由於他們知道什麼是平臺，而且他們如英雄般努力掙扎地要作出來，然而遇到的倒是「平臺冷漠」的環境，難聽點仍是那種有敵意的環境。

我只是在直白地描述出一下 developers.google.com 在外人眼裏是什麼樣子。它看起來很幼稚。Maps APIs在哪呢，老天啊？其中有些東西仍是實驗性的項目，我點進去看的APIs……他們都毫無價值。他們很明顯都是些真正的狗食。甚至都稱不上是好的有機食品。跟咱們內部APIs比起來，他們所有簡直就是豬屎馬糞。

固然，也不要錯誤地理解我對Google+的見解。他們還不算是最差的。這是文化氛圍的事。咱們如今作的簡單來講就是要進行一場戰爭，是一場失敗不少的少數的平臺派和那些強大的信心堅持的產品派的戰爭。

那些從頭至尾明白理解供外部可程序化的平臺概念的團隊都是受壓迫的人——Maps跟Docs團隊浮如今我腦海中，並且我也知道GMail是這個方向的先頭部隊，可是他們很可貴到資金注入，由於這不是咱們文化的一部分。Maestro的資金徹底無法和Microsoft Office開發平臺的資金相比：就像小白兔和暴龍相比同樣。Docs團隊知道本身永遠沒法和Office競爭，除非他們能遇上Office的腳本能力，並且他們得不到他們相要的資源。個人意思是我假定他們沒有，如今應用的腳本能力只在電子表格中有，並且沒有爲API設置鍵盤快捷鍵。在我看來，這個團隊徹底沒有被重視。

可是，當咱們擺出那種咱們知道怎麼給用戶設計出完美的產品的姿態時，你最好相信我，咱們就是笨蛋。你能夠說是自大，天真，或是別的什麼，無所謂，但最終的結果就是咱們乾的很愚蠢。由於，這世界不可能有一個產品對全部人都是完美的。

你看，咱們的瀏覽器竟然不能讓人設定默認的字號。這就是咱們對Accessibility的公然冒犯。個人意思是，我總有一天會老的，我也會得老花眼，並會變瞎的。個人意思是我不會變瞎，可是若是你到了40歲，你的老花眼讓你看不清近的東西。那麼，字號的選擇會成爲生和死的問題：某用戶就會被徹底排除在產品以外。可是Chrome團隊就是這麼NB傲慢：他們想要開發出無需配置的產品，他們對此至關自豪，去你TMD是瞎子還聾子，管你是誰，在你剩下的日子每訪問一個頁面都按一下Ctrl-+吧。

並不只是他們是第一個。問題是，咱們是一家「產品」公司，一直一直都是。咱們開發的最成功最有吸引力的產品——搜索引擎，那樣巨大的成功讓咱們產生了不少定式和偏見。

Amazon過去也是家產品公司，一道神祕的力量使得Bezos領悟到他們須要平臺。那道神祕力量來源於，他們被逐漸蒸發的市值逼到牆角了，不得不千方百計突圍出來。但他當時所擁有的只有一羣工程師和他們的一堆計算機……除非他們能變成印鈔機……你能夠看到他們是怎麼搞出來AWS的，而不是像咱們Google+同樣過後諸葛亮。

Microsoft從一開始就是個平臺，因此他們有不少不少的實踐。

Facebook：我有些沒看透。我不是專家，不過我很確定他們一開始也是一個產品，而且成功了很長時間。因此我不知道他們何時開始轉變成爲平臺的。應該是好久之前的事了，由於他們要成爲平臺後，Mafia Wars這玩意纔會出現（而Mafia Wars也很老了）。也許，Facebook只是看一眼咱們，就問到：「咱們如何擊敗Google？他們少了什麼？」

咱們面對的問題很是的龐大，由於咱們須要通過劇烈的文化轉變後，咱們才能迎頭遇上。咱們沒有內部的SOA平臺，因此咱們外部也沒有。這就是說，咱們整個公司都「沒有領會到」：產品經理沒有，工程師沒有，產品團隊沒有，沒人領會到。就算是個別人有，好比你你有，那也至關於沒有，除非咱們在生死存亡的時候。咱們不能這樣不斷推出產品，並裝做咱們之後會把這些產品轉變成迷人美麗的可擴展式的平臺。咱們試過了，不行。

平臺的黃金守則，「Eat Your Own Dogfood 吃本身的狗食」，換句話說，「先打造出本身使用的平臺，而後把它用在全部的地方」。你不能過後再作，那樣作就太困難了——你去問問那些把MS Office平臺化、把Amazon平臺化的人。若是你放在後面作，那麼你比一開始要花十倍的精力才能作對。你不能做弊，你不能讓內部軟件走祕密通道以取得特定的優先權限，不爲何，你必需從一開始就要解決這個問題。

2013-05-31

golang net 庫

err時沒有close ??

DialTimeout

dialtimeout是不行的

由於http會有複用

方案1：

要寫個結構繼承conn 而後在每次讀數據時調設置超時時間

type TimeoutConn struct {
net.Conn
timeSegment time.Duration
}

func DialTimeout(netw, addr string) (net.Conn, error) {
conn, err := net.DialTimeout(netw, addr, time.Second*5)
if err != nil {
return nil, err
}

return &TimeoutConn{
Conn: conn,
timeSegment: time.Second * 5
}, nil
}

func (c *TimecoutConn) Read(b []byte) (n int, err error) {
c.SetReadDeadline(time.Now().Add(c.timeSegment))
return c.Conn.Read(b)
}

func (c *TimecoutConn) Write(b []byte) (n int, err error) {
c.SetReadDeadline(time.Now().Add(c.timeSegment))
return c.Conn.Write(b)
}

: 方案2：; @七貝
咱們是這樣處理的。。。
func TimeoutDialer(cTimeout time.Duration, rwTimeout time.Duration) func(net, addr string) (c net.Conn, err error) {
return func(netw, addr string) (net.Conn, error) {
conn, err := net.DialTimeout(netw, addr, cTimeout)
if err != nil {
return nil, err
}
conn.SetDeadline(time.Now().Add(rwTimeout))
return conn, nil
}
}

func NewTimeoutClient(connectTimeout, readWriteTimeout time.Duration) * http.Client {
return & http.Client{
Transport: & http.Transport{
Dial: TimeoutDialer(connectTimeout, readWriteTimeout),
},
}
}

2014-06-20

Skype for Linux:

http://www.techspot.com/downloads/4985-skype-for-linux.html
[

國內用戶，離線deb包安裝能夠到這裏http://t.cn/RvOaRTw，網盤離線下了一份。到skype官方會被重定向到和光明日報版skype，好坑。 //@校長Ubuntu:你會發現很奇葩。。由於在skype官方網你根本找不到linux版本，反正我找了半天沒找到。。。。我只能在ubuntu軟件中心安裝skyp

]

2014-08-01

好的代碼應當便於理解、便於測試。

2014-12-22

Docker —— 從入門到實踐

http://yeasy.gitbooks.io/docker_practice/

--------------------------------------------------------------------------------

2014 技術總結流水賬

WEB API
- Spring Boot
存儲
- SQL
  - PostgreSQL
- NoSQL
  - Redis
  - SSDB
編程語言
- Java
  - myBatis-Spring
  - Jedis
分佈式
- Twemproxy
- Codis
WEB GUI
- RequireJS
- AngularJS
技術書籍
- UNIX 編程藝術
- GO 語言編程
- GO WEB 編程

2015 技術計劃

WEB API
- beego
存儲
- NoSQL
  - Redis
  - SSDB
編程語言
- Go
分佈式
- Codis
- ZooKeeper
- etcd
DevOps
- Docker
- Kubernetes
- seagull
WEB GUI
- AngularJS
- ECharts
- AngularUI
- Angular Material
技術書籍
- Docker 技術入門與實踐
- Go 併發編程實戰
- UNIX 環境高級編程
源碼閱讀
- beego
- codis
- golangtc
WEB 工具
- Nginx

2014-03-10

《Sharding & IDs at Instagram》

Each of our IDs consists of:

41 bits for time in milliseconds (gives us 41 years of IDs with a custom epoch)
13 bits that represent the logical shard ID
10 bits that represent an auto-incrementing sequence, modulus 1024. This means we can generate 1024 IDs, per shard, per millisecond