81–90 of 93 posts
Its nice and I can see myself using it in very specific instances, but it doesn't feel like the Rails killer that the post title claims it is, but that's just me
Earlier quoted context omitted.
I disagree. The main reason I dislike Rails is that it is too complicated. When working with it every day, I regularly come across issues with it that require that I delve into the source code. More often than not that is a depressing venture. I would love something more simple, that operated with less magic, and had code that was easier to understand. I'm not sure if Padrino is the answer, but it certainly merits a…
When's the last time you had to dive into the Rails source code? The only bits of Rails I'm consistently familiar with at the source level are the code that maps HTTP parameters to the "params" hash and into AR model attributes, and the session cookie stuff --- and those are professional interests, not "I couldn't figure out how to use it" things. I'm asking seriously, because I spend about 20% of my work time writin…
Earlier quoted context omitted.
I'm not sure that's 100% accurate. "sunk costs are retrospective (past) costs that have already been incurred and cannot be recovered", says Wikipedia. However, investment in Rails can be "recovered", because it's a useful, marketable skill. Switching to something else will incur costs as well, so the benefits would need to be both high and certain to really make it a 'sunk cost fallacy', no?
> I'm not sure that's 100% accurate It is. You're conflating several different notions. A sunk cost fallacy is the idea that because you've invested a certain amount of resources (time, in this case) in a particular approach, it would be foolish to switch because all the resources you've already expended would be "wasted."
No, you're using the wrong word here. It isn't a sunk cost when you've invested resources (i.e. can recover value from those resources in the future), it's when you've spent (i.e. cannot recover value from the resources) resources.
The knowledge gained from learning Rails is obviously recoverable, and can be directly applied to future work. Throwing that away is not a sunk cost issue.
Earlier quoted context omitted.
> I'm not sure that's 100% accurate It is. You're conflating several different notions. A sunk cost fallacy is the idea that because you've invested a certain amount of resources (time, in this case) in a particular approach, it would be foolish to switch because all the resources you've already expended would be "wasted."
> A sunk cost fallacy is the idea that because you've invested a certain amount of resources (time, in this case) in a particular approach, it would be foolish to switch because all the resources you've already expended would be "wasted." No, you're using the wrong word here. It isn't a sunk cost when you've invested resources (i.e. can recover value from those resources in the future), it's when you've spent (i.e. c…
Not sure why the author of the slides presents rails as a confusing mess. If you don't like the asset pipeline then don't use it. If you don't like the scaffolds then don't generate it. If you don't like active record, then don't use it. I love the fact that these new frameworks are popping up, but why try to pull down rails in the process? If this addressed legitimate issues rails has, then I would not have a proble…
The asset pipeline you can easy do without. I've forgotten Rails even did Scaffolds. But even though AR is "pluggable", you're working against the grain in Rails if you don't use it.
I empathize with the comments from the folks who are already heavily invested in Rails. It’s so easy to “just throw the whole stack at a problem” or “kill a fly with a shotgun.” This is always the way, and it’s why new ideas rarely displace the old ones directly. Instead, they have to appeal to a younger, nascent “market” that are not attached to the old product. Padrino’s best bet is to appeal to a younger, fresher…
Anecdotal contradiction incoming. I started with Rails years and years ago (can't even remember when). I moved to Merb when Merb was the new hotness because I preferred it's modular approach. After Merb was "merged" (i.e. a few of its philosophies were put into Rails and Merb died due to lack of development), I caught on to Padrino and was impressed by it for the same reasons I was impressed by Merb. I program in Rails for a living but use Padrino for my personal projects.
I actually think a potential knock against Padrino is that it's not quite as easy to get into as Rails. When I got into Rails, it was all "create a blog in five minutes" which is what attracted me to it. There was a point where I didn't even understand the distinction between Ruby/Rails -- it was just one big scripting language to my PHP-addled mind. I think Padrino (or even just plain Sinatra) has a slightly steeper learning curve; but it's hard for me to comment on that necessarily because I am no longer a beginner and my perspective is a lot different.
Earlier quoted context omitted.
This is a weirdly emotional appeal that ignores the fact that Rails is not Struts, is nothing like Struts, isn't standing still, was more or less rewritten not very long ago by assimilating its best competitor, and that the next ORM or gem that isn't popular today on Rails is very likely to be bootstrapped and implemented in the context of Rails --- unless its key distinguishing value is "a not-Rails replacement for…
I disagree. The main reason I dislike Rails is that it is too complicated. When working with it every day, I regularly come across issues with it that require that I delve into the source code. More often than not that is a depressing venture. I would love something more simple, that operated with less magic, and had code that was easier to understand. I'm not sure if Padrino is the answer, but it certainly merits a…
What I especially like is that I can start with a single-page static HTML "app" and evolve it out as needed, and refactoring or moving things about are never an issue.
I don't worry about having to turn stuff off or tripping over someone else's conventions.
(For the latter: I do not like the convention of grouping all models in folder, all views i another, and controllers off some place else. I prefer to treat related MVC components as a "tuple" and keep them together. This is how, for example, it's done with Monkeybars; I find it much more logically coherent, and this is how I organise my Ramaze projects.)
Earlier quoted context omitted.
About a week ago I had a problem with after_commit callbacks not being called. It turns out (after diving into the AR source) that they indiscriminately swallow errors from after_commit callbacks. If you're testing a newly-created callback it is difficult to determine whether it's actually been called or merely just raised an error. I couldn't have figured that out without reading the source- it's not documented. Fro…
"The after_commit and after_rollback callbacks are guaranteed to be called for all models created, updated, or destroyed within a transaction block. If any exceptions are raised within one of these callbacks, they will be ignored so that they don’t interfere with the other callbacks. As such, if your callback code could raise an exception, you’ll need to rescue it and handle it appropriately within the callback." htt…
― http://guides.rubyonrails.org/active_record_validations_call...
Earlier quoted context omitted.
"The after_commit and after_rollback callbacks are guaranteed to be called for all models created, updated, or destroyed within a transaction block. If any exceptions are raised within one of these callbacks, they will be ignored so that they don’t interfere with the other callbacks. As such, if your callback code could raise an exception, you’ll need to rescue it and handle it appropriately within the callback." htt…
"The whole callback chain is wrapped in a transaction. If any before callback method returns exactly false or raises an exception, the execution chain gets halted and a ROLLBACK is issued; after callbacks can only accomplish that by raising an exception." ― http://guides.rubyonrails.org/active_record_validations_call...
Padrino is really nice web framework for Ruby. I have used it for experimental projects. My work was using latest Padrino framework at work, but extremely unhappy with the its performance (slow response). We had ported the app to Rails 3.1 for better performance. (We will upgrade it to 3.2 soon) In fact, I think Padrino is pretty ideal for personal and small apps. Not really ideal for medium to large apps. Just my op…
My current Padrino project is around 2000 LOC, excluding tests. As it has grown more complex, I've broken off larger parts of its functionality into smaller apps within the same project. These apps share some resources -- particularly models -- but in terms of controllers and helpers, they are very much distinct in their roles in the overarching project.
Padrino has changed my mindset on how I approach large projects. Instead of trying to create something massive in itself, I logically separate key parts of the overarching app into smaller apps mounted within the same project.
I question the entire concept of a "large app". When classes are too large, methods are too long, it's generally considered to be sub-optimal code, or poor design, and there's a point where one is expected to break these things down into smaller pieces. Why does this concept not apply to our web apps?