Vive la différence

December 7th, 2007

One of the more useful programs in the developer’s toolkit is diff. This little utility compares two files and gives you just the differences (what changed) between them. Evey version control system in the world is ultimately based on diffs.

One way I commonly use it, is to see what I’ve changed in a file or a set of files. Let me clarify. I put everything in version control. Even tiny little programs that I’m tempted to throw away are in version control. Being able to use diff between my modified file and the previous version is a major reason for doing so.

Now, if I told you to quit your editor and run diff in a terminal, I wouldn’t be surprised if you decided to beat me with a clue stick. You should NEVER leave your editor. If you do, you don’t know how to use your editor, or your editor is not powerful enough. If your problem is the latter, you should switch to Emacs right now. Otherwise, keep reading, I can help you.

Depending on what version control system you use, you should modify the commands given below. I use BitKeeper (well, duh!), so all my examples will use that one.

To start with, stick this in your .emacs:

(defun bk-diffs ()
  "Get diffs between current edited buffer and checked in revision"
  (interactive)
  (let* ((filename (buffer-file-name (current-buffer)))
	(newbuf (get-buffer-create
		 (format "%s diffs"
			 (if filename (buffer-name) default-directory)))))
    (set-buffer newbuf)
    (if buffer-read-only
	(toggle-read-only))
    (erase-buffer)
    (insert
     (shell-command-to-string
      (if filename (format "bk diffs -uph %s" filename) "bk -r diffs -uph")))
    (switch-to-buffer-other-window newbuf)
    (diff-mode)
    (beginning-of-buffer)
    (diff-hunk-next)
    (toggle-read-only)
    newbuf))

Now, whenever you are in a file and want to modify it, all you need to do is run the command bk-diffs and you’ll get something like this:

Emacs diff mode screenshot

Cool, eh?

The command is also context sensitive, so if you run it from a buffer where you’re not editing a file, e.g. a dired buffer or a shell buffer, it will run a recursive diff and give you diffs for all the files. I use this all the time when I go back to repositories I haven’t touched in a while. It’s my “what the hell was I doing?” command. The output looks something like this:

Emacs diff mode screenshot 2

That’s not all. I have more tricks for you. First of all, navigation:

n or M-n Move to the next hunk
p or M-p Move to the previous hunk
M-N Move to the next file
M-P Move to the previous file

If you are an old school hacker and would rather see context diffs than unified diffs, you can hit C-c C-d while in the diffs buffer. To go back to unified diffs, hit C-c C-u.

There are also key strokes for going back to the source file from the diff buffer. Pressing Enter or M-o or C-c C-c will take you to the equivalent line (or thereabouts) in the source file from which the diff was taken.

Ok, that is useful, but I see you’re not blown away. The truth is, I saved the best part for last. Once you’re walking the diffs one by one, you can also press C-c C-a to either apply, or revert a hunk! How cool is that eh?

This last feature is something I use all the time to clean up a file before checking it in. E.g. I sometimes have a bunch of debug code or comments to myself that need to be removed before checking the file in. Rather than review the file by hand, I can go through the diffs and use the quick navigation that emacs provides for doing the clean up.

Finally, if you are a CVS user (I’m sorry, really. You should switch to something else), you can probably still use it inside vc-mode, hit C-x v = to get the diffs and try the keystrokes I mentioned.

Beautiful Emacs

December 5th, 2007

When you spend all day looking at code, it’s important to select a good editor font. Obviously, the font needs to be monospaced or the alignment will be all wrong. Well, there are only a handful of monospaced fonts worth looking at (and Courier is not one of them).

Take a look at the following image. Click on it, and pick your favorite of the four fonts.

Different fonts in Carbon Emacs

These are the fonts in the image, clockwise from the top left corner: Bitstream Vera Sans Mono, Andale Mono, Monaco, and Inconsolata.

Bitstream Vera Sans Mono is my second favorite. It’s the font I use on my web browser. However, for editing code, I find it a bit too heavy. This probably has more to do with my color scheme than the font per se, so your millage might vary.

Andale Mono is very readable, but I find the spacing all wrong and somewhat distracting. Look at the word “String”, the letters seem too far apart.

Inconsolata is my personal favorite. You need to crank up the font size because it seems to be a smaller font than the rest. I thought that point sizes were supposed to be standard, but apparently I was wrong.

Monaco is the default in Mac OS X, but it looks kind of silly. I used to use whatever was the default, so I’ve used this font quite a while. I never did mind it, but once I made the switch to Inconsolata, I can’t stand it anymore.

If you want to play with different fonts in Carbon Emacs, you can enable mac keys by running the (mac-key-mode) function, and then pressing ⌘T, which will open a standard font dialog.

However, if you want to use Inconsolata as your default font, put this in your .emacs

(require 'carbon-font)
(fixed-width-set-default-fontset
       "-apple-inconsolata-medium-r-normal--14-*-*-*-*-*-iso10646-1")

It took me a while to figure out how to change the font on Carbon Emacs, so I hope that even if you don’t choose Inconsolata as your preferred font, this information might prove useful.

Norton Fighter

December 5th, 2007

And on a lighter note… I found this clip hilarious.

Part 1:

and part 2:

If I used Windows, I’d buy norton antivirus just because of this ad.

Timeo Facebook et dona ferentes

December 5th, 2007

Which can be loosely translated as “I fear Facebook even if it brings gifts”. My friends have noticed that for quite some time I’ve stopped updating my Facebook status, or even interacting with the site altogether. The reason is simple. I don’t trust them.

A short time ago, Facebook introduced a new feature called “Beacon” that lets websites send status to your mini-feed. It immediately drew a lot of criticism because of its invasion to privacy, to the point that many people figured out ways to block it. Facebook’s CEO apologized for it today and made beacon opt-out.

Now, I was going to write a detailed article about why this bothers me and how insincere the apology sounded, but our good old friend Fake Steve Jobs did a much better job in this blog post. Money quote:

These guys are like Google, only their slogan isn’t “Don’t be evil” — it’s “Don’t get caught.”

And later:

The smarmy fake apology is not at all reassuring and seems to have been written by PR people who were trying to imitate a 23-year-old kid who’s speaking from the heart and trying to sound all sheepish and aw-shucks — except the flacks can’t do it because they’re as insincere and stage-managed as as the Facebook guys. Plus, let’s face it, the flacks are getting paid in Facebook equity, right?

I couldn’t have said it better myself. You should go read the whole post.

The Apple Experience

October 1st, 2007

Last week I was once again sucked into the argument of whether Apple is a hardware company or a software company. My take on it: it’s neither.

Apple is an “experience” company. They do hardware because it’s the only way to have the software under control. They do software because without good software, the hardware is useless. What they ultimately worry about is the user experience.

They partnered with AT&T because they needed to add the cellular network to the experience and they couldn’t build their own (they would have loved to). If they look like control freaks from the outside it’s because, well, they are.

On that note, in this piece, Saul Hansell argues that AT&T allows applications on other phones, except the iPhone. Saul claims that Mark Bercow, senior vice president of business development for Palm, encourages developers to do pretty much as they please with the Palm Treo:

Indeed, some developers have made video streaming applications, a particularly big bandwidth hog. (Of course, the cellular companies are free to charge whatever they wish for bandwidth use.)

Now go to the AT&T website and try to find their data rates. I could find a $24.99 data rate that was limited to 10MB, and an unlimited plan (with some fine print about per-kilobyte charges) for $69.99. That is in addition to the cost of the plan. The iPhone unlimited data plan is $20 per month. So while developers can create apps for any other AT&T phone, customers get charged per kilobyte. Now consider again what Steve Jobs said about third-party apps:

You need it to work when you need it to work. Cingular doesn’t want to see their West Coast network go down because some application messed up.

My take on that is that AT&T doesn’t want to see their network swamped with data transfers without being able to charge for them. However, a per-kilobyte service plan would have totally ruined the iPhone experience for the users. Apple wanted users to experience having a device that is always connected to the Internet. That experience is ruined if you’re worrying about how much you’re accessing the net because your service provider charges you per-kilobyte.

The reason Apple is so successful is because using their products is a pleasurable experience. That’s their trick, they think about the “experience”.

Meet the new Blog, same as the old Blog

July 27th, 2007

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

December 20th, 2006

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
    investigating

Now 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: ,

Spotlight (part deux)

June 13th, 2006

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)

June 1st, 2006

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:

A nerdish way to spend an evening

October 12th, 2005
  • 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.