楼主，
在前端娱乐圈，这种情况更常见，我们老项目用 requirejs+underscore+backbone
这种完全用古老 js 实现的 mvvm 做项目一直很好用，在工程化与可维护性上也都没有问题，也是当年比较流行的解决方案，嗯在 rails 刚出来火的那段时间里


但现在招人前端只会 vue，问他们看过 vue 源码，vue 的 ast 树了解吗，如果要给 vue 加新语法糖会吗这些相对深入点的，就全不会了。

如果用 orm 那么在每次 更新实体类对象到数据库中，
都会提供事件，
你只需要写一个事件订阅者，
记录是哪个用户把这个实体类哪个字段从什么值更新为什么值就行了。


如果你是基于纯 sql 操作数据库的，我建议写个代码生成器，把要拦截的方法都重新 proxy 一下，代替原方法，实现一个简单的 aop

nano 才是 Linux 自带的吧，vim emacs 都要手动安装

build 是用来运行构建环境的，
run 是作为工具提供给别人用的，
因为并不知道别人要编译哪些文件，所以 run 更灵活，而 build 需要写死等待被编译的文件

jb 家 IDE 自带的那个
还有 phpmyadmin

1
抽奖有 bug
如果结果 mod 为 0 是谁获得奖品

1

不好阅读

不如玩 arm7 stm32

@nigelvon #67 原文：“@zjsxwc GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成，到你这就变成“服务器查询执行业务的消耗仍旧不变”了？你确定你用过么”
======
回复：到了业务层面，就算不反回某数据的字段，数据库也返回数据的，除非你不用 orm

买点股票

说通俗一点，graphql 对于后端来说该写的接口还是要写，上了 graphql 后，后端的每个接口，变成了类似数据库表资源的存在，于是前端可以写出等价于 sql 的查询语句：

“ SELECT apiXXX1 WHERE arg1=aaaa AND arg2=bbbbb; SELECT .....”

等价于

{result1:apiXXX1(arg1:aaaa, arg2:bbbbb), result2: apiXXX2......}



前端同学的需求痛点是
1. graphql 可以一个请求完成对原先多次请求的查询，这样就不用 promise 等异步处理了。

但一般来说后端不用 graphql 也能做到一次请求性合并处理多个接口请求，无非是加一个循环而已。


2. graphql 可以通过 schema 约定接口请求与返回的强参数类型。

这个其实前后端本来就能通过接口文档的形式约定，原本是程序员基本素养问题，现在通过强制代码编写约定，我觉得可以提倡，但不少人会不乐意写因为麻烦。

3. graphql 可以过滤掉不需要的字段，减少网络带宽。

虽然减少网络带宽，但服务器查询执行业务的消耗仍旧不变，而且对于大部分业务来说，前端获取的数据越多越好，很少有人会为了省那点带宽干这事情。

GraphQL 其实还不如“古老”的结构化查询语言 SQL (Structured Query Language) 来的方便

那个根据女的照片来查询是否此人在 porn 网站上有流出过视频的 App 叫什么来着？不就是楼主要的功能吗

讲真，学习 js 是目前性价比最高的语言

wp 呗，写博客、记笔记、做官网都合适

额。。。。。。。

deadline 快到了之前

@ynyounuo #11 原文：“废那么大劲儿截半天图，你居然还没找到这个页面 https://github.com/php/php-src/commits?author=zsuraski ”
======

回复：确实是 2006 年就几乎不再贡献代码了，最近的几次提交只是改了下 copy right 注释