关于我
从项目成立，到单独成立一个公司来做，差不多也1年多了。摸着石头过河，当然免不了会踩一些坑。感谢这些踩过的坑，我们也在慢慢的成长。有些故事就算别人说过一百遍，也不及你亲身经历一遍来的更有收获。
项目需求混乱，拍脑袋想出一些东西，花大力气做出来，到现在剩下的没几个有用的。编程方式混乱，bug横飞，上线前还在添加新功能。手动部署频频出错，每次发布版本都是一场”恶梦”。听起来就像是软件工程里常见的反面教材。没有经验不怕，但要学会反省和总结。
在动手开始任务之前，现在我都会在心里问几个问题：这个任务可以解决什么问题，要解决什么问题。按照布置的方式完成任务有没有问题，这个功能有必要么？任务的本质是什么，有更简单的方式完成任务么？之前的遇到过类似的需求么？网上会有相关的有帮助的资料么？只有抱着对所做的事情更细致负责的态度，过后才能少出点问题少踩一些坑，磨刀不误砍柴工嘛。并且，随着大家的共同努力，现在的功能发布也进入了一个比较有序的状态。编写代码的时候，也会尽量站在可维护的角度思考。项目发布也改成了自动化发布。就目前看来，软件工程方面的问题得到了很大程度的缓解，最明显的效果就是bug数量明显减少了，返工的次数也降到了很低。
当然一个项目的成功，仅仅是做出一个可以用的软件还是远远的不够的。用户的需求才是软件的生存之本。新的一年里，我们的首要任务就是，在做好现有客户的情况下，挖掘出新的需求，新的客户。不断的探索，不断的改进。在现实的市场中去寻求突破。
新来的测试，注册账号登陆后提示权限不足，发给我说让我有时间看看。我把收到的用户名密码粘贴到浏览器中进行登陆，果然提示没有权限。于是在本地debug了一下，发现用户的权限对象为空。然后把执行的sql放到数据库查询了下，发现在表中此用户是有关联的权限的。于是就郁闷了，找其他同事帮忙看了看。 调了半天，发现此账号在用户注册的时候首字母是大写的，即数据库中存储的数据是首字母大写。然而却用的是小写登陆。因为数据库查询设置的是大小写不敏感的，所以登陆是没有问题的。但是，通过首字母小写的主键ID查询到的user对象的主键ID，被“神奇”的设置成了首字母小写。而并没有按照数据库中存储的那样首字母大写。这就导致了user对象的主键是首字母小写，而从数据库中查询出的user的关联对象role的外键userId，却是按照数据库中的那样为首字母大写。这就导致了user对象的主键ID和role对象的外键Userid不一致，从而引发了上述的问题。
我们的解决办法也很简单，在用户注册时（save user）和登陆时(query user)，统一把user id转换成小写，问题就解决了。因为靠用户输入的主键目前只有userId，所以其他应该没什么问题。前面，在输出hibernate的sql语句时想把参数也带出来。按网上的办法死活没起作用。最后看源码发现，在没指定log 的provider的情况下，log4j优先于logback.于是在maven中把 log4j exclude的掉，问题解决。
突然发现有3个月没写点什么了。看了一下最近的一篇文章。感觉自己的思维好跳跃额，想到什么就写什么-__-！
前面做了一断时间和其他公司接口对接的工作。从一开时的茫然失措到后面慢慢的也有了自己的一些心得。 这段工作经历让我认识到了，有些道理之所经典，之所以大家都常提。因为确实是有道理。听起来好像是废话，但是我觉的就是这些简单的道理，只有你身体力行的去照做了，回头反思你才能体会理解。
其实当你在没有任何相关经验，但又必需靠你去完成一件事情的时候。你所能做的就只有是多花时间，多花心思去尽量的把事情想的更周全。当然，如果你的资源够充足，经验够丰富，任务完成好的可能性会更大一些。但就我的经历看来，其实对待事情的态度才是最重要的一个因素。和我们配合的公司，在软件方面的资历比我们公司强很多。和我配合工作的人的经验肯定也比我更丰富。但就前一段时间的工作而言，很明显的是我们出错的次数反而要比他们少很多。除了对待事情的态度不同之外我想不到其他理由了。因为才参加工作不久。刚开始接手工作的时候，可以感觉到不管是上司还是合作的同事，有意无意都会透露出一种不信任。出了任何问题都会首先质问我。然而随着工作的进展，每每的发现问题的制造者都是对方的时候。也可以明显的感觉到大家对我工作的信任感逐步的在增加。当然也不是说，我就没有过出现过什么岔子。但我敢说的是，我一直在踏实的对待工作，尽力的避免问题。
前面工作不忙的时候看了很多的书。最近又换了一个项目和一群经验更丰富的人在一起工作。再回头去看之前看过的一些东西的时候。感觉认识又不同了，书中概念更加的清晰了。虽然曾经看过了一些书，也试着写过一些笔记。但现在看来，以前的笔记感觉就像是在记流水账。因为我自己也知道这种情况，所以也一直没有想过要post上来。没事的时候也喜欢瞎想，经后争取结合自己的经历和思考，再多记录一些。
Eclipse用了好多年了。回想起来，感觉它发展的好像不是很明显。界面功能什么的基本也没怎么变过。不知道是不是免费的原因。其实好早就闻名idea这款IDE了。但以前一直沉浸在免费和自己组装开发工具的“快感”中。也忘记了是什么起因，就决定转而使用idea开发。事实证明这个选择是对的。
到新的项目工作了一个月了。感觉想做的事情很多，又不知道该从何做起。刚来的时候看到遗留的代码，心中还不免嫌弃。但看看这一个月自己写过的代码，也不免偷工减料的地方。通过工作的实践,刚好检验了自己以前的一些想法和认识。有对的地方，也有不对的地方，也有待修正的地方,也有新的收获。而且依靠以前的知识累积，也能很清楚的认识到自己的不足和团队的不足。这是目前最庆幸的地方。
编写程序的最基本要求是完成给定的需求。而代码的可读性往往是最容易被忽略但也是相当重要的一个方面。因为可读性往往决定着程序的可维护性和可扩展性，而这些因素会间接的影响到项目的成本，甚至能够决定项目最终是否能够成功。Guava包含着大量精心设计的API，凝聚着优秀的编程实践。学习和使用Guava可以促使写出更易读、更易扩展的代码。
近期由于部门变动，被分到了一个新的项目中。只想感叹一句，终于有机会可以写代码了…从升本到现在工作1年，仔细算算已经有3年没有好好的写过代码了.工作的这一年中(省略)。接下来想利用参加这个新项目的机会，把前面学到的东西运用到实践中去。前些时候偶然发现了Guava这个东东。经过一些了解以后，不但刷新了我对编程的理解，也激起了我对函数式编程的兴趣。虽然用java来实现函数式编程问题还很多。但不妨碍Guava这个优秀的类库给程序的可读性、可维护性、可扩展性带来的提升。官方文档 GuavaExplained 老是被墙 :(
去年刚入职那会儿,给自己定下了读40本书的计划.到目前为止,计划已经执行了一半了.通读这么些书,感觉自己读书的速度有所提高.原因:1.很多的思想和概念会重复,平时也会看些技术博客和网站.随着知识的累积,慢慢的”新”的知识会变少; 2.读书时目的性会更强,跳读.以前,看书比较浮躁,也会”跳读”.但这两种跳读是不同的.因为现在读书时的心情会更加的平静.而且头脑是抽离思考的.就像刚到一个陌生的地方,感觉每跨一步都会小心翼翼.一旦熟悉了过后,走路便会成为本能.更多的精力就可以放在更有意义的事情上了;3.会有意识的提高自己的读书效率.
以前调试js代码都是用FireBug,一度让代码的编写轻松很多.最近又开始写点小东西,顺便研究了下Chrome DevTools这款谷歌浏览器自带的调试工具.于是果断抛弃了FireBug转而使用Chrome DevTools. 它不但提供了html,css,js代码的审查和改写这些基本功能.并且还提供了各种类型断点、各种属性的查看.还能让你从内存、cpu使用、页面渲染等各角度全方位的审查你的应用.当然还有很多高级功能,感觉都可以单独写本书了.最赞的是详细的文档Chrome DevTools,还有配套的视频(英文)!!
前段时间,用js写了一个自定义的多选控件.完成基本功能之后,花了好几天来优化程序的结构和性能.主要目的是把以前看到的、思考过的东西付诸于实践.读书的时候写的东西多,没耐性看书.后面又变为看的多，反而懒的去写.很明显都是不好的.于是就动手写了写.js部分改的比较多,css目前就没什么动力修了.代码放在了github上Mselect.