In case you missed the tweet from Alex âŚ
::: thumbnail
:::
Our team just designed, developed, and deployed a new site for, Boxcar, our streamlined deployment environment for Ruby on Rails applications.
::: thumbnail
:::
Feel free to take a tour to learn more about our product plans, which currently start as low as $59/month.
If you have a project that youâll be launching in the coming months, get in touch with us. :-)
::: warning Since publishing this article, I have given a talk on this topic at Rails Underground 2009. I invite you to checkout the slides. :::
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.
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 is how our Rails Boxcar hosting plans work.
Weâve seen a lot of customers avoid engaging with a hosting company more than a week or two before their launch because they want to reduce their monthly expenses, but the reality is that if you end up saving yourself a few hours of work by not scrambling at the last minute to get things setup, the hosting costs will pay for themselves. Several of our customers have learned this the hard way and as a result, this has resulted in extra stress that might have been avoidable if things had been ready earlier on.
The basic process that our team is to get a real deployment environment setup as early in the design and development process as possible. Often times, this will be 4-6 months before launch on larger projects. In our process, we aim to have a staging environment that mirrors our production environment. We tend to use a Boxcar Lite plan for our own client projects and get the deployment process working and automated. When itâs time to launch, we can easily upgrade the Boxcars with more resources to one or more Plus plans.
If youâre in the market for a hosting company, do keep us in mind, but if we can offer any advice, be sure to find out how you can scale upwards to meet your initial 3-6 month growth targets. Donât worry about planning too far ahead in the future, until you see how traffic picks up and how the application and databases perform, youâll be spending a lot of time guessing without data. If youâre new to this and arenât sure, Iâd encourage you to speak with a Ruby on Rails deployment specialist.
A few things to consider here:
.htaccess user/pass with this
method to the stakeholders so they can access the site whenver they
need to.
There are a handful of really great hosting companies out there for Ruby on Rails. Be sure to do your homework early! This isnât something you want to do at the last minute.
Reminder: Keep your project releasable at all times.
Before the big launch, be sure that you have outlined a consistent pattern for managing the HTML page titles on each page. Getting targeted traffic to your new web application is (usually) vital. Our team has adopted a basic pattern that we use throughout the application. This way we donât have to go through at the last minute and figure out where titles are and/or arenât being set.
In a previous post, I shared a basic plugin that our team uses on projects to manage page titles on a view-by-view basis.
Additionally, be sure to take advantage of using descriptive permalink URLs.
Another tip is to setup your application with analytics (google analytics is free!) If there is one thing that I wish we had setup from day one on every project in the past, was a set of conversion goals. So, be sure to get into your analytics account and prepare your application so that you can track these goals from the moment your application is launched. Collecting as much data about your visitorâs usage habits is going to help you in the coming weeks and months as you tune things based off of feedback and this data. Also, after you begin to introduce changes, you can analyze these metrics to verify that youâre improving things and not the opposite.
So, be sure that you are doing the following:
What happens when things go wrong? Weâve been amazed by how many projects weâve seen have been in production for months/years and lacking something that seemed so obvious. Exception notifications! All too often, weâve seen teams totally unaware that things were failing for their customers and not being reported to anybody. The easiest way to track exceptions in the past was to use the exception_notification plugin that the Rails team manages. You can have this plugin send your development team emails with a backtrace and all the goodies thatâd normally show up in a 500 error. At a minimum, you should be using something like this.
However, in the last year, the Rails community has seen two options, Exceptional and Hoptoad introduced for managing exceptions. Our team has only used Exceptional so far, because our good friends at Contrast invited us to be early beta-testers for their new service. We love the Exceptionalâs integration with Lighthouse, which is the bug/issue tracking application that weâre currently using. With Exceptional, our team is able to search through and track exceptions in our application and have a good meter on the overall health of our application. This solution works so much than the email-based approach because we can track which exceptions have been opened and sent to Lighthouse and if theyâve been closed by someone already.
Iâve heard great things about Hoptoad as well, but have yet to test it out. Would be interested to read a comparison between the two and am curious if there are other services for this currently.
Honestly, this is one of those things that we tend to forget about until the last minute. When youâre launching a new project, youâre bound to have a bug and/or a few broken links not accounted for. What you want to avoid is having your customers end up on an unhelpful page that looks like this:
::: thumbnail
:::
It doesnât take too long to put something together that is a bit more helpful for your visitors.
::: thumbnail
:::
So, do yourself a favor and add a ticket for your designers to design a
custom 404 and 500 pages to replace the defaults that are provided by
Ruby on Rails in public/.
If youâre working with startups, do remember that this is quite possibly their first launch. Itâs important to remember that theyâre going to be going through their own spectrum of feelings and itâs our job to help get them through the process with an eased mind. Show them that you have things covered, that things are ready to go, alert them when things pop up⌠in a nutshell. Keep them informed about the challenges and do what you can help to manage their stress. If theyâve just contracted you for an extended period of time to help get their big idea designed and developed, remember that this launch is just the beginning of the race for them. They have a big journey ahead of them and you just helped them get their new car engine built. Make sure they know that things are likely to breakdown along the way, need to be refueled (refactor! refactor!), and need service repairs. The worst thing you can do is set the expectation that nothing will go wrong once their application is released into the wild. They need to budget for this early on so that they can pace themselves after launch. (this is a big topic definitely worth of itâs own post)
Just remember that this should be a big celebration for your team and client. Remember to celebrate! (and then follow it with a retrospective)
As mentioned, these are just a handful of things that we have learned to avoid overlooking (through trial and error). Iâm hoping to share more thoughts on launching in the near future and would love to hear from all of you on things that youâve come across. What works? What doesnât work?
What is on your checklist for launching successful projects?
::: {.thumbnail style=âfloat:right;â}
:::
Earlier this week, our team launched a clientâs project into the public. We began working on it early this year and it was quite an endeavor for our team. The company that we helped launch is AlphaClone, a premier stock research and portfolio simulation service for individuals and professional investors alike. Clone, backtest and track over 230 top fund manager portfolios. More than 15,000 pre-generated clones and nearly limitless possibilities based on your own custom groups of funds. Take a tour of AlphaCloneâŚ
Itâs hard to deny that Iâm insanely proud of the team at Planet Argon for bringing our clientâs business idea to reality. Weâve been enjoying keeping up on how the press is responding so far since theyâve launched. I expect that theyâll do well with their business endeavor and look forward to helping them evolve and expand.
Iâve been asked to share some stories and lessons learned throughout the project. Given that we tackled a lot on the Interaction Design side of things in addition to relying a lot more on some of the advanced features of PostgreSQL (weâre dealing with a TON of data here), we have things to share. So, stay tuned as Iâll be highlighting some of those lessons over the coming week(s).
Additionally, if youâre looking for a team to help you execute your next big idea, give us a call!
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 lighthouselighthouse:
- Commit comment [#213]
Adds message as comment to ticket #213
* tagged - adds tag to the ticket (does not replace)
* responsible - sets the user responsible for ticket (responsible:none to
clear)
* milestone - sets the milestone for ticket (milestone:none to clear)
* state - sets state (new, open, hold, resolved, invalid)
- Commit comment [#213 tagged:committed responsible:johan milestone:"Launch"
state:resolved]
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.
So, I decided to start leveraging the features of git to help me out. For each ticket that I work on, this is my process.
In Lighthouse, I decide which ticket Iâm going to work on next. I then
create a local branch using the ticket # in the name. Example:
LH_1623
The workflow ends up looking like:
alphaclone git:(master): git checkout -b LH_1615
alphaclone git:(LH_1615): <â I am using zsh and have it display the
current local branch
I then work on this ticket. Since Iâm working within the branch and my prompt reminds me what ticket # is being worked on, it makes it easy for me to add this into my commit message.
git commit -m "Fixed the do-whacky issue with data importing. [#1615 state:resolved]"
At some point, this will be ready to be merged back into master and pushed to Github.
git checkout master
git merge LH_1615
git push origin master
Github will take your commit message and pass it over to Lighthouse and your ticket will be marked as resolved automatically. This workflow has saved me a lot of time from navigating through Lighthouse and has also helped me stay focused on individual tickets throughout the day. Quite often, Iâll get interrupted by something non-development related and seeing the ticket # in my terminal helps get me back on task.
Iâve managed to encourage a few of the others at Planet Argon to adopt this ticket-based branch process as well so that when we need to collaborate on a ticket we publish the ticket branch to Github so that others can work on it as well. (happens a lot when a designer and developer need to work together on the same issue/feature)
Anyhow, just a quick little introduction to something simple that I did that has definitely helped me become a little more efficient throughout the day. Perhaps you have a better approach and/or tips for others that youâd like to share?
Bob Zurek, the Chief Technology Officer at EnterpriseDB interviewed me a few months ago for their new Database Radio podcast. It finally was published last week. Bob and I had a nice conversation about PostgreSQL and itâs community, our use of PostgreSQL with Ruby, Ruby on Rails, and development tools/methods.
::: thumbnail
:::
You can listen to the podcast mp3 and/or read the transcript.
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.
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.
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 services.
In this following example, weâre going to create a new class called
Rubyurl.
class Rubyurl
end
What weâll want to do now is include the HTTParty library. (note: youâll need to require both rubygems and httparty gems and Iâll skip those lines in following code samples)
class Rubyurl
include HTTParty
end
The HTTParty provides a few class
methods,
which we can use to configure our library. Weâll go ahead and specify
the base_uri, which weâll set to rubyurl.com.
class Rubyurl
include HTTParty
base_uri 'rubyurl.com'
end
Now that our class is setup to talk to the
Rubyurl.com site, weâll want to add a new method
which we can use to communicate with the RubyURL API. Weâll call this
shorten as weâre using RubyURL to shorten long URLs⌠right?
class Rubyurl
include HTTParty
base_uri 'localhost:3000'
def self.shorten(website_url)
end
end
Our new shorten method will expect us to provide it with a website
url, which weâll want RubyURL to return a shortened URL for. The PATH
for the API that weâll want to talk to is: /api/links, which weâre
expected to pass XML or JSON to.
Here are two examples of using the RubyURL API with HTTParty.
Weâre going to use the post method that is provided with HTTParty to
send a request to /api/links.json. As you can see, weâre providing the
original website url to the web service.
class Rubyurl
include HTTParty
base_uri 'rubyurl.com'
def self.shorten(website_url)
post('/api/links.json', :query => { :link => { :website_url => website_url } })
end
end
When ran, itâll produce the following:
>> Rubyurl.shorten('http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb').inspect
=> {"link"=>{"permalink"=>"http://rubyurl.com/uJVu", "website_url"=>"http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb"}}
Pretty simple, eh?
The great thing about HTTParty is that you can use XML without changing much.
class Rubyurl
include HTTParty
base_uri 'rubyurl.com'
def self.shorten(website_url)
post('/api/links.xml', :query => { :link => { :website_url => website_url } })
end
end
Produces the following
http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb
http://rubyurl.com/uJVu
So⌠there you have it. HTTParty makes it extremely easy to interact with various web services that work over HTTP. Iâd encourage you all to take a few minutes to experiment with it and see what crazy ideas that come to mind during the process. :-)
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
were having to specify :heads/staging and couldnât have a local branch
named staging. Needless to say, it was causing some problems and
slowing us down.
This afternoon, we finally noticed in the GitHub interface that there
was a tag named staging. Hmm⌠interesting. We verified this by using
git show-ref.
::: thumbnail
:::
Are you using PostgreSQL? EnterpriseDB wantâs to hear your story at Postgres Rocks
Alex Malinovich decided to take some time this afternoon to write a Ubiquity command for RubyURL using the new RubyURL API. You can take a look at Alexâs Ubiquity code for RubyURL. Heâs taking advantage of the JSON support that I added to RubyURL this weekend and JQuery. Be sure to read Alexâs blog post, which includes a screencast! =)
Also! We added this to RubyURL so that if you have Ubiquity installed, youâll be presented with the following the next time you visit: http://rubyurl.com.
::: thumbnail
:::
Iâm sure that most of you heard the news that Google is releasing a new web browser named Chrome. Their comic for the announcement was very refreshing and entertaining read. Granted⌠nobody that I know has seen it (as of today)âŚ
For me, Iâm really interested in seeing what theyâve done to hopefully improve some of the short-comings of the user experience through their interaction design process. For example, tabs containing their own url/search fields sounds refreshing (I really dislike the hierarchy currently). Also, Iâm really looking forward to their dashboard-like default page.
::: thumbnail
:::
From a web development standpoint, it definitely raises questions about what weâll be able to do in the coming year(s).
What are your initial thoughts on this? DiscussâŚ
Update: Gary came across this amusing quote from a response by a representative at Microsoft.
âThe browser landscape is highly competitive, but people will choose Internet Explorer 8 for the way it puts the services they want right at their fingertips ⌠and, more than any other browsing technology, puts them in control of their personal data on-line,â Hachamovitch said. (read article on CNN)
Iâm really not sure what that even means. Donât we already have our online services at our fingertips? I suspect CNN interviewed the wrong person.. because this person said nothing.
Update #2: Only a PC version available⌠OSX / Linux are in development. Oh wellâŚ
Weâve just deployed the initial version of an API for RubyURL. It makes it really easy to create RubyURLs and is now open to the public. Should it end up being abused, weâll consider introducing an API KEY for authenticating and tracking abuse.
In the meantime, you can now start to use the RubyURL API.
For example, the followingâŚ
After wrestling with some git-remote-branching-merge-problems⌠I remembered this songâŚ
If youâre using git, you might add this to your [alias] section in
.gitconfig.
(notice the up-on-this alias)