在前后端分离大趋势的今天，通过模块的方式来管理代码似乎比以前任何时候都容易。组件都是由JavaScript编写，且组件本身就是一个状态机，这为我们编写测试带来了不少便利性。

近期入职的新同事比较多，而其中有些同事已经有在官网投稿的打算。为降低彼此之间的沟通成本，并缩短技术管理者的审阅时间，故而写下这篇官网投稿的相关指南。

在网上看到个有趣的自联结例子：Person对象自联结 ，它考虑了Person对象的孩子和孙子关系，本文要考虑的是另一种情况：每个用户和销售商有一个邀请码，当邀请新用户进来报名时，新用户可填写该邀请码以标志邀请者。这里销售商与用户、用户与用户之间存在着邀请与被邀请的关系，其中第二种关系是下面会讲到的自联结。

在Ruby的实例方法中分别有public, private以及protected三种类型，不同类型的方法将会有不一样的访问约束。而这篇文章我主要想详细介绍一下他们之间的区别。

这是Redux源码分析系列的第四篇文章，当这篇文章结束之后Redux源码分析系列也该告一段落了。这篇文章主要想谈谈bindActionCreators这个函数的实现原理，为了更好的理解这个函数我会恰当地引入一些应用代码。

前两篇文章分别分析了Redux中间件，以及Redux的数据中心的源码，如今已经对Redux这个库有一定程度的了解了。目前可以说主菜都已经上齐了，剩下的只能算是饭后甜点了，而今天的甜点是combineReducers这个函数。

将项目交付给一个没有 Rails开发经验的团队来部署上线成本非常高，Rails 常用的部署方式是使用 Capistrano 或者 Mina，如果对方团队的技术栈是基于 windows环境开发，那在本地跑项目的执行部署脚本的难度会非常的高 。这个时候 Docker就能很好的解决这个问题，Docker 将应用程序与该程序的依赖，打包在一个文件里面，对方只要执行这个文件就可以，不用担心环境问题。

上一篇文章介绍了Redux的数据中心，并分别讲解了数据中心为开发者提供的各种接口，了解到要触发状态的更新就需要调用dispatch方法来分发action。然而store提供的dispatch方法只能够用来分发特定格式的action。

在如今的前端浪潮中，React和Redux有着举足轻重的地位。React，Redux再加上用于链接他们的代码库就足以让一些没有足够经验的开发者迷失到代码的海洋里，很容易让程序员们培养成一种别人怎么写我就怎么写的编码习惯，难怪许多大神会说这是最好的时代但也是最坏的时代。

初入豆厂的时候就经常听到一些有经验的老员工谈到尾递归，当时我也不怎么当回事。相信许多初入职场的同学也跟我一样对于一些与自己所做工作似乎没有直接关系的东西一般都持排斥的态度。现在回想起来真想扇自己两巴掌，如果当时能够好好的了解一下这些概念的话，或许我能更早地发现编程里面更深层次的乐趣。