趁在隔离的空档期间组了台 NAS，自然而然的安装了 FreeBSD 和将数据拜托给了 ZFS。时间过得很快，回想接触这个系统已经有十几年的时间了。

初次接触 FreeBSD 还是在大学的时候，那时候自己的 MMX 166 笔记本装的还是 Slackware、实验室有台机子装的是 FreeBSD 4。由于次意外的断电，实验室的这台机器由于硬盘故障无法启动，当时作为兼职的运维只能我先去看看能不能解决。

那时候 FreeBSD 直观的印象其实很初步，就是配置方面和 Slackware 差不多，同时也体验到了 ports 的好处，就是至少不用像 Slackware 一样满世界的找 tar.gz 包了。

那时候「水云间」的 BSD 板块还是比较热闹的学术氛围浓厚，上面有各种各样的「奇迹淫巧」各种各样的 shell 脚本和配置文件。那时候的我们年轻而且还气盛，和争论 Vim、Emacs 哪个好一样，争论 GNU/Linux 和 BSD 之间孰优孰劣（现在是 Android 和 iOS 了吗？）也是个老生常谈的问题，热闹看得不亦乐乎。

再往后工作了以后就忙碌了很多，去「水云间」的日子也少了。在本世纪的头个十年，技术方面的发展非常的迅猛，「把玩」技术的时间也不会很多。我的主要系统也从 Slackware 往 Debian 上面迁移到后面买了台 Mac 就一直用 macOS 至今。

FreeBSD 的发展也是一路过来，版本从 4 一直到现在的 12，还是一路保持着 KISS（keep it simple, stupid）原则。当然FreeBSD 的「Simple」其实不是「简单」的意思，而是简洁。

安装好新的系统以及软件包以后，只需要拷贝应用的配置以及 /etc/rc.conf 还有 /boot/loader.conf 就可以直接投入使用。

开玩笑的说，这类的 BSD 系统是努力让管理员尽可能的快的遗忘掉它，因为知道使用 FreeBSD（以及 BSD 系列）的管理员，是知道拿它去做什么的。

所以这也是为什么眼看着份额却越来越低使用得人甚至讨论的人也是越来越少，而 FreeBSD 还存在的原因之一吧，哈哈。

的确 FreeBSD 从学院的背景走出来，很多地方不像 Linux 那么「分裂」以及「随意」，所以在 FreeBSD 安装盘里面有很多「年代感」的文件（所谓的传承？）。

FreeBSD 还是会时不时得给我些「小惊喜」。回到我的那台 NAS 上，我曾经需要给阵列卡加上监控和配置。LSI 厂商其实提供了 MegaRaid 等工具，在 FreeBSD 下其实官方已经提供了 mfiutil 这类的工具可以直接使用，同时参数和命令比 MegaRaid 更加的清晰。

FreeBSD 的在这个方面做得是两个极端，要么就是没有提供任何的支持，要么就是有非常完善的 Manual 以及 Handbook 说明。同理，对于 ZFS 方面的支持也是类似。除去协议方面的问题先不谈，我保守得至今还不敢在 Linux 生产环境下使用 ZFS，这已经是我的个固有的印象，而 FreeBSD 能做到开箱即用。

FreeBSD 的 slogan 现在变成了「The power to serve」。但 Linux 在应用层面 Docker 以及 K8S 等工具完全改变了传统运维的方式，这我在 FreeBSD 下是没有找到任何与之对比的杀手锏的（你问我 Jail？凑合吧…）。

在我看来，未来 FreeBSD 相对 Linux 应该更加下沉，无法让应用开发接触到了。它在底层存储、数据库、防火墙和网关还会继续占有一定的使用场景。对对，如果你说 macOS 甚至 Switch 也是 FreeBSD （或者和它有关系）的话。

FreeBSD 除了在特定场景下的优势，我个人对于 FreeBSD 的情感甚至可以说情怀，也是让我继续使用这个系统的原因。好比上面说的你十几年前的 rc.conf 不加修改扔到最新版本的 FreeBSD 还能兼容一样，当全部初始化时候出现 login 提示，这一切都给人感觉通过时间沉淀已经升华到另外一样东西了。

前几天，在之乎上看到个问题「现在使用 FreeBSD 是一种什么样的体验」、「现在学 FreeBSD 有必要吗」等等，只能轻轻的笑笑。其实，正式知道和使用 BSD 这些系统的人，基本上都是那些已经年过三十正在慢慢失去了折腾的时间和精力，或者已经在办公室里拿着保温杯泡着枸杞看着 KPI 担心脱发的那帮人了吧。

回想起如果那个下午没有意外的断电，可能就不会接触 FreeBSD 更不会有十几年的陪伴。但现在看过来，还是不后悔时间花在每次 /usr/ports 目录下等待 make install 完成屏幕暂停的时候吧。

因为，FreeBSD 以及 Slackware、Makefile、Vim… 等这些名词，毕竟是我的青春呀，笑（

- eof -

在编写内部项目中，往往不同的项目因为历史遗留问题，会有存在多个版本的 golang 编译器共存的情况。

同时，由于 golang 的包管理的短板（虽然在 golang 1.11 以后推出了 go mod），因此不可避免的安装 govendor、go dep 等多个包管理工具，非常的混乱。

本地使用多个 golang 的编译器版本其实更容易造成混乱，同时 env 满天飞也非常不方面维护。解决这块的问题很容易就想到了使用 Docker 去编译和检查本地项目， Docker 官方维护了多个版本的 golang 镜像。

那么考虑的目标是：

1. 使用同一个 Makefile 以及 Dockerfile 去维护项目的编译
2. 因为 golang 1.11 以后官方推出了 go mod，所以尽量使用官方的包管理工具
3. 接上条，老版本的依赖和本地编译使用 go mod vendor 去管理
4. Makefile 不管 golang 编译器的版本问题，编译器版本让 Dockerfile 去管理
5. 本地环境尽量使用最新版本的 golang 编译器，然后导入到 vendor 中

那么这样子，我们可以简单的使用 Dockerfile 去编译执行，例如下面使用编译器版本 golang 1.9.7 类似：

FROM golang:1.9.7 AS builder
# ...
RUN go build .
# ...

但需要注意的是，golang 1.11 之前必须代码在 $GOPATH 中，所以需要映射

ENV GOPATH /go
ENV GOROOT /usr/local/go
ENV PACKAGE ${YOUR_PACKAGE_NAME}
ENV BUILD_DIR ${GOPATH}/src/${PACKAGE}

# ...
COPY . ${BUILD_DIR}

然后在本地使用 go mod vendor 下载依赖包到项目的 /vendor 就可以在老版本中免去使用 dep、govendor 等依赖工具，统一使用官方的 go mod 去管理和下载依赖。

还有需要关注的是 Makefile 需要加个判断，为了增加通用性，建议根据路径判断 golang 的环境路径，而不是判断是否在 Docker 环境下：

# ...
ifneq ("$(wildcard /go)","")
    GOPATH=/go
    GOROOT=/usr/local/go
endif

GO=env $(GO_ENV) $(GOROOT)/bin/go

# ...

build:$(DIR_SRC)/main.go
    @$(GO) build $(GO_FLAGS) -o $(BIN) $(DIR_SRC)

这样子 Makefile 文件就可以同时同于本地高版本的环境以及 Docker 编译环境了。

详细的示例代码可以参看 这个简单的项目（作用只是用于生成随机密码），其中的 Makefile 以及 Dockerfile 。

最后，有个讨论 vendor 目录到底要不要纳入到版本控制中？我个人的看法是看情况，大部分情况下不会将这些第三方代码纳入版本控制中。主要的理由有：

1. 这些代码是第三方库的代码，不会直接更改以及维护；
2. go.mod 以及 go.sum 文件已经保存了第三方依赖的库信息（版本、hash 等等）；
3. 库文件通常会很多，纳入这些的文件会「污染」本地的 git history；
4. 不同于开源项目，我们本地的开发环境是可控的。

所以，类似的 Consul 等比较大型的项目还是会将 vendor 目录纳入到版本控制中，个人认为这也是因为兼容方面的考虑更多些，而如果个本地项目往往环境是可控的。

- eof -

三月即将过去四月份即将到来，很多公司年后的职级晋升安排即将结束。

同时，晋升的结果也将陆陆续续公布出来。几家欢喜几家愁，晋升成功的同事自然值得祝贺，没有过的同事也不要气馁再接再励。

对于技术人员而言，普遍有个很共通的现象，就是往往过于深入技术，忽略了平时对于沟通等所谓「软性素质」的培养和意识，造成可能无法表现出自己真正能力。下面，说说我对职级晋升的一些认知以及经验。

准备阶段

内容控制

通常来说，职级晋升是对去年整年的总结以及回顾，因此从时间的角度上考虑，答辩的内容应该尽量控制在这一年的区间范围内。当然，如果有项目的时间跨度比较长的，应该说明原因同时更需要说明自我在此项目中起到的作用。

往往，主管也答辩人都会犯一个错误，就是将「认为很厉害」的内容和技术点作为答辩的内容，这往往是有偏差的。答辩的内容选题应该从目标职级的角度出发，从目标职级考虑选送的答辩内容是否适合这个职位。

同时，需要根据答辩的时间（自述通常不会超过半小时）来确定选题的数量。因此，答辩的选题是非常重要的，往往选题错误就造成答辩方向的错误。

PPT 是门面

从 PPT 设计的角度上说，技术人员在这块的问题很有典型性，就是往往会将大段的代码（或者截图）贴到 PPT 上。

这会让评委对于内容方面会造成一定的困扰：首先，答辩过程中评委不可能对这块代码进行 Review；其次，从摘抄的这段代码来说也不能体现答辩者应有的水平。

所以，正确的做法应该是觉得需要感觉贴代码解释的地方，尽量贴流程图或者架构图或者 UML，如果还是感觉说不清楚那么建议考虑要不要简化和突出这块想要表述的内容。

技术人员的 PPT 还有个问题就是有太多的文字，这往往会造成表意不清晰。所以，个人的经验就是如果这个 PPT 超过了 200 个字，那么就应该考虑精简。

对 PPT 设计方面的技巧在这块不铺开讲述，网络上已经有更翔实的内容可以找到。

思路和角度很重要

同样的事情，去使用不同的角度去表述，往往返回的结果是不一样的。对于技术人员而言，很容易犯的错误就是将事物「描述得平淡无奇」。这让评委在答辩过程中感觉不到你在这个项目中起到的作用，以及你对这块事物的理解。

例如，有做业务的同学描述了很多对于整个系统的业务以及架构方面的设计，甚至业务的流程是如何流转。但是，根据评委的判断这是团队行为和输出，在答辩的描述中没有体现出其个人对于这个业务的思考和沉淀，以及起到的作用的影响。

所以，对于做业务的同学往往会觉得可能在技术的角度来看，光技术会觉得不够深入。但，换个角度考虑如果结合你对业务的理解，并融合到技术中输出技术的解决方案，那么高度就会不一样。

排练、排练、再排练

答辩的过程和时间是很紧凑的，因此在正式开始答辩前，进行自我排练是非常有必要的。如果条件允许，建议答辩人的主管都能把关一轮，往往在排练过程中就会发现各种问题：答辩人讲述 PPT 的时间、语速以及表达方式能力，等等。

答辩过程中

情绪控制

紧张的情绪能够毁掉所有，甚至让你说话都不利索，尤其作为「相对内向」的技术人员，这块是相对普遍存在的。因此，在答辩开始之前就应该控制和放松自己的情绪，不要过于紧张。

如果过于紧张，这里有个 Tips 可以考虑下：就是作为答辩人你可以认为这是一场技术交流，你尝试说明自己所做的工作以及出彩的地方，让对方觉得自己「很厉害」。

从评委侧也应该给予正向引导，例如答辩人进场的时候打个招呼寒暄一下，也会起到比较好的效果。

节奏控制

答辩开始需要自我介绍，建议两三句话讲重点，千万不要拖泥带水同时夹带不必要的信息。一个失败的自我介绍可能就会毁了整个答辩，毕竟这是你给评委的第一印象。

像上面说的，如果觉得很紧张，那么自我介绍的时候可以稍微刻意放慢下语速，可能会起到调节的作用。

从自我介绍转入到正题的转场口白要自然，如果控制不好演讲的技巧（也不知道应该说什么），那么万精油的一句「下面，我开始我的工作内容介绍」。

在表述 PPT 过程中语速尽量使用中速，前面说的如果排练过那根据内容以及语速，就能找到很好的平衡点。

其实还有个技巧，如果某个技术点很深入或者需要探讨，可以将这个点当作个包袱先抖出来，留给评委后面提问的时候解答。

评委的意图

需要意识到的一个点就是，评委问的所有的问题都有其含义的。如果你的回答让他抓不到他想要的点，那么你的得分会不一定很高的。

例如，当评委问你「这个系统设计的时候，你当时考虑了哪些方面」？这个问题其实反映出两个点：其一，就是你刚才答辩描述的时候没有讲透彻，或者说深度还不够；其二，评委需要个抓手需要了解你对这块的个人理解。

所以，当你回答这个问题的时候，无论从什么角度出发，千万千万不要再介绍业务和系统本身的内容了！应该从自己对这个系统的理解和沉淀出发去阐述自己的理解，如果能表达有一定的输出以及对同事和团队的影响就更好。

答辩后

关注结果、Review 自己

评委对于答辩者的评价是主观的，但是相对答辩的过程其实是客观的。这话说起来可能会有点矛盾，但从「师以质疑，友以折疑」的角度出发， 评委的评价是需要去深入理解的。

对于个人而言，晋升答辩是对过去工作的总结和评价，而不是代表对于未来工作的期待和展望。无论是自我表达的原因，也可能是评委理解不同的原因，评委对答辩者的评价都是不同的，这块需要个人辩证得去理解。

换个角度上考虑，如果你当晋升答辩是一场面试，那么这将是很好理解的一场过程了，而且这场面试的还能看到「面试官」对于自己的评价，何乐而不为呢？

资源和环境

当我们上升个高度去考虑职级晋升的时候，往往就不可避免得聊到职业规划和发展这个老生常谈的问题。

无论答辩的结果怎么样，我们更应该考虑以后的发展。首先，考虑的是个人对于自我提升这块，满足了自我的期望和要求没有；然后，再考虑公司能够提供的环境，能否有个上升的正向上升空间？

能够回答这两个问题，那么自然而然，对于职级这块的理解和态度也就是水到渠成的事情了。

-- eof --