bhuztez (bhuztez)

[RubyConfChina2017 话题分享] 用 Erlang 快速开发 Web 快速开发框架

bhuztez — Tue, 19 Sep 2017 21:43:51 +0800

代码以及 slides 都在仓库里 https://github.com/bhuztez/razor

参考资料

Regular Expression Matching in the Wild https://swtch.com/~rsc/regexp/regexp3.html

Efficient submatch addressing for regular expressions https://laurikari.net/ville/regex-submatch.pdf

How Pony ORM translates Python generators to SQL queries https://av.tib.eu/media/19938

Programming Is Hard, Let's Go Shopping! https://blog.codinghorror.com/programming-is-hard-lets-go-shopping/

补充

因为时间有限删掉，或者一开始就没想到要加进去的一些东西，演讲结束后，在后面的交流中提到的，补充在这里

C-c C-k 大法好

大部分框架都是用 inotify 之类的 API 来发现文件改动，有改动就自动重启 server。可是有时候你文件改了一半，连语法都有错误，此时重启就会出现一堆莫名其妙的错误。造框架的时候，要把这问题搞好也不容易。

而用 Emacs 编辑 Erlang 代码，编辑好了，存一下，C-c C-k，会先编译成 beam 文件，假如编译失败，那就停了。假如生成了 beam 文件，就会通过热更新替换进去，不需要重启 server 就立即生效了，且能替换进去的至少是编译通过了的。而造框架并不需要去搞什么监听文件改动的事，省去了很多麻烦。

所以，后面框架的设计，主要的一条就是在编译的时候，做更多检查，生成代码。而不是在运行期根据不同的配置有不同的行为。尽管做这些是为了开发的时候，热更新代码开发体验更好，同时因为代码都在编译期生成好了，运行期没有不必要的额外的开销。

关于 razor_url_dispatch

有些网站 Apache 或者 nginx 为了一些特殊的活动页，配置了超级多的正则表达式规则，因为他们用的语言本身不支持 pattern matching，所以用正则表达式规则在弥补这个缺陷。但是这不是没有代价的。

而在 razor_url_dispatch 里，你这么写直接会告诉你 rule conflict，不让你通过

-dispatch({page,"0", {endpoint, special_page}}).
-dispatch({page,"{id:integer}", {endpoint, page}}).

推荐的做法是像下面这样

-dispatch({page,"{id:integer}", {endpoint, page}}).

handle_request({'GET', page, #{id := 0}}) ->
  ok;
handle_request({'GET', page, #{id := ID}}) ->
  ok;

而在 Erlang 里，下面这样的代码同样会提示你 Warning: this clause cannot match because ...

handle_request({'GET', page, #{id := 0}}) ->
  ok;
handle_request({'GET', page, #{id := 0}}) ->
  ok;
handle_request({'GET', page, #{id := ID}}) ->
  ok;

因为更合理的划分，我们在编译的时候就可以得到更多 warning。同时也简化了正则表达式的实现，可以使用 tagged DFA 来一遍扫描。

失败人士的口号是，performance comes mostly from correctness。所以失败人士拒绝跑分。

关于 razor_db

为什么要支持子查询

子查询和 aggregation 一起的时候，需要正确判断到底是 where 还是 having。我们不能只看表达式里有没有出现 aggregation。举个例子

test(DB, subquery_having) ->
    razor_db:select(
      DB,
      [ Name
        || #{id := ID, name := Name} <- from(i1),
           group_by(Name),
           Count <- [count(ID)],
           exists(
             select(
               [ #{count => C}
                 || #{count := C} <- from(i2),
                    C == Count
               ]))
      ]);

生成的代码是这样的

test(DB, subquery_having) ->
    [Name
     || {Name}
            <- razor_db:query(DB,
                              "SELECT T1.name FROM i1 AS T1 GROUP BY "
                              "T1.name HAVING (EXISTS((SELECT T2.count "
                              "AS count FROM i2 AS T2 WHERE (T2.count "
                              "= count(T1.id)))))",
                              [])];

为什么一定要支持 Common Table Expression

因为根据 SQL 标准，Common Table Expression 必须 fencing

也就是我们把过滤条件写在最后的 SELECT 里，SQL 标准不允许 planner 把这个过滤条件挪到 Common Table Expression 里。所以必须把过滤条件写在 Common Table Expression 里。只要这个过滤条件里有参数，那么就意味着不可以手工写一段 SQL，拼在最前面了。

在 Erlang 中表示 HTML

<br />
{br, []}

<span><a href="index.html">Index</a></span>
{span, [], [{a, [{href, <<"index.html">>}], [<<"Index">>]}]}

更多 Live Coding？

要注意的是，最后的 razor_api_example，就已经是接近完整的代码了。

包括前面各种例子，都是用 pattern matching 来展示结果的，并没有太大必要增加 Live Coding。因为代码已经太多了。

当前设置新手用户不能在 22:00-9:00 发贴

bhuztez — Sun, 09 Jul 2017 10:54:40 +0800

现在都 11 点了，还不能发，这么厉害？

我无法回复

注意提示的是到 9 点，现在都 11 点了

其实你不需要 ORM

bhuztez — Tue, 20 May 2014 11:21:48 +0800

我是标题党，很多时候 ORM 还是很有必要的。

不过有另外一些时候，明明知道要写的 SQL 是什么，不得不和 ORM 较劲，让 ORM 生成我期望的 SQL。不如让我直接写 SQL 吧。

但是，ORM 做了一件事，能把查询出来的按行的结果，关联起来。没有 ORM，就只能手工做了。这也太麻烦了。

我想了想，其实是很简单的。不到 300 行就能轻松实现这样的功能嘛。你也可以按这个思路自己实现。

https://github.com/bhuztez/warm/blob/master/warm.py

n2o: nitrogen 威力加强版

bhuztez — Sun, 16 Mar 2014 12:56:14 +0800

n2o在 nitrogen 框架的基础上，优化了速度，跑分不输 PHP

利用 Erlang 强大的元编程能力，不仅能从 Erlang 代码快速生成 HTTP API，还能生成 JavaScript，前后端可以都只用 Erlang 了，再也不用考虑坑爹的 node.js 了。

@luikore 快出来跑分

DeepThought: 屌丝版 Datalog 解释器

bhuztez — Fri, 14 Feb 2014 19:51:22 +0800

又来打小广告了

DeepThought 只支持最最原始的 Datalog。现在已经有了 JavaScript 1.8.5，Python 2.7 以及 Ruby 1.9+ 三种语言的实现。

这里有几个简单的例子，注意要用最新稳定版 FIREFOX 才能正常浏览。

Gitto: 屌丝 git 托管工具

bhuztez — Wed, 18 Dec 2013 20:32:07 +0800

打个小广告

这两天把以前的脚本重新整理了下，弄了个屌丝 git 托管工具，让你可以三步搭起你自己的 git 托管服务

不需要数据库
不需要 Web 界面
没有 branch 级别的 push 限制
未经测试

太棒了，还不赶快试试 https://github.com/bhuztez/gitto

P.S. 会尽快支持 Windows 的

不小心点到了 feed

bhuztez — Tue, 10 Dec 2013 12:28:48 +0800

发现点后退怎么也回不去了。

boy 还是 girl?

bhuztez — Wed, 04 Dec 2013 20:44:35 +0800

无意间看到 Node.js 社区：一个人称代词引发的论战

让我想起了一个很头疼的问题

比如

He who is not an Erlang fanboy, does not understand OO.

为了不必要的麻烦，应该改成下面哪个才对？

They who is not an Erlang fanboy, does not understand OO.
They who is not an Erlang fangirl, does not understand OO.
She who is not an Erlang fanboy, does not understand OO.
She who is not an Erlang fangirl, does not understand OO.

@hooopo @fredwu @knwang @blacktulip @ywencn

另外，这不代表我支持这种假惺惺的避重就轻的行为。另外的另外，送一个鸡汤链接，Three Years in an Alternate Universe

Ruby 中文群组

bhuztez — Sat, 09 Nov 2013 16:45:26 +0800

https://groups.google.com/forum/#!forum/rubygroups

SQL is Agile

bhuztez — Thu, 10 Jan 2013 11:25:09 +0800

http://lucumr.pocoo.org/2012/12/29/sql-is-agile/

我也是这么认为的。最开始的时候，总是要先搞清楚数据本身的约定以及数据之间的联系，第一步总是要 normalize 的，schemaless 在这里并不能带来什么帮助，反而更麻烦了。从这个角度来看，MongoDB 显然不适合用来开发原型。

假如你不熟悉 SQL，可以看看这个博客

http://database-programmer.blogspot.com/

接着才是 RDBMS 处理不好的地方要 denormalize，有必要的话再引入别的类型的数据库

你可以放弃几乎所有 JOIN，获得接近线性扩展的集群能力。这是 MySQL NDB，Mnesia 之类的数据库了。

也可以预先定义好需要哪些 JOIN，把相关数据放在一起，从而为这些 JOIN 优化。Google F1 和 Oracle 的 Table Cluster 就是这么干的。有没有开源实现，我还没了解过，你可以来补充一下。

http://research.google.com/pubs/pub38125.html http://docs.oracle.com/cd/E11882_01/server.112/e25789/tablecls.htm#i25478

再后面就得等着被 CAP 坑了。

http://blog.nahurst.com/visual-guide-to-nosql-systems

CouchDB 用来做 aggregation，通过放弃 consistency，换取用空间换时间的机会 Memcachedb 之类的用来做缓存 BigTable 之类的，没用过，据说很有用