Coding by the Beach

OK, not 100% replication, but pretty close! http://reprap.org

Posted by Wordmobi

One mistake that I keep encountering over the years in my profession is the underestimation of work required for a work item (which can be a feature, a user story, a bug fix, defect fix, or whatever name you can put).

Any programming work item can be coded fairly quickly, but to know whether it is correct, one MUST test it (and this is not a tester’s job). I regard committing an untested code is a serious crime in the software engineering world. Yet I see it happen way too often.

If you are one of those people, please stop doing it. You are making your teammates sleep less, and you are ultimately responsible for making the world a worse place to live in. Test your code, man.

Posted by Wordmobi

Ok, I guess the WordMobi doesn’t really do much good when publishing pictures. But at least for ordinary thoughts it’s ok.

Anyway, just a note to myself: don’t over-engineer code with patterns. Make it easy to read.

Posted by Wordmobi

Some fancy drink that I get to drink everyday. It’s bitter but somewhat tasty after you get acquired to its taste. Somewhat the same story with beer.

Posted by Wordmobi

So today Steve Jobs announced the iPad, after more than a year of successfully making the public speculate and generate free publicity.

This will also mark my coming back to this blog, after almost a year of complete abandonment.

Where have I been all this time? Well, nowhere. I just haven’t had the will to write. Mental block, some people call it. Not that I have not learnt anything new anyway, but the last few months of work has been primarily requirements gathering and analysis.

The kind of work associated with requirements gathering is tougher than coding, by a lot. I now have even greater respect for those people who call themselves ‘business analysts’. Well, all I have done was just organizing documents from the client (whom until now has been looking for a better way to manage information other than email – the team suggested a change but was unable to convince the management), but the real challenge is how to organize these documents so they do not flood my team (myself included) with emails, and at the same time, decrease confusion (wordy and inconsistent requirements documents are coders’ public enemy #1, not to mention confusing terminologies, often with multiple meanings).

Well, wiki comes to the rescue! The team, after looking at the millions of alternatives, chose XWiki. Although it has been developed since 2003, same year that MediaWiki (most popular wiki software, partly due to the ubiquity of Wikipedia) was also developed, it has more built-in organization features (like the notion of ‘wiki space’). Its weakness is relative unavailability of plugins and extensions (about 40 applications (some not updated and not working on the latest version), and 40 plugins(similar status)) compared to MediaWiki (thousands of extensions). When a client requested a feature to globally edit article sections, I could not find such plugin already developed (although there are ways to work around it, they all amounted to about similar number of clicks and about the same level of obscurity as if using the traditional Microsoft Word and PDF documents).

Anyway, time to go to work.

I’ve been asking myself this question since I officially became a part of the computer industry… is creating a compatibility layer worth the time?

Before that, perhaps I should explain what a “compatibility layer” is. It is a separate project that sits between a 3rd party library and the project(s) that are our actual client project. Its primary function is to provide stability for the client project, so whenever there is a new 3rd party library that we want to use, we will already have standardized API and can simply extend or replace existing classes in the compatibility layer.

Of course, it costs considerable manpower to create such a compatibility layer. It will take a lot more hours to create such a project than if it were implemented directly on a 3rd party library. Not to mention:

• If we model the compatibility layer according to one library (or even create our own class models), another library may not be using exactly the same paradigms and constructs, so whenever time comes to replace one particular library, it will also become a tough challenge.
• The software that we write will require more resources to run, because of this additional layer that doesn’t actually do any real work.

A couple of years back, the team chose not to create such a layer. We paid a hefty price; when there was a decision to “tone down” our application from 3-dimensional to 2-dimensional, our first reaction was … “WTF?!?!” because that would mean restarting nearly from scratch, with a new library.

So now I’m back with the question. I am currently struggling to juggle between the 3rd party modules for Google Web Toolkit (GWT):

• GXT (a.k.a. Ext-GWT, ExtJS’s own GWT add-on; our current standard, but we want to replace it because it recently adopted a viral license – not good for commercial projects)
• GWT-Ext (a free (LGPL) 3rd party to the Ext library – but itself controversially depends on the last version of Ext library that was still non-viral (and had ambiguous licensing terms), and is no longer maintained by its author)
• SmartGWT (an emerging next-generation library for GWT; better back-end structure (based on the more mature SmartClient, compared to the younger ExtJS), a more liberal license (LGPL), but unfortunately still in beta and its features are rather limited)

So is it worth the time to create such a layer? I’m still too much a newbie in the area of computer industry to answer this question unambiguously. What do you think?

Technorati : library
Del.icio.us : library
Zooomr : library
Flickr : library

These days, I tend to shy away from writing verbose documentation with no breaks. I do that on purpose.

Having worked as a technical writer for a year, I know that the most complete document is not quite the answer in most situations. Even with the most complete document, people who read the document will still come to me to ask where things were. (And it does help a lot in the requirements process, where we are gathering data that will become the goals and constraints of the software project).

People are somewhat dumb by design. They will not look into things if they don’t have to. They would rather complain behind the writer’s back, too, than telling the writer that his document is incomplete (or complete but somewhat disorganized). They only like reading novels or magazine articles for entertainment. Reading 100-page documents is just out of style (or in their formal word, “work-like”).

I thought, hmmm… it doesn’t have to be this way.

These days I tend to choose pictures. A storyboard like this can definitely convey more than a thousand words worth of explanation:

Another way to chart ideas is by utilizing mind-maps. Here’s what it looks like:

From Wikimedia

What do you think? Is written document out of style? Is there a better way to document thoughts and processes, than verbose document writing?

As I venture into the deeper depths of the GWT/GWT-Ext and AJAX RIA game, I discover a lot of intricacies and eccentricities surrounding its existence.

I learnt that the base library of GWT-Ext, the renowned ExtJS, has undergone a recent license change (towards becoming a more commercial product) and infuriated many in the open-source community.

I also started learning a few tricks to speed up the otherwise very slow compilation process… I’m hoping these tips can be of good use to others:

Compiling GWT Takes a Long Time, so script away…

Because compiling a GWT project takes a ridiculous amount of time, we should try to make use of its XML facilities. We can make use of the GWT-Ext’s TreeLoader / XMLTreeLoader and GWT’s own XMLParser, and load data (or even a tree structure) dynamically. If you ever need to update the menu, all you have to do is change the configuration XML, instead of recompiling the whole mess of HTML + CSS + JS produced by GWT.

Create Your Own Event Objects

GWT-Ext relies on injected event objects to function properly, especially in those pages which require custom grids capable of adding or deleting rows and displaying different grid layouts dynamically, depending on the data received. Create your own classes of events and reuse them!

-

I suppose tips are never complete without sample code. I haven’t had time for that. Next post will hopefully come with sample codes.

Technorati : principles of good engineering, programming attitude
Del.icio.us : principles of good engineering, programming attitude
Zooomr : principles of good engineering, programming attitude
Flickr : principles of good engineering, programming attitude

Have you tried building an application with GWT? Sick and tired of waiting for those ‘Refresh’ cycles that seem to take forever (even though you probably only changed the length of one text field)? So were we…

This is the initial construction of the GUI builder that we are developing. The other part can be seen at my friend’s blog: http://luvj.wordpress.com/2009/02/18/gwt-ui-designer/

Initially, support will be limited to a very small subset of these widget libraries:

• Native GWT
• GWT-Ext
• SmartGWT
• Ext GWT a.k.a. GXT a.k.a. MyGWT

We will integrate these at some point this week… stay tuned…

Technorati : GWT, RAD
Del.icio.us : GWT, RAD
Zooomr : GWT, RAD
Flickr : GWT, RAD