【健荐】 201507 - 少即多
2015-08-06
之前写过一篇软文写作（分享）驱动学习，在那篇文章中我主要想表达的就是如何坚持做一件事情，我的结论说白了就是努力让事情变得简单有趣。拿这个健荐举例子，每天阅读大概500篇订阅，推到Pocket里的一个月大概有100篇左右，到月初详读所有文章，再挑选整理成推荐加上自己的评论和配图，至少需要5－6个小时左右的时间，对自己来说已经不能算是一件简单的事情了。所以试着减少一下评论的内容，增加推荐的文章数，力求言简意赅，也可以试着把事情变的简单一些。大家如果有什么反馈建议可以在公众号里直接回复，也帮助我持续改进，谢谢了～
谈程序的正确性
王垠的七月新文，核心观点“一个程序好不好是看它能否有效地解决问题，而不是只看它是否正确”。同意，但是不同意测试是验证正确性的观点，反而我认为测试恰恰是应该验证程序是否解决了问题。最牛B的编码套路
世上并没有最牛B的武功，只有最牛B的武者；最牛B的武者靠的也不是最牛B的武林秘籍，靠的是十年如一日的练习；功到自然成。Martin Folwer谈微服务的优缺点
比弄清楚是什么（什么是）更重要的是弄清楚不是什么（什么不是），比弄清楚适合什么更重要的是弄清楚不适合什么，比弄清楚优点更重要的是弄清楚缺点。编程王道，唯“慢”不破
欲速则不达，应该力求作对而不是盲目的追求“做完”，但不意味着不需要追求开发效率，反而我认为这里的慢代表的更多是扎实细致负责，而快往往是其基本功。为什么千万不要重写代码？
任何东西都会慢慢地挂上岁月的痕迹，就算是你新重写的看起来崭新的代码一样。重构比重写可以成本更低，粒度更小，风险更低，所以我推荐重构而不重写。但重构比重写要难得多。极限会议: 原则与实践
以终为始, 保持张力。极限编程很多实践都是将一些编程实践推到极致发现的，例如如果测试是好的，我们就把它做到极限，就有了TDD。如果沟通是好的，我们就把它做到极限，就有了结对编程。而同样的思路引申到会议实践，有意思。inception的核心逻辑
敏捷之余瀑布的一个变化就是对于变化的尊重。我们不再奢求需求不变，市场不变，不再依赖一开始的假设正确，也不再将赌注押在一开始就想对作对。“我们认为软件交付需要拥抱变化”，但是如何做？请看此文。使用异步 I/O 大大提高应用程序的性能
搞不清楚什么是同步阻塞I/O，同步非阻塞I/O，异步阻塞I/O，异步非阻塞I/O的请看这里。Flex 布局教程：1.语法篇 2.实例篇
前两天朋友圈被刷屏的两篇文章。阮一峰老师的文章就是通俗易懂，毫无废话。Flex 布局能不能成为拯救我等前端小白的救星，拭目以待。Functor, Applicative, 以及 Monad 的图片阐释
虽然还是有点儿糊涂，但是看到将Monad画成皮搋子的时候也是醉了。很喜欢这种将复杂事情轻松简单表达的方式。就算理解不了Monad这么高大上，对理解类型，函数，函数类型也有帮助。别再用MongoDB了！
作为一个还没有真正用过MongoDB的人无法评论他说的是对的是错的，不过我想表达的是就像TeaHour最新一期中Robbin说的，有的时候对于一个热门技术我们通常会过度使用，我们需要的是一个武器库而不是守着手里的一把锤子，见什么砸什么。[翻译]Emacs的prelude READMD文档
Prelude是我在用的一个Emacs的配置，比较适合对于Emacs无从下手但心向往之的想快速上手的同学们。如何用通俗的语言来解释「费米悖论」？
最后脑洞大开一下