ing...

 

我勸你早點歸去

你說你不想歸去

祇叫我抱著你

 

悠悠海風輕輕吹 冷卻了野火堆

 

我看見傷心的你 你叫我怎捨得去

哭態也絕美

 

如何止哭 祇得輕吻你髮邊

讓風繼續吹 不忍遠離

心裡極渴望 希望留下伴著你

 

風繼續吹 不忍遠離

心裡亦有淚 不願流淚望著你

 

過去多少快樂記憶 何妨與你一起去追

 

要將憂鬱苦痛洗去 柔情蜜意我願記取

要強忍離情淚 未許它向下垂

愁如鎖 眉頭聚 別離淚始終要下垂

 

我已令你快樂 你也讓我痴痴醉

你已在我心 不必再問記著誰

 

留住眼內每滴淚

為何仍斷續流默默垂

start /D "D:\Vs2005\Common7\IDE\" devenv.exe
start /D "D:\Microsoft Office\OFFICE11\" OUTLOOK.EXE
start /D "G:\My Documents\My Tools\MSN Messenger\" msnmsgr.exe
start /D "G:\My Documents\My Tools\Tencent\qq\" QQ.exe
start /D "D:\Mozilla Firefox\" firefox.exe
start /D "D:\Maxthon\" Maxthon.exe
start /D "D:\EditPlus 2\" editplus.exe
start /D "G:\My Documents\My Tools\TTPlayer\" TTPlayer.exe

互联网仍旧是内容为王，贬值的不是内容，而是做的重复性的内容太多，导致贬值，比如某条It新闻，Sina上有，Sohu上有，Netease上有，XX站也有，用户上哪儿都可以看，哪儿让他舒服他就去哪儿，那么对用户来讲这四个网站的价值是一样的。
原创的，频繁更新的网站始终是所有用户都喜欢的，但一个站不可能囊括所有的东西，这就会导致用户的细分，这其实是垂直网站的机会，专业的，大量原创，更新频繁的网站仍旧是互联网之王。

有点火星了，05年刘韧说：
   1. 活的网站，自己有生命力。用户会发展出更多用户。用户会产生内容，内容会吸引用户，更多的用户会产生更多的内容。如此循环。
   2. 商业运作对活的网站来说，只是催化剂。让它发展得更快而已。
   3. 死的网站。主要靠雇佣的编辑更新。一天不更新，这个网站就死了。
   4. 活的网站，全体员工可以集体休假一星期。而访问量不减。
   5. 图片分享的flickr，音乐分享的MySpace.com、书签分享的http://del.icio.us/，已经文字分享的众多Blog托管商，电影分享的众多p2p，这些都是活的网站。有生命的网站。
   6. 哪些是死网站，就不列了。得罪人。
   7. 活网站通常人很少。程序员和设计识主导；死网站一堆编辑，总编主导。
   8. 就像诗中唱到那样：“他们已经死了，我们正年轻。”

如果编辑们放假，Mtime会怎样？

在我读大学四年级的时候，  我记得曾经和一个计算机科学专业的同学聊天，他即将在某投资银行中就职。他说他即将从事软件设计，但他不会让自己陷入日常编码的实际工作中。这种事情应该交给编码员 — 显然应该由更低级别的人来完成。换言之，像我这样的人。当时，在以破译代码能力为最高追求的大学环境中，我隐约感到受了侮辱。

然而他有他的道理。那时我只是个编码员（他也不见得比我更好）。现在，如 Mike Gunderloy 著作的《从编码员到开发人员》 一书中所述，我已不再只是一个单纯的编码员，我已经把自己看作一名开发人员了。现在我不仅知道如何编写可编译的代码，还可以编写能快速运行、可靠、可通过严格测试、安全、易于维护、可全局化，并且达到各种高水平代码特性的代码。软件行业正整体从一支编码员队伍进化为开发人员队伍。

现在，如果询问开发人员他们下一步的职业规划，他们或许会说想当架构师（在英文中，架构师与建筑师是同一个词）。这个说法唤起了关于钛和毛玻璃的想象，通过比较，将单纯的开发人员归入建筑工人的角色。那么，我是否想跨入理论上的下一步，跻身架构师行列呢？我的回答是“不”。

这并没有故意看不起架构师的意思：软件开发的确需要人们对系统组件之间的交互进行布局，并在头脑中保持一个整体概念。虽然如此，我为作为开发人员感到自豪，并希望其他所有开发人员同样为此骄傲。

如果你羡慕像 Frank Gehry 或 Rem Koolhaas 这样的实体建筑师的设计自由，又该如何？我的回答会是，软件工程师领域尚不成熟，很难登上那样概念性的阶梯。建筑师可以设计 Bilbao Guggenheim 博物馆和西雅图公共图书馆这样的建筑物，是因为有几百年的土木工程知识支持着他们。软件行业还没有到达使每个人都在这一层次进行操作的高度；我们大部分人仍在试图搭建只有一层的房子，摔上前门，房子还不会塌就可以了。

Microsoft 检查他们的 bug 产生的原因时，发现大量的 bug 都不是设计 bug（设计师审查设计文档时会发现的那种 bug），也不是编码 bug（源代码不按程序员所希望的运行）。这种中间类别发生于源代码确实实现了程序员意图、但在意图中有一个本地化错误的情况下：这些问题类似于将错误的标记传递给某个方法，或错误理解了配置参数的意义。这不是架构师会面对的问题。这些都是我们开发人员需要自己正确解决的问题。

Fred Brooks 在他的著名文章《没有银弹》中间接提到过这些，他写道，“软件实体的本质是构造连锁概念：数据集、数据项的关系、算法、函数的调用。”他接着写道，“我相信构建软件最难的部分是规范、设计和测试这些概念化结构，而不是繁重的表示性劳动，也不是测试这种表示是否失真。”他不是在谈论架构师的工作，他是在谈论开发人员的工作。他实际上说的是，当一个编码员可能不太难，但当一个开发人员确实很难。我们应该认识到我们工作的价值。

我知道这不是编程工作的光荣。如果完美地构建了多个组件，并在其中整齐地封装了变体又允许将来的扩展，那将是令人惊喜不已的。程序员喜欢精确，将所有部分恰当地结合在一起会有一种美感。但是生产软件的大部分工作都类似于技艺娴熟的技术工人所从事的工作：执行代码审核、编写单元测试、清理注释。客户可能不会直接意识到我们的辛勤劳动如何保证他们的隐私，如何防止他们的系统免受攻击，但是我们自己知道我们提供的价值。并且，有一些领域（诸如性能优化、电源管理），它们是真正的“黑魔法”：并非高层建筑而是具体性工作，只有我们应用技能和经验随手解决问题。

我很骄傲地说我是一名开发人员，而不是架构师。或许某一天我们解决了软件中的所有工程问题，到那时我们都可以成为架构师。同时，一些设计完善的软件需要我们去完成。

 

From:http://msdn.microsoft.com/msdnmag/issues/07/06/EndBracket/default.aspx?loc=zh