I had an ulterior motive as well for not wanting a new phone. I was waiting for multiple devices to converge and converge successfully into one device that would combine the power of a digital camera, a GPS and a phone, besides the other odds and ends. It seemed that the Nokia N95 was finally the answer. It promised all of that and more.

So I went ahead and bought it. Yes, it hurt my hip pocket a little. But hey, I am allowed to treat myself now and then!

The phone - works great! The camera - fantastic. 5 MP captures all my blemishes in great detail. The GPS - Morbidly unjustified piece of crap.

Yes, strong words. Strong words indeed. It's my frustration with using the GPS that has made me so disgruntled and annoyed with the powers that be at Nokia. What could have been the Pièce de résistance of this phone is a blemish of the highest order.

Ok, the GPS part of the application works fine (or used to work fine, as you will see later). So if I want to see what my current latitude and longitude is, the phone will tell me pronto (after locking onto satellites). But Nokia, why would any normal phone buyer want to just know their latitude and longitude? The killer application part of the GPS module would have been navigation with voice guidance. So can I do that with your phone? Maybe. More importantly, can I do that out of the box? NO!

Out of the box, the Nokia navigation is totally useless. It takes the skills of a hacker and internet trawler to know how to install navigation with voice guidance into your phone.

So here is my question. Why has Nokia missed the boat here? Why did they supply the basics and not make it a complete package by making the GPS a truly usable function. If I, with some computer skills, had so much trouble, I can't ever see a normal person bothering with using the GPS. Ergo, I can't see a normal person buying the phone because it contains GPS. Why would you when you have other phones that match it in its capabilities? Why wouldn't you just buy a dedicated navigation unit, that works out of the box?

It's a travesty of usability. The navigation should have worked out of the box. I shouldn't have to second guess the device. Don't make me think. Otherwise, take the GPS out. It's not selling your phone.

And this makes me criticize the general phone manufacturing industry on the whole. So blinded are they by the pursuit of easy money, that they forget to do the basics right. Yes, by purchasing voice navigation the phone manufacturer got me to shell out money for a value added service (on top of an exorbitantly priced phone), but they would have had better marketing karma if the only usable component of GPS (navigation) just worked. Instead, I now have a phone that does the same thing as my $800 cheaper old phone did. I know I am the sucker here, and that makes me mad.

PS 1: Once I did get the MAPS application to work, it worked well for all of half hour! After that, the application just plainly refused to load. Now I can't even get my latitude and longitude. Sigh! Can anyone help?

PS 2: Don't get me started on the manual that comes with the phone. So out of date it is with what's actually on the phone, that I threw it out after my first attempt at getting the navigation to work. Menus are not where they should be as per the manual, there is no knowledge of what's actually on the device and the whole thing feels like an afterthought. Why bother with a manual Nokia?

PS 3: There is something to be said about the purchasing module for the navigation part. It worked so smoothly, that it was the only redeeming feature of the whole process, even though I was disgruntled at having to pay for it. But that was the ONLY part that worked well. Yes, Nokia, make the part that takes my money well. The rest can take care of itself right?

His take home pay was only 10% less than my take home pay. In actual dollar terms. So, for example, if my pay was $50000, he was getting $45000 in Indian Rupees. That means, if you factor in the actual living costs, he was earning more than I was by a magnitude of at least 25 to 30% for same programming roles and equivalent experience. (And his is not an isolated example).

Various feelings and thoughts went through my head, many of them unprintable (Yes, I was green with envy, but he is a friend, so I gotta be happy for him :) ). After a couple of hours, when logical thought process returned, I thought about how the cost of rising wages was likely to impact the whole process of outsourcing.

I contacted a friend of mine in the IT department of a banking giant in Sydney to get his perspective. After a bit of cajoling, he revealed that a recent outsourcing round had saved them nearly 25% of their total IT budget.

Of course, this is speculative saving. The actual savings won't be realized till the project has finished (2 or 3 years). In which time, the actual savings would be in the ballpark of 15% (increased costs, infrastructural issues, missed requirement, inflation .. whatever).

Now, 15% of $10 million (a not so inaccurate value) is still $1.5 million. No small change and any CEO/CIO would be happy to show that as his/her legacy (especially if it ends up as a bonus for him/her :)). But to save $1.5 million over 2-3 years and have your whole business processing outsourced seems excessive. Or does it?

I know there are no correct answers here and this example is too simple to attempt a values based judgment. I am scratching my head as I am writing this in trying to find a logical explanation for this. How is outsourcing still financially viable? Or how can it continue to be viable for both the Indian outsourcing industry and the Western IT departments? Any answers from both sides are most welcome!

The timing is absolutely wrong and the aim seems foggy. Sun has just open sourced Java ME, so why develop a conflicting product, even under the ambit of Apache? The stated aim is to reduce device fragmentation. Ha! By developing a different base API to Sun's Java ME? How will that work? Not only will developers have to content with the established device fragmentation issues, this will introduce another layer of complexity and API fragmentation. Have you tested on Sun's Java ME based devices? Have you tested on Apache Java ME based devices?

The truth seems to be a marketing push to garner respectability within the Java ME development community to push Motorola and create a Motorola-centric development ecosystem.

"Although we are not aware of Sun's open-source plans, we would hope Sun would join in this effort," said Mark VandenBrink, a senior director and chief platform architect in Motorola Mobile Devices business.

Huh? Who, within the community, is not aware of Sun's open-source plans?

Ok, so it's just a few lines of code that are, to put it mildly, exceeding the generally accepted 80 character limit. The fact that there is no explanation of what this class actually does in the Javadoc comments is to be expecting too much. Hey, it's the 'Main CityGuide MIDlet'. What more explanation do you want?

So, I decided to investigate further. At random, I picked another code example, the BallCanvas class in AudioDemo. Just a small snippet from this:

The formatting is all over the place, the commenting is, as you can see in the highlighted section, verbose (Destroy for the method called destroy()!).

OK, so these are just two examples, but when you look at the rest of the code examples, two things stick out.

1. Code comments were not a priority of the engineers writing the code samples for Java ME. There is no consistency.

2. Code formatting is all over the place. There is no adherence to any established guidelines or any semblance of quality control.

Why does Sun think it is ok that these code samples be released without mandating that a due QC be applied to them? Is this the same for examples of Java EE and Java SE? I know these are just code samples and Sun is doing us a favor by releasing them, but it shouldn't take me the better part of a day trying to gloss over badly formatted and incompletely commented code for a technology that Sun is trying to sell.

When you are trying to learn a new facet of Java ME technology based on these code samples, it would help if you have spent your years doing code reviews for undergraduates.

The sudden onset of the 1:55 local going from Roma Street to Ipswich woke me up from my day dream. The train was coming in to stop at the Milton station. I looked up at the gentle blur of a fast moving train and between the cracks of the bogie's, I could just about see the outline of the Milton brewery and the smiling Fourex man with the very inviting beer in his hand.

For the 10th time in as many minutes, I wondered what I was doing here. Sitting in a car park, early for an interview, I was trying to pass the time by convincing myself that this was a good thing. The palpitations in my heart were making coherent thought impossible. What seemed like a good idea a week before, now seemed like a monumental blunder.

I was 'here' to be interviewed for the position of a J2EE developer. While that in itself is enough to send shudders down my spine, the fact that I was going to be interviewed for a J2EE developer after working for more than 2 years on ASP.NET was making me hyperventilate. I am not good with interviews. Perhaps it has something to do with the disaster I had some time back with this. Since that event in my life, I have failed 4 interviews, including the one that I am here for. But I get ahead of myself.

Not content with difficulties of going for an interview after 2+ years for a technology I haven't touched in as many years, I had made it even worse by agreeing to be interviewed for a place that follows radically different programming practices. I have written about not liking XP, but the place that I was going for was an XP house, out and out.

All in all, this seems like a perfect case to use to brand me a sucker for punishment. Out of touch with J2EE, impossible to give a good interview, and hate the development methodology. Why did I bother?

2+ years ago, I had left J2EE to go ASP.NET to learn what ASP.NET had to offer. I wanted to expand my horizons, to learn about the competition. I wanted to see how and why ASP.NET may do things better than J2EE. Now, I do understand how these two technologies differ, and how one may be better suited for a particular job.

I wanted to try the same thing with XP after working in traditional methodologies all my life. To see what the competition had to offer. I had tried XP on my own and had ended up disliking it. My thought was to give it a shot for a couple of years and than reach an informed opinion.

Of course, I ended up giving a horrible interview. Combination of nerves, inability to think on the spot and the wondrous and unique ability of fluffing up simple explanations made for an excruciatingly difficult interview. Add to that the fact that the guy I had pulled up in my previous interview disaster now works for this company and had asked if I now knew the answer to the classic ('So you don't know what a static inner class is?') question. At that point I knew I had no chance. Of course I still don't know the answer to this question, but I guess I could simply look it up.

Which brings me to ponder on my next steps. Not getting through the interview wasn't a disaster. I already have a secure job and good working environment. I have even started on a new J2EE project. But not clearing interviews is starting to bother me now. Failing four interviews in 3 years is not a complete disaster, and I am not even counting the first one because it was inherently flawed. But it has been since that interview that I haven't cleared any more and that is a cause for concern. Going public with this admission may be a bad idea and self-deprecating, but I hope to learn how to get over this fear of being interviewed.

Now if you will excuse me, the fourex man has been holding on to my cold beer for a very long time now.

Of course, in that regard, open sourcing Java ME has no benefit. The source code for Sun's implementation of the complete Java ME API stack has been available for a long time now via the Sun Community Source Licensing. Check it out here. The community source licensing is very similar to what the goals of open sourcing it would be. Of course there are differences, and I am no lawyer, so make your own judgements by looking at the community source licensing page here. It even allows you to modify the source code and contribute the changes back for 'the benefit of the community' without getting paid. Sounds very much like open source to me :).

Note that the change log notes that the changes are accepted for 1.1 release, when in reality, it should be 1.2 release. I guess that there will be another release to fix that!

So why does Javablogs.com classify me as a mock Sun employee?

If Sun would like to offer me a position, I will be more than happy to call myself a mock Sun employee. Or whatever. But then I wouldn't be 'mock' anymore so that may defeat the purpose. How about Sun employee emeritus? Or Distinguished Sun fellow?

On second thoughts, Vikram Goyal may be fine too. I am still open to a position with Sun though.

So, would it come as a surprise to you that my good intention of using AJAXish behavior on an existing web application turned into a nightmare of gargantuan proportions, and it had nothing to do with knowing how to use AJAX?

It had all to do with knowing when to use AJAX.

To keep this entry simple, suffice to say, that I decided to implement a Google Suggest like capability for a search field in the said web application. I was happy with the result and so was my manager and we decided to show this to the users.

They hated it.

Not just hated it, but showed a varying range of emotions including paranoia, skepticism and general hatred towards the programming geeks (OK just kidding). Sample some of the responses (You need to know Google Suggest to understand these responses):

1. Why is this page not refreshing?

2. What is this drop down and why doesn't it go away?

3. Where is my result?

4. How do I select my result?

5. Why is this thing preselecting a partial result?

6. Aren't we paying you too much?

7. This coffee you served smells weird.

(They didn't actually say the last two, but I swear they meant to).

So, lesson learned.

Users are used to a certain way the web works. They expect a page refresh. Unless the whole web changes to resemble AJAXish behavior, they won't like this mixing and matching. Confusion will reign. Do I wait for the page to refresh or will this text box magically open up? Do I click this button or do I let it be clicked for me? In short, user experience will suffer.

I am not bad mouthing AJAX. It's a cool new slant at a new web (using, I emphasize, existing technology). But that's it. It's a cool new programming technology for the programming types. Unless the actual users initiate the need for change, or the users are involved from the start and shown the possibilities and accept the changes, use AJAX in moderation. Take one bitter pill a day.


var xmlHttp;
function createXMLHttpRequest() {
  if(window.ActiveXObject) {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
  } else if(window.XMLHttpRequest) {
    xmlHttp = new XMLHttpRequest();
  }
}

Now, having obtained an instance of this object, you can use it like any other Javascript object. Of course, the nice thing about it is that it can make HTTP requests to a back end process independent of the containing document or browser requests.

So the steps are:

1. Create this object.

2. Tell this object which method will handle response from the server.

// handleServerResponse is a method in your javascript code.
xmlHttp.onreadystatechange = handleServerResponse;

3. Make your request:

xmlHttp.open("GET", "YOUR URL"); // can use POST or PUT as well

4. Send your request:

// the parameter to this method can be an optional request parameter
xmlHttp.send(null);

5. Handle the response from the server in the method that you designated earlier.


function handleServerResponse() {

  if(xmlHttp.readyState == 4) { // the state when the request has completed
    if (xmlHttp.status == 200) { // the HTTP status code returned from the server
      var server_response = xmlHttp.responseText; // the servers response, use this with DHTML to modify current page
    }
  }
}

Everything else that you hear about AJAX, trust me, is just clever Javascript that is used to manipulate the DOM of the current document based on this asynchronous request to the server. Your server side code is not affected (unless you are coding specifically for AJAX).

There are other methods and properties of the XMLHttpRequest object and these can be looked up here.

I couldn't believe how simple it really was. The hype around this technology is mostly to do with AJAX patterns and clever stuff that is done using asynchronous requests and manipulating the browsers DOM on the fly. So if you know how to manipulate the DOM using Javascript, you now know how to manipulate the DOM without needing to make the whole page refresh.

I have never used Hibernate commercially.

There. With that career ending publicly stated confession, let me take a bow and get out of the way to contemplate a career change to opening my own curry restaurant (Ah, at least I would be able to eat my own creations).

For that matter, I haven't actually ever used Spring. Or Tapestry. Or Velocity. Webwork? No. I do have books on Hibernate, Spring and Tapestry.

While I am in this self-destruct mood, let me add. The last framework that I actually used and can tell you everything about in a heartbeat is Struts, version 1.1. I have only recently used Struts 1.2, and would be clueless if you asked me anything about the new Struts Shale Framework, based on Java Server Faces.

For me, the requirement to use anything over that framework didn't arise (the fact that my day job requires me to work partially with ASP.NET may have something to do with it as well). Unlearning a solid, reliable framework that did everything that you asked of it, just didn't seem right. There is not a single case I could make against using Struts (1.1 and 1.2) in production environments.

So, back to the list. Paul Reedman, responding to an article on a failed Java project in West Australia, hit the nail on the head by saying:

"Java Frameworks good grief what a joke, take your pick we have a million of them. Everyday on Server Side I read about a NEW, FANTASTIC, LABOUR saving framework.

I still run into Java projects that build their own frameworks !!! Yes Struts or hibernate is not good enough, we need our own framework, so lets spend precious several weeks (or months) of the project time recasting a new web framework."

He goes on to add:

"Another thing I have noticed is that Java people love building layers. So a particular developer doesn't like the interface into hibernate or struts (or whatever framework) so they build another layer on top of the framework.

This layer then becomes complicated and so a whole bunch of other people add to the layer in an attempt to make it "easier". (which doesn't happen because all they have done is to make it more complicated). Of course this new layer hides everything and soon you have no idea what you are doing. Importantly no one documents this new layer, so when new people join the project, they ask "I don't understand this framework..". Of course they don't know that underneath all of this software is plain old struts which has disappeared from view."

How true. Plain old Struts. Even though I have a propensity to add multiple layers to my Struts projects, I love the fact that Struts is the glue holding them together in a working whole. There was a never a requirement weird enough that made me think, "Hmm. Maybe Struts can't do that, better look at other frameworks".

Or maybe, I am holding on to the past without thinking about the future. Would I still be using Struts (ok maybe 1.2 instead of 1.1) 5 years from now? 10 years?

Or would I be giving away free rice with your curry?

In keeping with complete compliance with the java.net weblog policies, may I introduce you in a selfless way to my book on Mobile Media API, recently released by Apress.

Mobile Media API, as you may know, allows you to add multimedia capabilities to your Java enabled device (For an introduction to this API, please read a tutorial at java.net by, ahem, me, here: http://today.java.net/pub/a/today/2005/09/27/j2me4.html). The book covers this API in exhaustive detail and shows you how to add audio and video, generate tones, play with MIDI, capture audio and video streams and so on.

You can buy the book at Amazon here, or get to the book's website at Apress here. The Apress site also has a sample chapter on Media Player Lifecycle and Events. Finally, the book's companion site is here, where I run a case study on audio/video/text blogging from your mobile phone using MMAPI.

I also plan to giveaway two copies of the book to the first two people who promise to write a review on Amazon afterwards. Please email and convince me of your commitment at vikram@mmapibook.com!

Comments, feedback etc. also welcome at vikram@mmapibook.com.

So we decided to sign on the dotted line, paying the hefty deposit of $3000, on the condition that the final costs for site works be told to us before we proceeded further. If the site works came to be of a prohibitive cost, we would have pulled the plug on the project and waited a bit longer before we had enough money to go on.

You see, the block had a curious problem. It sloped for 2.75m (9 feet or 3 yards roughly) from the front to the back in a diagonal way. This required special ways to place the house, exact details of which, I will spare you.

The builder agreed to this condition and proceeded to provide an estimate for the site works, which would be accepted as final, as it would be done by their site surveyors and professional estimators.

So in early February, we received the final site works cost of $23200. An expensive figure, but we were preparing ourselves for it.

To cut a long story short, we then proceeded to customize the house. You know, widen the cupboards a little, paint this room this awful pink, select the tiles and so forth. Except, to be told 2 months later, that the site works done in February was incorrect, performed by an incompetent staff, and unfortunately, the actual cost IS going to be prohibitively expensive.

Now, mistakes happen. That's life, even if it spoils three months of designing and dreaming up your home. What happened afterwards, however, is less than optimal.

The builder decided to get nasty. Ignored phone calls and emails. Blamed us for our 'tight budget' (Yes, that's very professional, blame the victim). And asked us to cancel the project so that he won't have to refund the full deposit, when the mistake as admitted by their estimation manager, was because of their estimation staff.

So, where am I going with this personal story and why am I telling it to everybody unconcerned with the building industry?

There is a lesson here in managing failures of estimations that go beyond one industry and apply very specifically to the software industry.

This week, I had to go to a client's place. Perturbed by the lack of smoothness in a software/hardware rollover, I felt the heat as the client replayed to me a promised estimate provided by my manager and I several weeks earlier. The client complained that the initial estimate had proved wrong and that they were suffering because of it and were clearly unhappy.

I froze on the spot when I heard what she had to say. The words were eerily familiar. Ignoring the specifics, what she said, was exactly what I had said to the builder. There was a clear failure in providing estimates in both cases. I was now the builder and my client was me (ok ok metaphorically). I struggled with the implications.

I thought to myself: "Why am I any different to the builder? I failed to provide a service as a result of incorrect estimation, same as that &#$* builder. Is the client now thinking the same $#%^ thoughts about me?"

Clearly, a case of practice what you preach was in order.

The difference, as you may guess, lay in the way the estimation failure was managed. Instead of blaming the client, I apologized for the delay, provided a reasonable guarantee of future services and delegated tasks to ensure that the problems were rectified as a matter of high priority.

Of course, the core problem remained. What about the flawed estimates? How could I ensure that the estimates didn't fail us again? Further and more importantly, how could I ensure that failure of estimates didn't leave the client more unhappy than is to be expected from a failed commitment? In other words, how do you manage programming estimation failures?

As programmers we are notoriously and perhaps naively lampooned for providing generalized estimations ('If the software guys say it will take 4 man weeks, it will actually take 8'; or 'oh this is simple, it will only take a day!'; or 'you want it when?').

Yes, not all of us are like this. But we all do fail in our estimates one time or the other. The problem is not in the fact that we provide an incorrect estimate, but if we don't manage the fall out better.

So to repeat the question, how do you manage such failures?

(BTW: If by chance you live in Australia, and by chance you also happen to live in the state of Queensland, and further, due to another fortuitous circumstance you are also looking to build a house, well, first, Hello and Good Luck! and second, avoid Newstart homes like the bubonic plague. We still haven't received our deposit back.)

Of course, by winning the coffee mug, I will be a more productive blogger and wake up from my blogging slumber.

This is not entirely a blog entry for personal gain (so you can't boot me off Chris!). I am helping to spread the word of this worthwhile competition. As a previous winner (3rd prize still allows me to call myself a winner. Snif.) I have seen the benefit that this comeptition can bring to no-name software developers and students with half decent ideas.

So.. if you click on the image below, I get points that will help me win a coffee mug. But in the bargain, you get to know of this useful competition for Java ME (OK! J2ME) applications run by Sun and BenQ. A fair trade, I say. Click away!