A couple of years back, I made the switch from bash to zsh. I did so mainly because I saw a fantastic post on customizing the command prompt that I dove into head first, and I’ve stuck with it for the slightly improved tab completion. Your mileage may vary with regards to zsh, but I always find it difficult to do without it when I end up working on somebody else’s machine. Despite the improvement, there are a few differences between the shells, and I’ve come across a scipt or two that wasn’t especially zsh friendly. One of those is the very rake task that created this blog post.
In my last post, Yeoman, Backbone, and a Smarter Client, I discussed diving into the new development-minded technologies that have flooded the JS proverbial toolbox. The first project I put together with said tools is MaxWell, a single-page web app for graphing your point totals in ESPN’s Fantasy MaxPart games (think Pigskin Pick’em and ESPN’s march madness game, Tournament Challenge). Yeoman and the Yeoman Backbone generator were used to bootstrap the application. RequireJS is used to manage dependencies. The application itself lives inside a Backbone framework. Grunt is used to build the webapp and prepare it for deployment. Finally, the app is deployed using git and it lives on GitHub pages.
I have just gotten started using the Octopress framework for blogging, and I love it. The setup process is unbelievably well-documented, and if you’re familiar with Git and Ruby projects, you’ll pick it up fairly quickly. The only issue I had early on was pushing my new blog up to Github for version control. It’s a little tricky since the first step is cloning from Brandon Mathis’ Octopress repo, but the fix is relatively simple.
I have gone through a number of tutorials on newer front-end tools like AngularJS, Grunt, and Backbone. Nothing compares to building something of your own, though. After dipping my toe into the water numerous times before, I dove into the deep end and started combining these tools on my own.
I normally feel fairly well-versed in Git, which is to say, I can commit code, I can see what’s happening, and I generally know enough to not screw anything up. I thought my Git Fu was tight enough that I at least had a good grasp on all that could be done with the version control system until I came across a project that used submodules. In Git, a submodule is a connection from one repository to another. Say, for instance, you’re working on a suite of similar products. You want each one to have its own repository. That makes plenty of sense. But suppose each of these products shared a common messaging platform. Instead of maintaining this same code across the suite of products, which would defeat a lot of the purpose of setting up a VCS, you can give it its own subrepo, and have each product in your suite set up a submodule to reference that repo. All seems well and good, but there are a few gotchas to keep in mind.