2015 年又划上了句号，于我来说，又老了一岁，已经到了那个不再张口闭口“我还年轻”的年龄段，年龄对于我来说已经有所忌讳了，相信很多同龄人都会有同样复杂而又微妙的心情。时间对于每个人都很公平，一年 365 天，一天 24 小时，不会因为人的身份地位而有所偏颇，在时间面前，人非常渺小。
上半年怀着无奈和遗憾，从聚美离职了，这么快离开聚美是我始料未及的。在聚美，个人能力得到了较大的磨练，因为所面临的问题是我职业生涯中从前未有过的。第一次带团队，团队从最初的一盘散沙，没有方向，到慢慢走上正轨，再到团队对整个大环境失去信心。在整个过程中，我都尽力做了我该做的，但我也无力回天，不得不接受事实，在这里有必要在团队管理方面做下总结。
由于 React 的单向数据流的设计，衍生出了单向数据流的架构模式 Flux。
在 MVC 的分层架构中，Flux 属于 M 层，也就是 Model，而在 Flux 中，Store 是关键部分，Action 和 Dispatcher 都是围绕着 Store 来设计的，所以 Flux 架构模式的目标就是基于单向数据流如何更好的管理数据，在 Views 或 Controller-views 与数据之间进行解耦。
我在之前的 React 应用的架构模式 Flux 有详细的介绍过 Flux 架构模式及其应用。
"Flux is more of a pattern than a framework."
这是 Flux 在其 github 主页上截取的一句话，翻译成中文就是：Flux 更像是一种架构模式，而不是一个单纯的框架。
React Router 是专为 React 设计的路由解决方案，在使用 React 来开发 SPA （单页应用）项目时，都会需要路由功能，而 React Router 应该是目前使用率最高的。
React Router 并不是 Facebook 的 React 官方团队开发的，但是据说有官方人员参与开发。React Router 的设计思想来源于 Ember 的路由，如果原来有用过 Ember 的路由，那么应该对 React Router 不会陌生。
对于没有开发过后端，也没有开发过 SPA 的前端来说，「路由」这个名词可能会让人比较困惑，这里的路由并不是指「硬件路由」，也不是网络七层协议中的「网络层路由」，但是其思想原理是一样的。我尽量简单通俗的介绍一下。
假如我们有一台提供 Web 服务的服务器的网络地址是：10.0.0.1，而该 Web 服务又提供了三个可供用户访问的页面，其页面 URI 分别是：
http://10.0.0.1/ http://10.0.0.1/about http://10.0.0.1/concat
移动设备想要访问位于局域网中的某个特定设备上搭建的服务，需要通过代理服务器来实现，针对不同操作系统搭建代理服务器有不同的软件，如果系统是 OS X 的话，可以使用 Charles，对于 Windows，可以使用大名鼎鼎的 Fiddler ，可视化软件的使用这里不详述，本文重点讲述在 Unix/Linux 上使用 Squid 来搭建代理服务器。
通常我们需要测试的是某个设备上搭建的本地服务，那么至少要保证使用 127.0.0.1 是可以访问的，如果是配置了域名的虚拟主机也是同理，至少需要确保本地绑定 Hosts 可访问。
假如你的设备上有一个正在运行的 a.com，那么需要保证可以在设备上通过绑定 127.0.0.1 a.com 的 hosts 能正常访问到该服务。
React 组件之间的数据通信在 初探 React 组件 有初步接触，父组件可以通过声明 props 来向子组件传递数据，但是子组件无法向父组件传递数据，兄弟组件之间也不能相互传递数据。React 的这种单向数据流的通信模式能确保数据的流动简单可控，非常严谨，React 也一直秉承着简单严谨的设计思想。
那如上提到的非父子组件的数据通信该怎么办呢？有几种方案：
回调函数 父组件注册回调函数，子组件执行回调函数，这种方案比较简单，适用范围也有限，适合简单的子组件向父组件的数据通信；
事件 事件通信是 JavaScript 最常用的通信方案，这种通信方案不用局限于组件之间的关系，比较灵活，但是当应用复杂庞大的时候，使用这种通信方式会导致管理混乱，不可控；
Flux Facebook 官方团队提出来专门应用于 React 的一套应用的架构模式，本文将要讲述的就是该方案。
