Real World Fun with ActiveResource
I couldn’t necessarily pick a better title for the post, but essentially it’s the title of a presentation I gave last night to the Melbourne Ruby User Group.
The talk was a general overview about ActiveResource (a Ruby based library for talking to RESTful Web Services and deserialising the resultant XML into objects), based on some recent experience I had using it on a reporting project.
I did present a bit of sample code, but as this was literally just a bit of cut-and-paste from some Rails scaffold code, I’ve decided to not push it up to the cloud (but of course, I’m happy to do so if people are interested), and I’ve proceeded to publish a copy of the slides up to my account on SlideShare. You can find those here.
Railscamping
It has been a while, hasn’t it? I’ve been a bit too busy with some personal and professional stuff lately to be able to sit down and write a good piece for this.
A few things of interest which I’ve been involved with lately:
Last month, I presented a short piece on getting Rails applications up and running on top of JRuby for the Melbourne Ruby User’s Group. It was based on a number of experiences which I had on a team dealing with getting a new Rails application up and running. I also covered some details on the tools required to get it up onto a Java application server. Considering I’ve not done a big talk like that for a very long time, it happened to end up quite well (and got some great feedback from other people in the group).
For those who are interested, I’ve gone and uploaded the slides from the presentation onto slideshare, which you can find here.
On top of that, I was also at the most recent Railscamp – a big meetup of a bunch of Aussie Rails developers & enthusiasts. Being surrounded by a good weekend of geekery was great fun, and the vibe of the coding going on in the background during the days was quite motivating. My major contribution was a small piece on developing games in Ruby using the Gosu framework.
For those who have a bit of a random interest in it, I’ve uploaded the code I knocked up over the weekend onto Github, which you can access it here.
Overall, the weekend was a great bit of fun, including meeting a bunch of awesome people in other parts of the country. All I think I need to say – is rock on the next one!
Do tools maketh the man?
One of the things I find highly important to being a good developer is mastery of your tools and how they related to the technologies you’re working with. Whether that’s the venerable command-line, your preferred text-editor or IDE, and perhaps, even the operating system you’re running them all on, it’s incredibly important to be know your environment from back-to-front, and may even lead to you developing your own preferred shortcuts, command-line aliases, or even the discovery of custom tools and utilities (as any of my co-worker’s who regularly pair on my Windows machine would attend to).
Whilst this is all fair in practice, one of the cases where it happens to have some limitations is in organisations, which happen to take paired-programming seriously, which typically results in developers being unaware, or simply uninterested in wanting to evolve their tool knowledge beyond these stock standard defaults.
For me, being able to actually set up your preferred environment is something I happen to find important. From being able to pick an appropriate colour theming, or even the fonts your editors use, to even being able to add those aliases to your command shell (or, if you’re living in Windows land – being able to ditch cmd.exe and replace it with something like Powershell) is one of those things I couldn’t live without.
So when I do find myself working with something who doesn’t feel the need to do any of this stuff, I can’t help but wonder about their dedication to their own productivity – is it worth that much to being able to keep a stock standard environment, even if you lose productivity as a result? What about being able to refine your techniques as you happen to get more experience in the field, much like the development process, shouldn’t we aim to be able to improve how we build software as well?
Seeing people who work in this way just makes me feel like we’re losing something by environments where this conformity has been pushed, or, even worse, organically grown, as this artificial levelling in skill-sets may result in more developers who can work anywhere in their environment, but it doesn’t make things easy when they move outside it – what happens if a developer moves to a different organisation? Should they be expected to have to relearn a total environment just because it’s the standard. I think not – instead, developers should be able to pick the tools that they prefer to do the job, and get the experience they need with them.
Another entrant?
So, I’ve joined the blogging fraternity.
To be honest, this has been something I’ve been wanting to do for a while now, and as things have fallen into place on a personal level, I’ve decided to give it a shot.
For me, this is going to be a combination of things – highlighting things that I’ve been working on, plus thoughts & observations on differing aspects of software development.