作者文章: Fenng

QCon(北京) 技术大会预热

再有几天 QCon (Beijing) 技术大会 就开始了。QCon 是这几年出现的最有价值的技术会议,”绝对有技术含量”,相信北京这次也会让每个人不虚此行。这还是第一次在国内举办,很多国外的大师都来了,有机会能参加也是一件好事。QCon_Beijing.jpg

受邀主持网站架构案例分析这一场,所以有机会提前看到各位技术演讲人提交的 PPT。前天晚上看到豆瓣首席架构师洪强宁的 《豆瓣技术架构的发展历程》,击节称赞! 这个 PPT 会成为一份相当经典的架构参考文档。

据说现在已经一票难求了,如果要购票的话,可以用我的折扣代码。买票的时候报我的 BLOG 或者我的名字就可以省点钱。

EOF

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

技术人员的生产力

按:这其实是某一本书的推荐序(我这段时间没写 Blog 净帮着人忽悠了)。不过遇到了不靠谱的出版社不靠谱的编辑,据说整篇文章最后”只采用一两句行不行”? 当然不行。以后如果有出版社找我免费写推荐序或者书评,请自己考虑好再来浪费我的时间,多谢配合。


有的时候朋友们聚在一起聊天,会谈到国内国外技术人员的差异。我常喜欢说一句话”国内的 IT 公司基本上是劳动力密集型高科技企业“。比如就国外 Web 2.0 站点来说,CraigslistWikipedia 等流量比较大的网站不过数十人的小团队而已,如果放在国内,这样规模的网站起码要几百人乃至更多人员才能足够支撑。国外程序员一个人做的事情,国内可能要一个团队来做,当然可能还做不好。这里面或许有企业管理效率低下的因素存在(宁愿相信是这样的原因),不过大家都不愿意说的另一个因素是我们技术人员生产力效率低下。这种差异来自不是智力、体力上的差异,而是因为做事情的方式和方法,存在大量的重复劳动和人工劳动,对技术不能充分有效运用。如果不能对工作方式方法进行改进,我们永远都是技术流水线上的编码工人。

我们常说,重复的行为才能形成习惯,只有良好的习惯能导向成功。或许有人某些书籍或者聆听了某些”教诲”会逆反性的产生不以为然的想法,”这个我早就知道……” — 我自己常常就是这样自以为是。问题是,只是”知道”而没有行动起来加以”运用”,这样即使知道再多的技巧也不会形成良好的习惯,自然无法产生实质的改进,这可能也是技术人员惰性的一方面吧。其实我们需要的是能有更多的技术人员真正的行动起来,利用这些经验/教训/技巧…提升自己,也去积极影响他人,形成更良性的互动,不要让”持续改进”成为一句空话。另外,必须要补充的是,如果技术人员持续从事低效率的工作,极有可能逐渐厌烦技术,疏远技术,乃至对技术绝望,而一个高效的技术人才能从技术中获得真正的快乐。

也想告诉那些所谓的管理人员,不提升每位技术人员的生产力而希翼增加人手来解决技术困境的想法是不切实际的。那样做除了给企业增加负担,使组织更加混乱低效,很难起到什么实质作用。好的管理者必须能够引导下属持续提升生产力,不能一味用死板的流程制度限制团队的整体节奏。彼德克鲁克这之类的管理大师的大腿人人都好抱,但那是屠龙之术,您暂时还可能用不上,来点痛快实在的才是王道。

EOF

文章有删节。出版社的名字我就不直接说了,不过类似的经历的人还有潘加宇。你猜这是哪一家?

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

杭州四年

来到杭州四年了。前几年都还有个兴致简单总结一下过去一年的感受,今年都忘了这件事儿了。昨天好多朋友在 Twitter 上给我发来生日的消息,很感动。虽然我是按照老家的传统过阴历的生日。

上周有新入职的同时过来采访老员工,一天居然接待了两拨,向他们传递一些积极向上的信息的时候,自己其实心里非常困惑。可能人总要靠一些梦想支撑着做事吧,如果你信,就是真的,否则,真的你也不信。

最近有些事情缠身,杭州又连下了多天的雨,难受,压力之下戾气大增。”阴晴圆缺在窗外,心中一片艳阳天”,这是挺难得的境界。

如果没看到我发布 Blog ,那么我的 Twitter / Flickr / del.icio.us 可能都有内容更新,他们的价值或许比我写的文章更高。

不管怎样,我没有离开,依然在那儿,对,在网络上。

EOF

接下来的一些事情:

  • 4月去北京参加 QCon 技术会议
  • 杭州有家咖啡馆快开业了…
  • 和同事把手里的稿件校对完
  • 继续改进 JobsDigg ,让更多人受益

学习 HeroKu 的架构设计

这几天给我印象比较深的是 HeroKu ,提供 Ruby 快速部署环境并提供托管能力,他们的架构图做得十分漂亮,一幅图胜过千言万语,要是对 Web 架构感兴趣,都别问架构师了,看看 HeroKu 的架构估计就明白个差不多了 :)

概览图

好的架构图是画出来的,好的架构未必是设计出来的,最后架构好不好,还要看持续的改进能力。

HeroKu Overview.jpg

HTTP 反向代理

使用 Nginx , 这一层只进行 HTTP-level 的处理。Nginx 现在是不二选择。

HeroKu Reverse Proxy.jpg

HTTP Cache

对于静态内容,使用 Varnish 进行缓存。如果你在 Squid 和 Varnish 之间作选择,这里已经投了一票。

HeroKu HTTP cache.jpg

路由网(Routing Mesh)

Erlang 实现的架构组件,路由寻址,用以提升可用性和扩展性。

HeroKu Routing Mesh.jpg

动态网格(Dyno Grid)

用户部署的代码运行在这里,可以简单看成是应用服务器集群环境,只是粒度更小一点而已。

HeroKu Dyno Grid.jpg

对于 Dyno Grid 的进一步信息:

HeroKu Dyno Grid Arch.jpg

服务器操作系统是 Debian ;Ruby VM 是 MRI ,开源,C 写的;App Server 用的 Thin,他们说 Thin 比 Mongrel 更精炼;Rack,应用服务器接口;Rack 中间件,可选组件;框架,任何 Rack 兼容的都成;最后是客户托管的代码。

数据库

PostgreSQL,也可以采用远程数据库。

HeroKu Database.jpg

Memory Cache

Memcached ,居家旅行架构必备。

HeroKu Memcached.jpg

这几张图看下来,多少算是对 Ruby 环境有了一些感性认识。可以进一步查看 HeroKu 提供的文档,包含了一些代码实现上的准则。

部署是基于 Git 的。不知道大家有没有注意到 Git 在最近一年来的爆发? 超过 SVN 或许不是不可能的。

国内热炒”云计算”的,跟人家学学吧,与其整天帮着客户开发定制软件,还不如给客户提供一些弹性应用托管环境,起码看起来靠谱一些。

HeroKu ,不读 Hero-Ku, 读作 Her-oh-koo, 挺有趣

EOF

图的来源:HeroKu Platform Architecture

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