2021年4月2日
摘要: 苏标主动安全协议在2021年迎来一个新的版本粤标主动安全协议标准, 这个标准是基于jt/t808-2019协议框架的. 作为一个面向全国的主动安全平台不可能只能接入粤标, 还要兼容苏标.苏标主动安全协议本身就是一个比较复杂的混合协议, 将808协议指令和报警文件数据流混合在一起, 给开发者造成了不小的麻烦, 有点烧脑. 同时由于其本身业务的复杂度, 使得开发人员必须要有一定的开发经验, 结合比较好的设计模式才能构建出来性能良好的网关. 一般需要几个版本的迭代, 必须要在实际的大规模车辆接入, 运营一段时间积累足够多的设备经验, 才能逐步的成熟稳定下来. 没有一定规模的设备接入, 就能做出高性能的网关是不可能的事情.单纯的采用springboot netty,只是一个基础, 后面的代码我们仍然要有扎实良好的设计功底,才能做出一个优秀的主动安全平台.
2017年4月16日
摘要: 使用java语言开发一个高质量和高性能的jt808 协议的gps通信服务器，并不是一件简单容易的事情，开发出来一段程序和能够承受数十万台车载接入是两码事，除去开发部标808协议的固有复杂性和几个月长周期的协议bug调试，作为大批量794车载终端接入的服务端，需要能够处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理等。如果没有足够的网络编程经验积累和深入了解部标808协议文档，自研的gps服务器往往需要半年甚至数年的时间才能最终稳定下来，这种成本即便对一个大公司而言也是个严重的挑战。对于808协议的解析处理，需要编写自定义的解码器了，目前netty提供了多个基础编码器可以供开发者进行继承和拓展，开发的时候，需要了解这几个解码器的主要作用，主要用于那些通信数据传输的场景。
2017年4月15日
摘要: 部标监控平台jt808协议软件开发技术文章索引,主要涵盖了基于java技术开发jt808部标标准的方方面面，实现了部标808协议、部标809协议和部标796、794标准。
2016年9月13日
摘要: 开发企业级的部标gps监控平台，投入的开发力量很大，开发周期也很长，选择主流的开发语言以及成熟的开源技术框架来构建基础平台，是最恰当不过的事情，在设计之初就避免掉了技术选型的风险，避免以后在开发过程中，不断的填坑走弯路，以至于整个团队被坑埋掉。做gps平台这么多年，以前就了解到一些开发团队过于关注某一种语言的优势，比如过于选用go，erlang，python,php等技术，最后团队熟悉这些技术的关键人员离职了，都没人接手，不能不说是个悲剧。所以说平台的技术架构选型要注重的是稳健，均衡而不是偏激，而springmvc4, mybatis4, hibernate4就是gps监控平台软件开发的理想框架选择。
2016年4月25日
摘要: 对网上搜集的gps部标软件平台的开发技术文章进行了一个精华索引，免得重复搜索了。
2015年8月19日
摘要: gps软件平台和车辆管理系统的开发是一个相对垂直的行业应用软件开发，和一般的管理信息软件开发有很大的不同，是一个软硬件一体化的平台，数据来源于gps设备发送。依赖的技术要包括socket通信、gps定位、通信协议解析、gis地图开发、以及常规的前后端web技术等。同时还需要了解交通部的行业标准，如jt/t 796、808和部标809等标准。
2012年12月26日
摘要: 无论是开发地理信息系统还是开发视频监控系统，都会面临者一个问题：界面如何设计，实质是信息数据的如何组合搭配的问题。因为我不仅仅是那别人的地图引擎，如mapinfo, mapxtreme还有gmap.net, 百度，高德地图等来做个地图和坐标的展示或者车辆轨迹的展示，那样的话，我们的产品还有什么竞争力，还有什么差异化，对于用户来说有什么用处呢？
2012年10月25日
摘要: 我经常对我的同事们讲的一个观点:在it界成功真是太容易了。
1.最容易成功和获得一份不错薪资的行业就是it，只要你有学习能力，因为你所有要学的东西，都在网上，通过google可以获得你想要提高的所有东西。
2.只要你坚持不断的写程序，少说多写，你就很容易脱颖而出，因为你周围大部分人都在玩，有的在看垃圾小说，有的在聊天和微博，有的在低头玩弄智能手机。很少有人能够驱动自己从头到尾，从前端到后端，从页面到数据库，独立写一个完整的软件，并为之不断的改进。
2012年10月12日
摘要: 我们团队的开发人员在查询资料的时候，都偏爱使用百度，而我喜欢google, 有一些争议，他们说百度对与中文的搜索质量比较好，我有点怀疑。正好最近在做地图开发，经常搜索gmap.net这个关键词，发现百度对于博客园和blogjava的博客文章的收录特别的差，就是输入文章的全名，也找不到，而在谷歌上去可以快速的查询到。在网上看了百度的收录说明，发现百度的收录特别的慢，甚至是干脆不收录。你如果自己有个网站，还需要提交给他们，特别的愚蠢。比如在谷歌上输入gmap.net这个关键词，可以搜索到博客园和blogjava中的几乎所有的关于gmap.net的原创优质介绍文章。而在百度上去直接转到了csdn这样的垃圾盗链网站。
2012年10月11日
摘要: gps坐标在基于wgs84坐标系统的地图上显示出现偏移，误差很大，而且不是线性的，网上有人给出算法公式，都是胡说八道，根本不好用，更离谱的还要根据不同的城市，进行不同的加偏，还有的提供了一个加偏数据库，瞎扯淡。
商业地图数据提供和服务提供商，都必须要到国家测绘管理部门，进行评审通过后才能在大陆发布，谷歌地图也也一样。地图服务器商都需将真实坐标的电子地图，加密成火星地图和火星坐标。
2012年10月9日
摘要: gmap.net是一个好的开源地图程序，封装了各种网络地图引擎，统一了操作，但要把它用于实际的工作中，还需要在基础之上进行大量的开发工作。
1）虽然解决了最底层的地图获取、投影和瓦片展现的问题，但是可扩展性不好；
2）图层、图元、文字标注的关系比较弱，需要重新封装，按照传统gis引擎如arcgis和mapinfo的方式来改造；
3）业务信息的集成、业务数据的展现和操作没有考虑，如图元和业务信息的关联和信息的传递和事件触发、数据交换，需要提供一个粒度更大的开发包，才能非常方便的操作；
4）只能本地持久化，无法满足网络版的软件需要考虑将地图同步到各个客户端的要求。
2012年6月22日
摘要: 人们在没有亲身体验和互相对比的情况下，说出的话都是不可靠的。如果想获得最真实的市场调查资料，最好就是拿几款手机，站在cbd的人流大的地方，请人摆弄。
2012年3月4日
摘要: 谷歌厨师的创新热情有多高？据不完全统计，他们从2007年到2010年，就开发了超过3000种甜品，而菜品的数目则多到无法计算。
如果有机会去谷歌食堂蹭顿饭，懂行的人都表示会“兴奋地搓搓手”。
2011年12月15日
摘要: 为什么中国老出张艺谋，陈凯歌这样的傻逼导演，老是不知道何朝何代，人不人鬼不鬼的电影，更操蛋的，还有那么多人，争先恐后的去看他们拍的傻吊电影，票房一路走高。
2011年1月23日
2010年12月30日
2010年11月8日
2010年11月7日
2010年11月4日
2010年10月31日
摘要: 标准和流程来源于成熟的运营经验而不是意淫。现实情况是，有很多异想天开的、却又雷打不动的流程都是出自纸上谈兵的书生，而不是在一线奋战的将军和士兵。
2010年10月29日
2010年10月28日
摘要: 很多人，都说自己下属的执行力不够强，却很少反思自己的执行力，真正好的执行力，来自己于对自己的不断反思，不断改进。self-study, 这是个了不起的能力，可惜国内的企业都不重视，重视看重一些很容易看得见，却没有什么作用的东西。
2010年10月23日
摘要: 很多人没有创业的经验，毕业后直接进入到了大公司，直接融入到大公司中的有条不紊、稳定、单调的运转机器当中，充当生产线上的一个节点，所以无法知道，也没有体会到标准、流程的好处，直接感受到的个人是强行地被标准，被流程化，失去了创造力和灵活性。
但有是矛盾的，当他们厌倦了这一切的时候，又跳入小的、创业公司充当一些高级职位的时候，又开始对于公司初创时期的凌乱、茫无头绪、不专业、灰暗、不择手段的运作模式感到十足的厌恶和没有心理准备，但是又没有力量去把自己以前的公司的模式带入到新的公司中。
这是因为他们根本没有经历过这样的过程，只是前人栽树后人乘凉而已
2010年8月29日
摘要:
醉过方知酒浓，对于随意的抽调人力，组合出来的团队，往往是造成项目失败的根本原因。而单纯的要求项目经理的无限完美，是一种很愚蠢的行为。
2009年6月13日
摘要: 大凡一个好的it公司，必有一个牛逼的、有个人魅力的cto，大凡一个烂公司，必有一个昏庸无能、圆滑世故、东郭先生的cto。
2008年12月26日
摘要: 以下是jquery1.3的主要变化，推荐大家试用！
选择符引擎：有关选择符的代码已经全部重写，主要是在性能上有所提升，因为sizzle是jquery作者john resig新写的dom选择器引擎。好称是最好的引擎了。如果想自己设计一个的基于新的选择器语法的api，可以直接用sizzle，完全可以基自己的business开发底层脚本库。同时得益于新的引擎，选择器支持:not(div,p)，增加了一个closest方法，用来找最近的一个匹配选择器的父元素。
dom操作（append/prepend/before/after）：大部分代码也都重写了，包括一些执行嵌入script元素的逻辑。
.offset()：另一个经过重写的方法。
事件触发：事件被触发后会沿dom向上冒泡——而这可能带来问题。
新版的拖放（drag and drop）的性能将有一些提升
2008年12月22日
摘要: 从以下几个方面进行比较：
1.从技术方面对框架的优点和缺点进行分析
2.从ide支持的情况进行对比分析
3.从精通那个框架更有利于找到工作进行分析
4.从用人单位招聘的job数据进行分析，看那个框架出现在招聘要求中的次数更多
5.从亚马逊上的看那个框架出的书最多
6.从google 搜索分析google trends看那个框架搜索最多
2008年12月18日
摘要: 我在javaeye网站上看到一个很有意思的帖子，【请先不要讨论细节好吗】，问题却很常见，每个公司，每个团队都有这样的现象。这样的帖子很少，发帖者是不是很勇敢？至少引起了我的共鸣！在it管理中，我见过很多的leader，他们经常的口头禅是：“一定要细”，或者“你这个在细化一下”， 但什么是细，没有下文了。
我在想，很多人一开始就追求细节的完美，是不是因为搞技术的人，逻辑性太强，非黑即白，不懂变通，没有细节，就无法往下走。有关系呢？
2008年12月15日
摘要: oracle一直致力于全文检索技术的研究，当oracle9i rlease2发布之时，oracle数据库的全文检索技术已经非常完美，oracle text使oracle9i具备了强大的文本检索能力和智能化的文本管理能力。oracle text是oracle9i采用的新名称，在oracle8/8i中它被称作oracle intermedia text。使用oracle text，可以方便而有效地利用标准的sql工具来构建基于文本的新的开发工具或对现有应用程序进行扩展。应用程序开发人员可以在任何使用文本的oracle数据库应用程序中充分利用oracle text搜索，应用范围可以是现有应用程序中可搜索的注释字段，也可是实现涉及多种文档格式和复杂搜索标准的大型文档管理系统。oracle text支持oracle数据库所支持的大多数语言的基本全文搜索功能。
2008年12月11日
摘要: 使用jquery不仅要泛泛的去用，还要不断的结合自己的业务的写一些插件，才能理解jquery api设计的风格 simple and consistent.
2008年12月2日
摘要: 我关注springside，是因为我喜欢最佳实践，在团队中，我喜欢搜集、研究、制定、实施最佳实践、项目规范。我知道，在一个团队中，让大家follow n多的最佳实践，很不容易，特别是团队成员背景不同，或者新建的项目团队，有的研究struts, 有的学习seam, 有的懂spring, 有的不懂，有的喜欢hibernate, 有的擅长ibatis，连ide用的也不一样，有的用eclipse, 有的用idea，给配置管理造成很大的麻烦。现在回想，以前很多的项目，为了统一天下，苦口婆心，说服教育，威逼利诱，牺牲色相，该用的手段都用上了，真是个头疼的、吃了不讨好的事情。
2008年12月1日
摘要: ibatis在项目开发中，无论是企业管理还是电子商务，productivity作用都非常的大，淋漓尽致的体现了模板的好处，将sql的繁杂的语法和查询条件参数数据清晰的剥离出来，无论是开发速度和代码的易维护性上，都是无可比拟的。我对于ibatis的源码进行了改造，起名为xibatis。主要在分页上做了增强，并以后会在模板语法上做改进。
2008年11月28日
摘要: 两个很棒的javascript framework, 提供cheat sheet pdf下载地址，可以很清楚的比较两者语法的简洁性和dom操作的方便性。
2008年11月27日
摘要: 基于struts2的开发，如果没有足够的经验和规范做支撑，并不能带来还多的好处，如果失控，一样和jsp servlet泛滥，这一点需要警示。
2008年11月23日
摘要: ext.form.combobox 是基于输入框封装的widget，很灵活，代价是易用性非常差，特别是针对复杂的多级级联框。
调用者需要针对自己的需求做一下灵活的封装，来降低复杂度，让开发人员更容易调用，同时代码复用的程度更高。
无论是省市乡镇，还是商品分类，无论是两级，还是多级，还是同级多个child, api的行为都应当保持一致。
2008年11月19日
摘要: web前端工程师的定位，是由企业的策略所决定的，一般能有这个职位的，就表明一种态度，前端很重要。
但前端的东东很多，要求多和泛泛的要求，总想吃现成的，等于没有目标和方向，同时也营造不出想淘宝 ued team那样的氛围。
这其实是一种循环，氛围、态度、文化、思想，可以培养和造就一批企业所需要的人才，而合适的人才，又会反过来去营造这样的文化氛围。
2008年11月17日
摘要: 在一开始空手套白狼的时候，我们严格的分层，设计数据(data)、结构(strutcture)、行为(behaviour)、风格(style)，并绞尽脑汁的把要素粘连在一起，在随后的网站运营过程中，我们大多数的情况下，可能会改变风格、行为，少数的情况下，我们可能去重构结构，或者改变后端的数据定义，可以看出，以后的改进是局部的，增强的，不断提高交互能力和用户体验的。
2008年11月13日
摘要: 在电子商务网站的设计、开发当中，客户在对自己的运营理念一无所知，却对凯发k8网页登录首页关注的兴趣远远大于运营、内容、数据、功能，人们不仅为个人喜好所困，又错以为网站上加几个功能，web2.0概念，就是运营。当他们看到绚丽的网站是，产生一种强烈的幻觉，以为消费者会蜂拥而至，特别是网站亏损、经营不利时，竟然认为改版、加功能可以扭转颓势。
2008年11月12日
摘要: 在复杂的前端应用中，要避免简单的思考问题，简单的行为，特别是在大型的电子商务应用中，无论是底层框架代码还是高层的业务逻辑代码，没有架构，重复、臃肿、繁杂、没有重构的代码将会产生致命的灾害。
2008年11月3日
摘要: 从需求的角度讲，在电子商务应用当中，cookie的灵活应用对于用户体验非常重要，可以记忆用户的经常重复性的操作，个人偏好，等等。可惜很多的应用，并不擅长使用cookie.经常是输入一大堆搜索查询条件、可选操作后，再回退、刷新、再次登录后没有了,还要重新输入，非常恼火。所以我觉得能够智能化的记住用户的常用操作，是非常体贴用户、让用户感动的事情。