Knowing that, maybe I can go a little easier on myself when I fail to live up to the ideals, and simply keep on striving without having to feel that I am obviously an inferior coder.
Somehow, I (somebody with zero Ruby experience, and very little web dev experience) had ended up with the same impression. That certainly is some good evangelism.
I continued to be amazed and nonplussed that a community could do so well and know so many technologies so fluently when I took so long to learn them.
And now that I've met a bunch of Rails people in person and am considered a Rails guru by two consecutive companies, I'll tell you that yeah, it's mostly hype.
Not that Rails is bad -- it rocks. But it requires a lot of background in deep, messy Ruby to really do well, and there's a lot of bad Ruby and Rails code out there. How could it be otherwise?
When I started using PHP ten years ago, I inherited an existing project. Two days into it I thought to myself: "PHP is kind of like Perl, but less useful." I guess I missed the PHP hype phase. If it had one.
I've never been a language evangelist. I just solve problems with whatever technology is most appropriate for the case.
My own projects generally lack extensive testing (and the code lacks complex code paths) but I refactor heavily.
Rails developers read GoF and think "object composition is awesome!" Then they go and create a bunch of acts_as_foo and has_bar modules which they mix into their models and controllers, all the while thinking "object composition is awesome!" Meanwhile, it never occurs to them that modules are, in fact, closer to multiple inheritance than object composition, and all the wonderful benefits of object composition that GoF touts are nowhere to be found. Instead, what's left is a giant plate of spaghetti code...
To me it's telling that one of the best Rails developers I ever worked with had 10 years of C++ experience, so he was quite wary of multiple inheritance and all its dangers.
There are any number of indications for making such an observation.
- Multiple different 'Rails best practices'
Rails has changed a lot since version 1.0, but most of the 1.0 stuff still works. People usually learn Rails by reading blog posts and then trying out what they read. As they write code, read more, etc their perception of what the 'best practice' is changes and so does the new code that they write. This makes a mess of things. Experienced programmers will set a 'best practice' for the entire codebase and if that changes for whatever reason will refactor the entire codebase to match the new standard. This is pretty trivial in Rails simply because the codebase of even huge Rails apps is still pretty small.
- Lack of tests
A lack of tests is considered a sin in the Ruby world, but it happens all the time. Embracing testing, I think, is something that comes with time because if you're new you simply don't see the value of it. Lack of testing is bad, but there are also variations on this rampant in the Rails world. Different test frameworks in a single project (I call this the 'follow-the-shiny-new-trend' problem) or simply boilerplate tests that don't really tell you anything other than, yes, this ActiveRecord object without callbacks can be committed to the DB.
- Breaking MVC
This drives me nuts. Doing Model work in the Model except for over here where I do it in the View for whatever reason. This is a clear sign that the programmer doesn't have a good mental model of what's going on and why this is a really bad idea.
- Inconsistent use of the Rails API
This ties into the 'best practices' point, the Rails API is by now pretty big and you have to take the time to study it. New programmers don't usually do this because they don't have a background in programming in frameworks and resort to trial-and-error programming ('hey this works here, let's move on'). Which, BTW, is something that Rails makes very easy.
There are plenty of other things (terrible SQL, custom Ruby code with magic, arbitrary plugins, etc) but those are usually pretty easy to isolate and fix.
The good news is that Rails codebases are generally pretty easy to fix incrementally. Write up a coding standard, start writing useful tests and pick a test framework (really, RSpec is fine) and work from there.
Hard points to manage (which should be obvious and not Rails-specific),
- If you're fixing an app that is under active development you have a lot of coordination to do
- This is easier if you can work on-site
- It's a lot easier if the dev team is small
That's a good thing, right?
This particular form of arrogance (let's call it what it is) permeates throughout most sub-communities of CS programming. Ruby is just one tribe. Lispers are another. Game studios, web app developers, a different product team inside the same company, [insert pretty much any other here]... they all believe/rationalize that they are different to Java, and thus have nothing to learn from all those enterprise projects. Even HN has a particular anti-unit testing tribe that will turn up as soon as any article appears that says "Hey, Test Driven-Development is pretty good, huh?" who will complain that testing hurts velocity (it doesn't, see Etsy for a great example).
It's an arrogance that inevitably leads to the issues brought up in the article, taking out a huge technical debt that some other chump has to pay off. I'm not sure how this will ever change. I guess the conclusion is just to try and make sure you're not the chump.
Well, I used the example in the context of velocity, not necessarily in whether the users are happy ;)
The glitches are more of a concern, but that might be a hardware issue for all we know.
On the other hand, velocity has a specific and well-understood meaning within agile software development, and that's what the antecedent post was referring to.
Of course, if you were just being snarky and implying that Etsy are completing plenty of nominal work without it resulting in any actual progress, then carry on :-)
I know you were being intentionally facetious here, but this does nicely encapsulate "How Project Managers and Developers Fuck Agile".
Use of velocity outside of calculating capacity and extra demands being placed on the team is broken; yet I've seen Project Managers terrorize their charges by using it as some kind of fucked-up productivity measurement. For a developer, if your estimates don't include time taken to properly test and develop the user stories, you are lying. You're lying to the business, you're lying to the team, and you're hiding technical debt. As a developer, you get final sign-off on how many points you assign to a story - don't fuck up this 'simple' task :-)
Now, I think it's good to do a few high-level smoke tests first, to help nut out the interface. (It's much cheaper than having lots of meetings with the boss drawing boxes on a whiteboard, or worse, writing specs). But good test coverage is something that can often wait until fighting bugs becomes a pain point.
How much of this sounds familiar?
> “Design Patterns are a Java thing. In Ruby you just write code.”
> “The warnings Ruby produces are dumb; just disable them.”
> In a way I think this is a testament to the power of the platform. If you’re getting a 500 error in a Rails app, you can keep adding kludge after kludge and hitting “reload” until it works. No need to ever write a test or refactor. In languages and frameworks with a lower turnaround time, this kind of tweak-it-till-it-works workflow is simply impractical. Ruby on Rails has an impressively low barrier to fiddling.
This is all a religious war, but at the end of the day something like Rails enables you to come a lot closer to "good design, good programming" than many other systems currently in use, i.e. your less than favourite PHP or Java framework here.
I think that someone who honestly believes PHP has RUINED them may be a bit of a tool. We're programmers, we can figure it out.
The same thing's been said about PHP.
And sure, PHP ruins programmers like BASIC does - not at all, if they've some brain cells they can rub together. But it does teach shitty habits which can take time and effort to forget.
I'm just not sure there's much to Ruby or Rails that ingrains shitty habits, but I'm biased.
It does give you ample rope to hang yourself with, though.
Ruby on Rails is closer to Java J2EE, in all it's enterpriseyness. It may not use a whole lot of XML files here and there, but it's got a similar flavor IMHO. Lots of stuff happens by "convention over configuration". The XML shit from J2EE is just replaced with a little bit of domain specific code within Ruby.
I can only speculate what's the root cause here. Is the web stack just so horribly broken with session cookies and whatnot? Or the problem of displaying the content of a relational database in a HTML page a difficult problem? Or is it just trying to force a one-size-fits-all solution to a problem that is not well defined?
Either way, there is always new stuff to learn. It may crush your ego to learn something new, but in the end, it's a lot easier to read a book or Wikipedia article than to independently reinvent programming. Or maintain that app that's "too hard" to write unit tests for.
Understood monads? Good, try your hand at monad transformers, arrows, continuations, zippers, enumerator based IO...
Not only this, but there is active resistance to useing something like TAP.
It looks like an interesting tool, I'll investigate it.
You are being optimistic.
"Dividing methods into private and public is for control freaks, you don’t need it in Ruby"
Personally, I think Ruby hits a sweet spot here: the privacy curtain is strong enough that Ruby WILL let you know when you've stepped off the path of using methods which are part of the stable API. But you can then tell Ruby "yes, I understand, and I know what I'm doing".
object_instance.private_method is obviously prohibited, but so is self.private_method when called from another class method. The latter one is fine when private_method is called, without the self. To circumvent privateness in the other case ("calling an underscored method") you would have to say object_instance.send(:private_method).
Anyhow, personal recent experience on using a plugin that is an API to some webservice:
- Lots of static methods
- Code structure is awful
- Documentation is non-existent
... and I rarely use Rails let alone learn Ruby yet I can see how horrible that plugin is.
I heard I'm not alone when it comes to the discussion of the quality of plugins out there.
I don't mean to bad-mouth Rails framework because it is a well-thought project (let's not discuss the internal code). But as many who have been in this industry for a while, we kind of know that this is coming sooner or later.
Python code, in many places, seem to have a good balance of pragmatism, UNIX culture, and discipline.
Having said that, Rails 3.x seems to mark a change in attitude from the Rails core team. They're starting to address issues and stabilize the framework for the better. Let's hope the rest would clean up as well.
I can say the same of C, C++ and Python in the context of my personal work history. Is Avdi's experience so unusual in the Ruby world? It seems that most development jobs primarily involve working on other people's code if the language has been around for any time at all.
Edited to add: I've also seen everything listed in the "But Rails is different!" section in every commercial project I've ever worked on. I suspect most developers that just want to hack away on commercial code without any discipline end up having nearly the same set of justifications, no matter what language they're using. (Especially that bit about ignoring/disabling warnings.)
Of course maybe I just haven't looked in the right places. :)
I have no data to back that up, but it certainly seemed to happen that way.
If only that were true. Like the OP I've been working with mostly legacy Django codebases the last few years and much of the same issues he raises could be applied to those projects as well.
When a daemon gets too big, we split it up.
That makes each writing each new part feel much more like a green-field exercise than you'd expect from a product this size.
Let that be a call for people to develop
a) Rails experience
b) testing, refactoring, working with legacy code experience
Because it means that there are going to be a lot of 3+ year old projects in 2 years that will need those skills.
Most of the other developers I know are older, have computer science and/or EE degrees, and have been around the startup block a few times, and have several greenfield projects under their belt.
My biggest advice, use rails plugins sparingly, and when you do ensure they are well maintained. Nothing is worse than an old rails project that is using 20 plugins and you need to update it to a new major version of rails.
Why is this? I don't know exactly. It could be the way that plugins tend to manipulate multiple layers of the stack and tend not to use clearly-defined public interfaces. I suspect that more of it is the fact that plugins are the self-promotion tool of choice for the jobbing Rails developer: they fall from grace as quickly as they rose, abandoned by the developers to whom they gave a leg up, supplanted by a new, different plugin with an obviously - everyone agrees! - much more correct way of solving the problem. Meanwhile, your old Rails app is dependent on a dozen pieces of decrepit abandonware.
Why is this? I don't know exactly.
I guess those who forget the past are doomed to repeat it.
It's funny, principles of good programming are about as old as programming itself and yet everyone seems to feel the need to rediscover them periodically.
If you look at some great nix utilities, they should "do one thing and do it well". Hm, sounds like Single Responsibility Principle.
Dependency injection? Funny, reminds me a lot of nix pipes.
So to me the moral of the story is: programmers with experience and an open mind will tend to make good decisions. Inexperienced programmers just need time if they're willing to learn.
And arrogant jerks will always make messes.
Also nowadays you can afford to value simplicity over speed in so many more places.
But it's certainly true that sloppy code can be produced in any language.
That said, I've encountered many times where a Rubyists first reaction to anything Java is "oh that's terrible" but anything implemented in Ruby must be beautiful, just because it's Ruby. Clearly, that is not true and yet people believe it over and over again.
Also, if you look at a lot of the developments in the Rails world over the past few years, they've been running into problems long solved in the Java world, but only now have Ruby projects been getting big enough to warrant general purpose solutions.
A perfect example is Bundler. It's basically Maven for Java, but it took the community a while to realize "hey, managing libraries is a pain, we need a tool for it".
So as Rails grows up, hopefully it won't forget that many other communities have solved similar problems before it.
Sometimes it's almost as if Rails invented the Internet. :)
IE8 crashes trying to run this JS code.
SCRIPT438: Object doesn't support property or method 'indexOf'
github-badge.js, line 59 character 7
SCRIPT438: Object doesn't support this property or method
badge.js, line 47 character 7
SCRIPT438: Object doesn't support property or method 'getElementsByClassName'
embed.js?pname=wordpress&pver=2.61, line 35 character 78
SCRIPT438: Object doesn't support property or method 'getElementsByClassName'
embed.js?pname=wordpress&pver=2.61, line 35 character 78
Interestingly enough, when I switched it into IE7 mode, only the first two errors appeared.