QK31

 10月29日消息，UCWEB董事长雷军近日透露了其评价创业项目的标准。雷军表示，优秀的创业项目应该具备两大方面的10条标准。 
雷军表示对于创业者而言，团队和方向两者相辅相成，缺一不可。“如果创业者能力不足，再好的方向和机遇也很难把握；如果创业者能力非常出色，但做得方向不对，难成大器”。 
以下是雷军列出的两大方面10条标准： 
一、团队（投资就是投人。人是最关键的因素，如果这个创业团队非常优秀，一般应具备根据市场形势做一些具体方向的调整） 
1) 能洞察用户需求，对市场极其敏感 
2) 志存高远并脚踏实地 
3) 最好是两三个优势互补的人一起创业 
4) 一定要有技术过硬、并能带队伍的技术带头人（互联网项目） 
5) 低成本情况下的快速扩张能力 
6) 履历漂亮的人优先，比如担任过大公司高管或有创业经验等会加分 
二、方向（在对的时候做对的事情） 
7) 做最肥的市场，选择自己能做的最大的市场。只有大市场才能造就大企业，小池子养不了大鱼。方向略有偏差，会浪费宝贵的创业资源。 
选择正确的时间点。市场基本成熟了，企业也已有雏形，引入天使投资后，业务会得到爆炸性增长
9) 专注、专注再专注。最好只做一件事情，这样能把事情做到极致！ 
10) 业务在小规模下被验证，有机会在某个垂直市场做到数一数二的位置。 
此前，雷军曾经对创业者创业提出了三点建议。一是要做“最肥的市场”，二是组织“比较全面的创业团队”，三是把把需要做的事情尽量减少。

   被炒鱿鱼了，还不知道为什么？赶快看看下面的这些忠告吧，你是否在不知不觉中已经犯了如下大忌……       1.不要比你的老板穿得更好。
     如果你碰巧遇见一个极其没有品位的老板，喜欢穿着劣质西服到处向别人炫耀这是名牌时，我就建议你买块布找个土裁缝做件衣服得了。忠告你，不要试图用你自己的现身说法去影响老板的品位，你应该明白这个看上去像个土老冒的家伙之所以成为你的老板，肯定不是因为他会打扮的原因。说不定，他讨厌像奶油小生似的男人。
     2.不要试图与老板的女秘书调情。
     你这样在老板眼皮下面轻举妄动，简直无异于自寻死路；即使你的老板和他的秘书之间的关系像办公室里的桶装纯净水一样透明无瑕，你也别忽略一个正常男人对异性的占有欲和对同性的嫉妒与敌意，就像你在大街上看见一个超级美女被一个臭男人拥抱着的时候，你一样也会心中暗骂：哼，这走运的臭小子！
     3.不要在办公室到处施展你的超人口才。
     也许你想给你的老板留下一个深刻的演说家的形象，但遗憾的是，几乎所有的老板都讨厌看见一个喋喋不休的，像一只刚下完蛋的母鸡那样的口罗嗦男人。记住，能用三分钟表达完的事情千万别说上三个小时，如果你是那种不讲话就会发疯的人，那就建议你先在家里对着墙壁大声说上一个小时，直到筋疲力尽，直到没有心情在办公室胡说八道的程度的时候再去上班，惜言如金是你应该恪守的最基本的职业素养之一，用最短的句子把你的观点非常职业地表达出来，还有，在别人，尤其是老板讲话时，别随便打断。
     4.不要跟你的同事谈恋爱。
     因为你只是个正常男人,所以你就很难做到对你的情侣视而不见，这造成的直接后果就是：即使你工作勤勤恳恳得像只老黄牛，你的老板也会怀疑你的上班时间是不是都在谈恋爱了。别抱怨老板的胡乱猜疑，站在他的位置上，你一样也会这么想。如果你真的与你的某位同事陷入爱河，那你们看上去只有两条路可走，要么你离开公司，要么你的爱人离开公司。
     5.不要说黄色笑话。
     你要明白这种爱好与幽默无关。虽然你把你的女同事逗得喜笑颜开，但她极有可能转过身去对自己说：天那，这个家伙真无耻！连这种话都能说的出来
   6.不要跟你的同事交朋友。
     虽然把同事想象成你的假想敌的做法有些过分，但至少能使你防止某些糟糕的办公室纠纷的发生，就把他们当成一群你可以叫得出名字的陌生人好了。永远永远都不要推心置腹地把你的隐私告诉同事，这就好像在你身边埋了一颗地雷，没爆炸的时候风平浪静，可假如有一天爆炸了，你就彻底死定了。一个同事的杀伤力比一个亲密朋友的杀伤力厉害多了，最起码，你的密友不认识你的老板是谁。
     7.不要露骨地拍老板的马屁。
     如果他不是个白痴的话，他会明白，你只是在逗他玩而已。
     8.不要在背后议论老板的是非。
     如果你实在憋得难受，干嘛不去找个沙袋吊起来，上面写上老板的名字，然后给那个家伙一顿好揍。起码，与你向同事说老板坏话相比，这样没什么危险性，一般说，你背后说老板的那些话会很快传到老板的耳朵里，甚至比你说的那些还要难听几十倍，你就得留点神了，说不定什么时候，你老板会给你一顿好揍，–也许没那么糟糕，说不定他只是把你给炒了呢。
     9.不要穿得像个朋克那样进办公室。
     即使你的工作环境不需要你穿正式的西装领带，那你就穿样式最简单的休闲便装吧，除了结婚戒指以外，别配戴更多的饰品，否则会让人看上去比你的女同事还女人气十足。尽量避免穿粉红色系的衣服，如果不想把时间都花在选配衣服上，那就都选深色系列吧，必须注意，在穿黑色皮鞋时千万别穿白色袜子，不时清理你的衣橱，把那些有破洞的袜子坚决扔出去。
     10.不要在办公室的电脑里登陆色情网站。
     如果你自以为觉得没什么人注意到你正在干什么，或者以为自己是电脑高手，可以将你登陆过的网站删得不留痕迹–你显然过高地估计了自己的手段，你的老板能够非常简单而迅速地查到你到底在用你的电脑干什么，如果他想这样做的话，尤其在设施完善的大公司里，这点更是易如反掌。所以如果你不想留什么把柄在老板手上的话，你就先忍忍，回家再看吧，如果你老婆支持你看的话。
     11.不要忘记在办公室里关掉手机和呼机。
     为什么不让别人打电话到办公室来呢？你的手机声音只会让身边的同事感到厌烦，尤其在老板跟你谈话时，或者在重要的会议桌上。不要被手机广告所欺骗，以为成功人士都是二十四小时开着手机的，他们只不过是想多卖几台机子而已。
     12.不要把你的办公桌弄得比垃圾篓还要脏乱。
即使你喜欢那种食物发酵的酸臭气味，你也还是把这习惯留在家里吧。在别人皱着眉头经过你办公桌之前把办公桌收拾干净，毕竟这不是你的私人卧室，你必须要为其他同事的眼睛和鼻子着想。
     13.不要送价值昂贵的礼物给你的老板或者同事。
     这只会让他感到难堪和让其他同事胡思乱想。
     14.不要让自己陷入大公司里的人事斗争。
     尤其在你还是个没什么高层背景的普通职员时，千万不要有试图跟哪个部门老板结成同盟的幼稚想法，公司的事情和秘密永远比你想象的还要复杂和深奥，在你成为某次斗争的牺牲品之前，你也许还浑然不觉。无论哪一家的或者哪个国的公司都是如此，干嘛不老老实实把自己那份工作做好呢，让他们斗吧，你就当是在欣赏马戏表演吧！
     15.不要在办公室里接打超过十分钟以上的电话。
     在遇到令你尴尬的比如调情电话时，不要试图用降低声音或者改变说话的语气来逃掉别人的注意力，这只会让你的同事更加猜疑和好奇。
     16.不要娶你老板的女儿做太太。
     靠联姻来谋取事业成功是一种目光短浅的想法，即使你付出巨大的努力，即使你的确是栋梁之材，别人也会以为这仅仅是你娶了老板女儿的关系。如果你的老板没有一个天仙般的女儿的话，你这又是何苦呢？一个优秀的男人，无论娶了谁家的女儿，他早晚都会成功的。
     17.不要娶你的老板当太太，如果你老板是个女人的话。
你会发现，从此以后，不仅在办公室里，甚至家里也都成为一个充满灾难的场所。试想一下，当你跟这个女人在床上亲热的时候，忽然想起来这是你的老板，你是不是心里充满了罪恶感？如果是的话，那就提醒你，千万不要去追求你的女老板，除非你喜欢在家里也被人呼来喝去或者有受虐倾向。
     18.不要每天都准时上班。偶尔有意地迟到一次。
     是对其他习惯拖拖拉拉的同事的一种心理安慰。说不定，你因此有了个好人缘儿。
     19.不要轻信老板的许诺。
     也许你是个心地善良的老实人，你相信老板对你说过的每一句话。你相信你老板今年没给你加薪水是因为老板处在水深火热的危机关头，必须得拿你那点可怜的薪水去救火；或者你相信老板话里话外要提拔你的暗示，但是你必须做好什么都得不到的心理准备。别理会老板说的要给你什么，先看他已经给了你什么吧，比较一下，然后再想想是否还有必要跟着这样的老板。

之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。看看这一步完成后系统的图示：         
这一步涉及到了这些知识体系：这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。看看这一步完成后系统的图示：               
这一步涉及到了这些知识体系：前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。看看这一步完成后系统的图示：              
这一步涉及到了这些知识体系：页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；
架构演变第四步：数据缓存在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是开始变慢，经过查找，可能会发现系 统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。看看这一步完成后系统的图示：              
这一步涉及到了这些知识体系：缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
架构演变第五步： 增加webserver好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；2、如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等；在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了以往的速度。看看这一步完成后系统的图示：                     
这一步涉及到了这些知识体系：负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、主备技术（包括但不限于ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。
架构演变第六步：分库享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的 资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。看看这一步完成后系统的图示：                     
这一步涉及到了这些知识体系：这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很高的要求的。
架构演变第七步：分表、DAL和分布式缓存随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作，当然，这不可避免的会需要对程序 进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个阶段可 能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察和折磨，终于是将大量的数据缓存转移到分布式缓存上了。看看这一步完成后系统的图示：                  
这一步涉及到了这些知识体系：分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的封装等；
架构演变第八步：增加更多的webserver在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势 [...]

打开
C:\Documents and Settings=》Administrator=》Application Data=》Adobe=》Dreamweaver 9=》Configuration
 
Extensions.txt
修改前：
PHP,PHP3,PHP4,PHP5,TPL:PHP Files
修改后：
PHP,PHP3,PHP4,PHP5,phtml,TPL:PHP Files
 
还有就是修改
 
D:\Program Files\Adobe\Adobe Dreamweaver CS3\configuration\DocumentTypes
 
 <documenttype id="PHP_MySQL" servermodel="PHP MySQL" internaltype="Dynamic" winfileextension="php,php3,php4,php5,phtml" macfileextension="php,php3,php4,php5,phtml" file="Default.php" writebyteordermark="false"> 

网上搜索下tag的设计，虽然找到一个tag的设计描述，但也是跟我们正常的设计差不多
最后他认为最好tag设计要遵循三范式的设计基础设计
大概描述如下：
原文：http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html
数据库结构

最近, 在 del.icio.us 邮件列表, 我问了个问题 “有谁知道 del.icio.us的数据库设计?” .我得到些私人的反馈，下面跟大家分享下：
问题: 你需要设计一个数据库作为一个书签（或者是一个博客或者其他的）需要给它们建立许多的标签， 之后，你想通过SQL语句获取标签的union(并集)或者intersection(交集), 你同时需要在短时间内然会标签查询结果.
显然 有三种的解决方法 (注意::如果你做一个网站允许用户自定义标签, 确信看过我在站点里面进行的 my performance tests测试报告.)
“MySQLicious” solution
一个表的解决方法：

Intersection (AND)交集
Query for “search+webservice+semweb”: //查询一段tagSELECT *FROM `delicious`WHERE tags LIKE "%search%"AND tags LIKE "%webservice%"AND tags LIKE "%semweb%"
Union (OR)并集
Query for “search|webservice|semweb”:
SELECT *FROM `delicious`WHERE tags LIKE "%search%"OR tags LIKE "%webservice%"OR tags LIKE "%semweb%"
Minus
Query for “search+webservice-semweb”SELECT *FROM `delicious`WHERE tags LIKE "%search%"AND tags [...]