Rails used to be about simplicity. I just started a new project in Rails 2.3. Here's all the choices I'm now faced with:
- Database: MySQL, PostgreSQL
- Testing: Test/Unit, RSpec, Shoulda, Context/Matchy, minitest
- Mocking: Mocha, FlexMock, RR
- Templates: HTML/ERb, Markaby, HAML, Erector
- Authentication: restful_authentication, Clearance
- Web Server: Apache, Nginx
- App Server: Mongrel, Thin, Passenger
It's been about a year since I rolled out a greenfield project. Options are nice, but this feels like Java! And those options are just off the top of my head - I wrote them down in less than a minute without even thinking about it.
Admittedly, it's pretty easy for me to make choices for all these things. I have enough experience that I don't have to spend much time pondering. But for someone new to Rails this all must seem pretty intimidating.
I guess this is why Rails 2.3 has app templates now. Just in time!
Now who has a good template for a quicky open-source app?
Well. There's the "official" list and a modular take or my personal favorite which is highly opinionated.
Enjoy
But which of the options did you choose? Why you chose what you did would make a great blog post. :)
You have forgot about client-side styles: CSS vs SASS
Which one of those options weren't available a year ago? I would guess that the diversity of this list is more a reflection on our growing Ruby community than Rails. Rails will still happily make the same choices it always has on these topics, right?
App templates definitely sound like a great solution. But even without these, one nice thing about Rails is that it gives you a full, opinionated stack out of the box. Once you become more familiar with it, you may develop certain preferences (for example to swap Test::Unit out for RSpec), but as a beginner, you don't have to make that choice at the beginning.
Even Merb, which was always about flexibility and modularity, ended up offering the option to generate a new app using an opinionated stack, while retaining the ability to swap any piece out for something else. But it took this a step further by offering alternative, less opinionated app layouts.
Also, some of these choices are not relevant when creating a new app. For example, the app server / web server choices only matter for deployment, and even then it's trivial to switch from Mongrel to Passenger.
For what it's worth, my favorite stack right now consists of RSpec, HAML, Sass, AuthLogic, and Passenger, so that's what I tend to use for new projects. I'd definitely love a Rails template that sets this up by default. Will have to dig around for one (or write one).
Of course the ultimate decision also depends on who else works on the project and what their level of familiarity (or preference) is with these various choices.
I'm done with generators for authentication. My personal favourite for that matter is authlogic (http://github.com/binarylogic/authlogic/tree/master).
But I would also be very interested in the choices you made in the end.
authentication seems to have just been thrown in there. not all apps require authentication so I say leave that out of the discussion. Templates, erb is well enough but haml I think would fit more into writing everything in ruby since we already have ajax helpers, so this is a toss up. Though I prefer to write clean html in haml and non obtrusive js in jQuery. Then apache and passenger are just the most simple from my vantage point so go with that.
These are just the various technologies that YOU learned about. A new user just starting with rails will probably use just the defaults while learning rails. And it is still a short list.
The defaults afaik are defaults : Sqlite3, Test::Unit, ERB, Webrick. All the other stuff is your personal experience talking.
Also I really think that selecting the database has nothing to do with rails, both mysql and postgresql are much older than rails is - and a choice between these two (or any other database) does not have too much to do with rails.
While there are many choices available (and with Rails 3 there will be even more) a new Rails programmer will not have to make them. Rails has clear defaults (as Evegny states) and the majority of literature aimed at Rails newbies focuses solely on those defaults. Heck, most intermediate Rails programmers don't bother with Haml or Mocha at all. ERb and Test::Unit aren't that bad.
The motto 'convention over configuration' is as present as ever.
Choice is good:)
Hmm, no authlogic? I thought that was the new hotness in cookie cutter registration and authentication. I must be behind, again. Also what about jRails (jQuery for Rails)?
Just because something is a default doesn't make it a consensus, and maybe that matters. It's all well and good that Rails has basic defaults and that a lot of the literature focuses on them. But if a Rails noob questions about, say, some edge-casey aspect of Test::Unit, and she goes into the IRC channel for their local user's group and everybody says "sorry, wouldn't know, I use RSpec", then that's a mild issue. Rails moves quickly and a lot of people glean personal sources because docs (books, articles, blog posts) go out of date quickly, so I think using the same thing that your peers are using has its appeal.
I'd argue overall that even though we're looking a bit more like Java now, it's a good problem to have. It's a sign of Rails' success that people are trying to tweak with everything, and trying to solve new sorts of problems with it. But it's interesting how in early days people were so excited about Rails' aggressive simplicity--often you have to get more complicated to support all the people who want to use your software. It's like when people say "what's the deal with the auto-indexing feature in Microsoft Word, who uses that"--well, you probably never need to, but there are some book editors who consider that feature a lifesaver. So you aren't a book editor, it doesn't mean book editors aren't important.
Anyway, it's also worth noting that some of the defaults are just plain wrong. I think it's of very dubious use to tell a noob Rails programmer to use SQLite. And the fact that they still advocate the use of fixtures is a bit of a scandal to my mind. More than once, I've had a conversation with a new Rails programmer where he says "I'm using fixtures and they're really hard to maintain, am I doing something wrong?" And I have to reply "No, the problem isn't you. Fixtures suck, and you were lied to."
I'll say again, these are the choices I myself was faced with making within moments of generating the application. The choices you or anyone else has to make might be different, but there's still a lot of things to consider now. As people have pointed out, I forgot about fixtures/scenarios/mother/factory, Prototype/jQuery, and CSS/SASS/YUI/Blueprint/etc. And I do immediately have to decide on the database - I need to set it up!
(By the way, PostgreSQL is now my personal default choice for a database, but I haven't yet gotten to use it for a new project since making the mental switch. Oh the irony.)
And Francis has a good point. Experienced developers have moved on from many of the default choices. I believe test/unit is now used in fewer than half of new projects. SQLite is a horrible default choice for anything other than a toy demo, and Webrick is such an uncommon choice for deployment that using it always seems to result in a major blog post. Why should the default choices be essentially useless? That forces you to make a choice anyway. But ERb is still a great default, by the way.
I'm happy to list my choices, though I don't think anyone should necessarily make all the same ones as I do, since different projects have different requirements and constraints. So far we have MySQL, RSpec, RR (if we need mocking, which is unlikely), ERb, Passenger. No fixtures, though I'm happy rolling my own factory methods since it's so easy. Still on the fence about authentication, though authlogic does look interesting.
I whipped this template up the other day. It could come in handy: http://gist.github.com/57458
While I agree that some of the default choices may seem like kids toys to experienced developers, they're lots easier to cope with for newcomers to Rails.
Fixtures are relativly easy to understand, compared to using factories and whatnot. Fixtures DO suck, and newcomers needs to know this.
Perhaps some of the pains of choices, or people going all the way with fixtures, can be reduced by letting newcomers know that there are choices and where to look for educated opinions on them. This could be done by the Rails generator and put into the README as well ... but ultimately, it's up to each of us to stay current and to constantly question if we're making the right choices and using the right tools.
Francis, please. "You were lied to"?! I still use fixtures and find it great for a baseline to test the standard cases against. I also enjoy using test::unit over rspec. Does that make me a n00b programmer? Does it make anyone else enjoying the same choices a n00b? How offensive.
Rails offers you the choice to differ when you see fit, but please do so respectfully. I'm not using rspec, but I certainly don't berate people from making that choice. To me, the most important thing is that people are testing. What they're using to test is a very minor concern in that regard.
As it goes for sqlite3 as a default. I just used that as a production database for a new minor application that I put online. The app uses caching, so there's not a big need for high performance. So there are plenty of cases where it's a completely usable solution.
But the main reason that it's the default is that it's so easy to get started with. You can postpone the labor of setting up and using a bigger-iron database until that's a relevant concern. If you're building your application with Active Record and don't drop down to the metal, you'll be able to switch back and forth with no issues.
As to the core of this article, I absolutely agree! There's great tyranny in choices, which is why I'm always fighting for that Rails should have a great default choice. Nobody just learning Rails should have to worry about which testing library to use or what ORM to plugin or what JavaScript framework to start with. There should be great defaults for all of this.
When you then reach the level of Susser, you can cherry-pick choices outside of the defaults for the elements that you really care about. But if you're feeling it as a tyranny of choice, I'd argue that you probably don't need to go outside the defaults just yet. It should be obvious that you're feeling a certain pain with the defaults or lusting for a certain feature in the alternative that should make the choice a no-brainer.
Hmm, I never feel that I have to choose a database engine right away. I rarely have to write database engine specific SQL, I rely on the SQL ActiveRecord generates, and use sqlite3, the default. When I deploy, I use PostgreSQL. That is not something I choose per project, I always use PostgreSQL.
Same thing with jQuery. I don't choose jQuery instead of prototype on every project, I chose to use jQuery a year or so ago.
And test/unit. And mocha. And...
As for beginners, they probably don't know that they have a choice. So I don't think this is a big problem.
Francis said: "Anyway, it's also worth noting that some of the defaults are just plain wrong. I think it's of very dubious use to tell a noob Rails programmer to use SQLite."
Why? It's a perfectly good default. Heck, it's perfectly good in production sometimes. RubyFlow runs on SQLite no troubles and while it's hardly BaseCamp or something, it handles a pretty good amount of traffic no sweat.
If you're developing an app where SQLite wouldn't keep up, you'd need to be enough of an advanced developer to know not to use it and how to deal with making a change. If you're a "noob" Rails developer, then SQLite is just fine for the sort of things you'd be working on. The same goes for test/unit and fixtures (yes, fixtures have a nasty syntax, but the concept is fine).
Francis said: "Rails moves quickly and a lot of people glean personal sources because docs (books, articles, blog posts) go out of date quickly, so I think using the same thing that your peers are using has its appeal."
On this front you're totally right. I pity the poor writers whose Rails books are now woefully out of date, often within a few months of publication! The cost of Rails' simplicity was a lot of deprecation that wasn't strictly necessary (but has ultimately made Rails better syntax-wise, consider @session['whatever'] vs session[:whatever]).
I hate the amount of out of date Rails blog posts there are out there and how popular they still are. I'm an offender of this too. I have an old "Rails tricks" post that still gets over 100 visitors a day. I should update it..!
I think a lot of the choices have been around for a long time. Database, for example; there have always been multiple adapters. Some people turned away from fixtures quite early on; HAML was already up and running by the time of RailsConf Europe 2006; and so forth. There's more and more, but I don't think it's all that new overall.
I've seen evidence of this over the years as a Rails consultant. Some of the decisions (especially database and deployment stacks, but also things like not using fixtures) are organizational; my clients have already made those choices, but I see how much of a range there is, and I learned early on that if I'm advising on an existing project, I have to take an inventory of exactly what they're using at different junctures in the architecture. In a sense, even a plugin represents a choice in somewhat the same sense.
When I'm training Rails beginners, I try to stick to the defaults, partly because I like most of them and partly because they're faster; time is short; and I don't want to convey a false sense of how much time one spends, on average, getting the application configured. SQLite is great for that. (Notice I said "configured", not "running". I am still an implacable foe of the scaffolding :-)
Are the options really so intimidating to a new user? Does something in Rails 2.3 force you to MAKE YOUR DECISION RIGHT NOW ?
In my opinion, a new Rails programmer will hardly even be aware of all the options. They'll follow a tutorial which will get them started on something that Just Works™. The fact that there are alternatives will probably come as a pleasant revelation at such time as they are ready to receive it.
It was years before i found out there was an alternative to ERB.
@Francis Default choices are a very hard thing to get right over the lifespan of a fast evolving framework like rails. When DHH started rails there was on Rspec, Erb was the only viable template offering, Prototype was the cutting edge of Javascript frameworks, MySql was the most widely understood database. These all were pragmatic and sound choices.
Over time the choices have grown and some of us have moved away from some of the defaults. Those choices come with their own pain, I like the advances of Rspec but the fragility and idiomatic can be a huge hairy yak asking to be shaved when all you needed to do was test a very basic app. I have often regretted the use of Rspec where perhaps Test::Unit would have been a simpler choice.
When choosing a default for something like rails that has evolved over a few years the core team need to keep in mind the ease with in which a n00b will be able to get going. There are vast tomes of information to help somebody get going with Test::Unit. There are endless examples of Prototype all this information and stability of choice makes it easier to get going with predictable results. Haml & Sass have a lot of admirers but would be crazy defaults, some people are obsessive about markup and Haml & Sass are considered almost an insult despite them being simpler cleaner syntax.
There are occasions where the choice to switch has been taken, when it reduces the incline of the on ramp. The switch to SQlite is one such example. I would suspect over time there will be other changes... perhaps jQuery is getting close to ubiquity and is so damn well documented and supported it may make a good default.
To choose a default you have to take into consideration many things like; ease of use, speed to get going; breadth of documentation and examples; how idiosyncratic is the choice; how wide an application does it have; how well known is it. Perhaps I would like mocha and jQuery in the box but I can't fault the current defaults and have the choice to swap them in at will.
I think that new Rails programmers are not aware of all the options. I'm intermediate rails programmer and still have a lot to learn. But I've became very confused theses past weeks about all the different available options. I'm on the "rails" and "ruby-designer" google groups, and there is always some threads introducing or discussing some alternative, and every body has his opinion: that can confuse some new programmers.
Is there a place where most options are listed and with a description of the differences with the default ones? I think that would be very interesting to have something like that. Starting with the description, rails programmers could choose or not to study more about the available options.
Before we bash sqlite3 too much, it's the database for the iphone. I use a small rails app to create and maintain data for my current iphone app. I just delete the current db file from my iphone project and add the updated one. Voila, updated data. I even use my rails app to generate the sql queries i need. Thanks DHH!
I wholeheartedly support the idea of sharing app templates. Even if you're not a design shop, pumping out app after app, it's quite useful. We've put ours out there in full-app form rather than with the templating DSL. Notice there are many things that don't go in the default template that are still nice to document as preferred options.
I'd like to see a one-stop shop for Rails app templates. I find them very interesting to browse through, especially if given detailed descriptions of why certain choices have been made.
Not wanting to hijack Josh's thread, I've posted my thoughts about fixtures and whether they should be a Rails default.
And BTW, I probably was unclear about this, but I don't have any problem with Test::Unit being a Rails default. I use RSpec, but I think there are lots of good reasons to use Test::Unit, and personally I could go either way on that one.
@DHH: well said! Choices with sensible defaults is win-win.
I think this speaks to something I've been feeling lately. I don't feel like rails is saying "no" anymore. Where is DHH swooping in to blow away everyone's dreams of rails working with every platform ever. I've been following the core list for years and the level of PDIs and "that's a bad idea" have definitely dropped off over time. Which side is giving up here, the people who want new features, or the people editing those wants?
It's so complicated it needs templates? Multiple options for middleware stacks? Engines?
I'm not saying these aren't cool capabilities, but just exactly where are we going? What's the vision? Is anyone sticking to it anymore?
I think simple defaults + advanced choices is a great combination that suits just about everyone's needs. I don't use all of Rails' defaults and as was pointed out, expert/advanced programmers (or even intermediate types like myself), have the freedom to choose what suits their style best (or the particular project; though I think it has much more to do with personal preferences/style, or legacy requirements, in the case of database choice, than anything else). Personally, I prefer not to chance to the "latest/coolest" way of doing things until I'm sure that it provides me with significant benefits. I prefer to spend the time perfecting the knowledge of the system I already know (unless it's becoming obsolete).
At the same time, the defaults are great for beginners. My 10-year daughter is writing her first Rails app (with dad's help), and sqlite, ERb, and yes, Fixtures. I may use PostgreSQL, but why should she grapple with that when she's still learning the Rails framework/Ruby language? She'll use it eventually.
As she gets better, she might choose HAML over ERb, or think SASS is cool; but at this point better for her to understand what she's doing in plain HTML/CSS, even if it's more verbose, before she learns the shortcuts. The way I look at it, and I could be wrong, is that when you're starting out, it's important to learn the "long way" of doing something, because you then get the fundamentals down. Then you can progress to the "faster/quicker/cooler/power-of-zen/look-what-i-can-do-with-only-2-lines-of-code" way, and you know what you're doing. If you go straight to the shortcut, when the shortcut doesn't work, you're lost as you have no idea what's really happening. Well, that was a side-point I guess.
@DHH: Nice to see someone else that still uses Test::Unit. I still haven't seen how RSpec is so much better that it makes me want to switch.
@jeff: I think the reason Test::Unit is lagging so much these days is that there is very little energy going into making it "better" (whatever that means). There is a lot of work being done on RSpec and Shoulda and other test frameworks, but very little on Test::Unit. Given that, I think it's natural and expected that people will follow where things are being worked on. We tend to like cutting edge stuff, which is maybe what got this whole post started.
Rails is more chaos than simplicity ... sorry to say that. The "tyranny of choice" is valid also in other areas like documentation, plugins, authorities, forums, etc. etc. I miss something like wordpress.org, a realiable starting point and an 'authority' when needed.
The Ruby / Rails ecosystem is so vibrant it makes very hard for a beginner to catch up. You always have the feeling you are missing something, the tools you are using /trying to learn are already deprecated, or the latest versions will broke up your existing code.
I think the most important thing is that one must spend enormous energies to keep himself up to date, on the edge. In WP i can stay out 6 months - 1 year and still know where to continue.
Rails became too big -- leaves no room for non-professionals. If you dedicate 100% time to Ruby and Rails you will be able to deliver miracles in 2-3 weeks, but if you are a simple hacker you'll always be stressed what you are missing out.
Yes, it is sustainable and productive, but too fast growing and nobody of the pros has the time to create & maintain the proper guide for us, the rest.
Since my prev. comment I was thinking about a solution. I could imagine a website as a reference about what is the current opinion about ruby and its ecosystem.
These opinions would be driven by the community leaders, domain experts, polls and/or available statistics. This would also reveal the major aspects of ruby, its current usage, and would offer the most actual resources for learning & keeping beginners up-to-date.
The site would be a live map with layered navigation to reveal the aspects and details. But the main page would be simple like this:
"Today, _x%_ of programmers are using ruby to build mostly web applications through the rails framework.
The community is driven by y opiniators, has z reliable resources -- z1_ for learning & _z2 for keeping you updated -- and created n active projects/plugins.
Ruby developers as developing environment are using mostly Apple MacBooks and OSX Tiger, Textmate as the default editor/IDE, and host their code in Git repositories.
The installation of the development machine is done manually although there are prebuilt app templates in rise.
BDD is the basic approach to development, and the majority of the apps are backend applications built on MySQL as storage engine, Active Record as the O-R mapper, HAML/SASS for generating views, Cells as extensions to controllers.
....
And so on covering deployment & app management / tuning.
Anyone interested?
The reason nothing's happening with Test::Unit is that it's deprecated. All new development is going forward in MiniTest. Heck, MiniTest was supposed to become Test::Unit 2.0 until a backwards-compatibility protest was raised on ruby-core.
If you're not eager to jump on the BDD bandwagon but are frustrated with the lack of new ideas in Test::Unit, it's because you're looking in the wrong place. Take a look at MiniTest. It won't take long.
Phil - where are the minitest docs? Can't find anything on how to get started w/it.