Robby on Rails

Managing your Life the Agile Way in 2009

Robby Russell — Sun, 28 Dec 2008 15:20:00 -0600

We’re just a few days away from 2009 and it’s that time when we all start looking back at the last year and set goals for the coming new year. I felt like sharing some of my thoughts on how I’m aiming to approach the new year.

Historically, I’ve never been a huge fan of New Years Resolutions because my attempts were always too big to successfully measure. The goals themselves weren’t poorly thought-out, it’s just that it’s really easy to make a list of personal targets, without putting a lot of emphasis on how you’re going to achieve them. The biggest trouble that I’ve had with goals is allocating enough mental energy for implementation planning. (if only I had someone to and wireframe my life…)

Due to this, New Years Resolutions haven’t been a huge success for me. I’ve found it much too easy to pass the buck onto the usual suspects, which consist of: lack of time, energy, too much work, general life changes, health, etc.

So, for 2009… I’m going to try something different by focusing on a set of best practices that I can use on a daily-basis. I suppose that my main goal is to not place too much emphasis on any specific targets and instead place the responsibility on myself to follow these best-practices and see what good (or bad) comes of it.

By rephrasing my internal conversation from, “What did I achieve this last year?” to “Am I doing things the best that I can?” I am confident that the answer will usually be, “not likely.” I do believe that through this subtle change in context, I’ll be better apt to self-evaluate how (and why) I am doing the things that I do and refactor accordingly. If we’re not consistently Refactoring ourselves (as we do with our code), we’re going to retain a lot inefficiencies in our personal and work lives, which make it difficult for us to quickly respond to changes and opportunities.

Our life (personal and work) is just another project that we manage. Much of methodologies that we spend learning about and adopting can easily be translated to these other areas of our lives.

So as I brace myself for 2009, I find myself asking, How can I lead a more Agile life?

I’d love to hear how you’re adopting best-practices inspired by Agile methodologies in your life and I promise to share mine over the coming year.

Rails 3 and Merb

Robby Russell — Tue, 23 Dec 2008 16:55:00 -0600

So… Rails and Merb are going to be merged into Rails 3. (link)

Has hell frozen over?

(it has in Portland the last week)

I’m curious about how the revised core team will incorporate the library-agnostic view points into Rails without increasing the complexity for configuration. For example, being able to use a different ORM is great, but at the same time, one of the things that I have really liked about Ruby on Rails was that it did make decisions ahead of time for you. Conventions over Configuration and all that jazz. While they intend to keep these defaults, I really wonder how much more configuration will be involved. Be that as it may, Rails and Merb are run by some of the best developers I’ve ever known… so I am sure these decisions will not be made without some deep consideration.

Rails application don’t all look and smell the same, but it’s nice to know that there is consistency across all of our client applications. What I’m concerned about (from an efficiency standpoint) is that this could lead to project-diversity at the cost of experimenting. Pre-Rails, the development teams that I was a part of was constantly trying out new libraries from client project to project, but this came at a huge cost. We weren’t able to leverage our experience with previous projects like our team does with Ruby on Rails currently. (hell, I even helped write two different ORMs in the two years before Rails for PHP… and still wasn’t satisfied)

But, this isn’t so much a technical problem as much as a people problem. The thing is… is that Rails helped solve a people problem with a technical answer. Having testing, consistency, and other best practices built-in did the world a huge favor. ...and all it took was someone like DHH to throw his opinion out there and stick to it. It took me nearly a full year to really embrace a lot of these conventions, but in the end.. it paid off.

While I do feel that it’s in developers best interests to try out new approaches, I just don’t think it should be on your clients dime. This was part of the reason why I quit my last job to start Planet Argon full-time. I really wanted to get away from that cycle.

Since we (Planet Argon) adopted Ruby on Rails four years ago, we’ve been able to build off of every project we had worked on before. We since adopted things like RSpec and JQuery, but our team decided on these changes after someone took the initiative to experiment with these on internal and personal projects. Having this foundation has freed up a lot of our time to focus on other issues as a team, like Interaction Design, Usability, and client collaboration.

As far as Merb itself, I honestly haven’t tried to do anything with it since about 0.2/0.3. I gave up quickly though because the documentation didn’t help me get anywhere and my time is valuable. I’ve since seen that documentation has improved drastically, but I haven’t been able to prioritize the time needed to really play with it. With Merb being merged into Rails 3, it means that I really should spend more time exploring it as we might be able to leverage some of it’s benefits without as much of an investment.

Much of the lack of great interest in Merb was because I felt Rails had consistently provided our team with a solid foundation for a majority of our internal and client applications. The old saying, “if it ain’t broke, don’t fix it.” Not to say that others haven’t expressed a lot of excitement about Merb and it’s benefits, I just didn’t see there being enough of a productivity gain to warrant the time investment required to really learn and use a new framework… and the one thing that I have had trouble with was that it didn’t sound like Merb encouraged a default set of libraries. I could be totally wrong, but that’s been the perception I’ve had based on how it was branded.

But… the best part about this for you, me, and the Rails community? Is that I don’t need to register robbyonmerb.com anytime soon. ;-)

I hope that you’re all having a great end to 2008 and am excited to see all the energy in the Ruby/Rails/Merb community. I suspect that between these two (now-merged) teams, we’ll have an even better platform to develop web applications on. I believe this is great news and I’m all in favor of seeing the Ruby community conquer these challenges that lay ahead.

Anyhow, I’m just thinking out loud. What are your thoughts?

RailsBoxcar.com 2.0

Robby Russell — Wed, 17 Dec 2008 23:55:00 -0600

In case you missed the tweet from Alex ...

Our team just designed, developed, and deployed a new site for, Boxcar, our streamlined deployment environment for Ruby on Rails applications.

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. :-)

Launching Ruby on Rails projects, a checklist

Robby Russell — Sun, 14 Dec 2008 19:28:00 -0600

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 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:

Get your Capistrano or Vlad deployment tasks setup early. Make sure everything works and set it up to work with multiple deployment environments. (staging, production, etc.)
- Use Boxcar Conductor with your Rails Boxcar. (Boxcar Conductor on github)
Use the HTTP Basic Authentication, which is available in Ruby on Rails to keep peeping toms (competitors, search crawlers, spammers, etc.. ) out of your project while you’re deploying to your staging environment. We tend to give out a .htaccess user/pass with this method to the stakeholders so they can access the site whenver they need to.
- Rails documentation on HTTP Basic Authentication: view docs
- Watch a Railscast for using HTTP Basic Authentication: watch screencast
Get your automated tasks (cron jobs) setup way before launch. Verify that things are working here at the right times
- Extra-credit: Check server time settings to make sure you’re not running big tasks at time periods when heavy traffic is expected
Make sure your hosting provider has monitoring setup. It’s good to gauge uptime % from launch
- Extra-credit: Setup your own monitoring with Pingdom or similar service to make sure you know when things are down. (You can audit your hosting provider this way!)

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.

Search Engines and Analytics

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:

Have implemented descriptive page titles and urls
Are ready to track your site visitor’s usage habits from the starting gate
- Conversion goals for obvious things like: sign-ups/registrations, viewing your product tour, contact requests, etc.

When Things Go Wrong / Tracking Exceptions

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.

Tip: Make sure your hosting environment can send out emails! (otherwise, you’ll never know about these problems…eek!)

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.

Non-default 404 and 500 pages

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:

It doesn’t take too long to put something together that is a bit more helpful for your visitors.

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/.

Hold your client’s hands

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)

In Conclusion

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?

AlphaClone on PostgreSQL and Ruby on Rails

Robby Russell — Fri, 12 Dec 2008 08:23:00 -0600

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!

Interviewed by Database Radio Podcast

Robby Russell — Thu, 11 Dec 2008 11:46:00 -0600

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.

You can listen to the podcast mp3 and/or read the transcript.

Lighthouse tickets and Git branching

Robby Russell — Thu, 11 Dec 2008 11:36:00 -0600

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


lighthouse:
  - 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?

The HTTParty has just begun

Robby Russell — Wed, 26 Nov 2008 19:54:00 -0600

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 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.

RubyURL via JSON w/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?

RubyURL via XML w/HTTParty

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

<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<link>
  <website_url>http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb</website_url>
  <permalink>http://rubyurl.com/uJVu</permalink>
</link>

Closing thoughts

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. :-)

Lesson Learned: Git Ref Naming

Robby Russell — Thu, 18 Sep 2008 23:23:00 -0500

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.


git:(master): git show-ref | grep staging
6a18119ca9.... refs/heads/staging
82caa5f121.... refs/remotes/origin/staging
6a18119ca9.... refs/tags/staging

Notice the tag reference at the end? After asking in #git, we were able to remove the tag with the following:

git tag -d staging

Then we needed to remove the reference of staging on Github with git push origin :staging. (we got rid of the remote branch temporarily as well so that we could clean this up).

The next step was to push our local branch back out to the remote branch git push origin staging:staging.... and now we’re back in business with a simple:

git checkout --track -b staging origin/staging

Anyhow, if you end up having those warnings/errors above, you might take a look at git-show-ref to see what is in your local repository as this could be causing you some unnecessary headaches.

Kudos to Allison for taking the time to really read and digest the git documentation, which helped us figure this shit out. :-)

Since we’re still learning to get around through things like this, if you have any more insight into this issue, feel free to help educate us a bit by sharing your wisdom in response to this post. :-)

MySQL is just a toy

Robby Russell — Thu, 11 Sep 2008 13:04:00 -0500

Are you using PostgreSQL? EnterpriseDB want’s to hear your story at Postgres Rocks

Ubiquity meets RubyURL

Robby Russell — Tue, 02 Sep 2008 20:41:00 -0500

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.

Google Chrome: discuss

Robby Russell — Mon, 01 Sep 2008 21:40:00 -0500

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.

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…

The new RubyURL API

Robby Russell — Sun, 31 Aug 2008 13:55:00 -0500

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…


$ curl  -i \ 
        -X POST \
        -H 'Content-Type: application/xml' \
        -d '<link><website_url>http://github.com/robbyrussell</website_url></link>' \
        http://rubyurl.com/api/links  


	...would return the following response.




	I’ll be updating the ShortURL gem in the coming days (unless someone else wants to patch it first wink) to take advantage of new API, versus how it’s currently creating RubyURLs.


	You can see the code & changes for this new API on the RubyURL github site.


	Update with JSON


	I took a little time today to update the API and extend it to support JSON. So… you can now use the RubyURL API to generate RubyURLs via JSON. (see commits)




	Enjoy! If you’re using RubyURL via the new API, I’d love to hear about it. :-)



Flash Message Conductor
Robby Russell — Fri, 29 Aug 2008 16:35:00 -0500
Do you find yourself copying and pasting the same code from Rails application-to-application as new projects start? Our team has a handful of projects in development right now and we notice that some of these reusable components tend to get out of sync when we bounce between projects. So, we’re making an effort to spot these and are creating a handful of plugins so that we can keep them updated between projects. (I’m sure that a lot of you do this as well)


	In an effort to share some of our patterns, we’ll try to release them into the wild for others to use and perhaps if you have better patterns to offer, we’re always interested in improving our approach.


	Introducing Flash Message Conductor


	Over the years, our designers and developers have approached the management of flash messages several different ways. In Rails, the default way to add something to a flash message is to do something like this in your controller.


flash[:message] = "You have successfully signed in to your account."

	What we began doing a while back is to create a few controller helper methods:


add_message( "You have successfully signed in to your account." )
add_notice( "You've Got Mail!" )
add_error( "Oops! Something got fucked up!" )

	Really, nothing too crazy here, just a pattern that our developers have preferred to managing our application’s flash messages.


	Okay, so now for the part of the puzzle that we aimed to make consistent across our projects. Rendering flash messages would usually result in several lines of conditionals in our application layout to check if the flash had any values assigned to it. As we worked with our HTML/CSS designers to define a consistent pattern, we moved our code into a helper for rendering flash messages.


	With Flash Message Conductor, we just need to pop in the following into our application layout.


<%= render_flash_messages %>

	If we had called add_message, it’d render the following:


<div id="flash_messages">
  <p class="message">You have successfully done XYZ...</p>
</div>

	Or, should you have called add_error, it’d render the following:


<div id="flash_messages">
  <p class="error">Oops! Something went bonkers!</p>
</div>

	What we’ve done here is defined a consistent pattern for our designers and developers to follow. We’ll always have a div container that will use a p tag to display the flash messages with a CSS class value that maps to the type of flash message that we’re displaying. This makes it easier for us to reuse the same flash message styling (and tweak if necessary), but we know that it’ll produce the same HTML across our applications.


	Installing Flash Message Conductor


	Like most modern Rails applications, you can install with:



script/plugin install git://github.com/planetargon/flash-message-conductor.git


	Then all of our helper methods will be available to your application. We’ve also included an example CSS file, which you’ll find in the plugin directory.


	Sample output:



Uploaded with plasq’s Skitch!

	Anyhow, we’ve posted the plugin up on GitHub for you all to use, if you’d like to adopt a similar approach. If you have any alternative patterns that has helped your team, do share and I’m looking forward to sharing some more of ours in the near future.


	For more information, visit the Flash Message Conductor plugin on GitHub.


	If anything, hopefully this will inspire those of you who find yourself copying/pasting artifacts from application-to-application to extract that code into it’s own reusable plugin. :-)

   



Git: Push it! (real good)
Robby Russell — Fri, 29 Aug 2008 13:23:00 -0500
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)



   



RSpec: It Should Behave Like
Robby Russell — Tue, 19 Aug 2008 21:47:00 -0500
I was going through an older project of ours and cleaning up some specs and noticed how often we were doing the same thing in several places. When we started the project, we didn’t get the benefits of shared groups. Now that we have some time to go through and update some of our older specs, I’ve been trying to take advantage of the features currently available in RSpec. One feature that I haven’t seen a lot of mention of by people is shared groups, so I thought I’d take a few minutes to write up a quick intro to using it.


	To pick some low-hanging fruit, let’s take an all-too-familiar method, which you might be familiar with… login_required. Sound familiar? Have you found yourself stubbing login_required over and over throughout your specs?


describe Admin::DohickiesController, 'index' do

  before( :each ) do
    controller.stub!( :login_required )
    Dohicky.should_receive( :paginate ).and_return( Array.new )
    get :index
  end

 ...
end

	If you’re requiring that a user should be logged in when interacting with most of the application (as in the case of an administration section/namespace), you might want to consolidate some of your work into one shared specification group. The basic premise behind this is that you can write a typical describe block and load it into any other spec groups that you need. For example, in our case, we’ll need to stub login_required in several places. We can set this up in one shared group and reference it wherever necessary.


	For example, here is what we’ll start off with.


describe "an admin user is signed in" do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

describe Admin::DohickiesController, 'index' do
  ...

	However, the new describe block isn’t accessible from the block at the bottom of the example… yet. To do this, we just need to pass the option: :shared => true as you’ll see in the following example.


describe "an admin user is signed in", :shared => true do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

	Great, now we can reference it by referring to it with: it_should_behave_like SharedGroupName. In our example above, this would look like:


describe "an admin user is signed in" do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

describe Admin::DohickiesController, 'index' do
  it_should_behave_like "an admin user is signed in"

  before( :each ) do
    Dohicky.should_receive( :paginate ).and_return( Array.new )
    get :index
  end

 ...
end

describe Admin::DohickiesController, 'new' do
  it_should_behave_like "an admin user is signed in"

  before( :each ) do
    @dohicky = mock_model( Dohicky )
    Dohicky.should_receive( :new ).and_return( @dohicky )
    get :new
  end

  ...

	That’s it! Pretty simple, eh? We can now reference this shared group in any describe blocks that we want to. A benefit to this approach is that we can make change the authentication system (say, we decide to switch it entirely and/or even just change method names, set any other prerequisites necessary when an admin is signed in), we’ll have a single place to change in our specs. (tip: you can put these in your spec_helper file)


	You can learn more about it_should_behave_like and other helpful features on the RSpec documentation site.


	If you have any suggestions on better ways of handling things like this, please follow up and share your solutions. I’m always looking to sharpen my tools. :-)


	Update


	In response, Bryan Helmkamp suggests that a better solution is to define a method in our specs like, for example: build_mock_user_and_login. then calling it in our before(:each). So, maybe the approach above isn’t the most ideal method but I did wantt o draw some attention to it_should_behave_like. I suppose that I need a better example.. another post, perhaps? :-)


	Also, Ed Spencer has posted an article titled, DRYing up your CRUD controller RSpecs, which will introduce you mor to it_should_behave_like.


	Thanks for feedback people!


	Related Posts


	
	Be Careful that you don’t Stub your Big Toe
		Spec Your Views
	

   



Things.app syncs with the iPhone!
Robby Russell — Mon, 18 Aug 2008 23:18:00 -0500
Awesome. Things 1.1 for the iPhone was just pushed to the Apple iTunes Store, which means… I can finally sync my Things.app with my iPhone!


	


	I’ve been using Things for quite a while to manage my life (work and personal) and bringing this to my phone definitely makes my day.


	


	For more information about Things, visit the following sites:


	
	http://culturedcode.com/things/ (Things for OSX)
		Things (iPhone)
	


	I’ll post a review in the coming days as I get a chance to play with it. Just wanted to share the news. :-)

   



Alan Cooper @ Agile2008 slides
Robby Russell — Tue, 12 Aug 2008 18:19:00 -0500
Alan Cooper, author of About Face, has slides from his presentation at Agile 2008 online.


	
	The Wisdom of Experience
	


	If anybody knows if there is video of this talk, please let me know. :-)


	Here are a few skitches from the slideshow.











   



Expanding Rails Boxcar packages
Robby Russell — Mon, 04 Aug 2008 09:30:00 -0500
If you’re in the market for a new hosting provider for your Ruby on Rails application, you might take a look at the new options for Rails Boxcar. We recently expanded our service offerings into three pricing tiers as well as custom packages for those who need a bit more.


	


	A few things that we’ve recently added support for:


	
	Provide us your SSH key during sign up!
	
	Allows us to keep your server even more secure by avoiding sending passwords over the net
		Other fun features related to this coming soon
	
	
		Auto-configured Nginx w/Mongrel cluster
		Phusion Passenger (mod_rails) support! (for those with mixed-environments)
		Continued development of Boxcar Conductor)
		...more in the works!
	


	The best part is that we can get you up and running with a new Boxcar now for as low as $59/month USD.


	For more information, visit: http://railsboxcar.com


	If you have any questions, don’t hesitate to contact us.

   



Pair Programming and Micro Projects
Robby Russell — Thu, 31 Jul 2008 21:55:00 -0500
It’s been quiet because I’ve been busy over the past few months. Projects, vacations, and pair programming with our new developer, Nigel. ;-)


	


	In other news, Chris and I launched http://ohmyscience.org (on twitter) in an effort to get a small one-night micro-project out the door.




	I have a growing list of a few micro-projects that I hope to be helping get developed and launched before the summer is over. Stay tuned!




	I hope that you’re all enjoying your summer!

   



ShortURL on Github
Robby Russell — Thu, 24 Jul 2008 10:56:00 -0500
After noticing a few patch requests on Rubyforge.. I decided that I’d put the ShortURL gem up on GitHub as I spend quite a bit of my time there these days. :-)


	
	http://github.com/robbyrussell/shorturl/tree
	


	I’ve also thrown up a few lines of code so that you can get the gist of the gem. ;-)



   



Ruby 1.8.7 on MacPorts causing some problems
Robby Russell — Fri, 20 Jun 2008 16:11:00 -0500
It appears that MacPorts has upgraded to Ruby 1.8.7, which is good news if you’re running Rails 2.1… but if you have an older Rails application… it’s not going to work too well.


	In order to get Ruby 1.8.6 installed with the latest MacPorts, you’ll need to do the following.



  $ mkdir /Users/Shared/dports



$ svn checkout -r 36429 \ 
    http://svn.macports.org/repository/macports/trunk/dports/lang/ruby/ \ 
    /Users/Shared/dports/lang/ruby/


	Then you’ll need to modify your macports to use this new local source. You’ll need to edit /opt/local/etc/macports/sources.conf  and add the following line above the existing rsync record.


	file:///Users/Shared/dports and create that directory


	Next, you’ll want to index this new local source with the following command:


	portindex /Users/Shared/dports


	After that, you can do the following.


	sudo port uninstall rb-rubygems ruby


	sudo port clean rb-rubygems ruby


	sudo rm -r /opt/local/lib/ruby/gems/1.8/doc/rubygems-1.1.1/


	sudo port deactivate autoconf


	sudo port install ruby rb-rubygems


	..and hopefully you’ll have Ruby 1.8.6 installed and be able to retain the rubygems you installed already.

   



Basecamp...
Robby Russell — Wed, 04 Jun 2008 12:13:00 -0500
Kudos to the 37signals team for launching what looks like a nice way to get the word out about their products.


	I’ve been using Basecamp for three years and it’s been a great tool for collaborating with our clients.


	


	Disclaimer: This is my get-rich-quick scheme for the day.

   



New Boxcar plans announced!
Robby Russell — Fri, 30 May 2008 14:30:00 -0500
Yesterday we announced our new suite of plans for Rails Boxcar. You can now get started with a pre-configured VPS designed by Rails developers like you for as low as $59/month.


	You can check out our new rates here:


	
	http://railsboxcar.com
	


	If you’re at RailsConf, be sure to introduce yourself and ask for details. :-)

Robby on Rails

Managing your Life the Agile Way in 2009

Related Posts

Rails 3 and Merb

RailsBoxcar.com 2.0

Launching Ruby on Rails projects, a checklist

Hosting

Search Engines and Analytics

When Things Go Wrong / Tracking Exceptions

Non-default 404 and 500 pages

Hold your client’s hands

In Conclusion

Related Articles

AlphaClone on PostgreSQL and Ruby on Rails

Interviewed by Database Radio Podcast

Lighthouse tickets and Git branching

Related Posts

The HTTParty has just begun

Install HTTParty

Talking to the RubyURL API

RubyURL via JSON w/HTTParty

RubyURL via XML w/HTTParty

Closing thoughts

Lesson Learned: Git Ref Naming

MySQL is just a toy

Ubiquity meets RubyURL

Related Posts

Google Chrome: discuss

The new RubyURL API

Update with JSON

Flash Message Conductor

Introducing Flash Message Conductor

Installing Flash Message Conductor

Git: Push it! (real good)

RSpec: It Should Behave Like

Update

Related Posts

Things.app syncs with the iPhone!

Alan Cooper @ Agile2008 slides

Expanding Rails Boxcar packages

Pair Programming and Micro Projects

ShortURL on Github

Ruby 1.8.7 on MacPorts causing some problems

Basecamp...

New Boxcar plans announced!