Ruby Weekly once again confirms my belief that Ruby developers are actually getting dumber by the week. And considering you fuckups were already as dumb as rocks, that’s saying something.
Autoloaded
Because manually telling Ruby how to magically load stuff on-demand was too hard, we now have Autoloaded. There’s a section in there about debugging. Look, shit-for-brains… once you have to debug your autoloader’s autoloader, you need to go be homeless or something. Software engineering is way too tough if you can’t handle writing out your code’s dependencies explicitly and you can’t handle setting up the autoloader.
The Rails autoloader has caused me many problems, and it was tame compared to this steaming pile. I suspect this kind of magic is what pushes Ruby devs on to garbage like nodejs – at least you aren’t guessing what the hell is using a given library or whether you still need a particular dependency.
And naturally it has its own little DSL to make devs have one more thing to learn and debug. Yeah. Have fun, kids.
Databound
So… we’re too lazy to build apps the right way to begin with, I get that. We have to use CRUD abstractions and just blast everything through create/update methods. Because you know, building domain-specific APIs that do this – well that’s hard. Sure there are benefits to having a very explicit API that is easy to read and understand, but we’re Ruby developers. We don’t like things to be easy to read, understand, and maintain; we like them to be clever and so magic that two lines of code will have a list of side-effects longer than most prescription medications (and equally frightening).
So naturally we don’t want to expose smart web service endpoints to JavaScript. Instead, we want to just magick (it’s “magick” when it’s a verb, I’ve decided) it all up via Databound. Nevermind the idiocy of exposing low-level data access methods to your UI layer. This makes it so you can build cool Web 7.0 apps without having to think about software architecture or APIs or anything! And since projects are always fresh in our minds and developers never leave, avoiding a solid API won’t ever have any maintenance costs.
App Optimization
Apparently Rails developers don’t know the first thing about web servers, because the first thing to check when you have “5-10 second pageloads” is optimizing for front-end performance.
Some of these suggestions are so obvious that even the most incompetent systems admin has already set them up. Gzipping static assets? Optimizing uploaded images to a more web-friendly size and format? Proper asset cache expiration? Avoiding JS files in the <head> section? Come on, folks, you aren’t really so stupid that you have slow-ass sites because of this trivial shit… are you??
Other suggestions are ridiculous. If your site is taking 5-10 seconds to load, and it’s because you’re not using SPDY, you’ve failed so fucking hard already, it’s not worth your time to do anything that doesn’t involve eating a god damned bullet.
Even as stupid as the article is, I expected to see a tiny bit of sanity. Like, “hey maybe spend an hour benchmarking to see if it’s front-end of back-end issues”. Nope.
And some of it is just plain bad advice.
As a site grows, it becomes unreasonable to bundle all styles into a single application.css file. Users can end up viewing pages that load 100% of a site’s styles but only use 5-10%. In cases like this, you can break up page-specific styles into individual files and load them with a scheme that uses the controller/action to find CSS files.
Ummm… yeah, okay so this isn’t entirely untrue, but realistically a single request for a 10k CSS file that can be cached all at once is still better than having five separate requests for 2k CSS files. What’s unreasonable is wasting dev time and effort to, in all likelihood, slow shit down even further. You fucking idiot.
Taking it further, there’s a good chance that if your view-specific CSS is small and users aren’t visiting many instances of the same view, making them request a second stylesheet isn’t necessary — just like with JS, you can inline them onto the page. Check out this gist for the setup I’ve used to inline CSS and JS assets in the past.
WHAT? Inline your shit? Why?
If your view-specific CSS is so small that you’d be okay in-lining it, chances are IT’S EVEN FUCKING SMALLER IF YOU SERVE IT IN YOUR GZIPPED CENTRAL CSS FILE. YOU FUCK. You’re adding uncacheable CSS and JS to your pages to avoid making your core CSS file marginally larger?
You are probably including CSS for things like Bootstrap, jQueryUI, and a billion other flashy piles of vomit because you think it’ll hide your incompetence. Those 500 fucking bytes of CSS per view aren’t going to fucking ruin you.
Unless your site is an absurd behemoth that has thousands of different views that all have their own 500 bytes of CSS. In which case, you’ve failed so SO much. I can’t imagine you’re doing anything anybody cares about if you’re that incompetent. Again, you need to quit being a dev and probably off yourself.
Conclusion
I’m better than you. I’m not good. I’m probably an “intermediate” developer. The vast majority of you are just so shitty, you make me look FUCKING AMAZING.
I guess I should thank you for that.
Ruby Weekly, you’ve hit a new low if you think this garbage is worth circulating.
I totally agree with you. Fortunately since 2 yeras I have a new life – just switched from Rails to Djabgo :)