为网站和智能手机构建FlightCaster前台应用

本文是采访FlightCaster团队的第二部分内容（第一部分讲的是FlightCaster如何使用Clojure），主要集中在Rails和Heroku的使用方面，如何从多个数据源收集并整合数据，为不同手机设备创建多种用户界面并将它们集成到系统当中。

InfoQ采访了Flightcaster的James Bracy、Jon Bracy、Jared Strate、Jonathan Chase，以及Inmite（FlightCaster的黑莓合作伙伴）的Pavel Petre。

InfoQ：你们如何在Web前台处理长时间运行的过程?

Jon：我们使用Heroku的Delayed Jobs插件来实时捕获多种来源的数据。如果我们不持续捕获数据，它们就会丢失，所以可靠性是非常重要的。目前，DJs一天要处理二百万次的更新。每个数 据源采集器都有自己的工作者队列。如果一个DJ挂了，Heroku就会启动另一个继续工作。如果需要更多的工作者，简单的跑个指令即可。我们还用DJs来 做批处理、格式化及转换。例如，时间就是在DJ里被格式化的。

InfoQ：在你们网站上线的第一周，对Heroku感觉如何？

Jon：Heroku会根据网站前台需求自动扩展，即便是在New York Times、Wall Street Journal、Reuters、Techcrunch、InfoQ和slashdot都在报道FlightCaster时的峰值期间也没什么问题。在此 期间，我还在线部署了一些小的修改，并没有什么不便之处，运作都十分正常。它们也有内建缓存，因此花两分钟设定之后，就没什么太担心的了。另外，对于数据 捕获及原始输入数据处理，我们还得到了极佳的扩展能力。

InfoQ：到目前为止，你们对Rails有何体会？

Jared：我们的网站不全是Rails，还有一些Javascript/Ajax来简化输入和提升用户体验。航班延误因素并不是算法的 一部分，它们是通过把逻辑应用于航班数据而得出的。程序分析天气数据（航空例行天气报告）并应用一些基础逻辑来判断与天气相关的延误，然后通知旅客天气情 况。分析官方情况、预计抵港/离港时间来判断一些明显的航班延误。分析进港航班数据来判断明显的延误。我们还做了一些简单的阈值数学运算以决定如果显示预 报。除此之外，时区也是一个大问题，这取决于用户、进港航班、目的地等的位置。

InfoQ：你们使用了Rails的哪些部分？全部的ORM、REST吗？

Jon：Rails所有部分在不同的地方都用到了，没有哪一部分没有用到。但我们从没有使用Rails用到的一个属性域。我们一开始就使 用'updated_at'和'created_at'属性域来存放更新数据时的时间戳信息，而不是在收到数据并将其放入数据库的时间。为此，但是你得告 诉Rails不要写这两个属性域，而且你必须始终记得要这么做。

Jared: 用户输入被加以分析并自动补全；Rails的自动补全功能棒极了。

InfoQ：数据是如何从后台抓取到前台的？

Jon：Rails Web服务器读取由Clojure/Cascading/Hadoop端产生的JSON，用其解释输入的实时数据并形成预报。客户端通过REST API接收预报和实时数据。客户端只是用来查看数据的，逻辑保留在服务器上。

InfoQ：你们是如何获取数据的？是否有什么地方能够获得延误及其他所需数据？

Jon：目前我们从联邦航空管理局（FAA）获取航班数据、从国家海洋气象局获取天气信息、从Flightstats获取航空公司信息。我们也开始与某些航空公司接触以便能直接从他们那获取数据。

InfoQ：Mashup很流行——你们在整合来自多个数据源的数据的时候有没有碰到问题？

Jon：日期和时间一直是最大的问题。时区和夏令时都必须考虑进去，不然你可能会在搜索今天的班机时却得到明天的。要找到机场当地的时区也很困难，好在机场的经度和纬度比较容易获得，因此我们可以利用时区向量地图用经纬度来确定时区。

InfoQ：你们的手机界面复杂么，用到类似定位或加速度计这样的设备特有功能没有？

James：我们没有用到任何设备特有功能。我们想过增加‘晃动有机随机选取航班’的功能，但是每个应用程序都已经有了‘晃动……’的功能。实际上这些功能并不那么重要，这一版也就没做这种功能。

Pavel：也许有机会用到GPS，比如根据当前地点搜索机场等。

InfoQ：你们考虑过跨平台的HTML5解决方案吗？

Jamas：HTML5解决方案还未成为主流。或许可以了解一下，但我们更愿意使用本地API。

InfoQ：手机应用是如何连接到Flightcaster 后台的？

James：我们的后台就是一个RESTful API over HTTP，我们所有的客户端应用都是用它。

InfoQ：对于iPhone、黑莓和Android手机，你们有什么体会？

Pavel：要想在RIM OS 4.2.1+黑莓手机上达到iPhone应用程序的外观效果，唯一可能就是全部自己写。与Android相比，在黑莓上开发一个“漂亮的程序”需要做许多 额外工作。对于黑莓手机，在安装包大小、多种分辨率支持及多操作系统版本之间寻找平衡非常重要。我们最终提供了两个版本：一个是为老版4.2.1设备准备 的；另一个给4.3及以上版本设备（包括5.0触摸设备）准备的。这两个版本都提供了一些额外的代码来适应实际设备。而在Android上，支持不同配置 要容易得多。只需指定不同的配置目录（比如layout-en-finger-480x320）覆盖默认配置即可。由于手机有多种数据连接方式、运营商、 企业级的BB策略，因而用通用程序来切换传输方式（WiFi、BES、BIS、直连TCP、...）变得更加困难——我们给用户提供了选择传输方式的界 面。在这方面我们正在做一些改进，这样大多数用户就不用进入该设置界面了。但是很不幸，黑莓对通讯层的处理不像在Android上那么简 单，Android可以自动切换连接。

James：在iPhone上开发GUI相对简单，但性能不如期望的好。例如，应用程序加载时第一个视图滚动得不是很流畅。我们很快找到 了问题所在。iPhone社区和文献都非常不错，有足够的信息可以让你确保应用程序正常工作。iPhone SDK也是经过周全考虑的。这是我们做的第一个手机应用，此后我们还开发了一个Android应用。相比起来，iPhone应用开发起来最容易，而且用起 来很惬意。在开发Android时我发现其SDK也不错，但是设备响应不如iPhone快。而且即便是和Objective-C比，用Java写程序也非 常啰嗦。Apple以设计著称，这一点从GUI设计方面展现出来了。界面构建器确实让设计变得简单了。在iPhone上编程时让我感觉特别有趣的一点是， 手动分配内存实际上帮了我的忙，它让我放慢了速度并真正彻底理解其工作方式。

Jared：在Android上，获取数据并传进视图比预期工作量要大。Java太啰嗦了，或许在手机平台上用另一种不同的语言可能会更 理想。用基于xml的布局简单输出到视图上很容易，然而复杂的视图开发起来既慢又难，特别是对非一致数据更是如此。不过，自动补全的文本域却是一个吸引人 的特性，而且简单易用。

Chase： 在我们利用Apple绘图方法而非高层API改写了部分视图后，iPhone GUI响应得到了改善。展现迟缓的原因是我们使用了透明特性，这在iPhone上非常耗性能。这个应用程序上架审核的过程跟我们预想的差不多（大约两 周）。尽管我们已经修正了一些大bug，它们还是导致该应用程序只获得了1星评价。

查看英文原文：Building FlightCaster's Frontends for the Web and Smartphones。

译者简介：张文钿（a.k.a ihower），来自台湾新竹，和多股份有限公司共同创办人及 Ruby on Rails 程式设计师。2006年开始接触Ruby on Rails，从此爱上Ruby这个极具生产力及表达能力的程式语言。他同时也是Ruby Taiwan社群主力成员，不定期在台北主办Ruby Tuesday技术分享聚会。