Robby on Rails: Tag planetargon

Boxcar Conductor: Rails deployment made easy

Robby Russell — Tue, 15 Apr 2008 12:16:00 -0500

In a previous post, I showed how we’ve been working on an interactive deployment process for Rails applications to reduce the time it takes to deploy to a Boxcar.

We began to move our Boxcar deployment recipes into it’s own Rails plugin and just made it available on GitHub.

Introducing Boxcar Conductor

The Boxcar Conductor plugin aims to automate the entire process for deploying to your Boxcar. We’re down to just a few simple commands to run to get your application up and running. While mileage may vary with other hosting providers, we did want to open up this work to the community and centralize our work with the community of Boxcar customers who have helped us build and test these tools.

Install Boxcar Conductor

If you’re running on Edge Rails… you can take advantage of the new support for installing plugins in git repositories.


  $ ./script/plugin install git://github.com/robbyrussell/boxcar-conductor.git

note: If you’re not using edge rails, you can download a tarball and install the plugin manually.

Installing the plugin will add a custom Capfile and config/deploy.rb, which has a few things for you to define based on your Boxcar subscription.

Configure Your Boxcar

Once the plugin is installed, you can run the following task:


  $ cap boxcar:config

This will ask you a few questions about your deployment needs.

Uploaded with plasq’s Skitch!

Which database server will you be using? (along with db user/pass info)
How many mongrels should run in your cluster?

After a few quick multiple choice answers, you’re application is ready to be deployed and you can run an Boxcar-specific deployment task.


  $ cap deploy

We’ve also created a new public project on Lighthouse so that you can submit tickets and ideas to us. With Boxcar, we’re really aiming to remove as many steps from the deployment process that aren’t necessary.

To follow along, visit the project on lighthouse or GitHub.

If you’re interested in learning more about Rails Boxcar, feel free to drop us a line.

Portland is calling... (you)

Robby Russell — Fri, 11 Apr 2008 01:30:00 -0500

We’re not looking for rock stars or ninjas at Planet Argon. ;-)

We’re looking for individuals that share our core values.

COLLABORATION – We believe that an open dialogue between all members of a group helps to produce more reasoned and intelligent decisions.
ENTHUSIASM – We recognize the unique power of people who are passionate about their craft. We believe that fun is an essential ingredient in a collaborative and vibrant company culture. We think happy people make better software.
COMMUNITY – We are part of many communities. Our neighborhoods, our cities, our workplace, and our professional communities. We give back to our communities by implementing socially responsible business practices and sharing our knowledge and tools with our peers.
VERSATILITY – We believe that it is important for our team to be open and flexible, as well as the work that we do. This allows us to adapt to change and encourage innovation.
EXECUTION – We value action and when people make things happen. It is important that we follow through on our commitments, plans, and ideas.

..maybe you’re a .NET/Java/PHP/Python developer (who secretly plays with Ruby on Rails at night/weekends). We’re looking for an intermediate-level Rails developer to join our team. Ideal candidates would be in the Portland, Oregon area or willing to relocate.

If you’re interested, take a moment and introduce yourself.

Managing Required Gems on Rails Projects

Robby Russell — Wed, 26 Mar 2008 22:27:00 -0500

We’re starting a new project and I’m finding myself adding things to the code base that we’ve done in the past… hence the last few posts. As we’re doing this, I’d like to highlight some of the little things that we do on each project to maintain some consistency and in that process reach out to the community for alternative approaches.

I’m intrigued by the vendor everything concept, but we haven’t yet adopted this on any of our projects (yet).

What we have been doing is to maintain a REQUIRED_GEMS file in the root directory of our Rails application.

For example:


$ cat REQUIRED_GEMS

actionmailer
actionpack
actionwebservice
activerecord
activesupport
cgi_multipart_eof_fix
daemons
fastercsv
fastthread
feedtools
gem_plugin
image_science
mongrel
mongrel_cluster
mysql
rails
rake
RedCloth
Ruby-MemCache
soap4r
uuidtools

Everybody on the team (designers/developers) knows to look here to make sure they have everything installed when beginning to work on the application.

This has worked fairly well from project to project but since we’re starting a new project, I’m curious if anybody has some better ways to approach this. Should we look more seriously at the vendor everything approach or are there any alternative approaches?

Learning Git without getting your SVN feet wet

Robby Russell — Tue, 11 Mar 2008 01:59:00 -0500

Our team has been migrating towards using Git as our primary SCM. We have way too many Subversion-based projects and repositories to just do a clean switch over and not everybody on the team has had time to start playing with it. Baby-steps…

So, for those of us who want to use it day-to-day, we’re using git-svn.

Andy Delcambre has posted the first in a series of blog articles to help you pick up on using Git on Subversion-based projects. Check out his article, Git SVN workflow to get up to speed.

Also, if you’re on OSX and using Git… check out Justin Palmer’s new project, GitNub, which describes itself as, “a Gitk-like application written in RubyCocoa that looks like it belongs on a Mac.” This looks promising. :-)

Heading to London, grab a pint?

Robby Russell — Fri, 18 Jan 2008 01:55:00 -0600

Just when you think that you’re sneaking through Fall/Winter without getting sick… it hits you. Been sick the last week and am finally coming up for air. :-)

Anyhow, I’m going to be traveling a few times over the coming weeks/months and wanted to reach out…

Dear Londoners,

A few of us from the Planet Argon team, (Andy, Paige, and myself) are heading to London in just over a week to visit one of our big clients. We’ll also be staying for a few more days to explore. If you’re interested in grabbing a few pints and/or interested in meeting up, drop me an email we’ll try to coordinate something when we’re over there. =)

Moved to our new studio

Robby Russell — Wed, 21 Nov 2007 08:56:00 -0600

One of the reasons why I’ve been too busy to write on my blog lately is that we recently moved into to a new studio. We had a lot of preparation to do before we moved in and are finally getting settled in the new space.

We took the space from…

To this…

As you can see.. we have lots of natural light for the entire team…

I think that Chris Griffin shares the same excitement that I do about the new space. ;-)

We’ll be posting more photos on the Planet Argon flickr stream over the coming weeks as we get the studio organized. :-)

Multiple Database Connections in Ruby on Rails

Robby Russell — Fri, 05 Oct 2007 17:54:00 -0500

We have a client that already has some database replication going on in their deployment and needed to have most of their Ruby on Rails application pull from slave servers, but the few writes would go to the master, which would then end up in their slaves.

So, I was able to quickly extend ActiveRecord with just two methods to achieve this. Anyhow, earlier today, someone in #caboose asked if there was any solutions to this and it prompted me to finally package this up into a quick and dirty Rails plugin.

Introducing… Active Delegate!

To install, do the following:


cd vendor/plugins;
piston import http://svn.planetargon.org/rails/plugins/active_delegate

Next, you’ll need to create another database entry in your database.yml.


login: &login
  adapter: postgresql
  host: localhost
  port: 5432

development:
  database: rubyurl_development
  <<: *login

test:
  database: rubyurl_test
  <<: *login

production:
  database: rubyurl_servant
  <<: *login

# NOTICE THE NEXT ENTRY/KEY
master_database:
  database: rubyurl_master
  <<: *login

At this point, your Rails application won’t talk to the master_database, because nothing is being told to connect to it. So, the current solution with Active Delegate is to create an ActiveRecord model that will act as a connection handler.


  # app/models/master_database.rb
  class MasterDatabase < ActiveRecord::Base
    handles_connection_for :master_database # <-- this matches the key from our database.yml
  end

Now, in the model(s) that we’ll want to have talk to this database, we’ll do add the following.


  # app/models/animal.rb
  class Animal < ActiveRecord::Base
     delegates_connection_to :master_database, :on => [:create, :save, :destroy]
  end

Now, when your application performs a create, save, or destroy, it’ll talk to the master database and your find calls will retrieve data from your servant database.

It’s late on a Friday afternoon and I felt compelled to toss this up for everyone. I think that this could be improved quite a bit, but it’s working great for the original problem that needed to be solved.

If you have feedback and/or bugs, please send us tickets.

PLANET ARGON is seeking fresh talent... could it be you?

Robby Russell — Thu, 04 Oct 2007 10:10:00 -0500

My blog has been fairly quiet lately because our team has been busy helping push a few big client projects out the door. We’ll be posting announcements about those launches on the PLANET ARGON Blog soon, so stay-tuned there!

We’ve been growing the design-side of our team lately, but we’re also still seeking some more Rails-talent in Portland, OR. If you’re in Portland or interested in moving here¹, you should introduce yourself to our team. We’re looking for people to work on-site in Portland, so any remote candidates will be turned away… we’re moving into a shiny and new office space in downtown and are looking for another developer to join our Design and Development team.

you’ll fit in really well if you’re into outdoor activities… ;-)

We’re seeking mid-level Ruby on Rails developers that can pick things up quickly. Having some experience with RSpec will go along way with us. Ideal candidates would have great communication skills and be able to work in a fast-paced environment that places a huge emphasis on collaboration between designers and developers (let’s not forget to mention our clients). Bring what you already know and learn the rest with us.

While everyone might have Wii’s in the office, we’ve taken it to the next level with Speed Stacking! :-p

To apply, send an email to af22+8509@c1.catchthebest.com,

Side note: We’re giving Catch the Best a whirl to review job candidates. If you’re hiring people, you might consider giving it a try.

¹ Everybody is moving to Portland… ;-)

Collaborative Bookmarking... UNLEASHED

Robby Russell — Tue, 21 Aug 2007 22:26:00 -0500

Like many… I’ve been using del.icio.us for several years and so have some of my closest colleagues. A few of us at PLANET ARGON have been using the for:username tag to send each other links, which has been a great productivity hack as we don’t need to copy URLs and paste them into emails, IMs, or IRC channel windows anymore. One of the things that del.icio.us doesn’t have a totally perfect implementation is sending to a group. There are people in your network, but to my knowledge, there isn’t a way to send everyone in a network the same link without selecting everyone individually. This was adding more time to the process of saving a link for ourselves and our fellow team members. So, we came up with a clever hack… a new delicious user account.

Over the past four months, our team has bookmarked almost four hundred links on topics ranging from Rails plugins, Interaction Design, Business processes, cool new web applications, to any variety of things that we find relevant to our team.

So, all of the links are being sent to a fake user. How do we see the links for that user without having to logout of our current user and into the planetargon account? Well, what we’ve done is take the delicious RSS feed and pipe it through feedburner and given everyone the URL that feedburner provides. Now, we’re all able to subscribe to the same feed and check out links when each of us has time for it.

...and this is what I get to see show up in my RSS reader. :-)

How is your team managing bookmarks? :-)

Rails Code Audits and Reviews, continued

Robby Russell — Mon, 18 Jun 2007 12:47:00 -0500

In response to my article, Audit Your Rails Development Team, Tim Case writes,

“I think what you are doing has value and I’ve been anticipating that someone in the rails community would step up and do this, hence the question I posed because I’ve thought about that thorny issue too. I have a feeling Planet Argon is making the first step in a direction that has been building, Peer review has the potential to be positive for the entire community, provided that it’s shepherded properly and with care.”

It’s been just over a year since we first made a public announcement of our Rails Code Audit and Review service and we’ve had different types of clients inquire about it. We make sure to call it a code audit and review because we’re not aiming to only point out flaws. We see our service as a way to help stake holders gauge the capabilities of their developers while also providing developers with some more insight to how things could be done differently. There are a lot of developers using Ruby on Rails now and it’s safe to say that there are many that aren’t very good yet. Some may argue that the ease of getting started with Rails makes it easy for inexperienced developers to stay just good enough and never take the next step. We’ve seen some beautiful code and we’ve seen some horrific code. Some of our clients have made the tough decision to fire their existing freelancers after we’ve completed our analysis… but we’ve seen several situations where our clients were happier with their developers after.

For example, we recently completed a code audit and review for a client, which came to us with some concerns about their development team. Things seemed to be going slower than they thought it would and really wanted to have an outside opinion about the quality of their work. Overall, their application was being developed really well and the biggest problems that they had were related to a lack of testing. So, we’re now walking them through the process of integrating RSpec into their development process. Their development team admitted that they suffered from a lack of testing, but were very honest about the fact that they just didn’t know where to begin as it wasn’t something they had time to learn before. We’ve been able to provide them with some direction and now we’re available to answer questions and review their work from time to time. The outcome was good for everyone. The developers are better off because their manager has more confidence in them. The manager has more confidence in the product as a whole and knows exactly where his team should focus their attention on next. We’ve gained a new Rails consulting client and get to help them with their cool project.

While we love working on entire projects from start to finish, we also love working with other developers and development teams. This has been one of our favorite types of client relationships. We’re currently working with a handful of people as they work their way through the project life cycle and we’re always a phone call, Basecamp message, or email away from assisting them. I feel that these types of services are important to the Rails community, because we’ve witnessed situations where clients were unhappy with Rails because they weren’t happy with their developers. We’ve seen people drop Rails in favor of something else because of the poor quality of code that was being written in Rails. When bad perceptions spread, it’s bad for the community as a whole.

What we can do, is become the backup team for the client and/or development team. Should they run into any weird deployment issues at 2am on a Sunday morning or aren’t able to track down the cause of some performance issue, we’re another set of people that can help out. While we don’t know every nook and cranny of our consulting clients’ applications, we do have a good understanding of them. This allows us to dive in and help more quickly than we can for clients that call us for the first time a few hours after they had an emergency.

It’s my opinion that these types of services are very valuable and highly encourage other consultancies in the Rails community to offer them.

If you’re part of a development team and/or a freelance developer and looking for this sort of relationship, please contact us to see how we can assist you.

Rails Business: Weekly Review #2

Robby Russell — Mon, 18 Jun 2007 01:26:00 -0500

First of all, I’d like to welcome the more than fifty people that have joined the Rails Business group since my last post. Over the past week, there were less posts, but we did cover a few important topics, which may be of interest to you.

Subcontracting

Michael Breen asked a few questions about subcontracting for larger firms and how people set their rates when doing this. Several of the responses provided some personal experiences (good and bad) of being a subcontractor on large projects. Where some risks are and how to negotiate your rates, when applicable.

Read the discussion

Change Requests

Nick Coyne started a discussion on how to manage change requests in an Agile development process.

Dealing with large clients

There was also a discussion about how to go about responding to a 150 page RFP for a large client. A few of us offered our experiences of bidding on large projects. Read more

Join the Community

The list is about to pass 400 members and it’s already proving to be a valuable resource for all of you entrepreneurs out there. I encourage you all to introduce yourself.

For more info: http://groups.google.com/group/rails-business

Hug Your Designer Day, part 2

Robby Russell — Wed, 23 May 2007 17:04:00 -0500

In an effort to increase awareness of the importance of good Interaction and Interface Design in Web Development… I suggested that today be... Hug Your Designer Day.

Designers Versus Developers

Are you seeing a lot of this in your Design and Development teams?

Allison Beckwith, Experience Director and Graeme Nelson, Lead Architect

Happy Designers and Happy Developers

Well, maybe it’s time that your developers gave your designers a hug…

Alain Bloch, Web Developer and Chris Griffin, User Interface Designer

Also… to celebrate Hug Your Designer Day, Amy Hoy was kind enough to post her slides and some audio that I recorded of her talk at RailsConf 07.

Let’s all take a moment to thank the designers who put the experience of the users first. The success of our projects rely on everyone working together. Hug Your Designer! (they might hug back…)

Heading to Portland for RailsConf... by foot

Robby Russell — Wed, 16 May 2007 17:21:00 -0500

Yay! It’s almost conference time… and I’m almost completely thrilled!

Why am I not more thrilled? Well, mainly because RailsConf is being hosted here in Portland, which means that I don’t get to travel by train like we did last year via The Argon Express. (ah… the memories)

One perk of being here already… is that I get to act as a tour guide to visitors. For example, earlier today… Josh Susser (hasmanyjosh) joined Graeme and I for lunch in downtown Portland, OR. It was exciting to hear about how he and his fellow Rubyists at Powerset are using Ruby and Rails for various projects. John also spent a few minutes introducing us to Merb, which some people think will become popular in near future. We’re expecting more visitors to come by the offices over the next few days.

If you’re in Portland already (Wednesday)... you might head over to the Lucky Lab for a game of Werewolf, which I believe Michael Buffington is organizing the event. I’m going to try to make it… maybe I’ll see you there!

Flickr Group

I created a flickr group named RailsConf 2007, and started to use the tag railsconf2007 for flickr photos. I look forward to seeing all your photos from the event!

IRC Channel

As of this afternoon, there are almost 20 people hanging out in #railsconf on freenode. Stop by and introduce yourself!

Portland Revealed

If you haven’t already subscribed to our feed, you might have missed that the PLANET ARGON team has been posting several articles about things to do, see, and drink in Portland during your visit to RailsConf. Here are a few that we’ve posted so far.

You can also peak around GoSeeOregon (a Rails application!) to find places around town to go see.

RailsConf is coming to Beertown

Robby Russell — Thu, 10 May 2007 13:05:00 -0500

The team at PLANET ARGON is continuing a series of blog posts for all of you who are coming to Portland, Oregon for RailsConf 2007. Allison just posted Portland Revealed: Episode 2: Beertown, which provides a list of places to get good beer in Portland… starting at the PDX Airport to other places around the conference center. We even through in a platial map to make the beer hunt easier for you. :-)

View all Portland Revealed articles

Happy Birthday Allison

Robby Russell — Wed, 28 Mar 2007 20:53:00 -0500

This morning was delightful. I woke up to find that 37signals had referenced our website on Signal vs Noise this morning. In particular, they referenced the Rails hosting order form on the PLANET ARGON site. What’s interesting is that Allison created this design over a year and a half ago.. and we’re actually in the process of a complete site redesign, which Chris and Allison are planning to blog about in depth. :-)

There are some discussions within the comments on the blog post about the design decisions that were made, some of which we’ve already begun to address in our redesign process brainstorming (based on google analytic conversion data).

On top of that, today is our Experience Director, Allison Beckwith’s, birthday.

Thanks for the linkage, 37signals!

...and… Happy Birthday Allison!

Meet... Chris, Graeme., and Gary

Robby Russell — Mon, 26 Feb 2007 11:01:00 -0600

Okay, this is a little overdue… but better late than never! ;-)

We’ve had several new people start with PLANET ARGON over the past few months. Some of them are blogging about their experience of working with Ruby on Rails and being a part of our team. I wanted to quickly introduce you to a few of them and their blogs, which I hope that you consider subscribing to.

Chris

For quite some time, we’ve been needing more design assistance, so late last year… we hired Chris Griffin, who moved here last year from Florida. He’s our new User Interface Designer and gets to work within the Rails environment everyday with the rest of us. It seems that Brian and Chris worked over the weekend to get his new blog up. Chris is self-proclaimed genius. I suggest that you keep an eye on his blog… because I’m sure it’s going to be a pretty active one. Chris joining our team marks a pivotal point in our teams evolution as we continue to place more emphasis in our Design and Development process on the User Experience.

http://chriszgriffin.com/

Graeme

Our newest hire is Graeme Nelson, who recently moved to Portland from Seattle. He just joined our Design and Development team and if you’ve been reading the Rails-related blogs, you might have seen his blog already. He’s been blogging a lot about using RSpec with Rails and other fun things. He’s been contracting with us since the start of the year and I’m really excited that he’s accepted a job offer and joined the team!

http://blog.imperialdune.com/

Gary

Last… but not least is Gary Blessington. I believe that I first offered Gary a job with PLANET ARGON about 2 1/2 years ago when we were still focused on PHP/PostgreSQL…. but PHP apparently wasn’t enough of a catalyst. Gary and I previously worked together at Imark Communications several years ago, when I first started doing web development. He was the senior developer on the team and was an important mentor during my early days of developing in a professional environment. Late last year, he hung up his .NET tool belt to become our Design and Development Director. He started blogging earlier this year and is sharing his experience of switching from .NET to Ruby on Rails.

http://garyblessington.us/.

I’ll introduce the others as they start blogging and such. :-)

Happy holidays!

Robby Russell — Sat, 23 Dec 2006 11:22:00 -0600

Yesterday, those of us who were still at the PLANET ARGON office (and not already on vacation) took the afternoon off yesterday to have a few drinks to kick-start the holiday season.

I’m getting ready to head up to Seattle for the holiday weekend. I hope that you all have a safe and fun holiday season!

Portland Public Transporation and the Zen of Office Management

Robby Russell — Tue, 10 Oct 2006 12:33:00 -0500

One of the coolest parts about my job (aside working with cool people everyday)... is getting a say in where we spend some of our money as a company. One of the things that Allison and I decided that we really wanted to do as a company was encourage sustainable business and growth in our local community. Everyone here loves Portland, Oregon.

This screenshot was taken after we took headshots for our transportation passes.

Our awesome Office Manager, Nicole Fritz has started a blog, which she plans to, ”...not only to let people know what goes on behind the scenes at PA, but to give other startups hints and tips about cool admin things that I have learned along the way (from taxes to how to get the right people “on the bus”).”

Nicole has posted an article, which introduces people to some of the great tax credits that small businesses like PLANET ARGON can take advantage of… in particular how we are now taking advantage of a tax credit for public transportation, bike storage, carpool programs, and more.

If you’re a customer of ours or are running a small business… you might consider subscribing to her feed.

Meeting up in London

Robby Russell — Mon, 11 Sep 2006 21:09:00 -0500

I’m leaving for London tomorrow. Thank you all for your responses to my travel security questions. I really appreciate it. :-)

I’m going to be getting in on Wednesday afternoon and am going to try to meet up with people at PizzaOnRails.

Thurs-Fri is RailsConf fun… but I haven’t figured out what I will be doing over the weekend. I’m leaving for New York on Tuesday.

Does anybody know of any good vegetarian places that I should go out of my way to try in London? Interested in hanging out and talking shop? Email me! :-)

New Business Card

Robby Russell — Mon, 11 Sep 2006 10:51:00 -0500

Figured that I might as well follow in the footsteps of Luke Redpath and show you my new business cards.

Our Creative Direcrtor, Allison Beckwith felt that it was time for a redesign. I should try to snap a shot of all the past PLANET ARGON cards. We have them up on a wall in chronological order… dating back four years ago this month.

Since we were doing double-sided this time I wanted to be sure that there was enough space for writing on the back… which helps with writing down a note, giving someone a coupon code for hosting, or my cell phone number if they are special enough. :-)

Leaving on a Jet Plane...

Robby Russell — Fri, 01 Sep 2006 19:01:00 -0500

Just got my confirmation email…

Your payment of £616.88, has been received and your RailsConf Europe 2006 registration is now complete

Ouch! In USD… this translates…

UK£ 616.88 = $1175.21809 U.S. dollars

Sheesh.

So, I am going to be heading to sunny London, UK on September 12th for the RailsConf Europe. In fact, I’ll be traveling for about two full weeks in September as I will be heading to London for the conference and to wander around for a few extra days. Then I will be flying to New York City on the 17th or 18th for almost a week where I will be working with one of our clients for a few days and spending the weekend sightseeing.

If you’re interested in meeting up with me in either London or New York during these trips… email me. :-)

james.adam: hey, there's a small possibilty that i might be in NY at the same time as you too!

robby: heh. cool

james.adam: that would be 3 weekends in a row. people will talk

Knowing Me, Knowing You, part 2

Robby Russell — Tue, 29 Aug 2006 20:16:00 -0500

Earlier this month, I posted the first in the series of Knowing Me, Knowing You. In this second post, I would like to take you inside the PLANET ARGON office. More specifically… I would like to list all the books that I found on peoples desks. These aren’t books that are sitting on the bookshelves… but books that are sitting within arms reach of the employees at PLANET ARGON.

Here goes with some links to our favorite Independent bookstore, Powells.

About Face 2.0, by Alan Cooper
Activity-Centered Design, by Geri Gay
Another Roadside Attraction, by Tom Robbins
DNS & Bind Cookbook, by Cricket Liu
Mastering the Requirements Process, Suzanne Robertson
Mind Hacks, by Tom Stafford
New Utopians a Study of System Design, by Robert Boguslaw
Pragmatic Version Control: Using Subversion, by Mike Mason
Practices of an Agile Developer, by Venkat Subramaniam and Andy Hunt
Programming Ruby, by Dave Thomas
Rails Recipes , by Chad Fowler
RT Essentials, by Jesse Vincent
Thoughtful Interaction Design, by Jonas Lowgren

Care to take a guess at who is reading what?

Your Turn

Take a look around your workspace... which books are within arms reach. Right now. :-)

Testing Cookies in Ruby on Rails

Robby Russell — Mon, 28 Aug 2006 08:27:00 -0500

Over the weekend, Brian Ford released a useful plugin for testing your Ruby on Rails applications called, assert_cookie.

Brian likes his cookies…

“I love cookies. There are, of course, tons of varieties and I’m no connoisseur but I love the soft chocolate chip right out of the oven, hot and gooey. But, if you’re like me, you don’t want your Rails code to be gooey.” -Brian Ford

To use assert_cookie, follow these steps.

Install via, script/plugin install http://svn.planetargon.org/rails/plugins/assert_cookie
Fill your tests with some cookies
Test your cookies!

Here are a few examples that Brian posted.

  assert_cookie :pass, 
      :value => lambda { |value| UUID.parse(value).valid? }
  assert_cookie :yellow, :value => ['sunny', 'days']
  assert_cookie :delight, :value => 'yum'
  assert_cookie :secret, :path => lambda { |path| path =~ /secret/ }, 
      :secure => true

For more information on other plugins and tools that PLANET ARGON is releasing under open source licenses, visit www.planetargon.org.

Also, be sure to subscribe to Brian Ford’s feed as he says he’ll be announcing more plugins and tips soon. :-)

Have Fun!

Dialogue-Driven Development is about Listening

Robby Russell — Fri, 25 Aug 2006 19:11:00 -0500

I know. I know. I recently wrote that Dialogue-Driven Development was about rounded corners. It just happens that I also think that d3 is more than that. d3 is focuses on the conversations between various stakeholders within a project.

What is dialogue?

an exchange of ideas or opinions on a particular issue, esp. a political or religious issue, with a view to reaching an amicable agreement or settlement¹.

What is a conversation?

informal interchange of thoughts, information, etc., by spoken words; oral communication between persons; talk; colloquy²

Let’s focus on a really important side of the conversation, which is the art of listening.

In Information Anxiety 2, Richard Saul Wurman lists five tips for being a better listener.

“Having two ears and one tongue, we should listen twice as much as we speak.”
“Don’t try to formulate your reply when the other person is speaking.”
“The person who starts a sentence should be the one to finish it.”
“Don’t let your fear of silence propel you to fill it with air. A moment of silence can be the most revealing part of a conversation.”
“Remember that listening is not a passive endeavor, but an activity that requires great energy. Try to listen with the same intensity you use to talk.”

The Value in Face to Face

It’s been a while since we at PLANET ARGON have started working on a project that we didn’t get a chance to meet face to face with the client. For projects that we know will involve a lot of dialogue, it’s an absolute must at the beginning of the project. This is exactly why Brian and I fly across the country to meet our clients in person.

Wurman writes, “Time and time again, studies have shown that the best communication occurs face to face.”

“Precision of communication is important, more important than ever, in our era of hair-trigger balances, when a false, or misunderstood word may create as much disaster as a sudden thoughtless act.” – James Thurber

Our team is still shaping how best to encourage and facilitate valuable patterns of dialogue with our clients. One aspect we are certain of is that all interactions should be clearly documented, including the subtleties of body language and how the client’s team works together.

Two Ears, One Mouth

There are many benefits to having two ears. We should all try to listen more. I’ll be the first to admit that this is one of the most difficult things to do, especially when you’re opinionated.

“We have two ears and one mouth so that we can listen twice as much as we speak.” -Epictetus

The next time we find ourselves in the middle of a conversation, let’s try to listen more. :-)

¹ http://dictionary.reference.com/search?q=dialogue

² http://dictionary.reference.com/search?q=conversation

Project Illuminatus, an introduction

Robby Russell — Mon, 14 Aug 2006 19:52:00 -0500

Due to an unfortunate event last week, this blog entry is a few days late.

Over the next few weeks and months, the PLANET ARGON team will be blogging about one of our big projects that recently started. We needed to get the client to sign off on the blogging project and got the a-okay from their management early last week.

First, some background.

We were contacted by this rather large (enterprise?) company around the time that we went to RailsConf. When we got back, I began talking with our primary point of contact about their project, which sounded like a fairly big challenge and the sales process took a few weeks to come to an agreement on the next steps. Once they were finished interviewing a few other potential firms, we got the go-ahead that we should proceed with an ITER-ZERO, which I outlined a few months ago in part one of, The Art of Delivery.

ITER-ZERO was essentially a two-day trip for Brian and I to Washington DC (pictures) to interview the client and some of their existing users (domain experts), establish the protocol and channels for communication between them (the client) and our team, and work on identifying the core goals of their product that we’ll be developing with them. They have an existing product that they’ve been selling to customers for over ten years and the product that we’ll be developing will be the next generation of this software. The new product is replacing a desktop application that is only runs on Windows. The application that we’re currently working has a technical requirement that is needs to run on any operating system with a modern web browser, including some of the newer phones that have Opera mini installed! As you can see, we have our work cut out for us… :-)

During our meetings, we agreed that while their final product name is going through their marketing process, that we should have a playful project name to refer to. Our primary contact at the firm suggested, Project Illuminatus[1]. He’s a bit of a conspiracy theory nut… and it sounded fun… so we agreed to that. :-)

If I recall, Brian and I stayed up past 2am (the time zone change does that to you…) working on structuring the project wiki (instiki) to document the dialogue that occurred on our first day in DC. This provided us with a solid plan for how we wanted to focus our attention to identifying the goals that we wanted to collaborate on with the client to build an innovative and simple to define solution. Simple solutions emerge from even complex goals when you can clarify them using simple and intelligible language.

In this great blog interview, Stiff asked several famous developers the following question, “What do you think makes some programmers 10 or 100 times more productive than others?”

David Heinemeir Hannsson responded with, “The ability to restate hard problems as easy ones.”

On day two, we showed their team the wiki and explained how they could collaborate with us there. If they had ideas and new goals identified, they had a place to store those. It’s vital that your attention is on the scope of the work that needs to be investigated. We try not to solve all of the problems too quickly… it’d be naive of us to think that we could. Products evolve and so must their requirements.

I’m not going to go into everything that went on here at the moment, perhaps Brian will fill us in on some of this.

When we got back to Portland, Brian and I began meeting with Allison Beckwith, our Creative Director, to outline one of the most complex pieces of the system. As a team, we decided that this is what we need to focus more of our immediate attention to. In the their previous application, there was approximately five different modules that did something very similar, but just slightly different enough for their original developers to just build separate interfaces, which were not consistent and difficult to use for someone new to the application. We want to consolidate this into one new solution that focuses on how the users will be using the system… not just the tasks that they are fulfilling. This is why we spend so much time thinking about the goals that the users have… not what they have to do.

Oh yeah… one of the non-functional requirements?

“The product shall be easy to use on the first attempt by a member of the general public without training.”[2]

About a week later, we agreed on what work would be performed during ITER-001 (iteration one), which included paper prototyping and a few rounds wireframe mockups for this one major component of the application. I’ll let Allison Beckwith (yes! she started a blog) fill you in on this when she gets some time to outline her process for doing this.

Stay tuned…

¹ http://en.wikipedia.org/wiki/Illuminatus

² copied directly from Mastering the Requirements Process, 2nd edition. It works.. and does it need to be reestated any simpler than that?

Rails and Mongrel go to the Pound

Robby Russell — Tue, 08 Aug 2006 19:35:00 -0500

We’ve been encouraging our Rails hosting customers to give Pound and Mongrel a try for deploying their Ruby on Rails applications. David Gibbons has been adding some recipes for doing this on the PLANET ARGON Documentation Project

Check out:

...and today David posted an article on his blog titled, Why you need multiple mongrel instances with rails!

The Rails birthday party isn't over!

Robby Russell — Tue, 08 Aug 2006 17:47:00 -0500

Ruby on Rails is two years old now and we’ve been hosting Rails applications for over a year and a half now!

To mark this occasion, if you sign up with one of our Shared Rails Hosting plans by Friday, August 11th, we’ll give you an extra month of hosting for free!

Our hosting plans start as low as $11.25/month!

If you’re looking for a great place to deploy your Rails application with some of the cutting edge deployment options (mongrel, pound, lighttpd, capistrano, etc…) take a look at the PLANET ARGON Documentation Project to learn more.

When signing up for your new account, use the following coupon code: RAILS.IS.2.YEARS.OLD!

To learn more about our hosting options, visit http://www.planetargon.com/hosting.html or visit us in our chat room.

Clients Deserve Simplicity

Robby Russell — Sun, 06 Aug 2006 22:57:00 -0500

A few months ago, I posted an article titled, Trawling for Requirements, which was just before the Argon Express left for our trip to Chicago for RailsConf 2006. I’ve been kicking around some ideas with Brian ever since that afternoon on how there just seemed to be a big void in software development arena. It’s always felt that so many of the software development methodologies are designed to get developers to find a better way to work for and with clients. It’s our goal to outline a pattern that simplifies this process, not just for ourselves, but also our clients.

With each new project that our team starts, we are given an opportunity to improve on our evolving pattern for communicating with clients to better understand their goals. If there is one thing that we’ve seen help this process, it is consistent dialogue. When good collaboration exists through meaningful dialogue, confidence increases in not only the client. As developers, we are able to be confident that we understand their goals. This should generate better results.

“You are not writing requirements to serve as a contract with your client. Rather, you are writing them to ensure that both of you share the same and demonstrably correct, understanding of what is needed. Do not ask the client to sign off on the requirements; instead, ask the client to sign on to them and make them a collaborative effort.”

—Suzanne and James Robertson, Mastering the Requirements Process, 2nd Ed.

In Mastering the Requirements Process, the authors list the following as being key to identifying the project goal.

Purpose: What should the project do?
Advantage: What business advantage does it provide?
Measurement: How do you measure the advantage?
Reasonable: Given what you understand about the constraints, is it possible for the product to achieve the business advantage?
Feasible: Given what you have learned from the blastoff, is it possible to build a product to achieve the measure?
Achievable: Does the organization have (or can it acquire) the skills to build the product and operate it once built?

At first glance, I would agree that these are good questions to find answers for with your client.

Requirements, Not Solutions

Many clients come to us with a list of solutions (features) that describe implementation. This has been one of our concerns with the Product Backlog as it doesn’t discourage feature lists. Take a moment to read Goal Oriented Requirements, which gives you a few bullets to think about when interacting with your client when extracting requirements.

Take a moment to read Brian’s thoughts on the product backlog.

In Mastering the Requirements Process, the authors give two examples to show the difference between a solution and a requirement.

A Solution

The product shall display pictures of goods for the customer to click on.

A Requirement

The product shall enable the customer to select the goods he wishes to order.

When requirements are defined in this form, it allows for further dialogue about multiple implementations.

For example, we’re working on a project where the product shall enable the users to send messages to a central system. We’ve defined a few specific implementations (email, text message, web form) and know that as new technologies emerge, the same requirement will still apply. It’s important to remember that we are gathering requirements not solutions and from there… we can collaborate with the client to design a solution that fits the requirements. Before we attempt to do solve the problem, we must ask that the requirement is aligned with the project goal.

We want our clients to assimilate our development methodologies quickly and naturally, which is what Dialogue-Driven Development aims to help achieve—namely through communication, something we humans do rather well. By lowering the learning curve and accelerating the integration of clients into our process, we can focus a greater sum of our collective energy on the needs of the client, the purpose of the project, and the goals of it’s users.

Although, perhaps we have it all wrong when trying to make software and the development process simpler as Paul Kedrosky suggested. ;-)

Our clients don’t just want simplicity. They deserve it!

DDD (d3) is the new conversational software development

Robby Russell — Thu, 03 Aug 2006 22:28:00 -0500

I’m not sure how I missed this recent post on Martin Fowler’s bliki last week on Customer Affinity. In this post he references when the term “agile” first came about and mentioned that, “one of Kent’s suggested names for ‘Agile’ was conversational software development – the point being that it’s a two way communication. “

Conversational Software Development.

This doesn’t sound so different than what Brian Ford and I are calling, Dialogue-Driven Development. ;-)

Fowler goes on to say, “This isn’t something like a telecoms protocol that you can define, but the back and forth discussions about how software can enhance the business are where the real value lives. Much of this conversation is of half-baked ideas, some of which grow into valuable features – often ones that aren’t things that the customer originally thought of.”

If you didn’t follow the thread of comments on my recent post on Dialogue-Driven Development, you might not know that this name came up during Martin Fowler’s keynote at RailsConf when Brian and I were sitting next to each other and Martin kept reusing the word “dialogue.” Brian and I can’t seem to agree if I said, “Dialogue-Driven Development” out loud or if he wrote it down on a piece of paper first… so we’re going to have to share the credit. What made this so fascinating at the time was that for the entire trip from Portland to Chicago on the Argon Express, Brian and I had been discussing a lot of what we’re planning to change and define with our approach to Client/Project/Development Collaboration & Management… and in the end… we left Chicago with ~~DDD~~ d3.

Thank you, Martin for being part of this process.

Like all things, this approach is open to ~~discussion~~ dialogue.

UPDATE

Brian has written an article called, It’s all about the dialogue. (digg.it)

RAILS PLUGIN: Resource Hacks

Robby Russell — Thu, 03 Aug 2006 10:17:00 -0500

Jeremy Voorhis and Andrew Grim released a new plugin for Ruby on Rails called, resource hacks , which can be found in the PLANET ARGON open source repository located at www.planetargon.org.

Take a moment to read Jeremy’s announcement.

Enjoy and digg it. :-)

Dialogue-Driven Development

Robby Russell — Wed, 02 Aug 2006 21:55:00 -0500

Just a few months ago, I wrote a short article called, The Art of Delivery, which outlined how we at PLANET ARGON approach iterative development and how it relates to quicker release cycles. I wanted to follow up with this and add some more thoughts to that and what we’ve been trying and learning since that point in time.

With iterative development cycles, we’re able to focus our attention on very specific and well-defined goals while we work with the client to organize the other goals that they’d like us to help develop solutions for.

An End to the Product Backlog

While everyone at PLANET ARGON has been doing some research on modern Agile-related methodologies, we’ve been throwing a lot of ideas back and forth… and often times we end up cherry-picking individual practices and throwing it into our evolving processes.

The problem that we’ve seen with most examples of using a standard Scrum Product Backlog is that it focuses too much on tasks rather than providing solutions for goals that are central to the success of the project. It also requires that someone maintain, on a regular basis, a well-defined list of tasks, which often times the client (Product Owner) dictates. We’ve seen many situations where a client has more feature requests than is necessary in order to attain the goal that was originally set. If we had a nickel for every time we heard someone say, “wouldn’t it be cool if it did this?”

I’ve personally worked on many projects that fell into this routine too early in the development cycle. Most clients that we work with are trying to provide a solution for their users and aren’t always the best Domain Expert. Taking the whole less is more approach, it’s vital that the earlier you can get your users in front of your application, the sooner you can get them to generate feedback, which aids in you making educated decisions about what to add to the project later on.

Features are Expensive

Aside from the monetary costs of adding new features and functionality, it is important to remember that as you add new code to an application you increase the maintainability and overall scope of the project. With each new feature, the requirements change, complexity increases, and as far as your users are concerned, they are now being exposed to something new, which may or may not be what they want or need. For example, I was in a sales meeting yesterday and our potential client mentioned that at a former job during the dot-com era, their web team added e-Cards to their web site and it had nothing to do with their business model. The users did however use this new feature but they later went out of business. Perhaps they should have been an e-Card business instead. Imagine if BaseCamp added a local weather feature… I might use it… but it doesn’t help me manage our projects any better.

When clients approach us with a new feature that wasn’t previously discussed, we have to ask them they Why, What, and How? What goal is this feature providing a solution for? Do we already have a solution implemented that solves this problem? Is this a new goal and how (and why) did this goal come about? What are the costs of implementing such a feature and how will it affect the current stability of the user base and application? If we put it off 3 months, would it cause the project to come to a grinding halt? What about 6 months?

It’s important to always remember that one of the biggest problems in software development is feature creep. Many projects fail due to this and as a project manager, developer, or client… please consider the consequences and benefits of each new feature. Focus on the goals and connect the dots from there.

Get the goals clearly defined and provide clear and simple solutions for them.

Just Say NO to Bloat!

Start with a Mission Statement

One of the new things that we’ve begun doing with a few new clients is assigning them with an initial task of providing us with a Mission Statement. From the Mission Statement we can ask how each goal that the client and we outline relates to it. If one of the key goals of the Mission Statement is, “to provide gorillas with easy access to basketballs”... we will have to question any goals that imply that we might also need to provide access to soccer balls, car batteries, or scissors… or that when a gorilla is getting their basketball we might want to provide them access to stock reports. We’re not trying to solve all the gorilla’s problems and it would be naive for us to think that we know what they want before we’ve had a chance to really engage in that dialogue.

Users are the Domain Experts

Very rarely do we get a chance to interact with users before we’ve begun coding a project and getting an alpha release in front of a subset of users. Brian and I just got back from a few days in Washington DC, where we worked with a new client. They have an existing GUI application that began development in the mid-90s and we’re being contracted to help build a new solution to the problem that they began to solve ten years ago. The application has suffered from a lot of feature creep as many evolving products do. As they gave us a demonstration of their existing product, we saw first hand how it was even difficult for them to remember why Feature X was in the system. “Most customers don’t use that anyways.”

So, why is it there? Of course, nobody remembers why everything is there now. As developers come and go projects get managed by various people over the course of their life, many of different opinions and features get injected into the application. It’s a common problem and it takes a lot for a company to finally admit that it’s time to throw it out the door and start fresh.

The old rules don’t apply anymore. *

One of the first things that we did in our meetings was discuss what goals their product was aiming to provide solutions for. What do they believe that their users want and need? To get this answer, we scheduled a few conference calls with real users of their existing software! I cannot describe how helpful those interviews were and we saw a lot of consistency in their goals as users of such a system. It became apparent that they were the Domain Experts and as we move forward with the project we are going to have access to interact with those users.

Rethinking the Dialogue

When thinking about delivery, we must consider the major obstacles to overcome during the course of an iteration or release cycle. More important than having well-defined deliverables is having well-defined expectations. If you’re delivering a prototype, be clear about what a prototype is and what is it not. Schedule regular meetings with your client throughout the process. Keep the client updated as much as possible. Ask questions as soon as you can… and be sure to ask them the right questions.

There is an art to it and it’s important that you keep this process lightweight and agile like you do your development process. Perhaps we need to think of development and project management under a new heading… *Dialogue-Driven Development? ~~DDD~~? ...just what we need… another acronym. ;-)

UPDATE

We’re not going to call it DDD… just d3.

Knowing Me, Knowing You

Robby Russell — Wed, 02 Aug 2006 16:44:00 -0500

One of the things that we aim to do at PLANET ARGON is keep a sense of transparency between you… whether you be a client, community members, readers, or voyeurs. For those of you who don’t hang out all day in our live chat channel… you might not know who is behind the curtain. I’d like to take a moment to list some random facts related to PLANET ARGON in a series titled, “Knowing Me, Knowing You¹.” a-haa!

Did You Know?

50% of the employees at PLANET ARGON are vegetarians! (can you guess who?)
50% of the employees at PLANET ARGON are originally from Oregon. (can you guess who?)
Andrew claims to have beaten minesweeper on expert in 112 seconds!
Nicole was an exchange student in Switzerland for a year.
Brian is currently majoring in Mathematics.
Jeremy skipped the first grade.
Robby dropped out of high school when he was 16.
Allison built her first web page on Prodigy at age 14, it was called Allie’s in Wonderland. (sorry, no internet archives!)
David says he has three piercings... but I’ve only seen one. o.0
Daniel was a sea scout and got the nickname OB, which was short for OBservant.
...to be continued.

Your Turn!

Send me an email and share some random facts and I’ll select a few to mention on my next installment of Knowing Me, Knowing You.

¹ Named after the BBC show, Alan Partridge – Knowing Me, Knowing You

Quick Borat update

Robby Russell — Wed, 02 Aug 2006 13:07:00 -0500

I wanted to post a quick udpate on the status of Project Borat, which we started working on just over three months ago. The reason we hadn’t been blogging about it was because the client’s business plan was going under a rewrite and they decided to pull the plug on it for now.

So, we’ve decided to pick another one of our new client projects to blog about about.

I just wanted to thank Peat and Brian for helping with this little blogging experiment… and look forward to announcing the next one by the end of the week. :-)

Goodbye, Borat!

New Hires at PLANET ARGON

Robby Russell — Tue, 01 Aug 2006 11:03:00 -0500

Quick update on what’s going on at PLANET ARGON. Starting today, we are adding two more talented individuals to our Core Team. Neither of them are active bloggers yet, but if you want to meet them… you can stop by our IRC channel and say hi!

I would like to introduce Daniel Johnson, who will be joining the Rails Hosting and support side of the business. I’ve personally known him for a few years as a member of PDXLUG, a Portland Linux User Group that I helped start almost four years ago. You might keep an eye on his blog over the next few weeks… :-)

Jumping into the Rails development arena here at PLANET ARGON is Andrew Grim, who has been one of our satellite developers (contractors) for the past month. We liked him so much that we just had to offer him a full-time position.

...and if you’re considering moving to beautiful Portland, Oregon, we’re still looking for a few more people. ;-)

the Argon Express

Robby Russell — Tue, 27 Jun 2006 01:31:00 -0500

While at RailsConf, I was asked probably a few dozen times how the trip to Chicago via Amtrak was… and my answer was, “fun!” It really was… granted it wasn’t easy to sleep on the train but we did have fun.

Here are a few photos from the trip… in chronological order. Be sure to see the gallery as people are adding more and more photos to the group.

Walking to Union Station in Portland, OR.

Group photos before boarding…

Traveling on the train along the Columbia River

Late night hacking..

Late at night… leg streching

Breakfast on the train

Stopped in Wisconsin

Hacking on the train…

More hacking on the train…

The Mac shot…

Arrived at Union Station in Chicago, IL.

A video is coming soon too!

RailsConf, day 1

Robby Russell — Fri, 23 Jun 2006 16:22:00 -0500

Rails and Database Schemas

This morning, David Thomas opened up the conference by pointing out three problems that Rails needs to solve. The one that hit home for me and my love of databases… especially monolithic legacy ones… was his first bullet, “Data Integration.” Natural keys, composites, automatic AR relationships with reflection, and non-database backends. He didn’t mention stored procedures… I’ll have to ask him about that. ;-)

Shared Hosting and Rails

I’m currently sitting in Topfunky’s talk, “Rails Deployment on Shared Hosting”. He had a few funny slides… yes… deployment on shared hosting can be painful. We’ve been working with our customers to ease this problem as much as possible by collaborating on the PLANET ARGON Documentation Project. He also suggested that people consider a VPS, which is a very viable option… if you have the time and patience to setup the server. The pains of regular shared hosting are a big concern especially if you have a mission critical business application. This is why we moved towards our Rails Business Hosting plans and are working out the details for yet another step above in terms of cost and reliability. Stay tuned for more details…

I’ll post more notes later…

Snakes on a Train

Robby Russell — Thu, 22 Jun 2006 11:39:00 -0500

First of all, thank you Allison for keeping people updated for the past few days as the sixteen of us traveled across the country together. We made new friends and enemies over those two days and we’re already talking about RubyConf and next year. :-)

Yesterday…. Allison posted that we arrived in Chicago. We are all at the conference hotel now and last night we had the world famous Giordano’s pizza. Then we headed downtown to a few clubs (several of the argon express passengers came). I just woke up from the best sleep since Portland as I didn’t have to try to sleep in an awkward position on a train seat.

I also updated the Flickr group for the Argon Express. Hopefully the others who joined us will be posting photos to the group. :-)

The Argon Express Has Arrived!

allison@planetargon.com (Allison Beckwith) — Wed, 21 Jun 2006 17:50:00 -0500

Hello Chicago!

I just got a message from Robby announcing their arrival in the windy city. I’d advise that anyone eager to catch up with the Argon Express passengers stay away until they have all showered. 40-some hours on a crowded train? No thanks! :P

Hope you all had fun on the train, be sure to add your photos to the Argon Express group photo pool.