单位一个项目是基于Thingworx的，但Thingworx本身可视化方面很弱，难以满足要求。同时又期望开发工作可以平台化、自动化，以降低运维、人力的成本。所以在这一年，开始自己动手搭平台，现在将陆续记录一些搭建历程。
一、平台选型
原本期望有一个现成的开源平台，在大概两周左右的时间里，试用过很多平台，JeeSite和EOVA是其中最出名的两个，分别代表了Spring和JFinal阵营。JeeSite中MyBatis使用xml管理所有SQL让我难以接受（个人承担不起初期反复生成维护SQL脚本的成本）；EOVA因为用视图层具有使用数据生成模板的逻辑，但当时又看中了AdminLTE的界面（正好用于看板和仪表盘的应用系统），所以难以短期理清模板逻辑并迁移到AdminLTE上。
后来在网上搜到一个JESNG，就是JeeSite使用了AdminLTE。本打算用它先开发初期版本，但是因为Thingworx使用PG数据库，JESNG虽然使用MyBatis，但是用了很多mysql特有的函数，所以也放弃了它。
那么就只好自己搭平台了，虽然会慢一点，但其中益处，又是不能言喻的了。
框架上注意到了去年刚刚流行的SpringBoot和国内开源社区已经流行了很久的Rails风格的JFinal。JFinal3.x版本中更是有自己的Template功能，记得几年前还是推荐集成beelt的（闲话：记得当年尝试beelt的时候，还记得作者在手册里写当初在这上面花了太长业余时间，很多同事研究了云计算、大数据，都变成高端人才了）。
一方面，相比ORM我在数据库操作上更倾向于ActiveRecord，另一方面，我在集成测试上又非常羡慕Spring可以在JUnit中自己加载所需的上下文，所以我用SpringBoot集成了JFinal。除了集成测试之外，全部功能都依赖于JFinal，这种行为有得有失，之后叙述了。
二、初始的错误
我理想的开发场景是这样的，首先我（或者任何人）有一个想法，和贝多芬谱曲时能听到乐器在演奏旋律一样，想法内容包括了我在一个什么样的场景通过怎样的操作步骤完成了怎样的事，是我对操作场景的“幻想”。
随后，我在幻想场景时，包括了所有的顶层细节。我在做什么时将提示我成功，在做了什么时系统会提示失败，系统会以怎样的形式和内容告诉我发生了什么，并指导我下一步做什么。这段消息的弹窗是需要用户点击【确定】按钮还是现实3秒自动淡化消失。除了不涉及系统之外，我“幻想”除了整个单个操作的细节。
然后我将组织测试用例和测试数据，在文档层面，它就是我的需求，在系统层面，它是一组包括删除已有数据库，创建测试数据库，创建数据结构并初始化所有测试点数据的数据库脚本。
接下来，我将根据测试用例开始编写测试代码，编写测试代码时我将决定有哪些类需要被建立，哪些方法将被通过何种形式调用，虽然在编写时测试代码时这些类和方法根本就不存在。
完成了测试代码后，我就开始执行测试代码。我单击一个执行按钮，测试数据库被删除、重新建立并初始化，所有的测试都失败了（因为我还没开始写系统代码）。
接下来我开始编写系统代码，每次仅完成可让一个测试通过的代码，反复执行测试代码。直到所有的测试都完成。
UI层：UI能力相对薄弱，还未想好集成测试的办法。但是如果所有的UI层只依赖于我“幻想”的抽象，而不依赖于后台Java代码，那么失败的几率应该还是比较小的。
但是刚开始时我并没有这么做。我一开始设计了用户、角色、组织机构、部门四张表，期望先开发后重构，很快就因为各种原因陷入混乱，我再次陷入无穷的细节当中，而不是按部就班只做那些最重要的事情。
三、过程中的收获
这个过程中，也接触了一些框架，以下是一些肤浅的心得：
layui：我用它很快实现了一个JS树，但是它目前版本还不支持各种节点操作（作者也在官网上写了）。
zTree：这是一个功能非常全面的树框架，基于JQuery，Demo文档中向我展现出了所有我能想到的一个JS树应该有（或可能有）的功能。
四、解决问题的办法
接下来我准备首先复习一点UI知识，使用AdminLTE过程中非常依赖例子，没有完全掌握原理，在构建“幻想”时捉襟见肘。其次就是拖缓进度，从TDD重新开始。如此也能形成一套非常有意义的文档。
最后，就是设计上的学习，在做登录功能时，其复杂程度超过我的想象。
很多人都实现过登录，因为它同时包括界面、表单、跳转、数据库、Session。因此，登录同时也依赖于系统的UI、控制层、数据库访问实现。而在真实的系统中，登录不仅仅是比对密码，还需要加载角色、菜单，所以就牵涉了特殊用户（管理员）、开发模式（不校验权限）等场景。
当然即便如此，世界上已有的系统已经无数过实现过这些功能了，甚至已经有Shiro等优秀的开源框架了。所有的问题，都源于自己知识和经验的不足。陆续地，我将把这些经验上的不足，以及新的经验记录下来。