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
.appthat can be downloaded and dragged to the user's
/Applicationsfolder. 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
Application Support, but open a terminal window with the
$PATHand 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.*
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:
- Suggest "templates" for building a Rails app. "Traditional" with Rails/ActiveRecord/Test::Unit/Postgres with an explanation of what this setup is good for
- "Highrise was built with this toolset" or something. Another template could be "Mongified" with MongoMapper (or Mongoid) and MongoDB. Each template would explain the design goals and why they were made, plus some live references.
- Indexed reference to every Railscast ever created. 90% of the time when I get stuck - this is what unstucks me. Build in a summary and allow some linking over to Ryan's awesome site.
- A reasonable, concise explanation of the more popular tools out there, what they're good at, and where their github repo is.
- Integration directly with Github and perhaps some "git love" built in?
- Integration with the Cheat Gem
- Simplified and condensed Rails guides, built right in.
- A StackOverflow search link that, by default, searches within the Rails tag.
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:
- The Mongo Template
- MongoMapper, Mongoid (and whatever other gems) with explanations and github locations.
- The Cheat Gem results for MongoDB The goal here is to give the user a "flavor" for what working with Mongo in Rails will be like - the gems involved, the issues people might have had, the love people are giving it. Which brings us to an interesting aspect of this application.Nothing is more compelling and useful then"love" from other users. There are a number of places to scrape "love" from (stop it) - but even if you just started with stats from Github (commit frequency, watchers, fork counts, open issues)
- there's a lot of information to gather there.You could do an end user a tremendous service by gathering all of that and showing it next to each gem or toolset.
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:
- Select a template or clone one, modifying it as you like (use Mongoid instead of MongoMapper). Share it on Github too (format TBD)!
- The app creates a gemset, a .gitignore, set's up common configuration stuff, creates a deployment file using Cap (or whatever), installs your gems, initializes your DB and executes a core set of tests that act as guides to get you going.
- If you don't like it, the app goes 100% backwards - erasing the DB, the files, the gemset and so on.
- If you do like it - you're off and running!
- As you build your app, you can come back to Rails.app for help as needed.
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 :).