今天被小伙伴问到了闭包，虽然自己原来也看到一些关于闭包的文章，但是发现自己什么都说不出，所以又到了学习的时刻了。
首先先去百科了下闭包的概念：1
闭包就是能够读取其他函数内部变量的函数。由于在javascript中，只有函数内部的子函数才能读取局部变量，所以闭包可以理解成“定义在一个函数内部的函数“。在本质上，闭包是将函数内部和函数外部连接起来的桥梁。
咱们将这段话拆分一下：
将话分成了三部分，果然理解起来就容易多了。我在网上也找到了很多介绍闭包的文章，例如http://www.ruanyifeng.com/blog/2009/08/learning_javascript_closures.html，但无奈本人是java程序员理解起来还是不够清晰，所以还是谢了自己的java理解版本，如下：
首先我们先聊聊最老生常谈的话题，区块链是什么？我在网上找了很多的解释，在这里我推荐一个我认为最好的解释。我们可以换一个角度来问这个问题，与其关心什么是区块链，不如去考虑，满足什么条件就可以称为区块链呢？这里给出三点：
接下来我们来聊聊区块链为什么会这么火？为什么称区块链是一场革命呢？其实就两个字，信任。
信任是自古以来一直都有的东西，从洞穴时代到工业时代再到信息时代，人们无不依赖于信任来进行交易：我信任你，我才会和你交易。解决社会因为审核所花费的成本，在当今社会中充斥这大量的中介机构（这里的中介机构不光是我们通常理解的房屋中介什么的），我们在京东买东西付款，是因为我们相信京东收到付款后会给我们发货；我们把钱存银行，是因为我们相信银行不会花掉我们的钱等等。思考一下，我们的社会运转其实就是依赖这些中介机构，但另一方面也说明同时我们花费着巨额的成本去证明“我们之间可以信任”。想象一下，去掉这些证明信任的环节，那我们的社会将会是什么样呢？可见称区块链为一场革命是有必要的。
再说“非对称加密”之前，我们先聊一聊“对称加密”。对称加密是我们所熟知的加密，通过加密算法和秘钥将明文加密成密文。其中算法和秘钥都是固定的，也就是说如果我们的算法和秘钥有任何泄露的话，我们的加密也就不再安全。这个是“对称加密”的问题，现在想一下我们真正的使用场景。假设我们是发送端，为了信息的安全，需要把内容加密发送，所以接收端必须要知道加密算法和秘钥，这才可以识别加密内容并使用。这就带来了一个问题，我们的信息安全是建立在信任接收端之上的，相信接收端不会泄露我们的加密算法和秘钥，所以“对称加密”严格来说并不太安全。由于以上“对称加密”的问题，这就催生了“非对称加密”。
“非对称加密”需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。 非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。
前端时间和斌哥吃饭，我就斌哥他们做游戏用的是什么通信协议，斌哥说他们用的是websocket。关于websocket的名字我也是听说过的，但也只是了解到了它是http之上的协议，也没有做过深入的理解。这两天闲下来写，所以就查找了websocket了的资料。
既然提到了websocket，http就不能绕过去的。websocket的出现就是为了弥补http的不足。我们都知道一个事实，http协议只能由客户端发起，就是说服务器不能主动向客户端发起请求。但是websocket就是一个全双工协议，允许服务器主动发送信息给客户端。websocket本身是html5规范的一部分，就是来解决服务器给浏览器发消息的问题（原来只能依靠不断的轮询服务器才能做到的事情），但websocket也不局限于浏览器的使用，任何实现了websocket协议的客户端和服务端都可以用此通信。那么websocket到底和http有啥关系呢？websocket和http都是从tcp之上演化而来的，对于websocket来说，它依赖了http协议进行一次握手（关于为啥非得用http握手我就不太清楚了，可能是最先html5的规范并且肯定要在浏览器使用的原因吧），握手成功后，数据就从tcp通道传输，与http无关了。
下面我们来聊一聊http，http的历史发展我就不再多说了，网上很多资料写的很清楚，
在这里我想聊一个java最基础的java bean的理解。
作为一个java程序员，java bean有get set仿佛是天经地义的。我也是这样认为的。然而经过高人提点，我们仿佛忽略了一个问题，我们一直在使用orm框架，其实set get是orm框架所必须的。其实我们可以看jdk源码，我们能看到jdk的java bean里全有get set吗？明显不是，反而用的多的也是被我们经常忽略的构造函数。
java bean应该有行为吗？答案是肯定的，java是面向对象的语言，java bean的行为正是其面向对象语言的最主要的特征。好的，让我们这里回想下，我们写的程序。我们的系统一般会分为以下三层，在这里我们把每一个层级对应的java bean都以不同对的名字分类：
最近在学习TDD，说实话对于TDD的应用我还是抱有一定的观望态度的。我先简单介绍下TDD的过程：
但是做为一个身陷囹圄的码农，我做的最多的是业务系统（讲的通俗一点就是CRUD）。如果我要按照TDD来开发的话，我需要经历什么呢？先写test。光是这里我就觉得很别扭了，我的目标其实很明确，就是写一个insert表的接口，表有对应的数据字段。这里接口的操作和数据模型非常简单明确，我完全可以先写接口，然后用test来验证接口。
仿佛到了这里已经偏离TDD了，TDD本身的意思是”测试驱动开发“，跟我的方式是由本质区别的。想到这里，我也就明白了，对于简单的业务系统来说，TDD可能并不是太适用。但是对于算法或者比较复杂的业务的时候，可能就比较适用了。我们的架构师在这里对我们的测试题目有了一个不错的分
这些天我们正在准备重新规划商户的接口，同事们出了一版设计，但是遭到了我们老大的否定，但是我本身也是比较赞同同事的设计的。矛盾点是在这里：
我认为，我们作为提供基础数据服务的部门，因为我们基本是最上游系统，所以我认为我们这边应该尽量少的包含业务，尽量使我们的接口更好的通用化，至于下游系统怎么使用我们的数据做它自己的业务，我觉得我们并不太需要去关心。这里我们只拿一个接口我说明，Vender getVender(String code, int type)
比如说type有两种，1代表供应商、2代表联营商，按照我上面所说的理由接口设计出来应该是这样的。
我们老大认为，作为服务的提供方（server）首先应该站在调用方（client）去考虑，绝大多数的下游系统只是存储一个code信息，他自己一般是知道自己是什么类型的商户，所以他如果使用这个接口就必须传一个1或者2，这个对于客户端来说就不是很友好。这样这个判断类型的逻辑就分散到了各个调用
接口的对接一定要深入了解对方的需求，不仅仅是满足需求就好。
如果对方提出一个需求，正确的态度是要和对方多了解下对方的场景，对方能提供的入参和对方想要的出参。正好你有一个接口可以满足这个需求，但这个时候不要就立刻给出对方这个接口，我们一定要经过自己的思考，这个接口是否真正的合适对方，是否需要再提供另一个接口给对方使用呢？？？
案例：
商户物资的一个接口需要查询商户信息，其实物资接口只需要商户主要信息的id，但是调用了商户基本信息查询接口，其实此接口内部查询了包含主要信息以及其他七部分信息的数据，其实这个接口对于物资就不太合适。在分布式系统中，各个系统都是相互调用的，接口之间的调用其实都是一个调用链条，其中任何节点的效率都会影响到其之后所有的调用节点，这样越在后面的调用节点，其实是之前节点的影响效率的累加，越是上层的接口影响越是深远，所以不光是接口的设计很重要，对于接口的理解也十分重要。
在一个大型公司当中，对项目的最最主要的要求就是稳定，任何的改动尽可能的是其影响的范围缩小到最小。改动其实是难免的，只要有需求的任何变化，项目或多或少都会有改动。maven作为一个项目的管理工具，他使用model来实现分层，理想的情况下每个模块内部的类只影响到自己个module本身。例如我们的项目，原则上至少会分成以下几个module，dao、biz、rpc、service、api。
假设我们我们的业务中有一个student表，所以我们dao module会有一个StudentEntity的pojo，如果严格按照原则的话，那我们至少有三个pojo（service是api的一个实现算一个）来表达这个student业务，需要做至少两次convert才最终到service提供出去服务（暂时不包括rpc module），这样才做到了控制影响范围。但是这样带来的一个后果就是，我们的每个module里都会有大量的convert代码，然而其实绝大多数每个module 的pojo之间差别是很小的，甚至是没有任何差别的。所以我们一般做项目的时候都会做一些权衡，有一些东西是可以贯穿整个项目的，比如说自定义的BusinessException、一些constants、一些enum。但是项目module之间的依赖是顺序传递的，如下图:1
2
3
4
5
6
7
8
9+---------+ +-----+ +-----+
| service | --> | biz | --> | dao |
+---------+ +-----+ +-----+
| |
| |
v v
+---------+ +-----+
| api | | rpc |
+---------+ +-----+
今天看《冒号学堂》的时候，看到里面又提到了关于设计语言的传值方式的问题，我记得大概一两年前我就写过类似的东西，里面也讨论了java的传值方式的问题。时至今日，再次看到这个问题的时候，又有了一些别的理解。
现在java8已经比较流行了，其中最大的亮点大概就是支持了函数式编程，lambda以及function。这就让我们联想到，究竟什么是函数式编程？如果说java8才支持函数式编程，那java8以前算是什么编程呢？不要着急，以下是我的一些个人理解，在这里写下来。
函数大概大家都知道是什么，其实所谓函数式编程就是要大家像编写函数一样去编程。函数的特点是什么呢？最最重要的就是无副作用。什么叫无副作用呢？就像我们写的数学函数一样，我们的输入一定，输出肯定是一样的！比方说我们定义了一个新的运算规则函数，输入两个自然数，输出一个自然数。比方说输入1和9，会输出11，现实当中会由于我多次调用这个函数，然后我输入1和9，输入就变成了12吗？绝对不会！说来也算惭愧，其实我们经常写的代码就会有这种类似的问题。java是在2014年才正式支持这个特性。java8之前也算是铁杆的命令式编程语言吧，但是现在随着硬件水平的提高，命令式编程语言的优点不是那么明显了，相反函数式编程更加适合这个多核高并发的时代，所以最为流行语言的佼佼者，java也不得不跟随时代的潮流，支持函数式编程的特性。