第一次发帖毫无技术含量，但是绝对有市场含量。
广州4399招聘Erlang服务器开发工程师，市场和技术优势就不多说了，有意向就联系我吧，一起开创一片事业！
职位有求：
联系人: litaocheng(at)gmail.com
之前和 Redwood 的 Raymond 聊过一下。他们有一个相当宏伟的计划（具体内容当然不方便透露啦），可以说的是，他们关注于金融领域，大家可以从“支付网关”之类的关键词展开联想。所以，看到他们在这里贴出来的招人贴，理应是要帮忙推一下的啦。各位对这个领域有兴趣的童鞋。不妨考虑下。
Redwood Technology is a new division of Redwood Group International, specializing in product and project development. We are seeking exceptional computer scientists and electrical engineers who live to work in an exciting and challenging fast paced startup environment using new technologies to rapidly develop proof of concepts and then work with product management to transform them into production solutions.
Responsibilities:
- You will be responsible for rapidly developing solutions in Erlang/OTP, and supporting them through their product life cycle (requirements, design, code, test, support).
- Work with product management and clients to define requirements, solution architecture, and technologies.
- Involved in all aspects of the product/project lifecycle, and must be able to develop all aspects of the web application.
- Incrementally and iteratively develop the solution over many short sprints
- Work with and mentor other team membersYou must have:
- Practical experience developing distributed, concurrent, scalable, and fault tolerant enterprise web applications.
- Proven exceptional experience with Erlang/OTP design and development
- Experience with multiple languages including Erlang/OTP, Java, Javascipt, PHP, C/C++, HTML, etc.
- Proven exceptional experience with embedded device design and development
- Experience producing UML artifacts (use case requirements, sequence diagrams, state/activity diagrams, class diagrams, component diagrams, deployment/package diagrams) to document your system architecture
- experience reverse engineering Java and PHP applications
- Practical experience with Cloud computing
- Practical experience with multiple operating systems (Unix, Linux, Windows, OSX)
- Practical experience with iOS and Android
- Experience building ReST services and application platforms
- Experience with Data Storage (RDBMS, NoSQL, etc.)
- Good communication skills
- A strong belief or experience in Agile and iterative development approaches
- Ability to document (UML) architecture and designs
- A CS or EE degree, and be passionate about applying the latest software ideas to your systems
- Be a startup junkie who wants to see a new idea (and company) succeed.
- Solid experience with web development technologies (both browser-centric and server-centric).
- Ability to get things done
- Ability to think outside of the box; generate creative solutions
上次 ECUG 2010 以来，Erlang 在国内其实已经在渐渐地进入“实战单元”了。各路大佬本着“悄悄地进村，打枪地不要”的原则，私下里暗自招兵买马，囤积人才，已经有一阵子了。二十一世纪什么最贵？从各路的跳槽消息来看，冯小刚的话似乎也蛮有预见性的嘛。
“暮春三月，江南草长，杂花生树，群莺乱飞……”，又到招人的季节。坊间招人的英雄贴，渐渐地多了起来。以下便是一则。
Chicago Boss 这个名字听起来，怎么也让人联想不到 Web 开发领域。反而总让人不由得想起黑帮、枪战、还有私酒泛滥的 1920 年代（估计是最近看《大西洋帝国》给闹的）。但是，的而且确，这个玩意明白无误地就是 Web 开发领域的事儿。
先上亮点：
High Productivity
Compact query syntax:
boss_db:find(person, [age > 25])Elegant controllers:
edit('GET', []) ->
ok;
edit('POST', []) ->
{redirect, "/somewhere"}.
Simple data models:
-module(person, [Id, FirstName, LastName]).full_name() ->
FirstName ++ " " ++ LastName.
Rails-y records:
Person = person:new(id, "Joe", "Blow"),
Person:save()
Django templates:
{% for person in people %}
- {{ person.full_name }}
{% endfor %}
Easy Comet – New in 0.4.5
BossMQ introduces a simple API for sending and receiving messages. Here is a complete long-polling chat backend:
send_chat('POST', [Channel]) ->
boss_mq:push(Channel, Req:post_param("msg")).receive_chat('GET', [Channel]) ->
{ok, Time, Messages} = boss_mq:pull(Channel),
{json, [{time, Time}, {messages, Messages}]}.
With BossMQ, any controller action is a potential Comet endpoint. Thus, Comet endpoints have complete access to your entire application — databases, templates, the whole stack.
High Reliability
100% asynchronous network I/O
- Under load, uses less RAM than synchronous apps (PHP, Rails, Django)
- Comet long-polls won’t block the app server
- Single-process model keeps CPU context switches to a minimum
Supports both SQL and schema-less databases
- MySQL
- PostgreSQL
- MongoDB (NEW)
- Tokyo Tyrant
- Mnesia
- Or write your own adapter — usually ~300 lines of code
Operational simplicity
- Zero downtime code upgrades in production (NEW)
- Standalone server does not require Apache, Nginx, etc.
- Direct SMTP mail delivery does not require Postfix
Unique testing framework
- Closure-based tests reduce test code size
- Run functional tests in-memory — no network I/O
- Integrated web and email testing
Future plans (not yet implemented!)
- Full OTP compliance
- Full test coverage
- See the Roadmap
好吧我得承认，其中的一些亮点其实是来自 Erlang 语言本身的。
毫无疑问，这个项目提供了 Erlang 和 ruby on rails’ way 的跨界组合优势。比如说，在采用高生产力的 rails 方式来构建项目时，如果心存疑虑，担心某一天会被可能的性能问题跳出来反咬一口的话，那么现在又多了一个具有 FP 风格的选择了。
有必要表扬一句的是：chicago boss 的文档整理得相当靠谱，单就这一点而言，在众多的 Erlang Web 项目中，就很有走红潜质。此外，开发过程似乎也可圈可点，按照 roadmad 的特性持续升级，很让人看好。不过也有的地方让人感觉有点奇怪，比如说，源代码竟然是要下载的，而没有用“开源工业标准”的 github ，这多少有点让我不适应。
顺便 blah 一下，如今这世道， web 开发似乎已经渐渐地在更多转变为前端以 jquery 为基础的 ajax 开发了，换句话说，前端正在静态页面化。而所谓的后端系统也已经相对标准——更像是 restful 的 CRUD 接口再加上薄薄的一层业务逻辑。前端与后端之间的接口方式与约定已经相当之稳定。那么，比如说，有了 chicago boss 这么有生产力的架构，在后端性能开始吃紧的情况下，趁着系统升级的机会，简单地整一把，平滑地将后端系统“迁移”到更高效的平台上，未尝也不是一个不错的升级方向嘛。
为期两天的 ECUG2010 圆满闭幕，按照惯例，交作业。
上次在上海办的，没有去成，这次在北京，无论如何，抛下一大堆事情还是去了。感觉很好，非常之好，但是你又很难跟人讲清楚到底好在哪儿，组织、演讲、提问、茶歇、闲聊……，样样都好，但似乎让人感觉超好的又还不止是这些而已……，具体是什么，我说不上来，还是得大家亲身去感受才行。
这次大家的 Topic 密度都很大，就好像你还没站稳，对方就势大力沉地给你一个降龙十八掌，如果没被砸晕的话，你至少也得腾腾腾地退个十步八步才能站得住。而且，每个人讲的东西都很不好消化，以至于，我这里趁着每日清晨思路最为敏捷之时，勇猛精进地消化了这许多天，也只能大概其地理出一个思路，还得赶紧动笔写下来，以免一会儿又犯糊涂了。
下面开始 Blah …
Read more…
某同学在 Erlang-China Maillist 里问：
> [erlang-china:3459] 这里好像已经不活跃了？
> 看看最近的帖子居然都是2009年的。。。。
然后，有人说了：
> ……社区09年上半年比较活跃吧，主要是因为zhao 翻译完《erlang语言编程》出版了，大家热情都很高。现在那些人估计都有点牛屎了，都在忙着怎办把erlang用到项目里去吧，因此也在社区里消失了……
汗~~！作为“牛屎”之一，特地从“牛屎海”的深处浮起来冒个泡，回应一下。
我确实正是在埋头把 Erlang 用到小小的项目里。而，我们搞技术的都知道，一旦深入项目的具体细节，就“不怎么好玩了”。需要面对大量“乏味的业务问题”，大多数问题也不会指向“技术的发现”。在项目这锅汤里泡上一圈出来，可能会得到一堆“解决业务问题”的小窍门，但肯定不会收获多少“解决特定技术问题”的深入思考。尤其是，如果一切以“多快好省地解决问题”为优先考虑的话，那么，用到的技术很可能大多都会是浅浅的，以体力活居多，没什么技术含量。这大概是难免的，说到底了，技术毕竟还是要服务于业务的。这次的 ECUG 没有什么“技术营养”可以和大家分享，很有些不甘心啊。不过，肯定还是会去参加的，又有一年没见了。大家，很是有些想念。
社区的活跃，或许是铺开来广泛应用的一个前奏吧，后面肯定会有一个潜水期的。还记得 2000 年左右，那会儿我在搞 PHP 也碰见过这种情况，论坛活跃了一阵子，也不知道怎么地，突然就沉寂下来。之后，过了好多年，PHP 似乎才慢慢地“火”起来。我个人从经验角度来看，一个语言社区，无论它活跃也好，不活跃也罢，其实始终也都是“一小撮”，大家其实也不用太在意的。当然了，如果聚光灯到处乱闪，还有一大票粉丝摇旗呐喊，那当然很“带劲”，自我感觉很时尚。但是，如果没有这些光环的话，那其实也没关系，因为大家毕竟不是混时尚界的，让人“掉到这口深坑里”的，仍然是那些些费解而有趣的技术问题，而不是计算机程序设计语言的今冬流行时尚风向标。借用某位同学之前在讨论到 Erlang 能不能火的时候说过过的话——最好的境界是“悄悄地进村，打枪地不要”，大家都低调地闷声发大财，那就挺好。
明天见了，各位。
官方的 Erlang-Question Maillist 确实是个值得“长期潜水”的地方——因为，这里时常会有“水怪”出没，比方，象火爆的 Joe Armstrong 爷爷和热辣的 Ulf Wiger 大叔之类。比方说，讨论象“争论 Erlang 到底 OO 不 OO”这样的“诱饵话题”，通常会比较容易吸引到“大水怪”们跑过来……，然后就有好戏看了。就算话题本身的乐趣有限，争论本身也不会让人失望。通过争论，我们能够看到各种各样的背景、引用、推论、思维方式乃至文化……，这些可都是人类精神世界多样性的珍贵样本，比起技术本身也毫不逊色。
以下为 BLAH，没时间的同学自行跳过。
在程序设计语言的圈子里，有关 OO 的争辩，几乎是各大社区每过一阵就会又发生一次的“风景”。单就辩论本身而言，对于一部分同学来说，因为围观的次数实在太多，无论是辩论的过程还是结论，其实大都已经不再新鲜。
但，从另外一个角度来说，每次这样的辩论，几乎总是能给我们带来一些新鲜的“猛料”。他们在辩论之中的引用、类比、或是提及，就像是一本好书末尾的“引用来源”列表(这个东西我们历来都不重视啊)。我们所要做的只是轻点鼠标按图索骥而已。这样的阅读通常都很让人愉快，因为它们每每都能给我带来“新鲜的空气”。不知其他人是否也有同感，或许是因为国外的治学风气更好(注明引用来源的好习惯)，又也许是语言的隔阂(这些好东西都是英文的)，再不就是我个人的理论基础太薄弱(太不喜欢读论文)，原因不太可考；反正单就我自己而言，每次阅读这些东西都能让我在受益匪浅(长见识啊)的同时又切身体会到与其他科技“发达国家”之间学术水平的遥远差距(人家几十年前的论文，对我来说根本就是闻所未闻)。
这一次，激烈的辩论发生在 Clojure 社区。大家可以点下面的链接围观(也可以当作提高英语水平的好“毒物”)：
照例，提醒一句，总是有些好东西在墙外，请自备工具。
Kresten Krab Thorup 是一位有着 20 多年程序设计语言实现经验的大牛。
I have been doing language implementation for 20 years. I was at NeXT doing the Objective-C compiler for some years in early-mid 90’s. I have worked on severa rounds of gcc, the GNU Objective-C, the palmos-m68k port, the JVM interpreter inside GNU Compiled Java. I have also contributed little pieces to JRuby, and a ton of other language stuff.
貌似是一位靠谱程度相当之高的同学。他在 GitHub 上设立了一个 Running Erlang On JVM 的项目 —— Erjang，到目前为止，已经达到可以顺畅运行 RingTest 的完成度，有兴趣的同学可以 git clone git://github.com/krestenkrab/erjang.git 弄回来玩一玩。Erjang 的大致设计思路是：
It loads Erlang’s binary .beam file format, converts it into Java’s .class file format, and loads it into the JVM. It will eventually have it’s own implementation of all Erlang’s BIFs (built-in-functions) written in Java. Those are being implemented as I stumble upon them in testing.
当然了，这是“终极目标”，当前实现版本的状况是：
Right now Erjang relies on an external Erlang process to utilize some of the beam handling code in the standard library (e.g., so I don’t have to parse .beam files), but Erjang would eventually be able to self-host the required modules. Right now, Erjang also uses jinterface to talk to other Erlang nodes, but that will needs porting/rewriting, I think.
稍有常识的技术人员都知道，如果不是过过嘴瘾的话，这样的“终极目标”将会意味着多大的工作量，但是有 20年+ 专业经验值的牛人通常都是非常 unpredictable 的物种。因而，这些工作对他而言到底需要多少时间，确实也很难说。
我知道，看到这样的项目，和我一样，第一反应，你肯定也会产生这样的疑问 —— Erlang 的 BEAM 已经是一个有着相当长时间历史的成熟 VM ，在很多方面都已经做了高度优化，为其他 VM 所不及；而 Erlang 在 Language 和 VM 的配合上也颇多好评，为人称道。那么，Kresten 这么做又有什么必要呢？
实际上，这个问题在 Reddit 上确实也引来了一大堆激烈的争论。Kresten 本人为此单独写了一篇 Erjang, Why? 来讲述自己的观点，有兴趣了解的朋友可以点[这里]延伸阅读。以下是我的 blah ，不喜欢 blah 的同学可以直接略过。
对于我个人而言，似乎还看不见 Erjang 的实用意义(说不定是因为我短视呢)。
但，无论如何，人家牛人 Kresten 同学既然都已经做出来了，总归也不会是一件坏事。 JVM Team 好歹也是 20年+ 以上大量开发团队的智慧结晶，必有过人之处，两相对照，肯定能发现一些 BEAM 团队没有考虑到的地方。通常而言，一个语言出现多个实现，彼此互相对照和竞争，绝对是一件好事。比如说，在 Kresten 的 blog 中就已经提到，它在 fib 的测试上发现 BEAM 在 bignum 的运算表现上不如 JVM 的好。
除了这些“整体上”的好处，Erlang 在 JVM 的实现，想必会也受到 JVM 体系固有的限制，如果因而破坏语言本事的一些核心特性，比如，进程的独立性，GC的独立性之类的，那么在具体选择时，就值得我们这些使用者再三斟酌了。
———-我是分隔线————-
顺便要抱怨一下。今天点 Firefox 地址栏里的 RSS 图标想要直接订阅 Kresten 的 blog ，发现 fusion.google.com 居然也被该死的功夫网给墙了，纯粹一个工具，能颠覆什么？这帮魑魅魍魉怎么就怕成这样了？
大家大多都有翻墙经验，随便设置一下就好了。但是，其他人怎么办？一个这么好的功能，就这样被这些破玩意给糟蹋了，凭什么？想来都让人上火。希望大家和我一样，多向身边的人传播翻墙技巧。日拆一砖，就不信丫能在世界的东方永远屹立不倒。
Recent Comments