Taken from the SharpDevelop project‘s Architecture Documents:

((Almost (all)) ((mid (size)) to (large (size)) (software projects)) have ((some (sort)) of (add-in architecture)). An (add-in) is basically (an (extension to the (functionality of the (main application)))). The (common way to (introduce (an add-in structure)) is to (load (libraries from (a specific directory)) at (runtime)).

I‘m trying to see if I can…hmm…write some code maybe ?

Update: Have something you can read here...with some 1:31 a.m. type Ruby code :-) Rohith struck a chord on some of the stuff and the conversation is there too.

Worth trying it out ?

This is something that I‘d planned to blog about when I was in India; unfortunately, running around to round up documents for entry into Canada seems to have endowed me with amnesia.

The idea arose after JD and I discussed how cool the gloves in the movie Minority Report were. Of course, there are CyberGloves which are currently in the market, but they are way too expensive to be as ubiquitous as, say, a keyboard or a mouse.

We intially conceived of actually tracking fingers, but that sounded slightly harder. The first demo required only a few components:

• An inexpensive laser pointer (those red ones only cost around Rs. 75)
• A cheapo webcam (though as you‘ll read, better is better)
• A JDK of some sort (no preferences, just happened to have IDEA open at said time)

We rigged up the setup so that the webcam observed the screen. We moved the laser pointer around the screen, while the Java code monitoring the webcam tracked the laser pointer and moved the mouse along with it.

And man! It worked like a charm! So basically, we could stand 10 feet away from the screen and move around the mouse. Yay!

Question was: why would someone want to manipulate a mouse from 10 feet away?
Very few people‘d want to.

Interesting thought #2: Ever been in those presentations where the presenter is that faceless voice to a lot of people because he is clicking buttons and stuff at his machine? Well, what if he didn‘t have to click those buttons using his mouse. What if he were manipulating the presentation woth his laser pointer?

Sooner said than done. We hijacked the TWI conference room for an hour or so, and got it working in 15 minutes or so. Worked amazingly! Even wrote some simple code to be able to click on a button if the laser pointer was held at a point for more than x seconds.

The only problems faced were the fact that the image from the webcam was not properly calibrated, and there were inaccuracies at times. I‘d imagine that to be fixed using any of those semi-automatic calibration algorithms I read up in college.

Unfortunately, project work (on JD‘s part) and stuff on my side ended that effort. But it did jump back at me yesterday night. Might as well do it this weekend. And this time, I even have gloves! :-D

This last week has been stressful, frustrating: maybe it has to do with the accumulation of the result of the last few weeks, or maybe it has to do with this being my first client-side engagement. Until a month back, it was engagement with some delivery thrown in. And I see the results of this ‘enablement‘ and nothing has changed. Oh no, don‘t get me wrong.

1) There is pairing.
2) There are standups.
3) Work is done in terms of stories.

and etcetera.

But now that I look at it, these are just surface effects. It is almost as if XP were being followed in the letter, not the spirit. And I wonder how it could be done better. And one overwhelming thought looms.

I think it is the way we approach enablement. We start with a few practices and extrapolate that any of the nonbelievers will ease into those practices over time. We expect that the client team will mould XP to its particular requirements when we start off.

I think that both of those expectations are false.

Nonbelievers will not believe. It is simple as that. OK, there are a lot of grey areas, but say I believed in God, and someone tried to convince me through experiments that my belief is false…would I change? To change a belief requires something dramatic to happen. Only then can one change. It will not be demonstrable to him by showing the incremental betterment of the code.

The client team will mould XP to fit its requirements – only if it has practised XP (as is) previously and has perceived its limitations. Asking them to do this at the very beginning is like asking them to bend waterfall to match XP…bizarre as that sounds.

Easing into XP practices is not an option. What the hell do you mean by ‘easing into pairing‘ or ‘easing into writing‘ tests? It hasn‘t happened here, and my limited observations say that it‘s not possible. Easing into pairing is another term for postponing pairing. In this case.

Is it not possible to have some kind of understanding with the client so that in the beginning, they do exactly what is suggested. That might sound too harsh and maybe dictatorial, but the point is not to demonstrate superiority. I would call it hand-holding; the only way for them to realise and mould the process is to experience the bookish way it is done.

Once they are through the first phase of this rigid adherence, it will be easy to loosen up, and start putting in modifications and customisations. This might work better than keeping it loose from the beginning itself and then having to go through the pain of repeated discussion of how to convert a non-pairing developer throughout the lifecycle of the project.

Conversely, this also might mean that:

1) I suck at convincing people or understanding human nature.
2) Such an agreement may never be reached.
3) Maybe it‘s not done that way: business ethics or something (I don‘t even know what I mean by that)

Unfortunately, this situation is very real, and very painful. And it leaves me exhausted at the end of the week.

Incremental changes to FitWriter. Conveniences basically. I had lots more to say but I can‘t find the paper I wrote down the stuff I wanted to blog about. Where the blazes…?

Gitanjali tried using FitWriter and immediately got an exception. Forgotten to package a DLL. It‘s still in the same location. Sorry :-)

It is a pretty gloomy afternoon right now, and the light has begun to fade again. What better weather than this to write small throwaway code :-D

We recently got to writing new FIT tests on the project owing to a large piece of work that could best be driven through FIT tests. We are using FitNesse.

As usual, my pair and I chafed under the gruelling test-writing session, all the while hoping that we hadn‘t misplaced a pipe (which we did lots of times). We needed a better editor.

I wrote one this afternoon. It‘s rather grandly called FitWriter. Simple and uncomplicated for now. But it should be enough to ward off the raw test-writing ghosts on the project.

It‘s here.

A screenshot: