All 3 entries tagged Ruby

View all 5 entries tagged Ruby on Warwick Blogs | View entries tagged Ruby at Technorati | There are no images tagged Ruby on this blog

August 16, 2006

Ruby: the bad

Follow-up to More fun with Ruby from Secret Plans and Clever Tricks

Someone asked recently if we had an rss splicing service available anywhere – take 2 (or n ) feeds, and return a single feed comprised of all the entries from all the feeds, correctly date–ordered. We wrote one ages ago, but it never quite made it into production so we dropped it again. So, I thought I'd try the golden hammer and see what Ruby could do with it.

Sure enough, gem install feedtools and 10 lines of code and I had a working splicer, running as a web service. Point it at a couple of feeds from WarwickBlogs and...wait...and...wait... and after about 10 seconds, it returned a beautiful spliced feed. MMMKay, maybe blogs is taking a long time to return the feeds. Stick a squid proxy between me and blogs, hack a refresh pattern to work around blogs' inability to serve cacheable content, 2 more lines of ruby to configure it to use the proxy; web requests now take about 1ms, feed splicer still takes 8 seconds.

Fire up the ruby profiler to see it it's doing anything obviously dumb, it doesn't seem to be. It seems that ReXML, ruby's default XML parser, is just hideously slooooow. If it takes 8 seconds to splice 2 feeds of 10 items each on my relatively quick PC, this is never going into production. Ah well, better dig out the java one; which, if I remember correctly, could splice two feeds in a small fraction of a second. Of course, it'll take a day to get something working, and another day to get a production environment set up, and this is hardly mission–critical so it's going to the back of the queue. harumph. Maybe by the time I get round to it someone will have tuned the FeedTools so I can go back to using Ruby :–)

September 01, 2005

Can you do big applications in little languages?

Follow-up to Ruby vs Java from Secret Plans and Clever Tricks

In a comment on my previous post, Jon said

My overall impression of Ruby on Rails is that it might be good for getting things going quickly, but it's bad for building large, stable, maintainable systems

I think this is interesting enough to examine in more detail. Though before I start, I'd better add a disclaimer: I'm a Java programmer, and whatever I might say in the rest of this entry, I'm likely to remain one for the forseeable (I hope!)

Anyway, on with the show. I think you can take two approaches to the statement above. Approach 1 is the easy one: Sure, you wouldn't write an airline reservation system in RoR, any more than you'd use J2EE to munge the output of top, but how large is large? Does any UK university have a bespoke web system which is too big to manage in RoR ? Sometimes, Java programmers can be guilty of treating every application as if it was the flight control system for a 747, when it's really just CRUD for 3 database tables.

…which leads me to approach 2, the more interesting approach. What are the limiting factors for an app. written in RoR? Or PHP+{Cake/Biscuit/Mojavi/etc.}, since it shares many of the same characteristics ?

I think that scalability in terms of performance is a complete red herring. There are any number of mahooosive apps running on LAMP architectures – tens or hundreds of millions of hits a day. There are less for Rails, in part because it's much newer technology, but I don't see anything there that makes me think it wouldn't scale in the same way.

Similarly stability, at least in terms of uptime. PHP and Rails' shared-nothing, sessionless architectures actually (ISTM) make it easier to provide resilience in the form of load-balanced servers, and the periodic cycling of httpd workers makes worries about memory leaks and the like much less of a big deal. Again, looking at the real world there are loads of LAMP sites whose application uptime is up above 99.99%; I'd contend that there are very few web applications with an uptime requirement that couldn't be met with a scripting langage-based architecture.

So we're left with questions of maintainability, which is where it gets interesting. There's absolutely no doubt in my mind that there are some awful bits of PHP out there running stuff on the internet. Not least because I've seen and had to clear up some of it. But there's some bloody terrible java too. And when you consider Ruby, the picture gets even muddier; Ruby is at least as OO as Java, if not more. There's nothing inherehent in Ruby that's any more likely to make you write crap than there is in Java.

At the end of the day, maintainability is, ISTM, a people issue and not a language issue. And this may be one area where Java scores. Because the barrier to entry for java apps is higher, (a) the average coding skill level is higher, and (b) the average team size (and thereby probability of at least one good coder involved in the project) is higher. But that just suggests that the same team ought to be able to produce equally maintainable code, regardless of platform – so they should choose whichever one makes the job easier.

There are a few thing that do weigh heavily in Java's favour though. Decent tooling (IDES, build tools, etc) and, arguably more importantly, high quality libraries for core stuff like socket malarkey, threading, unicode handling and XML parsing.

Nontheless, I'm skeptical of the claim that a scripting langage "can't do" big complicated applications. It feels a little bit like something that (to paraphrase Cal Henderson) "Is said to be true because it would be good if it was true".

Still, I'm sticking with Java. It's like a favourite jumper; sure it might be a bit scratchy, and some of those new t-shirts the cool kids are wearing sure look good, but I can't quite bring myself to risk getting caught out in the cold :-)

August 31, 2005

Ruby vs Java

Writing about web page

Actually, it's not a Ruby vs. Java post as such, if you want a language p*ssing contest you can look here.

However, following on from last week's Flickr event, I've been devoting a bit of time to thinking about the alternatives to our current J2EE deveopment environment, and whether we can learn anything from them. I couldn't quite bring myself to try PHP, but Ruby seemed like an a suitable point of comparison.

So… Language-wise, Ruby is quite nice. It's properly OO, dynamically typed, with a reasonable exception system. Using begin/end instead of { and } makes my toes curl a bit, but at least it's optional.

Rails is to Ruby as (approximately) JSP,Spring&Hibernate (or JDO&JSF) is to Java; an MVC-ish framework, a templating language and a persistence framework. It's really easy to do basic CRUD in; the framework does most of the work for you and there are code-generators to get you started. However, if you want that sort of thing in Java you can have it, with something like appfuse

The (apparent) lack of a decent IDE is aggravating; I've got pretty used to just banging on ctrl-. ('fill the next bit in') and ctrl-1 ('fix this error') in eclipse, and having to go back to vi was a bit of a slap in the face. ISTM that this is one of the big disadvantages of a dynamically typed language. But the tradeoff is the instant deploy: change code, hit refresh, view results. I'd forgotten how efficient that makes things; I must try and get that working in eclipse again. This is especially a problem with Spring and Hibernate, both of which take ages to post-process a deploy for various reasons

For my next trick, I'm going to try and do something which isn't quite standard CRUD, to see if Rails is trading off flexibility for ease-of-use or not.

Most recent entries


Search this blog

on twitter...


    RSS2.0 Atom
    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXXI