前言

早在之前，有收到一个白客的邮件，说我们发送电子邮件的域名缺少安全检查，让我们最好补上对应的安全检查：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

I'm an independent cyber security researcher i have found multiple issues in your website.

Vulnerability : Missing SPF 


I am just looking at your SPF records then found following. SPF Records missing safe check which can allow me to send mail and phish easily any victim.

PoC:

<?php

$to = "VICTIM@example.com";

$subject = "Password Change";

$txt = "Change your password by visiting here - [VIRUS LINK HERE]l";

$headers = "From: https://karve.io";

mail($to,$subject,$txt,$headers);

?>
SPF record lookup and validation for: xxx.com

后面检查了一下，发现确实是这样子，我们的电子邮件没有加上对应的安全检查，很容易被别人冒发，从而有可能对我们的用户造成严重的电子邮件欺诈。

发送欺诈电子邮件的危害

举个例子，黑客可以通过这个站点 emkei.cz 来冒充我们的官方 support 邮箱来发送一些钓鱼邮件给用户。如果用户信以为真，那么就会对用户的利益造成损失，这就是电子邮件欺诈

前言

虽然在之前的文章有写过，怎么在 windows 7 上通过 docker 来实现多个 golang 环境, 并使用了 Go Module:

• windows7 通过 docker 来实现多个 golang 版本并存
• 初试 Go Module

但是事实上在本机进行开发的时候，还是本地环境装的 golang 环境开发起来更方便 (macOS 还好，差别不大，但是 windows 7 的 docker 实在不怎么友好)， 所以就打算将本机环境的 golang 版本升级到 1.13 版本。

升级 golang 版本

查看了一下，发现本机环境装的 golang 还是 1.7.6 这个版本，太老了

1
2

F:\airdroid_code\go\src\resque-worker-server>go version
go version go1.7.4 windows/amd64

前言

前段时间在小组轻分享中，有成员分享了 <项目百态> 这本书的其中一章 <巨神阿特拉斯>, 由于找不到电子版，所以就手动扫描了 这一章 的 pdf 版本, 这章后面提出来一个问题，有一位万能的，包打天下的领导，对团队来说，是福是祸 ？ 肯定是福，但要防止变成祸。本节描述了这样一个场景，并表明福变为祸的原因。不过，本节并没有提出明确的建议，让读者自己去思考。

思考

本来有这种领导对于下属来说是一件非常幸福的事情，但是一定要警惕，千万不能有 “溺爱” 现象，否则就会出现 “巨婴”。正是因为他太万能了，反而影响下属们的自然成长规律，尤其是下属的领导力和管理经验。总的来说，就是不懂得放权，或者是说是不舍得放权。而这就是祸。

对于这一点，我倒是挺有感触的，我接触技术管理也有 3-5 年了。对于放权更有感触，总结这几年的管理上的成长，我最感谢我领导的地方就是他懂得对我放权，允许我通过犯错误来得到成长。当然有一个很重要的前提就是，不要犯愚蠢的错误或者重复犯错。可以犯经验错误，但是有且仅有一次。

前言

之前有时候要紧急调试线上服务器的代码，一般都是用 Xshell 4 等工具，远程登录到服务器，然后直接用 vim 编辑代码。但是对 vim 语法不够熟练，而且有些代码比较长，显示也不太方便。 如果可以像本地 IDE 那样子显示服务器上的代码，并且直接编辑，实时保存就好了。后面找了一下，发现 vscode 配合他的一个插件 remote ssh， 就可以实现这个功能。

安装

做开发的应该没有人不知道 vscode 的吧，号称前端开发神器。 配合各种各样的插件简直无往不利。 首先去 这边 下载一个，因为我是 windows 7 的。所以就下载 windows 的版本了。

前言

通过 初试 Go Module 我们已经能够使用 Go Module 来安装项目的依赖包。 接下来我们试一下我们正式线上的项目，会有没有问题。

映射 ssh 文件夹

我们将一个叫做 resque-worker-server 的项目，放到容器中的共享目录 /go/src/ 中，并初始化 mod:

1

go mod init gitlab.airdroid.com/airdroid_background/resque-worker-server

然后接下来就直接构建 go build, 但是发现报错了:

前言

最近打算把服务端的一些 Go 服务升级到 1.13, 并且用上 Go Module 这个 Go 的第三方包管理机制。 虽然早在 Go 1.11 版本发布的时候，就推出了 Go Module 这个机制了，但是毕竟那时候还在跟 Go dep 撕逼呢, 而且是第一个版本出来的新机制，有点不敢用，怕入坑之后爬不出来。 一直等到了 1.13 版本，这个机制已经相对成熟了，而且几乎取代了 vendor 机制了，也被广大 gopher 接受了，所以是时候升级上来了。而且升级的代价其实不高，因为 Go 的版本发布几乎都遵守Go1兼容协议, 也就是说我们几乎不需要改代码依然有很大的概率可以编译成功(事实上改动的确实不多，无非就是针对 Go Module 机制，将一些第三方依赖的引用进行调整，具体的业务逻辑几乎不用动)。改动成本那么低，又可以告别 Go path, 采用更加优雅的 Go Module, 何乐而不为，所以本文主要是讲一下 Go Module 的一些简单试用。

前言

前面讲了很多关于 air-ui 组件的东西，包括多语言，主题定制，构建等等。但是其实一个组件库包含那么多的组件，在开发的时候，难免会遇到很多奇奇怪怪的问题，本节就讲一下在开发这些组件的时候，遇到的一些问题，以及怎么解决。(虽然很大程度上复用了 element-ui 的组件逻辑代码，但是难免还会有其他的坑)。

兼容 jsx 语法

之前在处理 jsx 语法的时候，有报错：

1
2
3
4
5
6
7
8
9
10

const wrap = (
  <div
    ref="wrap"
    style={ style }
    onScroll={ this.handleScroll }
    class={[this.wrapClass, 'air-scrollbar__wrap', gutter ? '' : 'air-scrollbar__wrap--hidden-default']}
  >
    { [view] }
  </div>
);

前言

在 自建vue组件 air-ui (14) -- 打包构建(dev 和 dist) 我们已经知道 air-ui 的 dev 构建 和 dist 构建。 接下来我们讲一下为啥还需要一个 pub 的构建任务，以及这个任务是用来干啥的。

直接将 master 分支作为第三方库拉取的分支

假设我们没有 pub 任务。直接就使用 dist 构建生成 lib 目录，然后将代码提交到 master 分支，并且用 master 打了一个 tag。
这时候我们就可以在某一个项目上用这种方式去加载 air-ui:

1

"air-ui": "git+ssh://git@gitlab.xxx.com:web/vue-ui.git#v0.0.4",

然后我们很顺利引用了:

1
2
3
4

import AirUI from 'air-ui';
import 'air-ui/lib/styles/index.css';

Vue.use(AirUI);

前言

UI组件的一个很重要的功能，就是允许可以定制化主题。 而且这也是为啥写组件的时候，要把对应组件的 scss 样式抽出来，不让其打包到 air-ui.common.js 的原因，这个原因就跟语言包为啥也要抽出来，不打包进去的原因。因为这样会增加 air-ui.common.js 的体积，而且我们要使用定制化主题的话，或者使用其他语种的，原有的打进去的默认主题和默认语种，就都没有用了。 所以这也是为啥当我们引入 air-ui.common.js 的时候，也要同时引用 css 文件的原因，因为 air-ui.common.js 并没有包含样式。

var.scss

为了更好的提供组件主题定制，我们规定所有可定制化的参数，全部写在 var.scss, 也就是说，假设我新做了一个组件，叫 dropdown, 并且我希望他有几个样式可以被定制化，那么就可以把参数写在 var.scss 文件里面 (这个文件不涉及到具体的 class 样式，全部都是参数), 那么就可以在这个文件加上以下参数：

1
2
3

$--dropdown-menu-box-shadow: xxx !default;
$--dropdown-menuItem-hover-fill: xxx !default;
$--dropdown-menuItem-hover-color: xxx !default;

前言

本节主要讲一下 air-ui 的打包。 air-ui 的构建主要分为 3 个环境:

1. 本地开发环境 dev
2. 打组件包 dist
3. 打 pub 包并打 tag pub

本节主要是讲一下前两种方式， dev 和 dist, 至于最后的 pub 方式,因为遇到的坑比较多，所以会再开一节来讲。

前言

通过上节 自建vue组件 air-ui (12) -- 国际化机制 我们已经知道怎么在 air-ui 进行国际化配置了。但是还遗留几个问题没有解决：

1. 我们现在是有默认引入 zh-CN.js 这个文件的，这样会导致我们后面打包出来的 air-ui.common.js 体积变大，我们要怎么将之抽出来？？
2. 组件单独打包出来的话，引入的时候，要怎么接入多语言机制？？

将语言包文件引用单独抽出来

我们知道在打 air-ui.common.js 包的时候，之所以会把语言包的 zh-CN.js 打进去是因为，只要入口文件有引用的话，那么默认就会打包进去，打包链是这样子的：

前言

air-ui 组件库的某些组件也会用到一些提示语，除了允许用传参来自定义之外，肯定会有预设值。 比如 air-select 组件的时候，可以允许搜索的，

如果搜索不到，会有一个默认提示： 无匹配数据， 这个就是这个组件的其中一个提示语预设值。而且这个预设值其实是中文。接下来我们看看是怎么实现的？

前言

通过上节 自建vue组件 air-ui (10) -- vuepress 写文档 (进阶版) 其实关于 vuepress 写文档的事情，也基本上能说的也差不多了。本节主要是在这个基础上再进行一下补充，将一些在 air-ui 组件库写文档中遇到的一些奇葩的问题，以及怎么解决的，这个也列一下，做一下备忘录。

第三方库 Popper 的报错

之前有遇到一个很奇怪的情况，就是写autocomplete demo 的时候，在本地运行中，是可以 work 的：

而且打包到另外一个项目用第三方库的方式引用，也是可以的：

1
2
3
4
5
6
7
8
9
10

<air-col :span="12">
    <div class="sub-title">激活即列出输入建议</div>
    <air-autocomplete
            class="inline-input"
            v-model="state1"
            :fetch-suggestions="querySearch"
            placeholder="请输入内容"
            @select="handleSelect"
    ></air-autocomplete>
</air-col>

但是一旦放到 vuepress 文档里面，就会报错？？

前言

通过上节 自建vue组件 air-ui (9) -- 用 vuepress 写文档 已经会写 button 标签的文档了。 并且写了 7 个例子用来描述 button 和 button-group 的属性，所以最后的 Button.md 的代码如下:

还是很详细的，具体文档效果上一节的最后有 gif 截图显示。 接下来我们继续写其他已完成组件的文档。

内置服务组件的文档怎么写？？

那么问题来了，对于标签组件的文档，我们还可以当做局部组件来引入。那么这种内部服务组件呢，或者指令类型的组件？？ 要怎么引入？？ 毕竟在 vuepress 环境下，可没有像 air-ui 项目那样，可以在 main.js 对组件库进行全局注册？？ 那么怎么找到 vuepress 的 vue 对象呢 ？？

前言

从前面的章节中，我们知道怎么创建组件，但是我们测试组件属性的时候，都写在 home.vue 中，而且只有 demo，没有配上对应的属性描述。所以接下来我们要做的就是开始为这些已完成的组件来写文档。

element-ui 的文档

我们可以看到 element-ui 的文档还是写的非常好的。

不过他这个文档的项目，其实就是他们自己写的。感兴趣的可以自己去看代码，就在源码项目的 examples 目录，执行 yarn dev 就可以把这个站点跑起来。它有例子也有对应的代码和注释。可以说非常的清晰。但是不适合 air-ui, 原因有两个:

1. 自己从头再去搞一个文档项目，性价比太低了，没有那么时间。
2. 他们是先写 demo 代码，再把代码通过 markdown-it 编译成 vue 文件，然后再嵌进去的，而且样式也是写在一起的。导致后面如果要新加一个组件的说明文档，得去调代码，调完代码再写进去。无论是扩展还是维护，其实成本都不低。

所以总的来说，看起来效果不错，但是真的不适合我，性价比太低。可以先看一下，最后 air-ui 成形的文档效果：

前言

在之前的文章中，我们已经知道怎么去创建一个组件了，并且怎么初始化，但是有没有发现一个细节，就是 element-ui 除了完整引入的方式，比如:

1
2
3
4

import ElementUI from 'element-ui';
import 'element-ui/lib/theme-chalk/index.css';

Vue.use(ElementUI);

还支持按需引入的方式：

1
2
3
4
5
6
7
8

import { Button, Select } from 'element-ui';

Vue.component(Button.name, Button);
Vue.component(Select.name, Select);
/* 或写为
 * Vue.use(Button)
 * Vue.use(Select)
 */

听说这种方式可以减少项目体积。 如果本节讲一下 air-ui 怎么做到按需引入。

前言

通过 自建vue组件 air-ui (5) -- 创建第一个组件 Button 和 自建vue组件 air-ui (6) -- 创建内置服务组件 我们知道怎么创建标签组件和内置服务组件了，这一节我们来讲讲怎么创建指令组件。

这次我们做 loading 组件，还是拿 element ui 的 loading 来参考， 它这个组件有点意思，有两种调用方式：

1. 全局指令方式
2. 全局方法的服务方式

这个其实就告诉我们，只要你想，一个组件可以有不同的表现方式，不管是标签方式，还是指令，或者服务方式。 我们先看下目录结构：

1
2
3
4
5
6
7

components/
|    |--- loading/
|    |     |--- src/
|    |     |     |--- directive.js
|    |     |     |--- index.js
|    |     |     |--- loading.vue
|    |     |--- index.js

从目录结构来看，应该很好理解。 .vue 结尾的是 dom 渲染， directive.js 是指令封装逻辑， index.js 是服务的封装逻辑。 根目录下的 index.js 是导出的方式

前言

通过 自建vue组件 air-ui (5) -- 创建第一个组件 Button 我们已经知道怎么创建一个标签类型的组件了。本节我们就继续讲怎么创建服务类型的组件。

创建服务类型的组件

以 notification 这个组件为例，他就是一个典型的内置服务组件。其实就是绑定到Vue的原型上，当做全局方法来使用。

设置 vue 的全局方法其实很常见，比如发 ajax 请求时喜欢用axios挂载到vue原型上，如下：

1
2
3
4
5
6
7
8

// 1 引入vue和axios
import Vue from 'vue'
import axios from 'axios'
// 2 对axios的一些封装
// code ...

// 3 然后挂载到原型上
Vue.prototype.$axios = axios

用的时候就直接上 this.$axios

1
2

// 用axios.get()方法可以这样用
this.$axios.get()

前言

通过 自建vue组件 air-ui (4) -- air-ui 环境搭建和目录结构 我们已经搭好了 air-ui 项目，接下来就是开始写组件了。

ui 组件的三种类型

常见的 ui 组件有三种类型：

标签类型

这个是最常见的组件类型，比如 button， checkbox 等等， 使用的时候是这样子的：

1

<air-button>这是一个按钮</air-button>

内置服务类型

内置服务类型的组件，其实就是绑定到 VUE 的全局对象中，比如 message， notification， loading，使用方式是这样子的：

1
2
3
4

this.$message({
  message: '警告哦，这是一条警告消息',
  type: 'warning'
});

前言

前面花了两个篇幅来详细分析了一下 element-ui 这个项目：

• 自建vue组件 air-ui (2) -- 先分析一下 element ui 项目
• 自建vue组件 air-ui (3) -- css 开发规范

终于进入到 air-ui 的篇幅了。其实前面已经说过，在组件逻辑方面 和 css 方面，element-ui 做的很好，我也挑不出大毛病，而且它们也不是我要重写 ui 组件的主要原因。air-ui 主要还是以下几个方面跟 element-ui 有比较大的差异，也主要是以这些方面来写文章：

1. 目录结构
2. 文档方面
3. 构建方面
4. 主题定制
5. 多语言方面以及在整个过程中，遇到的一些坑

本节主要讲 air-ui 环境搭建和目录结构。