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，給配置管理造成很大的麻煩?，F在回想，以前很多的項目，為了統一天下，苦口婆心，說服教育，威逼利誘，犧牲色相，該用的手段都用上了，真是個頭疼的、吃了不討好的事情。
閱讀全文
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日
摘要: 在電子商務網站的設計、開發當中，客戶在對自己的運營理念一無所知，卻對首頁關注的興趣遠遠大于運營、內容、數據、功能，人們不僅為個人喜好所困，又錯以為網站上加幾個功能，web2.0概念，就是運營。當他們看到絢麗的網站是，產生一種強烈的幻覺，以為消費者會蜂擁而至，特別是網站虧損、經營不利時，竟然認為改版、加功能可以扭轉頹勢。
閱讀全文
2008年11月12日
摘要: 在復雜的前端應用中，要避免簡單的思考問題，簡單的行為，特別是在大型的電子商務應用中，無論是底層框架代碼還是高層的業務邏輯代碼，沒有架構，重復、臃腫、繁雜、沒有重構的代碼將會產生致命的災害。
閱讀全文
2008年11月3日
摘要: 從需求的角度講，在電子商務應用當中，cookie的靈活應用對于用戶體驗非常重要，可以記憶用戶的經常重復性的操作，個人偏好，等等?？上Ш芏嗟膽茫⒉簧瞄L使用cookie.經常是輸入一大堆搜索查詢條件、可選操作后，再回退、刷新、再次登錄后沒有了,還要重新輸入，非常惱火。所以我覺得能夠智能化的記住用戶的常用操作，是非常體貼用戶、讓用戶感動的事情。
閱讀全文