Well Oiled Machine

At work. Trying to get access to a system in the non-production environment, i.e. the various development and test environment. This, I thought, was a straight forward task. I was dead wrong.

Here's the chronology of events, assume the system is called Zion, similarly names are obfuscated to keep the assassins from coming after me:

1. Had training on Zion with the Oracle, he suggested best approach is to request for an inactive account in Production, then re-activate it in the Dev/Test environment once they are refreshed, this way our accounts survives a Production refresh.
2. Requested our Group Assistant to lodged a bulk request for our whole team, as suggested again by the Oracle
3. After a couple days, tracked down the request by our Group Assistant in an online system (what a tool! not in a good way...)
4. There is no status given, so I checked with Helpdesk. They say it is pending approval by Morpheus
5. Checked with Morpheus, he said he did not receive approval request
6. Checked with Helpdesk, they say the tool wont let them resend approval request, asked for email approval instead
7. Asked Morpheus to provide approval via email, cc'ed to Helpdesk
8. Morpheus forwarded to Trinity
9. Send email to Trinity to expedite this
10. Trinity called, stating that this is not the proper approach to request accounts, i.e. involving Production, asking what we are trying to do. Explained to her. She said she'll figure out a way to get us access.
11. After a few days later of no response, sent email to Trinity, cc'ed to Morpheus, stating we don't care for inactive Production access, we just need access to the Dev/Test environment that can be refreshed without losing our account to do our work!
12. Few days later, called her about this, she asked me to talk to Agent Smith to create these accounts.
13. Called Agent Smith, he says he's busy at the moment, fair enough, agreed i'll send him email. So I sent email
14. A day later, Agent Smith responded, cc'ed Trinity stating I should get the support team to handle this. Support team is headed by none other than Trinity. Start of infinite loop.

I should go write a book!

All this while, we didn't get to do our work since we dont have access to the system. The captain of the ship is of course Morpheus.

This folks, is a well oiled corporate machine, puts the nebuchanedzzar to shame!

Code Generation

Code generator, -noun : a tool used by management to regulate (read: reduce pay) or replace the software engineering intelligentsia with code monkies.

Seriously, that was what came to my mind when I first heard the term. In fact, I was right. It turns out the director of the company I was working for at that time, whom introduced the term to me, defined it exactly that way.

Fast forward a few years, I joined a Canadian/German outfit that just off-shored part of their dev team. It was a J2EE and Swing laden sweatshop in the tropics. At least it looked that way during the inquisition, or interview in some nomenclature, with all the J2EE and Swing interrogation. I was in for a big surprise. The first day at work, I was tasked to implement a simple search screen with a link to a dev guide and coding conventions. I was excited, getting down and dirty so quick and early has never happened to me before. I reminded myself to buy the lotto that day. Sadly, that thought didn’t last, as quickly as it faded, it was replaced by apprehension after I read the guide. I quickly did as the dev guide suggested, created my business interface, annotated it, created the implementation and filled out the business logic, run the ant task to build and deploy. Lo and behold, my EJB 2.1 SSB and the official confirmation of my officiation of the office of the code monkey.

Surprisingly though, I stayed and enjoyed working there longer than I first suspected, which was 1 day. The framework, allowed me to write business code without hassling with all the ejb 2 overhead, such as home and remote interface, xml configuration, etc. Plain old java beans became persistable entities (no, not ejb entity beans) as easily. All this was before Java 5, before EJB3. I was even developing swing interfaces without dealing with Swing code most of the time, it was a framework not unlike JSF, years before JSF. I only had to deal with Swing code when there were requirements to build some very non-standard UI behaviours, which is a testament as to why BAs/End users should never be given control over defining User Interfaces.

Interestingly, after my time there, code generation has been a very useful tool to me to solve problems as well as to improve development efficiency. We were using xdoclet back then to do compile time code geneartion, but with advent of annotaions and the mirror API in Java 5 and its standardization into the JDK in 6 and a number of byte code/runtime manipulation libraries nowadays, the potential for compile and runtime code generation is almost limitless.

During the JAOO knowledge sharing session a few weeks back, discussions about TDD came up. Someone remarked about how un-enforceable it is and its up to the developers discipline. That immediately reminded me of some POC annotations I wrote a while back when the mirror API was first made available in jdk 5, along with the processors, that generated skeleton unit tests. If I annotated my business interface or class, at compile time it would generate Test classes and test method for all the public methods in the business interface and class. Of course the test methods were generated to throw an exception with a “TODO” string in it, I still had to write the test code. If we wanted to enforce this, all we have to do is add a checkstyle like mechanism into the source check-in hooks to inspect the business classes/interfaces for that annotation. Obviously, this doesn’t guarantee that the test code is implemented or even correct/useful, but it is one step closer to TDD.

Basic UI requirements

Whenever a new framework is being discussed, or “pimped” as a colleague of mine describes it, all sorts of nergasmic hand waving takes place and a lot of geek saliva are wasted on how easy it is to do things compared to the older frameworks. Unfortunately, almost always, the basic requirements or standards of the actual users of the systems implemented by such frameworks are often lost in the geek moan-fest.

What I’d like to list down here, mostly for my reference, is some very basic requirements of features that are often very useful for end users of web applications, some of it can be adopted for non web based UI as well.

1. Idempotence : Users should be able to accidentally click on a button twice in succession or click on refresh after a button click without it causing a rise in global warming. Related to this, is also clicking on the back and forward button and actually going back and forward instead of getting gestapo signs popping up
2. Linkable or book-markable screens : Users should be able to bookmark screen so that they can return to it easily at a later date. This is especially useful if the screen requires half a day to get to.
3. Consistent theme : This is a bit subtle. One of Ben Shneiderman’s golden rules of interface design is Consistency. If users are using a single application that are made up of a number of systems which they have absolutely no idea of, they should not see a duck-crap green with menus on the side on one page and hello kitty pink with menus on the top the moment they navigate to another screen.

There it is, not a big list, but something to begin with. How these are used as criteria to determine the next shiny geek toy are as follows:

1. Can the new toy support those features out of the box, if not what add-ons/plug-ins or customization needs to be done
2. Once we know the new toy support those features, how easy is it to be used by the *coughcoughcodemonkiescoughcough* developers. Is it a one-liner or is it xml-hell, etc?
3. Now compare that to the old framework

Again not much, but something to start with.

Opening Day!

Wow never though I'd ever get my own blog going. But here it is. First post!