Thank you, Rails
jacobian.org
jacobian.org
Now that I've got a bit of experience under my belt I'm looking for more opportunities to work with this community and I love what I see. I feel like working alongside these guys is making me into a much better developer.
It's a tribute to Rails' genius that so many people view it as a threat. You still see people who seem genuinely afraid to let go of their massive, overly complex frameworks, or optimizing every little bit of their PHP app. People afraid of relinquishing the slightest bit of control for convention.
What I actually see, when I hear developers decrying this stuff, is geeks afraid that they're going to lose their Genius cards now that there's an easier way.
The fact is, Rails doesn't reduce the amount of hard thinking required to write a reasonably complicated web app, it reduces the amount of boring boiler plate code. For heavy lifting Rails still gives you the tools you need, there's a reason Rails Metal and find_by_sql exist. There's a reason most of the core parts of Rails are interchangeable (esp. with the upcoming Rails 3). Solving any worthwhile problem generally requires real work. Rails doesn't change this.
The brilliance that Rails brings to the table is balance. Many of the design decisions of Rails just hit the sweet spot for a large category of apps, and remove so many of the pain points in development.
The thing about Rails is that it represents the maturation of web development. It's not anything amazing per se, just a clever roll up of the best practices that emerged from the decade of Perl, Java, PHP development that preceded it. Ruby is the secret sauce that makes things just feel so slick.
I don't mean to minimize the initial innovation, it's just that Rails is no longer very unique. A lot of frameworks have largely caught up even if written in less flexible languages, and long term I see opportunities for new frameworks to leapfrog Rails.
The biggest liability for Rails is the Ruby runtime. Yes progress is being made here, but it's still a pretty sad state of affairs with regards to memory leaks and performance. I bang my head up against this every few months and it really hurts.
Another issue is the need to handle more complex applications. Frameworks like Seaside allow you to set up complex stateful apps in a more robust way than will probably ever be technically possible in Rails (again due to limitations with Continuations in the Ruby runtime).
A related issue is the question of what dark places we will end up in over a couple decades of large code bases running under Ruby with no warnings. I think it's pretty clear by now that Java is an unnecessary straitjacket, but do-whatever-the-fuck-you-want-with-no-warnings-whatsoever Ruby environment is not necessarily the most conducive to long term stability. I'll take it over Java any day, but I still have my doubts.
Finally, there is the issue of increased ajax-ification of apps. Rails was a leader here early on insomuch as it provided proof of concept that Ajax could be done easily without a cross-browser-DHTML-guru certification, but 5 years later the Prototype + Rails helpers paradigm is quite dated. Ajax has huge potential for simplifying back-end code and making web apps inherently more scalable and performant. This is one area where Rails could re-invent itself, but a mature framework like Rails is going to have a disadvantage against a fresh approach starting from first principles.
In short, I think the competition has openings.
A lot of what people identify as pathological is an evolutionary advantage in BFEWAD. Straight-jacketing the programmer is often a good thing because on a team of 100 programmers in three continents (you might think I exaggerate), including (by my last count) 12 programmers who have less than 3 months of professional experience, we want to make sure the damage done by the least skilled programmer on his worst day is strictly contained.
I don't know if Rails scales to that sort of development, to be honest. The least skilled developer, touching one part of one class at the periphery of the project, is essentially one line of code away from blowing up the entire project.
I should know: since I'm the sole Rails programmer at my business, I am by definition the least skilled programmer. And since I've managed to corrupt the results of my analytics code by making a one-line ill-considered addition to my printing code (which are kept in wildly divergent classes in different packages and namespaced from each other), just because it was not obvious I was altering the global state of the interpreter. That sort of bug has never happened to me in Java.
A lot of techniques which are considered kosher in the Rails community don't scale to large distributed teams really well. Monkey patching is the obvious example -- if you have two developers who have different understandings of what Array#pack is supposed to do, you're going to run into HELLACIOUS, difficult to debug bugs. If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.
I think you're generally pretty safe as long as you stay away from the core library methods. It's the attempts to transparently extend well-known methods that I think tend to blow up on people.
b) You will eventually generate a namespace collision based on the birthday paradox alone, no matter whether programmers avoid the core methods or not, if they are working in the same classes. The Ruby community encourages people to have fun with String, Number, etc because it results in easy to write DSLs.
c) array = []
array.methods.size => 127
require 'activesupport' => true
array.methods.size => 185
Those added methods include, among others: sum, to, split, blank?, rand, load, to_xml, to_json... and numerous other things some intrepid developer might decide their own arrays could benefit from.
Edit: The code sample didn't demonstrate what I wanted it to demonstrate, so I changed it to one that did, although it demonstrated something related anyhow.
If you're so afraid of incompetent developers money patching things so that they break, why aren't you afraid that they write Java* code that spawns 2 million threads, crashing the system? Or code that deletes the hard drive? There are plenty of easy ways to break a program besides monkey patching.
* With "Java" I mean whatever your favorite language is that you think will prevent incompetent developers from doing stupid things.
And code that modifies core classes, like your Array#pack example, is almost always bad code. It doesn't matter if you're working alone or with 100 people.
Shortly thereafter, they terminated my contract because my work was not "up to their standards". :C
The Rails community with all its various gem and plugin authors is a large distributed team of programmers. We already work on that scale.
Thanks.
Waaay off topic, but i wouldn't use the expression "scales to." Asking how to scale Rails up to 100 programmers is asking the wrong question. Asking how to maintain the same application with just one team on one continent is the question and Rails might be the answer. Then again, it might not be the answer for your specific company. But that is the question to ask.
If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.
Again, you have my sympathies. But Rails is not the answer to this problem and neither is Java. One answer to that question that has worked for others in this situation could be continuous integration. Why didn't your automated tests fail when the dev in Seoul checked his code in?
I am not saying Rails is for you, or for anyone with 100 devs on multiple continents. But I do have a little experience with multiple developers on separate continents building C++ and Java applications, and the problem of stopping developers from breaking code was always solved with processes like continuous integration and code reviews and not because of some special property of Java.
I like Rails for certain things and not for others. I am not arguing you should use it. But I do feel that the issues you raise are not Java vs. Rails issues but process issues. Java won't solve them for you and neither will Rails.
Just imagine what we could do with a Beowulf cluster of 100 Rails programmers!
http://github.com/raganwald/homoiconic/blob/master/2009-04-0...
So while I was ranting a bit about the process vs. tools issue, I fundamentally agree with your concerns that programming Ruby in the style of Rails has issues.
I strongly suggest this kind of risk to be dealt with at the human resources department.
Last time I had to deal with something like this, I suggested firing the HR person who interviewed the then candidate and who did nothing to stop what should have been pretty obvious even to someone without any tech background.
The saddest fact in BFEWAD is that, at the same time Java makes it safe to use 100s of programmers in several continents, you won't need a 100s developers in several continents if you use something less primitive.
As for the monkey patch, there is another technique that prevents it from ruining your week: all automated API tests must pass _before_ the kid in Seoul commits a file.
OTOH, I find Ruby's syntax a bit too flexible and that makes it difficult for me to parse someone else's code unless I know that person very well. When comparing Rails and Django, I prefer the latter. It's just that I can wrap my head around it more easily.
Assuming that the only problem is that they are inexperienced...
On a team of that size, you're not only doing development, you are (or should be) grooming future senior devs. In the enterprise world, on timelines that run 5-10 years, with groups 100+ in number, you have an entire ecosystem to manage.
Also, in groups of that size, you're going to make mistakes in hiring. I've seen the same thing on small teams, where the whole team interviews someone who ends up sucking. With a 95% success rate, with 100 people, you're still talking five screwups.
Breaking things into smaller teams doesn't necessarily get you what you want, either. You end up with a bunch more management, turf wars, and a bunch of other hard-to-deal with crap.
Basically, at the really large scale, it is less about the code, and a lot more about managing people over a long timeline.
I have been using non-C++-ish languages for about two-and-half decades now and I never met a BFEA that demanded such a huge team. In fact, I regard huge projects like this as very risky and always advise smaller projects that can bring more to the bottom line and that can be implemented in steps.
What the hell are you doing that needs such a huge team?
BFEA-wise, the technical challenges revolve around the intersections between the various projects - message queues, batch servers, databases, storage (and more storage). Proponents of independent teams tend to dismiss these challenges, resulting in an overall environment that is more expensive to implement and manage. (for example, sure, that obscure OSS project may be _perfect_ for the task, until the one guy that knows it leaves, and you have to pay someone top-dollar to ramp up on it)
To be fair, there's usually a lot of room for improvement, efficiency-wise. To continue to be fair, I don't know that the success rate of small dev shops is any better or worse than the large: there are more failures than successes, and many more "good enough" situations.
A certain balance is required between exposing intention and implementation information for one to easily grasp what is going on and how can one interfere with it.
If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.
Code reviews are absolutely required with any dynamic language. It's a good practice anyway, to keep everyone on the same page.
You don't sound argumentative. You sound hyperbolic.
Do you have a citation for 'most' of the popular web applications not being code reviewed? Have the developers at, say, twitter said they ignore commits and code written by co-workers?
I got addicted to Sinatra because it pretty much begged me to try Haml + jQ --- which is an amazing combination --- and we recently ported all our Erb's to Haml in our Rails app as well.
I think it's a major design mistake to hide or abstract Javascript now that jQuery has pretty much won the JS framework war.
%a.post_link.confirm_link.destructive_link{link_to(@x)}
Hi mom
<box name="foo">
<item number="1" />
<item number="2" />
</box>
<div class="box" id="foo">
<div clas="item" id="item_1" />
<div clas="item" id="item_2" />
</div>
.box#foo
.item#item_1
.item#item_2I also worry about creating something in HAML and having people not familiar with it not be able to dive into the project and start working right away. I'm actually on the other side of that scenario right now and it's a pain.
But I do have to admit, it's a very pleasing syntax.
I'm much happier now with Rails and Django.
I spent nearly 4 years doing OO PHP. I enjoy coding a lot more now I'm rocking ruby/rails.
If anything this article has made me more inclined to check out python/django.
Yes, there was plenty of emotional bullshit in the community as solutions were hyped and abandoned. I think Passenger was initially a massive logical regression when it was mod_rails, but now that it's mod_rack it no longer agitates me so.
Thank you, Rails, for helping the world realize how awesome HTTP is as seamless, simplifying middleware.
Even if it mostly failed at pulling it off, Rails convinced even some PHBs that Apache is not the alpha and omega of HTTP.
Truth is, people can get kind of religions about their technological choices, no matter what those choices are (I guess it takes some faith to believe in your choice, when there's no clear answer to "which is best"? ... there never is).
There's pg's idea, of working hard to make lots of money, so you are free to work on what you really enjoy.
And 37Signals' idea, of a lifestyle business that you enjoy working at in the first place (assuming you resolve the above added concerns and demotivation).
So all that said, I really appreciate the author's candor. The negative attacks people make against other frameworks and languages really discourage people who are just getting started with this stuff because it casts doubt in their minds about whether or not they bet on the right horse. I may actually play around with Django now to see what it's all about.
I mentioned Ian Bicking's great talk at this year's PyCon elsewhere in these comments, but another thing he touched on was framework fanboyism, and how it's mainly the result of people being new to the framework and trying to convince themselves that it's the answer to everything. Whether it's Django or Rails or any other technology, excitement is good, but not when it becomes tribal and adversarial toward perceived competitors.
I don't know much about the Django community, but in the Rails community I seldom hear any discussion of Django. The few times I've heard talk of Django in the Rails community, it's along the lines of "Oh yeah, it's great for x/y/z use cases." It's hard for me to imagine DHH or other Rails notables writing anything remotely similar to this post.
Is this just me being sheltered? Or is there more of a pre-occupation with Rails in the Django community than vice-versa? If so, why? Just curious to hear what other's experiences have been.
Django currently is more modular. The ease with which you can integrate third-party components is unparalleled in my experience. I also like Django's ORM a whole lot more.
Rails is awesome, other frameworks are too ... but keeping blinders on is not good on the long term.
The Merb/Rails merge reveals some reasons why there aren't a lot of widely used Ruby frameworks, and I'd say it's mostly a large scale manifestation of DRY, combined with the maturity and wealth of features in the Rails codebase and the fact that most of the changes devs would like to see in Rails are already going into it.
Which is real shame, because there are many really good options for Ruby Web development.
What people are saying here abut Rails I felt about Nitro, whihc came out at the same time but had a more well-considered implementation. It was thread-safe from the start, much faster than Rails, did less mucking around (if any) with core Ruby classes, made it easy to swap in different ORMs, offered a trnsformation pipeline that was simialr to Rack middleware; in fact, it seemed much like what Rails3 is going to be, only five years ago.
But it got no traction in Rubyland. In fact, at one MountainWest RubyConf, Chad Fowler flat out told people to stop working on Nitro, because there was Rails.
There's a weird myopia among many Rubyists, a lack of curiosity about what else is happening.