今天早上并没有能够成功在五点半起床去坐车，所以，我现在依然在老家。
之所以没能成功，有一些客观因素，不过，不在本文讨论，我们来讨论讨论主观因素。
我的闹钟其实是有两个的：
两个闹钟就是担心我自己不能够起床，不过目前来看，显然两个闹钟是无法拯救我的。
回顾我与两个闹钟战斗的场景，我突然意识到。我之所以起不来，很可能是与下意识关掉闹钟这个行为有关。
下意识关掉闹钟，让我从“你该起床”的场景中剥离出来，可以起床。如果能够控制自己，不要去关掉闹钟，让自己始终处于这样的一个场景中，想来能够更好的刺激自己起床。
由于要做每日极漫小程序，也就需要其背后的漫画翻译组活跃起来，随之，就需要翻译组背后的工具正常使用，不过 LCTC-CLI 已经很久没有更新了，便趁这个机会，恢复这个工具的更新。
对工具的更新， 首先应当做的，自然是补全测试，这样才好确保自己的改动不至于让老项目无法正常运转。
首先，执行命令，将 Mocha 安装在开发依赖中。
npm install --save-dev mocha
随后，再修改 package.json 文件中的 scripts 部分的内容，将 test 对应的命令改为 mocha，效果如下
{
...
"scripts": {
"test": "mocha"
}
...
}
Code language: JavaScript (javascript)这样，你就可以运行 npm test 来执行测试了。
安装完成后，你可以运行npm test 命令，来执行测试，这时，你会发现报错如下：
Warning: Could not find any test files matching pattern: test
No test files found
这是因为你并没有创建测试文件夹和测试文件，所以自然会报错。
执行如下命令，来创建一个测试目录和对应的测试文件
mkdir test
touch test/test.js
再次执行，你就可以看到，测试成功通过。
0 passing (3ms)
虽然是告诉你，你并没有通过任何的测试代码（所以是 0 passing）
接下来，编写第一个测试，打开 test/test.js，然后填入下述代码
var assert = require('assert');
describe('Array', function() {
describe('#indexOf()', function() {
it('should return -1 when the value is not present', function() {
assert.equal([1,2,3].indexOf(4), -1);
});
});
});
Code language: JavaScript (javascript)然后，再次执行 npm test ，这样，就完成了第一个测试，你会看到这样的输出
Array
#indexOf()
✓ should return -1 when the value is not present
1 passing (7ms)
这样，就完成了初步的 Mocha 的引入和测试。接下来，开始继续编写实际的测试即可。
不过，我在编写测试时发现，原先的代码结构极为不合理，因此，决定直接重写了。使用 TDD 的思想，完成重写这个工具。
再上一篇文章中，我提到了，想要去做一个前端的队列。
和几个朋友聊了聊，他们认为这个东西不值得做，因为没有价值。
在我看来不这样认为。
就这样的话题而言，证实很容易。只要实现，并证明可用，就可以完成证实的内容。
但是，更重要的是证伪，需要证明这个东西，虽然可以做出来，但是并不好用。具体的不好用是多么不好用，具体的量化。这样才能算完成了证伪
今天在 V2ex 和别人讨论我写的《离用户近一点，再近一点》时，提到了队列、3rd API
关于 3rd API 的问题，我可以理解，因为涉及到安全问题，我们需要将 token 放在后端。如果安全问题可以解决，放在前端也不无可能。
关于队列的问题，我就有了想法？为什么不可行？
队列主要问题有三处
关于消息通讯，可以考虑实现 P2P 网络来链接不同的前端设备；而选举问题，可能需要我去看看拜占庭将军问题，以及了解一些数学相关的东西。其中，老王给我了一个思路，可以看看分布式队列的实现逻辑。
调度问题也可以参考分布式队列。
在搜索的过程中，找到了香港城市大学的教授的研究页面。
https://staff.ie.cuhk.edu.hk/~mhchen/projects/p2p.queuing.html
搜索关键词
peer to peer queue
peer to peer message queue
补充信息
搜索过程中，发现问题被简化了，可能有一些可能可以在前端实现队列的工具，比如 ZeroMQ。
作为一个 Engineer ，前「后端工程师」，我用过不少后端框架，比如 PHP 里的 ThinkPHP（3.x）时代，Laravel（5.x）时代，Python 的 Flask、Django ，Ruby 里的 Rails。
其中，近两年我用的最多的是 Laravel 和 Django ，原因是他们提供了一个很重要的 Feature ，就是 Admin Panel。只不过 Django 是官方自带的（Django Admin），而 Laravel 使用的是第三方 Pacakge （Laravel-Admin）。
借助这两个工具，可以快速的生成一个好用且效果非常不错的管理后台，让并不是很喜欢做界面的我大呼爽快（实际上我并不是不喜欢写 JS，我仅仅是不喜欢写 CSS，现在的组件化开发大大的让我解脱出来）。只需要很少的一些代码，就能够完成自己想要的效果。
不过，这样让我产生了一定的依赖，现在要做一些和 Web 相关的事情时，我都会优先考虑 Laravel 和 Django ，因为他们提供了 Admin 后台，可以让我在很长的一段时间内不去关注后台的逻辑，更加专注于前台的开发。
这很好，很敏捷。但是也让我失去了自己开发业务后台的耐性，毕竟，已经有更加简单的实现方式了，为什么还要为难自己呢？
但是，如果你想要认认真真去做一个项目的时候，会发现这种高度简化的代码，让你的拓展性非常的差，你无法更好的去做好自己应该做的事情。
所以，为什么不从一开始就自己写后台呢？虽然慢了点，但是对于你自己来说，也是足够的。随着你自己的开发项目的变多，完全可以做一套你自己的通用后台，完全符合你自己的要求、想法。那才是你真正需要的。
在现代的工业体系下，任何工作都被拆分为流水线上的一环，如今的互联网行业更是从用户那里知道他们想要什么再到实际做出来，有足足六七个环节。
作为一个有写代码爱好的人来说，能选择的余地不多，唯有「后端工程师」和「前端工程师」，在过去的很长时间，我基本上呆在后端的领域，去做了很多后端相关的开发，自己也在后端方面有了更多的认识。
在新的 2019 年，我将会尝试让自己转向，成为一个前端工程师。接下来，我来说一说我这个选择的背后逻辑。
白子：离客户越近，其价值就越大。
提到择业，就避不开两个话题，企业的需求和员工的价值。一般来说，我们认为，员工的价值由他为企业带来的价值所决定。
这句话没错，那么，员工如何为企业带来价值？
员工可以帮助企业创造更好的产品，但是，这是价值么？
更好的产品本身并不是价值，其所带来的用户、客户才是真正的价值。
员工本身并不让企业盈利，相反，企业需要支付费用给员工。而客户则是支付费用给公司，帮助企业盈利。
从这个角度来看，离客户越近的人，越能产生价值，这也就是为什么我们会经常看到一个企业里，销售是赚钱最多的人，因为他们离客户最近，能够给企业带来实打实的价值。
白子：技术本身就是螺丝钉，只研技术，不过是一个螺丝钉，变成一个更粗的螺丝钉。
关注技术本身有没有坏处？当然没有，作为一个开发者，追求技术的卓越是应有的义务。但是，从企业的角度来说，只关注技术本身，意味着你的价值会不断降低。
技术再强，也是可以找到替代者的，区别仅仅是愿不愿意花那么多钱罢了。业务理解的深度，却是其他人无法轻易替代的。江山代有才人出，各领风骚数百年，技术迭代速度非常快，总会有新人出来，比你更加擅长技术。
白子：如今的前端更加接近业务本身，更具备价值
随着现代软件产品的高度流水线化，我们推崇的前后端分离、RESTFul API、GraphQL 让后端的工作越来越轻松，可以花费更多的精力投放在技术深度的探索，去研究更加深层次的优化问题，而不需要花费更多的心思在业务逻辑上去。
同样的，前端不得不承担起业务流程的开发，工作量大大加大。虽然有各种各样的组件库帮助前端优化了具体布局、界面上面的工作，但业务流程本身的复杂度并不会因为组件库的引入而简化。
在这种强前端重后端的模式下，前端承担了原本是后端的工作，让后端不再需要去理解业务逻辑，更加关注技术本身的内容就可以了。离业务越来越远，使得后端的话语权越来越小。
前端工程师本身负责的是客户可以看见的内容，这使得他们相比于后端工程师，有着更多的职业选择。
他们了解用户交互体验，可以从开发转换成为用户研究
他们了解用户使用方法，可以从开发转换成为销售
他们了解用户使用路径，可以从开发转换成为产品经理
而后端，由于专精于技术，其职业选择，也不过是从一门技术，转为另外一门技术罢了。
其实，说到开发，就难免会遇到一个问题？
你是想做前端还是想做后端？
在大企业内，前端和后端差距都不大，不过从个人成长角度来看，二者又有所不同。
从技术成长的角度来看，前端和后端的选择并不会影响你最终成为技术大牛。任何一个领域，都有足够多的人不努力，等待着别人去教他们，只要你愿意努力，很容易就超过他们。所以，在这篇文章中，我并不想从技术的角度考虑。
这个想法是这两天在喂羊的间隙想到的。
前端和后端的区别是什么？区别在于前端更接近用户，而后端离用户更远。
在传统的开发模式下，前端切图，生成模板丢给后端，后端加入模板的标签，渲染界面。
在如今的开发模式下，后端提供 API ，前端负责完整的交互、路由等工作，需要花费大量的时间和精力在与用户相关的内容上。这使得前端开发人员，有更多的机会直面用户需求。而后端更多的是面对业务，根据一个个业务封装编写对应的 API，这使得后端无法完整的了解用户的需求到底是什么。
为什么要离用户近？
我见到过很多程序员，他们只关注于技术本身，而不在意产品、业务方面的事情，但是如果你有着自己做点什么东西的想法，那么，就一定要离用户近，接触到用户真实的需求，并去分析，为什么用户的需求产品经理给出的方案却是这个样子的。
离用户更近，离钱更近。
不过，虽然前端可能更适合一个想要自己做事情的人，但是你反而应该先去以后端的身份加入到整个生态中，因为在一开始的时候，你还有足够的精力和热情去研究技术，随着时间的流逝，你对技术的兴趣会越来越小，会花费大量的精力在产品、推广上。所以，前期关注底层的技术，后期关注用户、体验层面的东西。
在过去刀耕火种的编程年代，程序员写代码的时候都是手动创建表
但是，在开发过程中，难免会遇到需要对表结构进行修改，在一些小型团队中，尚且可以通过喊一声，大家都执行同样的操作来完成，确保各自的数据结构的一致性。
随着开发流程的变长、开发人员数目的增多、远程工作的流行，这种方案显然不可行。
因此，就出现了 Migration 。Migration 是将数据库的变化以代码的形式存储起来。一个人在进行数据库修改时，使用 Migration 进行操作，其他人只要执行对应的 Migration ，就可以进行数据库结构的同步。
一个现代化的框架，应该有 Migration。
如果你未指定 Node.js 的版本时，会以 0.10.2 版本 运行，此版本无法使用 const ,所以，需要指定你的 Node 版本。
由于工作上的原因，有需求要使用 WePy，刚好，有了云开发的契机，就决定研究一下。
想要做云开发和 WePY，首先要先熟悉 WePY。 WePY 其实之前就听说过，不过自己一直没有使用，更多还是习惯用小程序原生写法来进行开发。
后续，也用过一些其他的框架，比如 MinUI 。
和 MinUI 相比，WePY 给我来说最大的感受是提供了 promise 的支持和 async/await 的支持，这个支持可以极大的改善 JavaScript 编程时遇到的 Callback Hell 的问题，可以让我们更加愉悦的开发。
此外，我比较看重的特性是支持外部的 NPM 包，支持 NPM 包意味着可以更好的使用 JavaScript 原本的工程化的产品，也是大大提升生产力的特性。不过，相比于 Promise 的支持和 async/await 的支持，这个如今已经被微信小程序官方团队所支持的 npm 也显得不那么重要了。
在看文档时注意到，WePY 是使用 wepy init 来进行初始化的，而且可以使用 wepy list 来查看项目的模板。发现了其中有一个基于 ZanUI 的模板。
由于 ZanUI 及更名后的 VantUI 我都比较熟悉，所以从他下手，去研究一下如何制作 WePY 的模板。
复制 repo名/模板名，并在前面加上 github 的域名，就找到了对应的 repo 。
简单的看了一下项目的文件，发现其中并没有什么特殊的，需要指明初始化内容的文件，所以猜测大概率是不需要进行单独的配置的。
这方面 WePY 的文档做的不是很好，我在文档中并没有找到相关的说明。如果可以的话，希望开发者可以加一个功能，比如加上一个 .wepy-template ，可以在里面加入一些交互式的问题，从而来让用户设置一些内容。
在确定了模板其实并不困难以后，我就开始做自己的云开发模板了。
做一个模板只需要三步
说起来简单，不过，在实际制作时，还是应当注意一些问题：
git init 来初始化版本控制。这是因为云开发是与小程序的 AppID 进行绑定的，如果前期没有做好控制，容易出现后续将 AppID 加入了版本追踪。所以在一开始，我就将项目进行了初始化，方便后续的回溯。wepy init 命令将整个过程完整的走一遍。确保你的模板是可用的。在做第一个版本的时候，我是将云函数的目录放在 src 目录下，后续，在运行时发现， WePY 会自动编译云函数的目录，导致出错。不得已，我将云函数的目录放置在了项目的根目录。
当时在研究这部分时，我试图去寻找 wepy.config.js文件的配置说明，希望找到一个 exclude 配置项目，来忽略一部分目录，可惜，我并没有找到。
在使用原生写法的时候，我常常会在 Page({}) 函数外部放上一些引用。比如这样
const database = wx.cloud.database()
const storeCollection = database.collection('store')
Page({
onReady():function(){
// some code
}
})
在 WePY 中我试图将代码放在 Page 实例的内部，不过会导致报错，因此，我不得不废弃这样的写法，改用 constructor 来实现。
export default class Index extends wepy.page {
constructor () {
super()
this.db = wx.cloud.database()
}
onLoad() {
console.log('onLoad')
console.log(this.db)
}
}
在 WePY 中，由于传承了 Vue 的思想，并没有提供对 getApp的 hack ，不过在实际的测试过程中，发现 getApp() 依然可用。
如果不引入 Redux 之类的状态管理工具的情况下，getApp() 的单例模式作为一个全局的 Bus 来进行数据的传递还是非常方便的。
总的来说， WePY 是一个值得尝试的框架，单纯 Async/Await 的引入，可以让你的代码变得更加简洁易懂。特别是如果你的项目需要长期运转的情况下，整洁的代码会帮助你的项目成功。
此外，如果你很习惯于 Vue 的写法，那么 WePY 不容错过，computed 属性还是非常实用的。