Log

Today, for fun, I made a few of these cahiers:

1. 24 lb. gray (speckled) paper
2. 140 lb. gray card stock cover
3. Black waxed thread

The quality of the paper I currently have to work with isn’t so hot so I’ve ordered some from French Paper. I’m sure the next set will be more handsome.

I ran into David Eisinger at Fullsteam Brewery a few nights ago. After talking about what we had both been working on recently we found ourselves on the topic of mananging a larger project with Git. He mentioned a command that I had not heard of previously: git cherry. I did some research on it and realized a flaw in my current workflow.

Up until now I have been using a git-ish expression like git log master..current-topic to find a list of commits thate are in the current-topic branch but not in master branch. However, this method only pays attention to commit hashes, not the actual commit diffs themselves, when determining the existance of a particular commit in a branch. git cherry is different. It does pay attention to diffs so you can have better overall visability of what’s been applied and what hasn’t.

The Setup

To illustrate this idea, here’s the transcript for an example that I’ve set up.

You’ll notice that the two commits 31e27cc (Second.) and d48dd31 (Fourth.) are exactly the same changesets; just committed to two different branches.

Evaluating the Differences

vs.

These two methods return similar information, but take a look at the output of the git cherrycommand. A line that is prefixed with a + is a change that is in the current branch and does not have an equivalant changeset in the upstream branch (master in this case). A line that is prefixed with a - is a change that does have an equivalant changeset in the upstream, regardless of whether or not their commit hashes are different.

This is really useful if you have sent patches to other members of the team via email instead of pushing the commits upstream. The changes you’ve made locally will be under a different commit hash than those your teammate applied using the patch. git cherry will let you easily see which patches have been applied and which haven’t.

So Trevor O’Brien and I were in .NET MAGAZINE this month. We answered questions about the new McKinney.com that was launched in September of 2010. We also spoke about Lectric—a library I built and a biproduct of the website. Here are a few shots of the issue:

This is the first time I’ve ever been in a magazine. There’s something strange about seeing your name printed on paper like this. It’s pretty rad, though. Be sure to pick up a copy, flip to page 102 and check it out.

Lately, while reading through other developers' code, I’ve been noticing a bad habit. What’s frustrating about this habit is that it’s re-enforced by many jQuery tutorials—pumping many ill-informed JavaScript developers into the world. That habit is the (over-)use of return false.

God, make it stop.

The truth about return false

What you may not know is that return false is actually performing two things at once:event.preventDefault() and event.stopPropegation(). In simple situations, including in most jQuery examples, using return false won’t cause too many problems, but it can cause all sorts of problems when mixed into a larger application.

So which to use?

event.preventDefault()

Use this to prevent the default behavior of the element from being executed. To most developers, this is what you want instead of return false. It will stop the default behavior while still allowing the event to bubble up to parent elements. Here’s a quick example of its use:

event.stopPropegation()

Use this to prevent the current event from bubbling upward to parent elements.

return false

Use this if you want both of the above to happen.

I used to use the following when creating a new element to place on the page:$('');. Now I’ve always had a few qualms with this method. For one, it’s not very readable; especially if we start mixing in a bunch of string concatenation: $('');

Dude, Gross! Second, if one of my co-workers makes changes to this line and commits it to Git, depending on the length of the line, it might take me forever to find exactly what changed in a diff.

So what to do? Thankfully, there’s a feature in jQuery that has helped me out a lot in this area; you might not even know you can do it. As of jQuery 1.4 you can now do this instead:

The second parameter can now receive an object literal that contains parameters that should be applied to the object after it’s created. You can even assign events this way. This new approach isFASTER as well. It uses the browser’s native JavaScript createElement function instead ofinnerHTML mechanism so it’s faster. Basically, jQuery creates the element then assigns the attributes to it via the .attr() method.

A More Expressive Example

You can also bind any event type to the element as well.

If you break the options out as defaults, you can do some pretty nifty stuff. Like this:

I’ve been using this technique for the last few projects and it’s really been working out well.

Lately I’ve been involved with a Rails application that has a heavy Flash front-end. This being the first project I’ve worked on with so much Flash since switching to Git, I ran into a few issues. It became hard for Nick and I to pull from the repository without being haunted by SWF merge conflicts. We could just ignore the SWF files all-together, but since I’m using Capistrano for deployment, this just isn’t an option. The SWFs have to be present in the repository for them to make it to the production server. Thankfully, utilizing Git, I’ve arrived at a decent solution.

The key is to have a separate remote branch from which you deploy to production. Unsurprisingly, ours is called “production”. While the master branch ignores SWFs (via .gitignore), the production branch does not. After configuring Capistrano to deploy using the production branch you’ll have a clear way of getting SWFs to the server. The workflow goes like this:

1. git checkout production
2. git rebase master
3. Export the SWF from Flash
4. git commit -am "Updating the SWF."
5. git push --force origin production
6. git checkout master
7. cap production deploy
8. This setup keeps SWFs out of our day-to-day and allows us to deploy just fine with Capistrano.

Vim 7.3 just introduced a persistent undo feature. Turning on this feature will give you the ability to close a file and, after reopening it, still be able to undo changes from the last session. Pretty nifty.

Create a directory called “.undo” in your home directory and add the following two lines to your .vimrc to take advantage of it:

set undofile set undodir=~/.undo 

Pro tip: Don’t write more than 80 characters per line.

match ErrorMsg /\%81v.\+/ 

This will highlight characters on lines that exceed the 80 character mark. It’s an easy way to audit the presentation of your code while your coding. Readable code for much success!

:.!command

Sends the current line to a unix command and replaces it with the output of that command. For example :.!date replaces the current line with today’s date.

The significance of the . is that Vim is accepting a range of lines to send to the command line, and . means the current line. So if you wanted to send a Visual mode selection to, say, sort, you would do this: :‘<,’>!sort

Also, typing !! while in Normal mode will produce :.! for you.

:cd %:p:h

Let’s break this one down. :cd changes the current directory to the path specified. If no path is given, :cd will move you to your home directory.

In our situation, we are passing %:p:h as our path. The % is our current filename. :p is a filename modifier that provides the full path to the file. :h selects all path segments until it reaches the filename; choosing the directory containing our file.

One of my staple plugins for Vim is NERDTree. Version 4.0 was released last October, and included in that release was a way of extending its file menu system. As a web developer, I find myself wasting a fair amount of time hopping out of Vim into Finder or Photoshop to find the dimensions of images I’m working with in CSS. Using the new NERDTreeMenu API and ImageMagick, I wrote a quick script to reveal image dimensions right within Vim.

Place this file in your nerdtree_plugin directory. In order to use it, you’ll have to select a file that has a .JPG, .PNG, .GIF or .BMP extension, press “m” and then press “i”.