最近发现了一个有意思的项目 pRESTd ，可以将 PostgreSQL 数据库的操作转换为 RESTful API 请求，虽然暂时没有 100% 做到对 SQL 语句的支持，但通过 http 请求的方式提供了比 psql 控制台和代码更为轻量更为灵活的方式，根据他们官方文档的介绍， prestd 也支持类 PostgreSQL 的其他数据库，诸如 TimescaleDB 和 Redshift 。 其实，市面上很多数据库都原生支持 RESTful API ，允许用户以这种简单的方式进行有限的数据库访问及操作，比如说 Snowflake ， CockroachDB 和 TigerGraph ， pRESTd 的出现恰好为 PostgreSQL 这种更为流行的数据库补齐了这块短板。 限于篇幅，本文仅涉及 pRESTd 的环境准备和安装过程。 环境需求 PostgreSQL 数据库，我本地的
Cobra 是一款非常流行的命令行生成工具，由 Go 语言实现，比如说著名的博客工具 Hugo ， GitHub 命令行等都是用它实现的。 一直以来我只是闻其名，却没有真正用过。最近入职了新公司，简单熟悉了新组的代码库之后，发现整个框架就是用 Cobra 搭起来的，虽然本质上是各种复杂的服务，但 Cobra 可以为用户提供一套非常简单有效的命令行工具来操作它们。因此借着这个机会，趁周末放假，我在自己的机器上实现了一个简单的命令行工具来计算输入的数学表达式，以此来熟悉一下这个大名鼎鼎的命令行构建工具。 需求 需求很简单，输入一段数学表达式，能够输出正确结果，比如说 1 + 2 得到 3 ，支持加减乘除和指数计算，包括小括号。 因为只是练习之作，这个小玩具就简单粗暴地命名为 suan ，取汉字“算”的拼音。 环境 我的 Go 版本如下所示， » go version go version go
谈笑风生又一年 我们从混乱无措的 2020 年到了平淡乏味的 2021 ，眼下终于也要揭过去这一页，回望过去的一年，突然发现我的这篇小文章都是多余的，因为值得一提的地方实在不是很多，但按照传统，还是水一篇吧。 生活终于从过去的两点一线彻底变成了一个奇点，休闲、工作、购物、吃饭基本都可以在方圆 300 米之内搞定。很多时候都不需要考虑开车的事情，最远的一次出门是开到车管所续新的驾照，为节能减排，低碳环保做出了重大贡献。翻翻账单记录，上次去加油站还是在九月份，飞涨的油价似乎影响到了我，又似乎没有影响。 本以为在疫苗的加持下，我们可以度过疫情，恢复以前的正常生活，但国外抗疫的无能养出了 Delta 变种和 Omicron 变种，使得本来有些向下趋势的曲线一飞冲天，然而与去年的封城宵禁不同，至少在美国，很多人的眼里已经没有了新冠病毒，仿佛疫情从未出现过，照常生活，照常养蛊，美国的疫情早已失控，
要理解递归，先得理解递归 发现问题 函数的递归调用是码农在日常工作中不可或缺的利器，在某些问题上，函数递归可以提供更为简洁的代码实现和更为直观的阅读理解，比如说我们很熟悉的树形结构的遍历。 然而，当函数调用的层数过多的时候，就可能导致著名的 Stack Overflow 错误，而栈空间一般是由编译器（ C/C++ 等）或者 Java 虚拟机（ Java 系语言）来管理，对程序员是不可见的，当然我们可以通过配置参数来调整程序的栈空间大小，但不免麻烦，并且递归层数一增加，栈很可能又要溢出。 尾递归是一个常用的优化方法，很多语言在执行的时候会识别这种优化，因为递归函数调用是一个函数的最后一步，所以在递归调用之前，就可以把当前函数调用从栈中弹出，再把新的函数调用压栈，这样就不会因为递归深度的增加吃掉栈空间了。 但尾递归并不是很容易就能实现的，用二叉树的中序遍历举例，它的递归版本非常简单直观，
在日常写码中，我们经常能遇到判断一个元素是否在一个给定的集合中的需求。听起来这种问题很简单，用哈希集合就能轻松搞定，用 Python 表示的话，很容易写出如下的代码， >>> my_set = set([1, 2, 3, 4, 5, 6, 7, 8, 9, 10]) >>> 1 in my_set True >>> 11 in my_set False 并且我们知道在集合中查询的时间复杂度是常数级。然而，如果集合上了规模，我们就不得不考虑这样一个集合将要占用多少空间了。假如里面存的都是整数，按一个整数四个字节计算，十亿个整数就要用掉大约 4GB 的内存，这个大小光是程序启动时从外存加载数据的时间就够程序喝一壶的。 那么如何解决这个问题呢？ 当然，如果我们确实希望精确地知道一个元素是否在这规模大小为十亿的集合中，哈希集合的使用还是不可避
