31–40 of 250 posts
If you replace the title with Django it still works. I’m doing the same as the author, but with Django.
As someone who doesn't do enough web dev to justify learning Ruby just for Rails: how does it compare to Django? That's the only batteries-included web backend framework I'm familiar with... Asking out or curiosity.
Earlier quoted context omitted.
Is this really necessary given the advances with SQLite in Rails 8? What edge does this have over what’s included these days?
Litestack provides numerous benefits, but the largest is live replication to S3-compatible storage, which SQLite will not do by default.
What they meant was https://github.com/oldmoe/litestack which has a lot of things built on top of sqlite, like job queue and caches. Rails 8 now comes with most of them out of the box.
My SaaS ran on litestack until rails 8 came out, then I switched without problems.
Don't really know much about Rails because I wound up picking Django instead when faced with the choice many years ago. That said, honestly, my perspective of Ruby on Rails has been tainted by watching GitLab get pwned over and over and over. My distro can barely keep up with GitLab being pwned because by the time the security release hits stable channels there's already another CVE. I liked GitLab, but something is…
I’m curious on others thoughts on whether or not to use Devise? With the recent Rails updates, even in Rails 7, Devise didn’t seem that useful and seemed to over complicate the user authentication, registration, lost password experience and also seemed like I had to do a lot of work overriding their views to fit with my application. It seemed easier to not use Devise? It had its usefulness in earlier versions of Rail…
For very simple username/password authentication, what Rails 8 provides is probably sufficient. But the moment you need other auth providers, 2FA, etc., Devise is very much still useful.
Earlier quoted context omitted.
Huh. TIL. But in the rails context couldn’t you mostly manage with an ActiveRecord validation? I know it wouldn’t be ideal.
This is perhaps what you were hinting at when you said “wouldn’t be ideal”, but Active Record validations on their own are subject to race conditions with concurrent requests. The only truly safe way to ensure integrity of your data is to enforce validations/constraints at the database level. IME you usually want _both_ the Active Record validations, and the database-level validations, because you get better error me…
Don't really know much about Rails because I wound up picking Django instead when faced with the choice many years ago. That said, honestly, my perspective of Ruby on Rails has been tainted by watching GitLab get pwned over and over and over. My distro can barely keep up with GitLab being pwned because by the time the security release hits stable channels there's already another CVE. I liked GitLab, but something is…
As a counter-point (and I know nothing about Gitlab), but GitHub and Shopify are both prominent Rails apps with pretty good security records. GitHub wrote about it last year: https://github.blog/engineering/architecture-optimization/bu... I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securel…
- PHP had a really good developer experience (even with the rough edges, for the time), but building robust applications on PHP could prove quite challenging. It has gotten a lot better, but there are still remnants all over from the past.
- Ruby, likewise, seems to have a really good developer experience, and indeed it seems Rails apps sometimes suffer with robustness and reliability. Not just GitLab, but also Twitter in the past, too.
I think some people may read what I'm saying and think I'm just a hater, but not really. I actually just wonder if what I see with GitLab is telling us more about GitLab, or if it's telling us more about Ruby or Rails. Is it hard to make robust Rails software?
> I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securely go learn before building (or learn as you go, but that has consequences typically).
This is good general advice but I am aiming more specifically. I'm wondering if anyone with more expertise could answer to what classes of issues you have to work to avoid. I know Shopify was working on gradual static typing for Ruby: is dynamic typing a problem? That sort of thing.
Of course, you can write both secure and insecure code in any programming language in many different ways, but some ecosystems make it easier and harder and I think that's more what I'm getting at.
Frankly, even if it's true that it's tricky to make Rails apps secure, that wouldn't really dissuade me from still using it in some cases if it seemed like it could save me a lot of time and effort. That's pretty much exactly why I used Django to begin with; I definitely don't feel like Django was the most robust platform to write webapps in, just a very productive one (that was still decently robust in my experience, but you know, YMMV.)
I hope as an industry we can move away from this "___ is dead" talk. The OP shouldn't even need to say this. If something is being worked on (in any capacity) and has at least one user, it isn't "dead."
"Is it dead" is groupthink questioning that leads to great ideas being swept under the rug because they're not perceived as popular enough.
Think for yourself and use the tools that make sense to you.
Earlier quoted context omitted.
As a counter-point (and I know nothing about Gitlab), but GitHub and Shopify are both prominent Rails apps with pretty good security records. GitHub wrote about it last year: https://github.blog/engineering/architecture-optimization/bu... I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securel…
Of course, it's definitely not impossible to write secure Rails apps, just like anything else; it's hard to know from the outside what that says about Rails in particular. For example, PHP had a lot of rough edges, but Facebook still managed to take it to the highest heights as far as websites go. I'm not arguing Rails is like PHP, but I see a commonality: - PHP had a really good developer experience (even with the r…
I don’t see as many CVEs, at least to my knowledge, with GitHub or Shopify. Not that they haven’t happened, but seem to _much_ less. Stripe is mostly ruby, though not rails, and have done well with security.
My suspicion from outside of Gitlab is that it’s a quality and prioritization problem. Security is hard. It requires very deliberate decision making and investment. Ruby and Rails are generally very stable, but you can use them to crazy ends if you allow yourself to.
> Rails is not dead; It's better than ever. Try using it to make something new this year. I hope as an industry we can move away from this "___ is dead" talk. The OP shouldn't even need to say this. If something is being worked on (in any capacity) and has at least one user, it isn't "dead." "Is it dead" is groupthink questioning that leads to great ideas being swept under the rug because they're not perceived as pop…