查看原文

本文是一篇经验总结贴，总结了他们为什么从 Celery 切换到 RQ，简单来说，就是 RQ 简单到爆，只有一种方式做一件事情，可以避免 over-complicated, over-engineer。作者觉得 Celery 是个很优秀的工具，可以提供各种 Broker 还有很多很棒的 Feature。但是如果看使用场景，很多时候我们只需要能从 web 进程中 enqueue job 到队列去，然后 worker 执行。就这么简单，如果非要再加一些需求进来，队列监控，限速什么的也不是不可以。但是过度工程到构建 workflow 什么都就有点跟 80% 需求偏差有些大了。RQ 使用 Pickle 做序列化，Redis 做 Broker 和 Backend，os …

查看原文

本文介绍了两种 Health Check: Readiness & Liveness，前者用于让负载均衡知道什么可以指派流量给应用，后者用于让负载均衡直到什么时候应该将应用移除出 Pool。

• Readiness 的使用场景：应用即便已经正在运行了，它仍然需要一定时间才能 serve 服务，这段时间可能用来加载数据，可能用来构建缓存，可能用来选举 Leader，总之 Readiness 检查通过前是不会有流量发给应用的。
• Liveness 的使用场景：应用可能运行到一半崩溃了，死锁了，CPU100%了，总之没法响应请求了。这时候 Livenss 能够检察出应用无法再处理请求了，就会将其从 Pool 中挪走，或者更聪明的工具可以重启应用或者干脆起新的应用加到 Pool 中。
• 在 Kubernetes 中有三种 Probe 可以使用，HTTP / Command / TCP。
  • HTTP 200~300 响应码的情况下 …

查看原文

本文列出了五十多项在使用 Bash 的时候需要注意的地方，Bash 是如此强大但又非常容易出错，一不小心就会删干净你计算机中没备份的文件。如果说人在不停地试错中学习，本文给出了绝佳的避免犯错的清单。

• 通配符(*)，空格( ), 有 leading-dash (-打头的文件), 有 ! 是很多错误的本源。这些东西让 bash 很魔法，也很魔幻。每一行 sh 代码都要好好想想字符串或者变量中是否会存在被转义的可能，如果会，配置好环境变量或者加上 quote。
  • for i in 后面要用通配符 或者使用 find -exec.
  • cp 的时候 "./$file" 这样比较靠谱。
  • [[ $var == [[ 比较人性能识别 $var 的空格
  • [ "$var" = [ 就比较不人性了，得加 "$var" quote.
  • 很多人没有注意到 if [ a = b …

查看原文

本文介绍了 [ 和 [[ 这两个命令的各种细微区别。简单来说 [ 是命令 /bin/[, 而 [[ 是则是 keyword，二者都用于比较，前者可以在任何 POSIX shells 中运行，后者只能在特定 shell 如 bash zsh ksh 等中运行。 你可以认为 [ 是 test 的语法糖，除了它必须在命令的末尾加上 ]. [[ 是 [ 的改良版，是一个 keyword 而不是 program => 设想 bash 在解析 [[ 前会有一个单独的 parsing context 处理其中的参数，这使我们在使用时可以绕开 wordsplitting, glob 等自动扩展，从而避免掉各种 quote。

一般来说如果考虑到可移植性，要移植到全 POSIX 平台 …

查看原文

本文是 Slack 工程博客关于如何扩展他们的任务队列的分享，他们的任务队列具体来说运行任何不在 web request 中执行的任务，例如推送提醒，unfurl，账单计算等，高峰时期队列 qps 可达到 33k/per second，任务时长从毫秒到数分钟不等。初版设计在公司上古时代就在用了，还用了很多年。Scaling 的契机是遇上了一次生产环境的大故障，就出在这个任务队列系统上，简单来说数据库资源争抢导致任务执行时间变长直到 Redis 内存超限，Boom。恢复时还屋漏偏逢连夜雨的碰上了任务没法 dequeue。所以，事故后，他们的重新设计的目标是：在核心系统最小故障时间的前提下，做到不停机的升级。

• 初版设计：[www1 www2 www3] => [redis1 redis2 redis3 redis4] => [worker1 worker2 worker3 worker4], www 可以任意发布任务到 redis，每个 …

查看原文

这篇 Reddit 帖子中包含了一些有趣但蛮激烈的讨论。原 po 批评 Pipenv 品味差 接口不好 核心问题没解决好 还有很多特性缺失，不如使用另一款工具 poetry。@theavalkyrie 认为原 po 还好，讨论戾气太重，社区中大家都是贡献自己的余力在做事情，社区氛围应该是帮忙把软件写的更好，而不是简单一句 bad, terrible 去指点江山。Pipenv 的作者 @kennethreitz 认为两个工具都很年轻，但是没有必要搞什么竞赛。Poetry 的作者 @SDisPater 认为开发者好好开发就好，至于社区的人想用什么就让他们自己决定好了。

衍生思考：目前来说两个工具看场景，如果写一个库，我会用 poetry，因为省掉写 setup.py, MANIFEST.in, setup.cfg 变成几行 toml 真的是体验好很多 …

查看原文

本文是 TAOCP 的第一章，讲的是 十几条 Unix 哲学。Unix 哲学的目标是设计出小而有用的操作系统，同时服务接口还特别干净。Unix 哲学是 bottom-up 的，如果用一句话来概述，那边是 KISS: keep it simple, stuipd.

这篇文章介绍了好几套说法，包括 Doug McIlroy, Rob Pike，以及作者自己(Eric Steven Raymond)整理的说法。

• Doug McIlroy: 做一件事，做好它。 程序应该只关注一个目标，并尽可能把它做好。让程序能够互相协同工作。应该让程序处理文本数据流，因为这是一个通用的接口。
• Rob Pike: 不要优化代码除非经过测量找到了瓶颈；简单的算法和数据结构在小数据场景下又好用有快，即便你用的是穷举。尽早创建原型。
• Eric Steven …

查看原文

本文是 Slack 的一篇工程博客，讲述他们内部推行的一个关于 Security Development Lifecycle (SDL) 的工作流，旨在帮助安全团队更好地评估业务代码。简单来说，就是通过 goSDL 这个工具在 slack / jira 这些工具中间回答问题，勾掉 checklists，这些问题和任务都是和安全相关的注意要点。这个工具本身也在帮助安全团队更好地调整选项和问题，用来提升开发效率和安全评估。

衍生思考：其实比较想拿到他们评估的那些问题都有哪些，这个工具本身并没有太大的技术难点。很多企业做开发前后都有安全评估的环节，其实程序员们并不是不想搞安全，只是要注意的细节实在是比较不容易想到。

查看原文

这是 @jbeda 发布的一系列推文，作者想要探讨的问题是 kubernetes 是不是真的太复杂了。tldr；简单来说，不是！尽管 k8s 是个复杂的系统，但是它引入了非常多有价值的抽象。

• 确实在某个小领域中，你可以用更简单的工具来比 k8s 做得更好。
• 你可以自己从头从 jenkins/bash/puppet/chef/salt/ansible/terraform... 什么的开始搭自己的平台，你可能会觉得用这套技术很很舒服。你不觉得复杂，只是因为你伴随着它一起成长。。。但只要来个新人，要适应这些工具，真的得适应大半天。// 就是说，你自己写出来的软件的复杂度，跟你学到的软件的复杂度，就算差不多，你也会觉得别人写的更复杂。
• ^ 这就是 K8s 所创造的价值。它为一个领域的问题提供了一系列的抽象（deployment, configmap, service, statefulset, secret, pod, ...)。尽管学习的曲线抖了一点，但一旦适应了 …

查看原文

本文是 TAOUP 第 10 章 的节选，答案是：任何东西都应该成为配置，应该考虑的问题是：什么不要成为配置。一般来说，能自动算出来的东西不写配置，除非花了很长时间才能算出来。如果别的程序能做的东西，本程序就别去做了。