Your Code is My Hell

lol That's exactly the opposite of what the author was trying to accomplish with this article. ;)

"Ruby has such wonderful evangelists that somewhere along the line I had gotten the idea that all Rails projects had 100% test coverage, and refactoring was a matter of course."

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.

Again, it's about maturity. Every popular young platform has a relatively large amount of evangelical fervor and a relatively small amount of real-world long-term experience. Java was no different, years ago.

The striving is the key. Keep it up!

I deal with this at work. The code has never been refactored. There are unit tests for some areas but the views and controllers have so many lines of code and so many unneeded branches that attempting a test there is near impossible now. As soon as I came to the team I've managed to accomplish two minoir refactoring jobs in small areas of the code. I've pitched a more major refactor to the team and now we just need to get it passed our manager.

My own projects generally lack extensive testing (and the code lacks complex code paths) but I refactor heavily.

I taught myself Ruby and Rails on my couch, by myself, over years. But I did it after a more-than-ten-year C/C++ career.

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?

Spaghetti code is procedural-- what you see in Ruby is ravioli code :)

So true. Modules are a wonderful feature, but they come with a lot of power, the implications of which are not always easily understood.

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.

I've done my share of cleanups in various languages. I don't agree that Rails code is "a special kind of horrible", but there are a few things that seem to be very common in Rails code. A lot of it seems to be written by inexperienced programmers.

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.

- AJAX

Rails embraced JavaScript very early on and is a very fine framework for doing AJAX in. However, doing AJAX is a completely different skillset and most programmers don't have it. Most projects just seem to have various widgets floating around that don't share a common coding or state system. That makes them hard to unify and also means there's a lot of arbitrary XHR calls going into the Rails app (for which there are often 'special case' Controller methods, which don't share a lot of logic with anything else)

- 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

Rails is a really nice framework and a lot of people are getting a lot of productivity out of it. It's easy to look down on shoddy code and say that from your years of coding experience on the front lines you could do a better job, but that's not how experience is built. If you're reading this you've probably written some pretty horrendous code earlier on. Look at it this way : if a startup can hire an outside consultant to clean up their code and teach them some lessons, then what they had before you came in was apparently enough to get them off the ground and their programmers learned a lot in the process.

That's a good thing, right?

Which side of the example is Etsy supposed to be for that, exactly? They make a lot of changes, and supposedly do a lot of testing, but if you're actually paying attention to what's going on there (and the overlap between Etsy fanatics and people who know what TDD is are pretty small) they have constant stream of small problems. Many people I know who are serious Etsy users complain that the site changes too frequently, has tons of glitches and is confusing - most serious ones were overwhelmed years ago. Just thought I'd let you know since you're using them as an example of something.

We're not anti-testing. We just think that certain classes of error are better caught at compile time by the type system than at runtime by unit tests, which can even be more lines of code than what they're testing and still miss an edge case.

Part of the issue is that whereas unit testing is a good idea to use where possible, test-driven-development is a religion.

> who will complain that testing hurts velocity

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 :-)

Testing is good, but it hurts the ability to churn code quickly. You get stuck with a bad design, because it's too expensive to re-write all the tests.

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.

That's a bit trite, don't you think?

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.

I don't think that RoR will be looked back upon the same way as PHP. PHP is a language with a buggy interpreter with a ghetto as a standard library with a community consisting of a bunch of script kiddies. </flame>

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?

That's what I love about Haskell: You'll never get the impression that you learned all there is to it.

Understood monads? Good, try your hand at monad transformers, arrows, continuations, zippers, enumerator based IO...

I've always had a soft spot for TAP's output format. It just seems like it has potential for much better debuggability. The concept of a plan alone puts it above xUnit styles in my mind. That and the expectation that each assertion has a descriptive message just makes it's output seem easier to follow.

TAP is nice. I think it could use some extensions... but when I handrolled a test program a few years ago, I chose TAP. It... works.

What is TAP?

Christian Neukirchen (the creator of Rack, among other things) created knock[1], a TAP tool for Ruby. It doesn't seem to have developed much a following, though.

[1] https://github.com/chneukirchen/knock

Yes, Ruby has private methods:

    def i_am_public
       ...
    end

    def i_am_private
       ...
    end
    private :i_am_private

    private

    def i_am_also_private
       ...
    end

Ruby has a public/private divide which can easily be circumvented. But the circumvention is a bit ugly, which is a good thing - it makes the circumvention obvious in the code.

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".

Strictly speaking ruby, private only forbids calling the method in question with an explicit receiver.

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).

With a young language, the ratio of people working on greenfield projects to legacy projects is going to be higher than with an old language.

Greenfield projects and projects < 1 year old are very common right now.

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.

I think it depends a lot on age/experience and how you got into development. In my case, I'm relatively young, lack a college degree, and started out in sysadmin and, shortly thereafter, operations engineering roles. I've discovered good ops people are a pain in the ass to find, and I had the misfortune to be very good at it, so I naturally keep getting already-"running" systems dropped on me with instructions to maintain, fix, and interface with them. I've only had one true greenfield project (still in progress) since I started getting paid for my work.

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.

So very true. Almost all the misery of maintaining and upgrading a Rails app comes from the interactions between plugins, each other, and 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.

Yes. Though principles tend to change. For examples Unix' "No news is good news" started because IO was slow via teletypes. Now we keep it, because it makes piping easier.

Also nowadays you can afford to value simplicity over speed in so many more places.

To me what the article is highlighting is a certain blindness on the part of many Ruby coders. My first language of choice is Ruby, so I'm not trying to spread hate here.

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. :)

I had someone else report an IE7 crash recently. I wish I could narrow down WHICH JS is the problem. It's just stock WordPress+various widgets.

Or as I like to put it when filing bugs:

IE8 crashes trying to run this JS code.