indiWiz.com

Writing OpenSource code has been one of my priorities. I have been doing it for years now. This is the story of how it all began.

2003

Before joining in a tech job, many people told me how routine tech job is. People give requirements, and the techies translate it to working code. This was frightening to me! So I decided, I will do all the mundane programming work quickly using automated scripts. I developed a TextEditor for this purpose. It was completely scriptable using BeanShell. This probably is my first OpenSource application. The Java package name started with com.indiwiz.*. The application was shared to the world from my site indiWiz.com.

2005-6

I had a huge collection of porn, and I was sharing my computer with my family. The system had dual boot with both Windows and Linux. I wanted a cross-platform application which would enable me to encrypt and decrypt my precious downloads. During free moments in office, I started exploring encryption and security. This resulted in the WizCrypt project. I learned a great deal when writing this project. This is the only project I have worked on which involved file-format design. For this project I did not want to have the package name starting with com.indiwiz.*. I found the com to be misleading of the purpose. I wanted a package name starting with org. Luckily, I came up with the name WizTools.org, and more luckily, it was available for registration. I grabbed it. Since that date, all my OpenSource work has been branded under this label.

2007

At this time I was working in SpikeSource with an interesting team. I started RESTClient project for testing RESTful WebServices. This was developed in collaboration with Ravi Subramanian (we lost Ravi in a accident in 2008). His sudden demise was a shock to me. This is the most popular product from the WizTools.org stable. It has the maximum community inputs. To broadcast updates of the WizTools.org project, I anticipated a need for a dedicated blog. Thus was wiztools.blogspot.com born.

Present

This is the period during which huge amount of effort and time was spent by me to stabilize and popularize RESTClient. I also started the WizTools.org mini-projects. The mini-projects was created to host all simpler applications without involving the cost (in terms of time) of creating a new project and associated repositories and mailing lists. At the time of writing, the mini-project hosts around 14 released tools/components, and few other productivity tools like JEdit macros and bookmarklets. We also have started some interesting new projects like Java Portlets (reusable JSR-286 portlets) and The Great Wall (micro-blogging web-application) recently.

Now, looking back at the projects available at WizTools.org, I recollect beautiful stories of my own needs for these projects. And the efforts my collaborators and I put to bring them in place.

I was reading the book Beautiful Teams. There is an essay by Cory Doctorow titled The Copyfighters Take Mordor. In this essay Doctorow recounts how a set of sparsely-funded freedom-loving individuals fight the might of Corporate funded copyright groups from passing a new international law to curb freedom in the UN. If freedom-fighters had not succeeded, the present world would have been different. Even distribution and editing of Creative Common licensed media work would be controlled by the broadcaster (even if the author of the digital work gave permission otherwise). Thankfully the freedom-fighters won!

The hightlight of this fight is a tool. The tool is a collaborative text editor for the Mac called SubEthaEdit. During the boring and tedious meetings in the UN where the Corporates were selling their idea, our own set of free-individuals recorded the transcript, collaboratively-edited (using SubEthaEdit) and posted the information for the world to see in various blogs. This had caught the attention of the world, and now, the world is a better place.

SubEthaEdit interested me. I wanted to try it. Unfortunately, SubEthaEdit is available only for Mac. I was disappointed. Then I searched for OpenSource alternatives. This lead me to Gobby. Gobby is a GTK+ application which can run in Linux, Mac and Windows. For example, in Ubuntu I installed it thus:

$ sudo apt-get install gobby

Gobby is cool. Checkout some of the screenshots I took. Gobby could prove to be a powerful tool for code-review and collaborative document editing/review.

Fontmatrix is an excellent Font organizing Software available for Linux, Windows and MacOS.

To install it in all Debian based systems (including Ubuntu):

$ sudo apt-get install fontmatrix

Screenshot of Fontmatrix running in my system:

Post acquisition by Facebook, the software behind FriendFeed has been OpenSourced. Tornado is a Python WebServer/Framework. The distinguishing feature of this WebServer is that it is non-blocking and designed for high-scalability.

Facebook in the past has OpenSourced many of their frameworks and tools.

Version 2.2 of my favorite OpenSource virtualization software, VirtualBox is released. On reading the changelog, I found the new version supporting Open Virtualization Format. This is cool because, now it will be possible to share virtual appliances built with different tools.

JEdit is my favorite text editor. And today I was pleased to find some powerful scripting capability in its search and replace functionality. Basically I wanted to enclose a RegularExpression pattern with:

<a href="">PATTERN</a>

The Search and Replace dialog provided an option Return value of a BeanShell snippet. So whatever RegularExpression pattern grouping I provided, I was able to access them using the BeanShell variable _1 to _9. So my final replace statement became:

"<a href\"\">" + _1 + "</a>"

Cool solution to a simple problem.

I wanted very basic DI functionality for RESTClient. Just wanted a mock implementation to execute when doing a mvn test, and real implementation when executed otherwise. So the functionality was simple. My immediate requirement did not require constructor injection or setter injection. And all the beans instantiated had to be singletons. No other fancy requirement. So for this limited functionality, I was able to design a small framework in two classes: DIFramework.java and DIException.java. For mapping the implementation to the interface, it is managed using a simple property file with content:

org.wiztools.restclient.IGlobalOptions = org.wiztools.restclient.GlobalOptions

The mock implementation in the test execution would be:

org.wiztools.restclient.IGlobalOptions = org.wiztools.restclient.MockGlobalOptions

org.wiztools.restclient.IGlobalOptions is the interface, and org.wiztools.restclient.GlobalOptions and org.wiztools.restclient.MockGlobalOptions are the implementation. To get instance of implementation bean:

IGlobalOptions obj = DIFramework.getInstance(IGlobalOptions.class);

This would return two different beans in different execution environments based on the property control.

It is really surprising how fast it has come out of beta (compared to other Google products). View the official blog announcing it. For people using Windows XP and Vista (the only supported platforms of Google Chrome), the download is available here: http://www.google.com/chrome/.

My language of preference after Java, has a new release: 3.0. This is an interesting release as it breaks backwards compatibility. A conversion tool for 2.0 code migration to 3.0 is also made available by the community.