五年后的今天，网络应用比以前丰富得多。我们去SNS站点上制造各种feed，偷菜钓鱼，在围脖上闲言碎语几句，围观各种新奇和八卦的各种事件。这种点击式，快速，碎片式的表达方式已经让我的表达能力急剧退化。稍微长点就只能用刘韧体代替。哦，刘韧体，这个词伴随着那个人的本性暴露早已被人忘记。当年可是通过他的列表式表达，让我获得很多互联网一手的资讯。还是很值得感谢的。

年初我兴冲冲地买了个笔记本(不是电脑，纸质的)，钢笔，英雄牌黑墨水，干嘛呢？写周记。是不是挺无聊的？写了一两次，完全写不动，那是一件蛮累的事情，我初衷是要通过周记来审慎自己的内心，保持一种积极向上的状态。老有种要把生活完全掌控在手中的感觉，觉得这样才踏实，才是有希望，有憧憬的人生。但往往要会有些偏离，会有那么些自责。咦，这种轨迹让我想起黄仁宇大历史观的曲线图。

扯远了，我也不知道想表达啥。人好像越大，越不习惯去表达内心。不管怎么样，往后会往花点时间在这里写点啥，也不至于失去表达能力。

对于memset的使用，基于“定义变量并严格初始化”这条黄金法则。所以，每次使用一块内存时都很小心的初始化它，以防止某些意外错误的发生。但却不知道memset()初始化大块内存时，耗费吓人！其实我们只要流程上控制好，根据需要采取首位或所需最后位补0的方法，也是可以搞定这个事情的。

具体可以见下面这段测试程序：

#include <stdio.h>
#include <sys/time.h>
#include <time.h>
#include <string.h>

#define BUF_LEN  (1024*1024)
#define TIMES     512

double use_noset()
{
timeval timestart,timeend;
gettimeofday(&timestart, NULL);

for( int i = 0; i < TIMES; i ++)
{
char* buff = new char[BUF_LEN];
for(int j = 0; j < BUF_LEN; j++)
{
buff[j] =0;
}
delete[] buff;
}

gettimeofday(&timeend, NULL);
double linStart = 0,linEnd = 0;
linStart = ((double)timestart.tv_sec * 1000000 + (double)timestart.tv_usec);    //unit S
linEnd = ((double)timeend.tv_sec * 1000000 + (double)timeend.tv_usec);       //unit S
double time = linEnd-linStart;
return time;

}

double use_memset()
{
timeval timestart,timeend;
gettimeofday(&timestart, NULL);

for( int i = 0; i < TIMES; i ++)
{
char* buff = new char[BUF_LEN];
memset(buff,0,BUF_LEN);
delete[] buff;
}

gettimeofday(&timeend, NULL);
double linStart = 0,linEnd = 0;
linStart = ((double)timestart.tv_sec * 1000000 + (double)timestart.tv_usec);    //unit S
linEnd = ((double)timeend.tv_sec * 1000000 + (double)timeend.tv_usec);       //unit S
double time = linEnd-linStart;
return time;
}

double use_setlast()
{
timeval timestart,timeend;
gettimeofday(&timestart, NULL);

for( int i = 0; i < TIMES; i ++)
{
char* buff = new char[BUF_LEN];
buff[BUF_LEN-1] = ‘\0′;
delete[] buff;
}

gettimeofday(&timeend, NULL);
double linStart = 0,linEnd = 0;
linStart = ((double)timestart.tv_sec * 1000000 + (double)timestart.tv_usec);    //unit S
linEnd = ((double)timeend.tv_sec * 1000000 + (double)timeend.tv_usec);       //unit S
double time = linEnd-linStart;
return time;
}

int main(int argc, char** argv)
{
double t1 = use_noset();
double t2 = use_memset();
double t3 = use_setlast();
printf(”no memset used =%f, memset used t2= %f, no memset used t3=%f,t1/t2=%f t2/t3=%f\n”, t1, t2, t3,(t1/t2), (t2/t3));
}

跑出来的结果是：
no memset used =2118321.000000, memset used t2= 102161.000000, no memset used t3=37.000000,t1/t2=20.735124 t2/t3=2761.108108

从结果可以看出，memset()，比直接给每个字节赋值要快20倍，但跟后位置零相比，整整慢了近3k倍。如果运行高并发的程序这种效率就很要人命。

教条主义真是害人。多动手实践，不要做多余的事情，控制好你的程序才是最关键的。

它用来传播消息，让更多人了解到事件背后的真相，各种新闻和论坛站点让消息的获取更加低廉和加快速，全名博客运动更是提出每个人人都是公民记者的口号，twitter更是让这种消息的传播速度达到极致！

它还让每个人有都能自由地分享知识，打破知识的垄断。如今通过搜索引擎这一入口，我们几乎可以获取到各个方面的知识。小到衣服沾了油渍如何清洗，大到制作一颗原子弹的技术细节，无所不包。维基百科更让全民都参与知识的整理和编撰的工作。致使大英百科全书在它面前显得如此渺小。

它也可以用更低的成本解决现实生活中的问题。email降低我们的沟通成本。各种B2B，B2C，C2C可以方便地进行交易。征婚交友网站帮我们找到生命中的例外一般。招聘网站帮我们找到好的工作和雇员。诸如此类，互联网均扮演重要角色。

做为互联网的从业人员，从互联网这几个作用的角度来看，我们就总喜欢让互联网来帮我们解决一个实际的问题。让它来做为一个教化的角色，传播文化和知识，觉得做一个互联网的应用就应该有高远之理想。以致曾想做一个大学生社区，能够教那帮小盆友们如何让大学生活过得更有意义。对，“有意义”这个词相信很多看过《士兵突击》的人都很有印象。

但实际的生活其实往往不是这样。一好友，最近工作不忙，闲来拿着一本言情小说来读。会怎么认为呢？肯定生活太无聊才这样。但其实她挺享受这种悠闲。她讲这句话的时候，我简直嫉妒死了。

林语堂说：一切中国的哲学家在不知不觉中认为唯一重要的问题是我们要怎样享受人生？谁最会享受人生？简言而之，就是如何让生活多点快乐才是最重要的事情。

而互联网呢？我们发现它越来越走向娱乐化。开心网凭借一款买卖奴隶的游戏就发展得如火如荼，QQ的娱乐化更让它赚个钵满盆，业界没有不眼红的。游戏行业更是撑起中国互联网业的半边天。但我们太多的业内专家都在讲中国的网络太过娱乐化。我也一度深受其印象，最想着要志存高远，做有意义于生活的互联网应用。

但生活本来就很不容易，没几个人打开浏览器就看到一大堆的说教，一大堆的人生意义，我们更多地需要写乐呵的东西，好好放松，享受人生。目前的互联网从这个角度看，就如和菜头在最新博文《玩》中指出中国互联网“不是太过娱乐化，而是根本娱乐得不够。沉默的大多数之所以是沉默的大多数，是因为他们没有可以参与的活动。屈指数一下，在网络上的集体游戏有几种范式？投票、跟帖、Digg、转载，还有什么？”

我们确实没有提供更多好玩的东西，这点值得好好深思。

class  Article(model):
pass
class ArticlePicture(model):
article =  model.GenericForeignKey(Article)

删除掉article对象是，就会自动删除掉关联的ArticlePicture对象。
如果包含GenericRelation关系，则需要显示声明才能删除掉关联对象。比如：

class Article(model):
pass
comments = generic.GenericRelation(UserComment, object_id_field="object_pk")
class Comment:
content_type = models.ForeignKey(ContentType, verbose_name='content type')
object_pk    = models.PositiveIntegerField('object pk', db_index=True)
object       = generic.GenericForeignKey('content_type', 'object_pk')

body = models.TextField(max_length=COMMENT_MAX_LENGTH, verbose_name="评论内容")

对于这种，comments = generic.GenericRelation(UserComment, object_id_field=”object_pk”) 才叫显示声明。删除Article就会删除指向它的所有相关评论。一切都是如此地方便，不用多操心！
b. 模板中的for标签。for标签远不止一个循环那么简单。还提供了不少很贴心的功能。比如forloop.first ，它可能判定那个元素是这个序列中的第一个。这个有时候非常关键，比如我们要一个切tab的操作。我一开始是这么做的：

{% for item in items %}
{% if item.is_first %}
<div class="first">{{ item.something }}</div>
{% else %}
<div >{{ item.something }}</div>
{% endif %}
{%  endfor %}

我就必须在views函数中，将序列中第一个元素：
items[0].is_first = True
这样的操作。虽然python的动态特性，很方便地解决了这个问题，但整个代码显得非常丑陋。细读文档，发现有forloop.first,这样就简单，优雅多了，如下：

{% for item in items %}
{% if forloop.first %}
<div class="first">{{ item.something }}</div>
{% else %}
<div >{{ item.something }}</div>
{% endif %}
{%  endfor %}

所以，一定要没事多读文档！
3.  模块化，不光是程序，还包括模板。

Django的按照app和template天生就具备极强的模块化特性。整个结构看起来非常规整，有序。仔细划分项目的功能，将不同的app分化出来，app的共同部分还而已抽取出来。另外对于模板文件，应该分析整个页面元素的特性，尽量把不同的内容独立出来，然后用extend 和 include 继承和包含进来。这样便于以后的维护和扩展。因为重复=易错+难改。

闲来无事在网上闲逛发现Bruce Eckel大牛(写Thinking in c++/ Java的家伙，能写如此畅销的技术书，我觉得算是牛人)的一篇新文章：Writing Software is Like … Writing。 探讨程序开发到底是个什么玩意儿。

文中指出，最初的Programmer大都是数学家或者工程师。貌似很自然地可以把程序开发类比于科学或者工程。但深究之，却发现他们异巨大。因为数学都是可计算，可论证，对错选其一而已，但程序却常常broken 掉。又如果说程序员就是一工程师，但我们却常常发现不同的程序员产生的结果差异巨大。而且软件工程的标准化是如此之难。所以，这两种类比显然都不太合适。

所以程序员既不是科学家，也不是工程师。这也可以解释程序之间，诸多项目中间，成功与失败，为什么有如此大的差异。那我们是什么呢？

作家，另外一种作家，这个称呼最符合我们。

大多数的人都很容易将词语组合成句子，而且不需要成为作家就可以毫无障碍地交流。君不见，博客大兴，几乎出现全民写作的盛况。而大多数程序员都能写些特定地，凑合能用用得程序出来。很多非专业的程序员，学个html语言，javascript写几个网页还是很简单的事情。

同是受过基本的文字训练，好的作家却能把大家所熟识的词语，组合起来，或行云流水，或妙笔生花，强大之处以致直指人心，千古流传。但大多数人的文字却是索然无味，枯燥干涩。而反观程序员，计算机大牛们能够用相同的程序语言写出更加简洁，优雅的代码或者更要好的工具出来。

二者的成长过程也非常类似。先接受基本的训练（不一定要走传统的教育模式，很多程序大牛均自学成才，正如很多作家走的是夜路数），然后不断地模仿，学习各家地所长，通过大量的训练，摸索出自己的风格和套路。最终，独步于江湖。所以，Programming仍然是相当具有创造性的一项劳动。

对于自己而言，人生之最大理想莫过于这句”左手程序，右手诗“。

excel是我第一个想到的工具，弄个总的功能表，再针对每个大功能进行细化。写上各种功能说明。但写了一个大提纲之后，就无法进行下去了。光有文字描述，过于空洞，每个图片，页面的大致布局，一点感觉都没有。估计，写完之后，连我都不想多看。

放弃excel之后，我转到visio，这可是个强大的玩意儿，我们前期的讨论一直基于由它画出来的图片而来。还学习了一篇专讲如何用visio设计网站的文档，但那个用起来太不顺手了，页面之间的链接和跳转极难组织。我只好又转向mindmanger。

mindmanger在长于思路的整理，还可以设定事情的完成度。一张图表下来，从可以全局观察，可以局部观察，整个非常清晰，比excel罗列的一大堆文字强多了。但几个topic下来，发现它实在是不适合网站的设计需求，粗粒度的组织还不错，但稍微详细点，就没法表达。

哎，我相当愁。只要借助于google，终于我发现了：Axure RP。啊，真是很强大，很专业的东东。

它是网站原型设计的定制工具。目前为止我觉得它最好用的功能数：

1. 强大的页面组织能力。通过链接和表单点击事件，把页面之间的关联和跳转自动维护起来。从一个页面很方便地点击进入另外一个页面。

2. 定制master。把一坨页面元素放在一起，生成一个自定义master，然后像普通的页面元素一样直接拖到其他页面上。比如：我定义一个sidebar页，然后所有的其他页面就可以直接用，不需要在一个个地绘制sidebar的样子。很强大的复用概念。非常符合现在web开发框架中模板设计的概念。这个设计好了，以后的模板设计，整个就可以更着走。

真的是非常好的工具，不敢独享，跟大家分享一下，使用之前，不妨先在这里，花上一个小时，看一个简单地教程，相信用起来更加事半功倍！

分离式，很cool啊，我新近设计的站点中，就采用这种方法，整个页面看不到一个js事件。但导致的结果是，有些响应点击的地方，很容易失效。仔细分析问题所在，发现是页面显示解析成功之后，加载js事件时，耗时在秒级。所以，导致在页面刷新很快时，页面元素的事件还没有来得及加载上去，从而，点击失效。

最后，我又不得不把关键性的事件挪到页面上，整个页面虽然乱点，但只要页面显示出来，相应的事件肯定已经加载好，不会出现点击失效的情况。

看来完美的设计总是不存在的，我们总需要牺牲一些东西，权衡，然后折中。不过，听说新版本的jquery已经在dom选择器的速度上有很大改进，但怕存在兼容性问题，不敢轻易试用。

这两天读了一下，做了一个简单地笔记，原文可以见：http://gettingreal.37signals.com/GR_chn.php

37signals团队在这一波web2.0大潮中，名气响亮。开发了Ruby on Rails的web framwork，深受开发者的喜爱。而且基于Ruby on Rails

做了几个web产品，很受欢迎。

建构从简（2）

·  做得要比竞争对手少。“少做”的含义：

·  更少的功能

·  更少的选择项和首选项

·  更少的配备人员和企业架构

·  更少的会议和抽象讨论

·  更少的承诺

·  为自己而做这个软件（这点适合我啊，我有不少的需求）

·  准时地早预算范围内推出产品：定额定量，绝对不要在一个难题上多投时间和金钱。要么缩小规模，要么缩小范围

·  了解你的应用程序应该做成什么样子的最佳方式就是：认识到它不应该成为什么

·  不要跟在竞争对手后面跑。要创建一个不同的故事来说服听众，告诉他们你的故事比他们在其它地方听到的更重要。

·  只看大方向，时时提醒自己什么是我们想要解决的问题关键，怎样去解决它。

·  不应该成为一种交易，要保持激情，如果你做这个软件一点都不兴奋，那就什么地方出问题了。

保持精益(3)

·  做得越精益，改变越容易

·  让限制带领你到创新的解决方法

首要任务(4)

·  竭尽全力将你的软件定位在一个点上。保持简洁的理念，所有的行动都要在这个理念的指引之下。

·  组织需要指导原则。需要有一个纲要；员工每天醒来时应该要知道他们为什么而工作。这个纲要最好言简意赅，富有激情：为什么你会在这里？是什么激励了你？

·  不能过早地限于细节。细节是你在使用的过程中才会显露出来的。只有在使用中你才能看到什么需要进一步关注，在使用中你在感到缺了些什么。

·  当问题成为问题的时候才去担心。

·  要清楚地知道你的产品是为谁服务的，然后集中精力去讨好这部分人。

·  先把一个伟大的产品推出，然后才去担心它无比成功了以后改怎么办的问题。（大规模问题，遇到了在考虑）

·  伟大的软件必须要有自己的理想，必定是有倾向的。对于不认同你的理念的用户，可以舍弃掉。

挑选功能(5)

·  部分而不是残缺不全：摆出产品应该成为什么样字的任何点子，然后砍掉一半。

·  只留精髓，去掉“无所谓”的功能需求。

·  从说“不”开始： 不轻易实现功能； 不要成为yes-man；不要试图去讨好任何人。

·  构建你有把握的产品和服务，不做能力之外的事情

·  为一般概念构建软件，并且鼓励人们创建自己的解决方案

·  对于客户的需求，say no ！Just read them and then throw them away(因为真正核心的需求客户会不断地提醒你，以至你无法忘却。)

·  询问客户他们不需要什么功能，而不是总问他们需要什么功能。

·  Innvoations comes from saying no！

We’re always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important.

—Steve Jobs, CEO, Apple (from The Seed of Apple’s Innovation)

操作(6)

·  尽快地推出一个真实的产品

·  更快地推出一个积极的产品，而不是一味追求完美的产品。通过真实世界的反馈，来引导产品的发展。

·  Geting Real的过程：从灵感，到草稿，到HTML， 到代码

·  少用设置选项，帮用户做出决定。有抱怨，再修改不迟。这样在减少用户负担的同时，也减少了开发成本。

·  快速决断，搞定之，不行，回头在修改之。

·  在使现实中测试你的软件。

·  任务尽量细化

组织(7)

·  整合团队。不要分离成独立的小单位

·  深度睡眠是真正的睡眠魔法发生的地方；独处的时间是真正的开发魔法的地方。

·  在工作中建立一条规定：一天中一半的时间作为独处的时间。Just shut up and get to work。

·  会议有毒：通过email，IM来快速讨论。

·  会议原则：设定30分钟的计时器；邀请尽可能少的人；没有明确议程的时候不要开会

·  没事多发布点什么，以提高团队的积极性和成就感。

人员配备(8)

·  不要随便招人。

·  通过测试项目的协作来摸底候选员工

·  通过开源社区去寻找所需要的人（可惜，在中国很难）

·  选择能快速学习的多面手，而不是专攻一面的专家（我喜欢）

·  选择快乐和技术水平中等的，而不是令人不满的专家。（热情很重要）

·  招文字功底好的人。

界面先行(9)

·  开始编程之前先设计界面：编程是构建应用的过程中最笨重的部分，也是改动起来最复杂，成本最高的地方。

·  震中设计：先设计核心的内容，再向外拓展，比如：导航栏，页脚，用色，边栏，标识等。给用户一个更友好、重点清晰的界面。

·  每个界面考虑三种情况：常规，初始，错误。缺一不可。

·  忽略初始界面的节点是你会犯的最大错误之一。初始界面是第一印象，失败就完。

·  初始界面应该包括：

    * 利用它作为添加新手指南和热门推荐的机会。

    * 给出一个填满内容的页面截图，这样能让人们有所期待。

    * 讲解如何上手，页面最终会像什么样子等。

    * 回答第一次来的访客会问到的关键问题：这是什么页面？我在干什么？页面有内容的时候是什么样子？

    * 做好预期准备，帮助减少挫折感、恐惧感和大的迷惑。

·  必须做好保护性设计。

·  细节的一致性没有必要。重要的是It depends

·  好的文案工作也是设计的重要部分

·  整体界面保持一致

代码(10)

·  保持代码的简单

·  幸福最大化

·  Listen when your code pushes back

·  开放接口：Get data out into the world via RSS，APIs， etc。

文字(11)

·  功能定义一点用都没有，坚决抵制功能文档

·  Don’t Do Dead Documents

·  Tell Me a Quick Story

·  Use Real Words

·  个性化你的产品

结论(16)

·  执行力: 成功仅在于优秀的执行力

·  人：有工作热忱的人

Pinax，基于Django之上给出许多社区开发元素，比如：tag，blog，friends，twitter clone，group，bookmark，wiki等。非常丰富，全面。去官方站点下载一个源码包下来，根据说明文档，修改一下配置，几条命令就可以搭建出一个功能全面的社区来。虽然是丑陋了一点。但功能太齐全了。另外，不想搭建想体验一下效果不然看看一小伙儿把它中文化的站点：pinaxcn。

可惜的是文档少了一点，只有深入源码。熟悉Django的很多Conversion，看看具体它的设计中,如何把一个社区元素给独立划分成单独的引用，又如何拼接起来。还有一些Django的高级引用。如自定义Field， Template tags,  Signals是如何用的，等等,都大有裨益。

Django自动化和复用方面做得非常好，换来的代价是需要很好地熟悉里面的Conversion，了解很多tricky的地方，这样才能发挥它的最大效能。

嗯，现在还只停留在学习的阶段，等实际搭建出一个站点之后再来谈谈具体的感受。

首先·把其官方首页，浏览一遍，大致知道它是什么东西。简单而已，就是把缓存的数据按照key，value做了一个大的hash表。然后定义了一套很方便的数据访问协议。有server和client之分。server负责缓存数据，接受client的请求。而且，支持分布式。

分布式，我每次听到这个名字都觉得异常高深。头脑就会冒出：分布式，N台机器，调度，协调，map/reduce，等一堆词，最后归结于一个词：复杂。但Memcached的分布式之简单，大出意料。我们看图说话：

上图中的node1，node2，node3就是server端，中间有一个客户端程序库的中间层，应用程序直接通过客户端程序库来访问server端的数据。其分布式就在于服务器列表那里。一个查询key过来，根据key，分配到对应的服务器列表中的某个服务器端node(i)，然后跟node(i)通信，获取相应的数据。

简而言之，将不同的key映射到不同的服务节点上存储，服务节点本身不通信。真是非常简单明了。我觉得这样的好处在于，保证服务端设计的简单。只是建立hash，影响简单地key的建立，查询，更新请求。这样的可扩展性很强。缓存不够，加几台机器，加内存就OK，服务端没有任何新的负担。服务端只需要保证查询的高效和稳定。由于不需要全局的调度服务， 因而也不会有单点失效的问题。但这样就把分布式的任务转移到客户端，只需要客户端做一个key到服务节点的映射。

你看，整个设计是不是相当之简单？但正式这么简单地一个设计，Memcached大行其道，被很多站点所采用。facebook在一篇文章中，还重点讨论了很多关于如何优化它的好文，见这里，中文翻译见这里，总结可以见这里。而且可以看到facebook用Memcached在800台机器上，做了整整28T的缓存，那可是28T的内存数据，真的很夸张！所以，设计和运营这种大型的网站真是一件非常有挑战和有意思的工作。

哦，对了，本文中的图来自于文档《memcached全面剖析》，此文相当不错，把Memcached的方方面面讲述得很清晰，是运营日本的mixi站点的技术人员所写。日本人做事之细致和专注还是很值得我们学习的。