我还没有见到哪个开发者在看到代码冲突而不沮丧地扯头发的。
解决每个代码冲突是每个开发者都讨厌的事情之一。尤其是当准备进行生产部署时遇到了这种情况！
设置正确的 Git 工作流可以为我们的开发工作流带来很多好处。
当然，拥有正确的 Git 工作流程并不能解决我们所有的问题。但这是朝正确方向迈出的一步。毕竟，团队都是协作工作的，所以在不破坏代码库的情况下一起构建功能是非常重要的。
Git 工作流的设置方式取决于我们正在处理的项目、团队的发布计划、团队的规模等等。
在本文中，将介绍 5 种不同的 Git 工作流程，它们的优点、缺点以及何时使用它们。
让我们开始吧！
再过一周就要征战百公里了。
长距离越野，除了好好的进行赛前拉练，在赛中我最关注的就是电解质补给了。
最近将手上的一个域名备案了，就将博客迁回到到国内的服务器上了，这样大家的访问的速度也可以快一些了。
因为换域名会影响搜索引擎收录、网站权重和 SEO 排名，所以除了将域名换上，我们还有一些额外的事情要做，否则网站的流量就像图上这样蹭蹭往下掉。
three years on
hope one everyday is a good day
without Numb, care One More Light forever
via youtube
今天把博客迁移到了新域名，顺便把 node.js、Hexo 和主题都升了下级。
当习惯的运行 hexo s 命令时，发现多了些 warnings，如下：
$ hexo -s
(node:87224) Warning: Accessing non-existent property 'lineno' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)
(node:87224) Warning: Accessing non-existent property 'column' of module exports inside circular dependency
(node:87224) Warning: Accessing non-existent property 'filename' of module exports inside circular dependency
(node:87224) Warning: Accessing non-existent property 'lineno' of module exports inside circular dependency
(node:87224) Warning: Accessing non-existent property 'column' of module exports inside circular dependency
(node:87224) Warning: Accessing non-existent property 'filename' of module exports inside circular dependency说实话我对 node.js 没啥了解，但是单词还是认识几个，看起来像是循环依赖的问题。（习惯性想起了一道面试题：Spring 是如何解决循环依赖的？）
这些 warnings 其实对 Hexo 程序运行没啥影响，只是看起来不舒服罢了。
但出于好奇和洁癖，就去 google 了一下。这里来总结一下原因及解决方案。
用 Docker for Mac 已经很久了，用它跑本地开发环境可以说是非常方便。
但是 Docker for Mac 自诞生以来就一直有一个问题，那就是在宿主机上看不到 docker0，无法访问容器所在的网络，也就是说不能 ping 通 Docker 给 Container 所分配的 IP 地址。关于这个问题，官方文档有描述：Known limitations, use cases, and workarounds
对于 docker run 启动的 Container 来说，通常会通过 -p 参数映射相应的服务端口，一般不会遇到要直接访问容器 IP 的情况。
但是当我们在 docker 中运行多个微服务并想进行本地调试的时候，在 Mac 上却没法实现。（--net=host 仅在 Linux 系统上有效，我在这个上边被坑了两三个小时 [捂脸] ）
例如上图中，Eureka Server 和 User 服务均存在于容器中，本地调试 Order 服务。Order 需要调用 User，但是我们在本机上是访问不到 172.22.0.3:8080 的。
快与好，实际上是我一直比较矛盾的。虽我不是处女座，但是也有一些些强迫症，比较追求完美。至于速度，我是个急性子，快是没的说的，这点从我的网名“逐风”也可以感觉出来。
但一直不知道如何平衡。
前两天看到阮一峰《科技爱好者周刊》上的刊首语，使我陷入了思考。
一件事“做得好”比较好，还是“做得快”比较好？
鱼和熊掌不能得兼，你怎么选择：做得好，付出的代价可能是耗时长、成本高；做得快，意味着完成度低、不是精品。
他推荐了一篇文章，那篇文章观点简单来说就是
做得快不仅可以让你在单位时间内完成更多的工作，而且 因为你工作得很快，所以你会觉得成本低，从而倾向于做更多。
写一篇博客，你可能需要两天。这是很高的时间成本，你觉得太贵了，于是你很少写。但是，做好一件事的唯一方法，就是多做这件事。做得越快，这件事的时间成本就越低，你会愿意做得更多。
人们总是倾向于，多消费时间成本低的东西。网站很快，就会多访问；搜索很快，就会多搜索；文章很容易读懂，就会多读几篇。做得快的核心，就是要让时间成本降下来，从而多做。
文章的原文是英文的：Speed matters: Why working quickly is more important than it seems
就决定自己试着翻译一下。
一方面抱着为自己解惑吧，另一方面最近也一直在学习英语，当做练习了。（第一次翻译，轻拍~~）
前一段在关闭 IDEA 打开 GoLand 之后，深深感慨了一声
丝滑般享受
但没想到声音刚落，就发现又掉坑里了 /(ㄒoㄒ)/~~
{
"foo": "Hello, World!",
"bar": {
"b": {
"go": "1"
},
"a": {
"go": "2"
},
"c": {
"go": "3"
}
}
}有如上一段 JSON，在程序中需要将其转为一个结构体以方便读取里边的数据，struct 的定义大概如下：
type Foobar struct {
Foo string `json:"foo"`
Bar map[string]struct {
Go string `json:"go"`
} `json:"bar"`
}现在有这么两个需求：
bar.a、bar.b、bar.cbar.b、bar.a、bar.c如果是用 Java 的小伙伴，肯定已经想到 SortedMap（用的比较多是 TreeMap）和 LinkedHashMap 了，前者是可以按 key 进行排序的，后者则可以保持键值对的插入顺序，而这两者都是 JDK 自带的，任何一个 Javaer 应该都使用过。
但是在 Go 语言的“简约设计”面前，这些都是不存在的——Go 只提供了最基础的 hash map。
并且，在借助 range 关键字对 Go 的 map 进行遍历访问的时候，会对 map 的 key 的顺序做随机化处理，也就是说即使是同一个 map 在同一个程序里进行两次相同的遍历，前后两轮访问 key 的顺序也是随机化的。(可以在这里验证：https://play.golang.org/p/s3Mj4gNfi4g )
在 Go 的官方 blog 的文章 Go maps in action 也确定了该现象确实存在，并且是有意而为之，
When iterating over a map with a range loop, the iteration order is not specified and is not guaranteed to be the same from one iteration to the next. Since the release of Go 1.0, the runtime has randomized map iteration order.
那么在 Go 里边实现以上需求就得绕些路了。
之前说过 Gateway 的路由配置，常用的有两种方式：
这两者之间因为配置文件的方式修改起来比较灵活，然后通过 Stream+Bus 的方式刷新路由配置，所以大家使用的比较多。
但是如果我们在网关层需要类似于 Canary Release（金丝雀发布，也称灰度发布）这样的能力的话，那么以上两种配置路由的方式就都显得太笨拙了。
矿井中的金丝雀
17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为 “瓦斯检测指标”，以便在危险状况下紧急撤离。