Meet the new Blog, same as the old Blog
As you can see, I finally bit the bullet and moved my blog to my own domain. I plan to do the same with the website (it's still being hosted at Galileo University). The website needs a lot of work. It' still so... twentieth century!
The blog is now running on WordPress and I have to admit it was trivial to install. The admin interface is also pretty decent.
My one complaint is that the WYSIWYG editor that they ship seems to mangle my HTML pretty bad, to the point that I have to use Emacs to fix it, so I won't use it.
One big improvement is that the code snippets now have syntax highlighting. Awww, look at those beautiful colors. I'll be posting more code snippets now that looking at them doesn't hurt my eyes.
Well, that's all for today. Don't forget to subscribe to the new RSS Feed and to cancel the old one. I won't be posting to blogger anymore.
Code Tells You How
Revision History Tells You Why
I had a little rant on commenting style and it seems that Jeff Atwood has beat me to it. Well, here's my rant anyway.
There are three different components I care about when reading code: "The How", "The Why", and "The What".
"The How" is the code. The very essence of code is to tell the computer how to do something. It's not 'what' to do, because that is open to interpretation, you might be trying to do something (what) and telling the computer to do something else (how). I don't need comments for the how, I can read the code. An example of a bad "how" comment is:
/* assign 0 to all flags */ for (i = 0; i < length; i++) things[i]->flag = 0;
I can see you're setting all flags to zero. Thanks for the non-information.
"The What". This is the interpretation of "The How". Basically, it's what that code is trying to accomplish. For instance:
/* clear all flags */ for (i = 0; i < length; i++) things[i]->flags = 0;
At least now I know what zero means. But it still doesn't tell me a lot. As a matter of fact, it's rare when I need to know "The What". If I need comments to know "The What", the code is probably poorly written. I should be able to infer "The What" from "The How".
"The Why". This is what I really care about. Why is this piece of code like this? Why not some other way? What was in the programmer's mind when he wrote that piece of code? What alternatives were considered and discarded? Why were they discarded?
/* We're on a deadline and I don't understand why the flags * array is getting corrupted. Clearing all flags seems to * fix it, but there is a deeper issue here that needs * investigating */ for (i = 0; i < length; i++) things[i]->flags = 0;
Ah, much better now. I've gained some insight into the programmer's mind, so later when I'm working on the code I can make sense of this line. Basically, I can answer the question: "Why was this added?"
But wait, there are problems with this approach.
First of all, you're using up 5 lines of comments for 1 line of code. That's verbose, but not the worst of the problems.
What's worse is that if I'm just skimming the code because I'm trying to solve some other problem for which I don't really care about this particular line, you're going to make me stumble. I'm going to read that comment, remember that I once knew of a way in which the flags could get corrupted and spend the next 1/2 day chasing an issue that has a workaround. Your nice comments are on my face when I don't need them.
Even worse, this style also leads to comments needing maintenance. The code will change, and the comment won't be updated with the change. You'll get
/* We're on a deadline and I don't understand why the flags * array is getting corrupted. Clearing all flags seems to * fix it, but there is a deeper issue here that needs * investigating */ for (i = 0; i < length; i++) { if (things[i]->flags & FLAG_INIT) things[i]->flags = 0; }
Whoa there buddy! You're saying that flags were getting corrupted and now you're using them? How can you trust them? Either the comment is wrong or the code is wrong.
What probably happened was that some programmer didn't read the comment (or read it but forgot to change it) and found a convenient place for putting his change. Now understanding this piece of code has been made harder than it should be.
And all of this is just looking at code statically. Code is organic, it grows, it changes, it evolves.
There aren't a lot of comments in the BitKeeper source base because we rely heavily on the Source Control system to answer the "Why" questions. So you'll see the above code as:
for (i = 0; i < length; i++) things[i]->flags = 0;
No comments whatsoever. However, if you need to understand what was going on, you can get the annotated version:
ob 1.123.21: for (i = 0; i < length; i++) things[i]->flags = 0;
and see the comments for the ChangeSet 1.123.21:
ChangeSet@1.123.21, 2006-07-21 10:45:34, ob +1 -0
Fix bug 2004-10-21: app crashes when restarting
src/main.c@1.23, 2006-06-29 19:40:46, ob +1 -0
We're on a deadline and I don't understand why the flags
array is getting corrupted. Clearing all flags seems to
fix it, but there is a deeper issue here that needs
investigatingNow the information is there, but it's not in my face unless I need it.
Note that when looking at code this way, the question "What changed?" is trivially answered by the diffs and therefore doesn't need to be answered by the comments. E.g. the following are really bad comments:
src/main.c@1.23, 2006-06-29 19:40:46, ob +1 -0 Add code to clear the flags
Well, duh! I can see that from the diffs!
@@ -274,6 +278,7 @@ things = getThings(x, y, z); length = getLenght(things); + for (i = 0; i < length; i++) things[i]->flags = 0; doStuff(things); }
I can see that you added code to clear the flags, why did you do it? That's the interesting bit.
Technorati Tags: BitKeeper, Programming
Spotlight (part deux)
After reading some comments about how Spotlight just works for other people, and talking with some friends that have Spotlight turned on, I started doubting that it was so bad. It turns out that when I got the MacBook Pro, I transfered about 40 GB of stuff from my old laptop, and apparently it also transfered a corrupt Spotlight Index.
So after running:
# mdutil -E /
and turning Spotlight back on, I'm no longer seeing the performance problems I had. All thanks to the comments. And I didn't think anybody read this blog :)
Spotlight must die (or get its act straight)
I just got a new MacBook Pro, and had it for about a week. What I discovered was that the machine wasn't as snappy as I thought it would be. It's a CORE DUO for Christ's sake, it has not one, but TWO cores, it has 2 GB of freaking RAM! It should be the fastest box around! But no, it's slow and every once in a while it just locks up for about 5 seconds.
After some fun with fs_usage trying to figure out what was going on, I found the culprit: Spotlight. See, spotlight interacts VERY VERY badly with the file system cache, and since Mac OS X has a unified cache, with the VM cache. This means that while the OS is trying really hard to keep your working set in memory, spotlight (a.k.a. mdimport) is indexing stuff and therefore causing unnecessary flushes of the cache.
The solution? Turn it off. Just run 'mdutil -i off /' and edit /etc/hostconfig to set "SPOTLIGHT=-NO-" and be done with it. Or if you don't want to even type that, get Spotless and click away. Go ahead, I'll wait.
The problems? Mail no longer searches, and no easy and quick way to launch applications. I installed QuickSilver for the application launching part, and will figure out if I can find an alternative for searching mail. But it's worth it.
My machine is SUPER FAST now, and the disk is quiet all the time. Processors are mostly idle if I'm not doing anything, ah the sound of a high performance machine...
How badly does Google Desktop Search hinder performance under Windows?
Technorati Tags: macos x
A nerdish way to spend an evening
- Get a laptop
- Install stellarium
- Go outside and bring:
- binoculars or a telescope if you have one
- a bottle of wine (or beer)
- cheese
- a blanket
Try a spot where there are no lights. It's hard if you're in the city, but it's really nice when there is darkness around.
Launch stellarium, see the sky. Enjoy.
I’m human, so sue me
Developers 'should be liable' for security holes - ZDNet UK News:
Making developers liable for security exploits is a stupid idea. The first problem with it is, who do we blame? Most of the security bugs nowadays are not your typical buffer overflow kind, which could have been prevented with careful programming. Most of the security bugs today have to do with interactions between system components. Let me explain.
There are two kinds of bugs, security or otherwise. Bugs that reflect the programmers lack of knowledge of a well established coding practice or API usage, and bugs that unless you have actually written the same code before in the same circumstances, you could not have predicted would occur.
If a web programmer takes a string from a user in a web form, and then passes that string unquoted to a shell, that programmer shouldn't be allowed within 15 feet of a web app. If a programmer writes a piece of code that interacts with other pieces of code, and the resulting interaction has a bug (which might be exploitable), we have an interaction bug. It's one of those "How could I have known?" moments we've all had. And if you sit and think about all the possible interactions before writing any code, you never get anything done.
What about liability? Assuming you have a sensible version control system in place, you can ask the question "Who wrote this pice of crap?" and get an answer. But who do you blame when the security bug is a result of a combination of changing APIs, implementing new features, fixing old bugs, etc. The answer to "Who wrote this piece of crap?" is "a group of programmers working at different times". For the web app example, some of the code might have been written when it wasn't a web app at all. There is human history in the code. It was written by humans.
And humans make mistakes. There is no way to avoid that. We just screw up every once in a while. Depending on how much you have to pay for your mistakes, you might be afraid of doing anything daring again. For instance, if I write a little application (single author, so all the bugs are mine), and get sued because it has a security bug, guess how many more applications I'll be writing. None. The cost of making a mistake is too expensive.
If companies are liable, you're just moving the problem to management. Companies get sued, so they are hesitant to put new applications out there. Applications that are not being used are not being debugged, and are thus less secure.
Markus Ranum wrote a great piece about this subject called Inviting Cockroaches to the Feast. It's a very good read.
First BitMover Regatta
Last week we had the First BitMover Regatta. On Tuesday, BitMover rented a bunch of sailboats, and a group of employees raced across the San Francisco Bay. It was my first time on a sailboat, and I had an excellent time. I had been on a Yacht before, deep sea fishing, but sailboats are an entirely different experience. Now I understand why Evi is sailing across the world. Sailing is too cool.
At around noon, we drove to Sausalito, where the sailboats were waiting for us in the dock. We divided in 3-person teams, and each team got a sailboat and a skipper. The skipper's role was giving us directions and basically taking care of us since not many 
people had sailed before. At the dock, we found our sailboat, a 42-foot Bēnēteau 423. The Bēnēteau 423 was one of the top 10 sailboats of 2003 according to Sail Magazine, and it's price is around $165,000. Not bad at all! Upon boarding the sailboat, we met Stan, our skipper, who had been in the Coast Guard for 20 years before becoming a sailing instructor for the Modern Sailing Academy in Sausalito. He explained all the boat terminology (port is left, starboard is right when facing the ship's front, or rather, the bow). And taught us how to work the sails. We used the motor to get out of the docks, hung around the start line until the race started, and set sail towards San Francisco.
Stan asked for a volunteer to take the helm (steering wheel) and I immediately stepped forward (knowing that working the helm would be easier than pulling all the
ropes). Since I had never been in a sailboat, I didn't expect it to lean that much. It's a little scary at first, but I was assured by Stan that they don't tip over under normal conditions (i.e. not in a hurricane). Driving that thing was fun, but it required a lot of attention. Basically if you let your attention drift for 10 seconds, you would slightly change course and lose the lift. If you lose the lift often enough, your skipper can order a Keelhauling, which I've been told is not pleasant. I must have done allright because we were going at about 3 knots towards San Francisco.
It took us a while to find the buoy where we were supposed to turn, but after a while, we found it and headed towards the bay bridge. We were going with the wind, which is really cool because you can go really, really fast. The course took us around Alcatraz, the famous prison where Al Capone was an inmate.
Seeing Alcatraz up close was quite a thrill. I have wanted to go to Alcatraz since 1994, when I first visited San Francisco, but because of various reasons, I have never taken a tour of "The Rock". After we went around Alcatraz, we headed back towards Sausalito, and the finish line. During that last segment, even though we were going more or less against the wind, we did a pretty good time. We won the race, crossing the finish line 7 minutes before the next sailboat.
We didn't have to return the boat until 5:00 pm, and we crossed the finish line at around 4:00 pm. What could we do in an hour? Well, that wasn't a hard decision, we convinced our skipper to take us to the other side of the Golden Gate Bridge. We set sail and managed to go
to the other side. It was amazing being under the bridge. We got a little taste of the ocean too, with a slightly rougher sea than what the bay had been. After a quick turn, we got back to the dock, returned the sailboat and called it a day.
Once we were in the land again, we were tired and hungry. We headed to the Buckeye Roadhouse in Mill Valley for dinner, and what a dinner we had! If you ever go to the Buckeye, try the Ahi tuna appetizer. It's unbelievably good.
After this first taste of sailing, I'm left wanting to learn how to sail. Who knows, maybe when I retire, I'll buy a sailboat and follow Evi's course around the World.
Technorati Tags: BitKeeper, BitMover, Sailing, San Francisco
Yet Another Stupid Idea
Single-play DVDs will never work, at least not for the rental market. Not only because they require new players, and of course the first thing I will do is get a new DVD player so that I can watch the new rentals only once. But because they don't interact well with how people watch movies. I often fall asleep while watching a movie, how would I see the ending? How about that phone call, or little emergency right in the middle of the movie? Or when I don't have 2 hours to watch the entire movie, but I'm willing to see 30 minutes now and the rest later?
People rent because it's more flexible than going to the movies. Taking away from people the flexibility of renting without giving them any of the advantages of movie theaters is not going to fly.
Unix died in 1982
If you look at this time history of Unix, you can see how after 1982 Unix became practically impossible to support. I mean, who was going to worry about compatibility between so many different flavors of Unix. I'm glad the list is short again in 2005. Now if only the GUIs had a standard ;-)
Judge this Book by its Cover
Or, how I learned the history of the computing industry and Unix by looking at the cover of a book.
Here's the deal. For reasons best left unexplained, I have every edition of the Unix System Administration Handbook by Evi Nemeth, et al. I even have the Linux System Administration Handbook. Since every book's edition is a different color, my daughter likes to play with them. The other day, while putting them back on the shelf, I noticed that the cover of the book reflects the history of the computer industry, the history of Unix, and a little history about Evi. So without further ado, here's my explanation of what it all means. You'll have to excuse the quality of the images, but I don't have a scanner so I took digital pictures.
Unix System Administration Handbook, 1st Edition
This book was published in 1989. We see that UNIX system administration is a difficult topic. There is a Unix system administrator driving his car towards a cliff. I don't know what the reference to cranberry bogs is about, but let's focus on the colorful characters.
Starting rom the left, we have a dog named biff, which is a reference to the biff(1) command in Unix that prints a message to your terminal when you have new mail. In the center is a daemon, a Unix process that runs in the background. Since the daemon is showing us his watch, maybe it's the NTP daemon? At the right of the daemon, you can see the finger(1) command, used to find information about a user and made famous by the Great Worm of '88. I don't know what the other two characters (the owl, and the cat, or is it perhaps a lady daemon?) are about. If anyone knows, or has a guess, let me know.
Unix System Administration Handbook, 2nd Edition
In the second edition, published in 1995, biff is dead (you can see the gravestone that says "R.I.P biff R.I.P"), probably replaced by POP. The cross behind reads "USL" and is a reference to the Unix System Laboratory at AT&T, the group responsible for System V, which had been sold to Novell in 1993.
In the front of biff's grave, it says "Here lies the entire Berkeley CSRG". That means the Computer Science Research Group, which was responsible for the development of the Berkeley version of Unix, called BSD, at the University of California and was disbanded in 1994.
The first edition of the book is being held by the paw of a cat. We can tell it's the first version because it's yellow, and it says "USAH", short for Unix System Administration Handbook.
The dog, Biff, is now gone from the front row. He's dead, remember? And has been substituted by a Monkey, a spider, and a Web. I don't know what the monkey has to do with anything, but the web is clearly a reference to the World Wide Web, which was invented in 1993. The spider is clearly a reference to the web spiders, or bots that search engines use to index web sites. We can still see the daemon, the finger, and a new character, Dr. SNTPd, a reference to the Simple Network Management Protocol.
Note that the car is more modern, and it has the word "Unix" written on the front. Also the System Administrator behind the wheel appears to be a woman. Could this be a reference to more women in system administration?
Unix System Administration Handbook, 3rd Edition
The third edition, published in 2001, has many of the same symbols as the second edition. In this edition, however, there's a new tomb. The Unix to Unix Copy Protocol, or UUCP, has died because most people use PPP by now. We can also see the second edition coming out of the grave being held by a tentacle.
Two more things should be noted. First, this is the first edition of the book to cover Linux, a newcomer to the Unix world, and you can see the Penguin in the co-pilot seat of the car. Also, the spider now has handcuffs, which might be a metaphor for the restrictions many sites started putting in place to prevent search engines from finding them.
Linux System Administration Handbook
This book came out in 2002, and was made specifically for Linux, which had by then surpassed in popularity all of the other Unix distributions. You can see the Linux Penguin driving now, and the sys admin as the co-pillot.
The spider's handcuffs have been replaced by a shackle, meaning the restrictions on spiders are greater now. The other books are gone, as Linux has been declared the only winner.
You can also see that the sign that used to read "Beware! Vendor Gratuitous Changes Ahead!" has been replaced by one that has Unix somewhat deviated, but still going up, Linux going straight up, and XP (a reference to Windows XP) going down. The helicopter that is crashing also has XP written on it. The authors have no love for Microsoft's Operating System.
There is also a penguin skiing on the mountain. I have no idea what that means.
The last interesting bit is that there is a sailboat in the back. Let's take a closer look at that sailboat.
See the name on the boat? It's the name of the main author of all the books, Evi Nemeth, who is now retired and sailing across the world.
Cool, isn't it? Robert Langdon isn't the only one that can find hidden symbols everywhere.
These are really good books by the way. You should probably get a copy of the Linux version.