WordPress是怎么赢的?

WordPress是怎么赢的?

一个以前在Six Apart工作4年的产品经理Byrne Reese发布了一篇文章阐述为什么WordPress成为了赢家。其在文章中比较了WordPress和其主要竞争对手产品Movable Type。我觉得其中有可取之处,本想全文翻译的,后来觉得文章太长,翻译太花时间,所以,我把文章中的观点总结如下。

作者例举了如下为什么WordPress会赢的理由:

一、Movable Type许可证,而WordPress是开源的

2004年,Movable Type修改了其许可证,这一举动激怒了所有Movable Type的用户,于是大家纷纷转投Wordpress,这是WordPress最终成为赢家最大的原因。就算是Movable Type有着优越的设计,优越的功能,还有优越的技术支持,但是面对的是一个完全免费的产品也没有办法。因为WordPress是开源的,开源就意味着完全免费,而Movable Type一开始也是免费的,但是其许可证策略有着很不确定的因素。(注:2007年Movable Type发布了开源版本)

二、WordPress很容易安装

WordPress的安装过程很简单,只需要不到5分钟,比起Movable Type来说,这太受用户和推广商欢迎,你几乎不需要去碰后台的那些Web设置。(注:不仅如此,WordPress的升级和安装插件和风格的用户体验也是非常的不错)这就是为什么大家都喜欢WordPress的原因,就算是其功能比Movable Type少了又少。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 2.80 )
Loading...
你会问问题吗?

你会问问题吗?

在工作和生活中,总是会有很多人问题我很多技术方面的问题。有一些时候,问问题的和答问题的总是会有一些不爽的事情发生。如下面的几种情况:

  • 比如:“我的电脑老是蓝屏,怎么办?”,通常这样的问题90%以上的回答是:“重装吧”。这让问问题的人感到很沮丧,但你不能不承认那不是答案。而且有时候让人无法解答,比如:“我的makefiel出错了,你帮我看看我的makfile”,我通常会非反问,报了什么错吗?
  • 另一种情况是,回答问题的人首先先对问问题的人的抱怨,你问的问题就不对,或是,你问的这个问题是什么意思,而导致问问题的人却在不停地解释,结果花了好长时间来讨论问题本身是什么。
  • 还有一种情况是,问的问题太简单了甚至太白痴了,比如你自己试一试或是读读文档就知道了的问题,或是问这个问题直接表明了你的无知或是懒惰。这种问题会相当影响别人对你的印象。
  • 第四种情况是,提问者滔滔不绝,扯这扯那,讲了一大堆,听得听累了。最后都不知道你要干什么。

所以,怎么去问问题,怎么问一个好的问题,是一个很重要的事。你提问的技术直接关系到了你是否能够很快得到你满意的答案。

这里有一篇文章推荐给大家《How To Ask Questions The Smart Way》,中文版在这里《提问的智慧》,我把其中的几个亮点总结如下:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (22 人打了分,平均分: 4.14 )
Loading...
提高编程技能最有效的方法

提高编程技能最有效的方法

StackExchange.com上有两个贴子(贴子一贴子二),贴子名叫“What is the single most effective thing you did to improve your programming skills?” – 对你的编程技术提高最有效的一件事是什么?回复的人中给了很多很不错的建议,我把他们总结了一下,十条,相信一定会对你有用。(注意:顺序是我自己按我的个人经验排的)

  • 和比自己聪明的能力比自己强的人工作。学习他们的代码,他们的做事方法,看一看那些人是怎么处理错误的。
  • 总是倾听别人怎么说,无论那个的资历和职位是什么样的。
  • 实践,实践,实践,总是不满意于一开始出来的事。
  • 多问问自己,现在在写什么代码?为什么要这样写成这样?还有没有更好的方法?
  • 学习多样的技术,多多比较他们,并一定要了解各种技术的优缺点。
  • 总是问别人问好的问题。
  • 多回头看看走过的路,做过的事,写过的程序,感觉一下他们有多烂。
  • 多读读那些大师写的书。
  • 不要总坐在电脑前编程序,多做做运动,多到户外走走,和非技术人多接触,向他们学习。
  • 把你的想法说出去,看看别人怎么回应的。从别人的回应中学习。

除了这些,下面是我个人想给你的建议——

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (24 人打了分,平均分: 4.04 )
Loading...
预发布环境,Tag发布机制和可重复的部署过程

预发布环境,Tag发布机制和可重复的部署过程

下面文章由网友吕毅投递,源文是:http://blog.lvscar.info/?p=427

—————————————————————————————————————————————

周末聚会,无意间聊起建筑行业。自己是搞软件开发的,我们的行业从建筑设计/施工过程中借鉴了大量的概念,隐喻,名词。可以说软件就是现实中伴随整个人类历史发展的“建筑”在虚拟空间中的投影。有个两年前问过其他朋友的问题,这次友人又再次提起,“为什么建筑设计过程中没有普遍性的采用版本控制呢?” 瞎扯了一干各种原因后,我们几乎同时想到一个名字”Joel”,建筑设计行业或许缺乏像Joel Spolsky一样十数年如一日,把自己丰富的经验和深入的思考转化成一篇篇文章以向新人传授软件开发过程中那些容易被忽略的概念。高傲的黑客们会对CMMI之类的认证抱以鄙夷之情,但对Joel整理出的12条写出更好软件的”最佳实践”,大家甚至把此称为审视其他团队开发过程的“Joel TEST”以推崇

这12条测试如下:

1. 是否启用版本控制?

2. 是否可以一步构建?

3. 是否进行每日构建?

4. 是否有bug跟踪列表?

5. 是否在修改bug后,才开始写新代码?

6. 是否及时更新工作计划?

7. 是否在开发前编写了大家一致认可的功能文档?

8. 是否有安静的工作环境?

9. 是否在使用最好的软件开发工具?

10.是否有专职测试人员?

11.是否在面试时以实际编写代码来检查求职者?

12.是否利用陌生人进行可用性测试?

你所在的团队符合其中的几条呢? 觉得这些条目太一般,软件开发原本就该如此? Joel Test写于十年前,一个Windows XP,Mac OS X,Ubuntu都还没有面世的年代。 如果你觉得这些条目有些过时了,Google中搜索“Joel Test”,你可以看到这十年内很多对此进行更新的尝试, 比如这两个页面“The Joel Test Update for 2010″,“Joel Test for web dev”.

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (9 人打了分,平均分: 3.11 )
Loading...
欢迎攻击宝酷

欢迎攻击宝酷

相信大家都发现昨天下午2011年2月16日,下午从2点到6点,宝酷基本打不开。原因是服务器受到了黑客攻击。从互联网上几乎ping不通服务器(丢包率60%以上,ping时延巨大,是平时的10倍以上),我勉强登上服务器查看了系统负载,相当低,于是停止了Apache,发现网络ping马上恢复正常。于是,我启动Apache,再使用iftop查看了一下TCP链接的带宽消耗,发现有那么一两个链接把服务器带宽全部吃完,于是我记录了下IP地址。攻击在下午6点时准停止,就像我们正常下班一样。

宝酷受到很多攻击,不过,基本上都是一些注入式的攻击,都是想取得一些权限的攻击。这是第一次受到不以取得权限为目的,而只在以影响宝酷正常运转的攻击。

我不竟想到了几个问题:

  1. 为什么要攻击?这只是一个技术blog,这样的攻击目的是什么?
  2. 黑客攻击的背后总是有相关的利益冲突的,不会是没有动机的攻击。

所以,我一直在想,是什么样的利益冲突导到宝酷被攻击的?这个BLOG得罪了谁呢?我这个小小的个人的BLOG触动了谁的利益呢?任何事情总是有因果关系的,我很不自然地想到了最近我发布的几篇文章……

欢迎攻击宝酷!我很乐意看到某些人生气的样子。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (27 人打了分,平均分: 4.30 )
Loading...
Web开发人员速查卡

Web开发人员速查卡

无论你是多牛的程序员,你都无法记住所有的东西。而很多时候,查找某些知识又比较费事。所以,网上有很多Cheat Sheets,翻译成小抄也好 ,速查卡也好,总之就是帮你节省 时间的。之前给大家介绍过Web设计的速查卡25个jQuery的编程小抄,还有程序员小抄大全,今天转一篇开发人员的速查卡,源文在这里。下面的文章我就不翻译了。

HTML Cheat Sheet

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (15 人打了分,平均分: 3.87 )
Loading...
TDD并不是看上去的那么美

TDD并不是看上去的那么美

春节前的一篇那些炒作过度的技术和概念中对敏捷和中国ThoughtWorks的微辞引发了很多争议,也惊动了中国ThoughtWorks公司给我发来了邮件想来找我当面聊聊。对于Agile的Fans们,意料之中地也对我进行了很多质疑和批评。我也回复了许多评论。不过,我的那些回复都是关于中国ThoughtWorks咨询师以及其咨询的方法的。我对Agile方法论中的具体内容评价的不是很多,所以,我想不妨讨论一下Agile方法论中的具体的实践(以前本站也讨论过结对编程的利与弊)。

那么,这次就说说TDD吧,这是ThoughtWorks中国和Agile的Fans们最喜欢的东西了。我在原来的那篇文章中,我把TDD从过度炒作的技术剔除了出去,因为我还是觉得TDD有些道理的,不过,回顾我的经验,我也并不是很喜欢TDD。我这篇文章是想告诉大家,TDD并没有看上去的那么美,而且非常难以掌控,并且,这个方法是有悖论之处的

TDD简介

TDD全称Test Driven Development,是一种软件开发的流程,其由敏捷的“极限编程”引入。其开发过程是从功能需求的test case开始,先添加一个test case,然后运行所有的test case看看有没有问题,再实现test case所要测试的功能,然后再运行test case,查看是否有case失败,然后重构代码,再重复以上步骤。其理念主要是确保两件事:

  • 确保所有的需求都能被照顾到。
  • 在代码不断增加和重构的过程中,可以检查所有的功能是否正确。

我不否认TDD的一些有用的地方,如果我们以Test Case 开始,那么,我们就可以立刻知道我们的代码运行的情况是什么样的,这样可以让我们更早地得到我们实现思路的反馈,于是我们更会有信心去重构,去重新设计,从而可以让我们的代码更为正确。

不过,我想提醒的是,TDD和Unit Test是两码子事儿。有很多人可能混淆了自动化的Unit Test(如:XUnit系例)和TDD的软件开发过程。另外,可能还会有人向鼓吹“TDD让你进行自顶向下的设计方式”,对此,请参阅本站的《Richard Feynman, 挑战者号, 软件工程》——NASA的挑战者号告诉你自顶向下设计的危险性。

TDD的困难之处

下面是几个我认为TDD不容易掌控的地方,甚至就有些不可能(如果有某某TDD的Fans或是ThoughtWorks的咨询师和你鼓吹TDD,你可以问问他们下面这些问题)

  • 测试范围的确定。TDD开发流程,一般是先写Test Case。Test Case有很多种,有Functional的,有Unit的,有Integration的……,最难的是Test Case要写成什么样的程度呢。

    阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (34 人打了分,平均分: 4.15 )
Loading...
GDB中应该知道的几个调试方法

GDB中应该知道的几个调试方法

七、八年前写过一篇《用GDB调试程序》,于是,从那以后,很多朋友在MSN上以及给我发邮件询问我关于GDB的问题,一直到今天,还有人在问GDB的相关问题。这么多年来,有一些问题是大家反复在问的,一方面,我觉得我以前的文章可能没有说清楚,另一方面,我觉得大家常问的问题正是最有用的,所以,在这里罗列出来。希望大家补充。

一、多线程调试

多线程调试可能是问得最多的。其实,重要就是下面几个命令:

  • info thread 查看当前进程的线程。
  • thread <ID> 切换调试的线程为指定ID的线程。
  • break file.c:100 thread all  在file.c文件第100行处为所有经过这里的线程设置断点。
  • set scheduler-locking off|on|step,这个是问得最多的。在使用step或者continue命令调试当前被调试线程的时候,其他线程也是同时执行的,怎么只让被调试程序执行呢?通过这个命令就可以实现这个需求。
    • off 不锁定任何线程,也就是所有线程都执行,这是默认值。
    • on 只有当前被调试程序会执行。
    • step 在单步的时候,除了next过一个函数的情况(熟悉情况的人可能知道,这其实是一个设置断点然后continue的行为)以外,只有当前线程会执行。

二、调试宏

这个问题超多。在GDB下,我们无法print宏定义,因为宏是预编译的。但是我们还是有办法来调试宏,这个需要GCC的配合。

在GCC编译程序的时候,加上-ggdb3参数,这样,你就可以调试宏了。

另外,你可以使用下述的GDB的宏调试命令 来查看相关的宏。

  • info macro – 你可以查看这个宏在哪些文件里被引用了,以及宏定义是什么样的。
  • macro – 你可以查看宏展开的样子。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 4.20 )
Loading...
Error handling in Egypt

Error handling in Egypt

以前发布过《C语言的错误处理》一文,不过今天想说的是Egypt的“错误处理”。埃及的事闹得挺大的,国外和中文twitter上更是炸了锅。不要以为程序员就只会写程序——看看程序员举出来的标语吧。呵呵。

Error handling in Egypt

当然,作为程序员来说,这段代码显然还需要重构:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (12 人打了分,平均分: 4.00 )
Loading...