【健荐】 201507 - 少即多

之前写过一篇软文写作(分享)驱动学习,在那篇文章中我主要想表达的就是如何坚持做一件事情,我的结论说白了就是努力让事情变得简单有趣。拿这个健荐举例子,每天阅读大概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无从下手但心向往之的想快速上手的同学们。

  • 如何用通俗的语言来解释「费米悖论」?
    最后脑洞大开一下

其他资源

2015-08-06 10:1928