Implementation Language Matters
"Speaking" a programming language is like speaking any other language. One major difference though is that while you don't often see for example an English speaker who insists on trying to speak French with an English sentence structure, you quite often see practitioners more familar with one computer language try to apply that language's idioms to every language they know. In my experience these are quite often former C++ types who insist on speaking Java, and every other language they know, with a strong C++ accent, particularly when it comes to design. I'm sure the same holds true for many long-time Java developers crossing over into Rails or some other language. The design idioms valid in one language are not necessarily valid in another.
I had a former long-time C++ turned Java developer recently state matter-of-factly to me that design and language are independent. This may be the case from a theoretical, academic or ivory tower standpoint, but it's not the case down in the trenches. The pallet of language and technologies used for implementation has a profound effect on application design. Certain frameworks for example often encourage particular design idioms that you may not follow had your choice of technology been different.
As an example, Java designs often rely quite heavily on Java interfaces. We do this for several reasons including some that are immediately practical. Decoupling dependencies and abstracting them with interfaces is generally considered a good practice, but a very practical reason for doing this is to better facilitate unit testing with mock objects. This is a bit foreign to many in the C++ world who are quite happy to spend their time in the debugger and consider such abstractions as over-engineering.
I agree with Stuart and think he hit the nail on the head regarding design patterns and language. But just as implementation language matters as far as design patterns go, there is clearly something in our choice of language and technologies that encourages certain designs in general. Design and language are not independent.
Review - Rails for Java Developers
In "Rails for Java Developers", Stuart Halloway and Justin Gehtland provide an introduction to Ruby and the Rails web application framework aimed at the Java developer more familiar with frameworks such as Struts and Hibernate. There's a lot of buzz in the Java community surrounding Ruby and Ruby on Rails so this title is quite timely.
Halloway and Gehtland provide a tutorial to learning Ruby and Rails by examining similarities with Java. The tutorial progresses by providing examples in both Ruby and Java using popular Java frameworks. The introduction of Ruby and Rails concepts by juxtaposing them with similar concepts implemented in Java is comforting for the developer who may feel a little intimidated by the differences between the languages. Working through the book, the Java developer will learn the basics about creating and deploying Ruby on Rails applications, picking up an exciting new language along the way.
The first three chapters introduce the Ruby programming language. This is the best Java-centric Ruby introduction that I've seen and it's something I wish I had available to me when I was first learning the language. The rest of the material covers the basics of Rails applications as well as web services and security issues. I found the chapters on testing and automating the development process to be particularly good.
The approach this book takes may not be suitable for everyone. After a certain point, I found that the constant juxtaposition of the Java way of accomplishing a task with the Ruby on Rails way of accomplishing a task wore a bit thin. I found myself just trying to skip past the Java bits to get on with the Ruby. Still, I found the book to be quite good overall. If you are an experienced Java developer seeking a gentle introduction to Ruby on Rails, you can't do better than "Rails for Java Developers".
