• Feeds

  • Archive for November, 2013


    寡头时代的技术大会


    尽管大部分技术大会的演讲材料会后公开了,但是大家还是看重现场去参加并聆听。参加一场技术大会,简单的理解是扩大自己的认知圈,感受一下不同的思维方式,深层次是希望通过讲演的感染力,获得思考、借鉴或者力量。如 @霍泰稳 在QCon上海大会keynote致辞中提到,“你正在改变世界,我们在影响你”,在一场大会中,大家通过演讲的材料或者讨论来相互影响。

    在另外一方面,技术大会的参会人员大多是一种仰望学习的心态,这种情况下,演讲也会具有一些局限性。

    • 知识的局部性,讲师为了内容的感染力及趣味性及易理解性,倾向于挑选领域中一些特色点来介绍,也会通过重复一些“正确的废话”获得大部分群体的共鸣。演讲不等同于老师上一堂课。
    • 时间的局限性,大部分演讲时间在半小时~1小时,较难将问题深入展开并让听众领悟;另外考虑到听众多元化的背景,也尽量选择最通俗的内容来讲解
    • 环境的局限性,具有丰富知识性的材料较难通过slide充分展示,同时,对于slides内容,观众由于需要跟随讲师演讲思路,未能有充分时间去理解、思考材料内容,也常常还未看清材料讲师已经翻到了下一页

    基于这些看法,并考虑到对听众实际生产力改进的影响,我最近更看好小班培训对于知识学习的效果。

    从讲师的角度,一场好的演讲,准备永远都是不充分的,演讲确实是一个厚积薄发的过程,尤其在内容的深度方面。除了表述的问题之外,有可能还是讲师自身认识的体系性与深度的问题。有些讲师虽然自己做过一些不错的系统,但也有可能未去深入去抽象其中的普遍性的规律,单纯复述一个强大系统的feature并不能让听众满足。讲师通过一次演讲的机会,可以整理自己的思想及体系,获得外界在领域内的反馈,更虚一点,一次好口碑的演讲,可以赢得社区的尊重及声望、建立技术品牌。

    技术大会也变得越来越国际化,由于互联网传播的速度,国内公司与国外在认知层面差距不是很明显,表现为老外的技术架构栈,国内公司搭建起来的似乎非常相似。但是从内在来看,开发文化的差异短期之内不太能改变,以及在开发工具、开发框架精细化方面尚有距离。

    不管在技术架构还是大数据处理分析上,大型公司都具备在架构实践及大数据挖掘方面的人才及环境的领先优势,至少从最近的一系列技术大会来看,这是一个寡头的时代。

    Cassandra代替Redis?

    最近用Cassandra的又逐渐多了,除了之前的360案例,在月初的QCon Shanghai 2013 篱笆网也介绍了其使用案例。而这篇百万用户时尚分享网站feed系统扩展实践文章则提到了Fashiolista和Instagram从Redis迁移到Cassandra的案例。考虑到到目前仍然有不少网友在讨论Redis的用法问题,Redis是一个数据库、内存、还是Key value store?以及Redis和memcache在实际场景的抉择问题,因此简单谈下相关区别。

    首先,Redis和Cassandra完全是适合不同的使用场景的NoSQL产品。前者是适用小规模内存型的key value或者key list数据,后者适合存储大规模数据。因此这篇文章提到切换主要原因或许还是前期Redis使用场景不合适,在初创公司项目初期,以顺手的工具快速实现功能的做法也可以理解。

    Redis的几种使用场景

    • 访问量大
    • key value或者key list数据结构
    • 容量小,可控,可以全部放入内存。由于Redis是单线程设计,因此大value会导致后续的请求一定的堵塞。另外hashset当hgetall时候由于存在遍历操作,也不适合集合太大。如果数据超过单机容量可以使用常规的sharding方法分布到多台机
    • 需持久化的场景

    上面四点一般情况下应是必要条件。因此常见网站的用户资料、好友列表就适用用Redis来保存。由于Redis具有memcached所有的特性,也有讨论说memcache是否可以退出了?在以下情况下,我会倾向于选择memcached而非redis

    • 简单无需持久化的key value,比如100字节以下。这种情况下使用memcached空间更节约且维护更简便。
    • 有滚动过期需求,如网站的session,每个新登录的用户定期过期。

    相关观点也可参考Memcached真的过时了吗

    几个问题

    1. 既然Redis可以持久化,用Redis保存的好友列表是否还需要保存到关系数据库?
    2. 手机游戏Clash of Clans中的城堡属性、及用户的金币、圣水、奖杯适用用什么数据结构保存?

    当我谈招聘时我谈什么

    校园招聘的季节也基本结束,校园招聘通常由多轮面试组成,在面试学生时候,社会招聘面试过程中以经验或阅历来推导能力的方法并不适用,一方面不少优秀的学生实践经验并不突出。另外一方面从实践经验及成果方面来衡量一个学生的能力也较片面。由于缺少经历方面的成果,而导致面试官对同一个候选人判断的尺度差异较大。因此最近团队内也进行了一些讨论。

    讨论时候参考了Matt Might教授的The illustrated guide to a Ph.D.(可参看阮一峰的中文译本),并绘制出了一个简单的能力模型。

    图中Level 1标识候选人具备专业领域(对应图中本科生的凸点)知识的应用能力,比如实现一个考虑了各种实现细节的MVC的程序,一个可以运行在实际网络环境的多人socket聊天室等。

    我们期望候选人能够匹配到图中的Level 2,类似图中master’s degree, 在面试过程中能够从与候选人的交谈中看到一个较深的specialty。如何判断较深?我们认为在该项能力上,即使放到我们已有的团队范围内,该能力也达到一个峰值。看起来似乎有些难,但是人各有长,你的专长未必是别人的专长,因此超越一个团队也不是非常困难。

    Level 3我们也公认比较难达到,属于特殊类人才。

    除了专业能力之外,我们也比较看重软性素质,分成理解力、学习力、内驱力及抽象能力,四个能力之间没有严格的次序关系。由于我们技术岗位的特殊性,这几项软性能力不具备普遍性及较强的借鉴性。比如沟通及表达能力在某些岗位比较重要,但是在大部分技术岗位,相应的要求可以相对弱化。

    12