Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 17:59:00 GMT)

Flash Message Conductor

Posted by Fri, 29 Aug 2008 21:35:00 GMT

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:

flash message area
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. :-)

New Boxcar plans announced!

Posted by Fri, 30 May 2008 19:30:00 GMT

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:

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

Meet us at RailsConf

Posted by Wed, 28 May 2008 13:46:00 GMT

If you’re coming to Portland for RailsConf or CabooseConf, be sure to introduce yourself (and we’ll try to do the same). A few of us from Planet Argon will be attending the conference. I thought that I’d make it easy to spot us by putting some faces to our names.

In corner #1 we have Alex Malinovich who is our Director of Deployment Services. If you have any questions about hosting options, deployment tips, and scaling your Ruby on Rails application.. be sure to tug on his shoulder. I also overheard that he’ll be giving people discounts on our Boxcar products to those he meets in person.

Alex
Alex Malinovich, Director of Deployment Services

In corner #2, we have Andy Delcambre who is on our development team. You might remember Andy from his series of blog posts/tutorials on using Git and getting Basecamp RSS feeds working in Google Reader via a Mongrel-based proxy (our team is still using this approach using this after ten months!).

Andy
Andy Delcambre, Software Developer

In corner #3, we have Gary Blessington who has been leading our design and development team. If you’re looking for a job working with Ruby on Rails, be sure to introduce yourself to Gary as he’s hoping to meet up with several applicants who will be in Portland this week.

IMG_9286 copy.jpg
Gary Blessington, Director of Design and Development

In corner #4… is me. I’m not doing any talks this year so I plan to do wander around stress-free as I’m not finishing my slides at the last minute or preparing for panel talks. I’m happy to field questions and exchange stories with you. :-)

me...
Robby Russell

We are hiring... so feel free to introduce yourself to any of the faces above.

...and most importantly, I hope you have a great time in Portland!

Boxcar Conductor: Rails deployment made easy

Posted by Tue, 15 Apr 2008 17:16:00 GMT

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

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

Related Posts

Portland is calling... (you)

Posted by Fri, 11 Apr 2008 06:30:00 GMT

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.

PLANET ARGON

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

Managing Required Gems on Rails Projects

Posted by Thu, 27 Mar 2008 03:27:00 GMT

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?

Older posts: 1 2 3 4 5 ... 18