以前，我们使用 reset.css 来完成 HTML 样式的初始化，借助这个 css 文件，可以将多个不同平台，不同系统下的基础组件的样式整合一致。
如今，我们可以使用 Normalize.css 来完成这个工作，也非常简单
yarn add normalize.css
Code language: CSS (css)安装完成后，在 vue 的主文件，引入即可
import 'normalize.css/normalize.css'
Code language: JavaScript (javascript)在使用了 Stylus 编写了小程序的一些样式后，我被这种显然更加简洁的工具折服了。
在新的 Vue 项目中，我希望继续使用 Stylus 来编写样式，只需执行如下代码
yarn add stylus stylus-loader
发现官方没有 plugin ，可以去做一个
在编写代码时，如果你的代码中配置了 ESLint， 而你自己没有运行 ESLint ，可能会导致你的 CI build 失败。因此，在 Commit 前加入格式的修正是很有必要的。
在这篇文章中，我将向你分享，如何使用 Prettier、Husky、Lint-staged 对项目进行 commit 前的格式修复，以及如何配合 Sublime Text 使用。
想要使用 Prettier 进行格式修复，首先，你需要安装 Prettier ，在命令行中执行如下命令：
npm install --global prettier
Code language: PHP (php)然后，在 Sublime Text 中使用 Package Control 来安装拓展 JSPrettier
在 Sublime Text 中唤起 Package Control ，执行 Install Pacakge ，并安装其中的 JsPrettier
你可以在项目的根目录下创建一个 .prettierrc 的文件，然后在其中加入配置项目，具体的配置项目可以参考官方的 Options 页面
比如，如下是我的配置文件
{
"singleQuote": true,
"semi": false,
"tabWidth": 2
}
Code language: JSON / JSON with Comments (json)Options 页面地址：https://prettier.io/docs/en/options.html
当你配置好了配置文件以后，打开 Sublime Text，找到一个 JS 文件，并打开，这时，在代码中点击右键，可以看到一个 JSPrettier Format Code ，点击这一项，就可以自动根据你所创建的配置文件，进行界面的修正了。
接下来，我们来配置 Precommit 的检查
首先，你需要安装 Husky
cnpm install lint-staged husky --dev --save
安装完成后，修改你的 packages.json 文件，在其中添加如下代码
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,json,wpy}": ["prettier --write", "git add"]
}
Code language: JavaScript (javascript)然后保存。这样，就完成了 precommit 的格式检查了。
接下来，你可以随便修改一个文件，然后执行 git commit操作，你可以看到其会输出如下的内容
参考链接：https://prettier.io/docs/en/precommit.html
在使用 Sublime Text 开发 WePY 时，会遇到一个问题, 如何让 Sublime Text 识别 .wpy 文件为 Vue 格式，并进行高亮呢？
你可以这样操作
你可以使用 Package Control 来安装 Vue Syntax Highlight 插件，安装完成后，你打开任何一个 .vue 文件，就会发现代码已经被高亮了，就说明你的你的插件安装成功了。
接下来，你需要打开任何一个 wpy 文件，然后点击菜单栏中的 View-Syntax-Open All Current Extension as…-Vue Component,这样，就可以完成了 .wpy 文件的 Vue 关联，后续，你再打开 .wpy 文件，就会自动使用 Vue 语法高亮插件了。
WordPress 官方出的，用于屏蔽垃圾评论的。基本上每个用 WordPress 的人都会装。
一个用于修改 WordPress 自动发信时的 Sender 和 Sender Email Adress 的插件。
将文章的 Slug 从中文转换为英文的插件。后续我会重写这个插件，更简单使用，以及发布到官方的插件市场。
JetPack 用于古腾堡编辑器中的新 Block
我自己开发的插件，效果可以参考顶部菜单栏中的分享页面。
用于控制自己的文章不要向内产生 PingBack
WordPress 优化插件
WordPress 访问量统计插件
由于要做每日极漫小程序，也就需要其背后的漫画翻译组活跃起来，随之，就需要翻译组背后的工具正常使用，不过 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 的思想，完成重写这个工具。
作为一个 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 后台，可以让我在很长的一段时间内不去关注后台的逻辑，更加专注于前台的开发。
这很好，很敏捷。但是也让我失去了自己开发业务后台的耐性，毕竟，已经有更加简单的实现方式了，为什么还要为难自己呢？
但是，如果你想要认认真真去做一个项目的时候，会发现这种高度简化的代码，让你的拓展性非常的差，你无法更好的去做好自己应该做的事情。
所以，为什么不从一开始就自己写后台呢？虽然慢了点，但是对于你自己来说，也是足够的。随着你自己的开发项目的变多，完全可以做一套你自己的通用后台，完全符合你自己的要求、想法。那才是你真正需要的。
其实，说到开发，就难免会遇到一个问题？
你是想做前端还是想做后端？
在大企业内，前端和后端差距都不大，不过从个人成长角度来看，二者又有所不同。
从技术成长的角度来看，前端和后端的选择并不会影响你最终成为技术大牛。任何一个领域，都有足够多的人不努力，等待着别人去教他们，只要你愿意努力，很容易就超过他们。所以，在这篇文章中，我并不想从技术的角度考虑。
这个想法是这两天在喂羊的间隙想到的。
前端和后端的区别是什么？区别在于前端更接近用户，而后端离用户更远。
在传统的开发模式下，前端切图，生成模板丢给后端，后端加入模板的标签，渲染界面。
在如今的开发模式下，后端提供 API ，前端负责完整的交互、路由等工作，需要花费大量的时间和精力在与用户相关的内容上。这使得前端开发人员，有更多的机会直面用户需求。而后端更多的是面对业务，根据一个个业务封装编写对应的 API，这使得后端无法完整的了解用户的需求到底是什么。
为什么要离用户近？
我见到过很多程序员，他们只关注于技术本身，而不在意产品、业务方面的事情，但是如果你有着自己做点什么东西的想法，那么，就一定要离用户近，接触到用户真实的需求，并去分析，为什么用户的需求产品经理给出的方案却是这个样子的。
离用户更近，离钱更近。
不过，虽然前端可能更适合一个想要自己做事情的人，但是你反而应该先去以后端的身份加入到整个生态中，因为在一开始的时候，你还有足够的精力和热情去研究技术，随着时间的流逝，你对技术的兴趣会越来越小，会花费大量的精力在产品、推广上。所以，前期关注底层的技术，后期关注用户、体验层面的东西。
在过去刀耕火种的编程年代，程序员写代码的时候都是手动创建表
但是，在开发过程中，难免会遇到需要对表结构进行修改，在一些小型团队中，尚且可以通过喊一声，大家都执行同样的操作来完成，确保各自的数据结构的一致性。
随着开发流程的变长、开发人员数目的增多、远程工作的流行，这种方案显然不可行。
因此，就出现了 Migration 。Migration 是将数据库的变化以代码的形式存储起来。一个人在进行数据库修改时，使用 Migration 进行操作，其他人只要执行对应的 Migration ，就可以进行数据库结构的同步。
一个现代化的框架，应该有 Migration。
如果你未指定 Node.js 的版本时，会以 0.10.2 版本 运行，此版本无法使用 const ,所以，需要指定你的 Node 版本。