作者文章: Fenng

黑客与画家

四月份读的最好的一本书是 Paul Graham 的大作 《黑客与画家》(中文版),这是一本能引发技术人思考的佳作,真正意义上的黑客精神、创业(Start-up)、编程语言,是这本技术散文集的三个主题。阮一峰的翻译很到位,很喜欢他的译文。国内做技术图书的翻译属于”高投入低回报”的工作,能埋头做事情的人越来越少了。

《黑客与画家》从解释为什么书呆子(Nerd)不受欢迎到阐述黑客精神的意义,实际上是给程序员进行了正名。保持黑客精神,就有可能改变这个世界。那些不服从管教的人们,是这个社会力量与财富的源泉,是的,现在很少有人关心这些了,大家更关心房子和油价,粮食和蔬菜。

paulgraham_2147_13521252.jpg

从利己角度来说,强烈建议每一个从学校即将毕业的人,或是所有的技术人都先读一下这本书的第六章,”如何创造财富“(How to Make Wealth),技术人有必要建立起对财富的价值观。说到”财富”,似乎是很让人不齿的事情,但是又是看到周围有很多技术人热衷谈论股票、炒房,谁让我们生活在这个糟糕的时代呢?少有人同时谈谈财富和技术的关系,还好有这本书。金钱只是财富的一种表达方式,但财富不等于金钱,不止是房子与车子。Paul Graham 的观点是:致富的最好办法是创造财富(而不是掠夺),自己创业或是加入创业团队是致富的可靠方法(就我来看,如果你是官二代或是富二代,那么另当别论)。Paul 与那些常见的忽悠大师不同的地方在于,他同时也会给出稍显冰冷的事实:创业的付出与回报总体上是成比例的,但是在个体上是不成比例的,不要把创业过于神话,但创业的确给了我们更多的可能。

给我带来不小启发的还有关于 “不能说的话” 的论述。身处当前这种复杂的社会环境中,如果你发现了这个社会的某种禁忌–你肯定会发现的,发现了不能说的话,怎么办?最恰当的办法是挑选合适的场合再说,而不是到处去说,我们要学会”只打值得打的仗”。想想我们平时在网上耗费大量精力而做的口水战,难道不是么无谓之争么?别去赞同这个社会任何一种歇斯底里,但是又不告诉他们你具体不赞同哪种狂热。如果不得不面对这样的挑衅,要么将争论提升到一个抽象的层次-实际上这比较难;要么,使用隐喻-这也不容易,作者还提示了一个办法,那就是幽默(他妈的, 这家伙太有意思了)。如果自己是潮水的一部分,你无法看清潮水的方向,唯一的办法是永远保持质疑,提升自己的思辨能力。

事实上,这本书在国内出版后还可能有两个后果:

  • 会有更多人产生创业的想法(记住,是创造财富而非掠夺财富)
  • 会产生更多的 LISP 程序员(中国有多少个 LISP 程序员?两位数还是三位数?)

后果自负 :)

EOF

Web 表单设计以及其它

填写表格是很多人都厌烦的事情,即使填写网络上的表格(表单)也是如此,而设计表单则可能是网络工程师/设计师最烦最无法拿捏的事情。绝大多数用户和一个网站交互的第一步就是面对表单(比如登录或是注册),很可能也是最重要的一步交互。遗憾的是,现在很多中小网站对于表单的设计仍然比较糟糕,或者是不够重视,甚至那些大型网站的表单设计也并没好到什么地方去。

Web_Forms_Design.jpg

中小网站的工程师(可能同时也是设计人员)在日常工作中无法回避表单,与其反复翻看别人的设计,东拼西凑成自己的表单,还不如彻底研究一下表单,所谓磨刀不误砍柴工,要提高提高效率,这是个不错的途径。关于表单的中文图书并不多,目前专门讲表单的只有两本。抽时间看完了《Web 表单设计:创建高可用性的网页表单》这本书之后,才发现表单设计在冰山下还有很多东西(抽时间要把另一本也看一下)。尤其优良设计的表单对于数据分析人员来说也是紧密相关的,毕竟面对要清洗的脏数据是很让人苦恼的事情。

有多少技术人每个月能保证看一本技术类的书籍呢?那些身处大型团队的朋友常说没有资源,我知道没资源的原因要么是拉不到资源,要么是资源在浪费中;中小型团队团队资源也紧缺 — 因为人少,也有资源上的浪费 — 因为重复做低效的事情。身在中小型团队,指望外力扭转现状是不太现实的,所以自身学习与提升不能放弃。

上一周在 QCon (北京)会场和朋友聊天的时候我开玩笑说,”QCon 的确有技术含量,但很多高端的东西现在还用不上,应该组织一场只面向中小网站的技术会议,规模稍微大点公司的人不许来。” 这句话其实也是有感而发,很多中小网站面对的问题其实很多都有共性,完全可以共享一些常用技术,共同进步。如果真的组织这样的会议,希望有朋友来分享一下表单设计。哪位愿意?

EOF

一个多月没写东西了,扯个闲篇再说。

此文作者:, 位于 Review 分类 标签: , , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Quora 用了哪些技术 ?

很多团队都在学习、研究 Quora 。前段时间看到这篇 Quora’s Technology Examined ,阐述了 Quora 的技术架构,有一些值得关注的信息,记录并分享一下。

使用云计算服务

Quora 大量使用 Amazon EC2 与 S3 服务;操作系统部署的是 Ubuntu Linux,易于部署和管理;静态内容用 Cloudfront.服务分发,图片先传到 EC2 服务器,使用 Pyhon S3 API 处理后后传到 S3。

从开始就使用云计算服务的的好处是节省了大量人工维护硬件服务器的成本,当然这个做法在咱这片土地上不太可行。

Quora_China_chat.png.scaled500.png
(refer: Copyright )
Web 层与 CMS

HAProxy 作为前端负载均衡服务器,反向代理服务器是 Nginx,Nginx 后面则是 Pylons (Pylons + Paste) , 承担动态 Web 请求。

Webnode2 与 LiveNode 这两个内部系统承担创建、管理内容的重任,Webnode2 生成 HTMLCSS 与 JavaScript ,并且与 LiveNode 轻度耦合。LiveNode 的作用用以显示 Web 页面内容。用 Python、C++ 与 JavaScript 写的。特别提到用到了 jQuery 与 Cython。LiveNode 有可能开源。

为什么用 Python?

前面已经提到了一些 Python 相关的技术组件。有意思的是从 Facebook 出来的团队居然用 Python 作为主要开发语言。Quora 对此有所解释: Facebook 选择 PHP 也并非是最佳选择,而是有历史原因。Quora 技术团队在考察了多个语言之后选择的 Python ,当然理由有一大堆,总体看来,并非很激进。

通信处理

后端通信使用的是 Facebook 开源出来的 Thrift,除了开发接口简单之外,可能更为熟悉也是一个因素吧 :) Comet 服务器使用的是 Tornado,用以处理 Long polling 以及 Push 更新(不知道知乎用的什么?),Tornado 是前 FriendFeed 技术团队开源的产品。

实时搜索

因为 Sphinx 不能满足实时性方面的要求,Quora 启用了自己开发的搜索引擎,只使用了 Thrift 与 Python Unicode 库,此外没有用别的。Quora 的搜索比较特别,因为要对输入内容做关联并且要做有效提示,所以需要提供更好的前缀索引(Prefix indexing)功能。

Quora 搜索的实现还是挺有技术含量的,对后端的查询请求压力也不小(或许当前的并发请求量还没那么大)。对这个场景,做相关开发的朋友不妨仔细研究一下。如果大体框架类似,那么决定最后生出的因素很可能是那些细节。

数据持久层

大量使用 MySQL 作为存储方案,Memcached 作 Cache 层。没有使用当前比较火爆的 NoSQL 相关产品。Quora 这样做有自己的理由,用户量级没有达到百万的 SNS 站点完全没必要用 NoSQL 的东西。或许以后 Quora 也会启用。

创始人查理·奇弗(Charlie Cheever)与亚当·德安杰洛(Adam D’Angelo)之前都在 Facebook ,所以,Quora 的技术还真有不少 Facebook 的基因。Quora 的团队规模并不大,做技术的估计十余人而已,这么紧凑的团队利用了这么多的技术与产品,可见很多人都是多面手了。这是国内技术团队需要向国外同行学习的地方。

EOF

这只是一篇概要性的描述,如果要知道一些更为细节的东西,请看 Quora 上的相关评论,上文中已经给出相关链接。

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

技术团队内部工具的选型与评估

不管技术团队规模如何,总要在内部用一些工具来支撑日常工作。这些工具的选择会影响整个团队的效率,不可不慎重。如何做这类产品的评估与选型?每个人都会有自己的方式,这里说说我在丁香园技术团队遇到类似场景的时候,一般会参考的几个维度和评估方法。

活跃分析

目前来看,Google Trends 是个不错的分析产品活跃度的工具,只是有些关键词选择需要注意一下,不要迷惑于表面的数据。

产品特性

一般来说,WikiPedia 的对同类产品的功能比较是非常详尽的。如果是一个相对陌生的产品,无论如何要看一下。真的佩服这些编辑者的水磨功夫,相比之下,国内的有些类似网站,没办法看。

主观评价

通过 Twitter 进行提问,可以收集到很多技术同行的反馈与评价。另外,如果没有候选产品,通过 Twitter 也可以征集产品列表,前提是平时要有不错的互动。

通过搜索引擎可能会找到一些评测文章,一定要注意各自的场景和团队规模以及技术风格,一般来说,此类文章参考价值不是很大。

国外技术人员接受程度

参考一些问答网站,比如 Stack Overflow 的讨论,一些产品的优缺点,几乎都会涉及到。

国内技术人员接受程度

通过新浪微博进行关键词搜索可以基本获知国内技术人员对某技术或者产品的使用与接受程度。比如,搜索一下 “Trac” 这个话题看看。

多方面沟通

尊重内部同事意见与建议,咨询一下更大规模的团队负责人的经验。有句话说得好,”听多数人的意见,和少数人商量,自己做决定”,对于这个场景,也是适合的。

我吸取的一个教训是要让相关的同事有”知情权”,避免黑箱操作。

选择与风险

团队负责人做最后的抉择,并且承担后续风险。如果经过一段时间,证实判断有问题,别硬着头皮往死胡同走,承认错误,尽快调整。

工具用不好或是不好用,团队效率可能会骤降许多,不得不重视。类似的惨痛教训还是不少的。

没错,我说的没有什么新奇的内容,都是常识。有时间我再改改。

EOF

此文作者:, 位于 Startup 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.