Ketan's Musings

Only Valid Measure of Code Quality

Image from http://www.osnews.com/story/19266/WTFs_m

WTF implies lack of clarity. Clear code is easier to understand, easier to maintain and easier to extend.

Announcing saikuro_treemap — an easy to setup tool to generate complexity treemaps of ruby code.

See a demo for yourself.

Complexity Visualization of Rake

It is important to know who your users are when you are in the business of building anything. Building things is expensive. Software or otherwise.

My mom would rather use a mac over a gentoo. A systems admin would rather use redhat over a mac on a production machine.

It is also important to say “NO” to people who are not your users. Almost all software at eclipse.org are frameworks, tools and app servers written primarily for developers.

The way software and API is designed for the developer is different from how it’s developed for the non-developer (most of the times). SWTBot was originally and still is primarily a test-automation tool for use by QAs to automate test cases. The APIs are designed to be extremely intuitive, simple and easy to extend by QAs by merely looking at examples and not having to read API documentation.

Some context is in order if you haven’t had the opportunity to work closely with QAs before. Most QAs I’ve met understand customer requirements, understand the software and what the customers want out of it. I like to treat them as end users of the buggy software I build. They may not understand SWT threading, the eclipse ui and platform, OSGi and how TCP packets travel across the corporate firewall over to a load distributor in front of a cloud hosted at a datacenter on the other side of the continent. Try explaining a “org.eclipse.swt.SWTException: Invalid thread access” to a QA and you’ll get interesting looks.

QAs are good at finding bugs in whatever software they are testing. Testing all of the software is time consuming, not to mention testing backward compatibility with older software. Nobody likes clicking around the same navigation path in the UI all the time.

QAs like exploring interesting ways to use the software and ensure that it works consistently as software evolves over time. The traditional favorites have been the ‘heavy weight’ automation tools like HP’s QTP, IBM’s Rational Robot, Borland’s SilkTest and the open source ‘light weight’ tools like selenium, sahi, and a lot others.

Each of these tools has its advantages and disadvantages. One of the most powerful features of each of these toolchains is the ability to author scripts in a dynamic language. The commercial vendors use vbscript or some other variant of the language, and provide some forms of integration with defect tracking tools. The open source tools are primarily light weight, use the languages like javascript, ruby, python and don’t integrate much with anything but your IDE and things like ant or rake.

The end goal is to make SWTBot an extremely good, open source, light weight tool for QAs to automate tests, and be just about useful for developers to write simple test cases with and not something in between that neither of them like.

As part of evolving SWTBot APIs we need to ensure that we stay true to our goal. This sometimes means saying NO to feature requests and even patches from developers if it hurts the non-developers.

I’m always amazed and wowed by eclipse the platform, and more importantly the various communities that have formed around it.

I’m working on creating an open-source functional testing tool for testing SWT apps, I call it SWTBot (which is named after a similar project ABBOT.

SWTBot does work fairly well with most popular SWT controls, barring a few like DateTime (which have different implementation across platforms.) The ACID test for SWTBot would be if it is able to test eclipse itself. I was trying to click on some submenus in the eclipse. Since menu entries among other UI components are lazy loaded, it is very difficult or rather impossible to walk over all UI components, and I was quite stuck with this fundamental problem.

Not for long — Logging on to #eclipse, a few conversations later with Paul, the problem got solved.

Read more about using JRuby or Groovy to write eclipse plugins here: http://dev.eclipse.org/blogs/wayne/2007/07/26/making-eclipse-plug-ins-using-jruby-or-groovy/

Sidu has written a good post on why you ought to be attending the ThoughtWorks Master Class Series 2007.

Registrations for the Bangalore event have already come to a close down. We’re already sending invites for the Pune event. There’s still some invites left for the Pune event, and you can just about make it if you register quick.