Tip #8 from The Pragmatic Programmer states:
Invest Regularly in Your Knowledge Portfolio
The first investment tip that it offers: LEARN AT LEAST ONE NEW LANGUAGE EVERY YEAR
In all honesty, I’m a bit behind. I’ve had my head down in the JAVA sand box for the past 5 years years and am just now coming up for air… Why now? I think a lot of Java developers out there are realizing some of the short comings of our language. There are 1,000 ways to do web applications, and none of them are “easy”. I’m not advocating drag and drop and *bam* you have an enterprise level application. What I’m talking about is the ever growing stack of tools that we must keep up with. Spring, JSF, Webwork, Struts (*grin*), Hibernate, and the list goes on and on. One of the biggest shortcomings of all of these API’s, at least in my opinion, is the failure to appreciate “The cost of change” and “The Price of Complexity“. Actually, the Price of Complexity may be The Cost of Change, or does The Cost of Change add to the Price of Complexity?? I can never keep my FUD straight…
Bruce Tate, from “Beyond Java”:
But I’ve come to recognize some real limitations in the Java language, and many of the frameworks that power it. For certain problems, Java just isn’t productive enoughfor me any more. I’ve experienced success with some alternatives. Though a language can last half a century to support legacy applications, I know no language can keep its leadership and its luster forever. Java’s reign will end. It’s not a question of if, but when.
Let me walk through my little spin on programming history. Keep in mind that I’m not half the developer that the creators of these great API’s are. Which is why I use them, err… I mean their work, instead of publishing my own latest and greatest thing. I have a lot of respect for guys like Erik Hatcher, Rick Hightower, Matt Raible, Rod Johnson, Bruce Tate, and others that have contributed quite a bit to the Java community…
After leaving the .com world and returning back into the real (read Corporate) world, I quickly realized a huge lesson. Change is constant. Clients will change their minds atleast 5 times before you hit on something that is even close to the application that they want, or dare I say need… And while change was regular in the .com world, atleast we could start drinking at noon and pretend that it was not so bad…
Seriously though, what happens when a client introduces a new feature request at the last minute? The XP philosophy say to negotiate with the client. Ask them to prioritize their story cards and help determine what will go in the current release. This works out well on a power point slide infront of a room full of developers all wishing for the same XP nirvana, but what not so much when you are sitting in your 10th meeting of the day with the VP of the department XYZ who is not taking no for an answer… (Yes, I realize that I am generalizing…) Bottom line, you are going to do the change… and endure another five minutes in a meeting listening to all of the latest pieces of buzz words and jargon being thrown around to justify the push for more features… I really hate the word synergy.
Ok, so our next trick was to become Agile. We will deliver code quickly, receive continuous feedback (from our code and from our client). In other words, we will be better able to handle change. Cool. Fire up JUnit, run the tests, everything is green… and actually this held up for a while, and I still think it holds up today in the Java world. The IDE’s and API’s available for unit testing are top notch. All of this has led to better code, and has made developers more confident, and effective when change has to occur. Plus we got to talk about our Units… Tests! You sick freaks…
So what happened? Being confident to make changes and being able to make changes does not help in the long run. I firmly believe that businesses change on a weekly, maybe daily basis depending on how large a company you work for. It is not practical to spend 3 days munging through XML Situps (ant, hibernate, spring, etc config files) to make a change. Remember, I’m not a very good programmer…
To be fair, I should mention that there have been some really cool projects released that are designed to help with this issue. AppFuse for one is a pretty sweet package that allows you to choose from 5 web frameworks and then builds the initial project structure out for you. This has been VERY helpful to me as I continue to use Jave regularly in my day job. Spring is actually pretty nice too… The MVC framework is FAR superior to struts, and it does help you do a lot of the config behind the scenes. For those interested, I think that Spring Live by Matt Raible is an excellent/practical introduction to the Spring stack.
However, with all this said, I think that Dave Thomas is pretty close to the mark:
Using the full might of a J2EE stack to write a small stand-alone application is using a sledgehammer to crack a nut. But I keep hearing the sound of nuts being pulverized as developers seem to think that using anything other than J2EE is somehow unprofessional.
Alright, so where am I going with all of this? I’m going to try something new. And I’m going to do it right here on this blog site. I’ve purchased the only < ?> book out about Ruby on Rails: Agile Development with Ruby on Rails. I’m rolling up my sleves and I’m going to learn all that I can about this new framework and language to see what it is that I am missing. As I get through the book and begin to implement some of my own ideas (37Signals is quite inspiring) I’ll be sharing my development experiences and will be sharing with the world all of my mistakes as I attempt to migrate from Java to Ruby on Rails. This change is not a permanent one. I’ll still use JAVA 100% of the time at my day job, and I think that for integrations and large scale projects, the choice of Java is pretty clear… And despite my self-deprecating humor, I do have quite a bit of Java knowledge and some skill and I would like to continue using it. This “experiment” is more or less to figure out if there is a “better way” to do the small to medium size projects… There’s nothing worse than getting nickeled and dimed on a small project… We’ll maybe if they started throwing quarters…
My first step: Figuring out how to get all this stuff running under Eclipse…
Yeah, that’s right… You can pry Eclipse out of my dead, cold, grubby hands…
Luckily, for me, it does not have to come to this… There are some articles out there that show how to get this done:
IBM Developer Works: Using the Ruby Development Tools plug-in for Eclipse
Rails in Eclipse
Baby steps… right?
If you do know of a better Windows development environment for Ruby on Rails, please leave me a comment…
–Ryan



