谈谈如何写好Mail
Mail(在这个时代,Mail默认的含义早已变成了Email,也就是电子邮件)是我们在工作中常用的表达和沟通方式之一。与IM工具、拿起电话直接Call、会议等相比,Mail容许相关干系人用更多的时间去了解背景、理解问题和思考解决方案,而不用立即予以答复。 ...
Mail(在这个时代,Mail默认的含义早已变成了Email,也就是电子邮件)是我们在工作中常用的表达和沟通方式之一。与IM工具、拿起电话直接Call、会议等相比,Mail容许相关干系人用更多的时间去了解背景、理解问题和思考解决方案,而不用立即予以答复。 ...
时间是人类最宝贵的财富之一,我十分认同这点,因此我在个人时间管理以及工作效率上也是一直追求持续改善的,期望能在最短的时间内产出更多有价值的成果,尤其是工作时间里。 ...
近期在做一些基础设施搭建的过程中,又遭遇到了公司http代理的问题。主要是很多主机上的工具只支持不带身份鉴权信息的http_proxy设置,如只 支持诸如:export http_proxy=‘http://10.10.1.1:8090’,而不支持export http_proxy=‘http://tonybai:passwd@10.10.1.1:8090’这种形式的配置。 ...
2011年我的确读了不少书,掐指算来纸版和电子版加在一起近50本,其中以技术类居多,但其他方面的也有一些。这里列出来做个简单回顾。 一、技术类 · 《你必须知道的495个C语言问题》 早在这本书出版前,其译者已经在网上完成了C FAQs的翻译(在这里)。这本书是基于最新C FAQs做了重新整理(包含C99)。虽说是最新,但因C语言近几年来变化很小,内容与之前译者在网上公开的那个免费版本相差不多。这本书适应面很广,初学者可以从中了解到很多谭氏教程中没有的东西;有经验的C程序员可以把它当成一本手册,需要时翻看。对于那些很在乎C语言细节的程序员来说,翻看一遍也未尝不可。 ...
2011年眼看就要接近尾声了,这里也对自己在2011年的"所作所为"做个小结^_^。 这一年来工作之外的我过得还是比较充实的,从下面的数字也可以看出: - 写了81篇博文 - 开源了2个工具(CBehave和buildc) - 合译了一本书("Seven Languages in Seven Weeks",不过尚未出版) - 读了近50本书(通过豆瓣读书统计) - 新学了一门语言 – Common Lisp - 新用了一门语言 – Python ...
Behaviour-Driven Development,即行为驱动开发在业界早已不是什么新鲜玩意了。我之前也略有了解,不过一直没有"深入钻研"。直到今年年初InfoQ的几篇有关BDD的文章才让我对BDD有了更多的认识。与TDD一样,C语言在BDD领域依旧是一个"后进分子",在多数主流语言(Java,C#,Ruby等)都已经拥有比较成熟的BDD框架(如JBehave、SpecFlow和Cucumber)的今天,C语言却似乎仅有一款BDD框架-CSpec可用。于是年初的时候我就把设计和实现一个用于C语言的行为驱动开发框架加入到我今年的ToDoList中了。 ...
本文翻译自Dan North的文章"Introducing BDD"。 我遇到了一个问题。当我在不同环境的多个项目中使用和教授类似测试驱动开发(test-driven development, TDD)这样的敏捷实践时,我总是能遇到来自程序员们相同的困惑和误解。他们想知道从哪里开始、测什么不测什么、一次测试多少、谁来调用他们的测试以及如何理解为什么一个测试失败了。 越是深入TDD,我越能感觉到我对TDD认知过程是时断时续、逐步掌握的,还远未进入到死胡同。我记得多数时间我想到的都是"这只是别人告诉我这样做的",而不是"哇,我明白为何要这样做了"。我断定一定可以通过某种方法将TDD直截了当地呈现给那些优秀的程序员们,并且可以避免所有陷阱。 ...
市面上关于优秀编程风格和习惯养成的书籍还真不少,其中“叫好又叫座”的书诸如《代码大全》、《编程精粹:编写高质量C语言代码》、《编程匠艺》、《重构》以及《Clean Code》等。不过前些天我在网上下载了一本名为《The Elements of Programming Style》的电子书,看过此书后,我才知道开创编写优秀风格代码之路的鼻祖是谁(不知道是否还有比这本书更加古老的且系统地讲述优良编程元素的书籍了?)。 ...
本文翻译自”Comments Only What the Code Cannot Say“,来自于《程序员应该知道的97件事》一书中的某个章节。 我们知道理论与实践之间存在差异。在实践中,这个差异远大于其在理论中所描述的那样 – 一份对注释(comments)的观察数据也证实了这一点。理论上,通常的注释代码的想法听起来是值得的:它可以为读者提供更多的细节,可以解释发生了什么事情。有什么能比自我帮助更具可帮助性的呢?然而在实践中,注释却经常变成一个破坏因素。与其他书面形式一样,编写好的注释也是有技巧的。这个技巧的主要内容是知道何时不写注释。 ...
本文翻译自”Use the Right Algorithm and Data Structure“,来自于《程序员应该知道的97件事》一书中的某个章节。 一家拥有多个分行的大银行抱怨说他们为出纳员新买的计算机运行得太慢了。这件事儿发生在电子银行以及ATM机使用普及程度远不及现在的那个年代。人们更多的是亲自到银行办理业务,这些运行超慢的计算机使得大家排起了长队。因此,这家银行威胁计算机供货商要结束他们之间的供货合同。 ...