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

Business of Rails Panel at RailsConf 2007

Posted by Fri, 02 Feb 2007 19:57:00 GMT

Trying to finish my book and running PLANET ARGON consumes quite a bit of my time… so when the RailsConf people announced that they were accepting proposals for talks, I opted to pass so that it wouldn’t distract from my sprint to finish my book. :-)

This decision was even easier for me when Nathaniel Talbot invited me to be part of his proposal for a panel of people that are running companies that specialize with Ruby on Rails. I liked the idea and the other people that were invited were all people that I greatly admired and respected… so I said yes. After all, so much of my time and energy goes into this stuff and there isn’t any doubt that I spend way more time on the business side of Rails… than in code these days.

I just got an email from Nathaniel to let me know that his proposal was accepted.

So, if you’ll be at RailsConf 2007 (US), come see me on The Business of Rails panel session.

The following people are planned to be on the panel.

Moderator: Nathaniel Talbott, Terralien Inc.

Panelists include:

  • Justin Gehtland, Relevance, LLC
  • Geoffrey Grosenbach, Topfunky Corporation
  • Andre Lewis, earthcode.com
  • Joe O’Brien, EdgeCase, LLC
  • Robby Russell, Planet Argon, LLC

I hope that you all send Nathaniel some great (and tough) questions… ;-)

Remember When?

Posted by Fri, 02 Feb 2007 05:49:00 GMT

I was looking through some old code from over two years ago, when I was playing with my first Rails applications. I noticed this hidden file in the public/ directory, called .htaccess.

Do you remember the good ‘ole days?


RewriteRule ^(.*)$ /dispatch.cgi?$1 [QSA,L]

I remember when we at PLANET ARGON first starting hosting Ruby on Rails applications (two years ago now!) and we had to continually explain to people that running on FastCGI was going to significantly improve speed over their default CGI deployment. This was one of the first FAQs that we posted on our website.

...oh how we’ve come a long way.

Before you know it, we’ll be on IRC and talking about the good ‘ole Rails days… like we do about the BBS days. ;-)

Do you have a remember when story related to Rails?

Goodbye Pound, Hello Nginx

Posted by Thu, 01 Feb 2007 18:48:00 GMT

I’ve been using pound for several months and it’s been a good relationship. Except, for some strange reason, I noticed that I was getting development mode errors when it was running in production mode. I thought there might be an issue with my mongrel cluster… but that wasn’t the case.

Let me give you a little background to how we’re encouraging customers to handle their deployment on PLANET ARGON.

Most of our hosting customers1 have three tiers (unless you have your own static IP address), one which we manage, two that you manage.

We handle the main web server/proxy server and proxy to your desired load balancer/proxy/server, which is generally any of the following options… depending on your preference.

Each customer has a unique proxy server port and a range of other ports for their mongrel clusters.

So… the typical setup is…

Apache(external:80) [proxies to]==> Pound(localhost:8050) [proxies to]==> Mongrel::Cluster(localhost:10500-10503)

Well, when a request comes in through Apache, it gets passed off to Pound and each tier has it’s own headers. By the time that it reaches Mongrel, all the requests appear to be coming from localhost.. not the remote address of the person using your application. Notice nothing but localhost requests in your production.log? ...this is the reason.

So, what side-effects does this have? Well, aside from every request looking local… Rails will, by default, output a normal development-mode error message if the request is coming from localhost.


    # found in...
    # actionpack/lib/action_controller/rescure.rb

    # Exception handler called when the performance of an action raises an exception.
    def rescue_action(exception)
      log_error(exception) if logger
      erase_results if performed?

      if consider_all_requests_local || local_request?
        rescue_action_locally(exception)
      else
        rescue_action_in_public(exception)
      end
    end

It seems that this currently causes the exception notification plugin, which we often use, to not work. We noticed this in a staging environment for an application that we’re building for a client about a month ago. After debugging SMTP servers, mongrel configuration… I was baffled.

Nginx to the rescue

After some investigation and attempts to find a workaround in Pound, I decided to redeploy my blog with Nginx. This was a pretty painless process and I was able to use the example posted on the PLANET ARGON Documentation Project.

Nginx allows you to do the following to overwrite the headers being passed to Mongrel.


    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;

Problem Solved!

If there is a workaround for this in Pound, I’d love to be able to relay this information to our customers that haven’t made the switch yet.

Thank you, Brian and Timothy for encouraging me to finally switch my blog to Nginx. ;-)

If you have questions related to deploying Rails applications, be sure to check out the Rails Deployment google group.

1 For more information about our hosting, visit http://planetargon.com/hosting.html.

Rails 1.2 On CRN.com

Posted by Sun, 28 Jan 2007 18:58:00 GMT

I was recently asked a few questions by Stacy Cowley, a writer for CRN about the Rails 1.2 release and how our Design and Development team at PLANET ARGON is adopting it. This Q&A session resulted in a brief article titled, Ruby on Rails Gets RESTFul in Major Update, which appeared on the CRN site last Friday afternoon.

Thanks to the Rails Core team and all of those in the community who continue to help make Ruby on Rails an awesome addition in my tool belt.

Announcement: New Ruby on Rails Deployment Group

Posted by Tue, 23 Jan 2007 19:52:00 GMT

Our team is working on a new hosting solution1 for Rails applications. Throughout this process, we’ve been reviewing all the various methods that our team and customers have been using to deploy and host applications written with Ruby on Rails. Our team has been able to closely watch the technologies change on our servers for almost two full years to accommodate the latest in deployment solutions.

Recently, a few deployment savvy customers of ours and us decided that it was time to take some of our experiences and conversations out into the public. We’d like to invite all of you that are interested in Rails deployment to join the new Deploying Rails google group. Whether you’re trying to setup a staging server, deploy to a shared solution like we offer at PLANET ARGON, managing your own VPS, or configuring a cluster of servers for your big launch, we’d love to talk with you about this stuff.

I’m secretly hoping that all the talented Rails deployment experts, like our friends at Rails Machine and Engine Yard, will join us in our effort. :-)

If you’re still hosting your Rails application on Apache and FCGI in a shared environment, this list is for you! ;-)

Join the group today!

UPDATE Zed Shaw has entered the building…

1 Stay tuned in early February… ;-)

Every Second Counts with a Piston in your Trunk

Posted by Tue, 16 Jan 2007 06:15:00 GMT

Recently, I wrote about using RSpec and autotest (...which I think should be called autospec) together to help boost productivity while working on Rails projects. It seems that a few members of the PLANET ARGON team have picked up on using it, which I’m happy to hear about. :-)

It’s not the only thing that I’m happy about though.

I recently came across another gem. Several of my comrades in #caboose are using piston to manage external plugins for Ruby on Rails. Wait! Isn’t this what Subversion externals is meant for? Well, yes… but externals also eat away at productivity. For example, each day, we may have anywhere from 4-6 designers and developers working on one client project. When we’re in crunch mode, this could account for quite a few subversion commits throughout the day. We all know that we should run svn up on a regular basis to make sure that we’re keeping things in sync… especially when designers and developers are working really closely and fine tuning something specific in the application. Well, the one downside to this process is that each svn up not only checks our repository, but it also checks external repositories.

“But wait! Can’t you just ignore externals on an update?”

Of course, but who wants to type out --ignore-externals each time they run an update? ...or perhaps you could make an alias for this in your shell. In any event, everyone on the team is then left to be responsible for doing this… and an extra 30-60 seconds (if not longer) per svn update times x number of people on project… well… time wasted if you’re closely watching the svn updates. Also, TextMate doesn’t have an option currently (that I could find) to ignore externals, so for those who manage subversion through it… they’re waiting on externals within their primary workspace.

Another issue with svn externals is that when a repository goes down, it really starts to slow stuff down your updates. This is always fun when you go to deploy your application with Capistrano and realize that you can’t finish the update because it can’t connect it to http://svn.lazyatom.com/public/plugins/acts_as_hasselhoff/ to make sure that your application has the latest version of the best plugins available for Rails.

acts_as_hasselhoff

Then there is the whole issue of wanting to make changes to the plugin that you’re including as an external. How does that fit into the whole mix?

There is Hope!

Piston encourages you to keep your external plugins in your local repository. Don’t worry, it remembers where it retrieved the code from so that you can update from the external repository at any time.

Installing Piston

Again, this is really simple like most gems.


    $ sudo gem install -y piston
    Password:
    ...
    Successfully installed piston-1.2.1

Great, that’s all that you have to do to get started with Piston. Now, let’s get on with the show.

If you don’t have any existing Subversion externals, feel free to skip this section.

Converting existing externals

Okay, so let’s say that you’re working on a Ruby on Rails project and are relying on several external repsitories. For example, a project that I’m working on… currently looks like this.


    $ svn proplist --verbose vendor/plugins/               
    Properties on 'vendor/plugins': 
      svn:externals : 
    authorization                 http://svn.writertopia.com/svn/plugins/authorization
    svn_tools                     http://svn.planetargon.org/rails/plugins/svn_tools
    simply_helpful                http://dev.rubyonrails.com/svn/rails/plugins/simply_helpful
    exception_notification        http://dev.rubyonrails.com/svn/rails/plugins/exception_notification
    asset_field                   http://svn.planetargon.org/rails/plugins/asset_field
    rspec_on_rails                svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5/rspec_on_rails/vendor/plugins/rspec_on_rails
    rspec_autotest                http://svn.caldersphere.net/svn/main/plugins/rspec_autotest

Piston is smart enough to know how to convert these Subversion externals into Piston-friendly plugins. This can be done by passing the piston command the convert option from within your Rails application directory.

Go ahead and run the following.


    $ piston convert
    Importing 'http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-0_RC1' to vendor/rails (-r 5619)
    Exported r5619 from 'http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-0_RC1' to 'vendor/rails'

    Importing 'http://svn.writertopia.com/svn/plugins/authorization' to vendor/plugins/authorization (-r 83)
    Exported r83 from 'http://svn.writertopia.com/svn/plugins/authorization' to 'vendor/plugins/authorization'

    Importing 'http://svn.planetargon.org/rails/plugins/svn_tools' to vendor/plugins/svn_tools (-r 119)
    Exported r119 from 'http://svn.planetargon.org/rails/plugins/svn_tools' to 'vendor/plugins/svn_tools'

    Importing 'http://dev.rubyonrails.com/svn/rails/plugins/simply_helpful' to vendor/plugins/simply_helpful (-r 5700)
    Exported r5700 from 'http://dev.rubyonrails.com/svn/rails/plugins/simply_helpful' to 'vendor/plugins/simply_helpful'

    Importing 'http://dev.rubyonrails.com/svn/rails/plugins/exception_notification' to vendor/plugins/exception_notification (-r 3900)
    Exported r3900 from 'http://dev.rubyonrails.com/svn/rails/plugins/exception_notification' to 'vendor/plugins/exception_notification'

    Importing 'http://svn.planetargon.org/rails/plugins/asset_field' to vendor/plugins/asset_field (-r 50)
    Exported r50 from 'http://svn.planetargon.org/rails/plugins/asset_field' to 'vendor/plugins/asset_field'

    Importing 'svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5/rspec_on_rails/vendor/plugins/rspec_on_rails' to vendor/plugins/rspec_on_rails (-r 1330)
    Exported r1330 from 'svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5/rspec_on_rails/vendor/plugins/rspec_on_rails' to 'vendor/plugins/rspec_on_rails'

    Importing 'http://svn.caldersphere.net/svn/main/plugins/rspec_autotest' to vendor/plugins/rspec_autotest (-r 48)
    Exported r48 from 'http://svn.caldersphere.net/svn/main/plugins/rspec_autotest' to 'vendor/plugins/rspec_autotest'

    Done converting existing svn:externals to Piston    

All we have to do now is checkin our changes to subversion and we’re golden.

svn ci -m "updating repository to use piston instead of those lame-o externals..."

If you find this interesting and want to learn more, be sure to check out this post on Ruby Inside for a detailed introduction to Piston.

update

the following morning I saw this come across our development team channel…

< argonbot> svn.commit( project_name, { :author => 'brian.ford', :rev => 83, :log => 'converted svn:externals to piston for product, cus I can.' } 

:-)

Older posts: 1 ... 15 16 17 18 19