With MS Office 2007, we have Ribbons where the menu of the application is drastically different than what we find in a traditional application. My first impression of Ribbons was "Sucks!". Its been more than a year when I felt that.

Technically, Ribbons are the modern way to help users find, understand, and use commands efficiently and directly—with a minimum number of clicks, with less need to resort to trial-and-error, and without having to refer to Help.




They have now become a UI components in Windows Forms. So far the handful of people I have meet haven't given me a good feedback about using Ribbons. But I somehow believe that it will soon become very popular. Remember how we hated the "Start" button on Windows XP and loved the start button of Windows 2000?

BTW, here is a good MS resource for designing UI components using Ribbons :
MSDN - Ribbons

I have learned and practiced "continuous development" and "continuous engineering". Does something called "continuous destruction" exist? I think it does exist, its just that we don't consider it as an area of study or practice in the Software Development Life Cycle. I think disposition of a component of a system is critical to its survival in this fast moving world of technology.

Continuous destruction should happen at all levels of the engineering community. From the top level product management to the individual coder, we should probably have the attitude to identify what to throw away and come up with something better.

It usually happens that we wait for the system to become obsolete or wait for someone to tell us that we need something better. After a new system is developed and delivered we generally sit down and relax and go into dividend earning mode.

So what’s stops you from destruction? Is it the lack of courage to change your “presently good system”? Is it the courage to tell yourself what runs short in your existing system? I think it’s the lack of inputs to decide what’s important and what’s not important for the system. What else?

In my current life as a developer, most of the successful designers are those who seem to have the guts to throw away their existing work or constantly evaluate parallel technology. These developers end up delivering more quality components. How many time shave you seen successful consumer products change their User Interface. Many do. Dont they?

The idea of "destruction" however is not studied as a phase in the Software Development Life Cycle, which I think we should be doing. Not doing so, makes different people with different roles in the project have separate ideas and energy about the idea of software destruction.

Related interesting link: Would Google destroy Digg or take it to the next level?

Happy destruction.//

This week at work Vinod introduced to me that there exists a Information Security certification called the Certified Information Systems Security Professional (CISSP). He is all GO on this one. On first hand, CISSP appeared to me as THE certification for a security professional after reading through many blog entries and specially after reading CISSP : Any Value, I am beginning to have second thoughts. Is this really for me, a security application developer? I havent yet concluded in for or against. In the midst of all this I am writing this short blog post.

Happy ??.//

I bet that you already knew that there are 3 ways to pass an argument to a C++ function(method). They are :

1. Pass by value.
2. Pass by address (pointer). --- which is technically a pass by value.
3. Pass by reference.

Today I realized that there is a fourth way of passing an argument which never occurred to me and none of the books I read told me about it (not that I can recall).
You can pass an argument as a reference to a pointer.

Example:
void FreeMyClass(MyClass*& ptr);

Why would you do that? Here is the precise scenario where I require it. I have functions that create pointers to objects.

Example: MyClass* CreateMyClass();

This function does a dynamic memmory allocation of MyClass and returns a pointer to the object. Consider it as a warapper to new operator, but doing some extra stuff.

The users of my API would would the pointer to do stuff and once they are finished they could call FreeMyClass(ptr);
Inside the function FreeMyClass(ptr), I want to reset the value of ptr to NULL, which I cannot do if my function signature was
FreeClass(MyClass* ptr), as pointers are passed by value.

Here is what my correct FreeMyClass function would look like.

void FreeMyClass(MyClass*& ptr) {
    
    if (ptr == NULL) {
        return ;
    }
    delete ptr;
    ptr = NULL;
   
    return;
}

The C way of doing such a thing is to have the function signature as:

void FreeMyClass(MyClass** ptr); 

This approach requires the caller to pass the pointer to a pointer of an object. I feel the C++ way is a more graceful way of doing things. With the C++ approach, you don’t have to depend on your user following the coding guideline that says, set a pointer to NULL after freeing it.

This thing is not so common in practice and so I wanted to shere it.

Happy Freeing.//

While administering Aminus3, we had a support query from somebody that said that her site login password changed everyday. I had to read the email more than once to understand what was actually going on. The password was not supposed to be changing daily, and even if it did, how would the user know.

What actually was happening was that, she would forget her password and click the "Forgot password" link on the site, expecting that her original password would be emailed. Every time the password reset email to her would contain a new password. It took a couple of such emails before she wrote to us reporting the bug in the system.

Coming to think of it, it is perfectly reasonable for a not-so-internet-savvy user to expect the "Forgot password" to send her the original password. Its straight logic -- need to read that article on usability again.

Food for thought!

Happy thinking.//