总结，坚定的前行

    时间飞逝，转眼两年，想一想去年毕业拿着简历在大学校园里憧憬着人生第一份工作，犹如昨天。有人说当我们感叹时间真快的时候，人就老了。哈哈 ，岁月催人老，人不得不老啊 ……

    近两年的工作是该做一总结了，总结过去展望未来嘛！

    始终做与电子地图相关的工作。先是研究导航算法，对于一个刚刚从信息管理与信息系统专业毕业的新手来说，还是蛮有挑战的，虽然时间不长，但是悟性还算不错吧。期间由一个师傅带着，这哥们儿不错，思维清晰的让人折服，总是能用简短的几句描述将复杂的蚁群算法概括清楚，后来算法遇到了瓶颈，java做底层算法是有些伤不起的，他因为个人原因离职了。导航引擎的开发被分为两个大的阶段，数据编译阶段，就是将普通的道路数据编译成结构紧密存储空间较小易于算法计算的中间文件。算法设计与实现阶段，就是针对已知起终点计算最优路径。这一过程让我深刻的理解了“程序=数据结构+算法”的真理。也让我亲身体会了大学学习的数据结构是多么重要，幸好当时学的并不算差。世间万物不过就那么几种数据结构就能描述罢了。而算法就有很大的随意性，是思维和智慧的考验。当我看到各种基于图的拓扑算法时，我还是惊呼前人的伟大呀！

    没做多久的导航，就遇到了瓶颈，起先是数据量过大，无法一次加载到内存，当然无法满足导航需求了。后来尝试将数据压缩，修改数据结构以节省内存，但势必造成计算的复杂度上升，依然达不到预想效果，再后来就考虑将文件分布式到其他主机，一次加载到内存，一个主机执行算法的主体部分，另外一些主机提供数据，但分布式不仅给程序带来复杂性，稳定性也受制于网络环境，最终还是不那么可靠。但这一次经历依旧很重要，先后尝试使用rpc远程调用，并发库和通信组件解决网络通信，数据分发，线程切换与任务分割。这个过程让我体会到分布式环境下的算法设计与任务分割是多么重要，我们需要解决的是：一个大任务如何切分成可以单独运行的小任务，又如何组织各个计算的结果，如何协调并调度这些任务。这一过程需要抽象当前事物，并从另一个侧面来找到任务执行的维度。

    但是因为当时刚刚出道，而且并不看好java做底层算法，或者说在这个行业里现在依然停留在做底层导航算法公司已经不多，就欣然停止了对这个领域的研究，转而进行应用开发。（因为毕竟学信息管理的，底层不是我的特长。）所谓应用开发就是使用公司提供的map api 开发一些与webGIS祥光的应用系统，如网点管理呀，人员监控定位或者车辆监控之类的。但地图的行业应用似乎是一个探索阶段，人们正在寻找电子地图的更多应用场景，所以往往需求不够明确，这个时候我们的工作多半是带有产品的性质，一方面我们推出基于自己对电子地图理解的行业解决方案，持续研发针对地图原生api的行业应用产品，另一方面我们关注客户的特殊需求，完成一些项目的开发工作。刚开始我们只是针对每个项目从零开始。渐渐的，我们注意到这种开发模式会导致开发和维护成本的持续上升，最后吞噬我们的利润。渐渐地我们意识到，开发一套行业应用开发平台是那么重要，开发平台 就是封转了通用功能的sdk,之后的相关需求就不再开发，我们向开发人员暴露了可调用的api和可扩展的基类。而这一过程让我意识到，应用开发其实就是不断封装和积累的过程。我们提高工作效率的唯一方法是不断抽离公共需求，将一些特性封装成工具，将一些封装成组件，再将一些过程拆分成不变和可变部分，使用抽象的方式实现这一过程。当一个应用需要重写的代码越来越少的时候，这个应用就会变得易于维护，开发成本也不断降低，团队的分工也变得更加清晰和单一。

   我们先后开发了地物编辑平台，人员定位服务。在这期间，我先后尝试使用googlecode提供的通用hibernate框架改写了公司ssh框架，为了处理延时操作，研究了异步消息jms，为了兼顾各个业务系统字段不统一，变化可能性大，研究了文档数据库mongoDB，这真是一个不错的数据库，有着关系数据库无法比拟的特性，高效的查询和结构化的bson存储，为我们平台的扩展性提供了极好的支持。不光如此，它还提供了地理索引，对我们业务有很好的支持。再后来，我们发现单纯的地物标注并不那么有意义，不能给客户创造价值呀！oracle spatial 空间数据库可以解决大多数空间计算问题，静态的地理位置信息被聪明的空间分析计算之后，再加上统计分析功能就能提供决策支持啦！哈哈  只是一个猜想而已了，目前没有需求表明他的成功。但多了这个功能我们的很多业务场景是可以使用的，当然有赖于大量的数据了。说到大数据，我渐渐发现那的确是一个不错的技术，他能解决之前不少的困惑。hadoop是我今后一段时间重点研究的技术了。

    学习是一种信仰，不断找到自身增长的新引擎，才能在思维的世界里勇往直前。内心的踏实总是自己给予的，永远不要指望环境有多好，只能努力让自己变得更好吧！