2013下半年总结——该拿什么来拯救
13年的8月底，对我的的13年前半年进行了一个小结（2013，我平凡却又不平凡的一年），再次查看，恍如昨日。
那么这半年来，我又做了些什么呢？又有哪些让人心窄的事呢？
中间件
在这里，接触到了SOA，接触了EJB，接触了CORBA，接触了ESB。
那么什么是中间件：中间件是一个独立的软件或服务，和你所做的系统是相对独立的。
那SOA呢？这个提到的一个概念是面向服务编程，对于SOA看了一本书(SOA实践指南)，不在于懂了多少，在于真的看完了……
EJB我接触过2.0，3.0，但真正编过码的只有3.0。不得不说，3.0比2.0简单的不是一点半点。
CORBA就算用应该也是遗留系统了，但CORBA中的封装组件的概念还是很好的。
ESB，心窄的看了看JBossESB，更心窄的是项目中用的不是这个JBossESB，而是一个叫做MuleESB的东西。后面说经验教训的时候会说到这个。
后来就开始了我们的高校云平台的搭建工作。
云平台
之所以叫云平台，有一部分原因就是云这个字比较火。
下面一一列出搭建这个开发环境用到的技术：
dwz，一个中国人自己的前端框架，用起来真心感觉挺好用的，目前为止，我们项目中的界面需求都可以满足。而且学习成本也不高，上手快。不过在第一次加载页面的时候把所有的js和css一次性加载这个也导致了我们项目中集成的一个难题。
struts2，这个不用多说了吧，MVC中的C。
Hibernate（EntityBean的实质），我们项目中的完全用面向对象的形式进行持久化，导致了项目初期很不适应。而且Hibernate性能优化相对来说比较麻烦，一个很简单的页面，往往要发很多语句。由于是分布式，关于Session关闭的问题到最后也没有解决，采取的解决方案是所有数据都进行手动查询。
EJB，业务逻辑层用的是无状态的会话Bean，消息驱动Bean现在还没有用到，但随着项目的进展，一定会用到这个的。而消息中间件，我们会采用ActiveMQ（apache开源项目）。
事务，关于EJB的事务，我们采用的是容器自管理的事务。但这种事务是二阶段提交事务，这种事务在一个系统内用还行，但如果是分布式，这个肯定就不够用的，而是要用补偿性事务，精力原因？也因为这种需求暂时没有那么大，所以这个暂时没有考虑……
spring，这个就不多说了吧……
项目管理：到目前为止用的都是禅道，源于贾总以前对其的研究，很快就上手用了。但这次迭代完成后（我们采取的开发方式是Scrum），会以我们项目小组作为试点，开始使用JIRA，通过学习人家的软件，不得不说，真的很牛！！！
Maven，一个jar包管理工具，这个东西的使用其实很简单。但是提前约定很重要，这也应了Maven的设计初衷，约定优于配置。在这里还进行了nexus的搭建（私服）。
Jenkins，这个是一个自动构建的工具，但是目前还没有真正投入使用，原因其实就是没有写好单元测试。而对于EJB的单元测试，真心有点蒙，不过最近看了一篇博客，有一个叫做EasyMock的测试框架，后面打算看下这个东西。不过最后一次坤哥开会，说要强制将自动构建用上，不论单元测试是否有，都进行自动构建。
eclipse，说到约定优于配置，那么我们也对eclipse进行了统一。通过一个人对eclipse进行配置（注释、样式、编码、插件），这样的好处也是不言而喻的。
dwr，ajax框架，在我最初提出要使用这个的时候，其他组员对其兼容性提出了很大的质疑，现在dwr最新的版本是3.0，我用3.0对目前主流的浏览器进行了测试，发现3.0对于主流浏览器都可以完美的兼容，如果你没有很高的性能需求，就别再去比较它与其它的区别了，直接用这个吧，简单，易用，兼容性好~~~PS，我觉得dwr得给我发点钱了，哈哈
shiro，一个权限框架，可以让你很方便的实现控制到页面按钮。
sso，单点登录，也是我们最近碰到的一个问题，目前正在攻克中，静待佳音吧~~~
confluence，一个wiki管理工具，不得不说外国人的设计真的很牛，你可以不用这个工具，但这个软件的你必须得看看人家的设计。
Java本身
除了上面说的这些，还对Java的语言本身的东西有了进一步的了解（因为要给其他人封装工具类）：
...，在方法的参数后面加三个点，就是说可以传入任意多个这个类型的参数。
容器，要封装，如果没有容器，那你就应该自己写个容器了，没有真不行。
泛型，有了它，让你封装起来得心应手，用好了，泛型真的是个宝。
虚拟机，虽然还没有系统的看一本书（计划中），但是现在在给别人解释的时候，总是会说类似它们不在同一个虚拟机内这样的话。
ClassLoader，调用方法在传递class的时候，会改变ClassLoader（自己猜测）。
Java中的传值、传址，虽然说这只是一句话的事，问谁谁可能一度娘就给你回答了，但是真正遇到问题，你真的会考虑是因为远程而将本来应该传址变成了传值了么？
这个环节，就是一个又一个小的知识点，但就是这一个又一个小的知识点，让我对Java有了一个深层次的了解与理解。
经验教训
如果要我说这个项目我学到的最重要的是什么？那么我会说是学习方法，这也利益于和贾总一起搭伙。
如果要我说这个项目我最心窄的事是什么？那么我会说是JBossESB，最后用了个轻量的Mule……
如果要我说这个项目我最骄傲的事是什么？那么我会说是真正体会到了开发一个分布式要付出更多的努力，要遇到更多蛋疼的问题，这也就是为什么有人曾说过，能不分布，千万别分布……
现在来对上面的进行一下解释：
因为之前看的东西，都是有视频可看的，我们也习惯了看视频去学习。猛的没有了视频，让自己找资料去学习，难免会在学习方法上有些偏差。我的偏差在于对于一个新事务的学习，首先是去百度直接搜索，可是后来我发现，贾总不是这样的。
对于一个全新的事务，他是大致在网上搜一下，然后就是去官网上面开始看了，后来我弄的几个东西（dwr，jira，greenhopper等）就是按照这个思路去做的，发现其实我们去看那些纯英文的网站的学习效率，要比我们看那些我们能看懂的度娘出来的不靠谱的网页快多了。
之所以JBossESB流产，源于我太懒，省事，没有对目前流行的所有ESB进行一个对比。其实这个也源于我们的应用服务器用JBoss，用JBossESB的话可以直接就用一个应用服务器了。因为JBossESB是基于消息的，而基于消息就对实时性要求的不是那么高，其实在看到一半的时候，就向贾总提出过换，但没有换成。而且在例子方面，做的也不是很好，只是一直在对它给的例子进行修改，没有真正放到Eclipse中进行运行过，种种原因，致使JBossESB即没有被应用，还用了那么长的时间，如果一开始就看的是Mule，那么肯定用不了那么长时间。
所以前期调研很重要。
因为分布，所以原本起作用的lazy（hibernate中的）却总是发生Session关闭的问题。因为分布，原本起作用的级联操作也出现了各种各样的不起作用。因为分布，我们不得不解决一个SSO的问题（就是不分布也得解决）。因为分布，出现了页面的样式丢失问题。因为分布，我们不得不去了解什么是补偿性事务。因为分布，原本的传址，却意外的变成了传值。
但庆幸我们一一解决或正在解决。
项目的不足
最近没事看了看百度沙龙，发现我们做的东西和他们做的东西很像。但人家解决的问题是我们想都没有想过的：
Sql优化作为一个AOP插入到程序中，每进行一次查询，对其进行一次分析、记录；
面向集成的架构（如果不知道这个词，那么去看下百度沙龙的第35期吧）：这个概念其实我们最初就想做一个这样的东西，最初的设想是用工作流或者模板来实现这样的一个东西，但项目一开始，这个想法就被抛的不知道有多远了。
远程增量与全量部署：一个正在跑的系统，你把它复制到本机上往往是不能用的，通过这个就可以实现在本地进行远程编程，个人感觉更像云编程。
开发难度，我们一开始的目标之一就是简化开发难度，虽然现在开发难度简化了一些，但是学习的成本依然还很多。不过引入坤哥开发的代码生成器后，开发难度又有了一定程度的降低。
项目部署启动时间高于开发时间的10%，百度员工采取的解决方案为通过JVM的Agent进行扩展。动态进行Class Loader的字节码分析后，进行扩展修改从而实现脚本式模式的开发实现。不懂？好吧，我也不懂。
自己的不足：
上面与其说是在说项目中的不足，不如说是自己的不足。
对于底层知识的匮乏，从某种程度上限制了自己对一些技术的发展。
一直在说我们不要做码农，要做管理，可是管理之后呢？适时的往底层走一下，多看看底层实现，别一直停留在应用层了~~
在书籍的涉猎上，远远不够，所以最近在学着利用自己的闲暇时间来看点小书，如果你不知道自己应该看什么，那么给你推荐一下我们勇哥的书单吧。自己看的书太少了，称不上书单，就不列了吧~
展望
1. 找个好点的工作；
2. 多看几本书，争取下次总结的时候也有一个书单；
3. 找点资料，看下那个一直被自己提及，但始终未看的大数据；
4. 将项目上用到的东西，都好好沉淀一下（最重要的）；
5. 往底层走走啦，不想一直飘在应用这一层。
6. 年底回家，给老妈买个电动车。
最后，在这里祝大家越来越好（当然包括我），新的一年，新的展望，一切马上有~~~