The scopes one is interesting. I agree that you need to authorize resources, but there are some nuances at times I’ve found non-scoped finding to be useful for.
Given the application, you may want an authorization failure to return a 404 status, to prevent information leaking to unauthenticated or unauthorized users. For instance, this is what GitHub does, so that I can’t poke around a private project and look for config/initializers/ files and tell if a file exists by comparing 403 vs 404 responses.
In such instances though, you may also wish to have audit logs that distinguish between not-found situations, and forbidden situations. In that case, an unscoped find, with a separate authorization layer that effectively enforces the scope, can yield the same effect but give you distinction. This may also prove useful for plain old debugging because you get information faster as to the cause of the failure (not found vs. authorization failure).
Additionally, if you have multiple controllers acting on the same resources, if you spread finders scoping through associations across all those controllers, rather than centralizing it in an authorization layer, it can turn out to be not-very DRY and spread what is essentially authorization logic across multiple places. Furthermore, if your authorization layer grows in complexity, you effectively end up sharing authorization logic between your authorization policy layer, and your controllers.
I tend to find this plays out more for #find style calls, and not so much for where queries as in your examples. For those, I do tend to still rely on scoping more.
At the end of the day, I think what we’re saying the accomplishes the same thing, just in different ways.
Just got a batch of these led flags at the office to try out.
After seeing too many “Rails is dead” rants from intermediate developers, who may have enough experience to make their own judgements but not enough to generalize to others' situations, it’s refreshing to read this.
I agree. The future of Rails and of Ruby has less to do with raw speed or hipness than it does with having a smooth and long path from “quicky” web apps up to major APIs with many contributors and appropriate amounts of abstractions.
In my own experience, on a number of small and verging-on-major Rails apps, the transition from the former to the latter scale of Rails project has always been marked by the creation of an app/services directory.
sorry this is a bit off-topic but would you mind pointing me to what is implied by having an app/services directory? I’m currently learning Ruby/Rails at a new job that involves managing and extending legacy Rails apps and am trying to get a handle on what good refactoring paths are. I have experience doing similar work in Java but I imagine the Rails community has had plenty of time to come up with their own best practices for cleaning up technical debt.
Not OP but, if you have a flow where you are orchestrating more than a few models, doing some mailings, etc, you could extract it to a Service object (or interaction, or interactor, or whatever you prefer to call it) A classic example of this popping up in a rails project is handling signups for a SaaS. You may have to create a few internal models (User, Account, Subscription), communicate with Stripe, and send welcome emails. It’s good to compose those into smaller actions, but you probably need something top level to coordinate.
Yeah, I also highly recommend that Code Climate blog post. A set of options any solo developer or team can start using right away and grow into over time as their knowledge of architectural patterns increases (and I say that as a technical lead still only confident in a few of ‘em).
Here’s some thoughts just having watched it.
Regarding point 4, maybe some of that could be eased by not covering so much on 1 screen. For example when covering the dashboard, there’s time spent mentioning the widgets on the left (Tasks & Activity monitor) but it doesn’t seem to tell me anything.
For what it’s worth, I thought the pacing on the ‘new user’ section was the best of the different stages. I especially liked the line “Let’s have a look at Hiburo from a new member’s perspective”.
One final bit I just noticed, the “I’ve already earned an achievement for being late on my first day” is a questionable line. That’s like, everybody’s nightmare, being late on your first day of work, and you just associated the app with it so, not a greet feeling there. Maybe there’s a positive alternative like ‘Welcomed as developer to the new team!’
Thank your for such insightful feedback. It will definitely help is in the future.
I can only agree with all your points, specially about the speed. The first version of video was a bit slower, but then we cut some parts of the text, because we didn’t want to make it boring. Probably, shouldn’t have done that.
First day’s achievement was meant as joke, to lighten the mood of video. We chose exactly this achievement, because that’s what most of our users get when they first sign-up and check-in. Your point about association with the bad event makes sense, but it didn’t come to our minds when we created the script.
Speaking about js framework, it’s just plain old jQuery, nothing fancy. The backend is written in Python, with the help of Django framework.
Side note, I did not know continual was a thing, and open sourced at that. Neat, gonna read it.
It probably shouldn’t exist, but setting up Graphite and all of its Python baggage gave me trouble.
Definitely true. Analytics snippets thwarted our last attempt at CSP.
A nice side effect at the attempt at least was, we completely stopped writing inline script of our own in the app, so the exercise was not without gains. A highly recommended goal.
This is why the “Submit to Lobsters” snippet doesn’t work on GitHub repo pages.