查看原文

本文尝试论证代码不是公司的资产，而更像是债务。我们的目标是添加商业价值，解决实际问题，代码只是我们解决问题中的 necessary evil。代码越多，你要理解越多，维护精力越大，要适配新需求也更复杂。比起添加了多少多少新代码，不如想想如何在保证相同功能的情况下写更少的代码。我们趋向于认为更少的代码可能是更好的设计（从可维护这个角度）。

查看原文

关于无限 (Infinity) 这是个数学概念，其实也是个编程概念。希尔伯特认为无限不存在于真实的物理世界，但是谁知道呢。1 / 0 在 Python 会触发 ZeroDivisionError, 但在 JavaScript 中就能得出 Infinity 的答案，这完全取决于人们怎么看待问题。有些编程语言会将 ∞ 作为一个大数的 placeholder，有些则直接提供了无限的数据结构 (<val> . <promise>) (1) Scheme Lazy。真实世界中的无限可能是个存疑的概念，但是编程中确实个实实在在的抽象。

查看原文

Go Cloud 是刚刚发布的一个开源项目，旨在为 open-cloud 提供一套普适的通用接口。在过去的数年里，云平台雨后春笋，遍地开花，但是也引入了问题：各家在提供基本功能时都有自己的实现和接口。这个项目解决的问题就是让你的代码可以几乎无缝的移植到各种平台，而不用修改代码。目前还仅支持 GCP，AWS，不过未来应该前景很好。例如，文中给出的示例是，使用一个通用的 *block.Bucket 类型可以适配 s3blob, 或者 gcsblob 云存储。

查看原文

Merkle Tree, 也叫 Hash Tree，是一种基于 Tree， Hash 这两种算法的数据结构，主要用于验证数量众多的数据。它的叶子结点存储数据的Hash，非叶子结点存储所有子节点 hash concat 后的数据的 hash。它被应用于 Git, Mercurial, BitCoin, Ethereum, Dynamo, ZFS, Cassandra 等等。我们可以在中本聪的 BitCoin 那篇论文里面找到 merkle tree( 第 8 章节 Simplified Payment Verification )；在 P2P 网络中，我们也可以通过简单校验 top hash 来看这个源靠不靠谱。

一般我们会推荐使用 SHA-2 家族的哈希函数。

Merkle tree 有一个缺陷是 …

查看原文

本文介绍了Google的代码仓库不是一个服务一个仓库，而是全公司95%的代码都存在一个单一仓库中。截止 2016 年的一些数据：

• 25k 开发者
• 十数个全球办公室
• 每天 16k 个变更，24k 个系统自动变更
• 800k qps 高峰时段
• 86T 数据
• 二十亿行代码

这个系统的一些特征：

• 名叫 Piper
• 分布式部署在 10 个 Google 全球数据中心
• 使用 Google 自家的数据库技术 Spanner
• 使用 Paxos 算法确保数据复制的一致性
• 需要配缓存，使用异步操作优化性能
• 支持文件级别的权限控制
• 大部分文件面向所有开发者公开，敏感配置文件或者核心商业算法相关的文件不全公开
• 文件读写都有审计
• 误提交的文件会被 Purge
• 提交的变更在一个 workspace 里面，有点像 svn 或者 …

查看原文

python/cpython/Objects/dictobject.c 是 CPython 的 dict 实现。

• indices 做 hashtable, entries 则作为 KeyEntry 的数组用来存 kv 数据。
• hashtable 有两种：combined table, split table.
• 哈希表中的 slots 有 4 种类型：unused, active, dummy, pending; 前两个很好理解，一个没用过，一个有数据，后两种跟删过的数据有关。
• 最小的 size 是 8，一个工程上的假设和优化。
• perturb_shift 设置为 5，用来做哈希碰撞的检测，也是个工程上认为是个合理的取值。
• 数据量到达 …

查看原文

HTTPS 现在是一项免费的技术。不给网站开启 HTTPS，就会被标为 Not secure。现状是 Alexa Rank 前五十的很多网站还是没开启默认将 HTTP 转向 HTTPS。这将导致的问题会有中间人劫持，篡改等等很严重的问题。让我们不要以这些大公司为标榜，默认开启 HTTP 转向 HTTPS!

查看原文

这个网站展出了多种 ReactiveX 算法的交互示例。

查看原文

本文介绍了一种学习的方法：写日志，月志，做索引。其实这也是 Techshack 的更新方式。好记性不如烂鼻头！

查看原文

本文讨论了一种能够加速查找与某个文件相关的所有 git log 的优化：使用 Bloom Filters。

Git Commit 的数据结构是一颗哈希树。树节点是文件快照，树的边是文件目录。

这种数据结构决定了 checkout 某个版本的数据方便，但是检索历史将要遍历很长的提交历史才行。 鉴于这颗树还与目录成绩长度有关，嵌套深的时候查起来很费力：

Bloom Filters 是一个 probabilistic set. 这个 set 就是一些比特位组成的开关，每次设置完之后我们查询问题可以得到两个答案：绝对不可能 / 可能. 如果我们能够得到前一个答案，意味着我们可以不用再深入检查了，只需要检查那些 可能 的case 是不是 true 即可。

一些工程上的小观察：

• 如果文件有变更，提交的父亲目录也会变更
• VSTS 对路径名长度设置为 512，因为路径名长度符合对数正态分布, 512 以上就比较少见了
• 大部分提交都很小
• 实测 false …