This is the first post in a new "flare tag" we're trying out: #healthydebate.
This tag is a place to create posts with the expectation of a debate...
For further actions, you may consider blocking this person and/or reporting abuse
What i love the most about Rails/Ruby is the top-notch quality of documentation.
I don't know how good your favorite language is, what i care first is documentation.
Because without good documentation, how good knowledge can be shared and improved ?
I've been doing Qt in the past and title of top notch documentation (in my personal opinion) is still with Qt.
With Rails you have to read up comments and issues on GitHub.it feels like documentation is a bit behind from actual usage...
I also feel like error messages have been really improving over time.
I said this thing by having little experience with "non-toy languages", what i see is non-existing or very bad quality of documentation. They said: Type is documentation. It's not an excuse for not having a good documentation to welcome and share knowledge among community. It made me sad.
I've always like Rails a lot but its always been a chore to configure and host it for a production environment with Apache/Other Webserver. Has this part been improved any lately?
Though maybe the answer is DigitalOcean:
digitalocean.com/community/tutoria...
I think it has improved a lot, but I agree that this is still not a strength.
Rails can also be a real pain to get setup in development if anything goes wrong especially outside of the Mac ecosystem.
What does dev.to use for its production setup? I've used Apache2 with the Passenger Apache module and RVM. I then use Capistrano to deploy new releases of the Rails app.
Works well once I figured out how to get it all working, but has me concerned it will be hard to re-create when I have to update the operating system down the line.
For what it's worth, I've had a positive developer experience with Linux.
They run on Heroku using puma
We run on Heroku using Puma because several years ago I was pulling my hair out trying to get my Rails server working and found Heroku and got everything set up in about ten minutes.
Haven't looked back since. Others in the industry have caught up to Heroku in this regard, so I can't say I'm hooked for life, but I've defaulted to them ever since. So when this was a solo project I just went with what I knew.
I agree with Dave.
I use
rbenvfor Ruby version control on Linux where it has been a joy to learn Ruby/Rails.😄 A shout-out to ActiveStorage! Rest in peace paperclip, carrierwave and others 💀
I love ActiveStorage too, I use it on my personal website and on all new projects at work.
But one major shortcoming I found, and something I hope will be addressed/changed in future versions, is that images cannot be cached by CDNs. I have CloudFront and CloudFlare caching static assets, but I had to exclude images because ActiveStorage generates 5 minutes-lived URLs from the backing service, and after 5 minutes if the cache tries to refresh itself it returns a 404 error.
As you can see in this issue on GitHub, it is a common concern.
Yeah I faced the same issue with no success :(
How did you work around it?
Seems like ActiveStorage was planned for files rather than for images :/
Well... I didn't ahah
We're just avoiding caching images, inefficient but at least it works. I hope they'll fix it soon
dev.to is still on carrierwave 😱
Promise we'll get to 5.2 soon!
Carrierwave is still much better than ActiveStorage in some circumstance. You don't need two extra queries to get assets of an object, f.e.
Wait, you're not going to break up Dev.to into microservices anytime soon?
Why would they, I see no real benefits in turning this website into microservices.
It is a rather small-focused platform, with a small team developing it and no real concerns in terms of scalability.
I was being facetious. There is nothing wrong with monolithic apps.
We worked with a few consultancies leading up to the open source announcement, mostly for a security audit.
I recall one convo where I was describing the system and I said "it's a Rails monolith", and their immediate automatic response was "so you'll want help breaking it up into microservices".
I was like "What, no! I love our majestic monolith". We do use a handful of external services (ours and SaaS), and none of it makes our process simpler. If anything we want to pull more stuff into the core codebase over time.
There are a lot of valid architectures, and monolith is absolutely one of them.
It is amusing to me because a microservice architecture is just a monolith broken up into smaller apps. For a startup, it makes no sense to put the extra planning and context switching onto the team just to have a more trendy setup. As DHH said, embrace the majestic monolith!
Even though I am pretty anti big framework, a part of me wants to live in that kind of ecosystem for the fun of it, loads of people cant be that wrong huh
The last biggish framework I used was a while ago when ASP MVC came out
Do you have any recommended reading material for someone who's been programming a long time but not done a lot of ruby and basically no rails?
Back when I did this sort of thing, it was the Hartl book that was always recommended.
I'm a frontend dev who just started building with Rails. I haven't had this much fun since I learned React.
I love how quickly you can scaffold apps. The community is also very welcoming.
@tux0r I take you for a Rails non-believer.
I'm a toy scripting language non-believer.
What about for scripts? Do you have a preferred way to do quick little algorithms?
I would say Python, but I don't want to read the replies ... :-)
Quick little algorithms are - when I have the choice - usually implemented in C or Lisp, depending on their complexity.
Is your implication that Ruby is a toy scripting language?
Fairly common here, especially among web companies that sprang up between 2008 and 2015 or so. I think it's definitely fading as a popular starter choice. Node, Go and Elixir definitely took a huge bite out of its popularity.
I think to embrace Rails one needs to embrace the "manifesto". I was learning Ruby and Rails a few years back and decided to give up just because it was too magical and its convention was very "dictatorial" to me. I went straight back to Python.
As I've grown more as a developer and had a few more languages in my toolbelt, coming back to Ruby and Rails wasn't so bad. Things started to make more sense and fall into places. (Symbols make sense to me now that I've known Clojure. Lack of parentheses aren't a stranger any more now that I've known Ocaml) I think Ruby (and Rails as a derivative) is a great attempt of an expressive language that's not too mind-bending (as in many functional ones) and yet very simple and even human-friendly.
Reading up the Rails Doctrine by DHH is a pretty good way to befriend Rails. Rails is really pleasing if one can start thinking less about perfection and idealism in a tool and more about shipping.
Hi @ben , through this DHH tweet
I came across this recent post Upgrading GitHub from Rails 3.2 to 5.2
It might help :-)
Thanks!
Here are a few points regarding what makes an ecosystem healthy:
Maturity - Rails is a very old framework (first version almost 10 years old) and as such, is mature. It is possible for a software to be feature-complete and just release bug fixes. The "cons" of maturity are that newer developers will feel that the technology is boring because of wide-spread acceptance in enterprise and smaller shops.
Availability of libraries - It is difficult for a core framework/library to solve every single problem in a particular niche. As such, it needs a plethora of libraries(gems in case of Ruby) which depend on it and solve ancillary user needs. For example, in web development, a framework can provide routing, templates, caching but leave out ORM or DB access or authentication to other libraries. These libraries help a framework stay relevant. Rails has a plethora of gems which solve a wide variety of problems.
Assumptions - A framework or library is created with some core assumptions which are heavily based on problems of that time. Rails solved a very real problem of the time of quick prototyping and easy iterative development. As times change, the pressing problems of developers change as well. An existing framework may have to reinvent itself or risk being replaced by newer technologies which solve the problem better.
Inertia - A framework has to maintain a balancing act in terms of making changes. Breaking changes displease existing users while no changes lead to code smells due to old mistakes never being fixed. Add too many features and the learning curve and discoverability is affected.
Very well-put.
I always send them to speedshop.co/blog/ :D
I've been doing Rails for a while, but until Rails 5 it felt like a burden. I always preferred sinatra/roda over Rails. Tried playing around with other frameworks...
But somehow after working more with Rails 5. It became my default option for a framework. Eco-system became mature enough to have good choice in gems, that satisfy my picky standards. I hardly have 'I'll write a simpler version of this gem in couple of days' moments and I feel like I have more time to do meaningful work.
I mostly agree, although since I started on Rails 5 my perspective doesn't go back very far.
I'm a little concerned with the pace of adoption of HTTP/2 features. Rails just got early hints for pushing assets, despite discussions about H2 and Rails going back to at least 2014. A quick search reveals zero info about whether the Rack/Rails ecosystem supports header compression. The most popular deployment option, Heroku, doesn't support H2. This concerns a feature that reached all major browsers over three years ago.
Webpack support has been great for modern frontend tooling, though the shiny new Webpack 4 was released months ago and support via the Webpacker gem is still in prerelease.
So yeah, working with Rails is awesome, and constantly getting better. That's why these few exceptions stick out to me, because they represent little pockets of stagnation in an ecosystem that consistently makes my work better and easier. These are pretty luxurious complaints to have, all things considered.
A lot of Rails apps are deployed on Heroku, I feel like if they started supporting it there would be more interest by the Rails community to go "HTTP/2 first"
I'm currently working on a company project with Rails 5.2. We're still on much older version of Rails for the majority of the main product so I can clearly appreciate the progress.
In particular I love how they managed to make Rails 5 much more modular and enabling only the things that you really intend to use keeps the resulting application much lighter to run and work on.
To be fair, I do see the benefits of microservices in the right scenario.
They allow for small, independent teams to focus on simple, testable and disposable bits of a greater application and this can help reduce time-to-market and embrace continous delivery when building complex and intricated systems.
I worked on a not-quite-microservices-but-still-service-oriented project and it was fun, bits of the application can go online without worrying about the others (we used message queues to decouple them). But it surely was complex to handle and maintain compared to a monolithic application.
This is pretty amazing. Both GitHub and Shopify are huge, billion dollar companies running on the original apps made over a decade ago. And they now both on the latest Rails, helping to push the framework forward [1]
I can't wait for y'all to see what we upstream now that we're in a position to give back and improve Rails. My keynote; Rails 6.0: Scalable by Default [2] at RailsConf was just a small portion of our plans for Rails. [3]
There are also work from Discourse on Rails performance, Ruby is getting a Method JIT. [4] and working on more pref work. TruffleRuby is close to 1.0 and it is available on all ruby manager [5]. The Open Source build is now also available on macOS as well.
There are lots more, and all of them were years in making, It took a year for Github to get to latest Rails release.
For the past few years, many have been writing off Ruby Rails, Ruby is comparatively expensive to scale ( and it still is ) , we expected other frameworks to catch up in terms of productivity, and will spell doom to Ruby Rails. Not only has such framework yet to appear, Ruby Rails continues to improve on all front.
I say the best days of Ruby Rails is yet to come.
[1] twitter.com/dhh/status/10305284762...
[2] speakerdeck.com/eileencodes/railsc...
[3] twitter.com/eileencodes/status/103...
[4] twitter.com/k0kubun/status/9601125...
[5] github.com/oracle/truffleruby/blob...
I think a major part of Rails' popularity in US/Canada is because it started in the States. I read an interesting article once about Ruby + Rails in US vs Europe. Wish I could find it...
I still have problem understanding why no nested directories. It was a big "no" without explanation.