4 ms·

> 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 framewo

> 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?

Haydos585x2 10y ago
They probably do it with all the spare time they have from using a framework to handle so many other features.
- sfilargi 10y ago
  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
  - reitanqild 10y ago
    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.
    - sfilargi 10y ago
      > 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.
mmanfrin 10y ago
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).
inopinatus 10y ago
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.html#creating-a-bug-report 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.
- sfilargi 10y ago
  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.
  - sandstrom 10y ago
    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!
- rmchugh 10y ago
  Interesting, my experience is the opposite: liberal use of ruby's dirty tricks often makes code hard to understand and thus debug.
  - epidemian 10y ago
    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.
    - inopinatus 10y ago
forkerenok 10y ago
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.
rimantas 10y ago
> 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.
- nix0n 10y ago
  > Because alternative is to hunt obscure bugs in the framework you built yourself. That's a false dichotomy, there are also smaller frameworks available.
- mudbutt 10y ago
  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!
juandazapata 10y ago
Because small frameworks don't have bugs, right?

Haydos585x2 10y ago

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

sfilargi 10y ago
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
- reitanqild 10y ago
  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.
  - sfilargi 10y ago
    > 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.

mmanfrin 10y ago

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

inopinatus 10y ago

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.html#creating-a-bug-report 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.

sfilargi 10y ago
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.
- sandstrom 10y ago
  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!
rmchugh 10y ago
Interesting, my experience is the opposite: liberal use of ruby's dirty tricks often makes code hard to understand and thus debug.
- epidemian 10y ago
  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.
  - inopinatus 10y ago

forkerenok 10y ago

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.

rimantas 10y ago

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

nix0n 10y ago
> Because alternative is to hunt obscure bugs in the framework you built yourself. That's a false dichotomy, there are also smaller frameworks available.
mudbutt 10y ago
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!

juandazapata 10y ago

Because small frameworks don't have bugs, right?