大家在北京和上海的苹果专卖店，会发现每个店员手上都拿着个iPod Touch 4，把你要买的东西的条码扫描一下，就把收银条给你打印好，你直接给现金或者刷卡就能把东西拿走，不用像其他的零售店一样到前台结账。

苹果的所有专卖店都启用了移动服务终端，它具有销售+客服+排队+收银等功能。依靠它，店员可以在客户所在的位置，各自并行，独立的开展工作，无须等待经常出现排队的收银环节，同时也可以把更多的时间用在专心接待客户上。

苹果所使用的移动服务终端硬件，就是iPod Touch 4，加上 Linea-Pro（条码扫描器+磁条读卡器），条码扫描器用于读取每个销售品的条码和序列号，磁条读卡器用于支持刷卡支付。

今天介绍的iScan，就是跟Linea-Pro一样的条码扫描器，它可以把iPod，iPhone和iPad变成移动条码枪，配合定制的软件，能够完成零售，库存采集等工作。

iScan和Linea-Pro的区别是什么？

1、iScan只有条码扫描功能，Linea-Pro还能完成刷卡。

2、iScan的零售价格是199美元，Linea-Pro是499美元。

iScan的外观

外观很小巧，整个包装盒才打火机大小。

打开包装之后，iScan的实际高度，不到打火机的一半。

接到iPad和iPod Touch 4上的效果。

iScan的官方软件

iScan接上iPod之后，会贴心的提示安装官方应用Command Center，是免费的。

Command Center的功能比较简单，主要是测试条码扫描，设定部分是配置Mac上的服务端，可以把扫描结果通过WIFI直接传送到Mac，实现Mac的无线条码扫描功能；另外就是设置条码在线搜索的服务商，支持自定义。

iScan的技术参数

iScan在条码规格支持上很全面，具体的范围可以看这里。它的电源直接从iPod取，没有单独的电池。按照官方的资料，可以在iPod Touch 电力全满状态下，扫描8,000次以上，足够支持一天的工作了。

iScan的试用总结

iScan的扫描速度非常快，几乎是红光一闪，条码就扫描到了。误码率也很低，在实际测试过程中，没有遇到读取错误的情况。iScan上的硬件扫描钮用起来也很方便，比软件按钮跟容易操作。

大家如果有兴趣，可以移步到mobilogics的官方网站，查询更详细的资料。

“天上白玉京，十二楼五城”，盛唐时期的李白，写下如此气势恢宏又幻象万千的诗句之时，或许很难想像数千年后，它们自云中款款而来并呈现手中的样子——在移动互联网时代，连接云端的手机已经成为富丽堂皇、奇珍充盈的商城的在线橱窗。

对于身处拥挤都市又工作繁忙的现代人来说，时间成本和选择成本正变得日渐高昂，于是诸如“万达广场”、“大悦城”之类大型的MALL成为人们工作之外娱乐、餐饮、购物、运动、休闲的首选。“淘宝”、“京东商城”和“当当网”等在线电商平台解决了非实时的淘货与比价型消费，而Mall商城的实时实地的体验型消费又如何通过手机来进行指引和形成用户黏性？对此，彩程设计结合来自市场的需求与项目，进行了一系列的探索和实践。

作为龙湖地产的移动战略合作伙伴，彩程去年为他们推出了三款商城地产类的App（含iPad与iPhone版）——“龙湖北城天街”、“龙湖西城天街”和“龙湖星悦荟”，尽管因为地域性太强的原因不可能有类似通用型App的大量下载而进入App Store的榜单前列，但比上海新天地，海港城guide，朗豪坊等同类App的排名要高出一大截。

为龙湖地产开发的商城类App

iPhone的有趣之处在于，它以设备为基础很好地为我们划定了一个圈层：消费能力中上；追求品质与体验；对时尚和新锐的东西接受度高，对互联网尤其是移动互联网不陌生——这正好是大型商城所想要笼络和争取的用户群，而安装了商城应用的iPhone本身即为一张VIP会员卡。

从商业经营的角度来讲，MALL通过成本、规模和管理方面的优势，让业态的聚集效应更突出，消费体验更丰富。而对地域性用户来说，只记住一个大品牌和一站式入口又无疑是最省事的方式。

我们设计的这三款APP大同小异，以导购型信息呈现为主，内容由活动、订餐、优惠、商家、微博、关于等几个模块构成，前台展现上根据信息的重要性以及属性特征制定好详略得当的交互框架，数据则由商家根据线下活动和后台即时更新。

商城App内容结构

龙湖星悦荟App典型界面

龙湖星悦荟App后台录入界面截图

商城类App，与商城整个线下经营以及对App的需求定位密切相关，2012，彩程再接再励，正应客户要求，着力打造一款涵盖商城信息、会员服务、二维码与在线分享的全新App，实现客户、商家与商城之间的互动与多赢，相信它出场会更为惊艳和值得期待。：）

抽空读完了多看版的《创业36条军规》，有不少可以借鉴的，在此做一些书摘吧。

1. 暴风影音的冯鑫的创业四原则：(1)凡事只能靠自己。(2)万事皆有解且有唯一正解。(3)凡是你担心的事一定会发生。(4)享受创业过程。

嗯，可能有时候我们会说，放权给我们的队友、相信团队成员的能力、扬长避短之类的，这不是和“凡事只能靠自己”的说法矛盾么？其实在读这本书的时候，有各种观点会充满矛盾，但实际上最核心的也是这些矛盾，我理解的即是在创业过程中不断地自省以及直面自己内心的独立思考的能力，像“凡事只能靠自己”这句话应该是在自己有逃避责任的倾向的时候需要告诉自己的。同样，万事皆有解且有唯一正解，如果脱离提出它的场合，很容易被理解为独断专行的绝对主义，你也可以说万事万物皆有无穷可能、参差多态乃世界美的本源，但实际上我理解孙陶然老师引用这句话的核心观点是：需要相信你手上的问题能够被处理掉，是坚持做下去的动力。“凡是你担心的事情一定会发生”更是一句自省的话了，如果真要学院派的去做一个统计，你可能会说我担心的事情65.74%都没有发生，这句话是错的，但实际上这是一句让你随时清醒与保持冷静的说辞，得这样来理解。最后“享受创业过程”，是帮助人缓压的办法，既然是你自己喜欢的事情，好好享受就行了，得之我幸不得我命。所以下面的书摘也需要考虑实际的上下文来理解，不然扣上“心灵鸡汤”、“打鸡血”的帽子是最简单和没成本的。

2. 心力强大就是活得明白，能够快速调整自己的心态，一味放纵自己的情绪不但会让情绪在放纵中放大，还会影响到自己身边的人，其结果必然与你的愿望适得其反。如果把自己的心态和心情建立在需要别人怎么对自己的前提下，别人会很累，自己的心态和心情也永远无法和谐，必然陷入永无止境的纠结之中。

这些年最大的感触是，我们心理上的不安的核心来自于对欲望的迫切要求，想要尽可能快的获得‘成功’或‘自由’，就像我们糟糕的教育经常宣传的那种非黑即白的人生观一样，我们有时候会对一些没得到的东西充满贪欲，但实际上首先我们的追求本身不会是完美的，其次我们很多时候又像是在活别人的生活，我们看到的一些书、一些人，很崇拜，所以就去让自己做一些那些人做的事情，把自己的情绪模仿成他人的情绪、移情，核心仍旧是自己对欲望的强烈渴求，但是不管欲望的目的是‘自由’还是‘财富’，也即是不管欲望的目的是所谓崇高的还是所谓功利的，如果太迫切的放任自己以及太过于认真，都会导致心态的失衡。这个时候最重要的应该是‘认识自己’，崔卫平老师有篇文章叫《需要一个低版本的人性观》写得很好，经常翻出来看看，杀菌消毒。

3. 绝大多数情况下，绝大多数人是没有主意的，谁能提出建议并且能够自圆其说，谁的主意就会使团队的主意。

嗯，我经常觉得“我所说的都是错的”，那是因为我从来不相信一个人能够通过逻辑来彻底理解哪怕是世界上最小的一个现象，很多事情无法被证明，就像非常简单的你无法证明眼前看到的世界是‘客观存在’的一样，所以这样的理解带来两个观点，第一是所有的权威都是臆想，特别在我们这个本来就很落后的国度，所以我们都不是精英，做的决策一定不会完美，因此试错是允许的也是合理的，在一个落后的地方建设要从基础开始，所以团队的leader一定不要害怕决策错误，大家又不是在赌命，心态宽松一些，包括在决策没有太好的市场反响的时候，心平气和的改良和复盘，好过苦逼兮兮的抓耳挠腮手足无措。嗯…好像说偏了哇….你看嘛，我说的都是有问题的。

4. 所谓机会就是别人不看好的时候你去尝试了，所有的成功者都是敢于冒险的人。实际上，行动本身就创造了最大的成功机会。所以后来者有六成把握的时候就应该扑上去，小公司只有更多地冒险才能换来更多的机会。

“行动本身就创造了最大的成功机会”，和上一点的观点类似，谁能参透事物的本质呢？无非是走得多了，经验更丰富罢了，像天才一万小时的理论一样，挖掘出来的常识就是，联系得多的人渐渐变成了“天才”，而真正的天才也许存在，但是和我们有啥关系呢，世界上所有美与好的东西又不是全靠真正的天才建成的。所以带着独立思考和自省的态度放心去做即可。

5. 团队成员需要协同作战，有三个原则非常重要：(1)共同的愿景和价值观。(2)彼此信任。(3)注重沟通技巧。

孙陶然老师说注意沟通技巧尤其重要，深以为然，我认为沟通有两点必须做好，一是公开，二是理解，公开无需多说，如果不公开自己内心所想，那还沟通个屁，前提都不成立。其次是理解，核心是能够换位思考，特别是在持不同观点的时候，如果能稍微踩一脚刹车，试着换到对方的角度和思维习惯去理解他说的话的意思，这样能避免由于观点不同导致激烈冲突，而且如果能真正理解对方的观点，在说服对方接受自己的观点也会顺利一些，成功率更高。

6. 西方人习惯用契约来解决问题，先小人后君子。中国是一个喜欢将人情与商业、政治与经济混在一起的国家，中国人喜欢用情义来解决问题。事先你好我好大家好，而一旦出现分歧，这个不行那个不行怎么都不行。你和我讲契约，我和你讲感情，你和我讲承诺，我和你讲道理，纠缠不清。

切记，所有的分歧和意见最后需要形成契约和规定，人人都有选择权，参与还是不参与，但是一旦选择了就按照契约来，把自己讲得很崇高很有理想太容易了，占这样的小便宜真是心头又爽又划算，还可以到处吹嘘，但真要做好事情得都和规矩较真，包括和这个社会的规矩较真。

7. 如果可能，创业要选择最肥的市场入手，在一个大市场中占有一个小份额就了不得了。选对创业方向事半功倍，不要会啥做啥，要抓住用户的强需求来创业，在个人爱好、个人特长及市场需求之间找到一个平衡点。

个人觉得，社团和公司最大的区别在于‘爱好’、‘特长’和‘需求’的顺序，做社团，最大的选择依据是爱好，喜欢什么就扑上去做吧，这样才能慢慢把爱好培养成特长，需求可以最次之，随缘。但是公司得反过来，首先得考虑的是需求，其次是特长，最后才是爱好，要由自己的性子喜欢什么做什么那还是别创业了，那叫求生活，自己一个人玩就行了，一帮人在一起，彼此都是负有责任的，这在我们这样的小年轻居多的创业公司尤其需要多多思索。另外关于需求，书里面有些观点摘抄一下：“什么是需求？用户愿意支付代价的取药就是需求”，但是根据需求做出来的东西不一定能叫“产品”，“如果只是少数人在少数时候才会需要的，趁早别做，那叫概念不叫商品”，“也许用户今天会在网站上停留三小时，但三周不来，他也无所谓”，“需要和购买是两回事，有些需求其实不存在，例如那些可有可无的需求，那些用户根本不愿意为之付出代价的需求，以及那些可以被替代的需求，都属于锦上添花的需求，对消费者而言有了更好没有也无所谓”。

8. 所有的成功都是因为啃下了必须啃的骨头而不是捏到了捏得动的软柿子。

别畏难。

9. 创业期的公司大多业务未定型，核心任务是找方向，寻求业务突破。任何一级领导都不能只管人不管事，尤其是核心高管，不懂业务和不参与业务的高管必然被淘汰。

创业团队没有人能够做到脱离于具体的事物运筹帷幄，有这样的人的话也只说明他是多余的，因为创业初期一切未定的时候，哪里有什么好运筹的，相反最关键的倒是去深入团队所做的每一件事情里面，不是干预，而是深深的了解每一个项目的进程、每一个成员的进度、每一个产品的细节和功能，这些其实是给定方向提供足够的参考，参考越多、越细致的话，决策失败的几率可能越小。

10. 一个被彻底贯彻了的战略好过朝令夕改。

彻底贯彻这几个字本身就是一个不断提高执行力的过程，也是杀怪吃分升级的过程，现在砍不翻大boss没关系，怕的是畏首畏尾，大的吃不下来，小的又不想吃，自己手里的没做好就望着其它地方去了，做项目也是一样，复盘留到项目结束后再来，做项目的过程全部精力都应该是：搞定它。

11. 一个团队的战斗力不是由队伍中最聪明的那个人决定的，而是由战略的正确性和团队的齐心协力决定的。尤为值得关注的是队伍中的“聪明人”，他们是队伍中的危险分子。登山时他们总想抄近路，游戏时他们总想去守株待兔，时不时就脱离预定位置让同事踏空。聪明人总认为自己聪明，所以贯彻领导指示之前总要评估一下领导对不对，往往不会去理解领导的意图而是沉湎于自己的意图。聪明人对团队的贡献在于其创造力带来的鲇鱼效应，但鲇鱼只能敲边鼓不能挑大梁。

两点：团队的核心成员需要重视大局多余重视自己的才能的展示和发挥，因为核心成员是挑大梁的，要更有责任心。其次，我认为这里所指的聪明其实并不是真正的聪明，就像我之前听人说的某种“中国式的智慧”，去你妈逼的智慧，既短视又自以为是还他妈的不反省，有哪个聪明的人会这么做呢？真正聪明的话，多多考虑别人，多多付出结果才会双赢。

12. 不要认为你自己是产品的用户，当你研发产品的时候你已经不是用户了，因为你每天沉醉在产品里边，对产品的熟悉程度已经远远超过普通用户，你已经不可能理解普通用户的使用体验了。

这又是一个不结合上下文理解的话容易误解的观点，自己做的产品自己不是用户的话也趁早别做了，这句话的意思是这样的一个反省：当自己太熟悉自己的产品的时候，可能对普通用户对产品的需求、体验上的判断容易错误，比如一些功能因为是自己设计开发的，可能自己很清楚，但是看普通用户的使用才发现不是这样。举个更远的例子，我发现我们长时间使用电子类产品所以对它们建立起来的各种理解在那些不常用电子设备的人身上是完全无效的，一个很简单的小叉按钮我们看着明白是取消、删除之类的意思，但是不怎么使用电脑的用户就可能不知道，所以核心还是，别自以为是，多留一些余地，多思考多实践来找方法。

13. 人生最关键的是两件事：想清楚和坚持住。想清楚两点：(1)根本目标–你想过什么样的生活。(2)最高准则–你想成为一个什么样的人。坚持住两点：(1)上进心–立志让自己成为同学之中的出色者之一。(2)执着劲儿–坚持自己的追求，遇到任何苦难都不放弃。

一直以来觉得人生本质是很荒诞的，因为面对“既然我们都会死亡，那活着有什么意义”这个问题的时候，所有的答案从某些方面来讲都是虚无的，但实际上我们在生存的时候依然具有喜怒哀乐之类的情感，是因为我们天生的会喜欢高帅富真善美，所以我们为什么每天兴致勃勃的做着做那，充满希望的生活下去，无非是舍不得那些让我们感到充满欢喜的事物，而我个人想要的，无非是自由的在一个拥有这些美好体验的环境中生活，而我也期待能在这个环境中创造出一些美好的事物来，这是我的最高的生活目标。

我们在做一些网站项目的时候，可能会遇到需要把某个全局变量注入到所有页面的情况，比如我们做一个在线商城，那么可能需要将用户的资料：比如用户的账号、用户的姓名等注入到每个页面里面。

TeamCola中每个页面右上角都会出现的用户名

但是如果用常规的方法，也就是在每个views方法中通过render_to_response方法注入用户数据的话，这样就会做非常多的重复工作，就像下面这样：

def views_meth1(request):
    return render_to_response('template_1.html', {'user': request.user})
 
def views_meth2(request):
    return render_to_response('template_2.html', {'user': request.user})
 
def views_meth3(request):
    return render_to_response('template_3.html', {'user': request.user})
 
# ...剩下的N个方法

这在需要传入的变量比较简单、数量较少的时候还行，一旦需要注入的变量多一些，或是需要经过一些额外的计算才能生成的时候，那就麻烦大了。所以如何避免这种repeat yourself的2B模式呢？我们可以选择如下的一种模式：

在每次创建新的django项目的时候，一般来说我们都会在根目录中创建一个类似名为utils.py的工具module，在这个module中，我们可以通过定义一个自己的render方法，来为每次模板的渲染注入指定的全局变量：

# in utils.py:
def mp_render(request, template, context={}):
    context['user'] = request.user
 
    return render_to_response(template, context)
 
# in views.py:
from utils import mp_render
 
def views_meth1(request):
    return mp_render(request, 'template_1.html')
 
def views_meth2(request):
    return mp_render(request, 'template_2.html')
 
def views_meth3(request):
    return mp_render(request, 'template_3.html')

很好理解吧，这样以后有新增加的全局变量需要注入的话，只需要修改mp_render方法就行了。嗯，这是很普通的方法，既然是普通方法，那就再来个文艺点的吧。

先来看看django文档里面对于render_to_response这个方法的定义吧，在’Required arguments’里面，有提到这个方法的第三个参数，叫context_instance，对于这个参数的说明如下：

The context instance to render the template with. By default, the template will be rendered with a Context instance (filled with values from dictionary). If you need to use context processors, render the template with a RequestContext instance instead. Your code might look something like this:

return render_to_response('my_template.html',
                          my_data_dictionary,
                          context_instance=RequestContext(request))

大意是：“默认的，render_to_response方法的第二个dictionary参数会被填充为一个Context对象注入进html模板文件里面。如果你需要使用context processors，那么需要使用一个RequestContext对象来渲染模板。”

那么什么是context processors呢？看完这一段文档的定义以后，应该一切就很明了了。

首先需要明白在django模板系统中，有两种封装模板变量的类，一个是django.template.Context，这是最常用的，我们在使用render_to_response方法的时候传入的第二个dictionary参数，就会被这个Context类封装一次，然后传到模板当中；另一个是django.template.RequestContext，它和Context类相比有两个不同之处。第一个不同的是，在生成一个RequestContext变量的时候，需要传入一个HttpRequest对象作为它的第一个参数：

c = RequestContext(request, {'foo': 'bar', })

第二个区别是，它会增加一些自动注入模板的变量，这些变量从哪儿来呢？在django的settings.py里有一部分是配置TEMPLATE_CONTEXT_PROCESSORS的，这个配置中的那一个个的tuple元素其实是一个个可以被调用的方法，而这些方法都会接收一个HttpRequest对象作为参数，而最终return一个dictionary，这个dictionary里面的元素就会成为RequestContext中自动注入模板的变量。我们看看settings.py中TEMPLATE_CONTEXT_PROCESSORS的某一个元素 django.contrib.auth.context_processors.auth 对应的代码吧:

# in django/contrib/auth/context_processors.py
def auth(request):
    """ ignore doc string """
    def get_user():
        ....
 
    return {
        'user': SimpleLazyObject(get_user),
        'messages': messages.get_messages(request),
        'perms':  lazy(lambda: PermWrapper(get_user()), PermWrapper)(),
    }

可以看到，auth方法最后返回的一个字典中，包含了三个元素，所以如果在使用render_to_response方法时，传入了第三个RequestContext参数，那么在它所渲染的模板中，就可以获取到对应的user、messages、perms变量了。

所以最后文艺解决方法是，在每一个需要注入全局变量的views方法中，调用render_to_response的时候，都传入第三个RequestContext对象参数即可：

def views_meth1(request):
    d1 = {'method': 1}
 
    return render_to_response('template_1.html', d1, context_instance=RequestContext(request))
 
def views_meth2(request):
    d2 = {'method': 2}
 
    return render_to_response('template_2.html', d2, context_instance=RequestContext(request))
 
def views_meth3(request):
    d3 = {'method': 3}
 
    return render_to_response('template_2.html', d3, context_instance=RequestContext(request))

这样需要注入的全局对象，就可以通过扩展TEMPLATE_CONTEXT_PROCESSORS来实现，灵活性更高，更易扩展。当然，在一般的项目开发中，个人觉得普通方法也足够用，所以就根据项目来做取舍吧。

当下大大小小层出不穷的互联网产品如同一场令人眼花缭乱的星球大战，普通用户会被死星、联盟战舰和绝地武士们手中的光剑所吸引，而设计师们则会去关注这些庞大或精巧的武器如何被制造出来。

是的，随着以用户为中心的设计（UCD）和用户体验设计（UED）概念的深入人心，互联网产品设计的方法和流程已被重新定义而且大同小异，即便是刚入门的麻瓜也能一本正经地告诉你一个正确的产品设计流程需要经过低保真原型、视觉设计、交互设计、高保真设计……等阶段。

彩程设计用户体验设计流程

产品经理不是巫师，拿脑袋当水晶球拍拍，就能精确地规划出每个界面和界面上的控件，而是通过一定的方法和工具，把逻辑思维逐步收缩，并落实纸面。低保真原型通常并非一个设计真正的起点，就好像一个完整而令人激动的星球大战故事还会有它的前传。

TeamCola是我们针对小团队开发的一款团队日志产品，通过让团队内部工作透明从而方便管理、增进信任和提高效率。想通过这款产品，来谈谈我们设计前期所使用的一些工具和方法。

软件设计，以人为本。产品设计前，对产品本身的典型使用人群需要个大致定位，如果不太明确，建议提前进行一些调研、走访并制作一份角色分析表，共同讨论和分析是什么类型的用户，会出于什么动机，在什么场景下，使用到软件的什么功能。关于用户研究，有很多成熟的理论与方法，不在此赘述。

产品的雏形或者说全貌，通常会先出现产品经理的脑海中，如果这个产品经理就是个单干户，那么他马上就可以做设计写代码或者同时搞了，但更多的情况是产品经理是团队的一员，需要跟团队的成员沟通，告诉他们自己想做的是个什么东西。当然，某些既不是普通产品又不是文艺产品经理的产品经理不在讨论之列。

在彩程，产品经理需要通过一张图来向团队成员来阐述这个产品的内在逻辑，用什么方式或软件来绘制不重要。这张图可以是纸面的草图，也可以经过精心的绘制，这样的图，我们称之为信息结构图。

Teamcola信息结构早期讨论稿

一个普通用户眼中的TeamCola信息结构

一个产品经理眼中的TeamCola信息结构

在这个阶段，产品经理着重需要考虑的是系统的核心功能和信息流向。这样一张信息结构图，对于信息逻辑的梳理非常有帮助，也方便向团队其他成员展示和阐述。

接下来，产品经理会开始绘制页面路径图和角色任务图，页面路径图会大致规划产品大概会有哪些页面，相互间的链接关系如何。然后将典型角色的典型任务列出，看看完成这些任务需要经过多少个网页，路径是否过长，是否有走不通的断头路等情况。

页面路径图讨论稿

整理后的页面路径图

典型角色在Teamcola中可能会面临的典型任务

有了这些前期成果，就可以开始正式的低保真原型设计了，在做每个具体页面信息架构的时候，可以根据内容的多寡和重要性进行某些页面的合并或拆分。至于形式，可以是手绘，也可以用Axure之类的软件来完成。一般说来手稿在绘制的时候效率更高，成本更低，摊在桌上很文青，贴在墙上很大师；html的版本则更方便在电脑上展示和远程传输，在展现一些动态的交互细节与不同页面间的跳转关系上更为方便。

在前期设计的辅助下开始基于页面信息架构的低保真原型设计

有些页面上有相互调用的模块，我们会做成小的卡片来方便讨论时的排列组合

把低保真设计原型贴在墙上方便集体讨论和查阅

低保真原型后面的故事，相信大家都知道啦～就是视觉设计、交互设计、前端开发、后端开发之类的一通猛干，把这些纸上的想法变成现实。：）

Mm⋯⋯我知道我们团队今年夏天干了什么

最后，欢迎体验我们这番设计的最终成果——最好用的团队日志管理工具——TeamCola!  同时欢迎关注@TeamCola与@彩程设计 以获得我们的最新动态。：）

最近在做的一个项目中需要使用到HTML5中引入的WebSocket技术，本来以为应该很容易就能搞定，谁知道在真正上手开发了以后才发现有很多麻烦的地方，虽然彩程是一个以前端开发和设计见长的团队，而且作为一个二手程序猿又长期不被待见，但是为了让有同样需求的朋友少走些弯路，我还是决定把实现方法贴在这个地方。

关于WebSocket的基本概念，维基百科上解释的很清楚，而且网上也能搜出来一大把，这里就略过不表，直接进入正题。

这次的问题首先有一个前提，就是得用Python来实现这个服务器，如果对具体语言没有限制的话，推荐大家首选Node.js的一个第三方库：Socket.IO，非常好用，10分钟不打针不吃药搞定WebSocket Server，而且用JS来写后端，相信也能对上很多文艺开发者的胃口。

但是如果选择用Python，google搜索的结果几乎都不能用，最要命的问题是，WebSocket协议本身还是一个草案，所以不同浏览器支持的协议版本有所不同，Safari 5.1支持的是老版本协议Hybi-02，Chrome 15以及Firefox 8.0支持的是新版本协议Hybi-10，老版本协议和新版本协议在建立通信的握手方法还有数据传输的格式要求上都有所不同，导致网上大多数实现方式只能适用于Safari浏览器，并且Safari和C&F浏览器之间无法互相通信。

首先第一步需要解释的是新、旧版本WebSocket协议的握手方式。我们先来看看三个不同浏览器发送的握手数据的结构：

Chrome：

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 127.0.0.1:1337
Sec-WebSocket-Origin: http://127.0.0.1:8000
Sec-WebSocket-Key: erWJbDVAlYnHvHNulgrW8Q==
Sec-WebSocket-Version: 8
Cookie: csrftoken=xxxxxx; sessionid=xxxxx

Firefox：

GET / HTTP/1.1
Host: 127.0.0.1:1337
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive, Upgrade
Sec-WebSocket-Version: 8
Sec-WebSocket-Origin: http://127.0.0.1:8000
Sec-WebSocket-Key: 1t3F81iAxNIZE2TxqWv+8A==
Cookie: xxx
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Safari：

GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: 127.0.0.1:1337
Origin: http://127.0.0.1:8000
Cookie: sessionid=xxxx; calView=day; dayCurrentDate=1314288000000
Sec-WebSocket-Key1: cV`p1* 42#7  ^9}_ 647  08{
Sec-WebSocket-Key2: O8 415 8x37R A8   4
;"######

可以看出，Chrome和Firefox实现的是新版协议，因此只传输了一个”Sec-WebSocket-Key”头以供服务端生成握手Token，但是遵循老版本的Safari的数据中有两个Key：”Sec-WebSocket-Key1″和”Sec-WebSocket-Key2″，因此服务端在生成握手Token的时候，需要做一次判断。先来看使用老版本协议的Safari，Token生成算法如下：

取出Sec-WebSocket-Key1中的所有数字字符形成一个数值，这里是1427964708，然后除以Key1中的空格数目，这里好像是6个空格，得到一个数值，保留该数值整数位，得到数值N1；对Sec-WebSocket-Key2如法炮制，得到第二个整数N2；把N1和N2按照Big-Endian字符序列连接起来，然后再与另外一个Key3连接，得到一个原始序列ser_key。那么Key3是什么呢？大家可以看到在Safari发送过来的握手请求最后，有一个8字节的奇怪的字符串“;”######”，这个就是Key3。回到ser_key，对这个原始序列做md5算出一个16字节长的digest，这就是老版本协议需要的token，然后将这个token附在握手消息的最后发送回Client，即可完成握手。

新版协议生成Token的方法比较简单：首先把Sec-WebSocket-Key和一串固定的UUID “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”做拼接，然后对这个拼接后的字符串做SHA1加密，得到digest以后，做一次base64编码，即可获得Token。

另外需要注意的是，新版本和老版本握手协议回传给Client的数据结构有所不同，在附件中的server源码中写得很清楚了，看看就能明白。

完成握手只是WebSocket Server的一半功能，现在只能保证这个Server能够和两个版本的浏览器建立链接了，但是如果试着把Chrome中的消息发送给Safari，会发现Safari无法接收。导致这个结果的原因，是因为两个版本的协议的Data Framing结构不同，也即是在握手建立连接后，Client发送和接收的数据结构都不一样。

首先第一步需要获取不同版本协议下Client发送过来的原始数据。老版本协议比较简单，实际上就是在原始数据前加了个’\x00′，在最后面加上了一个’\xFF’，所以如果Safari的Client发送一个字符串’test’，实际上WebSocket Server收到的数据是：’x00test\xFF’，所以只需要剥离掉首尾那两个字符就可以了。

比较麻烦的是新版本协议的数据，按照新版draft的解释，Chrome和Firefox发过来的数据报文由以下几个部分组成：首先是一个固定的字节（1000 0001或是1000 0002），这个字节可以不用理会。麻烦的是第二个字节，这里假设第二个字节是1011 1100，首先这个字节的第一位肯定是1，表示这是一个”masked”位，剩下的7个0/1位能够计算出一个数值，比如这里剩下的是 011 1100，计算出来就是60，这个值需要做如下判断：

如果这个值介于0000 0000 和 0111 1101 (0 ~ 125) 之间，那么这个值就代表了实际数据的长度；如果这个数值刚好等于0111 1110 (126)，那么接下来的2个字节才代表真实数据长度；如果这个数值刚好等于0111 1111 (127)，那么接下来的8个字节代表数据长度。

有了这个判断之后，能够知道代表数据长度的字节在第几位结束，比如我们举得例子60，这个值介于0~125之间，所以第二个字节本身就代表了原始数据的长度了（60个字节），所以从第三个字节开始，我们能抓出4个字节来，这一串字节叫做 “masks” (掩码?)，掩码之后的数据，就是实际的data…的兄弟了。说是兄弟，是因为这个数据是实际data根据掩码做过一次位运算后得到的，获得原始data的方法是，将兄弟数据的每一位x，和掩码的第i%4位做xor运算，其中i是x在兄弟数据中的索引。看得眼花是吧，看看下面这个代码片段也许就能明白了：

def parse_data(msg):
    code_length = ord(msg[1]) & 127
 
    if code_length == 126:
        masks = msg[4:8]
        data = msg[8:]
    elif code_length == 127:
        masks = msg[10:14]
        data = msg[14:]
    else:
        masks = msg[2:6]
        data = msg[6:]
 
    i = 0
    raw_str = ''
 
    for d in data:
        raw_str += chr(ord(d) ^ ord(masks[i%4]))
        i += 1

至此，已经可以顺利取出两个版本浏览器发送来的原始数据了。接下来，就是将这个原始数据封装成不同协议版本的需要的Client数据，发送给对应浏览器就可以了。支持老版本协议的Safari还是很简单，如果从Chrome或者Firefox发送来的原始数据是字符串’test’的话，按照之前解码的方式，前面加上一个’\x00′，最末加上一个’\xFF’，变成’\x00test\xFF’就可以发送给Safari接收了。如果是从Safari发送来的原始数据’test’，同样需要做解码的逆运算，唯一简单的，是不需要再用一个masks来生成一个兄弟数据了，从Server端发送原始的数据给Client就可以了。

还是来模拟这个过程，首先数据的第一位仍旧是1000 0001(‘\x81′)，接下来获取原始数据的长度data_length，根据长度是否超过125位，来生成1个字节或是3个字节的代表长度的位数（附件中的源码省略去了使用9个字节表示数据长度的情况，因为实际的Server不会传输那么大量的数据），最后再将该字节串和原始数据拼接起来，就可以了，代码片段如下：

def send_data(raw_str):
    back_str = []
 
    back_str.append('\x81')
    data_length = len(raw_str)
 
    if data_length < 125:
        back_str.append(chr(data_length))
    else:
        back_str.append(chr(126))
        back_str.append(chr(data_length >> 8))
        back_str.append(chr(data_length & 0xFF))
 
    back_str = "".join(back_str) + raw_str

这样生成的back_str，就能够发送给使用新版协议的Chrome或是Firefox了。

至此，这个简单的WebSocket Server就完成了，能够同时兼容老版协议和新版协议的Socket连接，以及不同版本之间的数据传输。该Server的源码请点击这里下载，需要注意的是里面用到了twisted框架来跑TCP服务，代码写得不怎么样，仅供大家参考。

参考文档：

1、The WebSocket protocol draft-ietf-hybi-thewebsocketprotocol-17
2、How to (de)construct data frames in WebSockets hybi 08+?
3、基于Websocket草案10协议的升级及基于Netty的握手实现
4、ABC of WebSocket

Before iWish

“倾听用户的声音！” 几乎成为所有服务行业的口头禅。你几乎可以从任何一本《XXX无师自通》的书中看到这句话， 或者你已经麻痹到直接忽略这句话的存在。

的确，这是一句如此的废话，任何人都会说这句话，但是他们却没有告诉你：“HOW?”

TeamCola 的成长需要感谢很多热心的网友。虽然最开始麻烦了一点，我们通过电子邮件接收用户反馈。我们为了方便我们的热心网友，于是我们增加了意见反馈的功能：

点击意见反馈后，亲们可以直接在页面中填写反馈。

的确，我们倾听用户的声音。但是我们又思考，用户会不会在想，“我辛辛苦苦给你们提了意见，然后呢？你们就屁也不放一个？ 或者，你们给我肯诚地回了我邮件，说得好好的，但是你们到底在搞锤子，是不是在敷衍我哟！”

我相信和我们的产品一样，这个世界上还有很多信息黑洞，用户提的意见石沉大海。就像飞机上了天，如果接机的亲友就不知道飞机死活，也不知道是什么时候降落，那过程会变得很煎熬。同样地，如果TeamCola是一个神秘的产品，他们这伙人在做什么？接下来会用到什么新功能？哪些BUG会被修改掉了？ 诸如此类的信息，我们能不能开放给我们的亲们？我们是否能让亲们知道呢？能让亲们参与决定接下来要开发的功能？能让亲们看到开发进度？ 于是，我们有了iWish.

After iWish

iWish的使用分为4个步骤：

1. 我们建立一个列表

2. 亲们上来可以看到别人的许愿，当然也可以许愿

3. 亲们可以给许愿投票

4. 亲们看到我们正在开发的功能

以TeamCola为例：

TeamCola的iWish地址为 http://iwish.mycolorway.com/tc/

就像飞机的状态板一样，用户可以看到哪些需求要“起飞”了，哪些要“降落”了，当然也可以提出“向哪里飞”的期望。

如果你也想创建一个自己产品的iWish，请点击 这里。

我们团队按照项目来组织分类，在TeamCola上，总共有28个工作分类。但其中接近一半的分类，最近一个月都没有人写日志，它们就像肚子上的肥肉一样让人不爽。

我们已经尝试了一些方法，来减少分类肥胖带来的影响。比如，在录入日志时，TeamCola会自动把你最近使用过的分类排到前面，方便选择；在团队日志页面，TeamCola会把你们团队常用的分类排在前面，其他的隐藏到‘不常用的分类’按钮下。但这些方法都是把肥肉藏起来，你显或不显，都在那里。

我们也尝试用分类合并功能，来减肥，但疗效不显著。它只能解决那些重复的，或者考虑不周的分类，并不能处理以前常用，但现在已经不用的休眠分类。

现在，我们想让事情变得更简单一点，用归档功能来给分类减肥。

归档功能在哪里？

在右上角–》团队设置–》分类管理，如下图。

归档和合并有什么区别

简单的说，归档用于给分类减肥，合并用于优化分类。
归档并不改变日志和分类的对应关系，它是把不用的分类从分类选择列表中去掉，同时锁定跟该分类相关的所有日志，不能再修改和删除。

合并分类会把两个分类下的日志，都关联到合并后的分类。合并后的分类依然会出现在分类选择列表中，相关联的日志也可以照常修改和删除。

归档之后的分类能够恢复么？

可以。如果需要记录工作日志到已归档的分类，你只需要通过分类名称旁边的“恢复”按钮就能搞定，如下图。

归档之后的优化

如果你的工作分类比较多（超过20个），那分类的颜色标志会有重复的情况。在通过归档减肥之后，你可能还需要优化现有分类的配色方案。TeamCola的配色板提供20个颜色，你可以自行设计。

分类归档的功能今天已经上线，欢迎大家使用后给我们反馈。

最后，祝愿天下所有的人减肥成功。

上回说道，TeamCola的第一个可用版本在开发完成后在2月2日这个非常2的日子里正式在团队里内部使用了，在新鲜感和使用热情渐渐退去后，越来越多产品和视觉上的问题开始显现出来，1个多月后，团队讨论决定对TeamCola做一次大的调整。

即使是早期的版本TeamCola也没打算支持IE6

在视觉上，经过讨论后总结了一些这个版本的不足，首当其冲的是TeamCola的标志。不少人对标志的第一印象是看不出TeamCola的字样，甚至不能辨识代表CO两个字母的橙色小拉环。当一个标志的识别性遇到了问题，无论它的设计构思有多巧妙都不能算是合格的标志。

视觉风上第二次迭代以灰和饱和度较低的深蓝色为主色调，而标题栏则以明亮的橙色作为字体颜色，灰蒙蒙的页面使得一些视觉上的杂音更加明显，在页面结构和排版上也存在着颇多不妥。经过几次讨论我决定推翻当前的视觉重新设计，而TeamCola在一轮又一轮测试反馈当中也酝酿着功能上新的变化。

第一张完成的视觉，项目仍然有任务和里程碑，标签式的项目总览显示的信息也比以前详实许多

4月18日TeamCola迎来了一版崭新的视觉设计，没有了LOGO，没有了条条框框，没有了橙得发红的标题，原本很重的Header也变成了一道淡淡的渐变。页面宽度也从960px缩短到了800px（日历页面为了显示更多信息仍然为960px），整体布局紧凑而又留有呼吸空间，阅读信息也变得轻松了许多。

项目的列表页，新的项目首页以项目列表的形式展示，能够很清楚地看到项目间活跃程度的不同

LOGO还没设计时的登陆页面

与此同时，TeamCola也总结了第一个可用版本内部使用时出现的问题，任务使用率太低使TeamCola最后去掉了任务功能，转而以工时(工作时间)作为TeamCola的核心，团队和团队成员以及项目都围绕着工时运作。老妖提出的“团队工作史”也成为了宣传TeamCola核心价值的口号被确定了下来。

取消任务功能后，TeamCola对工作记录功能进行了深耕细作，出现了直观的柱状图工时记录（最近更是增加了工时统计等方便的图形化数据），视觉上我移除了所有可能会对数据展示和信息陈列带来困扰的视觉元素，通过设定字体（如团队和项目页工时统计的数字，我设定22px的加粗Helvetica）和优化图形化数据（如在柱形工时图中为加班日着上蓝色，以及刚刚推出不久的项目着色功能）让工作记录的可读性更高。一切都是为了功能服务，没有多余的侧边栏，没有冗长的footer，甚至没有LOGO。

但是TeamCola仍然需要一个LOGO。在新版视觉送走了小拉环后不久，新的LOGO也呼之欲出。

在构思LOGO时画的一系列草图

可乐、时间、团队、激情。。。几天的草稿和脑暴之后，现在看到的TeamColaLOGO被创造出来了：

以色块构成的新TeamcolaLOGO同时也是一块适用于TeamCola的色谱

以包围白底可乐的色块填满的LOGO冷暖交汇，设计这个LOGO的初衷是一杯加了冰块还往外冒气的可乐，在夏日的灿烂的阳光下，面对蓝天与海洋的场景。TeamCola就是这样一款工具，它让团队内的沟通如喝口可乐一样舒畅无比，让团队的工作通透得如仲夏海边的浅滩，让团队成员工作的心情如看见蓝天般轻松自在。

标志诞生的同时，我还定义了配合LOGO使用的字体，以Calibri为原型设计的字体更加平滑，不失变化的t和c字母很好地被使用在LOGO之中，整套字体小范围使用的情况下也不失严谨正式。

TeamCola就是激活团队的那杯可乐

第一版设计出来后我很快完善了其他页面的设计，去掉了任务以及日历的调整之后，视觉上也快速地随之进行迭代。通知邮件样式、新手引导、无数据界面设计完成的同时，视觉规范、logo使用规范也渐渐完善，距离TeamCola的正式发布已经越来越近了。

TeamCola的各种通知也进行了细分归类方便进行设计

TeamCola的邮件通知样式，没有使用任何图片，一目了然

使用iphone可以将TeamCola链接添加到主屏幕以快速进入

在移动平台上，TeamCola也努力使用户可以无障碍地记录工时，查看项目和评论，甚至随时随地兑换可乐。虽然暂时没有推出各平台的原生客户端的计划，我们还是把重点放在了html5版的移动版TeamCola的设计和开发上，不久的将来大家就能用到不是app胜似app、操作体验流畅无比的手机版TeamCola了！

在ipad上使用TeamCola？大丈夫だ、問題ない！！

新的移动版TeamCola即将到来

正式发布前TeamCola的产品页面，此时只有Maklu的原型图能吊足大家胃口

5月23日，TeamCola正式对外发布，随着功能的继续完善优化，使用TeamCola将会更加顺畅。 让每一个团队都能发挥100%的能量，成为了我们废寝忘食努力下去的动力。在接下来的日子里，TeamCola仍然会是各个团队手中那杯喝不完的冰镇可乐。

6月29日，当我一如既往地打开Chrome进入Gmail时，顶部导航栏的变化像是在向我表达着什么。5分钟之后，当我点击了小滨滨的邀请链接，我惊奇地发现————连接被重置了！！

于是我只好全局ssh再次打开了邀请链接，Google+这才渐渐显山露水迎面走来，依然是熟悉的三栏布局，比例和功能分布也和facebook类似，抛开可以把亲朋好友圈养起来的恶搞特性(误)不讲，Google+最吸引我的是出色的视觉设计，简洁清丽的风格令人爱不释手。随着Google+的发布，诸如Google Calendar、Google Map等应用也随之换上了”小清新”风格。

Google+的设计让我想起了TeamCola。5月正式上线的TeamCola在把团队工作日志的特性做到极致的同时，极简化的视觉设计也得到了不少肯定评价。在半年的开发设计过程中，随着团队对TeamCola做小做精的定位愈加准确，视觉上也做了3次大的迭代。这3次迭代过程中，即使是一条边线的去留也要经过反复的推敲甚至开会讨论，这也使TeamCola能够越来越符合极简化设计的要求。

第一次迭代，不断精简视觉元素过程中的设计摸索

PowerMatrix截图

PowerMatrix(简称PM)是彩程在09年开发的在团队内使用的工作记录软件，也是TeamCola的前身。去年末由于所有人都已经无法忍受PM之苦逼难用，我们决定重新开发一款供团队内部使用的工作记录应用，由我来担任视觉设计，第一版视觉设计在12月初放出。

新PowerMatrix(当时还不叫TeamCola)有任务、项目、工作记录(日历)和积分功能，取代老PM首页的是一个，显示团队近期的动态(任务、里程碑和项目的新建、完成等)，侧边栏显示自己的任务和项目。第一版的视觉稿很快就做出来了，整体风格贴近其名字”PowerMatrix”蕴含科技色彩的冷峻专业。为了使页面更加紧凑，减少视觉焦点，通常放置在左上角的logo被移动到了footer位置。

这版视觉沿袭了当时我的设计风格，以渐变和阴影表现页面元素间层次，使用偏向中性色调。由于毛病太多(中间空白区域辽阔得可以放羊、层次太乱、LOGO的放置问题等)很快就被否决，在团队几次讨论后第二、第三版的设计也紧接着推出来了。

随着logo由科技感的文字变成一个更加geek的矩阵，PowerMatrix的渐变也逐步被弃用而转为更为纯粹的单色，所有阴影也随之取消。更大的变化是在排版和文案上的优化：导航的任务显示任务数气泡、dashboard的列表文字主次区分、侧边栏视觉上的弱化以及主区域加高突出等等，这次优化的设计很多保留到了第三次迭代之前，而视觉上的去繁入简更成为了后面迭代的核心诉求。

第二次迭代，极简设计之旅正式起航

经过几次头脑风暴，Teamcola击败了阿迪王项目王等一堆无厘头词汇，把PowerMatrix这个名字彻底扫进了历史的垃圾桶！2月2日，在一个这么2的日子里，TeamCola的第一条工作记录诞生了。

回到去年12月，在确定TeamCola这个名字之后，LOGO的设计被提上了议程，TeamCola需要它的第一个标志。在彩程团队之中，可乐和咖啡是很多成员日常工作不可或缺的饮料，而可乐本身又能衍生出年轻、轻快和活力等含义。第一版的TeamCola标志是文字和图形结合，使用Cooper std字体并以一个拉环的形象表示co两个字母。设计的初衷是力求LOGO简洁轻松，以鲜明的配色辅以小拉环的图形暗示来展示TeamCola这款轻量应用的魅力。没有渐变、明晰的外形能够很好地使用在页面上。页面的视觉风格在LOGO确定后选择了浅灰以及低饱和度的深蓝色作为主色调，辅以橙色和蓝色，在带警示性的文字和提示上使用桔红色突出显示，次要的信息元素以灰色来展示。

任务首页

随着LOGO的确定和视觉规范的建立，其他页面的视觉设计也随之展开。任务、项目、日历和积分页面很快完成了。和第一次迭代结束的设计相比，整体色调由深灰、橙色的偏暖调整到了灰蓝的偏冷，去掉了侧边栏不同类目的分隔线，排版上也有小的调整。2月初在团队内上线使用后，在产品功能定位和视觉设计上的问题越来越多使得TeamCola的设计进入了第三次迭代。

日历页面，此时的日历长宽是固定的，在高分辨率(如1920×1200)下会造成严重的空间浪费，而现在的TeamCola则会根据分辨率自动调整高度

除了一小撮希望推出ipad兑换而拼命攒分的同学外，大家都喜欢在饭后兑换一瓶冰镇饮料犒劳自己

从开始仍然带有应用程序的痕迹到整个页面除了LOGO外几乎没有图片的设计，TeamCola带给我的不仅仅是经验积累，还有大量的问题教训，使我不会像卡扎菲一样在错误的道路上越走越远。在看Basecamp、Github等一些优秀的网站，发出”原来还可以这样设计”的惊叹之余，更多的是需要回头审视自己的设计，到底有多少元素是需要留下来并能发挥作用的，有多少元素可以精简甚至去掉，如何在雕琢细节的时候不丢失整体。TeamCola作为团队工作日志工具，视觉设计的重点需要放在大量信息的梳理与展示当中，让使用者在使用过程中感觉不到设计的存在才是极简化设计的精髓。