2007年12月27日
快离开目前的公司了，前不久，当我提出离开的希望后，我的头，找我谈了一次心，谈话的过程中，他说了一句：“你不够自我，考虑的牵绊太多”，其实在这之前，我一直以为自己很自我，并且觉得这应当是需要克服的障碍之一，当听到这句话的时候，不由得心里顿了一下，出乎我的意料。
在这之中，领导也给我提过，将产品的规划、开发完全交给我来处理，我拒绝了，其实我之所以想离开，表面上看起来是一些小冲突，实际上，这些小冲突应该不至于让我如此坚定不移的要离开这里，真正离开的原因是我实在不愿意在这个年龄段去为一件让我感受不到希望，感受不到提高的事情浪费青春，即便给的待遇在这里还算不错，我这个人想来比较悲观，我会担心如此浪费青春，不得长进的话，数年后，将何去何从，我很是担心，扯远了，所以，如果能够掌控产品的整个过程，无论对于信心，还是长进，我都应该是满意的，但我还是拒绝了...
首先，我都不下意识的就觉得自己应该拒绝，缺乏接受的勇气，然后，我会去分析，我自己是否又能力做好，对于产品规划，我也并不是特别熟，我如何面对之前负责的同事，我在公司的形象如何转变，我如何与一些我不爽的人共事，一切一切，都成了障碍，光是靠嘴说，我也明白，其实没什么大不了，其实没什么问题，你工资照拿，又不会对你有什么损失，还是个不错的机会，为什么不接受，为什么不敢接受，有什么理由，是的，但当身临其境的时候，担心就会出来，会考虑太多，会考虑失败，无论成功或失败，对我个人都没损失，所以，如果直接一些，自我一些，答应下来的话，最多是某些时候会让自己感觉不好，尴尬一下，为什么不接受呢？
我问自己，但却没有答案。
特性：
1、本身基本上不做任何存储方面的工作，全部使用第三方的，只是提供一个干净、稳定的API接口，用着放心。
2、缓存依赖、过期策略、失效通知等基本功能都支持。
3、支持TAG方式的缓存读写。
4、支持一种比较特殊的分布缓存模式：各个本地节点（比如某个ASPNET进程）将缓存存储于本地进程内，而非走TCP等协议存储于远程，然后有一个noti服务器，当某个节点的某个缓存失效后，会发消息通知noti服务器，noti服务器再去通知所有节点，使各节点缓存失效，通过这种方式来确保各节点版本的同步，这样做的好处在于，可以将一些很频繁获取但数据量又不是特别大的数据存放在进程内，这样可以节省远程通信、反序列化的时间成本，提高响应速度，并且没有在GET的时候去核对版本，而是SET的时候去通知节点失效，是因为通常缓存的SET的比例都非常低，而GET的比例非常高，并且通知的操作是异步的，所以不用担心写操作导致的响应速度降低。
5、自动的缓存命中率管理，这个也算个重点功能，主要是可以通过判断缓存的读的次数，再辅助一定的规则，来确认缓存的命中率是否足够高，并且可以根据这个命中率的高低来决定缓存的存储位置，特别低的就不缓存了，比较低的存磁盘，再高点的就存远程服务器，实在高得没法的，存本地进程，至于某种存储方式选用具体哪个存储引擎，依然是可以配置的，至于如何计算命中率，也已经做成PROVIDER模式，可以自行更换，如果你觉得自己有更合理的计算规则，也可以自己写个PROVIDER。
下载地址，包含源代码哈：http://code.google.com/p/heycacher2/downloads/list
功能多简单的，每天定时从VSS上获取代码，然后编译SLN。
另外，还提供了个WCF的接口，可以远程调用，触发其获取代码并编译。
地址：http://code.google.com/p/vssdailybuilds/downloads/list
设计思想：
* 本质上，这就是一个用于粘合各种缓存引擎的东西，并增加了一些小巧的高级特征，自己不做任何实现，
* 仅仅对目前的各种缓存结构进行包装处理，并在保证兼容性的情况下尽可能实现一些实用的特性
*
* 确定性特征：缓存引用机制、分布的过期通知机制
*
* 不确定特征：远程依赖、多级缓冲机制、
*
* 已完成特征：基础功能、引用机制、分布过期通知、
*
* 未完成特征：多级缓冲机制、不依赖任何缓存引擎的有效性检查
*
* -- 特征介绍 --
*
* 分布过期通知：很大部分缓存的数据，读的比例远远大于写，也就是所谓的高命中率，这样一来，我们希望将这些数据，直接缓冲在各个本地节点的进程内，降低
* 读取时候的通信成本，提高响应速度，而在写的时候，由各个本地节点发送一个通知到中央通知服务器，再从这里分发到各个节点去，使之失效，从而导致缓存的
* 重加载，实现各个节点的缓存版本同步。
*
* 多级缓存：一个新设想，当一个key的数据被set到缓存的时候，并不实际缓存，仅仅找个地方存下这个key以及他的set和get次数，第2次再SET的到文件缓存中，
* 第3次的时候SET到内存或者远程的如memcached当中，这样可以有效的提高缓存命中率，解决因为搜索引擎进行全站扫描等引起的低命中率问题。
*
* 不依赖任何缓存引擎的有效性检查：针对文件缓存等，可以将缓存包装后存储，读取后解包，校验过期等有效性，最后逻辑判定是否有效，是删除还是返回。
*
* 引用机制：有的缓存，内容是一样的，但需要多个key，主要目标是解决这个问题。
*
* 远程依赖：有了分布通知的话，这个功能多少有点鸡肋，当初的目的是在本地建立一个TABLE存储缓存的KEY和依赖条件，当条件触发后，会通知远程服务器，
* 并可能进一步通知各节点，缓存失效了。
*
大致就是这样，代码开源，BSD，http://code.google.com/p/heycacher2/
现在还是一个基础版本，会不断的完善实现，但已经过基本的压力测试了，有兴趣的朋友可以一起来参与，众人拾柴火焰高。
1、软件开发过程中的质量细节，绝对是客观评价一个程序员功底的因素。
2、架构是哲学，一个没有融入自身对哲学思想理解的架构，只能是照虎画猫，成天把多少种设计模式挂在嘴边，只能在原地徘徊，难以前进。
3、一个健壮的开发流程，即便丧失一定的效率，但会有效的降低协作成本，从而降低总体成本。
4、假若连接口的重要性都还不清楚，就别来侃什么设计模式。
5、假若UI里充斥着大量和显示控制无关的代码，不够轻薄，就别来侃什么几层架构什么什么的。
6、别让程序员去切HTML，更别在切HTML的时候去考虑CSS该如何写，假如一边切HTML一边写CSS，那么永远不会得到一个高效的协作开发过程。
7、假若连自己编写的代码质量都不能保证，充斥着大量的低级BUG，就塌实点，先保证自己的代码质量够高后再来考虑别的。
8、一个好的架构，是在能够满足需求以及潜在需求的同时，保持代码尽可能的精简，有多少人能够把握好这个平衡呢？但至少我们可以时刻提醒自己，抓紧最重要的，放弃不必要的。
最近大伙忙着过年，园子也格外冷清，貌似我总是写一些似事而非，和技术关系不大的东西，还总爱往首页发，其实主要是想寻得一两个知音，闲下来后可以聊上几句，如同那个什么青年一样，发点感慨，发点牢骚，调节下情绪，也感谢各位的容忍，特别是这的主人，呵呵。
最近过年，生了场病，之前项目又突然出了点意外，流年不利啊，春节一过，今年正式进入我的本命年了，呵呵，或许小迷信一小也该去弄个红内裤什么的穿一穿，呵呵。
闲话扯了不少，发点感慨吧，三个字：“平常心”，最近突然觉得自己过去太勉强，凡事都想争个一二，有这个劲头，我觉得还是不错的，但如果这个劲头过了，或许也是不好的，再好的钢，硬度如果太高，反而会更容易折断，是不是因为太高的硬度，让钢材丧失了韧性，这方面的科学解释，我不是很清楚，意思上，或许是如此。其实做人做事或许也是如此，淡定一点，或许能够走得更远，不能说凡事不争，但也无需勉强自己，清楚明白自己的目标是什么，然后朝着这个目标努力，但不要追求一开始就爆发出全力，将力量蕴藏，缓慢释放，恐怕会更接近目标一些。
其实做事情吧，做好自己应该做的，自己觉得对的，就足够了，至于能否成功，何必去计较呢？之所以别去计较，是因为自然的力量太强大，今年的冻灾就可以体现，人的力量不过是那么的微不足道，所以，是不是和可以心态放得平和一些，把自己应当做的，认为正确的事情做到做好，速度上能快些当然是好的，但真的不需要去执着的、过分的去关心事情的结果，让自己的心态轻装上阵，是不是更好？如果过分追求事情的结果，当途中遇见困难与挫折的时候，打击如果足够大的时候，不知道是否有足够的韧性度过难关，这与平时管理中的进度控制等科学方法相违背，但假如我们是在创造，又如何能以科学的标准来裁定呢，创造本身就是在一定程度上对过去的一些事物的否定与破坏。所以科学的管理方法，不一定适合任何一个时刻，毕竟，MS收购YAHOO让我们看见了过去的霸主的辉煌与无奈，这样的事情总是在重演，新的战场一开始总是毫无规则的丛林规则...
认清楚自己的目标，做好自己应该做的事，自己认为正确的事，坚持己见，不断修正，蕴藏力量，缓慢释放，淡定，随缘。
发到首页热闹活跃下气氛，年过了，大家该收收心了：D
1、新浪，采编人员或原创或转载，产生内容，吸引用户与注意力，再根据新浪本身的定位，将这些注意力销售了出去，重要形式为形象广告，产生经济效益后，以工资+奖金的形式发放给采编人员，这时候连接生态链的内容是各种新闻等采编而来的狭义的内容，于是新浪是一个媒体，用户贡献注意力，获得咨询，编辑提供内容，获得经济收入，SINA搭台。（SINA的采编人员需要全职工作为内容而付出很多时间与精力，于是收益相对较多）
2、腾讯，开发软件并购买服务器带宽等资源，在多年前就免费为用户提供IM服务，也曾试图走广告销售的道路，可惜由于用户定位以及IM作为载体等实际因素，广告销售的路途并不顺利，于是也造就了据说2000年差点以50万贱卖的事，卖不掉后继续发展，最终发现，用户对QQ的依赖已不是一点两点，太多的用户，随着高中毕业进入大学，和过去的朋友天各一方，QQ成了保持联系的主要手段，当然还有太多的因素，最后让用户将自己的关系都放入了QQ里面，QQ号码不再是数字，于是腾讯开始提供各种增值服务，大赚特赚，而且还不是赚的第三方的钱，而是直接赚的用户的，而用户呢，可以不花钱继续享受基本的IM服务，而且用着还不错，为了让自己的QQ形象或者空间更漂亮，需要花点小钱，但用户很乐意，因为这些东西如同衣服一样，影响着一个用户在另一个用户心目中的形象问题，满足了用户的这个心理需要，钱还是不难赚的，在这里，食物链的内容是用户的关系与用户之间的各种行为，用户在使用的同时无障碍的贡献着这些内容，得到的是贡献时使用的IM服务，用户并不需要为贡献这些物质付出什么努力或者代价，利用这些内容与用户的心理，销售增值服务，这是腾讯的生态链。（QQ的用户仅仅是在使用的过程中顺带着提供了内容，为提供内容而付出的努力几乎没有，所以所得也几乎没有。）
3、土豆等视频网站，购买带宽等资源，提供视频服务，不过都没有版权，其中有一个叫ku6的网站，开了个先河，允许用户上传内容，并根据内容的播放次数获得收益，而这些收益最终自然是通过销售广告获得，只是ku6与所谓的“内容提供者”分享了一下，这虽然只是一个起点，而且问题很多，倘若将此方式铺开来用，或者即便是电影，版权问题也会得到解决，于是他们也是媒体，而且依照ku6的方式，也将建立一个完整的生态链，否则，单单依靠少部分分享的热情，我不知道热情如何持续。（视频的上传用户，根据上传的量来决定起所得）
4、各种博客网站，比如园子，其实道理和上面一样，写博客的人，有的为了出点小名，有的为了找到志同道合者，也有人为了记录起来方便以后看看，或者发泄一下，或者整理思路，比如我主要目的就是寻求志同道合者以及整理思路，DUDU提供了这样一个平台，但上面提到的这些需求，并不是必须的，或者说只有园子可以提供的，或许你会说园子的名声还是不错，是一个很独特的平台，所以于是我们也有看到，有的人逐渐的写，或者出名了或者没出名，但肯定的是逐渐的热情退却了，写得少了。。。当然，借着名声，也逐渐的进来了新鲜血液，这就是DUDU需要思考的了，如何吸引用户一直写一直写。。。特别是一些核心用户，提供高价值内容的用户，所以BSP的生态链其实不比视频站的结实。
废话了半天，其实就想说明一点，不管是sina那样的自行组织内容也好，或者QQ以及所谓的web2.0网站，依靠用户提供内容也好，都需要让生态链中的每一个参与群体获得与付出的努力同等的所得，主导者赚得中间的差价，于是这就是一桩好生意。
所以，咱们想做社区也好，分享网站也罢，任何任何，或者如同QQ那样给用户提供一种服务，这个服务用户很需要，并且能够在使用该服务的同时不用付出额外的努力就提供内容，或者就直接点，给提供内容的用户一些他认可的价值吧，比如钱。