Meme Splicer

...plus a little bit of Eclipse at the end.

As you can guess by the title, this post jumps around a bit...

It all started yesterday, as I was reading JM's comment about using unit tests as documentation -- this was in response to ealden's post on whether we should be testing simple methods -- I was struck by how true this was when I was searching the Jakarta Commons Beanutils documentation on what classes/methods I could use to convert a Java bean to a Map of its properties.

I spent a lot of time doing google searches and found some discussion on copyProperties -- but this static method on PropertyUtils was only good for copying from a bean to another bean or a Map to a bean (quite the opposite of what I wanted.) I also found another static method called "describe" but the documentation didn't give me a clear idea as to what it did ...

I finally hit on using Google Code Search and the search pointed me to the static method "describe" that does exactly what I wanted -- and this information came from the unit tests on the describe method.

Which brings me to a conclusion:

In a world where we tend to write lots of code with very little documentation (beanutils had javadoc documentation, but it wasn't enough) , it may be that unit tests are the ONLY documentation we have describing our internal application APIs...

Which then reminded of a another post in Steve Yelvington's blog a few days ago about Vernor Vinge's (an author I really like) novel (A Deepness in the Sky, I think) and how in the future we will no longer have programmers writing code, but more like "Programmer archaeologists" who search through vast code libraries searching for existing code they can retrofit into a solution.

If I remember correctly, "Programmer-at-Arms" was a position on their starship staff for a programmer who searches for weapons systems which they then build on the fly...

Which brings me to my Eclipse plugins wishlist:

1. a plugin that allows me to right click on the error message that shows up on the console (or maybe even the Junit error message) and context menu will pop up and allow me to either:
   
   
   
   • go to the code that was the source of the error message
   
   
   • or, search google for the error message - this usually gives me a clue as to the cause.
   
   
   
   I usually do either one or the other anyway - having a plugin makes the task a lot more convenient.
   
   
2. A plugin that will allow me to do google code searches not just on web, but use the Google desktop to search through the code on my local hard drive as well. We spend a lot more time trying to understand code written by others... seeing how the code is used just makes our task of learning how to use APIs of all the libraries so much easier...

It's all these kinds of stuff (Open source, code search, eclipse plugins) being invented today that will really bring us closer to a future when we programmers will be doing less of reinventing the wheel and get focused on making the wheel do something useful -- like making the Internet useful for porn... but that's another topic for another day :D

I'm currently in the process of formulating a new Unit Testing and TDD course. This is a course which I have a hard time giving -- its the one course I teach where I've gotten consistently bad reviews :(.

One problem with teaching TDD is that its not like teaching the Java language where you can focus on teaching syntax (and have the compiler enforce the rules of the syntax). Its similar to teaching OO (Object orientation) because its also about teaching concepts.

Teaching TDD is also made much more difficult because you're also teaching a process (this is in contrast to just teaching how to write Junit tests -- although part of teaching TDD is just that -- teaching the mechanics of writing Junit tests) and trying to convince the participants to adopt the process.

The hardest part lies in that you're trying to change something very ingrained in a programmer -- the very way he or she writes code. Along with the initial difficulty of learning the tools (figuring out Junit and other unit testing libraries) and skills (how to write tests, refactoring, etc), it also means undoing habits that have long been part of the programmer's way of working.

In addition, the programmer might also be trying to figure out how to implement TDD in their ongoing project, and worrying about how it impacts their project plans and estimates, as well as puzzling over how to actually implement it with an existing code base that has no unit tests.

All of these things conspire to make teaching TDD very difficult.

Personal blog writing sure feels different from maintaining a news blog. It's like the difference between a reporter filing a report and a pundit writing a column -- its not just the content, but it's the content plus the author that's in focus.

I've always been interested in blogging and other kinds of social networking software -- I wrote an open source news blog application called Squishdot a long long time ago, back when the RSS format was still in the sub-1.0 version.

It was one of the many Slashdot clones produced around that time. It's been maintained for several years now by Chris Withers, and the code base is probably showing its age :(.

There was a time when both Gnome and KDE used Squishdot for their respective community news sites. Gnome has moved on to other stuff, while KDE continues to use it.

Okay. So.

I finally bit the bullet.

I started blogging.

Finally.

Now what?