Best Buy, Theft Prevention, Israel and Customer Service

This morning I finally decided to get a new camera - the Sony W180, but let me not take the credit for it - the previous Nikon Coolpix had coolly stopped working entirely, after 2 years of great service. Pretty much every camera now a days is 10 or 12 Megapixels, which in my humble opinion is just crazy because I cannot even find the difference between images snapped using 5 and 6 megapixel cameras. (But don't let my feeble eyesight get in the way of your 40 mega pixel ambitions).

Best Buy has perfected the art of selling to technically challenged people, and I saw many cases of that glorious event happening as I walked through the store. The Sony W180 was available for $129, but you also need to buy your 20$ Sony digital memory card (standard camera memory cards don't work, and for pretty much the first time, I also decided to buy the 35$ 2-year warranty on it. The sales people there are extremely cordial, and helpful, and that is one of the strengths of Best Buy (although, just read on).

When I checked out of the store, the person on the exit door gave me a hard hard look, kind of reminding me of the time when I stood in the passport control line when entering Israel and answering questions about whether I am Jewish (I am not) or Muslim (I am not), and whether I am writing a book or a blog (I am yet to figure out what the interrogator was getting at on that one). The only difference is that this time I was just exiting a store after shelling out 200$, and by jove - the receipt was in the same clear bag that the salesperson packed and gave me, and was clearly visible from even the outside.

I remember a while back, Michael Righi got arrested for not showing the receipt at a store, so I am not sure if I would like to rebel in the same way, but that said, the experience of shopping at Best Buy didn't become better for me either. I have a steely resolve never to buy at Best Buy again.

So, what does this have to do with customer service, software or with anything? Perhaps not much, but it does reiterate a cheesy lesson we are taught in school - a chain is only as strong as its weakest link. I am currently involved with many customer service initiatives in my day job at NTELX, and it just reiterates to me that when checking the customer satisfaction, we don't have to get an "overall" or an "average" picture, rather, check what is the worst aspect of dealing with us from each client's perspective, then work backwards from there.

Customer Service as a crucial differentiator

Yesterday, I got $3.99 Horizon Organic Lowfat Milk from shoppers. When I got home, I noticed it was already curded. Now, if the carton that I picked up has gone bad, the others must be too. So, as a responsible consumer, I take it back to Shoppers and stand in line. The customer service person asks for my receipt. I am thinking of Seinfeld drycleaning episode. Really, what difference does it make - I don't want my 4$ back, I just want you to know that you have rotten milk on your shelves. Then, I give her the receipt and she returns 4$ to me. She doesn't thank me for taking the time to bringing back the rotten milk, but I do hear her page "Dairy Sales Associate to Customer Service" as I leave. So, I hope they did the right thing.

Later on, I drove to Jiffy Lube to get my car an oil change. Starting from simple tricks like looking up my name from the car tag and using that to greet me "Welcome back Dr. Arora" as I pull in to having awesome leather furniture in the waiting room, to carefully leaving the door open as I get back into my car, and my car key nicely hanging where I can find it, they make everything a breeze and a pleasant surprise. You hardly care what you pay (as long as it is in the range).

From a software or solutions company perspective, customer service is just as important. At NTELX, we have a saying - a customer who complains is our best friend, because that presents an opportunity to make things right. When any agency buys our software, they rely on the fact that we will help all users of the system reach their goals. If you call me, I will pick up the phone myself. If you email me, I will read it, and get back to you. Why do we do this? Simply so we can hear our customers and improve our software and make the problems disappear.

Changing CVS Root using find exec

There are a thousand ways to change the CVS Root, and one of them is this:

find . -name CVS -exec cp /tmp/Root {} \;

Obviously, what this does is to find each folder named "CVS" in the current folder, and copies the file /tmp/Root file into that folder.

(Just a handy trick.)

Clustering vs. Load Balancing - What is the difference?

These 2 terms - clustering and load balancing - are used in the same sense by a majority of IT people with relative impunity.

Clustering has a formal meaning. A cluster is a group of resources that are trying to achieve a common objective, and are aware of one another. Clustering usually involves setting up the resources (servers usually) to exchange details on a particular channel (port) and keep exchanging their states, so a resource's state is replicated at other places as well. It usually also includes load balancing, wherein, the request is routed to one of the resources in the cluster as per the load balancing policy.

Load balancing can also happen without clustering when we have multiple independent servers that have same setup, but other than that, are unaware of each other. Then, we can use a load balancer to forward requests to either one server or other, but one server does not use the other server’s resources. Also, one resource does not share its state with other resources.

Each load balancer basically does following tasks:

1. Continuously check which servers are up.
2. When a new request is received, send it to one of the servers as per the load balancing policy.
3. When a request is received for a user who already has a session, send the user to the *same* server (This part is important, as otherwise user would keep going between different servers, but not able to really do any work). This part is not required for serving static pages, in that case, there are no user session.

What does it mean from a user’s perspective? Which one is better?
Every time some one asks a generic question - which one is better, the answer is invariably "It depends". This isn't political equivocation, but simply restating the fact that if one was better than the other in all circumstances, then the other wouldn't exist.

Clustering saves the user's state, and is more transparent to the user, but is harder to setup, and is very resource specific. Different application servers have different clustering protocols, and don't necessarily work out of the box (don't you believe any of that marketing crap). Load balancing is comparatively more painless, and comparatively more independent of application servers.

From a user's perspective, it means that if the user is doing something on the application, and that server goes down, then depending upon whether the system is doing clustering or load balancing, the user observes different behavior. If the system is clustered, the user may be able to continue doing the transaction, and may not even realize that the server has gone down. If the system is load balanced without clustering, that means that the user's state will likely be lost, and the user will be simply sent to the other server(s) to restart transaction. The user has lost some work.

Hopefully that clarifies it somewhat.

A (soft) joke
I doubt if one article can clear years of misused terminology. The saving grace is that, it may give us one more of the soft computer science jokes that geeks can fall backwards on, the refined geeks scoff at, and no one else understands:

Q: Are you doing clustering or are you doing Load Balancing?
A: Yes.

YAGSC (Yet Another Grails Struts Comparison)

I have recently been inundated by emails about Grails (mostly good, some neutral, some outright complaints), even though my email inbox isn't much different from a certified black-hole. The great divide seems to be part philosophical and part technical. There are already quite a few technical comparisons of Grails vs. Java/Struts out there, such as: CompleteOpenSource, Nabble and StackOverflow, not to mention the big comparison over at JavaOne, but some of the philosophical issues seem harder to tackle:

1. Unsubstantiated Claim #1: Hesitation to move to Grails is really an unwillingness to learn anything new on part of Java developers.
   Really? This is a subjective claim, and I am sure it is going to be neither true nor false. But my personal experience on this issue suggests that Java developers do not want to learn Grails simply because they want to focus on solving new problems, not focus on solving new problems in a new way! It is the "new problem" that is of interest to them, not the "new way". One could argue that "new way" can make things much faster for them, but the Java developers frequently argue back that business (and not technical) problems are the ones where they are spending the time, so the "new way" isn't likely to change much in that case. This represents an implicit high level of maturity in Java/Struts based enterprise systems.
   
2. Claim #2: Grails is easier for development.
   Java, since its day one, has been known to be harder for development than say VB. Still, that has not stopped Java from progressing and reach dizzying heights. So, what does that teach us?
   
   The language/framework needs to be easy to develop, and scalable/efficient to execute/deploy. Which of these two attributes is more important - that is an inane question. Can you turn one knob up and the other knob down, and come out better? I don't know.
   
   With Java/Struts, apparently, the difficulty in development was not a show stopper. If Grails promises to ease development, but is even an epsilon less scalable, that already makes it a partially ordered set. In fancy terms: Grails, in that case, is not a Pareto optimization over Java. In layperson's terms: win some, lose some.
   
3. Claim #3: Grails doesn't have the same security of compile time checks.
   The bad news is that for a production system, this isn't so good. The good news is that by integrating unit tests, the impact of this problem can be minimized.
4. True, but pointless Claim #4: Convention over Configurability.
   This one is surprising. Grails lovers claim CoC to be a big plus. Java developers don't see why this should be a reason for celebration at all. Configuring a project takes very little time these days, and if you do that, and retain the choice of configurability, then should you be interested in something that takes 10 less minutes to setup, but is not as configurable?

Obviously enough, jury, is still out on this one.

XMarks

This is one browser extensions that I find very helpful. It is such a simple add on, but keeps the bookmarks on my home PC, work PC, laptop, netbook all synchronized. I just discovered that it now frees me up to organize my favorites wherever I am. Earlier, I would avoid organizing my favorites knowing very well that I also have to do it at 3 places, so inertia had a value. Now, being organized has a value, and I love it!

Here is the link to xmarks: http://www.xmarks.com/

Strunk and White's Golden Rule

In The Elements of Style, Strunk and White make one of the most obvious, yet one of the most overlooked rules in English - be concise!

I just reviewed a company brochure, and after 3 iterations with the pained writer, finally got them to cut down the introduction from 4 pages to half a page. Boy, it feels good.