My wadings into the Ruby language

First of all, sorry for the lack of posts lately. I've been occupied with a number of things, one of them, a fast-track learning of Ruby, the topic of this post.

So having been at this web stuff for a while now, I have of course heard of Ruby. It first came to my awareness when Ruby on Rails was first making the rounds, about 5-6 years ago. I toyed with Rails a bit, and while I liked the concept, it didn't seem ready for the sorts of tasks I wanted, some of the layout bugged me, and I gave it a pass at the time. At that point I'd never really considered Ruby for non-web use. (IE: as a system scripting language.)

I had a similar stance on Java up until around that time, but it becoming so common, I started taking up that language. I was impressed that as of Java 1.5 it had really grown up, and in other ways, less impressed at how overgrown it had become.

Stay with me folks. This does come back to Ruby. :)

I really liked the more recent innovations in Java 1.6, including the JSR-232 specification that allowed for other language implementations on the Java Virtual Machine, and to varying degrees, interfacing back and forth between Java and the alternative language. There have since sprung a dizzying array of languages, from PHP, to Python, and yes Ruby. There are many more, both re-implementations of existing languages, and many new ones made to work closely with Java.

I ended up particularly drawn to one called Groovy, which supported all sorts of great things from a terse syntax befitting a scripting language, to powerful introspection and the ability to treat objects as transparent, mutable entities. This is totally alien to traditional Java programming, which is more like C++ in how it deals with the definition of objects (IE: resolved at compile time only). But it's right at home with scripting languages. Add to that that is was an alternate lanugage designed FOR the JVM, and had some of the best support for cross-implementation calls, and it was my favourite new language for a while.

Groovy also has something called Grails, which is something right along the lines of Ruby on Rails, but of course on Groovy, and more aligned to the various Java frameworks such as Spring, Hibernate, and JSP.

So with the back-story in place... how I've tripped into Ruby, is that similar to Java a few years ago, I am seeing there's a push of late to put it into place for serious development. So I have opened the door to learning it, and took a crash course with an O'Reilly book on the subject about two weeks ago. More on the book in a future post.

Overall it's been a great experience, Ruby has been very easy to work with and *almost* everything has just worked. It has most of what the Groovy language offers in terms of language features, but the commitment to Java becomes a choice, not a requirement. That said, the Java implementation of Ruby, jRuby is no slouch, and in some areas bests the original implementation, being first to offer things like pre-compilation of scripts. (Interestingly, both Groovy, and jRuby seem to originate from Codehaus)

While I can't talk any specifics about what I've been working on, I can say that I am amazed at how productive I've been with Ruby in this short time, having never gone beyond the "Hello World" example prior to a couple weeks ago.

Some various and random impressions:

• It's not a simple language, it's nearly as grammaticly dense as Perl, but it feels like with less "edgy" cases. There's a simple simplicity and coherence to the language which reminds me of somewhat of Lua, in that even in the core language, higher-level details are often implemented in terms of lower-level language features. I am not sure it would be a good starter language for someone brand new to programming.
• It's great as a system-level script language. Perl hacks will feel almost at home, and it rips off some things it would seem directly from perl (like magic punctuation variable names for various things, down to a "use english" variant). In fact, Ruby almost feels like Perl with a formal object specification. (And no, I don't count Moose, and never will... a rant for another day.)
• It's great as a strong OO language. Java folks will feel almost right at home. While this may seem a direct contradiction to saying Perl folks will feel right at home, it oddly isn't. Ruby takes the everything-is-an-object approach to even deeper levels than Java. That said, there are adjustments for the Java programmer to make, such as some differing semantics on object/value equality, to exceptions being something your raise and rescue, instead of throwing and catching. (But you can still to the latter, which have nothing to do with exceptions in Ruby).
• my intuition served me well in waiting for Ruby. I've already run into issues with slightly older versions of Ruby (any version below 1.8.7, the latest as I write this) and have seen readings around that strongly suggest that anything below that is likely to be problematic. Many are waiting with baited breath for the release of Ruby 1.9 which introduces some futher evolution to the language, but seems to be careful to be compatible to the 1.8.7 language specification. For the folks preferring not to use the jRuby implementation, this also brings big improvements in execution speed, and a proper bytecode/VM to make multiple execution more efficient. But all that said... 1.8.7 serves me quite well, and has been quite stable, both in the Java version and off.
• the ecosystem for third party modules is strong, in a manner similar to Perl's CPAN. This is still my main reservation, as I don't consider it a good model for deployment for the installation instructions of my app have as it's first step be: "Install these dozen or so modules, and their dependencies, as extensions to your vendor's distribution of the language, from this ever-changing repository". How this ever came to be an acceptable request to make of someone deploying an application is utterly beyond me, and remains at the core of why languages such as Perl have fallen out of scope for many in my opinion. Even in my own endeavors with Perl, my strategy tended towards having projects bring in local versions of only pure-Perl modules, to be distributed with the application, to avoid having to ever emit such an insane set of installation notes.

So, I am taking the same cautious approach with Ruby, and so far, I have been getting fairly far using core or standard libraries. The problem is further compounded as I wish to create code which works equally well under either jRuby or the original, and the 3rd party modules, if not pure Ruby, are problematic to keep mobile between the two implementations.

If there's anything Java got right (and then got wrong again...) it was in putting an unrelenting focus on implementations in pure Java. If I need a MySQL driver, I grab it and go. If I need a serverlet container, I can grab it, and go... I need not concern myself with whether this particular system has the C client libraries, and the C compiler needed to install the driver to my language. (And that the version of my driver shim support my version of the language AND the version of my C driver, and... *head explodes*). All too often a language's support for this or that is a re-wrap of a C library, which makes it hard to deploy to N systems of varying specification.

I am hoping not to run into these frustrations too much with Ruby but will tread very carefully. I really like the language, and want to keep using it as a system-level scripting language. As well, in working with Grails, I came to accept the more rigid layouts that come with such frameworks, so I am looking forward to giving Rails another try soon too.

So there it is... that is one of many things distracting me from blogging. Hope to have more up soon. :)

TTC's "helpful" instructions to disabled for a broken elevator.

To anyone not familiar with the Toronto subway line, this is probably going to make no sense. But if you are... well... this is going to sound just completely bonkers.

So last night, I was on my way home, and just missed my connection to my bus @ St. George station. I was bored and looking around, checking up on social networks on my phone, and two things came together at once:

First, a friend on Facebook with MS was lamenting the not-uncommon case of "accessible" entrances often being extremely out of the way of the main entrance/exits to buildings.

And with that fresh in mind, I happened to glance upon a sign on the bus platform, indicating to those unable to use the stairs, what their alternatives might be should the elevator be broken. Picture is included at the end of the post.

And the more I read it, the more crazy it begins to sound... so I start thinking of the worst case, but possibly very real scenario, of someone who might:

- live in my general neighbourhood at Lansdowne and Dupont
- have a disability where using stairs was simply not an option, but otherwise mobile
- wants to go to Downsview station to do whatever might take them out there.

What would happen if they came upon the broken elevator, the contingency for which this sign is specifically designed to help?

Not knowing in advance of a situation here, the trip planning would likely be to take the 26 Dupont east to St. George, elevator down to the University line, and north. Easy!

So they set upon their way, get to the bus platform at St. George, and find the elevator to be broken, and read the sign, and come to realize their next steps are to:

1) Get back on the bus you just got off (hope it hasn't left yet...) and go back the way you came.

2) Go nearly 1/3 of the way back the way you came to Bathurst and Dupont St.

3) Wait for the southbound Bathurst bus, and take it to the Bathurst subway station on the Bloor line.

4) Take the subway east, past your intended transfer point (because the elevator to transfer subway lines is the same, broken one, causing this detour), to Yonge/Bloor station.

5) Take the elevator there (what are the chances both could be broken?) to the  Yonge line and go south.

6) Loop all the way past the 12 stops of the down-town loop then wave at the now very familiar St. George station, which you are now passing through for the third time, and continue to your destination.

So two extra buses, 14 extra subway stops, and probably close to 2 extra hours later, you have now reached your destination, thanks to the incredibly helpful instructions provided by this sign.

Now, are you ready to make the return trip home after?

So here it is... proof I am not making this up... the helpful sign by the elevator at the bus platform at St. George station (my apologies for the blurry picture, took it on a phone camera in the dark...):

So, I mean, most times this elevator is going to work, and this insanity will never need to be heeded, but seriously... this is the best option we can present people?

I sure hope not.

It's Lady Ada Lovelace day

Just a quick note to remind anyone who's missed it that today is Lady Ada Lovelace day, celebrating the life of a pioneer in computing, and women in technology fields. I don't think most people generally appreciate the role women played in the early days of computing... for more about Ada, and some current women in the field see the great stuff being blogged @ the Adafruit blog.

Back to who'd I'd like to feature... first up is Grace Hopper who was known as the "Mother of COBOL" (it was largely derived from her prior work on another language), and popularized the word "debugging". She for all intents and purposes invented the "high level language", which is to say we program with english-like expressions. Check the link to the Wikipedia page on her for more.

Lastly, I will point out that the ENIAC was programmed almost entirely by a team of six women!

So... happy Lady Ada Lovelace day. Spread the word!

NoSQL, getting back to basics?

I was reading an interesting article on O'Reilly Radar, about geo-spatial, location-aware application development, but I found the discussion towards the end about the application of NoSQL the more interesting part.

I've always grimaced at some of the SQL queries that come up... you know the ones, they are nearly a page long (or are multi-page affairs), and nearly impossible to infer the original intent. To centralize such complexity on the server side has always seemed like a bad idea to me. Keep the queries simple and quick to run, so as to not tax a critical central resource. That sort of application complexity should go in the application layer you can grow out easily vs. the database layer which is rather more hard to grow.

But I wasn't a "database guy", and deferred to those who were, and had these odd sense I was somehow missing something, and would let the "experts" deal with such issues. But it always felt wrong...

So to see stuff like this is being citied as the state-of-the-art thinking in data scalability is... satisfying:

"....at Digg, for instance, joins were verboten, no foreign key constraints, primary key look-ups. If you had to do ranges, keep them highly optimized and basically do the joins in memory. And it was really amazing. For instance, we rewrote comments about a year-and-a-half ago, and we switched from doing the sorting on a MySQL front to doing it in PHP. We saw a 4,000 percent increase in performance on that operation."

It really does feel like there is a renaissance happening in data storage, and this sort of getting back to basics is a key part of it I think.

Micro LED Matrix

So I was looking for a distraction when I was stuck on a project last week, and decided to throw together a variant of the "64 pixels are enough" project by Alex at Tinkerlog...

I really did nothing with his code besides change up some of the sayings. Differences hardware-wise are a smaller LED matrix I had from Seeedstudio's store and the use of a CR2032 coin cell for power. It seems to run for about 2 days on that vs. the 2 weeks Alex gets from 2xAA cells, but it's more compact. Some of the folks interested in wearable items may find it of interest.

I'm happy with how it turned out, and have a video below. Apologies for the poor quality, done with a phone camera, and it seems an interaction between the refresh rate of the camera and that of the the device caused double frames to show in much of the video.

Hello.

My name is Joe, and I will be your blogger for this visit. I am a geek-by-trade, and well... decided it's rather time I start blogging about my various interests, personal, professional, and well, whatever I feel like blogging about. It's bound to get eclectic at times, and I hope practical, insightful at other times.

It's late, and I am messing around with a little mini pixelboard project and wanted to put the URL to where I plan to blog in, so I created this just now, and don't have much time to settle in and make it hope or write much tonight. But... I do plan to commit to some regular postings on here going forward.

Off to finish that up... but welcome to my blog. :)