Entries from July 2009
- All (18)
- Entries (2)
- Links (16)
- Photos (0)
The Perfect Git Workflow for a One Person Project
A few months ago, I started investigating Git, and I fell in love with how much easier it made managing my code. I’m managing the source code to this site with Git, and along the way I’ve come up with a pretty good workflow for myself. The basic steps are:
- Branch
- Commit
- Rebase
- Merge
- Deploy
Let’s go through each one to see how it all works together.
Branch
With SVN, I found myself hating branching–it was always a complicated procedure, and I could never remember how to do it. In Git it’s as easy as git checkout -b <branch-name>, and you’re ready to go. Once you have a branch, you can modify it however you want, and you don’t have to worry about interfering with the master branch. In order to keep your master branch bug free, commit only to branches, not to master itself.
In addition to creating new branches for major features, I always have a few branches around that I pop into for certain things:
- “design” - any changes I want to make to the design go here
- “optimize” - optimizations to the site
- “bugfixes” - a place to work on minor bugfixes
Having these branches allows me to make small fixes to the site, and if it turns out it’s more than just a small fix, it doesn’t interfere with anything else.
Commit
In the Subversion world, it’s a pretty common practice to make very large commits, consisting of many changes. With Git, you should constantly be committing. By making many commits, you make it easier to find bugs you may have introduced, and it makes it a lot easier to track your progress. If you don’t like the thought of wading through long lists of commits in your logs, don’t worry–before bringing it over to the master branch, you can consolidate things with interactive rebasing, but while you’re hacking away on a branch, it really is advantageous to have many small commits.
Rebase
Rebasing is one of the harder things to grasp when you’re first learning about Git. For in-depth coverage of the topic, check out the Rebasing page in the Git Community Book. In a nutshell, doing git rebase master takes any commits to master and inserts them into your current branch, so you can then make sure your new code still works, and it’s a lot less hazardous than doing a merge. Rebasing your branch before putting into master is really important because it allows you to deal with any merge issues before the code goes to your main branch. To rebase, just run git rebase master.
Merge
After rebasing the branch, it’s safe to merge it into master. Since I’ve already dealt with any merge issues with the previous step, it’s as simple as checking out the master branch and running git merge <branch-name>
Deploy
I use Capistrano to deploy my code, so I’m constantly typing git push followed by cap deploy to deploy changes to my server. To make it easier, I just put both commands into one git alias:
deploy = !git push && cap deploy
Now I just need to run git deploy and it automatically pushes all of my changes to the remote Git repository and then deploys the site using Capistrano. Here’s some more information about Git aliases.
Useful tools
Though I primarily use Git through the command line, I really like using GitX to visualize branches. To host my repositories on my server, I use Gitosis, though if I had a few more projects, I’d dole out the money for a paid account at GitHub.
Have a great Git workflow? Think mine’s terrible? Let me know in the comments!
4 Easy Frontend Optimizations for Your Site
Over the past few weeks, I’ve been tweaking the site a bit to help speed up page loads. After running YSlow and Page Speed, it seemed like the slowest aspects of my site weren’t necessarily happening behind the scenes with my Ruby code, but rather on the frontend with images, Javascript, and CSS. Below, I’ve listed four ways you can squeeze more speed out of your site without even touching backend code.
Gzip your files
One of the first things I did to speed up my site was to start using mod_deflate to gzip compress data from my site before it’s even sent to the viewer’s browser. Basically what happens is after my Rails app returns the HTML for the page, Apache then compresses it and sends the compressed version to the user. Enabling this brought my front page size down to 6KB from around 22KB, a 73% improvement! You should enable this on all of your plaintext files, such as external CSS and Javascript files, as well as any HTML that’s being sent to the browser–essentially as many files as you can get away with.
For more information, make sure to read Paul Stamatiou’s excellent post on mod_deflate, where he goes through the steps of gzipping your site on Apache.
Set a far future expires header for images, stylesheets, and JS
When your browser wants to fetch a file, it first checks to see if it’s stored in its local cache, and if it has a new enough version of the file, it will display that instead of taking the time to download it from the server. The problem is, how does your browser know if the cached version is “new enough”? The trick is to use the Expires header for any files you know aren’t going to change very often (such as images, stylesheets, and javascript). I did this on all of my photos, and it has made a huge difference–after turning on the header, my bandwidth usage went down by 70%, since browsers were no longer re-requesting images they already had.
For how to set a far future expires header with Apache, check out Christian Johansen’s tutorial on the subject.
Load Javascript Libraries from Google
Nowadays, just about every site is using a javascript library of some sort, whether it’s Prototype, jQuery, or something else. Since the library might not change from site to site, why not leverage that to cut down on download times? Google has done the work for you, with their AJAX Libraries API, which provides you with a CDN-hosted version (what is a CDN?) of popular JS libraries, so they’re super fast, and once your browser downloads the library for the first time, it will be retrieved from cache for any site that uses the same file.
There are 2 ways to use Google’s hosted libraries, via the API listed on their page or just by including the file. For instance, I’m including jQuery 1.3.1 with this code:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>
I’m not sure exactly how much faster this has made my site, but it definitely keeps bandwidth usage down and makes the user experience much quicker.
Defer Loading of Stat-tracking Javascript
I’ve always run two separate stat tracking scripts on this site: Google Analytics and Mint, but recently, I really started to notice they were slowing down page loading time (especially with Mint). To combat this, I decided to defer loading the scripts until after the page has finished, so as to ensure they don’t impact the user experience negatively. To do this, I just used jQuery’s $.getScript() function like this:
$(document).ready(function() {
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
$.getScript(gaJsHost + 'google-analytics.com/ga.js', function() {
var pageTracker = _gat._getTracker("GOOGLE TRACKING CODE");
pageTracker._initData();
pageTracker._trackPageview();
});
$.getScript('http://path/to/mint/?js');
});
Just customize it to point at your stat tracking scripts, and you’re ready to go. One caveat with this–it may impact your stats, because scripts won’t be loaded until the page finishes rendering, meaning if someone clicks off the page before them, it might not register their visit. I haven’t had enough time to see if my decision to defer loading has affected my stats, but I’m guessing it would have at least a minor impact.
Anything else?
Is there anything else you’ve done for your site that’s really lowered your loading times? Let me know in the comments!