某些民营宽带供应商，为了降低与电信或联通等主干通讯的开销，可能会缓存一些静态资源。像长城宽带有一套非常复杂的缓存机制，但有时依然会误判缓存上了不该缓存的东西，很多后端开发都有过大受其害的经历吧。

我觉得想怎么说都无所谓，只是能不能说服别人的问题。但一旦落到人身攻击了，就不好了。

https://spring.io/blog/2016/09/22/new-in-spring-5-functional-web-framework

Spring 新的大版本更新我也是晕了，彻底写出了一种 Spark 的感觉

这就产生了一个很大的问题，为什么会产生那种只会 Rails CRUD 的熟练工，或者在 Java Spring 甚至连 PHP 上我们也有很多这样的程序员。Web 框架，特别是已经做好了 MVC 抽象的 Web 框架是一个巨大的黑盒，作者做得那么复杂是积累了大量的经验和想法，背后的实现非常复杂，光靠熟练是很难了解其根本的。这就是在 Getting Started 之后需要了解一个框架的大局，再去通过项目去熟练，去具体了解其细节的原因。

其实单从功能上来说 ActiveSupport 的 try 好像还是 &. 的超集。但这件事情就很奇怪，就好像一些人认为面向对象和面向接口甚至和函数式编程都可以是等价的，从数理上如此，但并不代表对人的感知上是如此的。所以 Ruby 放着一个已有的超集去实现一个子集，这其实就是 Ruby 平衡性的一个考量了。

我只是说类似啦。。。并不是说完全一样。try 还有一些奇怪的用法比如 Array#try(:[], key) 之类的。

我记错了，确实是 ActiveSupport 提供的。不过其实自己通过元编程也可以实现一个类似的。

Challenge 1 就是个 DP，Challenge 2 就是个 AC 自动机。而且这题目没有绕弯，基本上都是算法课涉及这两个算法最经典的例题了吧。。。

对于 challenge 6 的 easy 来说，其实也挺不 easy 的。由于题目要求精确到小数点后 30 位，基本超出了浮点数的精确范围。如果不考虑这点的话，可能无论什么方法都很难做对。

为了正确做对这道题，你需要定义一个自己的数据结构能够处理更多位的小数，比较方便的是定义成定点数，理论上定义个 100 位，做一个 30 位精确的题目应该是足够了。然后你需要实现这个数字的加减乘除运算。一旦这点做好，就有很多方法可以做对，无论是割圆法还是蒙特卡洛迭代，或者定义一个大正方形然后遍历每个点，应该都能算对。

如果要收敛得比较快，那么比较常用的是梅钦公式。不过梅钦公式中有个 arctan，这对于才实现了加减乘除的自定义数据结构来说很不方便。但可以用泰勒级数展开这个 arctan，从而把问题转换成一个迭代问题 。现代常用的计算圆周率的方法一般都是梅钦公式的改进，称为梅钦类公式。

除了这些方法以外，另一个难点是，如何证明自己的程序已经收敛到前 30 位完全正确了。证明自己是对的这一点也挺有意思，特别是我们假设 30 位的圆周率还没有被人类算出来，我们需要自行证明自己是对的，而不是拿一个正确答案来比较。这一点对于梅钦公式来说比较容易，对于蒙特卡洛方法来说则很难。