A couple weeks ago, I had the privilege of crossing the country to attend the jQuery conference in Boston.  It was a unique opportunity for me.  While we use jQuery extensively at work, I haven’t done much with it lately.  However, since we have a few projects coming up that will be web focused, so it was a timely occurrence.  I went with my good friend and coworker David (I’d link to his blog, but he doesn’t have one yet, cough) and another coworker, Erin, who had been to Boston before.

First off, Boston was awesome.  When we arrived on Friday night, we popped over to the conference venue to register before David and I headed into north Boston.  Erin was off to meet some local friends, but not before giving us a quick overview of the city.  We headed up to Hanover Street near North End Park, where we expected to find good Italian food.  We weren’t in the mood for Italian when we reached the area, so we wandered a while before ending up at the Green Dragon Tavern, an establishment that claims to have once been the “Headquarters of the Revolution” for a while.  After starting with a couple beers, we feasted on a Hot Corned Beef (with Mustard Horseradish Sauce) sandwich and some Boston Bangers and Mash.  It was a meal to write home about (or, you know, blog about).  We hadn’t even started the conference and it was already a great trip.  We continued to go out each night after the days festivities, but that first meal was easily the best.

The conference itself was great too.  My lack of recent experience with jQuery meant that almost all the talks were interesting and usually resulted in me adding to my list of things to learn.  Here are some of the highlights (in roughly chronological order):

The jQuery Mobile keynote - Todd Parker & Scott Jehl

I’m quite interested in the mobile web at the moment, and so everything in this talk was fascinating.  They support a whole host of devices (not just iOS) and are very close to releasing 1.0.  Also, there’s an awesome demo of jQuery Mobile’s slide transitions (click here to load the demo directly on your phone).  It’s just regular html with links to images and jQuery Mobile transforms it into a sliding image gallery.

Plugin Authoring Best Practices - Ben Alman

I haven’t created any plugins (yet) for jQuery, but after this talk I not only have the tools and templates to get started quickly, I understand what some of the line noise is when looking at existing plugins.  Also, I learned the term IIFE.

Event Improvements in jQuery 1.7 - Dave Methvin

This was, by far, the most entertaining talk of the weekend. Not only did I learn about the cool new unified event declaration model that’s coming in jQuery 1.7, I got a refresher course on all the memes I have and haven’t seen.

There was quite a bit more from the weekend.  Here are my raw notes, with many many URLs to explore.

All in all, it was a great trip.

In my dfm talk a couple weeks ago, I listed out some low hanging fruit; just a few things that I thought would be easy to add to the system.  Well, this past weekend, I went to the jQuery conference in Boston.  It was a great conference in its own right, and I hope to post on it this week, but for now I want to talk about the improvements I made to dfm while on the plane.

dfm uninstall

The first thing I tackled was the ability to remove dotfiles if they weren’t needed anymore.  Sometimes, you need to log into a shared account (such as root) and you’d like to use your settings, but not leave them behind for the next person.  Now, ‘dfm uninstall’ does just that.

dfm updatemergeandinstall

Up until now, fetching your latest dotfiles changes required two steps: ‘dfm updates’ and ‘dfm mergeandinstall’.  Well, now there’s updatemergeandinstall that does both.  It takes the same flags as either updates or mergeandinstall and works just like it sounds.  Oh, and for the perennially lazy (i.e., me), it has a shortcut named ‘umi’.

The Rest

The test suite covers all the new commands and I added more coverage for the lightly tested mergeandinstall code.  ’dfm install’ now cleans up dangling symlinks, for those times when a file is no longer needed.  And, finally, I refactored the code somewhat to make it easier to work on and to reduce duplication.

To update to the latest, just run these commands:

1
2

$ dfm remote add upstream git://github.com/justone/dotfiles.git
$ dfm pull upstream master

Enjoy.

A couple days ago, I did a presentation on my dotfiles manager (dfm) at the local Perl Mongers meeting.  It was a phenomenally rewarding experience.  The Perl community has always been fun and engaging and this meeting was no different.

Here’s the source for the slides and a PDF rendering for ease of perusing.  It’s a good overview of current usage as well as a laundry list of future features.

Enjoy.

Update: Here are the slides, hosted by speakerdeck.com

I couldn’t easily find information on this, so here’s a summary for those that go after me.

A working example is in the sbt-scalatra-on-dotcloud branch of my fork of my friend’s sbt-scalatra-example project.  If it gets merged in, I’ll update this post.

The sbt-scalatra-example project combines two great technologies.  The first is Scalatra, a super light-weight web framework for Scala that’s modeled after Ruby’s Sinatra.  The second is the simple-build-tool (sbt), a tool for building Scala applications that’s more like rake (config file written in real programming language) than make or ant/maven (config file written in an abstract form).  I was able to run the example, but I wanted to try out deploying to dotcloud, and doing that requires a war file (according to the java service documentation).

The biggest thing I had to figure out is that as of version 0.10 of sbt, web application support is now in the xsbt-web-plugin plugin.  Just knowing that would have saved me an hour this morning. Setting that up and tweaking a few other files means I can now do this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ sbt clean package-war
... snip ...
[info] Packaging /home/user/sbt-scalatra-example/target/scala-2.9.1.final/sbt-scalatra-example.war ...
[info] Done packaging.
[success] Total time: 13 s, completed Sep 23, 2011 3:57:00 PM

$ cp target/scala-2.9.1.final/sbt-scalatra-example.war dotcloud/ROOT.war

$ dotcloud create sbtscalatra
Created application "sbtscalatra"

$ cd dotcloud && dotcloud push sbtscalatra
... snip ...
Deployment finished. Your application is available at the following URLs
www: http://sbtscalatra-xxx.dotcloud.com/

Of course, this assumes you’ve installed sbt (brew install sbt on the mac) and signed up and configured Dotcloud.

Have fun.

I’m about to finish up my time here in beautiful North Carolina. The rental car is returned and I’m waiting for my plane to arrive and take me back to the west coast. It’s been a week chock full of great information. It’s a good thing that the conference was only three days long though, my brain is tired.

It’s going to take a while to process all the new data I have, but here are three highlights:

Module::Package

This was part of Ingy’s Postmodern Module Packaging.  It’s a module that enables bundling together Module::Install tasks into reusable chunks. I think it’s finally time for me to learn how to use this system.

Deploying PSGI applications

Miyagawa himself gave this talk, with an extra serving of enthusiasm about the tools that have grown up around his interface. He finished off with a demo of Plack::Middleware::InteractiveDebugger, which can pop up a little REPL in the browser window at any level of the stacktrace of an application error.

Pimp your Mac with Perl

I’m quite a fan of optimizing my workspace and this talk was fuel for the fire. It was only 20 minutes long, so most of the information is on the companion website.

That’s it for now. I’ll post more as I keep processing…

While reading a recent article on Edward Tufte, I went over to recovery.gov and came across a data set that details how much money each state has received and how many jobs were created.  I’d just found out about d3.js and so I used it to create a visualization of how much each job cost:

I use these every single day:

1
2
3
4

noremap <leader>ew :e <C-R>=expand("%:p:h") . "/" <CR>
noremap <leader>es :sp <C-R>=expand("%:p:h") . "/" <CR>
noremap <leader>ev :vsp <C-R>=expand("%:p:h") . "/" <CR>
noremap <leader>et :tabe <C-R>=expand("%:p:h") . "/" <CR>

These make it much easier to open files next to the file in the current buffer.  For instance, if I run the command “vi /etc/puppet/manifests/modules/foo/bar.pp” and I need to edit a file in the same directory as bar.pp, I just type ,ew and at the bottom of my vim window this appears:

1

:e /etc/puppet/manifests/modules/foo/

With the cursor at the end, waiting for me to type the filename or just hit enter so I can use NERDTree to select a file visually.  The other mappings open splits or tabs, allowing me to easily select where new file shows up.

This morning, I discovered an interesting side effect to this command. I ran “vi http://mbostock.github.com/d3/ex/unemployment.json” to see what the json data for this cloropleth was.  Then, to see what the us-counties.json file had in it, I just hit ,ew and the following showed up at the bottom of my vim window:

1

:e http://mbostock.github.com/d3/ex/

Awesome.

One more thing. These mappings are directly from this vimcasts episode. If you haven’t watched all the vimcasts episodes, then you’re missing out on some great content.

After a few months of managing my dotfiles with git, I felt the need to organize my vim plugins a little better.  I chose to use pathogen (created by Tim Pope), which allows me to keep each plugin in its own subdirectory.  It fits well with using git to manage dotfiles because git has two ways of tracking content from other repositories.  The first is submodules, which keep a remote URL and commit SHA1 so that the other content can be pulled in after cloning. The second is subtrees, which merges the history of the outside repository directly into a subdirectory.  Here’s a quick list of the pros and cons of each strategy:

Submodules

Pros:

• Each plugin is self contained and segregated from the rest of your files.
• It’s easy to see what files came from other sources.

Cons:

• Making tweaks to plugins is difficult; requires managing a fork of the upstream repo.
• Submodules are difficult to update.
• Initial clone takes longer as each submodule needs to be initialized and fetched.

Subtrees

Pros:

• Only one command to get all your files.
• Making tweaks to plugins is easy, just modify and commit.
• Initial clone is faster.

Cons:

• It’s more difficult to extract changes and submit them back upstream.
• Plugin files are in your repository too, potentially confusing your history
• Difficult to determine exactly where other content came from

After trying both out on a branch in my repository, I settled on using subtrees.  Using them can be daunting, but there’s a fantastic wrapper called git-subtree that greatly simplifies the whole process.

For instance, to add vim-fugitive (another by Mr. Pope), all I ran was this command:

1

git subtree add --prefix .vim/bundle/vim-fugitive https://github.com/tpope/vim-fugitive.git master --squash

This results in a single commit that contains the squashed history of the vim-fugitive plugin and a merge commit which merges that squashed commit into my repository.  Here’s what that looks like on github: ad19e02.

After that merge, the vim-fugitive files are now part of my repository.  No extra steps are necessary to get those files after an initial clone.

While I was writing this, I noticed that there have been a few more commits on the main fugitive repo, so I ran the following command to merge in those changes:

1

git subtree pull --prefix .vim/bundle/vim-fugitive https://github.com/tpope/vim-fugitive.git master --squash

It all works quite well.  As of this post I have eleven plugins managed with subtrees and it only takes a couple seconds to clone my entire repo onto a new machine or VM.

I’m sick today.

Well, that’s a bit of a misnomer.  You see, I don’t get “sick.”  I get miserable.  Being sick for most people is being laid out in bed with a head full of snot, hacking and coughing and blowing through two boxes of kleenex.

Not me.

I get miserable.  What this usually means is that my nose needs to be emptied on an hourly basis and I have less of an appetite and I usually get tired faster.  Do you see anything in that list that would excuse me from work?  I certainly don’t.  So I usually don’t get to stay home and get taken care of like I used to when I was a kid.  Not that I’m complaining.  Too much.

Anyway, that’s not why I wanted to post today.

Today, I went to Home Depot.  If you knew me at all, you would know this is a rarity.  I am much more likely to be found at an Apple store.  It wasn’t a particularly comfortable experience.  My dad would be comfortable in Home Depot¹.  He’s done some level of remodeling in each home my parents have owned and he was the main force behind the recent addition to their current house.  So he’s the kind of guy who would walk in and go directly to the right aisle, pay and be back out in five minutes instead of wandering around until someone asks if he’s in the right store.  He’s awesome.

I went to Home Depot for a very specific purpose.

I needed a putty knife and drop cloth to help repair holes in the drywall above our bed left there by the removal of a shelf.  It’s the first step in getting the room ready to be painted.  I’m a bit nervous about this project as it’s the biggest thing we’ve attempted since we bought our condo over four years ago, but I’m confident that we’ll figure out how to do it.

That’s not why I wanted to post today either.

I wanted to post today because posting is good for my writing muscles.  And I need to exercise them.  And just like the first run after not getting out for a while, it’s not going to be my best work.  But at least I’ve got my shoes on again.

I have quite a few dotfiles. I have so many that keeping them in sync is impossible with conventional methods. So, I turned to my old friend: version control. For a while, I kept them in subversion at work. This worked well as that was where I spent most of my time. Recently, however, I’ve wanted those same dotfiles to be available at home and other non-work areas. So, I investigated moving them over to a git repository. Not only is git easier to set one up, but keeping multiple long running branches doesn’t make you want to shoot something.

So, I investigated how other people are doing the same thing. There are no shortage of dotfiles repos on github, so I checked out a dozen or so. I also found this area on swik that linked to several pertinent blog posts about this very topic.

I decided to go with the symlink strategy to avoid the “git clean” bug ¹, but most of the dotfiles repositories used either a makefile, a shell script or a rakefile to do the actual symlinking. I wanted to make something more flexible, and that didn’t require me to use degenerate languages (make or shell) or something that wasn’t installed by default (ruby). Since perl is baked into most distributions, it seemed a good fit.

The end result of this effort is dfm, the dotfiles manager. This script handles the basic ‘install’ case while adding a few more features (like skipping files and recursing into subdirectories). It also has subcommands that make it easy to fetch updates and merge/install them. And finally, it has a passthrough that allows you to run any git command on the local repo without having to cd into it.

I’ve been using this system full time for about the last two months and it’s really been handy. I have two branches. One is a personal branch that I use on all of my non-work systems and a work branch that is based on the personal branch with the added utilities and configuration for work. This means I can share my personal dotfiles and still keep work stuff private.

In all of this, I also wanted to make something that was generally useful, so that other people could get up and running quickly with something similar. To this end, I’ve kept my master branch distilled down to the bare minimum to get up and running with dfm. Using dfm is just a matter of forking my repo and adding what you use. I also put a bunch of information about dfm and my dotfiles repository on the associated wiki on github.

I have quite a few ideas on where to go with this from here, but the basic functionality is there so I wanted to officially release it into the wild. Let me know if you find it useful or have something to contribute.

Have fun.