随笔-72  评论-20  文章-0  trackbacks-1
  置顶随笔
     摘要: 作者 : Stephen Covey


It will change your life (at least the way you react to situations).

它將改變你的一生(最低限度,它將改變你對不同情況的反應)。


What is this principle? 10% of life is made up of what happens to you. 90% of life is
decided by how you react.

90/10 的定律是什麼?生命的 10% 是由你的際遇所組成,餘下的 90% 則由你的反應
而決定。
  阅读全文
posted @ 2007-12-18 21:34 前方的路 阅读(248) | 评论 (0)编辑 收藏
  2010年5月6日
   工作五年,一晃已年过三十了。读研时,独立做项目,毕业头三年,主要在大公司工作,后来,也就是08年,半创业。具体点,合伙人吧,自己负责IT部门,到现在6人,公司总共20来人,旅游业。这两年严酷的创业经历,让我越发觉得管理(做事),以及领导(带人、待人,不是管人)的重要性。因为,随着组织的扩大,混乱度无形中就会增大,管理和领导,就是让这种混乱重归有序,重归单人作战那种意图和行动的高度统一。

    说得功利点吧,一个人的财富和其影响力是成正比的。影响力本质上就是对他人的价值。比如,郎_xian_评的出场费一天超过15万。作为技术人员,如果我们只能影响周边几个人,那么我们凭什么拿那么高的报酬,除非我们做的事情影响了很多人,比如杨勃的豆瓣网。所以,我还是觉得,技术人员往高处发展,逐渐应该有管理意识、培养自己的管理能力。技术从书本上可以学到很多,管理还真得实践,书上看到的,你觉得很弱智的问题,比如盲目扩张,自己亲身经历时,一样会犯,也许是行为习惯在起作用,看书不足以改变行为。

    回到正题上。
    也许是自己曾经在较大公司或团队的做事习惯和视野,刚创业时,用在这种小团队的商业项目开发上,几乎惨败。
    先说项目开发这块吧。
    大家知道,项目管理和过程管理是两码事,前者关注目标和进度,成本和收益;后者关注做事流程、方法。
    项目管理,体会最深的,就是目标和任务分解、进度控制,以及沟通。

    项目管理软件
    从大公司出来的人,我想最喜欢玩的,就是借助于项目管理软件(核心是甘特图)。市面上的大多数知名的项目管理软件,无论是桌面版还是网页版的,我都试过。当然最后也选择了一款:ConceptDraw Project,用了一年多,也多少有些用。但最后还是发现,它其实对项目进度和质量关系并不大。也许,一个Excel表格更实用。
     项目管理软件,本质上是解决一种沟通和职责分配的问题。比如,一个项目,折叠成一个三层树形结构,老板只关心第一层,也就是整体进度;中间是项目经理关注的功能层,最后一层,也就是具体的任务,是开发人员关注的。想想,如果没有这玩意,你怎么告诉其它项目干系人进度?但又引出几个问题:
    靠文档来沟通,还是靠信任? 太在乎文档,往往导致每天去关注文档如何漂亮、有说服力,并为此花大量时间,而不是项目如何漂亮。另外,是否有文档就可以防止扯皮、兑现承诺?我们是关于项目目标,还是关注彼此的博弈?

    进度偏差 创业型项目,往往都是以前没有接触过,其进度评估往往有很大误差,比如业务需求的挖掘和变化,技术难点,开发人员素质。我们是关注进度,还是关注项目本身的质量?两者都要,但如何兼顾?虽然有方法学,比如砍掉优先级低的,但你怎么让老板相信某个核心功能就得四天时间。
    在我们的进度设计不合理情况下,是否开发人员完成甘特图(WBS)下的任务就ok?远远不够,任务分得太细,往往限制了开发人员的创造性和自我评估能力,如果提前两天完成呢?
    我们现在是以项目管理软件为辅,任务的下达主要以邮件传达,每周一上午的周例会会白板宣布。我发现白板比投影仪PPT好用。

   关于规范
   这也是大公司特别喜欢玩的。
   也许我们前期会制定一个的架构、设计文档,代码规范,这有一个规范建立的时间成本以及规范本书的合理性,再说如果一个开发人员,特别是高手,如果不认同你的设计和规范,你要强推,他要么走人要么怠工。规范的本质是为了协作和后期可维护,如果只有两个人或一个人写某个模块,你觉得有这个必要吗?规范整洁的代码,在项目初期,对用户的价值关系很小,你会关心豆瓣网的js代码写得很漂亮吗?我们应该关注代码的健壮性而不是可维护性,我们不是在开发Windows。

    人适应项目,还是项目适应人
    大公司,往往是来了一个项目,赶快招人,人来适应项目。小公司呢,我现在的看法是,项目适应人。小公司,往往一个项目做砸,公司就面临解散。所以,我认为,最好还是按照开发人员的擅长,保证功能质量,最快的速度上线。另外,为了达成进度,可以在上线初期砍掉不太重要的栏目或功能。
    我在这个上面栽过跟头的。比如开发人员的擅长,如果他擅长jsp开发模式,而不是Hibernate+Spring的分层开发,就让他按自己的意思做吧。因为,创业型项目都不会太大;即使技术实现你感觉完美了,用户可能感觉不爽;再说,项目开发,涉及到业务调研、需求分析、原型界面、架构、开发、部署、推广。开发,也就是代码实现,占去项目时间,也许不到30%。项目如果证实有商业前景,代码重新实现一遍,花不了多少时间。
    但我也深深地意识到我们项目管理的级别,就如同CMM1到CMM4。但我还是觉得目前是最好的选择。
    如果最低层次的用户需求目标都达不到,直接考虑代码怎么有可扩展性、可维护性,对于小公司就是找死。
    另外,尊重和信任、支持开发人员的技术选择,往往是一种激励、增强团队凝聚力的方式。万众一心,比什么目标、进度更有效、实际。
    我们应该培养一种团队成员的内部创业心态,而不只是敬业。

    在进度把控上,我现在更倾向于强调我们的项目目标和紧迫性,而不是他们的任务。因为我希望大家的关注点是项目,而不是他的上级,他应该对项目负责,而不只是对上级负责。

    说说沟通
    项目管理中最难处理好的,就是沟通。以前,我比较关注于工具,如邮件、文档、ppt讲稿会议,逐渐我关注效率和效能,特别是态度。沟通最基础的就是态度。如果网站上线后,订单提交出现一个核心bug,你是直接找开发人员问责;还是告诉他哪儿出了问题,这个问题的严重,并且自己反省,比如测试流程出了问题。出现这种事情,也许需要负责人举重若轻的气度。但更深层次的,如果负责人能够培养其员工质量意识,危机意识,才是治本。因为一个有强烈质量意识的团队,他自然会去对代码健壮性、功能易用性精益求精,自然会去配合测试流程。
   刚才那个沟通问题,对开发人员的态度,前者是负面,后者是中立。那么前者,开发人员的反应是如何不让领导下次责怪自己,比如只做领导安排的事情;后者的反应是怎么去改进,不让这样的事情发生。
   如果你认可创新就可能出错,如果你认可开发人员都是想做好的。那么所有的事情,朝正向发展迈出了最决定性的第一步。

   沟通:命令式还是征询式
   在沟通,特别是下达任务或做决策这类事情上。应该说中国绝大多少管理者都是用命令式。我过去经常在用,但一直在试图改正,改用建议式和征询式。管理者最需要、最难开口的一句话是:Do you think so?命令的方式,经常出现下级不能理解上级的意图,严重的出现抵触。每个人,其实都喜欢别人按自己的想法做事,但你怎么知道自己的想法或决策是对或不是偏颇的,怎么让团队愿意去执行?去征询团队其他成员的意见,让他们参与,往往能够培养其主人翁意识、责任感、向心力,还能够完善自己的想法。但要将员工参与意识,转化为一种习惯,太难。
    当大家都没有主见时,需要领导者的果断、魄力和强势,但这种机会并不多,而且这种情况,需要团队成员对领导者的信任。
   
    遵守制度,还是建立信任
     在大公司,往往是告诉你怎么去遵守公司制度。在小公司,我认为最基础、最核心的一件事,就是建立信任,让团队信任你的人品(说到做到),信任你的能力(能够把大家带到一个新的高度)。建立了信任后,下一步的核心工作,怎么将你的个人目标,也就是团队目标,转化为每个成员的个人目标。
    有了信任这个基础,才会有了团队建设的第二个核心:激励。
    是激励,而不是约束、监督,让团队有战斗力。但大公司往往喜欢后者。也许,大公司都是职业经理人,反正是打工,太关注于事。如果说有个所谓的中国式领导,我觉得就是以人为本,对人的尊重。人的关系处理好了,事情就好做。
    加班、考勤、上网监控,这类对信任、激励极具破坏力的行为,也许是工业型社会对我们这个思考性创造性行业的侵蚀。知识型劳动者,需要一种与体力型劳动者完全不同的管理模式,这种模式也许需要一个从萌芽、生长到成熟期。现在在目前的中国,还只是刚走出萌芽期。
   
    以前完整看过余世维的11套视频,还看过几遍。他那种人本理念我还是很认同,只是,他在大公司、规范公司的做事情方法和风格,完全照搬拿到小公司,非常危险。你能够拿幼儿园那种教育方法来教育成年人吗?小公司不具备大公司那种职业化的环境,也不具备大公司在行业中的市场地位及资金实力。
    如果说大公司讲究做事方法、流程,如SWOT分析法、BCG矩阵,小公司更看重灵活性、市场适应性。小公司应该适当短视、急功近利,否则在你实施一个三年计划时,第二年还不赚钱可能就撑不下去。
    所以我觉得,在跨国大企业呆惯了,出来创业很危险。一个是做事方法不适应,另外一个就是没有平台。如果要出来创业,以前那种大企业的经历可能更是一种劣势。 也许有一种情况,你是大公司的高官,拿到一笔很大的风险投资,然后出来创业。
    
    人事招聘
     薪水  如果公司给得起,并且应聘者能力差不多。 就不要太在乎那200、300。虽然说至少要不低于行业平均值(IT人员是IT行业平均值,而不是本公司所在的行业平均值),但最重要的,还是不要低于当事人的期望值,因为最核心的是满意度,而满意度决定于期望值和实际值的差距。对于小公司,往往一个人技术人员的成本和收益,和其工资差距非常大,有可能10倍。所以,我们的关注点,应该是怎么一开始留住这位人才。然后,怎么让其充分发挥潜力。小公司往往不是因为节省那几千几万的工资成本死掉的,而是充分利用这位人才才活下去了。

     另外,不要以为有多少人才选择的机会,小公司往往不受高级人才的青睐。太高级的人才,可能养不起,而且往往太有个性,很难合作愉快,除非在来公司前有很长时间的了解。
     招聘到合适人才后,应该让其忘掉薪水,专注于工作,寻找工作本身的乐趣。当然,要做到让其在薪水上有优越感,也许是项目很盈利的那一天,开始时很难。

     人才标准 如果其能力和你预期相差不大的话,更应该考虑其态度、做事风格,甚至是价值观。因为其能力的发挥,和这个环境,特别是他的直接利益相关者,也就是上司,关系太大。如果配合得好,一个人可以顶三个。否则,那种内耗导致的进度延期,由此引起的市场机会丧失,公司财力无法支撑,往往是致命的。因为一个几人的IT团队,每一个人的职责就如同那木桶的一块板,缺了那块都存不了水。
     比如关于质量,更确切说是内容质量,我们目前做旅游电子商务,我认为内容质量很核心。但你招进来的同事,始终认为先要量,什么都可以抄,而我强调质,原创、半原创,可以少而精,而不能多而乱。除开项目进度,怎么去沟通?最好两个人一开始都认同原创的力量。

     提升一个人的技能不难,但改变一个人的态度比较难,改变一个人的价值观几乎不现实。所以先找志同道合的人吧。    
     别期望人才是可替代的。我们不是大公司,我们缺了谁,那一块就不转。
     大家都知道,松耦合要付出代价,比如SOAP协议的低性能,AMF私有协议的高性能。创业期,不要太多考虑人才替换,而是关注怎么发挥人的潜力,留住人,尽快高质量完成项目。人才替换的一个假设,可能是你对自己管理的不自信,因为你不相信自己能够留住人。
    
     这次就写这么多吧。
     我似乎有这种体会,考大学、四六级这类资格、证书类考试最好混,因为只要勤奋就可以,再加点方法就可以出类拔萃了。  上班也比较好混,说找工作吧,像我搞技术的,本身对技术很狂热,根本就不愁找不到工作,因为面试时我觉得那家伙应该比我牛,正好可以切磋切磋,没想太多所以没啥怯场或不自信。工作吧,如果是技术类,特别是商业软件,技术难度都不大,按上司意思来,很容易搞定。创业呢,自己要做商业判断、业务决策,还要协调若干人的工作(协调的本质是协调利益)。做事和管事,完全是两码事,有些难。不过,创业还是很有意思,因为你可以按自己的意愿去工作去生活,当然也是受限环境的自由。


我将我的一个回复放在这个地方,特示警醒:
告诫各位处于开发第一线的朋友,千万不要受本文的误导,把规范和设计文档不当回事。

我的看法:
1、文档的多少和深度决定于项目环境。
    如果是大项目,比如二三十开发人员,架构文档、需求文档、代码规范等都是必须,否则开发人员不能迅速了解项目技术和业务特点,从而无法快速开发,也即是规范可以降低培训成本和团队沟通;另外,项目开发中后期可能根本不可控,谁都看不懂其它人的代码。部署时看到的一些bug无法及时修复,因为到处都有地雷。我以前经历过这样的项目,最后加班都没用。

    如果是产品型,规范更重要。当然我说的产品可能是2.0版以后,因为这时候的产品基本得到了市场的认可。而在初版时,代码写得烂都没关系,因为你不不知道用户会不会买单,也不知道能否按进度开发完成。而在后续版本,如果没有规范文档,维护的成本都不亚于重新开发。特别是处于一线的开发人员会怨声载道:为什么要我来收拾残局?那么,这样的士气,开发效率怎么会高,项目质量怎么会高?

2、成熟型大公司那套做事流程,可能高手受不了,但可能是最优的方案。因为,到项目后期维护,往往只是一些业务功能的删减改进,不需要技术高手,这个过程可能漫漫几年,项目维护成本会非常高,雇佣高手一来他不愿意干二来也不需要这种人,如果项目代码还维持在一种“秩序”,初中级开发人员就可以胜任,有什么不好呢?
   项目上线时,是为了追求利润。项目维护期,是为了省成本。

3、刚入道的朋友,最好是按规范来,就像学武术,先要学套路。否则,养成的编程坏习惯,比如文件名叫Aaa1.java,代码没有缩进。过几年非常难改。而好的编程习惯,可以提升开发效率,还能让自己思维清晰。
   学技术阶段,一定要注意代码的可维护性、健壮性及灵活性,只有养成对代码精益求精的态度,你才可能成为技术高手。技术学好,做技术管理就有了基础,而且别人也会服你。

原文地址:http://www.javaeye.com/topic/646406
posted @ 2010-05-06 12:35 前方的路 阅读(385) | 评论 (0)编辑 收藏
  2010年4月19日
     摘要: 开发和架构的界限难以捉摸。有些人告诉你它根本不存在,架构只是开发者们所做的设计过程的简单扩展。 另外一些人认为这是一个鸿沟,它只能由那些做到高度抽象,而且不会陷入实现细节的开发者才能跨越。通常,在这两个极端的观点中间某处有个可操作的平衡点;不论如何,怎么从开发转换为架构师都是个有趣的问题。

经常被用来区分软件架构和软件设计开发的关键几点包括 伸缩性和抽象程度的增加以及作出正确设计决策意义的增强。软件架构是通过一个全局的观点,宏观的视角来理解软件系统作为一个整体如何工作。

即使这能够帮助区分软件开发和架构,它并不能帮助理解某人如何从开发提升到架构。 并且,它也不能帮助识别谁能够成为一个好的软件架构师,如果你想雇人的话你如何去寻找他们以及你是否是一个软件架构师。
  阅读全文
posted @ 2010-04-19 16:50 前方的路 阅读(207) | 评论 (0)编辑 收藏
  2010年4月14日
     摘要: Flashback 技术是以Undo segment中的内容为基础的, 因此受限于UNDO_RETENTON参数。要使用flashback 的特性,必须启用自动撤销管理表空间。
在Oracle 10g中, Flash back家族分为以下成员: Flashback Database, Flashback Drop,Flashback Query(分Flashback Query,Flashback Version Query, Flashback Transaction Query 三种) 和Flashback Table。  阅读全文
posted @ 2010-04-14 17:38 前方的路 阅读(453) | 评论 (0)编辑 收藏
  2010年3月25日
     摘要: 代码检查是白盒测试的一种静态测试方法,是众多软件测试方法中发现软件缺陷最有效的方法之一。本文结合国内外学者在相关领域的研究情况,介绍代码检查相关的基本概念、过程和分析方法。  阅读全文
posted @ 2010-03-25 18:17 前方的路 阅读(2166) | 评论 (1)编辑 收藏
  2009年6月16日
     摘要: 为什么需要对参数进行编码?相信有过开发的经验的广大程序员都知道,在Web中,若是直接在Url地址上传递参数值,若是中文,或者+等什么的就会出现乱码现象,若是数字或者英文的好象没有什么问题,简言之,传递过来的参数是需要进行编码的。 在这里,也许有人会说,为什么不直接用Server.UrlDecode和Server.UrlEncode这两个来进行编码和解码的操作呢? 的确,这两个服务器端对象很...  阅读全文
posted @ 2009-06-16 10:34 前方的路 阅读(905) | 评论 (0)编辑 收藏
  2008年8月14日
     摘要: Spring Framework最得以出名的是与Hibernate的无缝链接,基本上用Spring,就会用Hibernate。可惜的是Spring提供的 HibernateTemplate功能显得不够,使用起来也不是很方便。我们编程序时,一般先写BusinessService,由 BusinessService调DAO来执行存储,在这方面Spring没有很好的例子,造成真正想用好它,并不容易。  阅读全文
posted @ 2008-08-14 15:15 前方的路 阅读(158) | 评论 (0)编辑 收藏
     摘要: Spring Framework从诞生之日起,受到了越来越多的关注。最近,新的开源项目大多支持Spring Framework。国内目前也有专门的网站(http://spring.jactiongroup.net/)。那它为什么如此受欢迎呢?

我想最重要的是,EJB让每个人都痛恨。要编写一个EJB,需要写LocalHome, RemoteHome, Bean, LocalInterface, RemoteInterface,需要一个标准描述符,一个特殊厂商描述符(Weblogic、WebSphere都不一样),如果是Entity Bean,还需要Mapping文件。如此之多,实在麻烦。但EJB最重要的是解决Transaction问题,没有Spring之前,没有其他方法能够描述式的解决它。每个人、每个公司为了解决Transaction的问题,编程的写法都不一样,百花齐放。于是,在最需要它的时候,Spring出现了。  阅读全文
posted @ 2008-08-14 15:13 前方的路 阅读(205) | 评论 (0)编辑 收藏
  2008年8月11日
     摘要: Spring Framework  【Java开源 J2EE框架】 Spring 是一个解决了许多在J2EE开发中常见的问题的强大框架。 Spring提供了管理业务对象的一致方法并且鼓励了注入对接口编程而不是对类编程的良好习惯。Spring的架构基础是基于使用JavaBean属性的 Inversion of Control容器。然而,这仅仅是完整图景中的一部...  阅读全文
posted @ 2008-08-11 10:24 前方的路 阅读(678) | 评论 (0)编辑 收藏
  2008年2月20日

 

Chasing an OSGi vision

OSGi技术的研究和讨论

posted @ 2008-02-20 16:46 前方的路 阅读(342) | 评论 (1)编辑 收藏
  2008年2月17日
使用servlet来下载文件,其原理非常简单,只要得到文件的输入流(或相应字节),然后写输出流即可。现就其中的几个细节问题展开:
1. MIME类型的设置:
Web 浏览器使用 MIME 类型来识别非 HTML 文档,并决定如何显示该文档内的数据。
例如EXCEL文件的 MIME 类型是 "application/vnd.ms-excel "。要用servlet 来打开一个 EXCEL 文档,需要将 response 对象中 header 的 contentType 设置成“application/vnd.ms-excel ”。
response.setContentType(contentType);

2. Content disposition
HTTP response header中的content-disposition 允许 servlet 指定文档表示的信息。使用这种header ,你就可以将文档指定成单独打开(而不是在浏览器中打开),还可以根据用户的操作来显示。
如果用户要保存文档,你还可以为该文档建议一个文件名。这个建议名称会出现在 Save As 对话框的“文件名”栏中。如果没有指定,则对话框中就会出现 servlet 的名字。
servlet 中,将 header 设置成下面这样:
response.setHeader("Content-disposition","attachment;filename="+ "Example.xls" );

response.setHeader("Content-Disposition", "inline; filename="fliename)
点击打开会在ie中打开。


需要说明的有三点:
Ø 中文文件名需要进行iso8859-1转码方可正确显示:
fileName = new String(fileName.getBytes("GBK"),"iso8859-1");
Ø 传递的文件名,需要包含后缀名(如果此文件有后缀名),否则丢失文件的属性,而不能自行选择相关程序打开。
Ø 有下载前询问(是打开文件还是保存到计算机)和通过IE浏览器直接选择相关应用程序插件打开两种方式,前者如上代码所示,后者如下:
response.setHeader("Content-disposition","filename="+ "Example.xls" );
3. 在研究文件的上传及下载过程中,有几点体会
程序的I/O操作往往是性能的瓶颈所在,java io定义了两个基本的抽象类:InputStream和OutputStream,对于不同的数据类型比如磁盘,网络又提供了不同的实现,java.io也提供了一些缓冲流(BufferedStream),使硬盘可以很快的读写一大块的数据, 而Java基本的I/O类一次只能读写一个字节,但缓冲流(BufferedStream)可以一次读写一批数据,,缓冲流(Buffered Stream)大大提高了I/O的性能。所以:
Ø小块小块的读写数据会非常慢,因此,尽量大块的读写数据
Ø使用BufferedInputStream和BufferedOutputStream来批处理数据以提高性能
Ø对象的序列化(serialization)非常影响I/O的性能,尽量少用
posted @ 2008-02-17 16:32 前方的路 阅读(238) | 评论 (0)编辑 收藏
  2008年2月16日
     摘要: 金山软件事业部的技术总监许式伟常常称自己是一个计算机的狂热爱好者。对于他深厚的软件开发经历,他只简单的分成了桌面开发阶段、服务器开发阶段。但我想这每一个阶段中都蕴涵了很多关于他奋斗故事。  阅读全文
posted @ 2008-02-16 21:48 前方的路 阅读(481) | 评论 (0)编辑 收藏
  2008年2月3日
     摘要: 中国人大都喜欢用武侠小说来比较软件开发,但是在实战武功中,只有葵花宝典才是最厉害的,也只有掌握了葵花宝典,才能称为"不败"。

……

让你的思维快起来,你就会区别于那些反应迟钝的人。如果你不能让人生的道路变长,就让它变宽。这世界变化快,需要你变得比它快才行。

这样加快并不会让你短命,相反,你有更多的时间来享受生活和锻炼身体。你的生活将更有品质,更丰富,更有意义。面对变化,你将立于不败之地。我们都是和自己赛跑的人,需要跑得比昨天的自己更快。  阅读全文
posted @ 2008-02-03 22:30 前方的路 阅读(291) | 评论 (0)编辑 收藏
  2008年1月15日
     摘要: OpenCore纯插件体系结构中的核心概念包括:微内核、插件与服务。  阅读全文
posted @ 2008-01-15 18:26 前方的路 阅读(578) | 评论 (0)编辑 收藏
     摘要: IDG全球高级副总裁兼亚洲区总裁熊晓鸽曾在一篇文章中建议Web 2.0的创业者们“不要把融钱当成最重要的事”,并且给出了IDG选择互联网公司的标准:“首先看创业者,它要能创造一些服务和技术,而且这些服务和技术要能取代现有常规产业,或促进其达到巅峰;第二,不管提供产品还是服务,有终端消费者都是最重要的。”如何才能达到这样的标准呢?这就要求我们把目光从美元转到用户、甚至是转到自己身上。想想看,广大的用户在日常生活中,遇到什么样的具体问题?或者是涌现出哪些新的需求?而且这些问题和需求是可以借助Internet来解决的?有时候,找对要开的锁比找对钥匙更为重要。当然,锁找对了,还是要能够想出开锁的办法。接下来的“指导篇”,就是告诉您怎么样去找到合适的锁,又怎么样打造开锁的金钥匙。  阅读全文
posted @ 2008-01-15 10:00 前方的路 阅读(248) | 评论 (0)编辑 收藏
     摘要: 当前web2.0革命风起云涌,web2.0强调服务,而服务最基本的要求是速度快和稳定,离开这两个谈功能强大和易用性都没有任何意义。本文介绍一些关于笔者运营一个web2.0网站的优化心得和经验,希望能够和大家共同探讨。

Web2.0网站不同于以往以静态信息为主的网站架构,以往的结构大体分为2层,一个是客户端浏览器,一个就是web服务器;而web2.0以动态和交互为主,一般是3层或者4层,在静态信息网站的结构上的web服务器后端会增加应用服务器和数据库。一般会把浏览器和web服务器归为最上一层即为web层,应用服务器为中间一层,数据库为最底层。从优化角度来讲,越上层优化获得益处越大,优化也是从上自下而来。
  阅读全文
posted @ 2008-01-15 09:58 前方的路 阅读(326) | 评论 (0)编辑 收藏
     摘要: Google架构
Amazon的体系结构
eBay的架构
YouTube网站架构
Facebook 详解  阅读全文
posted @ 2008-01-15 09:57 前方的路 阅读(2855) | 评论 (0)编辑 收藏
     摘要: Web2.0的最大特征就是信息生产的革命,大大促进了网络内容的个体生产,从而引发了微内容的海量产生。

从方军的《网络大图景:人、物与讨论》汲取到的分类思路,微内容可以分为三大分类。

围绕人的。也就是人与人之间的连接、关系,这也是SNS网站所产生的微内容。

围绕物的。这是最通常的微内容方向。“物,是一种与人相对的泛指,新闻资讯是物,blog是物,图书是物,音乐是物,电影是物,旅行过的地方也是物,网摘是物,餐馆是物”。譬如豆瓣的对书、电影、音乐的评论、打分、收藏,抓虾的对blog item的收藏、推荐、分享等。

交互的。泛指人与人之间的虚拟的或真实的讨论。比如因为一个新闻引发的网络地震,就既包含了小范围内的真实讨论,也包含了大范围内虚拟的对话。
  阅读全文
posted @ 2008-01-15 09:47 前方的路 阅读(164) | 评论 (0)编辑 收藏
     摘要: Blog——博客、blog
Podcast——播客
RSS
Tag——标签
Wiki
Digg

  阅读全文
posted @ 2008-01-15 09:45 前方的路 阅读(349) | 评论 (0)编辑 收藏
     摘要: 1、在你开始之前,先定一个简单的目标。
2、链接是最基础的思想。
3、数据应该属于创建它的人。
4、数据优先,体验与功能其次。
5、做好积极分享一切的准备。
6、Web是一个平台;要让它成长。
7、理解与信奉“阶梯性”。
8、任何东西都是可编辑的。
9、Web上的身份是神圣的。
10、了解流行的标准并且使用他们。
11、遵循无意使用的规律。
12、粒化你的数据与服务。
13、提供用户能够单独受益的数据和服务。
14、让用户组织并过滤信息。
15、提供丰富的用户体验。
16、信奉并支持快速改进和反馈。
  阅读全文
posted @ 2008-01-15 09:41 前方的路 阅读(174) | 评论 (0)编辑 收藏
  2007年12月26日
     摘要: 普通的系统,在编译发布之后,系统就不允许进行更改或扩充了,如果要进行某个功能的扩充,则必须要修改代码重新编译发布。使用插件可以很好地解决这个问题。  阅读全文
posted @ 2007-12-26 15:12 前方的路 阅读(348) | 评论 (0)编辑 收藏
仅列出标题  下一页