All Your Blogs Are Belong To Us

We in India are no longer able to directly view blogs hosted on Blogspot, Typepad, Geocities, etc. This is because ISPs in India are blocking access to these popular sites acting on a government diktat to block some blogs "within the provisions of the Fundamental Right to free speech and expression granted in India's constitution" [sic]. Mridula was one of the first ones to notice and write about this blockade and the story has already made it to Slashdot and some of the mainstream media in India.

The government's diktat was to block a specific set of blogs ("to ensure a balanced flow of information") but since all the Blogspot URLs resolve to the same IP address, the blockade ends up blocking all blogs hosted on Blogspot. Ditto for Typepad, Geocities, etc. Since blogger.com is not blocked, I am able to post to my blog. I can also view my blog from my office since the Internet connection there is routed via a corporate proxy server located in the US. Using pkblogs.com, which was set up to allow people in Pakistan to view Blogspot blogs since they have a similar blockade in place, is another workaround, as is using a public proxy server or the Tor network using something like Torpark.

In 2003, a similar government diktat to block a specific Yahoo! Group had caused all Yahoo! Groups to become inaccessible from India. Thankfully that situation was resolved quickly and let's hope this issue is too.

A clueless bureaucracy eagerly assisted by a servile and clueless set of ISPs is not good news. Where is a cluebat when you need one?

GCC Summit 2006

Just FYI, the proceedings of the GCC Summit for 2006 are now available online. They usually make for interesting reading for those even mildly involved with GCC in particular or with compilers in general.

Presentation Skills

Most of us geeks seem to think that presentation skills are something for the marketroids or the suits to worry about. Even if we do have to present something, we only have fellow geeks in the audience who ought to be able to understand what we are talking about. However, geeks are humans too and humans need you to take care of certain things in your presentation for them to be able to fully appreciate and understand what you are talking about.

For example, in FOSS.in/2005 most of the talks were about cool stuff but in my opinion many a presentation left a lot to be desired. Among the talks that I attended, Jim Zemlin's talk about the Linux Standards Base was one of the precious few where the speaker seemed to understand and care about the basics of presentation.

Here are a few suggestions for speakers based on personal observations:

• Keep the points in your slides short - avoid verbiage. Use the points to drive your talk - do not expect the audience to read everything off the slides. You can annotate your slides with explanatory notes if you want to upload the slides somewhere for people who were not able to make it to your talk.
• Find out how much time you will have for your presentation, factor in the time usually taken up for questions from the audience and possible delays due to the previous talk and structure your presentation appropriately. You can have "checkpoint" slides in your presentation that you can use to gauge how well you are doing with respect to your plan.
• Use clear fonts (I personally prefer scalable sans-serif fonts) and use a relatively large point size. People in the back should be able to make out what is written on your slides.
  
• Spread your points evenly across a slide. Try not to list more than seven points per slide; use continuation slides to break up long lists of points.
  
• Use foreground and background colours that have create good contrast. Remember that what looks good on your computer under ordinary lighting might look quite different when projected on a big screen in a darkened room.
• Fancy transitions get pretty distracting pretty fast. Avoid them as much as possible except for things like progressively introducing the layers of a system, the phases of a handshake in a communication protocol, etc.
  
• Do not keep your hands in your pockets all the time (a worse habit is to move them about in there). Gesticulate while talking - it's sometimes hard to know what gestures to use, so observe good speakers while they talk.
• Make eye contact with the audience. Do not stare at a single person or throw fleeting glances at everyone. Hold eye contact with some random person for a little while, move on to another random person and so on.
• Try an ice-breaker in the beginning to make your audience comfortable with you instead of just diving into your presentation. Humour is the best ice-breaker in my opinion but it takes talent to pull it off well. Some speakers use a quick show-of-hands kind of surveys. For one of his talks in FOSS.in/2005, Andrew Cowie put on his DJ hat and played various high-tempo tracks from his playlist while the organisers arranged various things for the talk.
  
• It is usually not a good idea to declare "Feel free to interrupt me when you have a question". You will quickly discover that this ruins your flow and that there are several jerks out there who would ask a question just for the sake of it and to make their presence felt. You can pause your presentation at various "milestone" points instead and check if anyone in the audience has any questions to make sure that they understand the stuff being presented before moving on to other things.
• The people in the front row might just shout a question across to you instead of using a microphone. For the benefit of everyone else, repeat the question before answering it (possibly rephrasing it) so that they know what is being discussed.
• Ask someone to record your presentation and watch the video later. You will discover a lot of things you were saying or doing that you were not even aware of and some obvious areas for improvement. For example, the first time I saw a video of my own presentation I was dismayed by the fact that I had put on a pretentious accent for some reason, that I kept saying "Ok?" irritatingly often and that I kept my hands in my pockets almost all the time.
• Do not stand between the audience and the projection of the presentation slides obscuring their view.
  
• Depending on the nature of the presentation, it might be a good idea to distribute supporting material (brochures, printouts of the slides, etc.) before the presentation so that the people in the audience have a little background information or a take-home refresher. Printouts of slides can also be used by people (given enough space) to write notes corresponding to the slides.
• If you can help it, do not talk about something that you are not excited about yourself. You will very likely give a better presentation about something that you genuinely believe in and care for than otherwise.
  

I can go on and on like this, but most of these points are obvious if you have any common sense or if you observe a good speaker. You can also search the web for a great deal of material on presentation skills. If your company offers a training on presentation skills, take it instead of sniggering and dismissing it as something for "losers".

Finally, here are a few suggestions for presentation attendees:

• Please arrive on time. The cavalier attitude of most people towards punctuality causes unnecessary delays in starting a presentation and this has a cascading effect on the presentations following the presentation.
• Please do not ask questions merely for the sake of asking a question. Before you ask a question, ask yourself if the question makes sense, if the question is relevant to the current talk, if the question would require an answer that would be better off discussed in a post-talk chat with the speaker, etc.
  
• When you do ask a question, please use a microphone so that everyone else is able to make out what you are trying to ask. Please talk clearly and at a reasonable pace.
  
• When using a microphone, do not ask a question seated on your seat - it becomes very difficult for people to locate you. Stand up while you ask the question.
  
• Please do not come to a presentation merely to check emails, chat with friends, browse the web, etc. on your laptop using the wireless network made available by the organisers. It is being rude to the speaker and distracting to your neighbours.
  
• Please switch off your mobile phones during the talk or at least switch it to vibrating mode. If you absolutely must take a call, please leave the room and take it outside so that you do not disturb others.
• Try to be a bit discreet before walking out of a presentation - try not to walk out at all if you can help it. It is disheartening for a speaker to see people walk out of his presentation.
• Try to hold off on that urge to talk to your neighbour. It disturbs everyone else.
  

Once again, you would think that all of this is common sense but it is surprising how many people are willing to forget all of these when they attend a talk.

Books on C and C++

Tarandeep asked me what books on C and C++ I would recommend for someone who knows a bit of each of these programming languages. My problem is that I do not generally like reading books specific to a given programming language. In addition, I do not know C++ properly enough to be able to discern a genuinely good book on C++ from a mere pretender. He still insists that I write down a list of such books. I am therefore putting this list as a blog post in the hopes that people more knowledgeable about such things would help him out. We did search for such lists on the web but I was frankly not satisfied with the lists that we could readily find.

Here are the books on C that I would readily recommend:

1. "The C Programming Language", Second Edition, by Brian Kernighan and Dennis Ritchie.
   
2. "Expert C Programming - Deep C Secrets" by Peter van der Linden.
3. "C Traps and Pitfalls" by Andrew Koenig.
   

(See also: List of books recommended in the comp.lang.c FAQ.)

Here are the books on C++ that I think should be useful:

1. "The C++ Programming Language", Third Edition, by Bjarne Stroustrup.
2. "Effective C++", Third Edition", by Scott Meyers.
3. "Essential C++" by Stanley Lippman.

I did not particularly like Stroustrup's book, but it served as a useful reference when programming in C++.

By the way, many people do not like "The C Programming Language" but I am one of those who just love this book. It is a short book that is always to the point and has examples that teach you a lot about computer programming techniques and style. I agree that you should already know a bit about computer programming to fully appreciate this book. It was the book that I used to learn C. I love all of Brian Kernighan's books in general. He is one of the very few authors who have actually imbibed the lessons from "The Elements of Style".

In India, we have a few books on C and C++ written by some Indian authors that are terrible in my opinion but that unfortunately have been mandated as text books in several colleges here. The result is that many of the graduates who have not been exposed to other books form extremely warped ideas about these programming languages and about things like pointers. Sad.

Pricing Your Time

We often hear clichés like "Time is Money" or "Lost Time is Lost Money". Most of us generally agree with these assertions but do not actually try to quantify the money associated with our time. We therefore rely on our intuition or mood to decide whether it is worth it to do something ourselves or pay someone else to do it on our behalf.

For example, does it make sense for us to fill out the relevant form and file our income tax returns ourselves or should we just pay the fees to an agent who will do it for us?

Suppose the agent charges 200 rupees for this service, you drive a motorcycle that gives you about 48 kilometres per litre of petrol in city traffic conditions, the price of petrol is 55 rupees per litre, the distance to the income tax office is about 15 kilometres and the parking attendant there charges 2 rupees. If you were to file the returns yourselves (filing income tax returns online is not yet fully available in India), you will directly incur a cost of about 36 rupees in fuel and parking charges. Assuming that it takes about 15 minutes for you to fill the form yourself and about 60 minutes for the trip to the income tax office and back, is it worth saving this time and pay the agent an extra 164 rupees for his service?

A couple of my friends and I used to amuse ourselves by trying to calculate our time's worth using our salary as a guide. Assume that your annual salary is about 4,00,000 rupees, your employer expects you to work about 8 hours every day from Monday to Friday and grants you a leave of 15 days in a year. With about 52 weeks in a year, that is about 246 working days or 1,968 working hours. This means that your employer is willing to pay you about 203 rupees for every working hour.

So in this particular case, at least from your employer's perspective, it is better for you to pay the agent the extra 164 rupees that he is asking for rather than waste about 254 rupees in lost (hopefully productive) time.

Technically we should also consider other factors like the price we are willing to pay to save ourselves the effort (in addition to the time) involved in the task, the amount of trust we place in the agent to do the job correctly and on time, our willingness to share the information about our income with a third party, the amount of masochistic desire we have to do our job ourselves, etc. This is therefore a very crude measure of the monetary value of your time.

A professor of Economics has come up with another formula to calculate the monetary value of your time and you might have your own method of calculating this value. Whatever method you use, these methods can be used to quickly tell if it could be worthwhile to do something ourselves or pay someone else to do it for us.

(I wrote this piece purely for its amusement value - it should not be taken too seriously and should merely be used as an indicator in the spirit of Burgernomics.)

Superman Returns

I watched this movie over the weekend and was somewhat disappointed. The special effects were decent and more natural than in the original series of movies, as was to be expected, but the plot just had so many holes and the acting was so so-so that I was wondering how Bryan Singer and Kevin Spacey who gave us "The Usual Suspects" could have also given us this.

The New Yorker's Anthony Lane has written a far more eloquent critique of the movie than I can ever hope to write, but I would add that Brandon Routh is also about as good-looking as Christopher Reeve and is unfortunately about as wooden an actor. Of course, they are still nothing compared to Keanu Reeves when it comes to having a consistent lack of expressions throughout a movie. Perhaps having a chiseled good-looking face implies that your facial muscles are in a permanent rigor mortis.

There are some things that I would never understand about superhero stories. For one, why do they always have the same villain in story after story either as the main villain or as a willing aide to the main villain? Superman has Lex Luthor, Batman has the Joker, the X-Men have Magneto, He Man has Skeletor, etc. Do fans never get tired of seeing the same villains bugging their superheroes in episode after episode? Do they never wonder that if their superhero is all he is chalked out to be, why he is not able to get rid of this villain for good? Are they in fact aware of this irony and actively relish it?

Another thing that bugs me about superheroes is the need for almost all of them to have a mild-mannered alter ego. Why? And why can't other people recognise them in most of the cases? Clark Kent as the alter ego of Superman is particularly worrisome - does the addition of spectacles so change the facial appearance of a person that even someone close to them, like Lois Lane is to Superman, is unable to recognise them?

Yet another thing that really irritates me about superhero stories is the mess that all the hundreds and thousands of stories and story branches create. Again, Superman is the perfect example of this mess. Are there Supergirl, Superboy and Krypto, the Superdog, or not? Does Superman have a son or not? Has Superman died or not? Et cetera. What is the canonical Superman storyline?

Finally, why do most superheroes wear their underwear outside of their tights? What is it about superpowers that affects their sartorial sensibilities? In our college, a mild form of ragging involved the seniors making the freshers wear their underwear outside of their trousers, tying a bedsheet or a shawl around their neck as a cape and making them run down the corridors of hostels screaming "I am Superman!". Some of my friends would also remember our batchmate, who is now a banker in Bombay, running through the corridors of our hostel one night in an obviously inebriated state and clad only in an underwear and a bedsheet tied around his neck screaming "I am Superman!".

Separating Debugging Information

Debugging information in an executable usually takes up a lot of space so developers usually "strip" an executable before shipping it. This however makes it difficult to diagnose problems in your programme reported by the users, especially when a problem is only reproducible in the reporting user's environment.

Microsoft's development tools support creating a separate "Program Database" (PDB) file for an executable containing debugging information for the executable. Its diagnostic tools support reading a PDB file for an executable , if one is available, to generate a more usable diagnostic report for a fault. You ship stripped executables to your users and when they report a fault, you ask them to install the corresponding PDB files to help you get a better diagnostic report. I think that this is a nice idea and I used to wonder if the GNU toolchain would ever support something like this.

Danny Smith pointed out to me that something similar is already supported by recent versions of GDB and binutils. You can use the --only-keep-debug option of objcopy for this purpose. For example:

gcc -g hello.c
objcopy --only-keep-debug a.out a.dbg
strip --strip-debug a.out

a.dbg now has the debugging symbols and a.out has been stripped of debugging symbols. When you want to debug a.out you can use:

gdb -s a.dbg -e a.out

Simple.

Tales of Human Resources

In an organisation that I once worked for, the Human Resources department was particularly prone to engaging in activities and issuing diktats that were rather Dilbert-esque. Here I recount a couple of egregious examples of this behaviour that unnecessarily damaged the careers of several employees for absolutely no fault of their own.

At that time, the employees in that organisation were awarded grades every year reflecting their perceived performance based on appraisals by their peers, their seniors and anyone working under them. The grades ranged from A (exceptional) to D (unsatisfactory) and affected how much of a hike in salary (if any) you get when the next round of salary hikes takes place. They also affected the chances of your promotion.

Someone in the HR department read somewhere that the distribution of these grades in a large organisation usually follows the bell curve of a normal distribution with a few employees being graded exceptionally good or marked unsatisfactory and most employees being graded good or merely satisfactory. This person then made the leap of logic in deciding that the distribution of these grades must necessarily look like a bell curve and that too for each team in the organisation!

Needless to say, this had a very bad effect on some teams and our team was affected especially badly. Our team was assembled by hand-picking the best people from a lot of teams across the organisation to work on a particular project that the company perceived to have a lot of potential at the time. It was natural for almost everyone in the team to perform well and the managers mostly awarded Bs and As. The HR department, of course, would have none of this. The distribution must be "normal" across the team and all the pleas of the managers fell on deaf ears. The result was that some of our team members were awarded a D even though they had done good work throughout the year! This had a predictable effect on employee morale. A lot of people from the team left the company very soon.

The same organisation also had an unwritten rule of letting go of the bottom 5% of the employees of the organisation every year judged by their performance. The merits of this kind of a rule is, of course, debatable but once again a diktat from HR made it even more damaging. They decreed that every team should let go of the bottom 5% (rounded up to the nearest whole number), irrespective of whether there was actually anything unsatisfactory about the affected employees. Once again managers pleaded in vain with HR and were helpless as useful team members of a project were unnecessarily laid off. The crazy thing is that hiring continued to go in full swing during this period. Some managers thought they could take advantage of this and hire back the laid-off workers but HR nipped their plans by reminding them of the policy that an employee could not join the company after leaving it for a period of at least six months.

These incidents were not only devastating for the morale of the employees directly affected, but they were also depressing for the rest of us. Ironically, one of the purported aims of the HR department was to devise ways of boosting employee morale. Their actions however had the exact opposite effect.

Rolling in Money

"Is Indian IT getting too expensive?" is an article in The Times of India that is a perfect example of the reckless and utterly irresponsible journalism that is increasingly becoming the norm for this newspaper. While the general thrust of the article is more or less correct, either the reporters in question or the "analysts" they consulted seem to have simply made up all these numbers. Believe me, it is not at all the norm to pay a guy with 10 to 15 years of experience an annual salary of 1.5 to 2 crores Rupees (about 330,000 to 440,000 USD)! The numbers are off by about an order of magnitude. I also think a salary of 70,000 USD for a middle-level manager in the US as stated in the article is a bit on the lower side, though I cannot be sure. As a couple of us were joking upon reading this article, these guys should have published the names of the companies which supposedly pay such salaries so that all of us can apply for a job with such suckers. On the other hand, such a company will not last long because it will quickly drain out its cash reserves doling out such largesse.

Unfortunately, these are precisely the kind of stories that unnecessarily widen the divide between software engineers and other sections of the society. They also unnecessarily make software engineers a lucrative target for robbers and other criminals. They create frustration among gullible engineers who think they are never paid enough for their job, even if they are already being paid far more than they deserve. They cause engineers returning to India from the US and elsewhere to demand really outlandish salaries for a job.

Pathetic.

Mathematical Digressions

In my previous post, I said that the sum of the geometric series:

1 + x + x² + ... + x^n-1

is (xⁿ - 1)/(x - 1). One of my beliefs (as also shown by that post) is that you should never take a formula at its face value. Here I quickly attempt to show why this particular formula should be correct using a very commonly used proof. Let us assume that S denotes the desired sum. That is:

S = 1 + x + x² + ... + x^n-1

If we multiply both sides of this equation by x, we get:

x×S = x + x² + x³ + ... + xⁿ

If we subtract each side of the first equation from the corresponding side of the second equation we get:

(x - 1)×S = x + x² + x³ + ... + xⁿ - 1 - x - x² - ... - x^n-1

This simplifies to:

(x - 1)×S = xⁿ - 1

which gives:

S = (xⁿ - 1)/(x - 1)

as we had claimed.

By the way, while attending a conference call last night where it was particularly hard to concentrate on what was being discussed, I began to doodle and stumbled upon a simple result which might have been interesting about a millennium ago and is probably just an idle curiosity now. I am also sure it is contained somewhere in our high school text books for mathematics, but I cannot recall seeing it before. (Despite what might be indicated by these blog posts, I do not have much of an interest in mathematics itself and have never pursued it for its own sake.)

Anyways, looking at the factorisation of (x² - y²) into (x - y)×(x + y) and (x³ - y³) into (x - y)×(x² + x×y + y²), I wondered if (x - y) is always a factor of (xⁿ - yⁿ). By playing around a little bit with the terms, I could write:

xⁿ - yⁿ = (x - y)×(x^n-1 + x^n-2×y + ... + x×y^n-2 + y^n-1)

confirming my hypothesis. If you set y=1, this reduces to:

xⁿ - 1 = (x - 1)×(x^n-1 + x^n-2 + ... + x + 1)

which can be rewritten as:

(xⁿ - 1)/(x - 1) = x^n-1 + x^n-2 + ... + x + 1

which is the same formula that we derived just a while back for calculating the sum of a geometric series!