It's about time to start fighting against the Rails “magic” myth

I think you might be fighting an uphill battle here.<p>Some developers prefer Python, some prefer Ruby. An individual developer might be able to reel off a list of reasons why one is better than the other, but in the end it comes down to something intangible and subjective - "Ruby just <i>feels</i> better" or "Python <i>fits my brain</i> better".<p>The concept of "magic" is very similar. What feels magical and opaque to one developer might be plain and obvious to another. When you ask what "magic" means, you'll get different answers from different people.<p>From my point of view (as a Python/Django developer), even the basic <i>commands</i> that Rails uses feel strange. Compare the very first line of code that you run in a Django project vs a Rails project:<p><pre><code> django-admin.py startproject mysite </code></pre> with<p><pre><code> rails new blog </code></pre> The former says: "run the Python script called django-admin.py" (which immediately tells me that this is just a Python script that I could read, if I were so inclined) and pass the arguments "startproject" (which is a clear description of what is about to happen) and "mysite" (which is, fairly obviously, the name of the project to start). This reads like a sentence of the form 'use &#60;tool&#62; to perform &#60;action&#62; with arguments &#60;arguments&#62;'.<p>The latter says: "run the command rails" (what is this? A Ruby script? A bash script? A binary? Why is it called "rails" when the whole framework is called "Rails"?) and pass the arguments "new blog" (obviously this is creating <i>something</i>, but what? In most languages, "new" is a keyword that is usually used to create instances of classes - so is it creating an instance of something called "blog"? Does that mean that Rails knows what a "blog" is already?) To me - this is magic. Rails says "type this incantation and I'll do some stuff for you". Django says "here are some tools you can use to do stuff".<p>You might disagree with me entirely in this particular case - perhaps you find the Rails example clearer - which is fine. The point of this example is to say that framework and language preference is so intangible that the <i>very first line</i> of your documentation can sway someone's opinion either way. Instead of fighting against the "magic myth", you should just be trying to attract developers who <i>like</i> your particular brand of magic (or, alternatively, don't see your code as magic at all).

Convention over configuration: sane default values.<p>magic: changing the scope in which a block is eval'd so you can inject BlankSlates that have method_missing defined on them that then do some string manipulation in order to pick which code path to take.<p>Sometimes you need to lean pretty hard on the super-dynamic features to get the api you want. But is it worth it?

A lot of the apparent magic comes from the fact that most Rails developers never take the time to properly learn Ruby.

It's definitely nice to get a resource like this, but anyone who spends a reasonable amount of time writing applications for Rails should pick up all this. There really isn't that much Magic, it's convention.<p>Think of it like Struts, Spring or the Zend framework with all the configuration done for you with excellent documentation.

I've tried Rails a couple of times, but have never persisted with it as I can't work out how to do anything other than the default stuff. I make scaffolding, which is great, but then I want to take the scaffolding, use it as a starting point and change it. But the scaffolding doesn't seem to exist anywhere - it's just magically in existence.<p>I want to add authentication - every tutorial recommends different packages to use, but I don't want som prewritten code, I want to set a session cookie, I want to read it, I want to add stuff to databases manually, I don't want some random code providing this without understanding what's going on!<p>I'm sure that it's an easy thing to work out, but every time I get fed up with not knowing where anything is coming from so I give up and go back to what I know.

New PHP developer here. Just some perspective from an "industry" guy rather than a super-smart startup guy. I can clearly remember my first foray into Rails, and it'll be a while before I try it again unless I need it for a job. I just don't like it, and here's why.<p>For people like me, Rails is at least at first glance very unsettling. I followed the tutorial on their site about making a guestbook, on which they proudly boast how fast you'll have it up and running. So I punched in the code they suggested and bang, guestbook. They certainly weren't lying (maybe exaggerating a tad) about the speed, but ...<p>Wait. What the fuck? You've made a <i>lot</i> of assumptions about how I wanted this to work. What say I didn't want the form to look like that? Why are you writing CSS for me? That's <i>my</i> job! Going further into it made me feel even more uncomfortable, and after seeing the ORM database abstraction and taking my beloved SQL away from me, I left Rails behind.<p>It's one thing to provide a clever wrapper method to efficiently sort integers in PHP or Ruby without having to import or implement quicksort or whatever. That's abstraction me and my self-taught ilk are comfortable with. But the way Rails assumes what you meant from your code is just distressing. You don't feel like you wrote it, and this code is running and producing a finished webpage without you needing to understand how it works. You could reasonably respond that this is just another layer of abstraction, but producing an entire webpage for you based on some very cursory instruction does not have the same "pure" feel that a sort() implementation does.<p>My friends think it's great. I think it's scary. And reading some other elated posts from Rails nuts around the web about the whole "just works" thing and the magic going on really <i>is</i> unsettling. You're not building from the bottom up -- schema -&#62; logic -&#62; markup -&#62; style -&#62; scripts. It's all coming together in one big vaguely uncomfortable clump, and <i>you didn't write it</i>. Anything more than a vim macro/TextMate snippet or two that generates code for me -- even if I can edit it afterwards -- gives me a cold shiver, and makes me feel like I'm using Dreamweaver again.<p>You could read the code to see what it's doing and tweak accordingly, but then, why not write the code yourself in the first place?

No, it isn't. I was talking about this earlier on a topic about java. Magic is good, it keeps the 'I don't like magic' people away.<p>It provides a slow introduction to noobs and introduces them to the mindset that you shouldn't have to do a lot of configuration for things to just work out of the box.<p>Remove the magic and pretty soon we'll start having to use factory classes. Or a web.config file. Or any of the other annoying things you have to configure to some sane value every time you start a project with any other framework.

This sounds like a really good book. I'd love to read it, mainly because I am one of the people frustrated by rails "magic" (which I fully acknowledge comes from my lack of understanding of the framework).<p>I think that one of the reasons Rails appears to be magic to <i>me</i> is that I find it harder to do web programming in rails without the framework than with it. Hear me out, please, I'm coming from Java...<p>I can easily hack something together with jdbc, jsp, servlets, sql, pojos, and so forth. I'm not saying it's a good idea, but I can do it. Maybe this is because I started with java before all the mvc, orm, DI frameworks were in place. Maybe if I'd started with mod_ruby on apache prior to encountering rails, it would be different.<p>Now, I don't mean that it's easier to create a large, complicated site with servlets and jdbc instead of spring, hibernate, and so forth. What I do mean, though, is that if I need to do something in framework-less java, I can do it, whereas doing it the "spring way" is "harder" - ie., I have to go research how spring does it, figure it out, and so forth. And if I can't, or if it takes too long, I can (and do) say fuckit and just hack it all up in java.<p>In rails, if I don't get it, I'm still incapable of dropping to a lower level of programming. And that means that if I end up in a bind, I'm really screwed, because I don't understand the magic. Here's the thing - I really dig Rails, but eventually something <i>always</i> happens, and then the fact that I don't really understand how this magic wand I stole from the rails guys actually works bites me in the ass.<p>I've carefully avoided ever saying "it's confusing", or "rails can't", because I'd be wrong. So definitely, I want to read this book.

It's open source.<p>I played with it a bit and then read the source. Poof! Magic gone.

Good documentation definitely helps. However what concerns me more is the growing tendency of Rails and related packages to do more and more "magic" without warning the user, at the expense of best practices and the principle of least astonishment. The best example I can think of offhand is Bundler "helpfully" invoking sudo to modify your global system settings, as the default option.

I don't think the 'magic' is rails' real problem. It's the fact that all of the effort that went into making everything happen 'automagically' gets in the way when you want to do something the core developers never thought of.