I forget when I learned about special relativity, sometime in Junior or Senior High School, I think. I always had the most basic of understanding. At some point, I read Stephen Hawking’s A Brief History of Time and I understood a bit more.

For some reason, my web meanderings today took me to a Wikipedia article on the Twin Paradox. What always confused me was to think what images each would see if the twin on earth had a telescope trained on the spaceship and vice versa for the twin on the spaceship. Well this Minkowski diagram explains the whole thing. Wow.

Read the whole article if you were still unclear on the whole Twin Paradox thing.

Excellent DVCS Analysis: http://code.google.com/p/support/wiki/DVCSAnalysis. In summary:

• In terms of implementation effort, Mercurial has a clear advantage due to its efficient HTTP transport protocol.
• In terms of features, Git is more powerful, but this tends to be offset by it being more complicated to use.

I’ve adopted Git for my own personal use, though have recently learned that there is a whole family of distributed version control systems. After reading this article, it made a lot of sense for Google to adopt Mercurial, but left me satisfied that Git is a better tool for my personal use. Still, it probably makes sense to spend a little time with Mercurial and a few of the other systems because you never know when a little bit of knowledge can help you out of a bind.

This is a great tutorial on tools I’ve never used (aside for the clone stamp tool, of which I’m very familiar). Check it out!

I posted a few of these over the years, this one is the most crisp and well-done of the ones I have seen:

Recently, I started to realize that pages were taking a long time to load. When I finally became conscious of this, I looked into it. DNS resolution was tasking forever. After a few weeks of ignoring the problem and playing tricks with my provider’s router, I decided to Google my way out of the problem. Sure enough, googling led me to Google’s Public DNS Servers. There are two, 8.8.8.8 and 8.8.4.4. I set up my router to use these and kept my machine configs simple, whereby they specify the router (192.168.1.1).

This still worked like crap.

So, I went and changed every one of my machines to use custom DNS, changing network settings from 192.168.1.1 to 8.8.8.8/8.8.4.4. Viola, DNS lookup is now instantaneous. This has already made a HUGE impact on the user experience. The speedup is really kind of miraculous and I’m frustrated that I even had to deal with it.

I made sure to change  the DNS config on both the wired/wireless connections for my laptop, too.

If you have similar problems, try the Google Public DNS Servers. The extra configuration might be worth it.

The concept is interesting and well-formed, but in order to earn better
than a C, the idea must be feasible.

- A Yale University management professor in response to Fred Smith’s paper proposing reliable overnight delivery service. Smith went on to found Federal Express Corp.

I had always wondered how to send HTML e-mails—you know, the ones with embedded pictures, css, and specialized formatting—from my Gmail account but could never figure it out. Perhaps Gmail prevented this to make sure people didn’t use their Gmail accounts as a source of SPAM. Who knows. I googled, too, yes I did. Still nothing.

Then it hit me. Create a Google Document and e-mail that. At first, this didn’t seem like it would work because the e-mail option under “Share” said, “Email as attachment…”. But when you click on that there is an option to simply paste document into your message.

Viola!

THIS is a great read. Best tutorial I’ve seen. Concise and right on the mark.

http://www.eecs.harvard.edu/~cduan/technical/git/

After a few months, I started to understand those under-the-hood concepts. Once I did, suddenly everything made sense. I could understand the manual pages and perform all sorts of source control tasks. Everything that seemed so cryptic and obscure now was perfectly clear.

The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.

I’m still at the memorize the commands phase, but getting there.

I’m an avid fan of git, a great open-source version control system. I wrote a little bit about how I use my website as a private repository before. Now, I’m going to show you how to  integrate it with Perforce.

Working with Perforce as a remote repository functions in a similar way to using svn or cvs as a remote repository. And, for that matterm semantics are pretty much the same when git itself is the remote repository (such as github.org). I’ll assume you’re already familiar with Perforce and the directions that follow are specific to Linux, work on the Mac, and I imagine minor tweaks would be necessary for Windows.

Start off with your default p4 depot on your local drive. When working in git, you won’t be working in that folder on your OS mount. Rather, you’ll work in a clone repository.

On my linux box, my depot is at ~/sandbox/nick. My perforce client-spec is defined as: //depot/sandbox/nick/… //nick-machine06/sandbox/nick/… . Next, the command I will show you will also import revision history from Perforce. To do this, you need to create a clone of this repository that git will interact with. Simple:

[nick@machine06 ~]$ git p4 clone //depot/sandbox/nick@all sandbox.git

I believe the @all instructs the git-p4 commant to import all history for the imported files. This command creates a new directory on my root alongside my p4 depot:

~/sandbox (p4 depot)
~/sandbox.git #git's repository

When making changes via git, you work in ~/sandbox.git and submit to ~/sandbox. Here is a set of operations that edit a file and submit to the master branch:

vi ~/sandbox/nick/python/delempty.py
# make a change
# save the file
# notice I didn't "open" the file for edit. It's just a file, edit it. Git will detect changes when you submit.
git commit -a
# this will commit change to git repository

Then, the git p4 command submits the latest batch of changes to Perforce. It opens the files for editing in the P4 depot, creates a changelist, and submits.

git p4 submit

This will push it to perforce. It knows to do this because the “remote repository” (~/sandbox) is known to this git repository as it’s configured in hidden config files. Same works for cvs, subversion, and other git remote repositories.

Much of what I wrote here was learned from a thread over at kerneltrap.org. A colleague at work helped me work out the remaining bits. Thanks Dan! At some point, I’ll write about how developers can submit batches of code seamlessly using git and reviewers can view them in a lightweight branch. Of course, I need to figure all that out first!