@keakon 这里的异步处理是为了解决大量Notifications处理时候的性能问题，如果用户量和信息量不多，可以直接去掉Resque的异步任务处理

@keakon 不会错过的，所有未读notifi都存在redis里，而且，这部分代码并没有包含主动push到浏览器端的功能。

关于上面「第三页 #34」 我所发的代码，这部分代码只是刚刚在TextMate随便建个文本手工敲的，并没有在项目里运行测试过，所以可能会存在一些小bug，不过这些代码都是可用并且完整的Notifications功能块代码，是一个完整的功能。

上面的代码如果需要局限Notifications的数量，可以考虑使用redis的list来配合完成，但要写多一些代码来判别list是否有重复的notifi存在，而set本身就可以忽略重复的数据，所以省回这一步。

关于rails的开发效率，以 @Livid 这个讨论 http://www.v2ex.com/t/17897 的Notifications功能作为开发例子，有经验的rails开发人员可以在一个小时内完成，比如以下的代码是使用Redis的Set数据类型，结合Resque（https://github.com/defunkt/resque）的异步处理，半个小时内手工敲出来的，除开空行，总代码行数60行左右，完成了Notifications的创建，并且点击进主题会自动消去相关notif，现在设计是支持大量的notifs，类似于google reader中未读条数显示，200条以上未读提醒会以「200+」来显示。而在性能方面，notif的相关可变处理都是利用redis，时间复杂度都为O(1)，所以只要redis足够快，那么这方面代码就没有问题。
以下是相关代码
http://gist.github.com/1205886

@standme 抱歉，时间有限。而且，我不接项目开发的活，感谢你的信任。

针对 第三页 #20 的「没人可用」语意进行解释，免得造成误会，应该是「手下无可用之人」

「PB2」是程序的代号，「V2EX」是一个社区，我想作为建立人的 @Livid 比我更清楚两者之间的区别，我在主题里通篇没有提到过半个V2EX的字眼，单纯对「PB2」这个程序技术实现作为想法，你一上来回复就一副教训人的姿态来说一通运营之类的，末了还不够解气非得在twitter上来讽上那么几句「说永远比做容易」，这能让我怎么样？在这坐实「眼高手低」「只说不做」的头衔？


而关于运营，V2EX至今还是那么一个人独自的玩具，没人可用，会出现这种情况基本是创立人的原因，抱歉，我真的不觉得这是一个成功的运营。

@fly2never 请翻到第一页看下我最开始的回复，我从来没有否认PB2的构思所需要花费的事情，并且我还在 #3 的回复里特定指出构思的过程才是最花时间的。关于开发周期，有人比我更短，我预计的时间已经不是太短的了，况且我在已经找到一堆现成的gem来完成PB2一些比较花时间的功能。我不知道大家对一个月的1/4的概念是什么，那起码是1/4的收入，还没有加上开发完一个项目后的思路放空期，这个时间段加起来更长。
大家或者觉得奇怪为什么我要提出明确的开发周期，这个只是为了说明竟然我提出这个想法但为什么不自己去实现的却想要让别人去实现，是因为这个时间太长对于我实在不允许（并且这里没有完全排除对rails开发效率的自豪感，抱歉，rails开发人员或多或少都会以rails的开发效率自豪，对外偶尔无意识提出开发周期预测很正常，我跟我团队的人习惯对每个开发项目提出预计的开发周期，不做两个星期以上预测，如果感觉周期超过两个星期以上，会将开发进度分割开来，以能两个星期内完成为好，更多相关请翻到第一页 #94 查看我的回复），或者我在这里将预计的开发开发周期改为1年就不那么得罪人了，但这里某些人为何以自己没掌握的技术就来判断别人的能力？

@makestory topic不一定有major post，如果有只能有一个major post，因为topic不一定有内容主体，可能只需要一个title就够了，所以title是必须的，major post是可选的并且只可一个。


topic.major
topic.replys

这些很简单就可以实现，如果不想在Associations处实现的话，现有的代码基本不需要更改太多就可以实现
#class Topic < ActiveRecord::Base

def major
self.posts.major.first
end

def replys
self.posts.reply
end


上面就可以完成了，但这个写法不符合最新的rails写法，原有写法才是合适的。

@huacnlee 其实根本原因是出现在我预计「一个星期」的开发周期上，@Livid 无法接受「一个星期」完成一个PB2的开发，后面的言论，只不过是自找自说，没趣。

@keakon 想问一个，你觉得现在PB2中相对要花较多时间设计的一个功能是哪个？

@SolidZORO 无论如何，你是我在V2EX上对其专业技能拥有认同感的人之一，即使可能在某些方面欣赏度不一样。其实对有些事情还是笑笑算了，反正吵吵闹闹又少不了我一块肉，不过昨天浪费半天时间的苦果终究要自己偿，今晚忙到现在终于补回了昨天的安排。

@keakon 还没睡。七天的开发时间成本是对PB2现有「不做任何功能和UI上的变化」的rails版本开发，如果将后续维护新增功能的时间成本也计算上去，就太不实际了。

@Livid 开源很多时候并不是一个人贡献代码的结果，恰好，开源最性感的地方是体现在多人对项目的贡献，在 github.com 上，任何有用的开源项目基本都会很好的活着，即使「创始人」不再打理，但总会有新的fork或者其他人接手。

@goophy 期待你的一分钟变rails

@Livid 如果你非得将PB2看作是一个很复杂的系统，那么我只能说你或者是一个很好的设计人员或者产品经理，但却算不上太好的开发人员。

@Livid 非得论战下去？

@reorx 任何涉及到livid的PB2的讨论都会异常诡异

估计当初发帖时间将一星期左右改为一年左右就不会有问题了，这就不会触动谁的G点了，但改为一个月会怎么样？还是会这样引发过多的争论？