This was a long awaited post, not by the readers waiting to read this but by me, the author, waiting to write this. This is by far the most important blog post written by me, not for its content but for the moment it describes.
In a previous post titled "My GSoC 2007 Story" I wrote about how excited I was about this association with Mozilla and about the opportunity to fulfill my long lasting dream of contributing to open source and having credit for some notable software development. But that just the beginning of the fulfillment of the big dream. The way was just shown to me and I was given the map just having the end points of the journey. It was up to me to figure out the way and reach the destination after crossing all the hurdles. I am now proud that I could stand the journey and complete it. This post is the proof and the reward together.
The journey was of course not smooth as described in my "First Mozilla journey" post. But it was worth it. Now about the day I achieved it. It was 5th Sep 2007, yes Teacher's day here in India. (I guess I should really be thanking my teachers for their teachings as well as blessings). That was when Shawn(sdwilsh) checked in my patch, of course with certain changes to it from him. Here is the check-in comment.
The end was more tiring and hectic than I initially assumed. My feature was initially targeted for M7, but then due to delay from my side it was re-targeted to M8. Since this was considerably big thing and involved quite a bit of risk the drivers decided that this feature would be in only if it can come in by M8. Things were going pretty well with me working till 10 or 10:30 at the office due to lack of internet connection at home. I used to get a new patch every alternate day or at least hit a dead-end and wait for help from biesi/dmose/sdwilsh or some other person. I ended up adding more stuff to nsDownloadManager class than I thought I would be doing. Every week more than 2 or 3 times I used to discard some done stuff and redo it in different way. This was mainly because of my lack of XPCOM knowledge. Though I was very determined to get it in FF3 it was getting heavier and heavier for me. Thank God, I finally submitted a patch which addressed all the issues mentioned in the comments earlier.
It was all working and just a few hours (that was 10:30pm here and I had to go home - by bus) before the tree was to close for M8 I figured out that nsIFile.GetSize() was not returning the proper value because of which downlaods were getting corrupted and were of sizes more than the source files. The solution turned out that I had to clone the file to avoid the cached values. This required some effort and I postponed it to next day morning hoping to get it done before the tree closed. Though dmose told me to do it right away so that a review can be done that day itself and the patch would go in. But it was too late for me and I just left the office against all my wishes to stay overnight and work with those guys struggling in US. All the way to home I was cursing myself as I was not confident of getting it done in couple of hours and hence I might lead to this feature being dropped from FF3. That would have been like a big blow to me as I had widely publicized this among many of my friends.
The scene on the other end was also pretty similar. sdwilsh and Mardak spent almost the whole debugging my patch and figuring out what was happening. dmose had mentioned earlier itself that the management wanted this feature though it was not in the FF3 PRD. Lots of people had already blogged about this feature in FF3 and hence it was very critical. They finally figured out that the "http referrer" was also needed for resume to work properly and they added that also to the DB and sdwilsh came up with a new patch and probably got it reviewed by Mano.
When I came back in the morning the new patch was ready and the whole of mozilla team worldwide was active as lots of check-ins were to be done before midnight. sdwilsh finally got mconnor to review the patch. Since it was patch which was r+ by sdwilsh, mconnor could not find any flaw except for a comment about the file cloning to be made more clear. It was finally made and sdwilsh told me that he would be checking in that patch. I was very much excited and I had every right to be. After 3 months of work, several night outs discussing stuff with my US counterparts and much other effort had gone into bringing out the code in that patch. And finally when sdwilsh put the cvs check-in output on the bug I was so relieved. I knew that it would take an hour atleast for the new code to be picked up by mxr. After an hour I visited mxr to see my name in the contributors list. I copied the link to the line with my name in the nsDownloadManager.cpp and put it as my status message in GMail chat and Gtalk.
It was a great learning experience for me and a much greater sense of achievement.
Thanks again, Google and Mozilla.
I now continue to be a part of this awesome community and contribute whenever I can. After this success I took up the job of providing resume support for "Open With" kind of downloads. More about that in another post.
Shree Yalaguresh Prasanna.
Hari Om.
Thursday, October 25, 2007
Wednesday, October 17, 2007
Theory X and Theory Y
This is yet another discussion that I had with my Doddappa(uncle). The title seems to be a very interesting and something exciting. Even I felt the same when my uncle first mentioned it. But it eventually turned out that it was a very much common and known thing. Then why the hell am I writing about this here?? Well the answer is, I did not know that such a common thing could be documented so well and that it would be on of the most important management theories.
There is a nice Wikipedia article about this: http://en.wikipedia.org/wiki/Theory_X_and_theory_Y and hence I will not be writing anything about this here.
In short Theory X is the pessimistic view and Y is the optimistic view about the people you are managing. But in reality people at any place are really a mix of this and are generally somewhere in between these two extremes. So the manager needs to shrewed enough to identify and categorize people and manage them accordingly. Because X-type of management will piss-off the Y-type of people and may result in resource loss. The reason is that self motivated and creative people want freedom and do not like to be persistently nagged. On the other hand Y-type of management for X-type of people will result in zero or close to zero output and the manager's neck is on the blade. The reason simply being that lazy people who are at work just for money and exploit all facilities will just do that and refrain from working. So managers and people aspiring to be managers, though this is a very common and old and also a sort of outdated philosophy my guess is that it still is an important one.
There is a nice Wikipedia article about this: http://en.wikipedia.org/wiki/Theory_X_and_theory_Y and hence I will not be writing anything about this here.
In short Theory X is the pessimistic view and Y is the optimistic view about the people you are managing. But in reality people at any place are really a mix of this and are generally somewhere in between these two extremes. So the manager needs to shrewed enough to identify and categorize people and manage them accordingly. Because X-type of management will piss-off the Y-type of people and may result in resource loss. The reason is that self motivated and creative people want freedom and do not like to be persistently nagged. On the other hand Y-type of management for X-type of people will result in zero or close to zero output and the manager's neck is on the blade. The reason simply being that lazy people who are at work just for money and exploit all facilities will just do that and refrain from working. So managers and people aspiring to be managers, though this is a very common and old and also a sort of outdated philosophy my guess is that it still is an important one.
Tuesday, October 16, 2007
Basic Planning Gyaan
I recently completed my graduation in Computer Science and Engineering and started my career at National Instruments R&D as a Software Engineer. There are a lot of things that I learnt here in first few days. Of course I cannot put all of that here. But I can indeed put some most generic things, things mostly known to all or at least a lot of people. This post has something like that. The freshers here (one of whom was me) had a meeting with our manager for a particular thing. We discussed a lot of things out which I found few interesting and have put them here. These are mainly management related stuff like how a professional should lead his/her professional life. Pretty simple but very important things. These things are very essential for any organization to be successful.
Don't push things , rather take things on. Take Responsibilities .
-- This is the good old thing which told us not to put the blame on someone else when we do not succeed. Its just put in a different way. Whenever we have task facing us we should always go for it rather than shun it away waiting for someone else to take it. We should realize that the more we work the more we grow. Its always a +ve things to take up responsibility than to drop them or avoid them.
Always Under Commit , Over Deliver .
-- The previous point tells us to take up work. But what it does not speak about is that whatever is taken up must be completed in time. When accepting a job, when committing for something we should make sure we got enough room for this new thing and it is not going to affect our previous schedules and commitments. And also when finalizing deadline we should think of unforeseen situations and obstacles and plan accordingly. Have some buffer time reserved. Hence we should always under commit and try and work hard to over deliver. This point might seem contradicting to the previous one but both are to be balanced well to go up the ladder.
Don't randomly oscillate on days . Divide your day properly.
-- This is the discipline part. Every day has to be productive. At the end of each day when you ask yourself about that day's outcome you must have a valid answer. And this can happen only when we properly plan the day. Planning plays a crucial role even in a day's work. So instead of spending the day trying to do a lot things, we better plan the day. Tools like post-it reminers, or an online dairy or a calendar or some other form of To-Do list will come a long way in making the day fruitful. So the first thing you got to do when you move in daily is to list down the tasks you plan to do that day. Something like 5 to 10 minutes should be sufficient for this. Be sure to note these things so as to verify later. Start work as per plan. Note down any new thing that you come across in the middle of the day. Then close to the end of the day, say around an hour before you leave verify whether you accomplished all the listed tasks. If some critical things were left out then complete them before you leave. Or may be you can postpone the less important ones to a further date.
What is more important to a plan to work is that it should be followed. So once you have a plan for the day follow it. And follow it as closely as possible. Do not oscillate between multiple things at a time. For example - if you are focussing on something very seriously, just don't start browsing. That will put you out of the frame(of course unless you have some real good control over thoughts and mind).
Plan everything well for the time you spend out of the office as well.
-- Our personal life affects our professional life almost in every aspect and the converse is also true. If we can't get things done on time in office we end up staying late and that annoys people at home. They start cribbing, telling us why we are late daily and all that stuff. That obviously makes us angry and we lose the mental balance. And when we are in office with such a mind we do things in a much worse way and the cycle goes on. So we better plan things for our personal life also. Just to make sure that we are successful everywhere.
These are a sort of Golden Rules for anyone who aspires to be successful. At least that is what I feel. I of course have started following these and it has helped me a lot.
Don't push things , rather take things on. Take Responsibilities .
-- This is the good old thing which told us not to put the blame on someone else when we do not succeed. Its just put in a different way. Whenever we have task facing us we should always go for it rather than shun it away waiting for someone else to take it. We should realize that the more we work the more we grow. Its always a +ve things to take up responsibility than to drop them or avoid them.
Always Under Commit , Over Deliver .
-- The previous point tells us to take up work. But what it does not speak about is that whatever is taken up must be completed in time. When accepting a job, when committing for something we should make sure we got enough room for this new thing and it is not going to affect our previous schedules and commitments. And also when finalizing deadline we should think of unforeseen situations and obstacles and plan accordingly. Have some buffer time reserved. Hence we should always under commit and try and work hard to over deliver. This point might seem contradicting to the previous one but both are to be balanced well to go up the ladder.
Don't randomly oscillate on days . Divide your day properly.
-- This is the discipline part. Every day has to be productive. At the end of each day when you ask yourself about that day's outcome you must have a valid answer. And this can happen only when we properly plan the day. Planning plays a crucial role even in a day's work. So instead of spending the day trying to do a lot things, we better plan the day. Tools like post-it reminers, or an online dairy or a calendar or some other form of To-Do list will come a long way in making the day fruitful. So the first thing you got to do when you move in daily is to list down the tasks you plan to do that day. Something like 5 to 10 minutes should be sufficient for this. Be sure to note these things so as to verify later. Start work as per plan. Note down any new thing that you come across in the middle of the day. Then close to the end of the day, say around an hour before you leave verify whether you accomplished all the listed tasks. If some critical things were left out then complete them before you leave. Or may be you can postpone the less important ones to a further date.
What is more important to a plan to work is that it should be followed. So once you have a plan for the day follow it. And follow it as closely as possible. Do not oscillate between multiple things at a time. For example - if you are focussing on something very seriously, just don't start browsing. That will put you out of the frame(of course unless you have some real good control over thoughts and mind).
Plan everything well for the time you spend out of the office as well.
-- Our personal life affects our professional life almost in every aspect and the converse is also true. If we can't get things done on time in office we end up staying late and that annoys people at home. They start cribbing, telling us why we are late daily and all that stuff. That obviously makes us angry and we lose the mental balance. And when we are in office with such a mind we do things in a much worse way and the cycle goes on. So we better plan things for our personal life also. Just to make sure that we are successful everywhere.
These are a sort of Golden Rules for anyone who aspires to be successful. At least that is what I feel. I of course have started following these and it has helped me a lot.
Mozilla - Bookmarks' keywords & Quick Searches
This world is really full of amazing things. How much ever we discover and find out, there will be something interesting just right next to us which we would not have figured out. This post is about one such thing, which was right here from such a long time and I had not figured it out.
The first hints for this came to me when I saw one of my colleagues, Pramod S, at NI using shortforms for Google(g) and Wikipedia(wp) when searching. I thought he had come across some hack and tweaked his browser. But just today I realized that it is infact a feature in Firefox.
For any URL or webpage that we bookmark we can assign a keyword, a shortform, which can be entered in the URL bar to visit that bookmarked page. This is really a very useful things if we visit certain pages over and over again. In my case http://mxr.mozilla.org/seamonkey/ is one site that I cannot live without. So I have keywords for the 3 different searches available at this page, viz:
The first hints for this came to me when I saw one of my colleagues, Pramod S, at NI using shortforms for Google(g) and Wikipedia(wp) when searching. I thought he had come across some hack and tweaked his browser. But just today I realized that it is infact a feature in Firefox.
For any URL or webpage that we bookmark we can assign a keyword, a shortform, which can be entered in the URL bar to visit that bookmarked page. This is really a very useful things if we visit certain pages over and over again. In my case http://mxr.mozilla.org/seamonkey/ is one site that I cannot live without. So I have keywords for the 3 different searches available at this page, viz:
- mxrf - for file search(find)
- mxri - for identifier search
- mxrt - for free form text search
This feature is really handy and increases the brwosing speed to a great extent.
How to get this working? or how to assign the keywords?. This again is really simple. For existing bookmarks just go to the Bookmark properties by Right-Clicking on that and you get a small dialog with a text field for Keyword. Key in whatever you want and click on OK. Thats it you are ready to fire the internet with your keywords. For new bookmarks it is still easier. When you are creating a bookmard with the helper dialog you get the keyword field which you can key in or leave it blank (either to be filled later or not to be filled at all).
This is not the end. There is yet another enhancement to this. Certain bookmarked urls have query strings, as in case of search urls. The google url: http://www.google.com/ is followed by a query string of the form "search?hl=en&q=search string" which carries the search string entered. Such strings work with the keywords also. Meaning you can search for something on google using the keyword, 'g' like this:
"g any-search-string" . This will be converted to appropriate URL with a proper query string as specified in the bookmark properties. As it appears this of course requires a little bit of extra work. When saving an URL as bookmark, for instance when saving http://www.google.com/ you can save it along with the query string, but the search string being substituted by "%s" and whatever string you specify with the keyword will replace every occurance of %s in the URL. So this is how the bookmark URL will look like:
http://www.google.com/search?hl=en&q=%s ---- with g as the keyword. Now when using this bookmark, if you enter something like this in the URL bar:
"g bookmarks " -- this becomes-- http://www.google.com/search?hl=en&q=bookmarks -- and finally giving you search results for bookmarks.
Now this is how I have arranged my mxr bookmarks:
- http://mxr.mozilla.org/seamonkey/find?string=%s -- with keyword: mxrf
- http://mxr.mozilla.org/seamonkey/ident?string=%s -- with keyword: mxri
- http://mxr.mozilla.org/seamonkey/text?string=%s -- with keyword: mxrt
Now does this method appear too complex and cumbersome? Well mozillians come to your rescue yet again. You can save such enhanced search bookmarks called "Quick Search" bookmarks very easily like this:
Go to the search page and Right-Click on the search bar, and click on: "Add a keyword for this search" . That will give you the small bookmarking dialog, with a field for keyword. All that you have to do is to just enter the keyword that you want and click on OK. All the URL, query string and %s headache is taken care by Mozilla.
Well mozilla is here just to make your browsing experience easier, safer and worthwhile., isn't it?
And I am proud to be associated with this awesome community. ;-)
Happy and Fast Browsing.
Subtle things about s/w code Performance
Any software product is first benchmarked for its performance before it is shipped out. No company/developer wants complains about the performance of the product from its users. This one single thing can make the users to simply move away to another better performing product. And moreover such a complaint would mean inefficient coding and to some extent incompetence of the developers, which we software developers can't really take.
Performance is generally measured with 2 parameters:
1) Time taken by the application
2) Memory consumed by the application
Typically, on current day Desktop systems the memory criteria is almost ruled out, unless the application is really memory consuming like 3D games and other high end stuff.
But time has always been a concern. So many algorithms are developed to solve the same problem, with each algorithm being a good choice under some set of conditions. Those are all the high-funda things involving Math, mainly things like: O(n), Exponential complexity etc, etc..
Apart from these there are a lot of very small things, which appear as very trivial and insignificant but eventually make a lot of difference. I learnt about 2 such things at my work place NI, yesterday when I was working on my first task here. I of course cannot speak of the nature of my work and what exactly I was doing. Here are the generic things that I learnt:
1) Avoid calling a function in a loop, instead pass the data you are iterating in the
loop to the function being called.
Suppose you have a large amounts of data to be processed and you have helper processing function and an actual processing function. The most common way of accomplishing such a task would be to iterate through the data in the helper function and for every single instance of the data call the actual data processing function. This can be optimized to a great extent in a lot of cases. By iterating through the data in the helper function and calling the actual function we introduce a lot of function-call overhead, which obviously eats up a major chunk of time. If possible, which it indeed is in many cases, we should instead pass the large data chunk to the actual data processing function and iterate over there and make the necessary processing then and there itself as and when we fetch an instance of the data.
PS: By data instance here I mean one data unit. Something like an element if the data chunk is an array. If it is an array of structures, then one data instance would be a structure.
This way we reduce the overhead caused due to extensive function calls and there by improving the performance.
2) If we have an if/else block which is hit a lot of times continuously, then we should have the code for the most probably case in the if block.
This is particularly interesting. Yesterday when my tech lead told me about this, I was really surprised that optimization can be done at this level. I liked this very much.
Consider the following code fragment:
This is how the assembly code would look like.
Here the if/else block is repeatedly hit as it is in a loop and is the main body of the loop. In the assembly code when the if condition turns out to be true the code for true case is execute and then a JMP is made to loop beginning. BUT, but, in case of else there will be "2" JMP instructions - one to go to the else block and another to go back to loop beginning. This double jump obviously is an overhead and takes more time for execution. Hence we should try and design the if/else in a such a way the code for the most common or most probable case to be put in the if block, so that a maximum part of the execution happens only with a single jump.
This might seem so stupid or so subtle that may lead to the thinking that the performance gain with this trick is almost negligible. Its not so. Believe me, the gain is really good in most cases where the if/else block is repeatedly hit.
So stop jumping around and start improving your code. ;-)
Performance is generally measured with 2 parameters:
1) Time taken by the application
2) Memory consumed by the application
Typically, on current day Desktop systems the memory criteria is almost ruled out, unless the application is really memory consuming like 3D games and other high end stuff.
But time has always been a concern. So many algorithms are developed to solve the same problem, with each algorithm being a good choice under some set of conditions. Those are all the high-funda things involving Math, mainly things like: O(n), Exponential complexity etc, etc..
Apart from these there are a lot of very small things, which appear as very trivial and insignificant but eventually make a lot of difference. I learnt about 2 such things at my work place NI, yesterday when I was working on my first task here. I of course cannot speak of the nature of my work and what exactly I was doing. Here are the generic things that I learnt:
1) Avoid calling a function in a loop, instead pass the data you are iterating in the
loop to the function being called.
Suppose you have a large amounts of data to be processed and you have helper processing function and an actual processing function. The most common way of accomplishing such a task would be to iterate through the data in the helper function and for every single instance of the data call the actual data processing function. This can be optimized to a great extent in a lot of cases. By iterating through the data in the helper function and calling the actual function we introduce a lot of function-call overhead, which obviously eats up a major chunk of time. If possible, which it indeed is in many cases, we should instead pass the large data chunk to the actual data processing function and iterate over there and make the necessary processing then and there itself as and when we fetch an instance of the data.
PS: By data instance here I mean one data unit. Something like an element if the data chunk is an array. If it is an array of structures, then one data instance would be a structure.
This way we reduce the overhead caused due to extensive function calls and there by improving the performance.
2) If we have an if/else block which is hit a lot of times continuously, then we should have the code for the most probably case in the if block.
This is particularly interesting. Yesterday when my tech lead told me about this, I was really surprised that optimization can be done at this level. I liked this very much.
Consider the following code fragment:
for ( execute some times) {Something like above when compiled into machine language would look like this:
if (aCondition) {
.....
.....
} else {
......
......
}
}
loopLabel: instruction for condition check;
JMP if false to elseLabel
code for true case (if block)
some more code for true case
loop condition check
JMP to loopLabel if true
elseLabel: code for false case (else block)
some more code for false case
loop condition check
JMP to loopLabel if true
This is how the assembly code would look like.
Here the if/else block is repeatedly hit as it is in a loop and is the main body of the loop. In the assembly code when the if condition turns out to be true the code for true case is execute and then a JMP is made to loop beginning. BUT, but, in case of else there will be "2" JMP instructions - one to go to the else block and another to go back to loop beginning. This double jump obviously is an overhead and takes more time for execution. Hence we should try and design the if/else in a such a way the code for the most common or most probable case to be put in the if block, so that a maximum part of the execution happens only with a single jump.
This might seem so stupid or so subtle that may lead to the thinking that the performance gain with this trick is almost negligible. Its not so. Believe me, the gain is really good in most cases where the if/else block is repeatedly hit.
So stop jumping around and start improving your code. ;-)