|
|
|
|
最新动态
xyb 
在6 天, 4 小时前
xyb
在2 月, 1 周前
xyb
在2 月, 2 周前
xyb
在2 月, 3 周前
xyb
在3 月, 1 周前收藏了故事
xyb
在3 月, 2 周前
评论了 软件创业月月谈 － 关于互联网广告与推广. | 我也只是看到人家的日志，觉得以后可能会有用，就留意一下。GA我自己是很少用的，实在没啥经验。beijing open party有空一定去参与、学习一下。 |
|
xyb
在3 月, 2 周前
评论了 《好看簿信用机制设计》意见征集
. | 数字很容易被理解为一种定量的指标，便于理解，这是它的好处。但一个关键是，这个数字背后的含意。改名为活力指数，便于解决用户的困惑，值得肯定。不过，对于大野狼解释的这个积分的目的，似乎数字在这里起到的作用还不是特别明显。当我遇到好看簿上的另一位用户时，我是如何对他/她产生第一印象的？一个积分或者活力指数在这个情境中能带来那些帮助？用户们的兴趣点千差万别，而且非常发散，我怀疑一个数字是否能起到促进理解的作用。看到一个高的分数，我可能知道这位用户很活跃，或者比我在这个网站里的资历更老。但我还是要看一下他/她发表过什么样的故事，参与过那些讨论，才会有一个客观的认识，知道我们是否兴趣相投。如果是针对促进了解和沟通的目的，那么一个更好的个人首页，能把该用户的各种兴趣点充分展现，让我一目了然，我觉得会比一个分数更有效。
不过，听起来活力指数似乎会有用，只是我找不到它最合适的地方。 |
|
xyb
在3 月, 2 周前
评论了 FreeBSD systat. | 推荐一下linux里的atop，虽然跟systat差一点点，但总体还是很不错地：http://www.atcomputing.nl/Tools/atop/ |
|
xyb
在3 月, 2 周前
评论了 《好看簿信用机制设计》意见征集
. | 蚂蚁说得没错。与现在好看簿的这个积分机制类似，v2ex有个金融系统，按照livid的解释，与现实世界类似，必须要处理好金融膨胀的问题。积分机制大量给用户送分，就像超量发行货币，如果消费手段比较少，必然金融膨胀。正常用户可能开始热衷于赚取积分，但到一定程度之后就会厌倦这种游戏。而spammer则可以很容易获得积分，继续做恶。
要对付spammer，我想有几个可以做的事情。第一，是后台的处理，最好有自动的过滤算法及时发现疑似行为；第二，设置投诉途径，让普通用户帮助监察，比如像gmail一样增加report phishing按钮，作为后台过滤算法的重要数据来源；第三，尽量由人来做最后的判断，决定是否违规、是否处罚、如何处罚，避免机器误判，影响用户正常使用。
我决定得有一点很重要，这种处理机制最好在后台处理，具体细节对用户来说是黑箱操作。要知道有很多专业的spammer，这行很赚钱，有很多聪明的人，本来对付藏在幕后的他们成本就很高，再把自己的anti-spam战略全盘托出，我觉得不大好。而一般用户对网站的anti-spam如何运作的基本是不关心、不感兴趣的，只是为了应付spammer而弄个积分系统或其他系统来干扰用户，反而不利于网站的核心目标和用户体验。spammer与合理使用的用户是两类人，不用搞什么民主、公正，该封就封，他们也不会因为这来投诉，因为投诉的时间还不如改进一下机器人，发更多的帖子增加经济效益。只要注意不要误封普通用户，spammer应该来一个杀一个。 |
|
xyb
在3 月, 2 周前
xyb
在3 月, 2 周前
xyb
在4 月, 1 周前
评论了 打破沟通的藩篱
. | 邮件用gmail，即时通讯用msn和google talk。 |
|
xyb
在4 月, 2 周前收藏了故事
xyb
在5 月, 2 周前加入小组
xyb
在6 月, 2 周前回复讨论
share nothing vs. cache. | 不错，切换到不同方式是不太容易的，不要说缓存到share nothing，就是一个已有的老系统切换到用缓存的方式也要费很大的劲。
如何把缓存更好得应用到系统中也是个问题。django提供一个统一的缓存接口，倒是很方便；但有好几个地方可以插入缓存机制：html、view/controler、model等等，搞得太粗放后期开发不好办，搞得粒度太细又会太琐碎、效率不高。因为django有自己orm的关系，好像找不到特别理想的插入缓存机制的地方。 |
|
xyb
在6 月, 2 周前增加联系人
xyb
在6 月, 2 周前
xyb
在6 月, 2 周前回复讨论
xyb
在6 月, 2 周前回复讨论
xyb
在6 月, 2 周前回复讨论
share nothing vs. cache. | 现在看起来，其实如果一开始就打定主意用share nothing，反而开发和管理会更简单，能降低系统的复杂度。
在代码里到处嵌进去读取、更新缓存的代码并不那么好看，增加修改功能时要时刻留意缓存的一致性也不那么轻松。当数据太多需要切分数据库的时候呢？所有缓存相关的代码都得检查一遍，用新的方案替换。如果一开始就是share nothing，前台服务和后台存储两个系统能分得更清晰，耦合度低，可以分别升级，容易维护，从长远来看似乎更节省工程师的时间，不过初期投入会更高一些。 |
|
|
|
