- Recent
- Popular
- Tags (0)
- Subscribers (9)
- Launching Ruby on Rails projects, a checklistDecember 15 2008
-
As mentioned in a recent post, I’m hoping to share some lessons that were learned throughout the process of launching a client project. Over the past few years, we’ve been part of several dozen client projects and the big launch date is always an anxiety-filled, yet exciting point for the client and our team. I wanted to provide a quick list of a few the things that our team considers vital before launching that next big project. While most of these things might seem obvious, it’s still good to cover the basics and I hope a few people find it helpful.
Hosting
Our company has been offering Ruby on Rails hosting for nearly four years and a few years longer with the PHP5 and PostgreSQL world. Given that, we’ve seen customers come to us at the last minute before they launch and wanting to get things setup and deployed right away. Quite often, this is their first experience deploying a Ruby on Rails application and there has historically been a semi-steep learning curve to do this. It’s really encouraged that you get this stuff figured out ahead of time. If you’re lucky, some hosting companies might offer cheaper plans so that you can begin to get things setup a few months or ahead of time and upgrade your plan prior to the big launch. This
- Lighthouse tickets and Git branchingDecember 11 2008
-
We’re currently using Lighthouse as our ticketing system with clients for maintenance/bug requests. We’re also using Github for all of our major client projects. I’m sure that many of you take advantage of the Lighthouse service that Github allows you to use so that your commits can trigger actions on your tickets in Lighthouse.
If you’re not already, you might consider running (cheat ?):
- cheat lighthouse
With your commit messages, you can just pass in the ticket # and resolve your ticket without needing to interact with Lighthouse too much.
Okay, so one of the problems that I’ve had with this process is that I have had to constantly look back in my browser to see what the ticket # was that I was working on. So, I decided to start writing it down on a notepad as I was working through tickets so that I could look down at my desk, but this wasn’t terribly efficient either.
- The HTTParty has just begunNovember 27 2008
-
After releasing the new RubyURL API, I decided that it was time to look around at libraries to interact with it. I came across a new Ruby gem from John Nunemaker named, HTTParty, which aims to make it easy to talk to XML and JSON-based web services. Be sure to read John’s announcement of HTTParty.
So, I decided it might be fun to introduce more people to the gem by showing you all how to use it to talk to the new RubyURL API.
Install HTTParty
Before we get started, you’ll need to install the HTTParty gem with the following command:
~ : sudo gem install httparty Password: When you HTTParty, you must party hard! Successfully installed httparty-0.1.6 1 gem installed Installing ri documentation for httparty-0.1.6... Installing RDoc documentation for httparty-0.1.6...Great! Now that we’re ready to party hard, let’s build something.
Talking to the RubyURL API
The RubyURL API currently supports both XML and JSON, which are each supported by HTTParty. The great thing about HTTParty is that all you need to do is include it in a class and you’re able to quickly talk to remote ser
- Lesson Learned: Git Ref NamingSeptember 19 2008
-
Our team has been working our way into the Git world. One of our big client projects is now 100% git while the other is still on Subversion for another month or so. (I’m getting by with git-svn, the gateway drug on that). We’ve had pretty much nothing but success with Git for quite some time, but recently this repository started to get chaotic, which has eaten up time… which isn’t conducive to productivity.
So, I wanted to share a quick lesson that we learned today after scratching our head for a while. It’s important that you avoid having a branch on a remote repository that shares the name of a tag in your local and/or remote repository.
I REPEAT.
It’s bad mojo to have a tag and branch share the same name. Things that you’d expect to just work... don’t. This was causing us to see warnings and errors like the following, which we weren’t really sure what to make of it.
“warning: refname ‘staging’ is ambiguous.
“error: src refspec staging matches more than one.”
This started about two weeks ago when we started a few new remote branches: staging and design. It seemed to be going okay but we managed to muck up things when we merged those two together and some of us were having success fetching/pulling/pushing to staging and others
- MySQL is just a toySeptember 11 2008
-
Are you using PostgreSQL? EnterpriseDB want’s to hear your story at Postgres Rocks