If I Were Creating Rails.app

Wednesday, March 3 2012 opinion rails

Nothing but respect for Yehuda, but I'm thinking the Kickstarter model for creating a tool might not fit terribly well in the OSS landscape. I could be wrong. Either way - I have an idea.

Don't Fund It, Sell It.

Here's my premise: a lot of people have their Rails environment dialed in. The one's that are having a bit of a harder time tend to be the folks just getting started or perhaps upgrading. These are the people that might very well plunk down $5 for a tool to help them.

The premise of the Kickstsarter effort is to (basically) - well here I'll let Yehuda explain:

My plan is to deliver a .app that can be downloaded and dragged to the user's /Applications folder. At first, the application will have two facilities:- Install Rails into the system: This will install a working copy of Ruby, Rubygems, Rails and all necessary gems into the user's system, available from the Terminal. It may also install rvm and other common system tools, depending on the feedback I get from the community as I develop this project.

  • Open a Terminal with a working Rails environment: This will leave all necessary resources in the .app file or Application Support, but open a terminal window with the $PATH and other variables set up.

I think this sounds interesting. Hackers out there will probably say "I can do this with a Shell Script! So what!" and that may very well be true. But there are a number of devs out there who are very new to Rails and are getting frustrated at the choices involved.

Choice is a good thing. Frustration is not. Frustration by choices means you don't understand the choices (typically). To me, this is what Rails.app should focus on.

Help When and Where Needed

For people who have been working with Rails daily - the choices might not seem so difficult:- RVM or rbenv?
- Haml or Erb? Or Liquid? - CoffeeScript? - SASS or LESS? - Postgres or MySQL (well... this one shouldn't be so hard really). Or MongoDB? - ActiveRecord, DataMapper, or Sequel? - Vim, Textmate, or Sublime Text 2? - RSpec, Cucumber, or Test::Unit? Or all 3? Or just 2?

I'll stop here. If you're new to Rails and/or Ruby you might think it's a bit of a madhouse with so many options. To me, that's the joy of it all.

I also want to put a personal note here: some people are callously saying "the guy who screwed up Rails now wants to get paid to fix it" - the guy being Yehuda.

The problem isn't Rails itself (ActiveRecord discussions aside) really - it's the toolsets and "peripheral knowledge" that goes into it. Yehuda didn't create RVM, SASS, or any of the other choices here, so it's not fair to crucify a guy who's trying to fix something.

So how do you know what to use?* Educate yourself. Quickly. That's what Rails.app should do.*

Cheat Notes

The problem is frustration at getting started and setting up your app. If we focus completely on the problem it becomes obvious that the solution should primarily educate, secondarily create.

Given this - I have some ideas:

That seems pretty good for now. Ideally the app could be used offline so it would be great to "scrape" the sources if the licensing permits. You could literally just hook in the Cheat Gem and go from there.

Now, if User X wants to use MongoDB with Rails - enter "Mongo" in the search box. What pops out would be:

Get Going!

Ultimately the goal is to cut down the time "exploring" and "learning" by gathering the useful information, educating your user, and then getting them started. This is where Yehuda's idea takes shape:

Think back to when you were getting started with Rails - it was one Google search after another, one blog post after another, trying to get up to speed (it's still this way for me!). The one thing you can truly do to make developers stoked with a Rails.app is to help them understand.I dunno! Maybe I should build this :).