随手记

2013-08-21

二级结构真是一个很好的结构，用在 IPv4 地址管理上，就是 CIDR；用在 UNIX/LINUX 的用户管理上，就是 组 和 用户的概念，可以用来做权限控制；用在网络服务上，服务提供者组可以做负载均衡；再加上版本号的话，就是构建/发布的命名规则，例如 maven 中的 group 和 artifact 的概念。

2013-08-23

如果你的程序会被他人使用，最好提供一个指南(tutorial)文档，其中包含一个简单、完整、易于理解的例子（如，以用户登录、请假申请为例），如果能够用讲故事的方式来进行描述就更棒了。

理解一个系统，最好先感性，后理性；先脉络，后细节。

2013-09-04

用习惯了 Git，现在的项目用 SVN，感觉两者的差距就出来了。首先，如果断网了，则 SVN 无法提交本地修改；其次，SVN 的 merge + commit 操作以后，只能看到 commit 的日志，被 merge 进来的分支的历史全部丢失了，只能看到 commit 操作的修改历史。

2013-09-05

logback 配置文件的思维模型原来是这样子的：Logger 是我们的某个小头目（可以有多个，但是 Root Logger 有且只有一个），Appender 是真正输出日志的干活儿的，必须先成为某个日志控制器小头目的小弟（通过 appender-ref 指定）然后才能开始干活。

2013-09-15

问：计算机的模型是什么？

答：存储 + 计算

问：为什么存储是个问题？

答：

• 服务器必须逻辑上是不宕机的

• 服务器可以宕，但是状态必须维持
• 存储是状态的维持者
• 状态维持非常麻烦，所以需要把存储从业务中抽象出来，让业务系统不用为维持状态烦恼
• 抽象的结果
    – 中间件产生
    – 通常是某种大家熟知的数据结构
• 字典（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

2015-05-11

搭建高可用mongodb集群（一）——配置mongodb

http://www.lanceyan.com/tech/mongodb/mongodb_cluster_1.html

2015-07-30

爬取 AJAX 网页信息的 Java 库/框架

1. HttpUnit ( http://www.httpunit.org/ )

2. crawljax ( https://github.com/crawljax/crawljax )

2015-09-07

github explore (https://github.com/explore)

2015-10-13

https://jobs.lever.co/github/