从前看到很多人问一些编程类的问题（大多数都是C/C++的），反复回答特别麻烦，就希望能有一个易懂的指导书能够推荐给他们。独立写书当然是没有这个精力了，很长时间内只能搁置一边。最近又有同僚提起此事，并纠集不少好手参与，感觉写完有戏。> GitHub 项目> GitBook 查看欢迎各路高手来提PR参与书籍编写。

概述Mini SQL是SQL的一个子集，支持SQL的最常用的部分操作。Mini SQL分为：Interpreter, 将SQL翻译成API可识别的消息API，接收并响应消息……

纯前端的网页是可以直接部署到 GitHub Pages上的。下面展示一个Material-UI部署到GitHub Pages上的实例。 至于如何配置Material-UI，请参考Material-UI + React + Babel + Webpack 环境配置Demo: XJTU Index - 简单的导航网GitHub: XJTU Index - GitHub用Webpack将前端UI

一个文件就可以构建一个前端试想一下如下场景： 当网站请求一个JS文件并执行其中代码之后，整个应用前端马上出现。一切在客户端上完成渲染，这只能说是客户端渲染。在本文所描述的设计模式里面，用 app.js 代指可以构建前端的JS代码文件。简单地在HTML文件中加上这样一行（或者是用JS控制JS执行） <script src="app.js"></script>客户端马上去请求 app.js 接收完

平凡定义具体的App通常有一个这样的开始 app.jsvar app = document.createElement('div');//创建App容器document.body.appendChild(app); // 将容器挂载到DOM这是最简单的App挂载，即其平凡态。这与简单的JS操纵DOM毫无区别，这也是和谐的地方。 首先，一个符合规范的App不应该依赖HTML DOM中的特定节点，

渲染工作应该由谁完成？时下，前端 UI 设计越来越复杂，可谓“XX与XX齐飞，XX共XX一色”。 越来越复杂的 UI 意味着越来越重的 渲染工作。目前通常有两种选择：服务器渲染 与 客户端渲染 笔者是支持客户端渲染的（没错就是钦点的）以 Jade, YAML 为代表的 模板渲染引擎 一般作用于 服务器 作为 后端 的 视图部分。 而使用 JavaScript 直接 处理 HTML DOM

活动室申请系统是一个广泛存在的系统，如学生想要组织活动，需要学校的场地，那么他们会去向有权限的老师申请场地，然后在规定时间去规定的场地活动，如果这个场地是一个有锁的房间，那么可能还需要找门卫要钥匙开门，通常还需要出示申请通过的证明……这是一件逻辑简单的事务，随着办公互联网化、无纸化办公的需要，活动室申请系统应运而生。我们可以抽象地描述刚才的事务：首先有若干场地、空间、房间（Room）需要挂载在系统上

在线评测系统（Online Judge System）想必很多人都有所耳闻，比如上程序设计课程的时候需要在网上做题交代码……更不必说那些做高难度试题的信息竞赛选手了。通常来说，一个在线评测系统的核心是其积累的题库及测试数据。注册用户在系统里查看问题并提交答案交由评测系统评测，最后反馈给用户，这是一个基本的业务逻辑。我并不想做一个寻常的Online Judge，而是一个概化可复用的在线评测系统，用函数

在线支付系统在线支付系统是一个第三方安全交易系统。买方可以先向账户充值，然后系统会提醒卖方发货。一旦买方确认收货，系统会将钱转到卖方的账户，就这样他们完成了一次网络交易。在个文档描述了支付系统的基本的功能性和非功能性需求。请仔细阅读。功能性需求个人账户管理系统个人账户管理系统允许一个基础的用户（买方或卖方）用他们的真名、身份证号与电子邮件等基本个人信息注册一个账户，并且可以

之前那篇博文Mini SQL 总体设计（一） 中在提到Tokens分割的时候试图进行句法分析，这个问题就相当复杂了。看了指针1 实现的Token分割之后，我发现我有个地方搞错了。我试图将SQL语句中充当不同成分的部分提取出来，就像分析主谓宾一样，这实际上是句法分析。对于正则表达式来说未免任务过重。而且有限状态机也无法进行无限深度的括号平衡匹配。我应该把Tokens分割地更细，然后将逻辑复杂度转移到T