"I dislike the complexity of Rails and wish to make my own way of things."
..three years later...
"We are upgrading to Rails."
Ruby Web Dev The Other Way
51–60 of 65 posts
Re: Ruby Web Dev The Other Way
#52Earlier quoted context omitted.
Try to use Trailblazer. Even if you would not adopt it entirely - it is really a great way to broaden your perspective. An Editor is solely personal taste.
I have only a fleeting familiarity with Hanami and Trailblazer. It struck me that they are both achieving very similar ends. I preferred Hanami in that it retained very discoverable mechanics for people comfortable with recent low-level trends in webdev (e.g., Interactors are simply Service Objects) while Trailblazer seems to have its own heavily engineered high-level paradigms (e.g., Cells) that seemed more suited t…
Yes, they really have similar parts (mostly Operation and Action). But Hanami is a framework and Trbr is a architectural layer, that could be used inside any framework. In Trbr I really like the idea of Representable to convert objects. Trbr is more tailored for Raiks, to allow step by step improvement of existing Rails apps. Maybe it is not so important for Hanami, but with Sinatra it will still help a lot.
Re: Ruby Web Dev The Other Way
#53This confirms my overall feeling when considering Ruby and Rails. Instead, I choose Python and Flask. The whole Zen of Python really spoke to me and my team members: https://www.python.org/dev/peps/pep-0020/ No magic, just developer clarity. Neither of these items seemed like a primary concern for many different Ruby libraries and Rails itself. I also suggest trying out data mapper pattern instead of active record. F…
I didn't like the magic of Rails either, but didn't grok Python :( I'm much happier using Ruby + Sinatra + Sequel/ROM + dry-rb I do admit that Rails devs develop considerably faster than me. But I get a feeling the majority of them can't make much more than a single machine monolith. Rails has a way of narrowing many people's technical curiosities. But it probably behooves both sides to learn more about each other.
> Rails has a way of narrowing many people's technical
> curiosities.
Re: Ruby Web Dev The Other Way
#54The first few sentences of this article sold me. Because it describes to me exactly why I hate Rails, and Ember, and any other framework with a similar model. I hate Rails because Rails is Magic. And not the good (well, as good as magic can be), 0x5f3759df kind of magic either. The kind of magic where you're given some functions to call, and some places to put your code, and if you ask why, you are told that you don'…
There is no magic in Rails if you at least give some effort to understand how things work.
But everyone is free to invent their own incomplete and flawed versions which has benefit that you know the magic behind your framework. Alas, no one else does.
Re: Ruby Web Dev The Other Way
#55begin minor rant... Occam's razor is misused in the manifesto. The author indicates that it means "Prefer simple solutions", which it doesn't. Occam's razor requires a hypothesis, and generally means "Among competing hypotheses, the one with the fewest assumptions should be selected". For example, Special Relativity is exceedingly complex, especially if I try to explain it to you. Ontologically though (in actual fact…
Well, actually... http://tirania.org/blog/archive/2011/Feb-17.html
Wrong.
I'd explain why, but then I'd be called a "well-actualista".
Re: Ruby Web Dev The Other Way
#56I agree with the Manifesto. I've been using Rails professionally for 6+ years and the magic still causes some confusion. The Rails ecosystem provides so much out of the box and so many answered questions on Stack Overflow and Google it would be a constant uphill challenge to go against that flow. I'm looking forward to moving to Elixir and Phoenix which seems to embrace the less magical, more explicit manifesto while…
If you've been using Rails for 6+ years and aren't at least passingly familiar with the majority of the source code and design decisions, then you aren't a very curious developer
Re: Ruby Web Dev The Other Way
#57I'm not going to be able to comment on everything on this article and it is indeed a wonderfully put together resource, but I must say that I tend to disagree with the over-all premise. Yes, if you are a first time or beginner developer Rails can be overwhelming and you will learn a lot more by using a smaller framework such as Sinatra. On the other-hand if you are undertaking a medium to large scale project (and not…
Sounds like advice I would give a Python programmer who is considering a micro/mini-framework instead of Django.
I never really understood the micro-framework hype. Django is heavyweight, but you don't need to use every feature. And when you do need the feature it will work nicely with the other components.
Re: Ruby Web Dev The Other Way
#58Earlier quoted context omitted.
Sounds like advice I would give a Python programmer who is considering a micro/mini-framework instead of Django.
I never really understood the micro-framework hype. Django is heavyweight, but you don't need to use every feature. And when you do need the feature it will work nicely with the other components.
The argument boils down to "more code, more bugs" so large frameworks are less trustworthy than small libraries.
Of course on the other end these popular large frameworks often have a lot more maintainers (sometimes even more maintainers per line of code) than the smaller libraries frequently only maintained by one or two people. And there are of course synergies (yes I'm using that word unironically) when all the code lives in a single ecosystem rather than being based on a unique combination of purpose-built libraries.
Having used both Django and Flask, and various front-end frameworks and libraries, I can see the appeal of both sides of the argument. In the end I haven't found either argument to be bullet-proof though. Everything is always a trade-off.
Re: Ruby Web Dev The Other Way
#59Earlier quoted context omitted.
> Counterargument: nearly every medium-large scale project I've seen in Rails ends up full of mismatched idioms and confused usage of Rails core utilities and just general jankery. I think you could remove the word "Rails" and say the same about any medium-large scale software project with several developers working on it. Say what you will about Rails, but after working with it for about a decade, it's actually prev…
Totally anecdotal, but the past two startups I worked at used Rails on greenfield projects. The first one decided to go "off the rails" and made up their own architecture based on Uncle Bob's SOLID design principles or whatever. We weren't allowed to use ActiveRecord, which is a huge part of how you handle domain logic, validations, relationships, cascading deletes, and data consistency in Rails. Instead of ActiveRec…
Sounds like the first one could've used http://trailblazer.to/ - so far I'm using the [Reform](https://github.com/apotonick/reform) gem more because the app I'm currently working on is getting more forms that consists of multiple models (ActiveRecord and API). A shame that the [ActionForm](https://github.com/railsgsoc/actionform) GSoC project didn't make it to Rails core.
I haven't bought the Trailblazer book yet but I probably will somewhere in the next couple of weeks.
Re: Ruby Web Dev The Other Way
#60Earlier quoted context omitted.
Sounds like advice I would give a Python programmer who is considering a micro/mini-framework instead of Django.
I never really understood the micro-framework hype. Django is heavyweight, but you don't need to use every feature. And when you do need the feature it will work nicely with the other components.
This is largely true for someone who already knows the framework(s), probably less so when you're learning. There's less to do to make "a thing" that works in Flask than in Django. That said, many of the times I've reached for Flask I've realized, eh, it's going to be just as quick and "light" to do this in Django. At the working, production level, I wholly agree with you.