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 注释

脚本语言直接 git pull 部署，逃

搜索技术问题：
用英语✔
用中文✘

@zjsxwc #125 原文：“实话实说其实 wiki 语法更适合知识管理，老牌 mediawiki 开源免费用，markdown 还是算了吧”
回复：有个 golang 写的 mm – wiki 推荐 https://github.com/phachon/mm-wiki

实话实说其实 wiki 语法更适合知识管理，
老牌 mediawiki 开源免费用，
markdown 还是算了吧

翻译下楼主的话：

php 输出 html 的疑惑
找了下资料，两个方向，一个是模板输出 html，一个是 ob 函数输出 html。 由于前后端分离，服务端输出 html 的方式现在已经被淘汰了。 问题：就目前的工作情况中，服务端返回 html 是否被淡化或者说由于其他方面性能的提升被弱化了？（我只是想偷下懒，如果不重要我就不学了）