作为一名程序员，又或者IT工作者，拼搏在技术快速变迁的大潮流中，其实是一种幸运，毕竟我们无需陷入重复的枯燥生活之中。然而要跟上技术发展的脚步，真的太累了，就怕步伐太慢，一不留神你就落伍了。

或许有所谓通才与全才，又有那种最强大脑的天才们学什么都很快，除此之外，如我们这般的普通人，知识无涯生却有涯，就得聪明地利用有限的时间学习真正有用的。这种所谓“有用”，就是指学习之后能够给你贴上明显标签的那类知识。“标签”是一种信号，更像是某种声望。就是当团队面临对应问题时，人们会一拍脑袋首先想到你的那种声望。

响应式编程（Reactive Programming）的本质是异步非阻塞的高响应式处理，最核心思想则为Everything is stream，即针对流进行处理，这是其根本。从这个角度讲，我们可以将响应式编程的设计思想视为Stream-Oriented Design，即面向流的设计。

正如面向对象设计以对象为基本设计要素，函数式编程思想以函数为基本设计要素，响应式编程则应该以流为基本设计要素。这带来设计思想上根本的变化，包括：

• 以流作为建模的元素
• 流存在松耦合的上下游关系
• 以流为重用的单位
• 对流进行转换、运算、合并与拆分

在Rx框架中，一个流就是一个Observable或者Flowable。例如我们要统计网页的字数，则流的源头就是对网页内容的获取，而流就是Observable<String>类型的网页内容。至于统计操作，则需要经历分词、字数统计两个阶段，则可以视为是对流的转换与运算操作：

Flowable.fromFuture(pageContent)
    .flatMap(content -> Flowable.fromArray(s.split(" ")))
    .map(w -> new Pair<>(w, 1))
    .groupBy(Pair::getKey);

由于Rx框架提供了诸如merge、combineLatest、zip等操作符来完成多个流之间的组合，我们就可以分别建立各自的流，然后再利用这些操作符对其进行合并，或者反其道而行之。这样就能尽可能地分解出诸多原子的可重用的流。例如，针对UI的click操作以及response响应，我们就可以分别建立两个流，然后利用combineLatest进行组合。无论哪个流发射了数据，它都会将这两个流最近发射的数据组合起来，并按照指定的函数进行运算。

需求

客户希望通过spark来分析二进制文件中0和1的数量以及占比。如果要分析的是目录，则针对目录下的每个文件单独进行分析。分析后的结果保存与被分析文件同名的日志文件中，内容包括0和1字符的数量与占比。

我从2004年开始写技术博客。最初一直是在博客园，笔耕不辍，几年积累下来也有不少文章。最初我的关注点主要在于软件设计，尤其是与面向对象设计和设计模式有关的，在园子里也颇受关注。2006年，我将这些文章整理成册，名为“设计之道”，开源出来放在网上，似乎引起不少人的关注和追捧，其中就有电子工业出版社的博文视点编辑。2007年，在博客园dudu的帮助下，我在博文视点出版了我的第一本书《软件设计精要与模式》，这也是至今我出版的唯一一本自己的著作。本书在2009年出版了第二版，之后，就没有之后了。

因为我做的项目慢慢开始脱离.NET圈子，兴趣点也放在Java社区，我逐渐与微软的.NET阵营渐行渐远。不再继续申请连续五年的微软MVP，很少关注.NET技术，于是自己觉得应该与当时专注于.NET技术的博客园告别了。

其间自己效仿技术网红的做法，申请了域名，开起了个人网站。有了小小富贵，就想独立成家立业，典型的小市民。因为少了整个博客园这个圈子，个人网站的访问几乎称得上是“门前冷落鞍马稀”了。那时候没有GitHub，没有许多特别自由的博客软件，没有markdown，自己小本经营着个人网站，慢慢心也淡了。博客仍然继续写，因为后来需要域名备注的缘故，个人网站终于惨淡收场。待到Github page出现，就赶紧惊喜地将博客搬迁到github上。

当时我使用了jekyll制作了博客，自己修改了样式，二次开发了一些小程序，例如通过ruby程序自动将发布的博客同步到新浪微博上。我寻找到了geek的感觉，因而乐此不疲。然而我这人总有些喜新厌旧，慢慢的，博客虽然照常这样不温不火地写着，却寻找不回最初的乐趣了。直到我发现farbox。