Mephisto: Change from SVN to Git

Posted 7 months back at poocs.net - Home

The fine folks over at ENTP/ActiveReload have released version 0.8 of Mephisto, the Rails application that powers this site. With this new release, they, as everyone these days, have actively shifted the remaining bits and pieces of Mephisto’s development from Subversion to Git. (And its main repository is hosted at Github, where else.)

I hardly remember ever installing Mephisto from a tarball. I always used to track its Subversion trunk for the 3 blogs I run, which made upgrading as easy as svn up && rake db:migrate RAILS_ENV=production most of the time. Well, that was then and this is now. Looking at this recent shift to Git, I wanted to convert my blogs to the new Git repository without excessively messing with whatever I did to my local installation (quickly approaching my 30s, I might not even recall most of what I did). I was pretty certain, however, that I did not have massive local modifications. If I had, this approach might’ve been a little simplistic.

Here’s what I did.

Initializing

Starting out, you need to create a local Git repository within your local blog installation, which is as simple as:

$ cd /your/blog
$ git init
Initialized empty Git repository in .git/

The next step is to setup technoweenie’s master repository on Github as a remote to your local repository and fetch what’s currently in there.

$ git remote add technoweenie git://github.com/technoweenie/mephisto.git
$ git fetch technoweenie
remote: Generating pack...
...

This will fetch both the master branch and all branches technoweenie might’ve created. (This includes, for example, a branch that holds the current 0.8 release, if you don’t dare to ride the edge of Mephisto’s development.)

Merging

At this point we need to merge one of the branches we just fetched into your local (totally empty, for what it’s worth) repository. (I’ve decided to stay on the master branch. If you prefer a release branch, substitute it as appropriate.)

$ git merge technoweenie/master

Since Subversion scatters its .svn folders all over the place, we need to get rid of those. You can either do that manually or with a little find-fu.

$ find . -type d -name '.svn' -exec rm -rf {} \;

Excellent, that’s much better. Now it should be safe to check out the current state of affairs:

$ git status

Running this command will show you the currently untracked files. Those would be all files that existed locally before you started to create your own Git repository and which are non-existent in technoweenie’s repository.

Tracking local modifications

As I mentioned above, I didn’t have a boatload of local modifications. My changes were limited to bit of configuration, a few third party plugins (and the accompanying CSS/Javascript) and my local Mint installation. The additional files and directories that may show up are the cached HTML files that Mephisto sticks in public/.

To actually add your local modifications to your Git repository, simple add and commit them.

$ git add config/mongrel_cluster.yml
$ git commit -m 'Mongrel configuration'

If you’d prefer to rather ignore whatever else sits in your blog directory, add it to .gitignore

$ echo "public/*.html" >> .gitignore
$ echo "public/200*" >> .gitignore
$ echo "public/mint" >> .gitignore
$ git commit -m 'Ignore cache and mint' .gitignore

Cleaning up

I had a few files sitting in my directory that weren’t local modifications but seemed to have been removed from the official repository, too. Those weren’t caught by our merging of the Git branch since we started with zero history. To get rid of those, let’s take a look at git-clean.

$ git clean -n -d
Would remove app/views/admin/article_comments/
Would remove app/views/admin/articles/approve.rjs
Would remove app/views/admin/articles/comments.rhtml
Would remove app/views/admin/articles/destroy_comment.rjs
...

The -n argument prevents git clean from actually doing anything. If you’re confident it wouldn’t do anything harmful, go ahread and remove it. (You do have backups, right? Do you?)

At this point we’re down to regular upgrading business, so you might want to run the migrations and restart your Mongrel cluster. (Or whatever floats your deployment boat.)

$ rake db:migrate RAILS_ENV=production
$ mongrel_rails cluster::restart

Into the future

Now, whenever Mr. Weenie adds an exciting new feature to Mephisto you can grab that via:

$ git fetch technoweenie
$ git merge technoweenie/master

Or if you’d rather prefer to pick a specific commit:

$ git cherry-pick <SHA1>

Further reading

Since this is not a Git guide per-se, I’ll end the article at this point. There is plenty of other content available online to bring you up to speed with Git.

 def index @photos = Photo.paginate(:all, :conditions => { :user_id => current_user.id }, :page => params[:page] ) respond_to do |format| format.html # index.html.erb format.js { render :template => 'photos.html.erb' } end end 

 $ wget http://jqueryjs.googlecode.com/svn/trunk/plugins/livequery/jquery.livequery.js 

 <%= javascript_include_tag 'jquery', 'jquery.livequery.js,' 'application' %> 

 jQuery(document).ready(function($) { $('div.pagination a').livequery('click', function() { $('#main').load(this.href) return false }) }) 

Time.now.end_of_week # => Sun Mar 09 00:00:00 0800 2008

<%= date_select 'user', 'birthday', :order => [:day], :class => 'my_css_class' %>

Rails 2.0 TextMate bundle - Tasty Tidbit - respond_to and view navigation

Posted 8 months back at Dr Nic

The new release of the Rails TextMate bundle is coming soon. Its guaranteed to be shiny, sparkly and will fit in with any home or office decor. More importantly, it will be upgraded for Rails 2.0.

Today is the first Tasty Tidbit - a demonstration of one of the snazzy new features coming to your Macintosh soon.

In this Tasty Tidbit, we look at respond_to and the ability to create and navigate to view templates based on the selected format block, such as wants.js -> .js.rjs.

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="437" height="370" id="viddler"> <param name="movie" value="http://www.viddler.com/player/52b07473/"/> <param name="allowScriptAccess" value="always"/> <param name="allowFullScreen" value="true"/><embed src="http://www.viddler.com/player/52b07473/" width="437" height="370" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" name="viddler"></embed></object>

Cannot see the embedded video? Want the Hi-Def version? Download the video (5 Mb).

Zero Sign On - 1 better or Infinitely better than Single Sign On?

Posted 9 months back at Dr Nic

This article has no code in it. There are no TODO steps. Nothing to install. Its a picture of the future.

There is no reason to bookmark this article and read it another day. Its nearly all pictures. You can read it now.

This “picture of the future” was actually added to our browsers in the 90s. Netscape and MSIE3.0 both had it.

“It” is Client Certificates, and to me to means “never logging on with username/password NOR OpenID ever again”. Zero Sign On. It must be better than the much-targetted Single Sign On.

Client Certificates

Firefox 2.0:

Or on Safari/KeyChain:

Small problem: no website I’ve ever used has ever offered them, so I never knew they existed. I didn’t know what they did, nor as a web developer that I could create them for users who’d never need to login again.

Clifford Heath showed me the light. On #roro irc channel, we were exploring how “Zero Sign On” might be implemented using ssh-keygen, and browser plugins etc. Clifford mentioned client certificates and then someone else mentioned that MyOpenID already supported them.

I already had an myopenid account, so raced over to explore the new world of certificates.

Under “Authentication Settings”:

After submit:

And then:

Then feedback:

So I thought to test out if “Zero Sign On” actually worked. Normally, after logging out you’d need to submit username/password or if a site supported OpenID (yes myopenid.com is an OpenID provider which is a bit circular but bear with me) you login by entering your OpenID url and pressing Enter. Either way, you’ve got work to do.

Instead, I clicked “Login” link on the home page, and was redirected immediately to:

So it was still using cookies so that it could log me in immediately next time without clicking “login”, but either way, there is no username/password nor any other “type something here” login form. Just a “Remember Me” checkbox.

Finally, myopenid.com shows a log of your sign-in attempts:

Your sites and the future

As a web developer, you can do one of two things to get some leverage of Client Certificates.

1. Support OpenID as a login mechanism. Users with myopenid.com accounts (or other openid providers that support client certificates) will benefit from automatic login to their openid page and instant redirection to your site. You’ll also be able to help new users import their profile data to get them started quickly.
2. Implement Client Certificates yourself. I would have liked to have had a crack at this before posting about Client Certificates and all their sweet loveliness, but I didn’t. My bad. Instead, I found a nice step-by-step (plus comments with updates) on implementing Client Certificates

If you have/do implement Client Certificates in Ruby/Rails world, you’ll get a 1000 Happy Points from me if you open source it/blog about it. Happy Points are redeemable for Happiness in all countries.

AWDR depot app for Rails 2.0 (RubyPlus.org) - Part 2

Posted 9 months back at Rails on Edge

Here goes part 2.

I've finished the screencasts for chapter 8, 9, and 10.

Here are the problems I came across while doing so:

At the beginning of chapter 8, the top of the screen is cut off when creating sessions in the database, the is the whole line:

  rake db:sessions:create

And then towards the beginning of chapter 10, a line is cut off in 005_create_line_items.rb

  t.decimal :total_price, :null => false, :precision => 8, :scale => 2

I had some trouble with the ajax highlight effect in add_to_cart.js.rjs

  page[:current_item].visual_effect :highlight, 
        :startcolor => "#88ff88", 
        :endcolor => "#114411"      

and was not able to figure it out. When I clicked Add to Cart, I would get the error "TypeError: $("current_item") has no properties" and then another popup window with a lot of code in it. I looked around the internet for a while trying to get it fixed, but nothing I tried worked. If anyone figures this out, let me know. I ended up commenting out that line in add_to_cart.js.rjs.

Everything else works great. I really like Bala's screencasts, they are a great resource for learning Rails 2.0. After finishing them, I believe I know enough to make something that is not too complicated. For my next post, I believe I am going to start working on a forum in Rails, and AJAX it up(I could use a lot more experience with AJAX).

See you all next time!

newjs = newgem for JavaScript projects; free TDD suite

Posted 9 months back at Dr Nic

Want to start a new JavaScript project for a library or widget/badge for your website?

You know you should do TDD but wouldn’t know how to get started, what support libraries you need and where to get them from?

You need tools to deploy your library, your website etc?

You’d like a consistent structure to your project so that IDEs could provide support (toggle btw src/person.js and test/unit/person_test.html) [I haven’t done this bit yet, I’m sure I’ll add it to the JavaScipt Unit testing textmate bundle one day soon].

I couldn’t find anything helpful like this, so I created newjs - the JavaScript Project Generator.

Why?

But first, an brief history of everything…

I fell instantly in love with Rails for a couple reasons:

• rails & script/generate commands - they teach you what files you need
  and where they should go
• Ajax support - the marketing phrase “its as easy to use Ajax as not to” took me
  away from ASP.NET where the new Ajax.NET library was non-trivial to use; RJS
  didn’t exist at this stage, but Rails’ JavaScript support was still awesome
• TextMate - though I didn’t get to use it for 18 mths til I bought a Mac

Later I fell in love with Ruby, for its meta-programming, syntactical possibilities
and free TDD support within Rails.

Then I fell out of love with JavaScript. Partly because Rails started generating JavaScript for me, and ultimately because I didn’t have test support. Whether you use Rails JavaScript helpers, or write your own unobtrusive JavaScript libraries you’re still living in an unhappy world without tests; let alone without TDD.

I still wrote JavaScript because it still needed writing. But a lot of my JavaScript
became “write-once, modify-never” affairs. Not just because I had no tests,
but each project had a different structure, different deployment processes, etc.

Finally, this year I figured out “TDD for JavaScript”. For every 1000 blog articles about Rails or Ruby, there is 0-1 article on unit testing JavaScript. Or perhaps I just don’t know how to use Google. Soon, the “JavaScript Unit Testing” PeepCode will be finished, so hopefully it will add to this lacking body of knowledge.

What I needed now was one-line starter-kit for new JavaScript projects that included:

• A standard structure for JavaScript libraries/projects
• In-built testing support, with rake tasks and script/generate unit_test
  generators
• Tasks for deploying distribution files (via version numbers)
• Tasks for managing the project website

I don’t think there is one already, thus my hand was forced: newjs.

Installation & Getting Started

Installation and maintenance of generated JavaScript projects requires the installation of Ruby and RubyGems.

The command-line application newjs is installed as below, for any operating system (except the ‘sudo’ part - use as necessary):

sudo gem install newjs

You’ll note it uses RubiGen because I like to cheat when it comes to generating things.

To kick-off your new project/library, run the command-line app newjs:

$ newjs mylib -a "Dr Nic" -e "drnicwilliams@gmail.com" -u "http://mylib.rubyforge.org"
      create  config
      create  lib
      create  src
      create  script
      create  tasks
      create  test/assets
      create  test/assets/unittest.css
      create  test/assets/unittest.js
      create  test/assets/prototype.js
      create  tasks/javascript_test_autotest_tasks.rake
      create  tasks/environment.rake
      create  tasks/deploy.rake
      create  config/javascript_test_autotest.yml.sample
      create  lib/protodoc.rb
      create  lib/jstest.rb
      create  Rakefile
      create  README.txt
      create  History.txt
      create  License.txt
      create  src/HEADER
      create  src/mylib.js
      create  script/rstakeout
      create  script/js_autotest
  dependency  install_rubigen_scripts
      exists    script
      create    script/generate
      create    script/destroy

And you thought you wanted to create all that by hand…

TDD for JavaScript

Personally, I can never remember what basic HTML + JavaScript goes in the test HTML files. I quite like the javascript_test plugin for Rails, which allows you to generate a test HTML stub. So I’ve included a version of it
here.

Two actually: one for unit tests and one for functional tests.

$ script/generate unit_test some_lib
  create  test/unit
  create  test/unit/some_lib_test.html

For functional tests, use functional_test generator. See the newjs site for more details.

Lifecycle of JavaScript files

You create JavaScript files in src/ and then when you run rake dist
they can compressed into dist/project_name.js.

To make this work, add new src/ files into src/project_name.js via
<%= include "file_name.js" %>.

This is the build mechanism used by prototypejs and I stole it. Actually, I stole nearly everything from the prototypejs source structure.

Other stuff

Like newgem you can create a simple website (via textile files):

script/generate install_website

BONUS: instead of the crap purple default theme for newgem, newjs websites have a nice yellow theme - see example.

Source for newjs

Get it via git: master branch

Credits

The generated structure, the unittest.js test suite, and its included help files mostly come from prototypejs and newgem.

The generator mechanism is from RubiGem which comes from the Rails Generator created by Jeremy “I made someone leave Rails for PHP” Kemper.

Actually, I stole nearly everything from the prototypejs source structure. They are much cleverer than I am.

Shared hosting is alright

Posted 10 months back at interblah.net - Home

In which we consider why it might be that parts of the Rails community are so dismissive of the merit of shared hosting.

I've had a Dreamhost account for a long time. Some of my friends and I started sharing one of their premium plans in around 2001 (you know, before virtual hosts and all that jazz) to save some cash (I was a penniless PhD student), but we wanted somewhere to host our perennially profound blawgs and generally piss around with the web.

So after reading Alex Payne's response to a post on the DreamHost blog about Rails on shared hosting, while I don't really have much to say about the points on the Dreamhost post (Ruby/Rails may or may not get faster, who can say), I think the thoughts about working in shared hosting environments are interesting.

Here's the gist of Alex' argument, I think:

Big kids need their own sandboxes to play in.

As a programmer who wants to get paid for my work, making an application that I sell to people who then install it on a shared hosting account doesn't sound like a great way to make a living. If you'll excuse a callous generalization, it's a support nightmare for a down-market customer base. Plus, nobody but nerds (who don't pay for software anyway) install their own web applications anymore. People use hosted services.

It is possible to use Rails effectively with shared hosting. I've done it. I'm doing it now. I have a couple of VPSes, and they're good too, but this blog is being served up via Dreamhost*. I'm not saying they are perfect, but I also don't really believe that if the world would come to a shuddering halt were to lose access to what choice morsels of rubbish I choose to spout here.

Shared hosting exists to give people the ability to use server software without having to know a lot about dependencies, package management and toolchains. Certainly, it isn't the most performant or reliable way to serve a web application, nor does it afford you all the flexibility of virtual hosting, but does that mean it's worthless? Hardly.

You don't need to be a nerd to want to play with Rails

I feel like we're nearing a point in time where almost anyone can pick up the tools of our particular trade and start creating their own applications. And my, don't we have really nice tools! Surely if a Ruby-Newbie who's interested in scratching their own itch wants to play around with Rails, it's in our interests as a community to foster that. And so it that means at least trying to make it easy for people to host their own applications on hosting that is both common and affordable, then why shouldn't we be trying to assist?

Bigs kids might need their own sandboxes, but that doesn't mean that you should only be allowed to play if you can afford your own sandpit.

Do As Rails Core Do?

David Hansson has said that none of the Rails contributors may use shared hosting, and that's fine. Rails has always been about the contributors scratching their own itches. But I think the problem that Dreamhost are highlighting is that those core contributors have (directly or indirectly) made it clear that the "official" way you should deploy is on a dedicated server, using a combination of Mongrel and Apache/Lighttpd/Nginx. It's like: that's what all the high priests are doing, so if you're not doing the same, there's something wrong with you. Apparently the opinions from which Rails was summoned into existence not only include how you develop with it, but how you deploy it as well.

My point is simply this: you don't always have to act according to the opinions of other people. You don't even really need to agree with them. I didn't agree with Rails Core about the engines plugin, but that's fine, we've coexisted, and fed back where it was appropriate. The key is that if you want things to work better, you have to go do it yourself. David states that in his response reasonably well:

It's not saying that shared hosting is bad or evil. It's simply saying that the Rails contributors generally don't use it. By extension, it's not something that we are personally invested in solving as a traditional "scratch your own itch" type of development.

Incidentally, I find it remarkably refreshing that something which doesn't fall on the "golden path" isn't being automatically labelled as evil here. Anyway, back to the quote:

I'd love for Rails to be easy as pie to run in any environment. In that "more people could have fun learning Rails and deploying their first hobby application" kind of way. But I don't need it in the sense that I'm going to put in the work, personally, to make it happen.

(...cut....)

I'd love to see someone tackle this challenge and would be more than happy to work with a group pursuing this to get their results into Rails or working with Rails the best way we can. Consider that an open, standing invitation.

Back to the point:

What I really find weird that people would respond to Dreamhost's expression of pain as "What, shared hosting? That shit is WHACK! Real developers use VPS hosting, why are you even trying!"

Can we dial back on this brand of deeply passionate but equally-deeply uninformed knee-jerk reaction? Shared hosting might not the best way to deploy a critical application, but not every app is really that critical. And that's OK.

How I Use Dreamhost

In case anyone's interested, I do have a few things I do for the applications that I run on Dreamhost:

• Build your own ruby and install your own gems. You can install applications in your own home directory (try running ./configure --prefix=$HOME, in a nutshell). This puts you completely in control of the versions of Ruby and more importantly the gems that you application needs
• Put as much stuff in /vendor as possible. Try not to depend on the Rails gems that your shared host might provide, because you really don't need to. Hell, try and unpack as many gems into your application's vendor directory as you can.

shared-hosting-is-alright

Posted 10 months back at interblah.net - Home

Shared Hosting is Alright

I've had a Dreamhost account for a long time. Some of my friends and I started sharing one of their premium plans in around 2001 (you know, before virtual hosts and all that jazz) to save some cash (I was a penniless PhD student), but we wanted somewhere to host our perennially profound blawgs and generally piss around with the web.

So after reading Alex Payne's response to a post on the DreamHost blog about Rails on shared hosting, while I don't really have much to say about the points on the Dreamhost post (Ruby/Rails may or may not get faster, who can say), I think the thoughts about working in shared hosting environments are interesting.

Here's the gist of Alex' argument, I think:

Big kids need their own sandboxes to play in.

As a programmer who wants to get paid for my work, making an application that I sell to people who then install it on a shared hosting account doesn't sound like a great way to make a living. If you'll excuse a callous generalization, it's a support nightmare for a down-market customer base. Plus, nobody but nerds (who don't pay for software anyway) install their own web applications anymore. People use hosted services.

It is possible to use Rails effectively with shared hosting. I've done it. I'm doing it now. I have a couple of VPSes, and they're good too, but this blog is (was; I'm no longer using Mephisto...) being served up via Dreamhost*. I'm not saying they are perfect, but I also don't really believe that if the world would come to a shuddering halt were to lose access to what choice morsels of rubbish I choose to spout here.

Shared hosting exists to give people the ability to use server software without having to know a lot about dependencies, package management and toolchains. Certainly, it isn't the most performant or reliable way to serve a web application, nor does it afford you all the flexibility of virtual hosting, but does that mean it's worthless? Hardly.

You don't need to be a nerd to want to play with Rails

I feel like we're nearing a point in time where almost anyone can pick up the tools of our particular trade and start creating their own applications. And my, don't we have really nice tools! Surely if a Ruby-Newbie who's interested in scratching their own itch wants to play around with Rails, it's in our interests as a community to foster that. And so it that means at least trying to make it easy for people to host their own applications on hosting that is both common and affordable, then why shouldn't we be trying to assist?

Bigs kids might need their own sandboxes, but that doesn't mean that you should only be allowed to play if you can afford your own sandpit.

Do As Rails Core Do?

David Hansson has said that none of the Rails contributors may use shared hosting, and that's fine. Rails has always been about the contributors scratching their own itches. But I think the problem that Dreamhost are highlighting is that those core contributors have (directly or indirectly) made it clear that the "official" way you should deploy is on a dedicated server, using a combination of Mongrel and Apache/Lighttpd/Nginx. It's like: that's what all the high priests are doing, so if you're not doing the same, there's something wrong with you. Apparently the opinions from which Rails was summoned into existence not only include how you develop with it, but how you deploy it as well.

My point is simply this: you don't always have to act according to the opinions of other people. You don't even really need to agree with them. I didn't agree with Rails Core about the engines plugin, but that's fine, we've coexisted, and fed back where it was appropriate. The key is that if you want things to work better, you have to go do it yourself. David states that in his response reasonably well:

It's not saying that shared hosting is bad or evil. It's simply saying that the Rails contributors generally don't use it. By extension, it's not something that we are personally invested in solving as a traditional "scratch your own itch" type of development.

Incidentally, I find it remarkably refreshing that something which doesn't fall on the "golden path" isn't being automatically labelled as evil here. Anyway, back to the quote:

I'd love for Rails to be easy as pie to run in any environment. In that "more people could have fun learning Rails and deploying their first hobby application" kind of way. But I don't need it in the sense that I'm going to put in the work, personally, to make it happen.

(...cut....)

I'd love to see someone tackle this challenge and would be more than happy to work with a group pursuing this to get their results into Rails or working with Rails the best way we can. Consider that an open, standing invitation.

Back to the point:

What I really find weird that people would respond to Dreamhost's expression of pain as "What, shared hosting? That shit is WHACK! Real developers use VPS hosting, why are you even trying!"

Can we dial back on this brand of deeply passionate but equally-deeply uninformed knee-jerk reaction? Shared hosting might not the best way to deploy a critical application, but not every app is really that critical. And that's OK.

How I Use Dreamhost

In case anyone's interested, I do have a few things I do for the applications that I run on Dreamhost:

• Build your own ruby and install your own gems. You can install applications in your own home directory (try running ./configure --prefix=$HOME, in a nutshell). This puts you completely in control of the versions of Ruby and more importantly the gems that you application needs
• Put as much stuff in /vendor as possible. Try not to depend on the Rails gems that your shared host might provide, because you really don't need to. Hell, try and unpack as many gems into your application's vendor directory as you can.

shared-hosting-is-alright

Posted 10 months back at interblah.net - Home

Shared Hosting is Alright

I've had a Dreamhost account for a long time. Some of my friends and I started sharing one of their premium plans in around 2001 (you know, before virtual hosts and all that jazz) to save some cash (I was a penniless PhD student), but we wanted somewhere to host our perennially profound blawgs and generally piss around with the web.

So after reading Alex Payne's response to a post on the DreamHost blog about Rails on shared hosting, while I don't really have much to say about the points on the Dreamhost post (Ruby/Rails may or may not get faster, who can say), I think the thoughts about working in shared hosting environments are interesting.

Here's the gist of Alex' argument, I think:

Big kids need their own sandboxes to play in.

As a programmer who wants to get paid for my work, making an application that I sell to people who then install it on a shared hosting account doesn't sound like a great way to make a living. If you'll excuse a callous generalization, it's a support nightmare for a down-market customer base. Plus, nobody but nerds (who don't pay for software anyway) install their own web applications anymore. People use hosted services.

It is possible to use Rails effectively with shared hosting. I've done it. I'm doing it now. I have a couple of VPSes, and they're good too, but this blog is (was; I'm no longer using Mephisto...) being served up via Dreamhost*. I'm not saying they are perfect, but I also don't really believe that if the world would come to a shuddering halt were to lose access to what choice morsels of rubbish I choose to spout here.

Shared hosting exists to give people the ability to use server software without having to know a lot about dependencies, package management and toolchains. Certainly, it isn't the most performant or reliable way to serve a web application, nor does it afford you all the flexibility of virtual hosting, but does that mean it's worthless? Hardly.

You don't need to be a nerd to want to play with Rails

I feel like we're nearing a point in time where almost anyone can pick up the tools of our particular trade and start creating their own applications. And my, don't we have really nice tools! Surely if a Ruby-Newbie who's interested in scratching their own itch wants to play around with Rails, it's in our interests as a community to foster that. And so it that means at least trying to make it easy for people to host their own applications on hosting that is both common and affordable, then why shouldn't we be trying to assist?

Bigs kids might need their own sandboxes, but that doesn't mean that you should only be allowed to play if you can afford your own sandpit.

Do As Rails Core Do?

David Hansson has said that none of the Rails contributors may use shared hosting, and that's fine. Rails has always been about the contributors scratching their own itches. But I think the problem that Dreamhost are highlighting is that those core contributors have (directly or indirectly) made it clear that the "official" way you should deploy is on a dedicated server, using a combination of Mongrel and Apache/Lighttpd/Nginx. It's like: that's what all the high priests are doing, so if you're not doing the same, there's something wrong with you. Apparently the opinions from which Rails was summoned into existence not only include how you develop with it, but how you deploy it as well.

My point is simply this: you don't always have to act according to the opinions of other people. You don't even really need to agree with them. I didn't agree with Rails Core about the engines plugin, but that's fine, we've coexisted, and fed back where it was appropriate. The key is that if you want things to work better, you have to go do it yourself. David states that in his response reasonably well:

It's not saying that shared hosting is bad or evil. It's simply saying that the Rails contributors generally don't use it. By extension, it's not something that we are personally invested in solving as a traditional "scratch your own itch" type of development.

Incidentally, I find it remarkably refreshing that something which doesn't fall on the "golden path" isn't being automatically labelled as evil here. Anyway, back to the quote:

I'd love for Rails to be easy as pie to run in any environment. In that "more people could have fun learning Rails and deploying their first hobby application" kind of way. But I don't need it in the sense that I'm going to put in the work, personally, to make it happen.

(...cut....)

I'd love to see someone tackle this challenge and would be more than happy to work with a group pursuing this to get their results into Rails or working with Rails the best way we can. Consider that an open, standing invitation.

Back to the point:

What I really find weird that people would respond to Dreamhost's expression of pain as "What, shared hosting? That shit is WHACK! Real developers use VPS hosting, why are you even trying!"

Can we dial back on this brand of deeply passionate but equally-deeply uninformed knee-jerk reaction? Shared hosting might not the best way to deploy a critical application, but not every app is really that critical. And that's OK.

How I Use Dreamhost

In case anyone's interested, I do have a few things I do for the applications that I run on Dreamhost:

• Build your own ruby and install your own gems. You can install applications in your own home directory (try running ./configure --prefix=$HOME, in a nutshell). This puts you completely in control of the versions of Ruby and more importantly the gems that you application needs
• Put as much stuff in /vendor as possible. Try not to depend on the Rails gems that your shared host might provide, because you really don't need to. Hell, try and unpack as many gems into your application's vendor directory as you can.