初创公司CEO应该遵守的14条准则

初创公司CEO应该遵守的14条准则
(14 Ways To Be A Great Startup CEOhttp://onstartups.com/tabid/3339/bid/34321/14-Ways-To-Be-A-Great-Startup-CEO.aspx)
great startup ceo mark zuckerberg resized 600
初创公司的CEO生活并非我们想像的那么光鲜, 初创公司的生活也许也并非像媒体报道的那样多彩. 你知道我在指哪些媒体…那些谈论融资是多么容易,用户量扩大到多少,做CEO有多好. 很少能听到做CEO多么”操蛋”以及每个创始人都不想成为企业家. 我最近花了一些时间思考如何成为一个创始人兼CEO, 下面是一些结果.

[翻译]API设计黄金法则

API设计黄金法则

原文: http://programmer.97things.oreilly.com/wiki/index.php/The_Golden_Rule_of_API_Design
API的设计通常是一项艰巨的任务,尤其当设计的API非常庞大时. 如果你设计的API将会有成百上千的用户时,你要考虑今后应该如何扩展来避免不小心把客户端的代码搞挂. 除此之外,你还要考虑用户在使用API的过程中对你的影响.如果你的API类使用它内部的一个方法时,你要记得 – 用户可以通过子类复写(override)他,而这,可能会是灾难性的. 你将不能修改那些方法,因为用户已经这样使用它们了. 你今后的内部实现将无可避免的由你的用户来决定,而不再是你.

API程序员有各种各样的方法来解决这个问题,但最简单的还是禁止用户修改API.如果你用的是Java你可能会把所有的类都声明为final,如果用C#,则声明所有的方法为sealed.无论用什么语言,你都可以通过单例(singleton)或者静态工厂方法来避免用户复写代码,或者不当的扩展和使用你的代码.这些听起来很有道理,但,真是这样吗?

在过去的10年,我们渐渐意识到单元测试是一种非常非常重要的实践,但这一实践却并没有完全被整个行业所认可. 显而易见的是,大多数情况下,为一个未经测试的类编写测试用例时总是很难.你会发现使用了API的代码和API耦合的就像是上了强力胶一样.没有办法去模拟API类的行为,进而容易的测试API和你的代码之间的交互.

经过一段时间后也许会有改善,但只有我们在开始设计API时就考虑到测试问题.不幸的是,这可能需要你(API的设计者)多花一点时间 – 不仅测试自己的代码,还要考虑用户如何测试他们的代码. 这里就引出了伟大的”API设计黄金法则”: 仅仅给API写测试用例是不够的;你还要为使用API的代码写单元测试.只有这样做了,你才会在第一时间体会用户在使用你的API时进行测试时的种种问题.

让API易于测试的方法有很多.static,final和sealed并不见得是不合理的,他们有相应的使用场景.但意识到测试问题是很重要的,最好的办法就是自己去感受.一旦你这样做了,你将更加胜任各种设计挑战.

By Michael Feathers

规划你的WebAPI – 安全


译自“Professional Web APIs with PHP: eBay,
Google, PayPal, Amazon, FedEx, Plus Web Feeds” (chapter 12)


你一定听过这样一句话“失败的计划是必定失败(Fail to plan, and you plan to fail.”对WebAPI来说,在开始一切工作之前的规划尤为重要,因为他不仅会影响到实现难度,同时会让那些使用API的开发者痛苦不堪。

Continue reading “规划你的WebAPI – 安全”

ChromeOS是什么[翻译]

原文:http://www.tech-no-media.com/2009/07/what-chromeos-is-not.html

很多人都对ChromeOS兴奋不已,很明显有些博客言过其实。也许是该总结一下到底google的新OS是(不是)什么了。

ChromeOS
1.是linux:如果你认为Moblin(REF)是linux内核,clutter window manager也是linux的话。那么ChromeOS以及他还没有命名的轻量级窗口管理器也是linux。如同其他linux版本一样,ChromeOS也会开源,我们可能看到其他基于ChromeOS的版本 – 正如Ubuntu基于Debian一样。

2.是为上网本设计的操作系统:有一件事可以确定,ChromeOS会根据上网本的使用模式而专门优化,这和第一台EEE PC上的Xandros OS或 gOS类似:本地预装一部分应用程序,其他应用则基于云上。最主要的不同在于:google Gears使得云应用变得更易用,用户体验更好。如果你看一下google ChromeOS的合作伙伴,你会注意到他们大多在上网本市场有着很好的表现。

3.是基于ARM的:再看一眼合作伙伴,其中有Qualcomm,Freescale和德州电器,没有Intel!这三家是ARM芯片制造商同时对ChromeOS可以很好的运行在基于ARM的芯片上有很大的兴趣。对x86的兼容性会帮助ChromeOS占有更多的市场,但是大多数预装ChromeOS的机器会是基于ARM的。

4.会在货架上出售:对,ChromeOS的目标就是帮助出售便宜的上网电脑(用户只有上网机会为google创造价值)。在摆放时应避免和PC放到一起,造成消费者的混淆。

5.对linux来说是件好事:linux最大的问题是他的市场份额。因为linux只能代表2%的市场,很多软件,游戏和硬件商会忽略它,因为市场实在是太小了,不愿意将产品或者驱动移植到linux上。作为平衡,linux社区起到很大的作用,很多驱动,应用软件是由程序员自己开发的。但有一个问题,很多流行的游戏是由游戏工作室设计的,驱动应该是在硬件发布之前而不是之后开发的。如果基于linux的平台 – ChromeOS能够得到更多的市场份额,对整个linux社区都是一件好事 – 可以获得更好的商用软件供应商和硬件厂商的支持。

ChromeOS不是
1.并不完全依靠“云”:即便google没有使用Gnome或者KDE,她仍然可能会移植大多数的linux应用程序到ChromeOS,那么最终将有一整套完整的应用生态环境出现。尽管可能需要等上几年。因为Google gears的支持,类似google doc这样的web应用可以在离线状态下运行,所以本地应用程序可能是不需要的。

2.不是微软杀手:尽管为ChromeOS编写本地应用程序是可能的,但是ChromeOS最主要的目标是web接入。这意味着一开始可能只有很少的商用软件支持。因此,大多数人还是想要Windows作为他们的PC平台。ChromeOS可能只能在上网本制造商方面威胁到微软,但微软并没有在这方面赚钱,所以也就不大可能会引起大的对抗。

3.还没有准备好:google预期第一台装备ChromeOS的设备在2010年下半年诞生,尽管第一个beta版已经available。当ChromeOS上市的时候,Windows7和其他诸如Moblin和Jolicloud的linux操作系统将和它同台竞争。

REST API vs. SOAP API

译自“Professional Web APIs with PHP: eBay,
Google, PayPal, Amazon, FedEx, Plus Web Feeds”

REST API
当处理REST请求时,因为信息是通过GET,所以,信息在传输过程中会进行URL编码(URL-encoded);当需要进一步处理时,首先要进行解码(唯一例外是用户名和密码)。不同的请求类型应该使用不同的endpoints(URLs);如果要以单独的脚本程序来处理所有的请求,你可以让所有的请求都指向同一个endpoint,或者配置web服务器来映射许多endpoints到同一个脚本。我建议用后一种方式;它符合规范同时允许你以后在不需要影响外部接口的情况下做修改。

允许程序员使用web接口来请求API – 在调试程序时将变得非常有用;程序员可以快速的判断问题源于请求本身还是代码。你可以提供给程序员的调试工具越多,你的网站也就越容易开发。

SOAP APIs
当处理SOAP请求时,首先要检查请求是否符合WSDL指定的格式。如果你使用诸如NuSOAP的工具,他可以帮你做到这一点。事实上,大多数SOAP API使用一个框架来处理许多低级的工作。 SOAP API使用单一endpoint接收所有请求(作为一个通用规则,一些大的API会根据功能来拆分到不同的endpoint),因此,或者是你有一个很大的脚本文件,或者是在每个功能点都调用很多required()方法。

允许程序员在使用web接口时可以粘贴整个请求文档到一个表单,然后发送到你的服务器。从直接的经验来看,有这样一个工具对程序员调试程序时是非常有用的。提供脚本或者函数从而让程序员可以手动创建请求对那些没有使用SOAP框架的程序员是很有帮助的。

apache-derby连接jdbc连接url的解析

来自http://db.apache.org/derby/docs/10.4/devguide/devguide-single.htm。我这里只是翻译一下,其实最关键要搞清楚的就是系统文件夹(通常是C:/databases)和类路径(从类路径开始或者从jar文件中开始查找)的区别。

jdbc:derby:db1
•打开系统文件夹中的db1

jdbc:derby:london/sales
•打开数据库lodon/sales,london位于系统文件夹下,sales是london的子目录

jdbc:derby:/reference/phrases/french

•打开数据库 /reference/phrases/french。 unix下,就是从根目录开始的路径。windows下则是C:referencephrasesfrench(如果当前驱动器是C.如果一个包含数据库的jar文件在用户的类路径下,则这个路径是jar文件内的路径。

jdbc:derby:a:/demo/sample
•打开驱动器A中的数据库,路径是demosample

jdbc:derby:c:/databases/salesdb jdbc:derby:salesdb
•这两个连接到相同的数据库 – salesdb.在windows下derby默认的系统路径是C:databases.

jdbc:derby:support/bugsdb;create=true
•在系统路径下创建一个新的数据库 – support/bugsdb。如果不存在,则自动产生相应的文件夹。

jdbc:derby:sample;shutdown=true
•关闭sample数据库。(如果没有启用验证,则不需要提供用户密码)

jdbc:derby:/myDB
•以只读方式连接myDB(位于类路径下)

jdbc:derby:classpath:/myDB
•同样以只读方式连接myDB数据库。使用classpath的原因是,路径下可能存在和数据库同名的文件夹。

jdbc:derby:jar:(C:/dbs.jar)products/boiledfood
•访问只读数据库boiledfood, 位于C:dbs.jar中的products文件夹。

jdbc:derby:directory:myDB
•访问myDB(位于系统文件夹)。使用directory是类路径下可能存在同名文件夹(myDB)

OO设计原则

抖胆翻译一下scea study guide里的第一章的OO设计原则.纪录一下.

开闭原则
类应该被扩展,而不是被修改

Liskov替换原则
子类可以替换父类

依赖注入原则
依赖于抽象,而不是实现

接口分离原则
接口应该分开,避免单一通用的接口

合成重用原则
尽量用多态聚合代替继承

最少知识原则
操作知道尽可能少的当前类中的对象(自身,参数,类中的其他实例对象)

发布重用等效原则
细粒度的重用相当于细粒度的版本发布

包依赖:

共同关闭原则
一同变更的类应放在一起

公用重用原则
如果类不会一起被重用,就不应该放到一起.

非循环依赖原则
包之间不可以有循环依赖

依赖不变原则
依赖不应该经常变化

抽象不变原则
抽象包不应该经常变化

Javablog » How MIDlet Signing is Killing J2ME

Javablog » How MIDlet Signing is Killing J2ME

TODO: 翻译

实践的一小步-代码质量的一大步

实践的一小步-代码质量的一大步
作者:Steven Hale December 14, 2007
翻译:ZhangV 2008-2-18
原文出自:DevX.com
原文链接:http://www.devx.com/Java/Article/36231/0/page/1

假设持续整合是你开发过程中很重要的一部,你也很想把代码覆盖检查并入你的自动构建过程.但是如何设定覆盖率目标呢?经验丰富的代码覆盖支持者会建议你75%,85%甚至100%.

通过对项目中的代码分析,我意识到需要设定比上述数据低得多的目标.我不想成为团队中的Cathcart上校(Josef Heller的小说<<第22条军规>>中的人物,因为每当部下已经达到当前的飞行任务次数时,他就会设定更高的任务次数,虽然Yossarian不断地完成飞行任务,但却似乎永远都无法完成这个总在变化的次数,小说中最后Yossarian开小差逃到瑞典-译者).

我选择增量改进的策略而不是专制的设定更高的目标.为了成功的执行这个策略,每次构建都必须达到比之前构建更高的覆盖率.通过每次一小步的提升,来最终提升代码质量.

以下介绍如何使用Cobertura和Apache Ant来实现这个增量改进.

单元测试,代码覆盖,持续整合
这三个概念已经被广泛的接受为最佳实践.事实上,大多数程序员知道他们必须要单元测试.如果你还不知道,让我来引用Google研发总监Peter Norvig的名言:

“如果你觉得不需要写单元测试,把所有原因写下来到一张纸上.仔细的揣摩这张纸.然后,扔掉这张纸开始写单元测试.”

但是谁来测试测试人员呢? 也就是说,你怎么来确认你写了足够的测试呢?这些是非常宝贵的信息,因为那些没有被测试覆盖到的代码正是最耗费你经历的地方.一个解决办法是使用代码覆盖工具,它们会告诉你有被测试代码的百分比,然后加入一个代码覆盖检查到你的持续构建过程.如果你的覆盖检查不通过,那么构建也该被认定为失败.

在我的增量改进策略中,我选择Cobertura是因为她4个定义完整而简单的ant任务扩展.其中之一 cobertura-check,当代码覆盖率没有达到要求是会认定构建失败.例如下面这个例子,当覆盖率小于80%时,Ant会认为构建是失败的:

<target name=”coverage_check”>
<cobertura-check totallinerate=”80″/>
</target name=”coverage_check”>

但是,你可以使用之前的覆盖率来作为当前检查的标准.通过几个Cobertura的任务以及两个核心的ant任务,你就可以达到这个目标.而不需要担心是否应该考量 代码行率(line rate),分支率(branch rate)或者其他的覆盖数据.你的目标是改进,而不是一个绝对的硬性指标.

创建一个XML格式的代码覆盖报表
创建好ant任务后,你可以加入增量覆盖率检查到你的构建脚本中,第一步是用cobertura-report任务创建一个覆盖率报表:

<cobertura-report format=”xml”/>

下面是一个生成的报表:

<?xml version=”1.0″?>
<!DOCTYPE coverage SYSTEM “http://cobertura.sourceforge.net/xml/coverage-02.dtd”>

<coverage line-rate=”0.43612334801762115″ branch-rate=”0.48344370860927155″ version=”1.8″ timestamp=”1181043899853″>
<sources>
<source>./src/java</source>
</sources>
<packages>

</packages>
</coverage>

确保你把这个文件保存安全的地方(或者放到你的版本控制系统),因为之后你会用到他们.

从报表中得到覆盖率数据
一开始你可能会用Ant的XmlProperty任务来直接获取代码行率(line rate).但是这种做法有几个问题:
1.Cobertura的行率(line-rate)是十进制小鼠,但是cobertura-check是用整数形式的百分率
2.在一个实际的项目里,coverage.xml可能会很大,使用XmlProperty可能会造成内存不足的错误

我建议使用Ant的XSLT任务来获取你所需要的数据

<xslt in=”coverage.xml” out=”build/coverage.properties” style=”src/xsl/coverage.xsl” />

这个简单的xsl模板生成仅仅包含你所需要的数据的属性文件:

<xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”  version=”1.0″>
<xsl:output method=”text” omit-xml-declaration=”yes”/>
<xsl:template match=”coverage”>
total.line-rate=
<xsl:value-of select=”floor(@line-rate*100)”/>
</xsl:template>
</xsl:stylesheet>

注意方法:floor(@line-rate*100), 会把行率转成一个整数,生成的coverage.properties文件只有一行:

total.line-rate=44

这个属性文件仅仅是一个临时的文件,构建之后你可以把它清理掉.

使用Ant的property任务读入这个属性文件中唯一的值total.line-rate:

<property file=”build/coverage.properties” />

然后你可以把之前的”80″替换为新的Ant属性值:

<cobertura-check totallinerate=”${total.line-rate}”/>

完整的例子
最终的build.xml应该是这样(其他的任务省略掉):

<target name=”coverage_check” depends=”check_against_previous_rate”>
<antcall target=”coverage_report”/>
</target>

<target name=”coverage_report”>
<cobertura-report format=”xml” destdir=”.” />
</target>

<target name=”check_against_previous_rate” depends=”coverage_xml_to_properties”>
<property file=”build/coverage.properties” />
<cobertura-check totallinerate=”${coverage.line-rate}” />
</target>

<target name=”coverage_xml_to_properties”>
<xslt in=”coverage.xml” out=”build/coverage.properties” style=”src/xsl/coverage.xsl” />
</target>

注意:新的覆盖报表只有在覆盖检查通过时才生成.(覆盖率必须要高于前一次的构建)

记得要先执行coverage_report,然后执行coverage_check.实际开发中,你应该加入另一个covertura-report任务来生成HTML的报表.

跟踪改进率
一个附加的好处是你可以通过记录覆盖率数据到一个文件来跟踪改进率.通过echo人物:

<target name=”time”>
<tstamp>
<format property=”date.time” pattern=”yyyy-MM-dd HH:mm”/>
</tstamp>
</target>

<target name=”log” depends=”time”>
<echo file=”${history.txt}” append=”true”>
${date.time};total.line-rate;${total.line-rate}
</echo>
</target>

可量化的结果,看得见的改进
在使用了上述的措施后的一周后,我们的代码覆盖率提升了30%.可喜的是,那些之前不情愿写测试的程序员现在也很自豪地看到项目的覆盖率提升.

敏捷开发的民主精神在于,每一个团队成员都可以为整个团队提出目标 – 通过写单元测试. 没有专制的目标,没有cathcart上校.

你也可以更进一步.把这种增量式改进策略用到其他的地方.

作者Steven Hale,工作与瑞典的Omegapoint AB咨询公司.有超过20年的系统开发经验.

看板在行动(Kanban in Action)

作者:DavidAnderson 原文
翻译:ZhangV 2007-11-26

之前,在讨论我在corbis所使用的软件工程管理方法时 ,我曾提到引入看板系统来维持项目运行。因为它的引入,我们现在每个月平均发布两个新的版本。然而,这些并没有使用传统的敏捷开发方法如两周迭代(two week iteration)或快速迭代(sprint)。而是用看板系统来管理变更请求(CR-Change Request)。当CR被完成时,它被设在准备发布状态,并在每周三被发布。

尽管我们让没有用Visual Studio的开发人员使用了outlook的teamlook客户端联入Team Foundation Server跟踪所有CR,但基本上的日常工作,我们都是使用白板作为看板来跟踪所有CR,把Post-It当作看板卡。

我们的支持过程是由一组常见的软件工程资源驱动的,没有一个专职的支持维护团队。通过设置看板,我们可以向管理层保证 – 我们正在履行我们的承诺,我们使用了一定的资源来进行支持活动,而不需要特别指出是谁在负责。

每天早会上所有团队成员会围绕看板来进行当天的工作安排,讨论进度和当前存在的问题。达伦戴维斯,作为项目经理,会主持会议,并分析每张卡片并与其他成员讨论。每张卡上写着CR的标题以及ID,及负责人的名字。每个负责人有责任根据当前CR的进行阶段移动相应CR的卡片。达伦利用每天的早会来保证Team Foundation Server上的数据和看板是同步的。该看板系统基本上是自我组织(self organizing),但整个团队每天都会验证它的有效性。

一些关键概念。红星 – 这个任务已经严重超时的,超过28个工作日服务水平协议( SLA),通过该系统。这使”迟到”的项目能够自我加速,不需直接管理干预。粉红色卡表示这个CR在Team Foundation Server里还是open的。这些粉红色卡包含了描述信息和在Team Foundation Server里的ID 。还有一些其他类型的卡片:黄色-客户提出(customer-valued)的CR;蓝色-客户提出(和要求)的BUG;绿色-IT维护项,如:的sql 2005的升级;橙色-新增(或额外)的BUG;粉红-issue。

看板限制卡片最多只能有20张,分为不同阶段,系统的分析,开发,测试,构建/合并,部署。此外,我们也允许有3个bug可以放在任何地方。这样可以有效地利用闲散资源。当人手不够的时候,我们会减少这个数量,或者干脆不要。此外,还有两个维护项,这让我们能解决固定分配一些资源到大大系统维护和升级,例如API版本升级,与平台的升级。 如net2.0或sql server 2005 。

看板赋予我们三个成功要素:

  • 减少“进行中(work-in-progress)”, (讽刺的是,这些事情本身会限制工作的完成)
  • 量入而出(如果有新的CR,首先看看板上有没有足够的空间)
  • 确定优先顺序

我们每周和公司的技术总监开会讨论,决定任务的优先等级。他们从后台日志中拿出新的CR并考虑怎么把他们配置到看板上。这迫使他们思考哪些是最重要的事情。看板强迫他们给出优先等级。

看板还把我们从定时迭代的压迫(constraints of time-boxed iterations)中解放出来。尽管我们现在每两个星期发布一个新版本,大的任务可以在系统中最多可以存在60天。那些对于“一(两)周迭代”来说太大的任务同样可以放到看板里,而不需要特殊对待。

最后,看板解放了我们,我们不再把每个迭代都当作一个小型的项目而投入过多的管理成本它基本上是自行组织和管理,除非有特殊情况出现,如需要加快请求或因环境或系统的维修问题变更发布时间。

technorati的标签:敏捷,朱+安德森,精益生产,看板,软件+工程

顺便问一下customer-valued怎么翻译?

最后修改:2009-8-12