Ruby, Ruby, Ruby

[SirTainly]

Ok not the song, the programming language.

Possibly have an oppotunity to crosstrain to Ruby (I'm a Java Dev), is it a good career move ? Anyone here used it and have views on it ?

Simon

Edited by SirTainly on Tuesday 18th December 15:33

[GHW]

IMHO..

It's a language that's useful to have knowledge of so you can use it to write test harnesses, code generators, prototypes, etc (non-deliverable stuff that'd be a bit quick and hacky anyway) a bit more quickly - really all the same sorts of stuff that Perl's traditionally used for.

Commercially I don't see it being used an awful lot outside of some web dev circles - there's significantly more jobs out there for Java/C++/C#/etc devs than there are for Ruby devs, although no doubt if you find a Ruby job it'd probably be far more enjoyable than any of the others!

[cyberface]

Ruby rocks. My favourite programming language of them all

It has to be said that I'm not a programmer any more, but for prototyping / data manipulation / data analysis / general BA type stuff it simply is brilliant.

Perl can do all of what Ruby does, as can Python, but Ruby IMO is a lot clearer, much easier learning curve (Perl can be a bit obtuse to the non-expert).

Not seen any jobs explicitly asking for Ruby though - it's more of a thing that you use when you've got a job... I prototyped a data migration system (out of databases, PDF docs, XML docs, MS Word docs, flat files) through a bunch of Ruby scripts out into a new database on one contract... the prototype was stable and performed well enough to be used in production and the developers understood it all (with no prior Ruby experience) - project delivered one day ahead of (an insanely aggressive) schedule.

It's really handy for messing about with data - though traditional commercial DBMS connectivity could be stronger (and may well be now). You can get a lot done with fewer lines of code, and the code is understandable by BAs rather than bearded Unix Perl techies as well, which can be a bonus... and fewer lines of code mean fewer bugs.

It's cross platform as well, but so are the other scripting languages - and interfacing with host APIs (like the Win32 stuff) will remove the cross-platform element of your code just as in Perl / Python.

I love it, but it's yet to gain a serious foothold in anything outside projects where senior BAs / architects are allowed to pick and choose random technologies for a laugh.

[SirTainly]

Cheers guys...doesn't look like a very good move then. Fingers crossed something else comes up, after today's events I can't afford to be too choosey.

[cyberface]

SirTainly said:

Cheers guys...doesn't look like a very good move then. Fingers crossed something else comes up, after today's events I can't afford to be too choosey.

Ruby *is* beautiful though. Utter elegance.

Many more jobs doing Java of course, but unless you're concerned you'll lose your Java skills by picking up Ruby then why not have a go? I'm not a 'proper' developer, but with the pickaxe book and an aggressive project schedule I still wrote bloody good code with it.

It's one of those 'cult' things though that have a bunch of very overt enthusiasts, and nobody else knows about it. It's very good, but hasn't got a marketshare because nobody other than the enthusiasts are pushing it. Apple support it, and it's installed as standard with OS X but so are the other scripting languages... and it's a bit 'niche' for a big company to write big apps with, even though it's capable of doing so.

I wouldn't rule anything out TBH - variety is the spice of life when it comes to IT - I see far too many developer-turned-'architects' who have one tool (Java==hammer) and think every problem is a nail.... always use the right tool for the right job, and it's difficult to become well versed in many tools if you stick yourself into a single-toolchain career. Not slagging Java (though I'm not a fan) - it's the same for dot net devs, Oracle-only SQL devs, C programmers, etc.

Sometimes being a bit of a technology slut and having a fling with them all gives you a rounded experience of the strengths and weaknesses of each technology. Unless you're planning to be a single-tool developer all your life, which is a damn risky career plan given how quickly things become obsolete, it may be worth it purely to show flexibility on your CV.

And you *will* enjoy Ruby coming from Java.

[SirTainly]

I agree with keeping a broad skill set, in fact that's what has helped me more than once. The problem is I've been a Java dev for 7 years, but in the last 4 have not used any of the new technologies because either I've been supporting legacy clients, or as in my current job working for muppets.

I really want to try and use my next job to catch up with Java if possible, and or get some time on .Net. I think spending another 2 years + doing Ruby most of the time wouldn't do my Java skills much good, and if Ruby wasn't really bankable commercially I'd be a bit stuck when it's time to move on.

Edited by SirTainly on Wednesday 19th December 22:45

[GHW]

Groovy's beginning to look a bit promising, from a Java point of view (it's kind of a Java-centric scripting language that looks a wee bit like Python).

My 'usual' dicking-around language is Python, but my current project is all Java stuff, and I reckon Groovy could come in very useful when it comes to prototyping new bits and writing random test harnesses that use the existing Java code.

[clonmult]

cyberface said:

Perl can do all of what Ruby does, as can Python, but Ruby IMO is a lot clearer, much easier learning curve (Perl can be a bit obtuse to the non-expert).

Absolutely right on Perl. my only experience of it has been looking at code developed by a colleague. He's done some very clever things with it, but jeeeeze, its almost impossible to decipher, especially on code with zero documentation, written by a guy who's come into software development as a hobby, no formal training whatsoever.

[kiwisr]

There is always JRuby

[anonymous-user]

clonmult said:

Absolutely right on Perl. my only experience of it has been looking at code developed by a colleague. He's done some very clever things with it, but jeeeeze, its almost impossible to decipher, especially on code with zero documentation, written by a guy who's come into software development as a hobby, no formal training whatsoever.

I thought that and avoided it for years. When the proverbial hit the fan a couple of weeks ago in the project I'm working on I had to throw something together and quick. A few CPAN modules hung together and interspersed with regular expressions saved the day and proved to me that it's very powerful and not too bad once you get your head around it.

[cottonfoo]

clonmult said:

written by a guy who's come into software development as a hobby, no formal training whatsoever.

Magic words

You can write Perl to be fast, readable, maintainable, extensible, and of course, obfuscated. Don't be put off by poor quality code

[Altrezia]

I dislike ruby - Just don't see the point for web-apps, and for anything else, why move away from Java?

[cottonfoo]

You can make something perhaps up to ten times faster with Rails than you can with Java/Strutts. Strutts also breaks the "write once" rule. However, it's still pretty much down to what you prefer. And I prefer Perl and Catalyst, because it's what I know

[cyberface]

cottonfoo said:

You can make something perhaps up to ten times faster with Rails than you can with Java/Strutts. Strutts also breaks the "write once" rule. However, it's still pretty much down to what you prefer. And I prefer Perl and Catalyst, because it's what I know

Yup.

And in my world, fewer lines of code mean fewer bugs, and delivering quality quickly means happy clients

[SirTainly]

Struts is old hat though (Noah's Blog for building the Ark used it) how does RoR compare to say something like Ajax?

[aspender]

SirTainly said:

Struts is old hat though (Noah's Blog for building the Ark used it) how does RoR compare to say something like Ajax?

Well apart from the fact that RoR is a server-side programming language and framework, whilst Ajax is a coined term for the use of Javascript to make client-side HTTP requests without a page reload which typically consume XML data (or JSON, or other stuff) they are the same

ETA: serious answer:

Ajax is a term not a technology. Javascript code makes HTTP requests to the server from within a page displayed in the browser. On the server side code handles the request and returns data which the Javascript then uses to update a part of the page. The server-side aspect of this whole interaction may be handled by a RoR app or any of a multitude of other ways.

Edited by aspender on Thursday 20th December 19:02

[SirTainly]

aspender said:

SirTainly said:

Struts is old hat though (Noah's Blog for building the Ark used it) how does RoR compare to say something like Ajax?

Well apart from the fact that RoR is a server-side programming language and framework, whilst Ajax is a coined term for the use of Javascript to make client-side HTTP requests without a page reload which typically consume XML data (or JSON, or other stuff) they are the same

actually looking at this from the RoR:

"Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern. From the Ajax in the view, to the request and response in the controller, to the domain model wrapping the database, Rails gives you a pure-Ruby development environment. To go live, all you need to add is a database and a web server."

it would seem RoR encompasses Ajax.

So perhaps what I should have asked is how well it compares with Ajax + Hibernate?

[SirTainly]

Thanks for the serious answer . I should say I'm not really au fait with Ajax/Hibernate/Spring etc. as I said before my Java skills are no longer current. The last decent app I worked on used Struts + EJB2.0s as I was on the project in 2005 and the app was quite old by that point too. I really need either to get back up to speed or do something different, hence why I asked about Ruby (my CV had been sent to compnay willing to cross train to Ruby).

[aspender]

SirTainly said:

So perhaps what I should have asked is how well it compares with Ajax + Hibernate?

Your quote about Ruby on Rails mentions Model-View-Controller. Model being the logic that is responsible for creating, reading, udpating and deleting data. The view part is responsible for displaying that data and the controller part marshalls between the two.

To give a fair analogy between RoR and the Java world would go something like this:

RoR gives you an all-in-one easy to build and deploy framework supporting the MVC architecture. It does a lot of work to make it easy to get data (from databases typically) and to generate the visual representation of said data. The view part can be programmed to use Ajax style interactions thanks to some support for injecting the necessary Javascript into pages built using RoR.

In Java there are a multitude of different frameworks and implementations for each part of MVC. For Model you have Hibernate, JDO, EJB and loads more. They all perform the job of giving you a simple Java API into your data and hide you away from writing SQL and JDBC calls as much as possible. For the controller part there's Struts, Spring (elements of it, it is more than just a controller framework) and many more. An increasingly important part of any controller framework is the concept of annotations. These help make writing controllers easy (in fact they will typically be code-gen'd for you) and help to abstract you away from the lower level APIs such as Servlets. Finally for the view layer there are even more ways to do things in Java. JSP is the most long in the tooth and then there's also things like Velocity. However these do little to help you easily create Ajax interfaces, you will just end up with JSPs containing shed loads of Javascript to do that. Newer kids on the block like Google Web Toolkit (GWT) are much more interesting.

So your original question is better phrased as:

How does RoR compare to Spring + Hibernate, or JSP, Struts and JDBC.

[cyberface]

I've seen too many botched Hibernate implementations where the database is used merely as a persistence layer for the object model and is useless as a relational database for any other purpose (e.g. reporting) - requiring additional projects to make use of the data outside the application.

Of course I'm old fashioned and relational databases are still useful technology, I suppose you could go the whole hog, ignore any object-relational mapping and just use Hibernate as an object store, and make the app's data available over a web service or some other old SoA model.

I think that Java and Hibernate almost encourages this approach (design your app objects, leave the actual business data until later), or perhaps I've seen too many bad coders - I appreciate that Hibernate can be properly used to map a proper data architecture to a proper Java object model - whereas RoR seems to foster thought being put into both layers. Then again, perhaps I've only seen good Ruby coders....

Given its prevalence in the City at least, if I were a Java developer and wanted to stay a developer, I'd get up to speed with Hibernate / Spring / etc. because they are very commonly used. And they're used badly in most cases, so being good will get you jobs.

If you already had all that shit under your belt then I'd say learn Ruby (it'll take you a day, and you'll love it) - but if you're not au fait with Hibernate then there's a whole world of crap financial apps written in Java with Hibernate talking to Oracle on the back end for you to get jobs in....

That's the bottom line for *getting jobs* - certain technologies are more prevalent than others and will have more programming roles available. I personally subscribe to the 'fewer lines of code == fewer bugs' and love Ruby, but at least in the financial sector it isn't a wise career move. I only got away with delivering a Ruby app in an investment bank because I was the technical architect and it was my choice I don't think there are any others out there, and mine was a tactical app anyway - I wouldn't have recommended it for a long-term production app due to potential lack of future skilled resource.

My last comment on this before I get flamed by 'technical architects' is that there's more than one optimal architecture and it varies by application. MVC apps aren't ideal in all cases, sometimes even boggo OO isn't appropriate.