功能描述​

我们在写 Shell 脚本的时候有时需要向外输出一些信息，默认 Shell 的 echo 只能输出默认色调的字符串，而终端的颜色语法可读性不是很好，运维工程师可以用这样的插件提供各种颜色的终端输出。

PS: 这里当然有很多种解决方案，这里仅仅是 Semo 给大家提供的解决方案。

前言​

上一篇准备了两年的 Semo，今天正式跟大家见面中，已经首次跟大家介绍了 Semo，相信大家看完之后应该还是一头雾水，不知道 Semo 到底是个什么东东，为什么要用，有学 Semo 的时间，自己不是也可以撸出一个命令行工具么？所以，本篇还是不打算讲 Semo 的原理，还是再讲讲应用吧，今天给大家讲讲另一个用 Semo 写的插件：semo-plugin-read。

背景​

相信很多小伙伴对掘金都是大大点赞的，里面有各种大神，大牛写的长文教程，极大的降低了新手入门的门槛，面对一篇又一篇长文，你是否有收藏的冲动呢（比如收藏到有道云笔记）？虽然网上有各种文摘工具，但是还是想要 Markdown 版本，不像语雀，掘金貌似拿不到原文 Markdown，所以，这就是今天介绍的插件的开发初衷，当然实际开发以后就有点收不住了，:)

每隔一段时间都能看见新的讨论命令行工具的文章，大家都在探索怎么用 Node 开发一个命令行工具，并热情的分享 npm 社区若干优秀的和命令行开发有关的 npm 包。从学习的角度当然也不错，但我一直觉得怎么开发命令行工具不是最重要的，而是开发具体有用的命令行工具才是最重要的。

我在 3 年前开始从事 Node.js 开发，去了一个不把 Node 当做胶水而是全 Node 后台架构的公司，对于微服务架构来说，那后端的小项目就多了去了，每个项目，甚至一个项目里不同的开发者写的命令行工具（还有一次性脚本和计划任务）可能都是一套自己的设计，我当时想做一个简单易用，侵入小的方案，统一微服务架构下各个项目实现命令，脚本，计划任务等的实现规范。最终形成了 Semo 这个项目，我打算写一系列的文章跟大家分享 Semo 的原理和用法。

一个简易的 HTTP Server 工具，类似的工具有很多，包括但不限于：

• http-server
• serve

还有一些工具，比如 hexo，本来是个博客工具，也自带了 HTTP Server 的功能，umi，本来是个前端开发脚手架，也自带了启动 HTTP Server 的功能，当然，还有大名鼎鼎的 create-react-app 等等，而且 node 本身写一个简单的 Web 服务器也不是很复杂，那为什么还要去做一个新的轮子呢？

为什么造这个轮子​

其中一个原因是看到了一个项目 osgood，其实现了基于命令行工具快速定义路由和控制器的思路。另外，由于 Semo 做为一个命令行开发框架，其价值就是按需封装各种各样的命令行工具，而且其命令，脚本都有相对统一的模块风格，那就是基于约定导出固定变量用于固定用途的约定大于配置的思路。将二者结合就形成了这个新的 HTTP Server 工具，其 Web Server 部分基于 koa 及其中间件实现，定制性较强，这个轮子主要就是制定规则，提供相关语法糖。

感谢 Koa 的简洁和灵活，我们可以按需定制所需要的特性，本程序使用 Koa 来实现 Web 服务以及各种扩展功能

特性​

• 同时支持静态资源服务和后端接口服务，
• 后端服务，目录结构就是路由结构
• 后端服务路由可以灵活配置，内置了参数验证机制
• 后端服务可以引入全局中间件和单个路由中间件，也可以禁用内置中间件
• 支持一些个性化选项，个性化选项也都可以在配置文件(.semorc.yml)中设置
• 支持端口占用自动检测
• 支持和 SPA 模式和 404 模式

安装​

npm i -g @semo/cli semo-plugin-serve

使用​

semo serve [publicDir]

simple server tool

选项：
  --port, -p                                    server port                                              [默认值: false]
  --list, -l                                    list routes
  --init-koa, -i                                initial koa application                                  [默认值: false]
  --api-prefix                                  prefix all routes                                       [默认值: "/api"]
  --spa                                         fallback to index.html
  --gzip                                        enable gzip
  --routeDir                                    routes location
  --publicDir                                   static files location
  --file-index                                  index file name                                   [默认值: "index.html"]
  --file-404                                    index file name                                          [默认值: false]
  --disable-internal-middleware-custom-error    disable internal middleware custom error
  --disable-internal-middleware-custom-static   disable internal middleware custom static
  --disable-internal-middleware-custom-router   disable internal middleware custom router
  --disable-internal-middleware-koa-logger      disable internal middleware koa-logger
  --disable-internal-middleware-koa-bodyparser  disable internal middleware koa-bodyparser
  --disable-internal-middleware-koa-kcors       disable internal middleware kcors

命令行使用说明​

路由代码生成器​

借助于 Semo 提供的统一的代码生成入口和扩展性，我们实现了一个简单的路由代码生成器

semo make route a/b/c

查看声明的路由地址​

semo serve --list

启动服务​

semo serve [publicDir]
semo serve # 默认当前目录

watch 模式​

借助 nodemon 模块

npm i -g nodemon
nodemon --exec 'semo serve'

路由系统说明​

一个路由的样子​

完整版​

export const name = "signup"; // 给路由起个名字
export const method = "post"; // 支持各种 HTTP 请求方法
export const path = "abc"; // 自动添加到路径路由的后面
export const middleware = []; // 为单个路由指定前置中间件
export const validate = {
  // 请求参数验证
  username: "required",
};
export const handler = async (ctx) => {}; // 路由回调

简单版​

export = async ctx => {}

ctx 的约定用法​

关闭默认的 json 响应格式​

ctx.json = false;

自定义错误码​

这里要注意的是抛出的错误码必须经过定义

ctx.errors[10001] = "自定义错误消息";
// 或
ctx.error(10001, "自定义错误消息", 405);

throw new ctx.Exception(10001, "重写错误消息");

Mock 数据​

命令内置了 mockjs 库，只需要通过 ctx.Mock 和 ctx.mock 就能访问，ctx.mock === ctx.Mock.mock。

gzip 压缩​

当选项 --gzip 设置为 true 以后，默认凡是内容类型包含 text 的响应都会进行 gzip 压缩，如果想关闭可以在路由响应函数里进行如下操作：

module.export = async (ctx) => {
  ctx.compress = false;
  // 或
  ctx.gzip = false;
};

路由前缀​

我们默认的路由前缀是 /api，因为默认的使用场景是前端静态目录和后端动态接口都支持，如果仅仅是使用后端功能，可以改写前缀，或者清空前缀。

特殊的路由​

index 文件名的路由在我们对路由的理解里有特殊含义，因为我们一般不需要一个路由这样访问：/api/a/b/index，而只需要是 /api/a/b，所以如果我们不是将路由实现在 b.js里，而是b/index.js，效果是一样的。

SPA 模式和 404 模式​

只要在启动时加上 --spa 选项，不存在的路径就会指向默认的 index.html，需要注意的是 --api-prefix 选项指定的 API 前缀下的路由即使找不到也只是会抛出路由不存在的异常响应，而不会指向 index.html，这么做的目的是为了同时支持前后端的使用场景。

如果不使用 SPA 模式，并且配置了 --file-404 选项，比如 404.html，则所有不存在的 404 静态资源都会使用这个配置的静态页面进行输出，如果设置为 false 关闭了这个选项，则会输出为 Not found 字符串。

中间件的禁用和扩展​

通过工具提供的选项可以看出，所有内置的中间件都可以禁用，而且可以通过 --init-app 的选项注入一个模块来添加更多的中间件，两个特性一起使用的话，可以完全自定义 koa 所需要的所有的中间件，当然如果是这么做的话，那本工具也就没必要使用了。

// init-app.js
// semo serve --init-app init-app.js
module.exports = (app) => {
  app.use(async (ctx, next) => {
    await next();
  });
};

APIs​

如果不想用 Semo 来调度也可以直接已模块的方式引入，参数可以参考命令行选项

import { startServer } from 'semo-plugin-serve'

async() {
  await startServer({
    publicDir: '.'
  })
}

Constants​

• SEMO_SERVE_DISABLE_ERROR_STACK=1

最近公司架起了私有容器云平台 Openshift，A 项目作为首个试点项目准备迁入 Openshift。迁入 Openshift 主要需要考虑以下几方面。

1. 新的环境需要分配多少资源

2. 新的环境容器内如何启动

3. 如何平滑迁移

4. 如何方便的查看日志

5. 如何进行线上调试

6. 如何进行热部署

7. 如何回滚

8. 如何处理滚动升级时原容器内未处理完的请求

在进行一些同时包含前端和后端工作的任务时，一般前端会对后端产生接口方面的依赖，以前的做法一般不外乎以下两种：

1. 在接口准备好之前先做其他任务。

2. 前后端约定接口格式，各种形式，口头，邮件，即时通讯，前端也会用各种简单或复杂的方式模拟后端接口，争取做到和后端协同开发。

这两种方式都不是特别好，第一种缺少协同，在之后的对接中可能接口不符合需求，还需要调整时，会由于依赖前端又必须去做其他事情以填补这个空白时间。而第二种虽然可以做到同步开发，但是前端需要额外的工作量去做 Mock 数据的事情，而后端在开发过程中对格式的变更也很难及时的通知到前端。所以为了在前后端分离这样的项目架构下，前后端更好的协同开发，我们需要更好的方法。

为什么从 Git flow 改为 Gitlab flow?​

Git flow 虽然很经典，但是毕竟协作分支太多，要求整个团队对 Git 要有更深的理解，否则容易出现混乱，这里不去具体说明两个分支的优缺点和异同，经过一段时间的试验，我觉得 Gitlab flow 比之前的流程简单，也没有引起任何异常，算是平稳过渡，使用了 Gitlab flow 之后，每个人的效率都有一定程度的提高。

用 Push flow 还是 Fork flow​

选择了 Gitlab flow 之后，还要选择使用 push flow 或者 fork flow，这两种工作流都很好理解，我们是这样考虑的，对于熟悉流程的团队成员，我们采用 push flow，对于新进团队成员，在考察期内，我们采用 fork flow，这样在 merge request 时，纠正一些因为不熟悉流程，规范，代码而引起的错误。一旦新进成员完全熟悉并理解了流程，规范，代码，就可以切到 push flow。

由于业务需要，项目后端除了要实现接口服务之外，还需要支持计划任务，但是由于目前公司的部署方案整个朝着容器云（Openshift）的方向进行，因此生产环境是基于容器启动的，而基础镜像当中是不包含 crontab 服务的，而且运维同学觉得不应该在基础镜像中加入计划任务服务。在这样的前提下，我就要自己去找计划任务的解决方案了。经过几天的研究想过几种不同的方式，最终选定了一种，下面先从被放弃的思路说起。

最近在看 React Native，目的当然是能学到会用来做东西的程度，不过第一步还是想对其有个尽量准确而且深入的第一印象。以下是通过几天的了解之后的一些感受，有可能有不对的地方，请大牛批评指正。

RN 是跨平台原生应用解决方案之一​

如果从跨平台移动 APP 的制作技术来说，从最开始的纯 Webapp，到后面的 Hybrid APP，再到 React Native，React Native 给人一种十分先进的感觉，但同时也要知道的是，这种跨平台应用的技术很早就有了，而且是有很多种。范围缩小到移动 APP 这个领域，在 React Native 出现前后也出现了很多同类技术，比如 Weex, Native Script 等。我们在选择 RN 作为自己的主要学习方向时需要了解各个解决方案的区别和各自特点。

代码评审（Code review）对于提高团队的整体水平，减少 BUG，提高代码质量等方面都很有帮助，唯一可能需要担心的就是可能会对短期进度和效率有一定影响，为了最大化获得代码评审的好处，并降低对效率的影响，现制定以下评审工作流，以后暂时用这个流程执行，并在执行过程中根据体验和反馈不断优化和改进。