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.
Some readings:
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).
[Comment removed by author]
I can think of a number of reasons this could be going on:
suppress opens up old wounds for some people.As an aside, I’m anxiously awaiting his book on rom + roda. Really looking forward to seeing some ideas more codified in there.
The fact that Rails is way after its own “golden year” and its not trendy anymore in community of hipsters with Mabooks drinking Starbucks coffie does not even mean the “Rails is over”. You’re saying “IBM mainframes are over” only because there’s no media coverage about it now? Surprisingly, the giant boxes of silicon doesn’t care about being photographed and interviewed ;)
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.
A warning when using the Content-Security-Policy header: it will break almost all third-party Javascript snippets on your site. Most of these snippets are designed to be inline scripts, which is usually a feature you want to disable with content security.
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.
Just got a batch of these led flags at the office to try out.