Apps
Contact
Seminars
RSS FeedFebruary 17th, 2010
TODOIST (or not to do ist)
I really wanted to move my task management off of Outlook and into the cloud. Looked far and wide for all online task management programs – and have found absolutely nothing that comes close to matching Outlook’s task management. Earlier, in this post, when I found 2 of the non
-free ones, I was a bit optimistic that one of them might have some features (after all they are not free!). But I came out fairly disappointed.
Disgusting. Makes you want to go out and just create your own (but I am not going to do that).
February 9th, 2010
Ultimately the cloud will win (Todoist and the curse of the free)
My hard drive is whirring with the impending screeching of the fatalistic fatal crash, and that makes me remind one more time that in a couple of years from now, I absolutely won’t give my slightest toenail’s hoot to it. Whether it will be ChromeOS, or something else, my sense is that enough things will be on the cloud by then, that the pain will be significantly lesser. One of my 2010 resolutions is to continue to move some of the things onto the cloud. My current goal within that mega goal is to move my task management to Cloud.
Currently, I use Outlook for task management. (MS haters have left the blog at this point. 
). Outlook is one of the best tools for task management. The options in Outlook are absolutely brilliant and very comprehensive. Sometimes people give an erroneous description of the 80-20 rule that 80% of the people only use 20% of the features, or only 10% of the people use the 90% “advanced” features, blah blah. Somehow, no one seems to agree on what the “top 20%” features are, or what are the 90% advanced features. In case of task management, the features are very straight forward, most of the people use most of the features – and some use ALL the features, and still ask for more. For example, I love (and use) the “second Tuesday of every month” , “generate new task x days after the completion of the previous task” options. Similarly task assignment, status report etc are all necessary features from my perspective. Anything else, and I might as well use paper.
So, the question arises – how to move task management into Cloud. Now, iGoogle has a bunch of task management widgets – such as Google’s official “to do” list and a few other options. Some of them are students’ summer projects. Some of them are students’ summer projects that have not been finished. All of them are free. (Bless the soul of open source. Even when it doesn’t work.) Then, there are two programs that are worth mentioning. First is goosync, and second is todoist. These two are not free, but they do work. Goosync’s strength is they synchronization piece. That explains the “sync” portion of the name. But, it is not that comprehensive – that perhaps explains the “goo” portion of the name. Goosync costs about 31$/yr (19.95 GBP). Todoist premium is about 60$/year. (Suddenly my 200$ Outlook that lasts about 3 years considering the MS refresh cycle stops sounding that expensive – but I digress from my cloud obsession).
I am still going to play with these two options for some time, and see which, if any, sticks. Another option is to see if MS offers a cloud option for tasks (something that doesn’t require an enterprise server.)
September 27th, 2009
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:
- Continuously check which servers are up.
- When a new request is received, send it to one of the servers as per the load balancing policy.
- 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 sessions.
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 fluff). Load balancing is comparatively more painless, and relatively 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.
September 20th, 2009
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:
- 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. - 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.
- 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. - 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.
May 29th, 2009
Hiring a QA is a tough job
I will be honest that I have never had any luck hiring a good QA. While my success rate in hiring a good developer is a whopping 66%, the success rate in hiring a good QA dips to an abysmal 25%. That number essentially comes from my past record of having hired 20 QAs, 4 of whom turned out to be super stars, and others not so much.
So, the question rises again, why am I hiring another QA today. But either way, I am about 22 minutes away from interviewing a candidate, and I am desperately looking for clues, cues and questions to ask QAs. Some of the good questions that I have found are:
- Describe any good or interesting bug that you found. How did you follow it up until resolution?
- After you file a bug, what are the various things that can happen to it? (The question is same as asking more directly, the different states of a bug)
- What is the difference between a test case and a test report?
- How do you handle when a developer marks your bug as “invalid”? (The question is whether the QA can zero in on the SRS as the ultimate resolver).
- How do you determine what to test? (Again, the SRS)
- How do you handle the situation that there is no SRS? (Initiative)
- We are starting designing a product that will be ready in 10 months. Rather than hiring you right now, wouldnt it be more beneficial to hire you at that time, since you will not have anything to do anyway? (Deliberately misleading question)
- When would you start creating the test cases?
Ok, that is how far I got, and I need to go to the conference room now.