为网站和智能手机构建 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 里被格式化的。 我们碰到的唯一问题是在拉取 FlighStats 数据时的内存限制，因为 XML 文件实在是太大了。老实说，这曝露了我们在处理数据上的缺陷，并迫使我们采取更好的处理方式。因此，我们使用了 SAX 解析器而非 DOM 解析器。

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

有些数据源也会给我们无效的日期和时间（比如 26:00）。像这种无效的日期，通常丢掉即可。尽管我们能得到关于该无效日期的通知并记录下来，但我们系统的数据总量允许我们这样去做（丢弃），这取决于你要做什么。

我们有很多关于航空公司和 FAA 数据的问题。IATA、ICAO 和 FAA 给的航空公司和机场代码导致出现许多问题。比如，IATA 航线代码是两位字符，但 规格说明它可以是三位字符。而且，飞全球不同地区的航空公司可以共享同样的 IATA 代码。ICAO 代码相对比较好处理一些。全体航空公司 / 机场的标识符是个很大的问题，因为三个组织给出的是三个不同的标识符，而且所有标识符是可选的。所以即使我们以 ICAO 代码为主，我们也不能期望一定会有 ICAO 代码可以使用。

处理政府数据也是非常痛苦的。例如，FAA 将 ICAO 代码存放在指定给 FAA 代码的属性域。我们还发现 Flightstats 会报告一个虚构的航空公司（大洋航空）。

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 技术分享聚会。

感谢宋玮对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。