C#与JAVA的相同之处:由于C#与JAVA都是基于C++发展起来的,因此二者之间具有很多相似之处,具体如下:

1、C#和JAVA语言的编译结果是独立于计算机和编程语言的，可执行文件可以在受管理的执行

环境中执行；

2、C#和JAVA语言都是采用了自动的垃圾回收机制；

3、C#和JAVA语言都取消了指针操作；

4、C#和JAVA语言都没有头文件；

5、C#和JAVA语言都只支持单重继承，要实现与多重继承类似的功能，必须通过接口来实现；

6、类都是从Object类派生而来，类的对象通过关键字new生成；

7、C#和JAVA语言都支持线程；

8、C#和JAVA语言都没有全局变量和全局函数，所有的变量和函数都属于某个类所有；

9、C#和JAVA语言都支持对数组和字符串边界的严格检查，不会出现边界溢出的情况；

10、C#和JAVA语言都使用“.”操作符,不再使用“-＞”和“::”操作符；

11、C#和JAVA语言都将null和bool作为关键字；

12、C#和JAVA语言中所有的值都必须先初始化后才能使用；

13、C#和JAVA语言中的if语句都不允许采用整数作为判断条件；

14、C#和JAVA语言中的try语句块都可以后接finally语句块。

C#与JAVA的不同之处:

尽管C#和JAVA有很多相同之处，但是由于二者是两家不同公司开发的高级程序设计语言，它们又相互独立，

自成体系，各自具有一些自己特有的特点，下面将C#与JAVA之间的不同之处如下：

1、属性

对于那些经常使用快速开发工具，如Delphi或者Visual Basic的开发人员来说，属性是一个非常熟悉的概念。

一般来说，通过getXXX可以读取属性的值，而通过setXXX可以设置属性的值。

JAVA中比较常见的属性操作语句： foo.setSize(foo.getSize()+1)label.getFont().setBold(true)

c#中比较常见的属性操作语句： foo.size++label.font.bold=true

很明显，上述的属性设置方式较JAVA来说更为简洁，可主读性也更强。这充分体现了C#简单的特点。

JAVA对于属性的定义：public int getSize(){ return size} public void setSize(int value){ size=value}

c#对于属性的定义进行了简化：public int Size{ get{ return size} set{size=value}}

2、index

C#提供index来给对象加上索引的功能，从而用与处理数组类似的方式来处理对象，JAVA语言则不支持index

C#中定义index的典型方式如下：

public Story this[int index]

{

get{return stories[index]}

set{

if(value!=null){

stories[index]=value

}

}

3、delegate ：可以认为是一种类型安全、面向对象的函数指针。

C#使有delegate可以通过一个名字访问不同的函数，它实现和JAVA中的interface类似的功能，但是它比interface更为好用。

4、event

C#提供对event的直接支持，它通过delegate和event关键字实现对事件的处理。event关键字隐藏所有delegate方法，运算符“+=”和“-+”允许程序员自由加入或者删除时间处理程序。

5、enum：枚举用于指定一系列的对象。

C#通过如下语句来定义和使用枚举：

定义：public enum Direction{North,East,West,South}

使用：Direction wall=Direction.North

JAVA不直接支持枚举，如果要实现和C#相类似的功能，必须先定义一个类

public class Direction{

public final static int NORTH=1

public final static int EAST=2

public final static int WEST=3

public final static int SOUTH=4}

在定义了Direction类后，JAVA可以通过引用类中的值来使用枚举：

int wall= Direction.NOTRH

6、foreach语句

C#提供了标准的for循环，同时还提供了foreach语句（从VB中引入）来循环处理集合中的元素。

JAVA遍历集合中的所有元素的典型处理方式如下：

while(!collection.isEmpty())

{

Object o=collection.get()

connection.next()

…

}

C#遍历集合中的所有元素：foreach(object o in collection){…}

7、统一数据类型：

大多数的高级程序设计语言都有基本数据类型，如整型、浮点类型等。同时，为了更好地满足实际的需要，对不同的数据类型有不同的处理方式，显然，如果能够对简单数据类型的处理和对复杂数据类型的处理结合在一起，并用一致的方式加以处理的话，无疑会大大提升应用程序设计的效率，增强程序设计的灵活性。

JAVA语言在处理基本数据类型的时候也采取分别处理的策略，但是在基本数据类型的基础上提供了一系列封装这些基本数据类型的类，例如：整型（int）被类Integer所封装，双精度浮点（double）被类Double封装。

C#提供了一种和JAVA不同的方式来实现数据类型的统一。事实上，在c#中，即使是int这样的简单数据类型在C#内部也是通过一个结构体Int32来实现的，在C#中，可以这样认为，int只是结构体Int32的一个别名。由于C#中的结构体也继承自类Object，这样，Object类中定义的方法，各个结构体也拥有，于是，在C#中可以通过如下的方式来操作整数：int I=5System.Console.WriteLine(i.ToString())

8、操作符重载

通过操作符重载可以用一种比较自然的方式来操纵各种数据类型，从而大大提升程序的可读性和灵活性。C#中的“==”操作符在Object类中进行了定义，在Object中定义的==操作符通过比较两个值的引用来获得最后的结果。如果使有和集合相关的类，则必须在这样的类中实现ICompar接口，这个接口中定义了一个方法CompareTo，该方法返回两个对象的比较结果，在此基础上，可以进一步定义各个实现比较的操作符，如

“＞”、“＜”、“＞=”、“＜=”等。事实上，数字类型（int、long等）可以直接使用这些比较操作符，它们的内部都实现了ICompare接口。

9、多态性

虚似方法提供了多态性的技持。多态意味着派生类可以定义一个和基类中同名的方法。尽管JAVA和C#都支持多态性，但是它们的具体实现方式还是有一定的差别。

在JAVA语言中，默认情况下，基类的对象可以直接调用派生类中的虚似方法，在C#语言中，基类要调用派生类中的虚似方法必须通过virtual关键字来实现。同时，在C#语言中，一个方法要重载基类中的同名方法，还必须通过关键字override来实现。在C#中实现多态的典型程序如下：

Class B{ public virtual void foo{}}

Class D:B{ public overried void foo(){}}

以上只是简单地比较了C#和JAVA之间的异同，事实上，这二者之间的比较远不止上面所介绍的内容，要学好这两种语言，需要经过大量的实践工作，在实践中区分开两种语言

Programming Ruby（2nd Edition）

这似乎已经不是怪事：关于一种编程语言的经典教材，作者不是这门语言的创造者。就像Stan Lippman之于C++、Joshua Bloch之于Java、Martin Fowler之于UML一样，Dave Thomas也许是这个世界上最善于向别人讲解Ruby语言的人——至少超过Matsumoto是毫无问题的。也许正是因为自己也经历了“不懂到懂”的学习过程，有时候“旁观者”反倒比“创造者”更清楚学习者们需要什么。

所以这本书就是Ruby的经典教材。关于Ruby的基本语法和常用工具，书中第一部分和第二部分做了详细的介绍。第三部分“Ruby Crystallized”更加阐述了Ruby语言的一些细节和设计理念，其中第23章“Duck Typing”是刚从Java或者.NET平台走出来的读者不可错过的，因为对于类型与契约的理解、对于类与类型的理解，正是Ruby这种动态语言与Java/C#等静态语言最大的区别之一。随后的第四部分提供了Ruby基础类库的速查手册。

Dave Thomas和Andy Hunt这两个“Pragmatic Programmer”并非浪得虚名：这本Programming Ruby虽然不是一本称职的参考手册，却足够帮助一个初学者步入Ruby世界而不致误入歧途，并且能够在很少见的一些情况下——譬如说忘了yield的用法——给有经验的Ruby程序员提供帮助。在我看来，这也就足够奠定它作为经典教材的地位了。由于封面上有一柄丁字镐，这本书也被昵称为“镐头书”——它正是你发掘“红宝石”（Ruby）宝藏的必备工具。

Agile Web Development with Rails

Rails的作者David Heinemeier Hansson说过一句大实话：“我从来不会为了学语言而学语言。”大多数人在大多数时候学习一种新的语言不是为了比较语言的优劣，而是因为这个语言底下的某个工具能给他的工作带来帮助。Ruby世界里的这个“杀手应用”，让Ruby在短短一年时间里成为焦点的这个工具，就是Rails。

这是第一本介绍Rails的图书，又是由Rails的作者DHH和前面提到的Dave Thomas共同撰写，其价值可谓不言而喻了。许是两位作者有太多的“乾货”想要交给读者，这本书的第一版被他们——不幸地——写到了558页之厚。书中首先展示了一个规模不大的在线购物网站，让读者亲身体验用Rails进行敏捷开发的感受；然后针对Rails框架的各个组件和安全、部署等延伸话题展开了深入的讨论。其内容之全面、探讨之深入，令人叹为观止。看起来，和Matsumoto不同，DHH很清楚应该怎么介绍自己的作品——不管是“浅出”还是“深入”。

值得中国读者高兴的是，这本书的第一版已经由林芷薰翻译，电子工业出版社付梓。Rails仍然处在高速发展的阶段，从本书第一版截稿至今，Rails已经发生了相当大的变化，因此这本中译本甫一面世便已经有很多过时之处。但这本书毕竟不是参考手册，作者更多地是在其中阐述Rails的设计理念和最佳实践。对于英文阅读无法达到最快速度的读者来说，这个译本未尝不可以是一个称职的向导。

Rails开发者助手两种

不难想象，有很多性急的程序员会——就像我一样——草草了解Ruby语法之后就一头扎进Rails的绚丽宫殿，体验快速开发web应用的成就感，却不得不时时因为缺乏对Ruby语言的深入了解而感到迷惑：这个类里什么都没有，它为什么会工作？那个地方写的代码是什么意思？可是，要全面系统地学习Ruby，又实在令人望而生畏。还好，我们有这本Ruby for Rails。书中介绍了一些Ruby语言特性——既有普通的也有高级的，都是Rails中使用到的。简而言之，这就是一本专门为Rails应用开发者提供的Ruby指南。更有趣的是，书中还用了一章（第17章）篇幅专门介绍“如何探索Rails源代码”，真可谓是“授人以渔”的典范了。

另一个“助手”则是Chad Fowler——他也是Programming Ruby的合着者——的Rails Recipes。和任何一本“菜谱”（recipe）一样，这本书不会教你如何使用菜刀与炒勺、如何把蔬菜切片——你可以从别的很多地方学到这些技巧。这本RailsRecipes教给读者的，是如何在 Rails环境下急就章地完成一个你需要的功能。譬如说“用户登录与身份验证”这件事，每个网站、每个开发者都曾经做过不止一次，这本书中就给了读者一个简单而可靠的解决方案，读者只要抄抄改改，几分钟就可以完成这个功能。对于初接触Rails（以及Web 2.0）、面对很多问题尚且无从下手的新兵来说，这本书确实可以帮助他们解决一些实际问题。

不过这本书的局限也同样明显：如果你需要的菜色超出了这份菜谱的范围，它就只好爱莫能助了；而且，仅仅给出解决问题的代码，却没有对应的单元测试，也让习惯了TDD的读者多少有些忐忑。在我看来，这本书对“授人以鱼”的专注恰好和前一本Ruby for Rails构成了一对“可怕的对称”，也让这两本书有理由共存于Rails开发者的案头。

Ruby In A Nutshell

作为Ruby语言的缔造者，Yukihiro Matsumoto只能写一本“果壳书”，这本身就是一件耐人寻味的事情。O’Reilly的“果壳书”系列历来褒贬不一：有人认为它们缺乏深度，也有人认为它们是快速入门的好帮手。但Matsumoto最大的问题在于：他创造了Ruby，却没有真正意识到这种语言到底有多大的威力——后来他经常在Ruby on Rails讨论组活动，从中了解一些精妙的Ruby用法。其结果也很自然：这本Ruby In A Nutshell作为语言参考中规中矩，但对于实际应用中的妙处——例如在DSL方面的应用——却语焉不详。再加上它所针对的Ruby版本是略显过时的1.6版，也让这本书的地位略显尴尬。

Ruby 奇书两种

称它们为“奇书”，因为它们的主题实在偏颇。先看这本Enterprise Integration with Ruby：虽说脚本语言常常被称为“胶水”，有多少人会当真想到用Ruby去做企业应用集成？不过细看之下，这本书多少有些名不副实之嫌，因为它真正介绍的无非只是如何访问数据库、如何操作XML、如何通过SOCKET通信之类比较底层的技术而已。在一个生僻的题目之下写着另一些生僻的内容，尽管这些内容算得上有趣，但我还是要对那些没有读过这本书的Ruby程序员说：你没有错过太多——尽管这本书与你想象的并不一样。

最后要介绍的这本书更是备受争议：有人盛赞它是“精通Ruby的必经之路”，也有人批评它沉溺于奇技淫巧缺乏实用价值。但无论褒贬，更多的读者正在逐一挑战其中的谜题——这本书就是James Edward Gray所着的Best of Ruby Quiz。这本书（目前出版的是第一卷）列举了25道题目，读者大多可以想出一种办法来解决这些问题，往往还能 通过思考和重构找到第二种优雅的设计，但这本书却给你列出了第三种、第四种真正精巧的解决方案——充分利用Ruby技巧才能得出的解决方案。这些题目的最终解法之巧妙，常常令人拍案叫绝（或是破口大骂）。不过这些“奇技淫巧”也并非全无用处，例如书中很多题目在解答时都用到了正则表达式，理解这些解答对于深入学习正则表达式的用法是很有帮助的

Github不是突然火起来的，在Ruby社区Github其实从一开始就很流行，我们2009年搞Ruby大会就邀请了Github的人来上海了，早在2009年Github在国内的Ruby社区就很有名气了。之所以今天大家突然觉得Github火，只不过是因为刚拿到1亿美元融资的眼球效应罢了。

Github是一个从Ruby社区诞生出来的项目，这几年我也算是看着Github发展起来的，可以说Git在Ruby社区普及和爆发几乎是必然的事情。Git虽然是Linux内核社区开发出来的，但前几年一直不温不火。真正在开源社区普及和爆发，是从Ruby社区和Github开始的。

Rails是一个高度集成的Web框架，通常情况下一到两个Rails程序员做一个Web项目就够了，一旦多人同时在一个Rails项目上工作，代码提交和协作会遇到很大的麻烦，更不要说开源项目大规模远程协作了。这算是Rails项目的一个痛点：单个工程师开发效率很高，但是团队协作很困难，CVS/SVN这种集中提交式的SCM都不能很好的支持Rails团队的工作模式。事实上我的Ruby团队规模一大也遇到了这个难题，代码提交经常冲突，协作困难。

Git这种良好支持分支管理的分布式的SCM真正解决了这个问题：每个工程师在自己本地分支上开发，完成功能以后往master分支合并。我们Ruby团队使用Git以后，代码提交冲突问题迎刃而解。所以Git这种SCM像是给Ruby社区量身打造的一样，所以你可以看到Ruby社区几乎没有不用Git的。

Github本身也是这种需求下的产物，一些湾区的Ruby社区的程序员使用Git以后，找不到好的Git托管网站，于是就开发了Github出来。然后Rails框架率先迁移到Github上，形成了示范效应，整个Ruby社区呼啦啦都迁上去了。Ruby社区另有一好处：各种开源库和包都统一用Gem格式发布，而一旦大量Gem都迁移到Github上了，Ruby程序员就跟着都开始用Github了。我当年就是为了跟一些gem的库就开始用Gihub的。

这里多说两句：Ruby社区是一个相当团结的社区，很少分裂，经常是一旦采用一个技术，整个社区就会迅速跟进和普及。虽然在国内Ruby是个小众的编程语言，但是在硅谷，Ruby很火，被誉为云计算时代的Web编程语言。Ruby整个社区都迁移到Github，开始对其他编程语言社区形成示范效应，其他编程语言社区接着跟进。

Ruby程序员因为做Web开发，经常用JavaScript，很多Ruby社区核心人员本身也是JS社区的核心人员，JS社区也就很快进驻Github。同时Ruby社区因为DHH的示范效应，基本上整个社区都是人手一台Mac，天然对OSX比较近，而随着iOS开发的繁荣，大量的Ruby程序员跟进开发iOS app，带动iOS社区也从Github上成长起来了。看看今天的Github，Ruby，JS和iOS的项目比例是非常高的，Java比例则远不如Sourceforge和Google Code，这有一定的社区渊源。

Github也很重视社区活动，经常搞Drinkup，此外Github产品上有很多领先的地方，例如从网站产品上定位为social coding，支持大规模开源项目分布式协作的各种工作模式等等。

不过Github现在估值这么高，我认为主要还是云计算SAAS平台的概念带来的，它给企业用户提供Private代码仓库托管收费服务是盈利的。云平台现在估值都很高，Dropbox，Evernote都远比Github估值高，所以Github现在的估值高也不算意外。

---