什么样的小伙伴才是靠谱的小伙伴?

作为公司,什么样的小伙伴是公司需要的呢?同样的,作为公司的员工,什么样的小伙伴才是受欢迎的呢?

提这个问题是因为今天辞退了一个试用期内的小伙伴,而且是属于“送神”的那种。这个小伙伴总结来说就是:不听指挥,不听建议,活在自己的世界里。具体做了什么天怒人怨的事情就不一一言语否则有背后说人坏话之嫌。总之弄到最后是领导极度不满,开发组内最有耐心的同事也拒绝与其交流和协作。公司肯定与做得不对的地方,但是弄得这样人神共愤,该同事的行为真的实属”难得“。而因为该小伙伴,我也和开发组的小伙伴第一时间进行了反思和总结,在避免再次找到此类同事也进行了一些总结,在此谈一下自己的看法。

- 阅读剩余部分 -

nsq教程系列(1)-快速入门

系列说明

看到国内没有相关的翻译,都是些使用者的一些笔记之类的. 为了能够让更多的开发者使用nsq快速搭建消息队列服务,特有此系列. 此系列皆为翻译官网(http://nsq.io),个人水平有限,如有错误还望指出.

- 阅读剩余部分 -

nginx/tengine开启 ssl 后不支持 TLS1.2解决办法

准备把我之前的一个 web 应用弄成微信小程序时遇到了 TLS1.2的问题,翻遍了Google,重新编译安装了最新的 openssl,tengine等各种库,即使开启了 TLS1.2,可是请求时仍然响应的是 TLS1.0。折腾了一个通宵,最终发现果然是自己傻逼了,把自己坑得产不忍赌。

最后问题原来是曾经有一个被废弃的主机箱配置过 ssl,当初配置该主机只设置了支持 TLS1.0。而如果 nginx需要支持 TLS1.2,那么需要将所有主机的 ssl 配置都改为支持 TLS1.2。泪奔~~~

记录在这里,希望能给相同问题的哥们儿有所帮助~~~

因为多说关闭博客评论系统暂时关闭

恩,这个一个悲伤而无奈的故事.

当然, 我指的是多说. 一个没有任何盈利模式的产品能够坚持这么几年着实不容易. 在他们刚开始的时候曾经加过他们官方一个技术的QQ, 从最初5分钟内回复到每次发消息石沉大海我就知道, 多说快死了. 不过却坚持到了2017年, 也算吃惊. 也越来越坚信一个产品再好, 不盈利都是白搭的道理.

从多说导出了所有评论数据, 有时间写个脚本导入到我自己的系统吧. 就这样吧, 加班了...

glide get/update时报Error looking for testing解决方案

在使用glide管理go项目依赖包时,一旦我写了测试用例,再使用glide update/glide get xxx时就会出现下面的错误:

[WARN]  Unable to checkout testing
[ERROR] Error looking for testing: Cannot detect VCS
[ERROR] Failed to retrieve a list of test dependencies: Error resolving imports

很纳闷,testing包难道不是官方包?怎么还会说找不到呢?在Github上发现我并不孤单,于是在相关的issue下面回复了下, 后来发现原来是我自己的$GOPATH下面有一个testing的包,而这个包是我几年前初学golang时直接建立的文件夹,bingo,把testing这个文件夹重命名了一下,问题解决. 附上issue上的解决方案:

  1. check GOROOT before GOPATH in dependence.FindPkg (related to issue #577 )
    If there is "testing" project in GOPATH, pkg "testing" will be found in GOPATH success, "testing" and will be inserted into fetching list.

  2. only deal with first path on GOPATH, skip others
    If GOPATH has more than one paths, "GOPATH=/opt/gopkg:/home/someone/goprj" for example, trying to fetch own private project in goprj is strange. We should only fetch and vendor pkgs in first path of GOPATH.

Linux/Mac下设置SSH跳板机

需求

当我们需要登录某一个服务器集群下的某些内网机器时,需要通过该内网中某一个具有外网权限的机器来做跳板机,实现登录到该内网机中.

- 阅读剩余部分 -

API返回值设计的一些想法

背景

在用golang做一个mockhttp工具的时候模拟请求公司项目的api时发现用golang将请求结果值解析到struct并通过不同的返回值来判断是否请求成功,比如请求某接口成功时返回值:

{
   "name":"Scofield Peng",
   "age":18
}

失败时返回:

{
   "errcode":200001,
   "errmsg":"server error"
}

咋一看觉得很容易处理嘛,解析成相应的struct,看有没有值,omg,不觉得很累?很麻烦?尤其是像golang的json.UnMarshal()函数,如果接口返回错误时用正确时返回值得struct去解析,你还得判断struct是否为空,如果为空,再用错误时的struct去解析下. 太麻烦了好么!!!

- 阅读剩余部分 -