Wafer's Note

上篇文章我们说到如果你的 VectorDrawable 如果采用一个带 <selector> 的颜色进行着色，那么就需要在测试代码中对 Drawable 进行重新着色，而不是直接比较。

本篇文章就来着重说说其中的原理。

最近在迁移到 AndroidX 之后一直折腾 TDD 的事情，也遇到了大的小的不少坑点；

鉴于 AndroidX 在测试方面还没有太多的文档，就写一篇博文来总结一下折腾的经验，也给后来人做一些参考。

之前又稍微折腾着想尝试一下 TDD，并在每次构建的时候加入测试环节，当测试不通过就不允许 build。

当一切都配置好，点下 build App 的时候，却出现了 There were failing tests.。

我心想，不会啊，现在我就根本没写几个测试用例，为什么会通不过？

于是，就开始了艰难的调试过程

如果你开发过稍微有点体量的 Android App，都会因为越来越多的 Gradle 依赖而头疼。

一个 App 的编译依赖少则十几项，多则几十项，如果再加上多 module，那么依赖的统一管理就很重要了。

但是，如何高效统一管理，则是一个难题。今天就来说说如何使用 buildSrcVersions 轻松管理 gradle 依赖。

之前学算法分析的时候只知道通过数语句来计算算法的复杂度，而对于递归算法没有很好的方法；

由于递归算法通常采用分治思路，每递归一次，子问题在增多，但是子问题的规模在减少，所以如何去计算这种递归类算法的复杂度呢？
斯坦福的教授提供了一种使用 递归树 的方法。

GPG 相信很多人都折腾过，Yubikey 也有很多人买过；

但是好像只有老外折腾过 Yubikey + GPG 的；

最近刚折腾完毕，因为自己不慎还把一个老钥匙搞丢了，现在只能随它去了；

这里就写写我折腾过程中遇到的坑，前车之鉴，后事之师。

最近，鉴于性能考量，我从 MathJax 迁移到了 Katex，但是随之而来出现了一个问题，就是脚注里面的数学公式没办法渲染出来。

本文着重介绍一下如何解决 Travis CI 在进行自动集成的时候，总是会更新旧博客的问题。

之前有想过要把这篇文章合并到上一篇里面，不过这个问题比较隐蔽，而且较难解决，最后还是新开一篇文章来详细讲一下该怎么做，防止以后有人再被这个问题困扰。

这个想法是我在折腾 Hexo Next 6.0 的时候发现的，有位仁兄在 Next 的新 repo 问如何处理 CI 问题，受到他的启发，我就开始折腾使用 Travis CI 进行博客的自动部署了。

Solidity 是运行于以太坊(Ethereum) 区块链上的智能合约语言，它是图灵完备的，意味着可以用它写一些任意复杂度的程序并运行于区块链中。