Adventure From Java To Ruby——我猜Robbin有类似的感受

摘录自《From Java to Ruby》，第一章

Bruce Tate 写道

As I readied for change, I needed only the right customer. When a company
south of Austin invited me to build a Ruby on Rails application
with them, I couldn’t refuse. The application was a perfect fit for Ruby
on Rails, a new database-backed web-enabled application with an existing
implementation on Microsoft’s .NET Framework. They had pressing
cost concerns and scheduling constraints that I did not believe we could
meet with existing Java or .NET technologies. I had a project, a motivated
client, and all the right conditions for success. I told the customer
that Ruby was a match, and we continued.

When I said that I’d be doing demos every week starting the first week
after development, the company was plainly skeptical. They doubted
that we’d be able to do enough work to justify a room full of clients for
a demo, but as we presented the first week’s demo, the skepticism was
replaced with excitement. The Rails language let us quickly generate
some basic business objects, carve out our security model, and get
the first dozen or so screens up to show our users. With some of the
application in hand, we had a common basis for real communication.
Everyone in the room was aware that this project would be different.

After only two days of training, my development team, consisting of
two Ruby novices, started writing code the first day, and they continued
to improve through the first month. By the second month, they
were fully productive members of a well-oiled machine. The first four
demos included work that the customer estimated would take them
four months on the Java platform. For the customer, genuine excitement
replaced skepticism, and my biggest challenge was controlling
the scope creep born of months of accumulated requirements that they
had been unable to work into their existing system.

评论

9 楼 gigix 2006-09-20  

Suninny 写道

gigix 写道

引用

这本书并不如其人在IBM开发网上的短文有技术含量，因为此书主要是给管理者看的

要滴就是这个。我现在最急需的不是技术含量，解决技术问题很容易；我最需要的是一整套说辞，去说服某些人。

我知道传教士一般自己都不信教的

不光“传教士”，任何一个职业的商用软件开发者都不该“信教”。谁有Sun的股票吗？谁从Sun领工资吗？既然没有，为什么要抱着Java不放？Ruby/Rails也是一样，DHH本人有理由信这个教，我们应该做的只是充分了解它的好处和局限。
凡是说要忠于某个技术的，恐怕都得先问问自己，谁付你工资。

8 楼 Suninny 2006-09-19  

gigix 写道

引用

这本书并不如其人在IBM开发网上的短文有技术含量，因为此书主要是给管理者看的

要滴就是这个。我现在最急需的不是技术含量，解决技术问题很容易；我最需要的是一整套说辞，去说服某些人。

我知道传教士一般自己都不信教的

7 楼 bd7lx 2006-09-19  

这本书对技术人员更有吸引力些，首先是说服自己

从纯技术开发者转型到顾问的， 想的多数如何说服客户。技巧应该在MBA的谈判沟通技巧当中，这种布道的宣传方法不及让动摇者看到实际的示范例子。

对于上面提到的开发方法论，书中也没有最佳的业务实践可以参考，仅仅是转型中对过程的掌控，还有一些需要考虑的风险分析提供了类似模型参照。 

6 楼 gigix 2006-09-19  

引用

这本书并不如其人在IBM开发网上的短文有技术含量，因为此书主要是给管理者看的

要滴就是这个。我现在最急需的不是技术含量，解决技术问题很容易；我最需要的是一整套说辞，去说服某些人。

5 楼 simbasun 2006-09-19  

說服 Manager 使用 Ruby...
这个，基本上，很难...

4 楼 bd7lx 2006-09-19  

对草根的平民出身，很难要求接受正统的皇室做派，尽管Ruby是很优雅

实际上是不会有Best Practices， 壹千个人就有1000个哈姆雷特。

如果今天有人用XP实践在RoR的开发中，明天就会有RUP， 后天。。。

这本书的实际意义，就是说服自己改用Ruby， 爬技术的坡，过管理上的槛

3 楼 bd7lx 2006-09-19  

这本书并不如其人在IBM开发网上的短文有技术含量，因为此书主要是给管理者看的，也是显摆他的白水漂流和单车下山的爱好

http://ihower.idv.tw/blog/archives/1451#more-1451







From Java to Ruby

這本書是 Developer 買來說服 Manager 使用 Ruby 的書，或是自己說服自己。作者也是 Beyond Java 的作者，不過很有趣出版社換成 The Pragmatic Programmers  了哩。剛好最近常有非技術背景的人問我為什麼要從PHP換成用 Ruby。老實說，我的理由主要出自對 Ruby 的好感，喜歡它渾然自成的風格，先進簡潔又不會太難懂，也驚嘆 Ruby on Rails 的漂亮架構。不過為了說服更多人，作者寫了這本書，方便我們跟別人解釋的時候多掰一點… :p

作者自己開始採用 Ruby 作為專案開發的理由是  1.人，許多作者尊敬的程式設計師開始投靠Ruby，包括Java圈中有名的framework開發者 2. Java過多複雜的框架逐漸造成生產力限制 3.RoR爆炸性成長，以往作者只有看過Java和C++誕生時有這樣的榮景 4.Ruby很快樂，重拾作者初學Java時的熱情 5.RoR開始成熟了，作者相信可以滿足客戶作為商用。

當然這本書也會告訴你 Java 哪裡限制，哪裡 Ruby 更適合，哪裡 Java 適合，哪裡 Ruby還不成熟。Java complexity 在增加，Availability在降低，Competition 在日漸增加(如PHP,LAMP,Ruby)。這個時代 Productivity 就是王道，作者認為 RoR就是催化劑，幫助Ruby跨過市場觀望的鴻溝，未來 Ruby 將不只只有這一個 Framework。本書的一個中心問題就是 如何調整更換程式語言的風險? Java風險在增加，而 Ruby在下降，所以趁早擁抱ruby吧。

本書主要依照採用新語言的 Process 來編排，分成三個階段(資料收集,有限部署,廣泛部署)，各兩個步驟。1.確認痛苦 2.建立報償 3.建立Pilot 4.有限部署 5.整合 6. Ramp up

至此第一章 Induction 結束。以下隨便摘錄重點。

Pain

    * 在採用Ruby之前，你先要確定你現在有什麼 Pain。
    * Java的poor productivity來自C++的遺產及過多的架構。
    * Martin Fowler (寫 P of EAA那位) 認為Java的非必要複雜性不可接受的太高。

Establishing Your Reward

    * 從下載次數，願景，書籍可以觀察 Ruby 的成長。
    * Ruby 的基石就是 Productivity (生產力)，不管是短程或長程來看。
    * Java 的風險目前因為佔優勢的市場地位而比較低，但是專案風險卻因為開發時間和複雜度在增加。
    * Java 是 infrastructure 語言不適用在許多應用程式。

Pilot

    * 任何有效的 Pilot 都需要把現有的技術跟政治現實納入考量
    * learning 和 selling 的目標常不一致。挑難的部份用Ruby，可以學比較多，但又怕失敗。挑簡單的用Ruby，學到比較少，但比較容易成功。以下分五個導入情境 :
    * 典型法，重點放學習，在高技術風險的地方導入 Ruby
    * 比較法，同一案同時採用 Java 跟 Ruby 實作，同時比較優缺。
    * 特洛依法，在低風險案採用Ruby，逐漸獲得成功。
    * 賭上你的生意法，風險最大報酬最高，適合新公司，如 37signals，利用更好的 dynamic 跟 productive 的程式語言來對抗大公司，小蝦米對抗大鯨魚出奇才能致勝。
    * 拯救法，把用 Java 失敗的案子給 Ruby 做。

On an Island

    * Ruby 不只是 scripting 語言，在 integration, data munging, web development 和 rapid development 都很有辦法。
    * Ruby on Rails 有和 PHP 或 Visual Basic 一樣的快速度，而且又比 Java 乾淨。
    * Ruby middleware 支援 database integration, security, messaging, communications, XML, web services 等

Bridges

    * Ruby 提供跟別的程式語言很好的整合，尤其是 Java。
    * JRuby逐漸成熟，可以在 JVM 上跑 Ruby。
    * Ruby framework 偏好簡潔的XML和web services實作。

Ramping Up

    * 廣泛部署對Ruby還很新，deployment 策略常比類似的 java project 還先進。

Risk

最後一章談風險，包括技術上和政治上的。



http://railscn.com/viewtopic.php?t=1922

2 楼 YuLimin 2006-09-18  

robbin 写道

用ruby on rails确实很容易做到足够的敏捷，快速的用户反馈，令人吃惊的开发速度。

我现在就是觉得急需配套ruby on rails的软件开发最佳实践出台，现有的软件开发方法都不太适合ruby on rails。

Robbin问问松本看他们是怎么个开发的过程，或许真的有所启示？：）

1 楼 robbin 2006-09-18  

用ruby on rails确实很容易做到足够的敏捷，快速的用户反馈，令人吃惊的开发速度。

我现在就是觉得急需配套ruby on rails的软件开发最佳实践出台，现有的软件开发方法都不太适合ruby on rails。