Sunday, August 19, 2012

RESTClient 3.0 Preview Available for Download

Get the latest and greatest work-in-progress version of RESTClient: 3.0 preview release. This revision is a major revision with lots of internal design changes and rewrites. Functions present and functioning in 2.x series could also be broken. Request everyone's help in testing this revision.

Wednesday, August 15, 2012

RESTClient: 3.0 Development, move to GIT and code re-organization

The word 3.0 in relation to RESTClient brings horror to my memories. I started working on 3.0 couple of years back, implemented major changes, made the build unstable, and was not able to fix the working functionality of the previous versions. Then I had to do the inevitable: shelve the 3.0 release plan and start fixing the 2.x branch. And the development has continued in similar vein till now---that is until recently.

Now, I once again took the plunge: started working on the 3.0 release. The 3.0 release is major because:

  • Change the internal data-structure for holding request and response (to support binary formats)---this will break backward compatibility with the 2.x file formats.
  • The UI will have major code re-writes as it will need to support binary formats.
  • The public API will change.
Today I am happy to say that, I have successfully completed many of these changes as of now, and 3.0 preview release should be up for downloads within a week or two.

One of the best decisions I made recently for this 3.0 development is choosing Google Guice. Using the normal capability of Object Orientation provided by Java, it was increasingly difficult to wire UI components and develop maintainable code. Guice was some kind of nirvana in this sense: wiring components with participating APIs was made so much simpler. The choice of Guice and the API re-write made it easier for me to break monolithic classes into maintainable modules. This effort of mine will have long-term implications will provide quicker capability to change / add features.

One of the other changes is move to GIT from Subversion. Subversion was proving to be too restricting as a SCM tool. I was also acting as God---providing prospective committers commit rights. It was proving to be a hindrance---people cannot fork quickly and start developing. They had to wait for my permission before they can be productive. So, I believe, this move to GIT would prove to be extremely healthy for improving external participation.

So guys, as you are awaiting the next big version of RESTClient, I request all of you to actively participate in testing the preview release once it is made available!

Tuesday, August 14, 2012

RESTClient source moved to GIT

Today I moved RESTClient source code from SVN to GIT. This happened after a frustrating issue with SVN last night. Similar issue is discussed in this stackoverflow thread. The problem with centralised SCM software is this: when you are focusing deep in your code, a merge or update has the possibility of hijacking your focus from code to not so glamorous problems.