I-o, I-o, It’s Off To Work We Go

Language number 2 of the 7 is Io. When Bruce Tate was picking the languages for inclusion in this book he discounted JavaScript due to its ubiquity. Io takes its place as a prototype based language, and in the intro Bruce tells us that learning Io helped his understanding of JS. In my web developmenty day job I tend to spend more time on the back end, so don’t hit JavaScript too much, but from time to time I have the odd job to do in it. I can muddle through, but I’d certainly not claim any major expertise with it and I’m always happy to get back server-side. So despite not having heard of Io prior to discovering this book, the promise being able to apply some of the principles learnt here to my work has some allure. Additionally, at the Io’s home website, http://iolanguage.com/, the overview mentions that it was inspired by Smalltalk, a language that seems to be the starting point of every good idea in the industry right now. Admittedly, plenty of other languages are probably inspired by it as well, but it’s nice to see the reference in black and white :)

At this point I screeched into my first blocker. There doesn’t seem to be a download of the binaries available. It’s an old-school, unix-style, build-it-yourself job. That wouldn’t be sooo bad, but I’ve not installed Xcode on this box yet, so I don’t have the tools installed to do so. So to run what is described as a teeny tiny little interpreter, I’ve now got a few gig of Xcode install running. Waiting…

…And there we go. With Xcode installed I now have the ability to run make. Unfortunately the instructions for installing Io also require cmake. Another download, more installing…

…And finally, I can build the app. The Readme.txt file instructs me to run the following:
   mkdir build && cd build
   cmake ..
   make install
which, of course fails part way through the final step. A bit of googling and I find that a better command would be:
   sudo make install

…And at long last I can fire it up. Hoorah! The intro to the book states that we are on our own when it comes to installing the languages due to the wide variety of platforms etc. that readers might be using, which is fair enough. However, after all the hassle getting to this stage I decided to just run the hello world app as a quick test and take a break from it. Page 1 of Day 1 has taken me far longer than I feel like dealing with right now.

Hooray For Me, It’s Ruby Day 3

I’ve finished the first of my 7 languages, and in just under the week. Go me. The final chapter on Ruby focuses on the metaprogramming aspects of the language which are some of the things that Ruby fans seem to love.

We start with adding methods to existing classes. This is something that .net has some ability to do since the introduction of extension methods, but Ruby really adds the methods to the class unlike C# where it just adds different locations to look for it, so it doesn’t look like you’ll need to include references to different assemblies and namespaces and whatnot to find the method.

Next up is method_missing which is a very nice technique indeed. Basically it passes the name of the method being called as a parameter so that it can be dealt with in code. The example given was an api for roman numerals so you could enter Roman.XIV or Roman.VII for example and the numeral would be parsed and a number returned.

The chapter ended with a section on modules. I felt that this was not as clear as what had come before it unfortunately, though by the end of the section and with a bit of fiddling I was starting to get an idea about some of the things that it was showing. Certainly enough to be interested in finding out more about the language.

The self study for this day only had one task which was to extend the module that we’d written to handle CSV files with some metaprogrammed method_missing goodness. This went a lot quicker and smoother that day 2’s exercises, but again it would have been nice to see a completed version to compare against mine.

As an intro to Ruby it was short and sweet. I certainly can’t claim to have learned Ruby yet, but I’m undeniably further on than I was and keen to learn more in depth. I was able to pick up a copy of the pickaxe book from pragprog whilst they were running it on super special offer prices, so this will be happening sooner rather than later. Following IronRuby’s recent release of Visual Studio integration tooling, I’m looking forward to seeing how it can help my .net based apps.

Finishing Ruby Day 2, After A Day Or Two…

Finding the time to finish day 2 took me a few sessions over the next few days, but I’ve finally wrapped it up. The lessons continued with writing our own classes. This started with a simple tree example which I ended up getting a little carried away with extending. After that came mixins. These seem to deal with multiple inheritance issues that .net uses interfaces for, but Ruby includes implementation, which is nice. The chapter finished with a bit more general data manipulation.

The self study section starts with finding stuff again, but where day 1 was “find the docs” this is more focused on learning more about topics that we’ve touched in this chapter so I had to pay more attention to the content that I found.

It then moved to the exercises again. This time it felt a bit more like being thrown in at the deep end, requiring more googling and experimentation. This continued the theme of working harder to get more out of it, which is not without merit. The first set of exercise mentioned that there’d be answers at the back of the book, but this is not the case. Whilst with coding there is generally not a single correct answer, at this stage in my learning of the language I’d like to see what is considered to be a good solution to compare against mine. There are aspects of my code where I feel that I may be missing a better approach, but it does what I expect of it, so it can’t be tooooo bad.

Finding the time to get all the way through this chapter was tricky. However, this has a lot to do with the fact that I want to be at my computer to fiddle with the samples rather than just reading the book on my commute or something. That would have let me blast through things a goodly chunk faster but I’m trying to get the most out of it, so I’m happy with the progress I’m making through it.

Ruby Tuesday

The chapter for day 2 is a chunk longer than day 1, so with only a limited amount of time I did not manage to complete it. I did like what I saw though.

The first thing that jumped out at me was in array access. Given a plain old array like a=['first', 'second', 'third'] I’m entirely used to the concept of a[0] being ‘first’ a[1] ‘second’ etc. but have never seen the reverse indexing feature whereby a[-1] is ‘third’ and that delighted me.

I have seen snippets of Ruby like 3.times <blah blah blah> before and quite liked the flow that it lead to, but being able to assign a number to a variable and then use it in the same manner, like:
>> b=5
=> 5
>> b.times {puts "rockin the b"}
rockin the b
rockin the b
rockin the b
rockin the b
rockin the b
was another pleasing experience, as it seems more useful than just being able to run it on numeric literals.

After this we moved on the a custom implementation of the times method that we added to the Fixnum class using the yield keyword to execute the blocks of code. I quite liked the introduction of extension methods in .net for the ability to add handy methods to classes, so seeing this part of the dynamic nature of Ruby was another good thing.

I’ve got a little way to go yet before I even reach the next set of exercises, but again I found myself expanding on the samples given in the book which is a good sign that I’m feeling interested and engaged in what’s happening, and helps to make that learning start to stick. I had been contemplating trying to squeeze some IronRuby into some personal projects that I have been planning, so this bodes well for that.

So far, the only thing that I don’t like about Ruby is that it seems to favour the use of the underscore in naming conventions. I’ve long been a fan of the camel/pascal case conventions used in .net land if only for the simpler typing and shorter names that it provides. Ho hum, it can’t all be hugs and puppies.

7 Languages

People keep batting around the statement that you should aim to learn a new language every year to be a good programmer. This tends to be attributed to the book “The Pragmatic Programmer” the authors of which went on to create their own publishing company and have released many more books on programming pragmatically. One of their most recent releases is “Seven Languages In Seven Weeks” and in my aims to be a better dev, I have decided to attempt to follow this book and see what I can learn. It takes a bunch of languages that have fundamental differences between them, such as dynamic, functional and logic based, aiming to give you a basic understanding of what makes that language interesting and useful compared to the others. Whether or not I get to use any of these languages in my day job, hopefully it will open my eyes to different ways of doing things, and make me better with C# and VB.net.

The first language up is Ruby. I’ve never had the chance to get involved in Ruby at work, but have heard plenty of good things about the language so have been interested in learning a bit about it. I’m sure that there are plenty of other devs in the same boat, so this was a great choice of opener in my opinion.

Day 1 starts with a simple intro to Ruby syntax: simple assignments, printing to the console, the fact that everything is a object unlike .net with its value types, the way that the if statement considers 0 to be true, and touching on the dynamic typing but without going into enough depth to really get a feel for how this is useful in the real world. I hope to see days 2 and 3 help to get this point across as this is one of the key areas that I want to grok about Ruby coming from a static language like C#. There are plenty of small simple code examples in this segment that illustrate what is being taught as well as serving as a springboard for a little fiddling. They are all run in the irb REPL program. It’s quite nice to have such a light weight way to run some simple code. Visual Studio can be awesome, but it does take a while to get you to the code from a cold start.

After the usual discussions about how to do the basics the chapter leaves off with some exercises for the reader to perform. First of all these are just finding some useful sources of documentation on the intarwebs, including ranges. (‘aa’..’bb’).to_a is a very interesting thing to see in action :) After this there were a few exercises, starting off with the classic “Hello, world”, some basic looping, running code from a file rather than in the REPL and progressing through to a simple “guess the random number between 1 and 10 with a prompt to go higher or lower next go” game. I’m not sure that I’ll win any point for style, but these all came fairly simply. This last step of engaging us with some tasks based on, and stretching beyond, what has been given in the chapter works well for helping to solidify that learning.

This was a decent intro to the basics of the language and the approach of the book that has me looking forward to working through some more. For the record, and to open myself up to ridicule were anyone to bother with reading my little blog, the code I came up with for my guessing game was:

mynum = rand(10)
guess = -1
until guess == mynum
    puts "have a guess"
    guess = gets.to_i
    puts 'too low' if guess < mynum
    puts 'too high' if guess > mynum
end
puts 'woot'

I’m not sure what will happen if a non numeric character was entered, I don’t think Ruby is dynamic enough to come up with something that meaningful on its own ;)

Testing and Tooling, I’ve got it covered

We’re currently going through the process of trying to get unit tests around a large legacy code base at work, most of which has been written in a rather test-proof manner. This means that we need to introduce seams as we work through different sections, and obviously this sort of code change can create new and subtle bugs if any small errors are made in the refactoring. As we’re adding the tests as we go human error can mean that a method may be modified without the safety harness of tests to watch it. Having seen one such bug get onto our live webservers and cause a few issues when used in anger, it occurred to me that we ought to get some code coverage running so that we can tell exactly what code is tested, and see what we’ve missed.

I’ve dabbled with NCover in the past, but the open source version is getting a bit long in the tooth now, and I had no budget to jump straight in with the commercial version, so I found PartCover and after a bit of tweaking found that I could get useful metrics out of it, even if the interface currently feels rather clunky. At the high level, code coverage figures are a nice thing to know, but tell you very little about what is being tested, especially at this sort of stage of a project where we are at fractions of a percent. However, the ability to dig into different assemblies, classes, and even diving into the code in methods to see which lines had been executed suddenly gives us a great insight into what is going on. We can now see if there are any sections of the class that we are refactoring that aren’t covered by tests, and make sure that we rectify the situation before hitting the real world, like that implementation of IEquatable<T> that had tests for both equal and unequal objects, but not null. Oops.

Such tooling is less important in the modules that we’ve been able to code using TDD, but even there it is handy to see if we’ve been a bit over zealous with writing production code. We’re not ready to push code coverage into our CI system yet as the high level statistics would give management a bigger stick to beat us with over the low number of tests that we currently have. However, as we get more and more tests in there, then we shall end up with it in the automated build for the extra reassurance that it gives us.

 

On a slight tangent, I had a lovely experience whilst working on one of the new classes that I have been able to develop with TDD recently. I’d written a bunch of tests and the code to make them pass, and then went through the cycle again. All of a sudden my test runner lit up like a christmas tree. I’d made some simple schoolboy error, like a off by one, or using < instead of > or some such faux pas. Before I’d had a chance to think about anything else the system was already telling me I’d screwed up. It’s a nice warm and fuzzy feeling to know you have that kind of security in place :)

A Sink?

Yesterday evening saw Mads Torgersen and Lucian Wischik from the C# and VB teams respectively give a presentation to the London .net user group regarding the new Async functionality that has recently been released as a CTP addon to studio 2010. The guys are on tour, with the same core presentation that Anders gave at PDC, but in the context of the user group setting there was a lot more audience participation that pulled it in a different direction making it a useful follow-on.

One of the main messages that keeps cropping up in any discussion of the new feature is that it is not about spinning up new threads and making use of all those cores that we find in machines these days. It is about the orchestration of asynchronous tasks, allowing us developers to write code as if it were nice easy synchronous code, without all the callbacks for completion or failure. Creating methods that actually do work in parallel is a whole different matter.

As someone with only a few dribs and drabs of experience running code asynchronously, the demos I’ve seen so far are very compelling. The code is far far easy to write and understand using the new keywords, rather than manually prodding in all of the callbacks. Most of the emphasis has been on rich client code, whereas I spend most of my time in ASP.net at the moment, but the messages coming from MS are that we’ll be able to help servers to scale better by not blocking threads that are waiting for other services. Whether this is useful for relatively quick connections like hitting a big database server with a super high speed lan connection as opposed to slow things such as going out to web services across the internet will determine how useful this ends up being to me.

I’d like to quote a paragraph from Jon Skeet’s blog that seems to sum it all up well:

“It's important to note that it's not a free lunch, and doesn't try to be. It removes much of the error-prone mechanical drudgery of writing asynchronous code, but it doesn't attempt to magically parallelize everything you do. You still need to think about what makes sense to do asynchronously, and how to introduce parallelism where appropriate. That's a really good thing, in my view: it's about managing complexity rather than hiding it.”