devgrind

A while ago, Mike Clark wrote two blog postings on how to learn Ruby by writing tests (#1, #2). He explains that he wrote a test for each bit he learned about the language, over the years collecting a set of more than 200 tests which act as his personal knowledge base on the Ruby language:

Through trial and error they taught me how Ruby and its rich set of libraries really work. Not surprisingly, typing in code and running it makes you remember. Indeed, writing learning tests is a fun way to poke and prod any new language or API. And with every test you write you’re investing in an executable knowledge base.

Unfortunately I never tried this myself, but I like the idea. According to him, the benefit is twofold: The tests assist in acquiring and checking knowledge (by what he calls “asking Ruby”) and act as a knowledge base that manifests itself in code (and some documentation, where needed, I’d like to add).

Yet I am a little bit skeptical about “asking Ruby”. In his second posting, he suggests to “make a guess” in a particular case where he doesn’t know the result of a method invocation (“Rick”.index(’t')). Maybe I’m a bit hypersensitive here, but I have some reservations when it gets to using tests to find out how things (could or should) work. I’d think it would it be better to just look it up in a reference and write the test afterwards. The main reason is that using one test case (or a few) will give you one (or few) results, from which you will have to draw conclusions and generalize—the semantics of the index method in this case. What if your conclusions are wrong for some exceptional cases? Is it possible/feasible/desirable to write tests for each and every combination of parameters for a method? Why not trying a “read first” approach?

Nevertheless, the basic idea of using test cases for playing around with a language and collecting them as a reference is a nice idea. I’ll almost certainly try this the next time want to learn something about Ruby or a different language.

Filed by Arne at 2:57 pm under languages, learning, programming, ruby, testing
No Comments.

Today I stumbled upon another source of developer wisdom, Des Traynor’s Programming Theorems. One of the theorems rings especially true for me after the recent insights into developing a Sudoku solver the TDD way:

For every Architecture Astronaut out there, there is at least one coder who thinks that being “Agile” is a perfect substitute for foresight.

If you wonder what Architecture Astronauts are, its a term coined by Joel Spolsky with regard to people climbing up the abstraction ladder a little too far:

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all. These are the people I call Architecture Astronauts.

I know that I tend to be an Architecture Astronaut sometimes, probably it’s because thinking meta keeps me from the exhausting work of bothering with all the real-world problems. I wouldn’t be surprised if this was the main reason for developers to become Architecture Astronauts at all.

But Architectural Outer Space isn’t a place where I stay very long usually, because its my experience that the lack of oxygen disrupts any attempts of getting actually something done. And that’s where agility fits in: If I get the whole idea of agility right, it’s all about getting things done (unless you use it as an excuse to shutdown your brain).

Filed by Arne at 2:22 pm under agility, development
2 Comments.

There are few things in this world more soothing than the green bar of a project-embracing JUnit test suite after moving to a new platform.

Filed by Magnus at 11:04 am under development, geekery
No Comments.

Microsoft apparently hops on the dynamic languages train and releases IronRuby, a Ruby interpreter for the .NET platform which is also supported by Microsoft’s counterpart to Adobe Flash, the all new silvery Silverlight (which by the way also supports Python). I’m not exactly a fan of Microsoft, but I like the idea that web applets can now be written in Python and Ruby. How great would it be if these languages could once replace JavaScript on the client side as well. For now, I’ll stick with RJS templates for that purpose.

Filed by Arne at 6:23 pm under .net, python, ruby, web
No Comments.