总算是第七季前的安慰，我们看到了剧场版的24小时”救赎”，两个小时的故事还是很紧凑，很多线索都展开了，等着剧集来逐步展开。
有人说，喜欢老歌的原因其实是喜欢听这些老歌时候的回忆。
电视剧，电影同样，24小时已经成为生命中不可或缺的7年，每一年都有不同的感受。
Monthly Archive for November, 2008
不用说，大家都知道，这是陈奕迅的歌。因为林夕的词，所以自然优美和流畅。
想起这样的夜里，很多年前，还在格致读高中的时候，并没有太多的理想，因为只在有很多功课和考试测验要应付，天空好像总是灰色的。于是和当时的很多人一样，喜欢抄写那些流行歌曲的歌词，每个人几乎都可以拿出几本厚厚的歌词本。
五音不全，还好有一点创造精神，高中时代除了电脑以外，最多的时间便是花费在写歌词上了，一开始是填歌词，后来也像模像样的创作，可惜没有人去谱曲。唯一一次受用的是代表班级参加学校的革命歌曲歌词重填比赛，用的曲是当年很流行的徐良和王红的”热血颂”，后来得了学校的第二名，还算不错的成绩。
记得是把所有的写的歌词分阶段结集，当然没有出版，而是公公整整的抄写在漂亮的本子上，影响中只记得有一本叫做”云谈风情”，遗憾的是在高三毕业的时候，几本本子全部失踪了，懊恼了很久。如今，当年的文字已经全然忘记了，依稀印象中，是少年的情怀，那些日子每天一个人回家时候，陪伴我的夕阳和云霞。
年少时候，几乎听过当时国内可以听到的所有的流行歌曲，而听过的盒带，也能记住A面和B面的歌，个中乐趣，不是现在google一下就可以搜索到mp3所能体会。
小学时候，黑颜色的胶片，放着”草帽歌”，一遍遍的旋转，是旧居的老唱机。
高一时候，搬家，我急切的将双卡录音机插上插头，直到结婚后，这台陪伴了我高中生涯的录音机还是不舍得扔掉。
大学快毕业的时候又搬家，将一张草蜢的海报留在了自己房间的门后，许多记忆也就封存在里了。
袖珍收音机，CD机，mp3，发展的太快，如今，已经不太懂得珍惜了。
此刻，听着草蜢”心中的歌”，当年的情怀，突然间发现以前写下的每首歌，每个字，其实一直都陪伴我。
好像也是高一时候，上海电视台居然播映了当年的香港一个颁奖礼，第一次看到达明一派的现场演出，也第一次听到Raidas乐队，听到林夕。那时的我，一刹那不知所以的迷茫，或就是因为多年后我回忆起那一刻的悸动依然，快要中年的我和17岁的我，早就有了呼应。曾经的微笑印刻，如今的皱纹。
相关内容
iphone已经出到了os 2.2，真的很猛，之前用ipaq的时候，感觉windows ce好像要一年才一个版本。虽然iphone操作系统的更新不能说每一次都是革命性的，但是每次都增加不少功能。(我用的还是2.02，准备最近升到2.2，因为已经有很多应用要求必须是2.1以上了)
最近总是在考虑如何快速的可持续的进行项目，我相信apple应该也是一个好老师。至少从他们用基于freebsd来做操作系统的思路，就很喜欢，在巨人的肩上，总是可以看得更远。
相关内容
刚才看到最近在百度被cctv曝光的时候扮演了极其不光彩的网站的老板在一些网站上的言论，感觉很可笑，汽车网站多，就说人家是垃圾，在被千夫指的时候，放烟雾弹，扰乱视听，为什么不解释一下篡改标题事件？
企业是否成功，是否长时期的成功，领导人有着非常大的决定因素，比如apple的Jobs，即便apple困难到差点被卖掉，股票一文不值，只要领军人物在，没有什么事情不能翻盘的。
这三年，我所在的网站犯了所有不该犯的错误，造成今天的局面，也好，至少我们知道什么是错的。
用户是不可以愚弄的。一个只会炒作，容不得别人，心胸狭窄的领导，即便包装得再巧妙，获得短暂的成功，终究逃脱不了成为垃圾的命运。
相关内容
从这里看到，原来的网站好像打不开，从gr中复制的。
其实方法非常简单，找到你电驴的安装目录，打开它
然后找到一个叫config的文件夹，打开
找一个叫wordfilter的文本文件，删除它就OK了。
不过提醒一下，随着电驴的每次升级，敏感词列表都是会重新出来的，到时候再删掉就行了。
有兴趣的同志可以看看，电驴都过滤了哪些敏感词。
以上方法目前适用于VeryCD的emule和easymule
相关内容
最近在做实验，看怎么样才能够提高小团队的的项目开发效率。我碰到的场景，相信很多互联网公司也会碰到，在有限的时间、有限的资源情况下完成一个项目，并且在一定时间范围内升级功能达到具有竞争力。
这里定义的小团队是有一个项目经理，1-2个程序员，1个网页设计，测试则是不同项目组交叉设计。
原来存在的问题：
1 团队之间口头沟通多，书面沟通少，项目开发到后期发现会遗漏一些重要功能或者出现原来想到的问题。
2 页面设计和程序开发发生死锁，导致进度受到影响。
3 功能设计描述不清，造成页面设计和程序开发理解上的歧义。
4 测试时间的紧张造成没有很多时间和资源进行错误修正，影响产品质量。
5 由于进度始终不能如期完成，总是有项目的特性没有完成，造成团队疲惫，没有成就感，影响士气。
6 产品开发无法达到设计期望值，所以无法和竞争对手拉开差距，影响公司整体战略。
这里说过，我再借助一下“敏捷开发”这个术语，下面的方法绝对不是真正的敏捷开发，只是觉得这个词可以很好的描述我要表达的意思，当然也可以称呼为“有效率的逼迫性的按照时间管理的项目基于有限资源的小团队开发方法”
首先是准备工作：
1 通畅的电子邮件系统，因为大量的消息将通过电子邮件来传递。这一点我仍然不满意目前自己团队使用的的系统，我理想中的电子邮件系统是google mail企业版，免费，并且7G的容量，加上google日历和文档共享，足够小团队使用了。不用再担心自己的邮件服务器什么时候会出问题，google日历可以和很多中应用同步，不管你是windows，还是leopard或者iphone。
2 trac。我一再推荐使用trac来管理项目特性，简洁有效。除了安装稍微有点麻烦，基本没有缺点，基于sqlite数据库，便于管理。trac支持多人多项目的管理，可以有效的非配工作，不需要再手工写工单了，当然也不需要昂贵的ms project了。trac是免费开源的软件。
3 svn。不用再说了，如果主要还是基于windows开发的话，暂时不要去想git了，用svn足够应付小团队开发所需要的版本管理功能，加上强大的windows桌面端tortoiseSVN的话。
4 im工具，推荐使用msn或者gtalk，后者的好处是所有的对话都会存盘，便于以后搜索。如果你使用的mac的话，那么只有adium了，足够了。windows的话除了原生的那些im程序以外，推荐pidgin，除了可以集成多个聊天帐号以外，还可以支持otr加密方式，这样windows、linux下的pidgin+otr和adium(本身自带支持)之间的对话都将是加密的，基本不能窃听。
开发工具项目不同，各有所长，这里就不说了。
现在说说我设计的开发流程，先来说说要达到的效果：
1 目前设定所有项目在每周可以发布一个build版本，除了第一个b1达到最基本要求以外，之后的b2、b3等等要每周增加需要的功能，功能可能来自用户，可能来自市场竞争所需。
2 每一个build包括功能设计、特性分解、可行性分析、页面设计、程序开发、功能测试、整体测试。
3 根据项目需要完成的指标，一般网站来说，无非是用户数(包括用户活跃度等)、pageview(包括uv)、商品(条目)数量、成交情况等，每周根据数据情况来调整本周build的功能和优先级，来尽可能的完成既定指标。
所以前面说这是一种逼迫式的开发，对于项目管理的要求很高，这不是传统上用个project画一个甘特图就可以的，而是时间和资源的限制，效果的逼近。
目前在公司里，有两个项目采用了这样的方法，刚刚开始不久，还不能说取得很好的效果，不过感觉已经比以前效率高了。
整个方法的实施过程如下：
1 每周一开会讨论本周build要完成的特性，并估计下一个build要做的特性。本周build特性一般在10个以内，排好优先级顺序，按照1个程序员3-4个人天来计算。下一个build甚至后一个build的特性确认主要是列出必须做但是在本周肯定来不及实现的功能，这样可以根据之后的数据分析来再次客观的评估是否这个功能真的是”必须”，或者实现的细节有否和初衷有所差异。另外，这样可以让整个团队从产品角度清楚自己项目在本周会做到什么样子，下周什么样子，对于功能设计、数据监测、测试、市场推广都有益处。一般开会时候要确认项目上线时间和相关工作计划，主要是数据是否有升级、服务器部署是否有问题、数据监测方法、测试计划以及最重要的运营安排。
2 开发，这个就和一般项目没有什么区别，按照规划好本周要完成的特性的优先级进行，所有重要的沟通全部用邮件进行，项目经理需要在最快时间内响应需要决定的事宜，并有可能去调整特性优先级、build特性规划等。
3 bug and fix，当项目在运行的时候，会暴露出诸多小问题以及一些可以改进的UI、UE和功能点，为了不影响原来build在本周设定的目标，这些一律归到bug and fix这个trac上的milestone。然后区分几种情况：
致命bug：立刻修改，因为已经在运行了，所以需要立刻修改。
提升UI和UE：根据本周工作量，纳入本周的build或者下周的build，在下周一的会议上提出。
功能优化：在下周一的会议上讨论，原则上本周build不考虑。
凡是完成了的bug and fix都在close后注明是在哪一个build完成。
4 测试，测试通过邮件做内部测试，一般没有时间和资源做广泛的外部beta测试和用户面对面访谈，就只好不同的项目小组交叉测试了。测试人员可以当着项目经理或者开发人员逐一支出问题在哪里，这样便于项目经理描述问题。所有发现的错误和问题记录到上面的bug and fix，致命错误由开发人员立刻纠正。
5 发布，一般每周四开第二个会，决定是否进行发布，以及发布中可能存在的各类问题，当一个项目进行到build3之后，一般发布上也不会有太多的数据迁移和运营准备要做了。发布前做好数据备份当然是必须的，同时视情况调整产品运营手册等。周四的会基本上也可以知道本周的工作量完成情况，再思考一下，下周一又要开始新一轮的build了。
6 竞争对手分析，如果是竞争性产品，项目经理要有很清楚的产品路线图，以周为单位来知道自己负责的产品目前和竞争对手差距在哪里，若干时日之后，还有多少差距。一般得不到竞争对手的数据，所以各类数据只好自己进行监测和目标设定了。当你的产品经过一年50个build的发布，我想竞争对手日子会很难过了。如何针对竞争对手设计产品，我还有一个曾经在2004-2005年获得收益的”半盲法”，以后再分享。
基本流程就是这样，实际实施还有很多细节，比如文档管理、设计标准规范、开发规范、对于销售的支持和响应带来的影响、矛盾的功能如何平衡、怎么进行数据分析(怎么看懂google analytics)、设计、开发、测试、运营的同步和异步操作等。之后慢慢再讨论。
小团队的项目开发，还有一点就是士气和团结，不团结的团队，没有士气的团队，不喜欢互联网的团队，那么就算有再好的方法，也是无用的。这个话题已经超越项目管理的范畴。
（以上经验得益于诸多前辈:winamp开发小组、微软以特性列表为核心的项目开发管理、Borland早期Delphi和JBuilder开发成功的经验等）
相关内容
因为一些家里的事情，今天自己开车去了青浦。
之前去过不少次，不过都不是自己开车去的，没有想到从静安寺到青浦出口，只要40分钟就可以了，比我想象中近很多。
因为以前有一位同事是青浦的，所以对青浦感觉不错。而2002年在青浦warroom的场景也是历历在目。
相关内容
昨天还说到现在的电脑不像当年那样要一直升级，今天发现家里唯一的一台台式机启动不了了。
2003年女儿出生的时候买了这台台式机，来替换之前2000开始用的一台，当时记得配了AMD的，还算不错，女儿小时候的电影都使用moviemaker在这上面制作的，并且当然还负责导入了所有dv拍摄的视频。到2006年的时候，想升一下级，不过不是很顺利，中间过程也颇为复杂，反正最后cpu换成了赛扬，总觉得主板、cpu、硬盘这些配合的不太好，速度不是很好。之后大概两年多中，这台台式机非常忠诚的承担着下载的任务，我所有看的美剧和电影都是靠它下载的，也突然发现这两年已经不买碟了。其中的两个硬盘分别是2000年和2003年的，内存也是2003年时买的512M，显卡是2000年时候买的，总的来说，速度上是在不怎么样。因为下载的缘故，很多时候电脑都是一直开着，估计也加速了损耗。
上个月开始，电脑一直开始发出很响的声音，也没有怎么当回事情，后来拆开来清洗了一下灰尘，好了，没想到这次却是彻底点不亮了，估计也不是什么大毛病，支持现在赛扬的芯片和主板以及2000年的艾尔莎显卡，也没有太多要修理的余地了。
不过接下来是用兼容机，还是购买原装机，这倒是一个问题。正好最近在思考重新整顿家里的无线网络和数据储存，新在不得不开始了。
最新评论