using gomock in TDD
Preface
在golang TDD实践一文中我们领略了TDD method的优美与强大.引入TDD可以极大的提升代码的内部质量和设计水平,从而提升我们的自信,减少恐惧.但如果我们的功能代码依赖外部服务结果时该如何测试呢?假如我们的模块依赖数据库读取的数据,那我们在进行TDD时必须先搭建好DB及初始化好数据么?这很多时候会是一个的负担,阻止我们进行TDD.最好能有种机制能根据我们的test case轻量的模拟外部服务行为,这就是TDD里mock object的意义.
Exploring param passing With Golang's HTTP Context Support
Preface
想像如下场景:
某天,满头大汗的客服同事找到你反馈一个用户详情(PersonDetail)的请求失败了,要求你调查.服务架构如下:
调用顺序解释:
- 前端请求通过HTTP到达gateway节点, 目的是获取person_id的PersonDetail, 包括Name,Address,Education信息
- gateway节点需要从Name, Address, Education后端节点分别获取相关信息
- gateway节点将各个后端节点的response整合成为一个json后,传给前端
在这个过程中,各个后端服务节点都可能出问题导致此次请求失败,该如何查找问题呢?
这时如果有一个请求对应的一个uniqueId,用此可以将系统中这个request串起来:无论在哪个后端节点,只要在日志中过滤此uniqueId,就能找到对应日志,从而最终解决问题.
以上机制其实是分布式微服务系统的”刚需”,没有这种机制,几乎不可能进行有效的日志排查.
接下来看看我们如何在用golang和HTTP实现的系统中实现上述机制.
TCP connection reuse when HTTP in golang
由Too many open files问题看system limit
Preface
本文的缘起是作者写的golang服务,某天发现日志报错: socket: Too many open files, 定位到出问题的行:
1 | import "http" |
系统初始化时,会发起约1500余次http请求,看错误提示应该是http client在open socket时打开文件过多,超出系统限制, 但是通过linux命令ulimit将支持最多打开的文件数限制到65535, 仍是会报此错误.为什么限制远大于程序需要仍会发生这种错误? 如何修复这种看似毫无头绪的错误呢? 我们一步一步来.
golang TDD实践
Preface
如果我们每天的工作就是喝着咖啡,嚼着零食,惬意的写写代码,按时回家。对写好的代码充满信心,不需要时刻担心自己的代码线上是否会出问题,不担心局部小小改动会以意想不到的方式引起故障;让别人一提起你都会说:这家伙的代码,No Problem。相信会让我们的人生幸福指数提高不少,然而现实情况却not even close,让人苦恼。
TDD(Test Driven Development)在实践中被证明是一种很有效的软件设计/开发方法,它不一定会让我们的梦想全部成真,但起码,带来了希望。
本文是作者在golang中学习TDD方法的一个总结:首先概括了TDD要素,然后讨论如何用基于golang的testing框架实现基本的TDD,并给出了例子:如何在解决leetcode问题时应用TDD
漫谈Url Encode
Head First Golang Sort
一题两解:一道leetcode问题的DP和Greedy解法
Preface
DP(Dynamic Programming)和Greedy算法,区别于具体的算法,是algorithm paradigm,可称为算法思想,被用来求Optimization类问题,这类问题用一般方法解决起来颇有难度,而且常常复杂度太高。DP和Greedy会让不熟悉的同学有所畏惧。
DP和Greedy都需要专题性的练习,本文由一道具体的题引出DP和Greedy解法,读者可以基于这个具体的问题来了解两种算法思想的应用,以及对比两者对于解决同一道题目的不同,加深对两者应用场景的认识
为什么要学习DP和Greedy?
- 在技术面试中如果能展示DP和Greedy求最优解一般都会给自己带来加分,这也是本人学习DP和Greedy的直接动力。
- 很多常用算法都采用了DP和Greedy思想,参见这里,熟悉DP和Greedy思想更容易理解这类算法