I ordered an Arduino Duemilanove a few months ago, and other than simply testing it to see that it starts up I haven’t touched it. It’s been lying on my desk, making me feel guilty every time I saw it.

Today, having a few spare hours and because I just finished reading “Programming Embedded Systems”, I decided it was time to finally do something with it.

I spent ~3 hours soldering the Proto-Shield that came with it. It was the first time I ever did any soldering and I think it turned out OK, after some help from Dad.

Then, I made a simple ‘Hello, World’ application that changes LEDs according to a button press. What can I say, the amount of satisfaction from such a simple thing is so big! Maybe, it has to do with the fact that as a software developer, I rarely do things that have a physical effect.

You should follow me on twitter here.

Soon, I will be leaving my workplace for the past 3.5+ years, and that has got me to do some retrospective. One thing I’ve been reflecting on is how good programmers seem to move towards better programming/working habits that are shown to them and how easy it can be sometimes to make a difference.

On August, I moved to a new team. At the time, the team consisted of 3 developers (including myself) and a team leader. Both other developers have joined the project about a year earlier than me, and have been working in the workplace about 2 years more. They are really talented folks, and I’ve learned quite a bit working with them. But when I joined the team, it was in a bit off a “stop”. The team didn’t have that feeling of self-propelling inertia.

I knew that they used to do scrum in order to manage tasks and work, but that had stopped for some reason, and in my first weeks there I noticed how task management was at fault – sending emails to one-another, with things getting lost between mail-clients and no real way to tell where we are currently standing.

After about 3 weeks in the team I showed the guys a few links of agile teams and their cool whiteboards, filled with tasks and burndown charts. They immediately liked it and said that “it does look cool”. A few days later I brought some stacks of post-it notes and we spent an hour deciding how to partition the board and a simple convention for the post-it notes and actually drawing it on a board with permanent markers. We used an ugly picture-frame (with the picture inside flipped, so the white side was facing the glass) to draw a burndown chart on.

It was an immediate success – every time someone walked in we all enjoyed explaining how the board works. Moving a task to done was usually followed by a bit of celebration and everyone could see what was going on easily. Now, 7 months later, we plan our sprints, have daily scrums and continue to get better at planning and being more agile.

What I’m trying to say is, I guess, that sometimes all it takes is just a little push in the right direction to start something good going on. It may take some balls or reading some Dale Carnegie, but it’s worth it!

I just uploaded the latest version of JUnitConverter (yeah, I’m no big on design), and thought it would be the right chance to talk about it here.

In the summer of 2007 we, at my workplace, decided to upgrade our (non-legacy) code-bases to use JUnit 4 as part of a move to make people more aware of tests and like writing tests more.

I did some of the organizing work beforehand and saw that most of the migration work is dumb – delete that line, add an annotation there, etc. Not wanting people to get the feeling the that “testing is a dumb, routine, thing” I set out to write something to make things easier and more automated.

After some googling, I stumbled upon TestNG’s junit converter which converts junit tests to TestNG tests. Needing a fast solution, I hacked on its code to make it convert junit 3 tests to junit 4 tests and was done with it. The tool was used in our effort and helped (although it wasn’t perfect).

During the year and half that have passed since, I’ve continued working on junit-converter as a pet project. Wanting it to be smarter, and reduce the amount of needed work even more, I came to the conclusion that the smartest thing to do would be to use some Java parsing library (instead of using Doclet). I came across many different options, most of which lacking in strength or very cumbersome. Eventually, I decided using Antlr would be the best choice.

I developed JUC in my spare time, enjoying the different things I wanted to try out (it was done almost fully TDD with very high coverage, and I was always fascinated with antlr). Lately, I thought I’m not doing it justice by not updating the site (a large part is because sourceforge is so not welcoming in the admin mode), so I spent the last few hours tidying things up and creating a new release and uploaded it.

I think it’s a good tool for anyone who wants to upgrade his tests, but also can be a good place to see how working with Antlr and Java can be done. Actually, it’s one of the most interesting projects I’ve had the chance to hack with in the last few years.

Congratulations JUnitConverter!

Soon another semester will start. And, like every semester, I received the list of assignments that are due, with their deadlines. Up till now I used to type into Google Calendar each deadline and set SMS reminders, to make sure I won’t forget to hand the assignment, but this time I realized I’ve had enough of this, and don’t feel like entering 30 different tasks over and over again, set the sms reminders etc.

So I figured ‘Google has an API for everything, why not automate it?’ So I opened their tutorial and started reading. Just about all the information was there, other then information on setting a reminder’s type (pop up, sms, email etc’).

I’ve read the python API code, and couldn’t find a reference for this. Googling for it I saw a few people mentioning it and saying the easiest solution is setting the default reminder type to SMS and then using the samples in the tutorial.

After looking a little harder I saw the JavaScript API let’s one set this type (in the API it’s ‘method’), so I ran a javascript test and sniffed it just to make sure it’s a simple attribute. After seeing that is the case I came to the conclusion that all that’s needed to set the ‘method’ of a reminder is this:

reminder = gdata.calendar.Reminder(minutes='40')
reminder._attributes['method'] = 'method'
reminder.method = 'sms'
event.when[0].reminder.append(reminder)

Those two bold lines do the trick, where method can be ‘all’, ‘sms’, ‘email’ and ‘alert’ (meaning a pop-up).

Happy SMSing!

You should follow me on twitter here.

Our team has recently received a brand new 50’ plasma display. After some brainstorming we’ve decided we want to display on it a live dashboard that will be used for all sorts of stuff – an information radiator about current projects, displaying online information from production systems, pulling snapshots from different web-cams in our organization etc. Basically, we wanted to make it look Hot!

We wrote down a lot of cool stuff that we would like to see there. One problem though – no one was going to let us spend a bunch of time working on it. So, we thought the best thing to do was to pull an all-nighter. This post summaries the preparation we have done in order to make it a successful one.

Step 1: Decide what you want to do

As I’ve already mentioned, we created a detailed lists of the different widgets we’d like to see on screen. We sketched the looks and the behaviour.

Step 2: POC

Because my team usually works on client-server systems and doesn’t do a lot of web programming and/or UI applications, we thought it would be best to do a Proof-of-Concept to everything that might prove to be harder to do than it seems.

Over the course of a week I wrote down simpler POCs that used the different APIs we wanted to use and that sort of stuff. I think that in general it took me less than 5 hours to create all of those.

Step 3: Organize your environment

A colleague and I created a simple installation of the required development environment in order to allow people to start coding as fast as possible.

Step 4: Spread the knowledge

At the beginning of the all-nighter I gave a 90 mins presentation of the technology involved. It was a simple walk-through of the basic kind of stuff that we were going to do. Later I sat down with each time and gave them a walk-through of the POC code that is relevant to their work.

Step 5: Divide

Before hand I sat down and divided all the work to tasks. Then I assigned pairs to the tasks keeping in mind that the pairing should be as good as possible (when you’ve got only one night you need to choose a pair that already works, as against to the usual where you can allow the pair some time to learn how to work together).

Step 6: Conquer!

Right after that we started coding like hell. I’ve set up a board full of Post-It notes of the different tasks at hand. The board was then divided into 3 parts: Backlog, In Progress and DONE. Moving a task to DONE was celebrated with a round of applause and everyone was able to see how we were doing by simply glancing at the board.

Step 7: Enjoy the result

At 6 AM we were finished. We had most of the dashboard ready and thought it was time to call it a night.

Some general tips:

• We collected some money and bought snacks and drinks for the whole night (not including the obligatory pizza, of course).
• A colleague and I were responsible for integration – we spent the night between the working couples, seeing how they were doing, sharing information and tips that were being learned and made sure that people integrated their code as soon as possible. This was a good thing as gradually during the night the plasma screen became closer and closer to the result.
• Make sure you’ve got good music.
• Force everyone to take some breaks. We chatted a lot and some people played cards.
• We set up a web cam that videoed the post-its board and the plasma display during the whole night. I haven’t had the chance to watch it yet, but I bet it’s going to be pretty cool watching it in fast-forward.

I hope your all-nighter will be as fun as ours was!

Recently, a new guy has joined my team and is in the process of taking over one of the systems that’s currently in my control. The guy, as most of the other people in my workplace, is the product of the organization’s own “Java School” (“WHY?”, you’re yelling to yourself? That has to do with the special properties of my workplace, which can’t really be disclosed).

Anyway, I’ve tried to write down the points I think a person must control before being able to really lead a project, and would really like feedback on these.

Here it is, the Software Project Learning Process:

• Understand the project’s version control and release management – be able to check it out and build it.

• Be able to sketch the flow of the system.

• Read the code of the main parts.

• Run the tests. If you’re out of luck – find out exactly which ones are known not to pass and why.

• Know how to deploy and run the project (especially relevant in legacy systems that are not changed often).

• Meet your clients. If your project connects with others’ (you receive input from Steve’s system, say), meet them too.

• Know your project’s different input and output mediums (protocols with other systems, input file formats, etc).

• Understand other resources in your project (special files used, the database scheme, etc).

• Be able to tweak your project using its different configuration options.

These are obviously not ordered by importance, as that varies between projects. I have found this list helpful in the last couple of years whenever I’ve had to get someone new up and running with one of our systems.

Cheers!

Recently I started the process of handing one of my projects to a new programmer. The guy’s OK and has talent, but is very inexperienced and hasn’t had a chance to write real, production-quality code.

My general approach is usually talking about the purpose of the project, then architecture. Afterwards I talk about the purposes of the main parts in the design and then leave the guy to do a bit of digging.

Now, the time has come for the part that does really makes you understand what’s going on. I’ve given him a relatively small piece of work. How small? I guess it requires writing 4 new classes (2 plain objects and 2 real ones) that would take about 200 lines of code and modifying about 3 classes that already exist.

The guy started working on his solution when he asked me something to the lines of “which value should I return here? This one or that?” He was working with one of our tool-kit’s interfaces that I saw no reason for him to use. “Why are you using it?”, I asked. “Uhhh… Hmmm…”. Ding! A warning sign had popped in my head.

After a little questioning I found out that he searched for places in the code that were doing something similar and used that code too. He thought I was going to give him the usual “don’t copy and paste code” talk and said “Yeah, I know, code reuse! I’ll refactor it so I won’t need to copy it!” The problem was waaay beyond that.

The real problem is you should know what every line of your code does. That’s it. The interface he was using was totally irrelevant to the problem at hand, but because he saw it used he implemented it too. At first he didn’t get why it’s such a big deal. Only about 3 lines of code. I had to sit down with him and explain how hard it would be for someone else (or even himself a while from now) to try and understand and change that code. I’ve had the chance of seeing lines of code and asking myself “What the heck is this for?” That’s the worst thing that can happen to you. You now have voodoo code – can you delete it? Can you change it? Heck knows, especially if the test suite isn’t solid enough. And besides, a good programmer should be in control of what he’s doing and repeatedly ask himself “why?”. Why am I doing this? Why is this feature needed? Why am I catching this exception? Why why why. I think that’s probably the best way to leave great code behind.

So, that’s my point. Write what you understand, know what your code does.

Oh, and especially in cases like these – code review! See? Those are 2 lessons for the price of one.

I’ve been working on a pet project of mine, junit-converter, recently. It’s intended to help people migrate from JUnit 3 to JUnit 4, by adding required annotations and such, but it’s far from perfect. junit-converter is based on TestNG’s converter that uses Java’s Doclet.

For those who aren’t familiar with it, Doclet is something that allows you to process annotations added to javadoc comments and things like that, and it has some code-parsing capabilities that are being used in the TestNG converter.

Now, almost a year after publishing the first junit-converter version that’s based on the Doclet processing I’ve come to the decision that there has to be a better way for doing this. I’ve considered many options that I will write about some other time, but have finally come to the result that Antlr seems like the best candidate out there.

I’ve been using it for a few weeks now and had some difficulties getting it to work pragmatically with eclipse. The main problem with antlr (and anything else that generates code automatically) is that eclipse isn’t aware of the changes and because of that doesn’t compile the right files etc’. At the beginning I used to manually run the antlr compiler after every change I’ve made to the grammar and then refresh the files that were generated in eclipse. This of course was really annoying.

Later, I created an ANT build.xml file that parses the grammar only when needed and ran it manually, which was a bit simpler, but still no winner there.

Then, at last, I came up with the most comfortable configuration so far. I’ve added to my project another builder (under build preferences), an ant builder. It used my build.xml file and I configured eclipse to build using it every time I save (just like it does with its builtin compiler). After making a few tweaks so it won’t compile unless needed it was pretty fast and not annoying (considering the grammar isn’t where the majority of the changes are anyway).

So, just in case someone else wants an already ready build.xml file for this purpose I’m attaching mine. Notice that I’m running antlr using the ant execute task as the built-in task in ant doesn’t support antlr 3 and I didn’t want to add another dependency to my code for the published task on antlr’s site.

I hope this helps someone, and if anyone has a better way of doing this I’d like to hear about it!

Today I needed to make a few modification to one of our older Java applications. So, first thing’s first – I checked out the latest copy and ran the test suite. Surprisingly enough all the tests passed. But, something wasn’t right. I caught the glimpse of a stack trace flipping by in Eclipse’s console window. Scrolling up to it I found out an AssertionError was thrown. How come the tests passed?

A little digging revealed this (simplified) test case:

Can you spot the bug? The assertion fails, but in another thread. The test is testing an asynchronous module’s response. JUnit’s test executer isn’t aware of threads other than its own, so it thinks everything is OK. For the sake of the original developers I’ll mention the fact that they were using a home-built test runner that set ThreadGroups in order to catch those exceptions, but nowadays everyone use Eclipse’s JUnit plugin in my work place and that logic is no more.

So, what can we do? I first considered passing a boolean between the two threads so that the test’s thread would fail() if the other thread indicated failure. The problem is that the original error is either lost or hard to show.

After some thinking (and because I’m currently reading the great Concurrent Programming in Java book) I came up with this simple solution using the JDK Exchanger class:

So, what’s so better about this more complicated version? Well, first of all, it works. We use the exchanger to pass the exception to the testing thread. Another nice benefit is the fact we’re throwing the original exception – meaning that Eclipse’s plugin shows the right stack trace and clicking it gets you to the actual line that failed and not a simple fail() as opposed to the option I mentioned before.

Do you know of a better way to do this? I’m trying to think whether something can be added to JUnit for this purpose. Anyway, this results in a cool test that works great with the different plugins.

Happy testing!

I’ve always loved books. I remember the vacation between 5th and 6th grades, my mother took me to the local library to get a subscription. I used to read 3 books a day during that vacation.

Later on, I still loved books, and used that to learn a lot about things I was interested in. As a mostly self taught coder, reading was the major way of learning new things.

Nowadays I keep reading as one of my most important hobbies. I read both technical books and “regular” books. My friends find it amusing to see me switching between Harry Potter and the Pragmatic Programmers.

For the past 2 years I’ve been keeping a king of book log. It started as a to read page on my laptop’s wiki since I always had so many to remember I want to read. Every book I finished I crossed from the list, sometimes even giving it a small review. Now, more than 2 years after starting this I did a little count of the numbers of book I’ve read.

Turns out my average is 2 books a month – one technical and one “regular”. That means over 50 books since I started that log. And you can be sure that’s the number one habit in helping me “up to it” in my industry. I’ve recently finished reading Chad Fowler’s “My Job Went to India” which made me realize that this is one of the major edges I have that differentiate me from your average Joe Programmer.

I can hear you saying “So he reads! Big deal!” Well, it is a big deal! I usually drop by my work place’s library every two days for a quick look – see if anything interesting pops up. This, overall, gives you an edge for a few reasons.

First of all, simply looking at your library is helpful. There is a great number of books I haven’t read there, but I know by title most of them, so whenever someone asks a question I don’t know the answer to I usually know where to point them (and, of course, that works for my own problems as well). Furthermore, every book you read usually mentions quite a lot more, and, like Google’s Page Rank, once I see a book referenced a few times I know it’s probably a good read and add it to my to-read list. See, good book-writers do social-networking in their books apparently and happen to appreciate other good book-writers.

Another advantage to reading, which is quite obvious, is that every book you read makes you smarter. Whenever I have to work with some new technology I try to get my hands on The Book for it (every topic has one, like Rubi’s PickAxe, C’s K&R, the Gang of Four’s Design Patterns book and so on). That of course makes me comfortable with the technology. But my work doesn’t require me to learn a new technology every month. What do I read in those oh so boring months? Well, usually, a random interesting-looking book from the library. Yes, even if it is about a technology no one uses in my workplace any more or about something that has absolutely nothing to do with your work that you wonder how it got to the library in the first place. Because, as I said earlier – every book you read makes you smarter. Reading books on other programming languages gives you another angle from which to look at your current favorite. About a year ago I read a book about steganography (hiding information inside other information. Take for example all those songs you play backwards to hear hidden messages). Why did I read it? I really don’t know. But a few months later it helped me quite a lot when I needed some background with error-correction algorithms which, prior to reading that book, I had none. If I haven’t read it, I wouldn’t even know I was in need of error-correction. That is one lucky coincidence, isn’t it? Well, it isn’t.

And, a final nice side effect of reading books is that it makes you a better writer. It’s like working with a guru, some of it is bound to stick to you (I hope my writing skills here don’t offend any of my favorite writers, eh?).

So try it. Keep a to-read list. Read a book a month. I bet you will see it pays of quite quickly.

Have a nice weekend,

Aviv.