A Programmer Imperative

It is too easy to hype anything on the Internet. When I started career in this field I believed that information on web is very useful, but today as I see it, has become truly unreliable. These days, it's inevitable to assert the authenticity of any information. Viral marketing propaganda is common on internet as it is the easiest way to spread anything across globe, for many it is a "beautiful" business model to generate wealth.

I usually find people around me, ignorant of these hyped information, believing and expressing everything they find on web - which is mostly *not correct* or simply hyped up. It is easier to influence good number of people about "shared interest and biased views" which then drives a trend in community.

Take for example the hyped candidates: Web2.0, Agile, Ajax, Ruby etc. They are certainly not bad but are perceived in inexact ways (defeating the purpose);I find half of the people talking about these topics without understanding it or interpreting it to suit "their understanding". They are neither well read about it (articles are insufficient), nor do they understand it well.

Some people around me talk about agile methods and extreme programming, some try to criticize it ("Extreme Programming is one more excuse.."). Never in their life they've developed a software piece, even if they did, they did it in their own special and not so inspirational way, how can we give statement so allegedly? Some rolling stones perceive Web2.0 as sites with Dynamic Html effects with Ajax, they don't care why web2.0 and what exactly it is.

Fresh graduates are fallaciously evangelized to use specific technology/methodology, these masses are like blank slates, intemperately impressed by a good "English" speaker, They start believing without knowing the practical benefits and trade-offs of it. These hypes draw biased pictures in fresh brains which results in poor idea propagation, bad generation and software career scars.

It is always easy to observe a problem than to solve it. IMHO, The least we could do is to ask ourselves some basic questions like,

• Do we really understand what we are talking/expressing about?
• Do we need to be jack of all trades? should we learn every new stuff?
• Should we pass on or express anything we don't even understand completely?
• Can we question 'why' rather than following blindly?
• Can we not do good without convoluting the information?

Motivate, not manipulate, to lead.

Experiments with Continuous Integration

Ok, I've build yet another continuous integration tool. May be it's not as cool as CruiseControl or Continuum etc. but it serves the purpose very well.

We've a working set of around 1 million lines of Java code, scattered around 72 plug ins and features. It generally takes around 15 minutes to do a complete build and CVS fetch takes horrible half an hour, Ketan keeps reminding me to migrate from CVS to SVN and I should do that soon. All in all, It takes around forty minutes to export the BluePrint Foundry (BPF).

Manual build is too painful, which forced me to do something smarter. I'd initially setup a automated build with the help of:

• Eclipse PDE RCP Build script running as headless ant application.
• Few utility DOS Batch files (I know, it sucks) for fetching src, moving and rotating build files according to days.
• Windows Scheduler to run the nightly build.

It took two days of research to set it up and get it running successfully, it made life very easy until we started off with major refactoring to make BPF feature- based.

Some where in the dark corners of the "PDE build code" is the assumption to build features in alphabetical order(see bug for details), we've few features which have non-alphabetical dependencies. However it works perfectly in eclipse workbench because all(installed+workspace) the plug-ins are visible in the host platform, but not in headless PDE Build. I'm still struggling to make it work again.

In the mean time...

A quick look in to product export action tempted me to develop a plug-in which can export product in one shot, which can, then, very well can run as head-less eclipse application.

All it took was two hours of code browsing and extending the job and putting appropriate parameters in FeatureModel VO and executing that Job. Hmm.. it still required me to go on build machine and run that, with code in my hand i can configure very good scheduling framework to build. However, that would have been too much of time-investment at that point, rather i wrote one JMX Service which can be triggered from my workstation, cool and pretty easy.

Now, I've a build utility which can be remote triggered from any tool which understands JMX and can work with existing PDE builds. It will continue to make my life easier until the bug is fixed and I've a patch.