最近自己在家搞小玩具，有一个前后端交互的需求，毫无疑问应该用 Restful API 来进行通信。然而根据之前的经验，在 AWS 上最便宜的机器也要一个月三块五毛钱，对于我这种玩具项目来说太过奢侈，所以就想到了 AWS Lambda ，兼具价格低廉和无需维护的优点。每个月前一百万次请求免费，之后每一百万次请求收费两毛，再合适（便宜）不过了。 由于暂时不打算透露这个玩具项目具体是做啥的，但又想尽可能详细地记录下搭建的过程，这里我会用一个简单的 ISBN 10 转换到 ISBN 13 的 API 为例。选择 Go 语言作为编写工具，主要是因为我之前开发过一个 ISBN 格式转换的库，可以拿来即用。 Lambda 函数的配置 首先，创建一个新的 Lambda 函数 名字随便起一个，叫 isbnConverter ， Runtime 选择 Go 1.x 。然后需要为 Lambda 函数添加触发器
但凡从事码工这一行，多多少少会遇到 Base64 编码这个概念，因为我们总要接触互联网，而 Base64 编码诞生的目的就是为了让二进制数据能够在只支持文本的媒介上传输，比如说在网络上传输一张图片或者一段音频。而 Base64 本身是一种无损编码转换规则，同时编码后的内容与原始内容差别非常大，所以很多时候大家在网上留联系方式的时候也喜欢用 Base64 转换一下，既能把信息传达给网友，又避免了充斥在网络上的各种机器人的骚扰，比如这位朋友的自我介绍，甚至还贴心地给出了完整的解码命令行。 理论 那么 Base64 的编码规则是怎样的？因为在计算机的世界中，所有的内容都以字节数组（ Byte Array ）的形式呈现，所以 Base64 的输入数据自然是字节数组，每一个字节有 8 位 bit ， Base64 以每三个字节为一组，然后均分成四份，每一份有 6 个 bit ，而这 6 个 bit
现象 根据哈希表的定义，以及之前简单实现过的一个字典数据结构，当 Key 被插入哈希表后，哈希表根据散列函数求出的值来安排这个 Key 所在的位置，所以当我们遍历哈希表的时候， Key 的顺序是不确定的，因此码农在使用哈希表这个数据结构的时候，是不应该依赖于 Key 的插入顺序来达到某些目的的。 但有的时候我们可能会对哈希表中 Key 的插入顺序感兴趣，这时有经验的 Python 工程师就会用 collections 中的 OrderedDict 来保持插入 Key 的顺序。 >>> d1 = {} >>> d1['a'] = 1 >>> d1['b'] = 2 >>> d1['c'] = 3 >>> d1['d'] = 4 >>> d1['e'] = 5 >>>
我一个 DigitalOcean 的用户，怎么就转移到了 AWS 呢？ 起因 一开始我没有考虑过这个事情，用了 DigitalOcean 好几年，对它的服务一直非常满意，尤其是上面各种详尽的文档教程，让我这个非专业运维也成功运行了这个小网站好几年，也逐步的上了 HTTPS 、 ipv6 、 HTTP2 ，至少看起来像那么回事了。 后来偶然一次在 AWS 界面闲逛，发现了 Lightsail 这个服务，有点儿类似于 DigitalOcean 的 Marketplace ，也提供了一些常用的软件预装在云服务器上，关键是比 DigitalOcean 便宜了许多。当年 DigitalOcean 给我开的价是一个月十块钱，后来我给博客加了个备份，文件放在他们自家的 Space 上，起步价五块一个月，这样下来维护这个网站一个月的开销就是十五块。然而同样的服务如果用 AWS 的话，就少了十块钱还多（
个人背景：在旧金山湾区从业四年有余，非一线大厂，非上市公司，到手工资只有 base ，看一亩三分地上的网友晒包裹的时候看不懂除 base 之外的概念。 认识不少朋友，所谓的理财就是每年存满 401k ，一方面抵了高到不知哪里去的税务，一方面拿到公司给 match 的那一部分，每年存下的也挺多，加上这几年美股起飞，可以说是小赚了一笔，并且公司每年发自家股票，几乎不用怎么费力折腾理财，手里的钱就能蹭蹭蹭往上涨。我作为金融业零知识，脑子懒不愿多算数的普通码农，如果不是公司不给 match 401k ，我也不会费劲去研究这些东西。想到不 match 的情况下，虽说存的是税前工资，但也只是起到一个延迟交税的作用，而且如果 60 岁之前取出的话，还要交 10% 的罚款，对我不是太划算。虽然我工资低，但攒攒还是有一些的，躺在 Chase 银行吃着万分之一的利息（没错， banker 说 0.01% 的时
