Linux下的编译开发

在Linux环境下的编程实践不是很多,使用C语言开发跨平台的应用对自己来说是件有些挑战的事情,需要慢慢积累很多相关的知识和经验。

首先,程序使用跨平台的图形库,Troll Technologies公司的Qt图形库是很不错的选择。包括QGIS、Tora、Terraview等平时会用到的开源GIS项目都是使用基于Qt的图形库实现,还有大名鼎鼎的KDE桌面和Google Earth也是基于Qt构建。Linux下常用的跨平台图形库还有wxWidgets,在Gtk+或X11界面上都可以运行,Linux上流行的Gnome桌面就是基于Gtk+开发,还有日常会使用到的GIMP 和Gaim也是使用Gtk+的图形库。

Qt提供Designer设计器,可以图形化设计UI界面文件,然后导入到开发环境Visual Studio或KDevelop里面编译为本地界面代码,Qt提供的跨平台C++类库图形库,可以编译运行在Unix、Linux、Win32等多种操作系统平台之上。

在Linux环境下由于使用GCC(GNU Compiler C)编译,配置依赖函数库的Makefile文件十分重要,使用make命令编译生成动态库so文件,还需要通过Mingw进行交叉编译生成Win32平台上运行的DLL动态链接库。如果使用VC调用,还要再增加一个步骤,首先把Mingw环境下生成的DLL动态库通过编译工具Dumpbin生成DEF定义文件,再用Lib命令生成VC可以调用的LIB库文件。

MinGW即Minimalist GNU For Windows,是C++头文件和端口库的集合,在MinGW环境下可以不依赖第三方动态链接库情况下使用GCC产生Windows32 平台程序。并且MinGW允许GCC程序使用微软标准C运行时库(MSVCRT.DLL),同时还提供W32api函数库来使用Windows32 API包含的文件和端口库。与msvcrt.dll相结合,就可以充分使用CRT(C Runtime)以及Windows32 API提供的函数功能。

至于Linux下C++的集成开发环境,还没有找到很中意的选择,Eclipse+CDT的功能组合局限性较大,而Linux下主流的开发调试环境KDevelopAnjuta的使用又还不太熟悉,项目代码还是使用传统的DDD(Data Display Debugger)进行错误跟踪。总的说来,Linux下的开发过程有着独有的优势和特点,尽管有时会感觉不像Win32平台下那样便捷,但最重要的是整个开发环境都是自由软件构成,而自由软件必定也是每一位开发者被赋予灵感与动力的源泉。

北京的Google坐标

用过Google Maps的朋友都会认为它很Cool。其实创建一个类似的地图服务站点,在技术上难度并不大,已经有较为成熟的开源解决方案。但是能像Google那样有原始影像数据和庞大的集群支持,不是一般站点可以做到的。

这次把Google Maps搬出来,是想分享一下比较有意思的Google坐标换算方式。Google Maps使用Keyhole公司提供的卫星影像,全世界众多大城市的卫星图片可以达到1m以下的精度。Google Maps的卫星影像使用等角正切圆柱的墨卡托(Mercator)投影,被预先处理成按照不同精度划分的影象金字塔,提供了0-17共18级的缩放等级并进行四叉树编码,每张卫星图都由切片成256*256像素大小的影像组成,根据用户请求的位置拼接组成大的影像图。

Google Maps的坐标使用QRTS这四个字母进行编码,如右图所示,一张图片被分成不同字母标识的4块,根据请求的位置逐级细化,最后达到所需精度的卫星图片。如果知道特定位置的经纬度,换算成Google Maps坐标并不复杂。首先将经纬度转换为弧度,规格化后使得变化区间在0-1之内,然后根据需要的图像精度级数确定迭代次数,进而计算出经纬度对应的Google坐标字符串。

按照计算公式,北京的经纬度以天安门作为地理标准坐标,位于北纬39度54分27秒,东经116度23分17秒。换算后得到北京的Google坐标字符串是trstrqqrqssttttrrrstq,具体对应的卫星影像地址为:http://kh.google.com/kh?v=3&t=trstrqqrqssttt 网上提供了C和Python写的换算程序,感兴趣的朋友可以一窥究竟,方便的把经纬度换算成Google卫星影像坐标。

Google地图及其他

Google所带来的最大影响,在于它一直用前瞻性的技术改变着我们对互联网的看法。最近使用GoogleMaps的API做了些小的实验代码,基本就是将标注在数据库里的点坐标显示在Google提供的卫星地图上,不仅可以显示点标记的详细内容,还可以显示各点之间的路径信息。基于LAMP结构的PHP代码有很多不错的示例,只需将SQL脚本包含的坐标及路点信息存储在MySQL里就可以读取显示在GoogleMaps上,如果使用JSP开发,GoogleMaps JSP Taglibrary项目提供了一组Java类库,将JSP的Tag标签转化为调用地图的脚本,大大简化调用地图API的时间,并且它还能够与JSTL相结合生成数据库驱动的动态地图查询。

之所以说Google有时在引领Web技术的走向,Ajax的普及应用就是一个极好的证明,最近试用了Google发布的Ajax的工具包Web Toolkit,这个工具包可以加在Eclipse环境下通过Java类的编写自动生成Ajax所需的脚本,实现类似Gmail的富客户端效果的界面风 格,只是感觉上手使用还有些不方便,但随着版本更新,这应该会是很不错的Ajax代码生成方式。

当然Google的核心服务还是互联网搜索,说不准下一个Google神话将在何时诞生,但有兴趣的朋友可以使用开源的Java项目Nutch实现一个自己的互联网搜索引擎,在Nutch里面包含有完善的排序算法和网络爬虫程序,构建一个简单的互联网搜索站点应该不会只是一个梦想。

Python初体验

对于脚本解释语言Python的兴趣,动力源自于对喜欢的书评站点豆瓣(douban.com)的技术探究。站长阿北在一篇帖子中提到“豆瓣全部使用Python开发,网站后台的搜索引擎基于Twisted,GUI基于Quixote”,而且更令我惊讶的是,承载豆瓣每天8万独立IP和50万页面请求的竟只是一台DIY的AMD双核1U服务器。而且我每次访问,感觉服务器相应速度相当快。于是不得不对Python在Web开发中的表现大为赞叹。

当然Python的应用不仅限于此,在Python官方站点上列出的应用可谓包罗万象,而且NASA和Google也是Python的用户之一。其实早就关注Python的发展了,只是由于惰性一直没有入手学习。最近花了一个下午的时间把Pyhton语法通了一遍,用Eclipse的Pydev插件调试了例子代码,感觉使用Python确实可以享受到敏捷的开发效率。Python开发的模块和内置的元组、字典等数据结构使用起来很便捷。并且如果需要,关键算法可以使用纯C来实现。

比较来说,在Web应用方面,Java的开发效率确实不敢恭维,这一点是早有体会。在桌面开发上,国内Java框架研究先驱站JavaEye的站长Robbin,一年前就断言Java桌面开发已死,而Python的桌面应用则前途不可限量。这个观点不敢苟同,毕竟自己还是很喜欢以Eclipse为代表的SWT/JFace的桌面表现方式。但不得不赞一下类似Boa这样的Python IDE环境的优美简洁。

值得关注的Python开源Web项目是Zope和Django,但是对Zope的表现还不太信任,原因之一就是集成度太高,整个Zope结构大致相当于PHP+Apache+MySQL的集合,耦合度太高也会为拓展性及二次开发带来不便。Django准备仔细研究一下,争取做一个演示站点出来。类似chicagocrime.org这样的Python+Django+Google Map这样紧密结合实际的应用今后会大有用武之地。

可以参考的Python GIS桌面项目,感觉比较好的是陈老师推荐的mezoGIS,一个月前德国人刚启动的项目就已经开始研究了,不得不佩服一下。

需要开始用Python吗?今后应该会有涉及的,但逐渐发现越学越杂,反而都不能深入。那就这样吧,慢慢会好的。

基于Web Start的应用发布设想

一直看好Java Web Start的应用前景,通过这种方式可以使部署在服务器上的富客户端应用通过一个HTTP链接加载到客户机上,取消了传统C/S结构的种种限制,给使用者带来很大的便利。可以看看Sun公司的Java Web Start官方站点。Sun公司提供JWS的demo演示可以在这里找到。左图为JWS的标准访问流程。

最近讨论了一下类似ww2d这种数字地球的产品化前景,要做的改进主要是数据应该像Google Earth那样进行加密传输,而不能像NASA World Wind都下载到缓存里让所有人都得到,因为国内用户对自己的数据保护还是相当看重的,毕竟高分辨率的数据买来也需要不少花费。ww2d程序在我的Win2K下用Eclipse重新编译了一下,简单修改了几个地方,比如增大初始窗口、状态栏增加了几个坐标的显示等,然后上传到基于FreeBSD的麒麟OS服务器上运行一切正常,不得不再赞一下Java的跨平台特性。

准备考虑使用Java网络装载协议(JNLP)发布一下ww2d这样的Virtual Earth应用,远程客户可以通过Internet访问和运行部署在服务器上的ww2d应用程序。同时值得尝试一下将Eclipse的RCP富客户端应用使用JNLP打包和配置,发布为Web Start应用,这样结合Eclipse的RCP技术和Java Web Start,应该会有不错的收效。

如果网络传输不是问题,随着JWS技术的不断成熟,可以预见,日后相当一部分的Java Desktop应用可以通过这种方式发布。