易栈网-膘叔

说实话，本文的内容真的不可以相信，至少在国内没有多少人会这么用。国内据我所知，做开源的没几个混的好的，除非已经是历史优久的那些。当你的开源做了一两年之后，你会发现你的项目已经被人改的面目全非，换个名字在卖钱、在运营，难道不是吗？国内的这些状态实在让人对做开源实在不是一个好的平台。忍忍吧。

看看别人是怎么说的：
上周我在 PHPUK 上面讲了一些关于开源项目的内容。我想把它们整理一下都记录下来，以免忘记。也许我不太适合来给出一些这方面的建议，但这些都是我运营 joind.in 的一些真实、重要的总结。
社区（Community）

你喜欢一个项目，分享了它的代码，并且公布了它，这就算是开源项目吗？在我看来这不是，开源项目必须有一个社区。作为兴趣，你这么做可以，但是你想要其他人也参与这个项目，事情就大不同了。

为了让别人参与贡献，你必须建立一些基础设施，可以让别人能够顺利沟通，看到项目的进展。作为项目的负责人，你需要管理这些基础设置。Joind.in 使用google groups的邮件列表，问题跟踪系统（atlassian为开源项目提供免费的授权）以及IRC频道。我们也有一个博客，以及twitter账户来发表 公开的声明。我们使用了多个邮件列表，外联、功能、开发。这样就可以让不同的人选择自己感兴趣的信息，而不会被其他信息淹没。

如果你的项目还不是很有名，你需要通过博客，twitter，stack overflow等各种渠道来让人们知道它。

说明文件（README）

在项目能获得其他人的贡献之前，你首先要保证其他人能顺利的配置你的项目。你最好在网页，wiki，博客，以及项目中都有README信息，因为你不知道人们习惯从哪里看这些信息。

项目规划（Roadmap）

有一个清晰的项目规划是非常有用的。当用户给你提出一些新功能的时候，你可以说“it's on the roadmap”，或者让他们去邮件列表讨论。人们也知道你们正在干什么。

贡献代码（Code Contributions）

这一点有点复杂。大部分的开源贡献者只对他们感兴趣的东西感兴趣，其他的功能或者系统的其他部分很难引起他们的兴趣。但是恰恰其他部分是系统的关键部分。 还有，作为项目负责人，你需要及时审核，测试，合并，部署这些贡献的代码。当某些贡献不能被采纳的时候，你需要告诉别人为什么，以及如何改进。

以我的经验来看，区分真正有用的贡献，以及一般般、没用的贡献是比较困难的。有可能那个贡献者提交了代码以后就消失了，剩下你来维护这个代码。这个问题似乎只能靠直觉去解决。你能做的就是诚恳的对待贡献者，说出你心里真实的想法。

透明化（Transparency）

对我来说，这是运营开源项目最重要的一点！人们能看到代码，能看到问题列表，邮件列表，甚至持续集成服务器。我可以向人们求助，指出哪段代码不工作。有时候，在我还没有意识到问题的时候，就会有人跳出来指出我的错误。

对于和我一起工作的人来说，他们可以看到哪些“pull request”是开放的，谁评论了什么，哪些代码在什么时候被采纳了。我会提交我参与的所有分支到githut。所以当有人问我一个功能的进度的时候，我往往直接告诉他们最新的版本号。

把项目的所有东西都拿出来给人看有点像是在熨烫一件脏衣服，让人有点不适。但是这样做的好处是你可以听到各种各样的建议。好几次我在twitter上贴出了一个bug链接寻求帮助，有不少人去留言，给建议，也有人直接去测试代码。
----EOF----
上文来自：http://cnbeta.com/articles/175607.htm
说实话，社区这东西，由于在国内私人不能架设论坛，其实有点让人蛋疼（虽然很多人都私自架设了），在社区内有四种人：潜水员、用户、开发者、骂人者。任何一个论坛都会有第四类人，除了黄色网站吧。真正参与到项目中的人真的很少，往往很多人都是索取者。痛苦啊。

jpeg大家都知道，它有一个精度的概念，一般如果我们用GD库做缩略图时，默认精度就是100，这时候压缩的图片还是和原来一样清晰，但事实 上我们不需要这样的清晰，毕竟在网页中72的dpi就足够了。所以当我们把精度设置为72时，尺寸会明显下载。下降的很厉害哦。
于是，我在我们目前的项目中用上了自动根据 URL生成了缩略图，指定了某个域名下的图片生成。但最终发现所生成的图片都是超级大，很让我意外，于是将精度调整为72，但效果仍然这样，没有变化，这是为什么呢？
排查了很多原因，都没有发现代码上有任何问题，最终在检查apache的conf文件时发现，我将某个serveralias写错了。我在多个域名中间用","分隔了，事实上多个域名应该是用空格分开。
那可能您又要说了，如果这个域名不存在，那岂不是会报错？是的，事实上就是错了，但。。。。我在默认的网站配置里也有一个自动生成缩图的配置，那个配置中，精度是100.所以，死活排查不出问题。

当然看到这里就知道，我的问题还是解决了。否则我就不可能在这里记录笔记了。
看过我博客的人都知道，我。。。粗心犯的错误太多了。哎。

文案的作用真有那么大？文案重要大家都知道，只是可能都没有人关注过究竟有多大。
冯大辉在博客中提到：

转化率多了20%，这是多么恐怖的一件事情啊，文案差的例子，冯也在文章里举例了：

冯在博客里提到说豆瓣的产品经理每次在改版前后都会写上一篇博文来介绍新产品或者新功能，他更是表示每篇都看，就象这一篇中提到了：

以上这两段内容是“关于豆瓣”里的两段话，据说到现在都没有改过，但豆瓣却仍然每期都在改版，当然也是有成功有失败：

哎，

看来，任何产品经理做出来的产品也不是都能够被大众所接受，即使你的想法再好，但超前了就一定OK了，估计，到去年再做这个旅行分享一定会不错，因为，去年驴妈妈、悠哉等都在大力推广，那时候再做这样的分享站一定会很OK。
当然我也不是知名和资深的产品经理，所以，我也只能放放屁，即使我的想法再多也无法让它实现。

结对编程在我们现在的工作中真的没有使用这玩意。极限编程也没有用到，我们还是安稳的在一步一步的开发。。。但不代表我们没有尝试过。
其实，在07年的时候，那时候和一哥们就尝试过结对，效率确实上升了不少，但后来仔细想想，正由于两个人水平相近，这样的结对却没有真正带来了效率上升，反而还不如两个人单独开发，事后合并代码。虽然有一些BUG，但总体代码却多写了很多。再过了一段时间，也是和一朋友结对，但效率更低，因为两个人的水平不一致，水平高的受不了水平低的一些低级错误，水平低的却看不明白水平高的在做什么。痛苦。。。后来就放弃了这种想法。
以下是原文：http://www.cnbeta.com/articles/174866.htm
在过去的几年里，我有过许多结对编程的经历。有时在我的团队里进行，有时在客户那里，有时在coding dojo(一种编程模式，几个程序员一起合作完成一个任务)，有时在我的开源项目里。对于那些知道如何结对编程的程序员来说，这种模式很棒，很高效。
但是你不能指望在两个程序员面前摆台电脑，就指望他们一开始就做得很棒。结对编程需要学习，程序员需要知道实施者（敲键盘的人）和领航员之间的区别。下面来看看些细节。

在结对编程中，我遇到了一些误区，列在下面。
一、领航员误区
1. 发号施令者
喜欢发号施令的人总是对敲键盘的人说：“到末行，加个反括号，然后…”。他不去关注解决方法和下一步该怎么做，而过度关注一些编程细节。
事实上，他希望他自己来掌控键盘。所以当你碰到一个喜欢发号施令的人，那么将键盘交给他吧，转换领航员的角色。
2. 拼写纠错者
拼写纠错者坐在你旁边，纠正你输入的每个错误字符。当然，他没有时间来真正的进行导航。
和纠错者商量一下，当他给你纠错的时候让他请你喝一杯咖啡（或者任何你想要的东西）。
3. 吹毛求疵者
吹毛求疵者会指责你写的每行代码。当他的意见正确时，他会一意孤行，不用你已经写好的代码，而完全照着他的想法。
就如自由爵士音乐人都是复用其他乐队成员的音符，来构造成一首曲子一样，好的结对编程也应基于现有的基础上进行推进。
试着转换角色，也许吹毛求疵者就会变成一个目中无人的人。
4. 默不作声者
默不作声者是那些几乎不发表意见的人。他仅仅坐在那里看着你工作。
试着问下他对你的方法有什么意见，或者问他下一步该写什么测试代码。
5. 心不在焉者
心不在焉的人企图让你分心，而不是提供给你有建设性的意见，帮你解决问题。
那么让他离开吧，比起一个让自己分心的人而言，不如一个人编程。
二、实施者误区
1. 深藏不露者
深藏不露者仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码。关于该用什么方法，该选择哪种设计，领航员和实施者之间完全没有交流。
领航员需要问问深藏不露者关于他的计划或想法。
2. 目中无人的人
目中无人的人通常忽略领航员的所有建议，大多数是因为他们觉得自己的想法或编程技能更胜一筹。
当碰到一个目中无人的人时，立即停止结对编程吧，开始下一个任务吧。自大的人往往也不会是个好的领航员。他们很可能变成发号施令者或是吹毛求疵者。
3. 不知所措的人
不知所措的的人往往不习惯结对编程，非常紧张，不能掌控全局。
确保自己的领航员角色做到最好。小心的提出意见，对于不知所措的人主要给予鼓励。
但是，大多数程序员开始都是这种情况。所以，不要对他们的结对编程期望太高。让他们首先成为一个领航员，或者让能够很好的处理人际交往问题的领航员在他们旁边。
4. 跳跃性很大的人
跳跃很大的人喜欢在代码中进行大范围的跳跃，这样领航员不知道进行到哪里了。
领航员需要让他慢下来，问他关于他的计划，并确保自己比他知道更多的快捷键。
5. 不熟悉工具的人
不熟悉工具的人不知道开发环境的快捷键，效率非常低。
交换角色吧，让他看看你的技巧。或者打印一张印有快捷键的cheat sheet。
我相信还有其他的误区，如果你有什么想法请写在评论留言吧。
原文: planetgeek.ch  编译：伯乐在线
----EOF---
如果上面的事情真的是真的，那证明我们还是有问题，在结对编程的处理上。但我真不敢尝试了。哎

今天好象VPS崩了一次。上次也有过，不知道是怎么回事。
看LOG也没有明显的记录，郁闷了，看来openVZ还是会有点小缺点，不象xen相对比较稳定。
不知道是否同一台服务器的某些人负载过大导致的，因为我自己的机器还是几乎不占资源的。

纠结啊。
看来要物色便宜的xen服务器了