什么是Ruby?
Ruby 语言是一种动态语言，它与Python、Smalltalk和Perl这3种编程语言有些类似。Ruby语言起源于日本，它的研发者是日本人松本行弘（Matsumoto Yukihiro）。松本行弘在1993年开始着手Ruby语言的研发工作，他开发Ruby语言的初衷是为了提高编程的效率。 1995年12月Matz推出了Ruby的第一个版本Ruby 0.95。
Ruby语言的主要特点如下。
1．纯的面向对象语言
在Ruby中，一切皆是对象。下面举一个例子来更直观地说明Ruby语言的这一特点。
在Java中，求一个数的绝对值的代码如下。
int c = Math.abs(-20)
而在Ruby语言中，一切皆是对象，也就是说“-20”这个数也是一个对象，因此，求一个数绝对值的Ruby代码形式如下。
c = -20.abs
这样的代码编写方式是不是更形象一些呢？
2．解释型脚本语言
Ruby 语言是解释型脚本语言，它既有脚本语言强大的字符串处理能力和正则表达式，又不失解释型语言的动态性。一方面，在最初设计Ruby语言时，Ruby的研发者松本行弘考虑到文字处理方面的需要，他借鉴了Perl语言在文字处理方面的成功经验。另一方面，松本行弘将Ruby语言设定为一种解释型语言，Ruby 的动态性使得由Ruby语言编写的程序不需要事先编译即可直接运行，这为程序的调试带来了方便。同时，这一特点可以实现开发过程中的快速反馈。
3．其他特点
（1）动态载入。可以在运行时候重定义自己，类也可以在运行时继承或取消继承。
（2）自动内存管理机制。
（3）多精度整数。
（4）迭代器和闭包。
（5）开源项目。有大量活跃的社区支持Ruby语言。
什么是Rails?
虽然Ruby语言有很多优点，但是一直以来，其流行的范围也仅限于日本。直到2004年，Ruby才逐渐被世界上其他地区的人们所认识，那么是什么让Ruby语言走向世界的呢？是Rails。
Rails 框架首次提出是在2004年7月，它的研发者是26岁的丹麦人David Heinemeier Hansson。不同于已有复杂的Web 开发框架， Rails是一个更符合实际需要而且更高效的Web开发框架。Rails结合了PHP体系的优点（快速开发）和Java体系的优点（程序规整），因此， Rails在其提出后不长的时间里就受到了业内广泛的关注。
Rails框架主要有如下的6大特点。
1．全栈式的MVC框架
Rails是一个全栈式的MVC框架，换句话说，通过Rails可以实现MVC模式中的各个层次，并使它们无缝地协同运转起来。
在实际开发一个MVC模式的Web应用项目时，如果使用Java开发，需要用到Struts（Model层）、Hibernate （Controller 层）和Spring（View层）3个框架，而且需要额外整合3个框架开发出的内容。而使用Ruby语言开发相同的项目时，只需要用到Rails框架就可以完成。
2．约定优于配置
为了说明各个对象之间的关联关系，一般的Web应用开发框架往往采用写入XML配置文件的方法。这种方式虽然可以解决一些问题，但是却带来了管理上的混乱。
Rails 对此的态度是约定优于配置，这意味着在Rails中不会出现XML配置文件。Rails使用Web应用多年来积累的各种常见约定（更具体地说是命名规则）来代替XML配置文件，而在Rails内部的映射与发现机制根据这些约定可以实现对象之间的关联。在第1章中，通过Rails的映射与发现机制实现了数据表与Ruby对象之间的关联。
3．更少的代码
使用约定来代替XML配置文件说明Rails本身完成了大量的底层工作，这意味着使用更少的代码来实现应用程序是极有可能的。此外，代码量的缩减也减小了出现bug的可能性，降低了维护程序和升级程序的难度。
4．生成器
Rails 使用的实时映射技术和元编程技术，免去了开发人员在开发过程中编写大量样板文件代码的烦恼。在少数需要使用样板文件代码的时候，开发人员可以通过 Rails内建的生成器脚本实时创建，而不再是通过手工编写。Rails的这个特点可以使开发人员更专注于系统的逻辑结构，而不必为一些琐碎的细节所烦扰。
5．零周转时间
对已有的Web应用系统进行修改后，其一般需要经过配置、编译、发布、重新设置、测试等一系列步骤才能投入使用，这明显浪费了许多时间。而使用Rails开发Web应用系统，可以通过浏览器即时查看程序运行结果，从而节约了大量的时间。
6．支架系统
Rails的支架系统可以自动为任何相关的数据库表创建一套包含标准CRUD操作和前台视图的系统。通过支架系统，开发人员可以方便快捷地操纵数据库中的数据表。此外，Rails也允许开发人员使用自己设计的代码或视图来替换自动生成的代码和视图。
目前，Rails的最新版本是2005年12月13日发布的v1.0.0。从RoR正式提出到v1.0.0的发布，RoR在一年多的时间里受到了业内人士的广泛关注。RoR受到广泛关注主要有如下两个原因：首先，RoR的开发效率高（部署容易）、功能丰富（支持Ajax等流行应用），有消息称对于相同的 Web开发项目，使用RoR开发比使用Java体系架构开发快5~10倍；此外，令人不可思议的高性能是其受到关注的另一个重要原因，根据CSDN上转载的新闻称使用RoR开发出来的项目性能，比基于Struts+Hibernate+Spring的Java应用还要高15%~20%。
RoR 当前遇到的主要问题是使用RoR搭建的大型商业应用还很少，究其原因可以概括为两点：第一，从开发能力的角度，RoR是一个基于Ruby语言的轻型Web 开发框架，很多开发者对其是否适合大型应用难以把握。第二，本身使用RoR开发的大型商业应用较少，使得后来者持观望态度。
综合分析来看，RoR的发展前景还是很光明的。RoR在短时间内取得了巨大的成就，它打破了Web开发领域的固有观念，方便快捷的开发方式使其被广泛接受。而事实上，现在已有几家跨国公司正在使用RoR开发自己的Web应用程序，并且有多家大型公司在考虑使用RoR进行Web应用开发。
一步步实现Android CI
Android上的CI构建链与其它平台一致，依然包含Compilation, Testing, Inspection,
Deploying阶段，每一个阶段的Feedback的都保持对整个团队透明。
CI中各个步骤执行先后顺序的安排，应该是执行时间较短的优先执行。执行时间短的一般在提交代码前就可执行，错误率也比较低，就应该尽可能先执行。这样失败会来得更早一些，每一次CI运行失败前验证完毕的东西更多。上图中CI的工作流，正是在这样的一个原则的基础上形成的。
环境准备
* 在CI服务器上安装Java和Android运行环境
* 安装构建工具，本文采用Ant进行实践
* 搭建好CI服务。本文采用开源的CI服务Jenkins（Hudson）。
* Jenkins在功能上完全能够满足功能上的需要，且简单易用。
* 安装Ruby环境。本文中使用的Functional Test测试工具是基于Ruby实现的。
步骤 1：持续构建
持续构建的目的是随时可自动化生成最新的可运行的App。虽然有这么多限定词来表示这一步完成的验证条件，但事实上只需要经过三个步骤即可完成。
一是更新代码，Jenkins中已经很好的支持了SVN和Git这两项常用的代码管理工具。二是采用构建脚本构建安装包，Android已经很贴心的连Ant构建脚本都为我们准备好了，并且因为Android的包结构的规范，也很大程度上消除各开发人员环境下项目机构的不一致。三是持续执行前两步，只有在每一次出现任何代码变动时立即执行前两步才能保证随时都可以提供可运行的安装包。
持续构建实现起来比较容易，但是它所达成的效果还是很不错的。对开发人员来说，都可以采用同一个脚本快捷的在本地生成安装包，这在很大程度上也减少了出现“这在我机器上运行的很好”的问题。对于测试人员，随时都可以获取最新的测试包，不需要再等待开发人员腾出时间来做这件事。对于产品人员，可以利用这些最新包，在开发人员完成后第一时间获得反馈。甚至可以在完成部分功能的情况下就开始体验了。
Best Practice:
* 在每一次提交后都对整个project进行构建。这里的提交应该包含任何一个微小的改动。
* 所有人遵循相同的构建顺序，采用同一套构建脚本
* 每次构建的时候都执行同一套脚本
步骤 2：持续测试
持续测试是快速的通过自动化的手段收集软件健康状况的方法。持续测试是为了验证构建完成的包功能是否可用，而不仅仅能够安装运行。对App的测试可以从UI,
Function, Code三个层次来进行，这三者间的权重关系可以参照测试金字塔来设计。
根据前文提到的优先运行最快的原则，这三个层次的测试，应该按照Unit Test， Functional Test，和UI
Test的先后顺序安排在CI执行。
1、添加Unit Test
Unit
Test是运行成本最低的测试，并且对于测试用例覆盖最为全面。鼓励尽可能利用单元测试覆盖用例。Java中的单元测试首选的还是使用JUnit，但Android
project的代码因为对SDK存在着极强的依赖，仅仅使用JUnit进行单元测试，能够覆盖的代码实在太少。为了解除对SDK的依赖，自然会考虑引入Mockito这样的Mock框架。但即使借助Mockito写单元测试的工作量依然巨大，因为需要mock的对象实在太多。并且Android的object在JVM中无法创建。
这时可以采用Robolectric单元测试框架，这将大幅度提升单元测试覆盖率，且理论上可以达到100%。Robolectric是以JUnit为核心，完成了对Android
SDK的stub。采用stub的方式后，Android的组件在JVM中即可创建并运行，无需在Android平台下运行。这也意味着在Android开发中可以采用TDD的方式，进一步提高单元测试覆盖率。该框架的使用JUnit完全一样，运行性能也一致。
由于Robolectric对SDK进行了stub，在写单元测试时完全可以对组件状态进行验证，甚至可以对组件进行操作。下面这个测试就是对button点击事件的测试，并且验证了Activity的状态。
CI中各个步骤执行先后顺序的安排，应该是执行时间较短的优先执行。执行时间短的一般在提交代码前就可执行，错误率也比较低，就应该尽可能先执行。这样失败会来得更早一些，每一次CI运行失败前验证完毕的东西更多。上图中CI的工作流，正是在这样的一个原则的基础上形成的。
步骤 1：持续构建
持续构建的目的是随时可自动化生成最新的可运行的App。虽然有这么多限定词来表示这一步完成的验证条件，但事实上只需要经过三个步骤即可完成。
一是更新代码，Jenkins中已经很好的支持了SVN和Git这两项常用的代码管理工具。二是采用构建脚本构建安装包，Android已经很贴心的连Ant构建脚本都为我们准备好了，并且因为Android的包结构的规范，也很大程度上消除各开发人员环境下项目机构的不一致。三是持续执行前两步，只有在每一次出现任何代码变动时立即执行前两步才能保证随时都可以提供可运行的安装包。
持续构建实现起来比较容易，但是它所达成的效果还是很不错的。对开发人员来说，都可以采用同一个脚本快捷的在本地生成安装包，这在很大程度上也减少了出现“这在我机器上运行的很好”的问题。对于测试人员，随时都可以获取最新的测试包，不需要再等待开发人员腾出时间来做这件事。对于产品人员，可以利用这些最新包，在开发人员完成后第一时间获得反馈。甚至可以在完成部分功能的情况下就开始体验了。
Best Practice:
* 在每一次提交后都对整个project进行构建。这里的提交应该包含任何一个微小的改动。
* 所有人遵循相同的构建顺序，采用同一套构建脚本
* 每次构建的时候都执行同一套脚本
步骤 2：持续测试
持续测试是快速的通过自动化的手段收集软件健康状况的方法。持续测试是为了验证构建完成的包功能是否可用，而不仅仅能够安装运行。对App的测试可以从UI,
Function, Code三个层次来进行，这三者间的权重关系可以参照测试金字塔来设计。
根据前文提到的优先运行最快的原则，这三个层次的测试，应该按照Unit Test， Functional Test，和UI
Test的先后顺序安排在CI执行。
1、添加Unit Test
Unit
Test是运行成本最低的测试，并且对于测试用例覆盖最为全面。鼓励尽可能利用单元测试覆盖用例。Java中的单元测试首选的还是使用JUnit，但Android
project的代码因为对SDK存在着极强的依赖，仅仅使用JUnit进行单元测试，能够覆盖的代码实在太少。为了解除对SDK的依赖，自然会考虑引入Mockito这样的Mock框架。但即使借助Mockito写单元测试的工作量依然巨大，因为需要mock的对象实在太多。并且Android的object在JVM中无法创建。
这时可以采用Robolectric单元测试框架，这将大幅度提升单元测试覆盖率，且理论上可以达到100%。Robolectric是以JUnit为核心，完成了对Android
SDK的stub。采用stub的方式后，Android的组件在JVM中即可创建并运行，无需在Android平台下运行。这也意味着在Android开发中可以采用TDD的方式，进一步提高单元测试覆盖率。该框架的使用JUnit完全一样，运行性能也一致。
由于Robolectric对SDK进行了stub，在写单元测试时完全可以对组件状态进行验证，甚至可以对组件进行操作。下面这个测试就是对button点击事件的测试，并且验证了Activity的状态。
接下来的工作就是将Robolectric集成到CI中，让它检查程序的健康状况。Robolectric本质上还是JUnit，只是多了一些stub
对象而已。那我们集成Robolectric的方法和JUnit完全一致。只需创建Ant task，并在Jenkins中执行此task即可。此Ant task如下：
在将这些测试集成至CI后，最重要的一步收集结果是不能忘的。之前已经说过Calabash也可按照单元测试报告规范输出，加上Robolectric本身就是JUnit框架的扩展，报告也是按照单元测试报告规范输出。Unit
Test和Function Test的报告即可使用JUnit test收集。
要想获得单元测试覆盖率报告，Cobertura是个不错的选择。添加
从Jenkins上即可获得清晰的单元测试覆盖率的报告
2、添加Function Test
Android为大家提供了一套集成测试框架Android integration testing
framework。但此框架未集成Cucumber，这导致每增加一个Function Test都需要较大的开发和维护工作。这样高成本的实现Function
Test将大大延缓开发进度，最终因为项目进度的原因导致Function Test被丢弃。产生这样的后果那必然是不愿意看到的。
目前Android平台下已经出现多种Functiong Testing测试工具，如Native Driver, Robotium,
Calabash等。在尝试对比后，最终选择了Calabash Android作为解决方案。Calabash
Android是Cucumber在Android平台的实现，使用Ruby书写Function Test，并提供了一组操作Anadroid App元素的API。
3、添加UI Test
Android在新近退出了UI测试工具UIAutomator。此工具仅支持Android4.1及以上平台，鉴于目前市场上2.3和4.0版本仍占主导的情况来看，目前还无法满足大家的需要。另外应用该工具实现UI测试的开发成本还较高，笔者暂不推荐使用此工具，但应该关注其发展。
另外基于录制回放机制的测试方法同样可以进行UI测试。但录制回放的方法在面对功能快速迭代时，维护工作会急剧增加，而这个维护成本可以说是很难承受的，所以在此也不会将这种测试方法集成至CI中。
目前来看Android中UI测试还无令人满意的方法。若对UI成功比较看重，可以投入精力应用UIAutomator进行UI测试。
Best Practice:
*
将测试按照单元测试，组件测试，功能测试和系统测试进行划分。单元测试应该在每次提交时触发执行，其它的测试根据运行时间长短和重要程度可以每次提交触发执行或者定时周期执行。
* 将运行较快的测试优先执行。
* 让功能测试能够重复执行。否则维护成本太高，会被舍弃。若是后台数据导致不可重复，可以将数据抽象成为数据集，在每次运行前进行重置。
* 书写测试时每一个assert只做一种判断，这样可以明确每次测试的目的，并且可以快速定位测试失败愿意。
步骤 3：持续检查持续检查是对于代码本身检测和反馈。检测主要通过对代码静态分析验证代码风格，编程规范，代码复用，代码语言中的Best Practice等多个维度的代码质量。
Sonar作为一个开源的代码质量检测工具，涵盖了7项代码质量检测方式。这充分满足Android平台下对于代码质量的检测分析。Sonar分为两部分一部分是代码分析工具，另一部分是数据分析展示的Server。
Best Practice:
* 将测试覆盖率，代码分析结果透明化
* 持续降低代码复杂度
* 持续的促进设计的演进
* 持续的维护代码结构
* 持续减少代码重复
步骤 4：持续部署
由于Android App采用用户手动从Appstore自行下载安装的方式发布，使得Android
App无法直接部署至用户手机中。另外Appstore需要对于上线的App进行审核，不能持续进行Release。因而Android中持续部署将以持续发布可安装包为目标。
在以上目的下，只需根据自身项目资源找到合适的安装包管理工具即可。如本文采用Dropbox来管理所有安装包。
Dropbox作为一个云存储平台，在Android终端设备上可以轻松下载存放在其中的文件，同时上传安装包也可以交由Dropbox自己完成。
步骤 5：持续反馈
反馈是所有改进的开始，必须要让所有人获取到他们所关心的反馈信息，才能实施改进。持续反馈的目的就是让所有人都掌握项目健康状况。项目所有人事实都是有意愿知道项目当前的健康状况的，那CI就应该将项目的情况做到透明，并将不同的反馈通知到各相关的成员。
CI不同阶段产生了不同维度的反馈，如单元测试报告，测试覆盖率等。本实践中将这些反馈都透明的展示在项目首页中。之所以没有将这些反馈再以邮件的方式通知所有人，是因为团队成员已经养成了查看CI的习惯。
如果说只给所有人发一封邮件说明项目状况，那必然是告诉所有人“CI所有步骤是否都返回正确？”。这样一个反馈，包含了编译正确，所有测试通过，安装包已经准备完毕等重要信息。有必要让所有人都知道这个信息，特别是在CI执行失败的时候。Jenkins自身已经提供一个简单有效的透明化方法，以项目为蓝色表示通过，红色表示有步骤失败。
反馈的通知方式有很多种，不一定要采用邮件通知的方式。可以寻找更加有趣的方式，如果播放音乐和设置警报灯。在每一次Build成功或失败后都播放一段有趣的音乐，打开不同颜色的警报灯，这两种方法都是是一种简单有效的方式，可以让项目所有人都获取到最为关键的信息。
1、检测服务器环境是否充分，有没有所需的ruby版本，有没有数据库（如mysql）等 2、将代码放到服务器上，安装对应的gem，或通过bundle install安装依赖的gem。 3、在服务器上建立数据库，并配置好代码中的 config/database.yml
