Month: December 2006

Disabling the Browser Context Menu

Date: Monday, 18 Dec 2006 14:14
By Bret Taylor, December 3, 2006

You can disable the browser context menu for an element in your DOM with the following JavaScript recipe:

function disableContextMenu(element)
{
     element.oncontextmenu = function()
      {         return false;     }
}

For example, to disable the context menu over a photo on your page, you could use:

disableContextMenu(document.getElementById("photo"));

Browsers like Firefox do not always allow web pages to disable the context menu (this option is a setting in Firefox), so this recipe will not work 100% of the time in all browsers.

See the example

JavaScript Debug Log

Date: Monday, 18 Dec 2006 14:08
By Bret Taylor, December 3, 2006

Even with the most advanced debugging tools, every program requires a little “printf debugging”: run your program, print out state as it executes, and visually verify that everything is working properly. Unfortunately, there is no built in console to print debug messages to in JavaScript, forcing many JavaScript programmers to revert to calling alert() in their code. alert is completely infeasible for a function that gets called a lot, as it halts execution until you click an OK button. This recipe creates a simple debug log window that does not halt execution: 


function log(message) {
    if (!log.window_  log.window_.closed) {
        var win = window.open("", null, "width=400,height=200," +
                              "scrollbars=yes,resizable=yes,status=no," +
                              "location=no,menubar=no,toolbar=no");
        if (!win) return;
        var doc = win.document;
        doc.write("<html><head><title>Debug Log</title></head>" +
                  "<body></body></html>");
        doc.close();
        log.window_ = win;
    }
    var logLine = log.window_.document.createElement("div");
    logLine.appendChild(log.window_.document.createTextNode(message));
    log.window_.document.body.appendChild(logLine);
}

To print log messages, you just call log() within your code:


for (var i = 0; i < 10; i++) {
     log("This is log message #" + i);
}

When you push your code to production, you can just replace the definition of log with an empty function so your users will not see your debug messages.

See the example

Only well documented software will survive!

I remember when I started my previous job at 1999 as a software developer I’ve asked
my manager about the standards and policies of the company over the documenting. It wasn’t part of the requirements to produce any technical document that would help to see what is going on in the software. Some people started design documents and in beginning days it has been seen as a nice luxury to have if time allow us. Soon when the first phases of software delivery were over and maintenance became an issue every developer was asking the management to free some time for documentation. Unfortunately the need for documentation was not so crucial for the management as it was for the software developers that were responsible for maintenance of application that have been designed years behind.

In the meantime something else was going on which was very much related to this. First a new requirement was raised by the users. The Analysts brought them to developers to talk about the possibilities. Those architects being sharper than the rest took the opportunity and came up with a solution which was promised to rock. Some raised possible issues but very soon they were rejected as the solution was so “flexible” that those changes could be captured. In the beginning phase, just before users get a version to go live, when the concept is not proven to the users as it is for the architects, the new system can capture every requirement users want.. that seems a success, a big applause!

The architect gets promoted and the software is now in the hands of software developers. The product goes live and users are buying it. From time to time small change requests come to the development department and the responsible developer tries to figure out how it can be implemented. He realises that to get the software robust, he needs more time than expected and he learns not to underestimate the efforts. Next time a request comes he starts to tell the analyst that it is not that easy to implement this request and soon the requests make the developer frustrated. “It seems like they never make up their mind properly and keep changing their mind” he mumbles into his screen sometime while digging into the implementation. There comes a day that one of the requests is becoming too expensive to deliver and therefore the analyst finds a nice way of putting it to the request note to get it rejected. That developer may even leave the company and another one takes the place (they always do), but soon the same happens with the new developer and finally the management realises that “something should be done!” That is when management acknowledge the need for documentation.

One thing I have learned so far is that in IT business everyone is very busy and
nobody gets enough time.

I used to put the responsibility to the management’s shoulders to free up some time for me to get the documentation done. They couldn’t come up with nice and easy paste of project planning and it seemed always to be squeezed plan short on resources and the users want to get the product soon and some one made nice offer just to get the deal and so it is up to development to implement the new requirements. I had an impression that my manager tried to tell me (in a way) that I shouldn’t buy it if the requirements are not clear and detailed. Lost of time I happened to come across the situation where the current system isn’t really suitable to get the new requirements implemented. I should have seen it if I could get the requirements clear and detailed, and also if I know my system pretty well.

At the end of those days, I now realise that it was me whoI maintained that software. And it was me who suffered from the frustration and gave higher estimates for something that actually could have been done easier. And it was me who should have make the documentation happen. One could argue and say hey the time was not given, but I always believed that writing software is an act of art and I am the creator of it and at the end of the day the world is how we make it. So I should not have created any crap.

Fortunately, these days managers are more and more appreciating the documentation and it seems like they do their best to support the development
and free some time for documentation. That is very nice feeling when you have such a manager supporting you and that is how you can deliver maintainable software: Making good documentation at any costs.

In the past ten years I have seen tremendous changes in the way software is developed and maintained. Although there are plenty of methodologies I haven’t even thought about but it is remarkable that in this small world of mine companies have grown their IT departments into a dedicated service businesses. Companies are getting about 10 year service contract when buying the software. That is probably more than the service lifetime of a version of any big software like Oracle or even windows. Companies are investing huge money into the IT products and they want to get the best quality and longest support. It is not a shop-as-you-go business. It is rather a long-term relationship with support for change requests, as the market and the human needs are growing rapidly in these days. And one thing we all know; peoples demands never stops. So we need to make our software ready for that. We can’t assume that the system will cater all kind of situations and we need to document all aspects of it to make the changes coming in the near future possible.

So, who knows what I am writing right know? And who would want
to know that in 10 years over and over? It is me. And I can not remember it right if I wouldn’t right it down.