Hacker News Reader

Comment by sfilargi | Hacker News Reader

> IMHO these fixes address dozens of bugs that could cause major puzzlement for a typical Rails developer.

That has been the reason I always avoid huge frameworks like RoR.

If I was to hit a bug like this, I wouldn't know where to start debugging. How do people deal with obscure bugs in the framework with something like RoR?

View on HN

You start by boiling it down to an executable test case, for which there are templates here here: http://guides.rubyonrails.org/contributing_to_ruby_on_rails....

Then you share the test case in a bug report, and collaborate to fix it. Fixing it usually involves a source code dive.

With Rails's reasonably well documented and reasonably well written codebase it's usually possible to grok the source and dependencies even coming to it cold. With the possible exception of arel.

Ruby's dirty tricks department (monkey-patching third-party objects) and duck typing together are a real boon to debugging.

Nice, thanks. Pretty impressive documentation.

Seeing the praise it gets here, I will definitely give RoR a chance for my next side-project. Thanks again.

I think you will like it!

Github, Shopify, AirBnB, Indiegogo, Kickstarter, Twitch, Zendesk and many others run on Ruby on Rails. You'll be in good company!

Interesting, my experience is the opposite: liberal use of ruby's dirty tricks often makes code hard to understand and thus debug.

That's a separate statement, and they are not contradictory.

Using Ruby's dirty tricks on shipped code -> hard for debugging/understanding. Using Ruby's dirty tricks while debugging -> boon.

The grandparent didn't claim the former to be false, only the later to be true.

This is a correct reading of my remark. I happen to agree with the opinion of the followup as well, monkey-patching in production is a code stench.

Still I plead guilty to having occasionally monkey-patched prod code out of urgent necessity. My recommendation is to view it like an advanced and undesirable form of configuration; for my rails apps, each such hack always goes in an initializer file named for the library it is patching. If you are replacing third-party methods (or undermining the behaviour of a third-party method) and those methods are not called very frequently then judicious use of log noise e.g. through the deprecation mechanism will help at debug time.

i think different areas of Rails codebase vary here, some are pretty legible, some less so.

Once you understand how it all works, I'll grant that that can take years, it doesn't take much time at all to debug upstream code. Just last night I was playing around with the jsonapi-resources gem, and found an issue that was keeping me from being able to dynamically generate resources. After realizing I couldn't work around the issue through more metaprogramming, I set about monkey-patching the code.

It got too late so I couldn't finish the job, but once I do, I'll get it working for my project, then package it up and make a pull request so I don't have to support it myself.

Ruby is definitely wizardry but it's accessible wizardry.

They probably do it with all the spare time they have from using a framework to handle so many other features.

If you are lucky enough to hit it during development or testing, then yes, fair point.

If you hit however in production and only under load or some corner cases, it must be a real bitch to try to debug code that you haven't wrote yourself.

But since my original post is being seen as a troll, I think I will just shut-up and go hide under a rock or something. :D

Definitely not a troll I think. I guess downvoted because of disagreement.

I'll also try to explain why:

A few weeks later I have forgotten the specifics about my own code as well.

Also: often there are fewer bugs in library code.

And: getting help (paid or through stackoverflow) is probably easier.

> I guess downvoted because of disagreement.

Fair enough :D

> A few weeks later I have forgotten the specifics about my own code as well.

> Also: often there are fewer bugs in library code.

> And: getting help (paid or through stackoverflow) is probably easier.

I can definitely see your point, especially about being easier to get help. I imagine if you are anything other than a one man shop, you will be in much better position debugging Rails or Django, rather than trying to figure out the mess you ex-employee left.

   > That has been the reason I always avoid
   > huge frameworks like RoR.

For others it is the reason to use huge frameworks like RoR. Because alternative is to hunt obscure bugs in the framework you built yourself.

> Because alternative is to hunt obscure bugs in the framework you built yourself.

That's a false dichotomy, there are also smaller frameworks available.

Finding bugs for something you wrote yourself is easy because you WROTE it and can easily reason about what each method does, what data/methods does it have access to etc. etc.

Anyways, I unfortunately work with Rails and I hate it. To me Rails stresses and encourages bad practices, everything has an implicit environment inherited from a massive hierarchy of classes with their own implicit environment that will only work if the current state of the app matches what each classes assumes it will be.

Data changes and morphs during the initialization and creation of class instances causing shitty bugs. EVERYTHING needs careful consideration of all of these relations and class hierarchies before writing simple things.

Everything is highly coupled and interwoven making a change one place break something somewhere else. Rails should be taught in Universities as a case study in the pitfalls of Object Oriented Design

Also essentially all of the major players have left and moved on to new things. Most Ruby Gems haven't been updated in years!

Appreciating the sentiment, I would like to add that a great framework builds a great community around itself, which helps (A LOT) sort out (in the worst case work around) all sorts of issues. And this holds for Rails.

These are bugs from the 5.0.0 release. I can't really think of a time where Rails itself cause issues in my day-to-day (other than missing a timezone which was something I could easily fix).

Because small frameworks don't have bugs, right?

Reply on news.ycombinator.com