苟利国家生死以,岂因祸福避趋之

Panda Home

用 Cobra 写一个命令行工具

发布于 # 聊聊技术
标签: # cli # Cobra # Go # 调度场算法
用 Cobra 写一个命令行工具
Photo by https://pixabay.com/photos/abacus-asian-culture-counting-frame-7019994/

Cobra 是一款非常流行的命令行生成工具,由 Go 语言实现,比如说著名的博客工具 Hugo , GitHub 命令行等都是用它实现的。 一直以来我只是闻其名,却没有真正用过。最近入职了新公司,简单熟悉了新组的代码库之后,发现整个框架就是用 Cobra 搭起来的,虽然本质上是各种复杂的服务,但 Cobra 可以为用户提供一套非常简单有效的命令行工具来操作它们。因此借着这个机会,趁周末放假,我在自己的机器上实现了一个简单的命令行工具来计算输入的数学表达式,以此来熟悉一下这个大名鼎鼎的命令行构建工具。 需求 需求很简单,输入一段数学表达式,能够输出正确结果,比如说 1 + 2 得到 3 ,支持加减乘除和指数计算,包括小括号。 因为只是练习之作,这个小玩具就简单粗暴地命名为 suan ,取汉字“算”的拼音。 环境 我的 Go 版本如下所示, » go version go version go

我的 2021

发布于 # 随便聊聊
标签: # 2021 # 年终总结 # 谈笑风生
我的 2021
Photo by Markus Winkler on Unsplash

谈笑风生又一年 我们从混乱无措的 2020 年到了平淡乏味的 2021 ,眼下终于也要揭过去这一页,回望过去的一年,突然发现我的这篇小文章都是多余的,因为值得一提的地方实在不是很多,但按照传统,还是水一篇吧。 生活终于从过去的两点一线彻底变成了一个奇点,休闲、工作、购物、吃饭基本都可以在方圆 300 米之内搞定。很多时候都不需要考虑开车的事情,最远的一次出门是开到车管所续新的驾照,为节能减排,低碳环保做出了重大贡献。翻翻账单记录,上次去加油站还是在九月份,飞涨的油价似乎影响到了我,又似乎没有影响。 本以为在疫苗的加持下,我们可以度过疫情,恢复以前的正常生活,但国外抗疫的无能养出了 Delta 变种和 Omicron 变种,使得本来有些向下趋势的曲线一飞冲天,然而与去年的封城宵禁不同,至少在美国,很多人的眼里已经没有了新冠病毒,仿佛疫情从未出现过,照常生活,照常养蛊,美国的疫情早已失控,

如何将递归转成迭代

要理解递归,先得理解递归 发现问题 函数的递归调用是码农在日常工作中不可或缺的利器,在某些问题上,函数递归可以提供更为简洁的代码实现和更为直观的阅读理解,比如说我们很熟悉的树形结构的遍历。 然而,当函数调用的层数过多的时候,就可能导致著名的 Stack Overflow 错误,而栈空间一般是由编译器( C/C++ 等)或者 Java 虚拟机( Java 系语言)来管理,对程序员是不可见的,当然我们可以通过配置参数来调整程序的栈空间大小,但不免麻烦,并且递归层数一增加,栈很可能又要溢出。 尾递归是一个常用的优化方法,很多语言在执行的时候会识别这种优化,因为递归函数调用是一个函数的最后一步,所以在递归调用之前,就可以把当前函数调用从栈中弹出,再把新的函数调用压栈,这样就不会因为递归深度的增加吃掉栈空间了。 但尾递归并不是很容易就能实现的,用二叉树的中序遍历举例,它的递归版本非常简单直观,

布隆过滤器简介

发布于 # 聊聊技术
标签: # 布隆过滤器 # 大数据 # Bloomfilter # Java # Go # Python
布隆过滤器简介
Photo by Thomas Martinsen on Unsplash

在日常写码中,我们经常能遇到判断一个元素是否在一个给定的集合中的需求。听起来这种问题很简单,用哈希集合就能轻松搞定,用 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 的内存,这个大小光是程序启动时从外存加载数据的时间就够程序喝一壶的。 那么如何解决这个问题呢? 当然,如果我们确实希望精确地知道一个元素是否在这规模大小为十亿的集合中,哈希集合的使用还是不可避

记一次 Airflow 性能调优

本文基于运行在 Google Cloud Composer 上的 Airflow 1.10.15 。 TL;DR 复制一份参数计算表格,填入 Airflow 集群的配置,将最下方给出的参数结果应用到自己的集群上,稍等片刻即可生效。 问题产生 Airflow 用得久了,上面跑的 DAG 越来越多,并且随着业务量增加,每个 DAG 中需要执行的任务数量也越来越大,这时很容易遇到任务节点之间延迟过大的问题,具体表现为在上游节点执行完成之后,要等很久它的直接下游节点才会被 scheduler 安排到队列里等待执行。在我们的生产环境中,根据甘特图显示,最严重的时候两个相邻节点的执行需要等待 40 分钟之久,而任务的本身运行时间仅仅需要五六分钟左右,这样的性能对于数据离线分析来说是不可接受的,因此花了两天的工夫进行性能调优,借鉴了大量文档和前人经验。为了避免再次掉坑里,就决定写篇短文来记录一下这次调优