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 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.
As I’ve started diving into more client-side heavy web apps, I’m finding myself constantly asking why any given tool was developed. Lots of web technologies can look cool, but what problem is each trying to solve. Bower was one that mystified me, even as I let Yeoman go ahead and install it in my latest project. It describes itself as a package manager for the web. As a user of npm, I was aware of various packages and tools that can be installed, but I did not understand what packages Bower could be capable of handling. What problem is Bower trying to solve?