Posts tagged with “How To”
- All (8)
- Entries (6)
- Links (2)
- Photos (0)
Using Git Branches as Patches
At Viddler, we’re now using Git for projects, and it’s going really well so far. While we haven’t figured out the perfect workflow just yet, we’re doing some things I really like, and one of them is treating branches like patches.
Often, people think of Git branches as a full copy of the parent branch, but it’s better to treat them as a simple collection of new commits, to be applied to the parent branch later. This might not seem too revolutionary, but this small change in thinking can really improve your workflow.
For example, at Viddler we use Trac to manage tickets, and in Git. For each ticket in Trac, we create a branch, called something like 3241-fix-embed-codes. We have two permanent branches: dev, which reflects current development, and master, which is considered always production-ready. So, dev and master are going to have different code to reflect their reflective stability. To get started with a fix, we first create a feature branch from master:
git checkout -b 3241-fix-embed-codes master
This simply creates a new branch of master called 3241-fix-embed-codes and checks it out. When the ticket is completed and the code has been committed, the patch thinking really comes into play. Since this now needs to be tested in the dev environment, the branch first gets applied to the dev branch:
git checkout dev
git merge —no-ff 3241-fix-embed-codes
Using the —no-ff option on git merge is important for this patch mindset: it creates a separate commit for the merge itself, which allows you to git revert the entire thing (if necessary), rather than having to undo each individual commit within it.
Once we’ve decided this fix is read for production, it’s time to move the code over to master. Without the patch mindset, you might consider merging dev into master, but that means you’d be copying anything that’s applied to dev, some of which might not yet be ready. When you think of your feature branch as a patch, however, it’s easy to only apply the one you need. To apply this patch to master, just use a similar method as before:
git checkout master
git merge --no-ff 3241-fix-embed-codes
Now you’ve only moved the safe commits over, leaving any buggy code safely in dev.
This method may seem obvious, but the mindset has really changed the way I use Git, and I think it makes it a much more powerful tool, especially when you’re working across multiple environments (like production and staging). I’ve skipped over some additional considerations, like merging master/dev into your feature branch, but those are topics for a future post.
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!
Posting to Brightkite using ActiveResource and REST
The other day, I came across Brightkite’s REST API. After taking a look at it, I decided it was the perfect opportunity to try out ActiveResource, the dead simple way to consume RESTful resources. In 20 lines, I was able to put together a simple script to find your most recent check-in on Brightkite and then post to that place.
A Quick Intro To Active Resource
First off, here’s an idea of just how easy it is to connect to a REST API using ActiveResource. Take, for instance, the “places” resource in Brightkite; these URLs all have the base http://brightkite.com/places. To interface with places, all it takes is this:
class Place < ActiveResource::Base
self.site = 'http://brightkite.com'
end
That’s it. To get all the places, just do Place.find(:all). To create a new place, all it takes is Place.new. Amazing, to say the least. There’s a lot more that’s possible, so I recommend you check out the ActiveResource page on the Rails wiki.
The code
Below are the 20 lines necessary to post a note to Brightkite through the API. Just change USERNAME and PASSWORD to your username and password and change the note text at the bottom, and you’re ready to go. While this is a pretty simple example, it shows just how powerful a well constructed REST API can be.
Getting Brightkite and Verizon to Play Nicely
After hearing all about Brightkite from Brandice and Colin, I decided to take the plunge and try out the service a few weeks ago. In the time since, I’ve become addicted to the service, and I’m constantly amazed at how well thought out the site is. One thing that really bugged me, though, is that Brightkite doesn’t work with Verizon text messages. After being initially disheartened, I found getting around the issue to be pretty easy: instead of text messages, I used PIX messages.
If you take a look at Brightkite’s SMS Guide when logged into the service, you’ll notice a email under “Post a photo to a place.” This is the email you’ll be sending your updates to. To use any of the mobile commands (PDF) with Verizon, just send a PIX message to the email address without a photo attached. Put your command in the “text” field, send the message, and you should be good to go.
A word of caution: if you don’t have unlimited picture messaging, this method may end up being very costly. I’m not sure if Verizon still charges their PIX rate for messages without pictures, but if they do, make sure you’re not going over your allotted number of messages.
Hopefully, Verizon will fix whatever issue is breaking the Brightkite integration soon, so we don’t have to continue to hack around the problem. In the meantime, however, this method should continue to work; I haven’t had any issues with it thus far.
Rails Envy Caching Tutorial
Awesome guide to Rails caching that definitely saved me several times building this site.
Organize Nested Resource Controllers More Efficiently in Rails
Nested resources are awesome. If you want to have a blog with entries that have comments, the resources are dead simple:
map.resources :entries do |entry|
entry.resources :comments
end
Awesome, now you have set up paths like entries/3/ and entries/3/comments/ using an EntriesController and a CommentsController. What if, however, you want to have a base comments resource (/comments/) to show all comments? You already have a CommentsController, and it doesn’t do what you want. To solve this, I do something like this:
map.resources :entries do |entry|
entry.resources :comments, :controller => 'entries/comments'
end
map.resources :comments
Now, you have all your routes set up, and you can have separate controllers, Entries::CommentsController (which lives in controllers/entries/comments_controller.rb) and CommentsController. Just remember when generating the nested controller to use the proper name, like so:
ruby script/generate controller entries/comments
Deploying Rails on Dreamhost with Phusion Passenger
Deploying Ruby on Rails has always been a pain, even with tools like Mongrel and Capistrano. On shared hosting, it’s nearly impossible. A little while ago, I noticed a project called Phusion Passenger (aka mod_rails), which sought to make deploying as easy as uploading your application to your webhost. A few days ago, Dreamhost (my host) announced on their blog that Phusion Passenger was available on their servers. Naturally, I took some time to play around with it, and so far I’ve been extremely impressed. I threw together a quick app using Viddler.rb and deployed it to Dreamhost (you can see it here). Here’s a quick guide on how to deploy to Dreamhost yourself using mod_rails.
Getting set up
The first thing to do is to set up your domain or subdomain to use Passenger. Just go to the Manage Domains page on the DH web panel, and either create a new domain or edit an existing one. Check the “Ruby on Rails Passenger (mod_rails)?” checkbox and set the web directory to where the public directory of your app will be. Below is a screenshot of my settings for viddler.fidgeting.net.
Next, you need to create your database, so just go into the Manage MySQL section of the panel. Create your database, which should be named as a production database. In my case, it was viddler_production. Then, make sure to change your database.yml to reflect the database you just created.
Uploading and running your application
Before uploading, make sure the first line of your public/dispatch.fcgi has the correct path to ruby on Dreamhost (which is /usr/bin/ruby). Then all you need to do is upload the files to Dreamhost and go to the domain. That’s it—your app is now completely functional. Amazing, huh?
If you need to first run migrations, you can do that from SSH with this command:
RAILS_ENV=production rake db:migrate
If you need to restart your application (anytime you change any files), just run the following command via SSH:
touch tmp/restart.txt
Getting Gems to work on Dreamhost
Since Dreamhost is a shared host, you can’t directly install gems on the server. Dreamhost’s wiki has a lot of information on different ways to get gems working, but they are all fairly involved, and I couldn’t get any of them to work. The way I did it was by unpacking the gems into vendor/gems by using the “gem unpack” command:
gem unpack <GEM NAME>
I’m sure there are better ways to do it, but this method worked perfectly for me.
Overall Impressions
Like I said at the beginning, I’m very impressed with Passenger, and so far I haven’t noticed any issues. The total time for me to deploy was about 20 minutes: way faster than with Mongrel or FastCGI. It’s definitely awesome to see a host as large as Dreamhost using this, and hopefully soon more will follow suit.
Getting Started with phpViddler
Over on the Viddler Lab blog, Colin Devroe and I are putting together a series on how to use phpViddler, the PHP wrapper for Viddler API. Parts one and two are already up, and more are on the way, so definitely check it out if you’re interested in developing a site powered by Viddler.