From d18165f4b22ee6636103d5fed2b4a411b1cc3550 Mon Sep 17 00:00:00 2001 From: David Eisinger Date: Sat, 4 Nov 2023 13:38:46 -0400 Subject: [PATCH] Edit ruby post --- .../index.md | 10 +- static/archive/codefol-io-bskabg.txt | 374 ++++++++++++++++++ themes/v2/layouts/elsewhere/single.html | 1 + 3 files changed, 383 insertions(+), 2 deletions(-) create mode 100644 static/archive/codefol-io-bskabg.txt diff --git a/content/elsewhere/why-i-still-like-ruby-and-a-few-things-i-dont-like/index.md b/content/elsewhere/why-i-still-like-ruby-and-a-few-things-i-dont-like/index.md index e0a9ccb..f749e20 100644 --- a/content/elsewhere/why-i-still-like-ruby-and-a-few-things-i-dont-like/index.md +++ b/content/elsewhere/why-i-still-like-ruby-and-a-few-things-i-dont-like/index.md @@ -3,6 +3,12 @@ title: "Why I Still Like Ruby (and a Few Things I Don’t Like)" date: 2020-08-06T00:00:00+00:00 draft: false canonical_url: https://www.viget.com/articles/why-i-still-like-ruby-and-a-few-things-i-dont-like/ +featured: true +references: +- title: "When Should You NOT Use Rails?" + url: https://codefol.io/posts/when-should-you-not-use-rails/ + date: 2023-11-04T17:36:55Z + file: codefol-io-bskabg.txt --- The Stack Overflow [2020 Developer @@ -49,7 +55,7 @@ from and contributes to, and with a few notable exceptions[^2], it's all made available without the expectation of direct profit. This means that you can pull a library into your codebase and not have to worry about the funding status of the -company that built it (thinking specifically of things like +company that built it (contrast with ventured-funded open-source like [Gatsby](https://www.gatsbyjs.org/) and [Strapi](https://strapi.io/)). Granted, with time, money, and a dedicated staff, the potential is there to build better open source products than what small teams can do in @@ -151,7 +157,7 @@ thread](https://www.reddit.com/r/ruby/comments/hpta1o/i_am_tired_of_hearing_that (and [this comment](https://www.reddit.com/r/ruby/comments/hpta1o/i_am_tired_of_hearing_that_ruby_is_fine/fxvfzgo/) in particular) or [this blog -post](http://codefol.io/posts/when-should-you-not-use-rails/), but what +post](https://codefol.io/posts/when-should-you-not-use-rails/), but what really matters is whether or not Ruby is suitable for your needs and tastes, not what bloggers/commenters/survey-takers think. diff --git a/static/archive/codefol-io-bskabg.txt b/static/archive/codefol-io-bskabg.txt new file mode 100644 index 0000000..ef67d5d --- /dev/null +++ b/static/archive/codefol-io-bskabg.txt @@ -0,0 +1,374 @@ + [1]Codefol.io book logo + +[2]Codefol.io + + * [3]All Articles + * [4]Articles by Topic + * [5]Favourite Articles + * [6]RSS + * [7]About + +When Should You NOT Use Rails? + + A chimpanzee in a white coat types at a keyboard lit by glowing LEDs. + He's gorgeous, yes. But is his talent natural… or is it Ruby on Rails? + + I was [8]recently on Jason Swett’s podcast again. He’s a great + interviewer and I always have fun with him. + + By Twitter request we talked about… When would you not use Rails? It’s + a great question. + + For the entertaining version, [9]listen to the podcast. For the + just-the-facts extra-complete version, I’m writing this post. + +When Is Rails the Wrong Choice? + + I’ll start with a few simple, obvious times you wouldn’t use Rails, and + then I’ll talk about some technically interesting times. + + First, and most important, is team familiarity. If your team doesn’t + already know Rails and isn’t especially interested in learning it then + Rails is the wrong choice. This should be obvious, but it still + deserves first billing. + + Second, when you know some other framework fits better. I’ll talk more + below about when that is. But sometimes you have a specific concern + that trumps everything else. If you need to use a Java-language machine + learning library and you don’t want to use JRuby for some reason, Rails + isn’t your framework. If you’re writing a WordPress plugin, you’ll be + doing it in PHP. Often there’s one specific compatibility concern that + overrides everything else. + + You can also think of it as: use it where Rails’ good points hold and + its bad points don’t. So we’ll also talk about the good and bad points. + + Separately: you’d normally only use Rails as an HTTP server, so some + tasks just aren’t Rails-shaped. + +When is Rails Too Much? + + [10]A pirate puppet with an eyepatch, safety goggles and a huge + scraggly mustache watches over a purple crystal ball at his feet.' He’s + too much lab assistant for your lab. + + Some places not to use Rails can include: + + Really Small Tasks that Won’t Grow: if a server does very little, Rails + is often too much. Not going to touch a database? Then the DB setup + isn’t helping you, is it? Just a tiny low-traffic intermediate server + with no caching? A lot of Rails is more trouble than it’s worth. + + Be careful with tasks that grow, though — making a tiny server scale up + to do a lot more can be ugly. If you’re already serving HTTP pages to a + human with a web browser, consider that you may have to add features to + it later. Something like that is already fairly large from the word + “go”. + + When It’s ‘Just’ an API Server: Rails has less to offer an API server + that speaks JSON over the wire. A lot of its HTTP security doesn’t + matter for that case: CSRF protection is entirely about dealing with + HTML and Javascript. Many kinds of XSS attacks are dependent on a + browser as the weak link, or on putting unescaped user input into HTML. + Redirection vulnerabilities assume automatic redirection, which APIs + usually don’t do. You can prevent SQL injection attacks with just an + ORM, a simpler ORM, or even the raw Ruby MySQL and Postgres gems, which + support question-mark arguments. + + Rails security really shines when you’re navigating the bewildering + world of HTML and browser security. Small projects that mostly speak a + structured format read by machines will get less from Rails. Securing + something like an integer ID or a hash of strings is just easier than + ensuring your HTML contains no script tags or anything exploitable. + + Related to that is when you’re doing in-browser rendering and Rails is + ‘just’ serving JSON. It’s a weird kind of in-between case. A lot of + Rails security and convenience functions no longer help you, but you’re + still doing things where internal libraries (ActiveRecord, ActiveJob, + ActionMailer) can be highly useful. But if you’re never rendering HTML + on the server and you’re very sure you never will, Rails will probably + help you less. + +When Is Rails Not Enough? + + Rails is also designed for a small team and a medium-sized codebase. A + huge team (lots of programmers) or a huge codebase (lots of + controllers, models and/or lines of code) will tend to drag down the + standard Rails-app structure. + + Ruby allows for a lot of [11]non-local effects. Whether that’s + monkeypatching, writing to a database or creating new types at runtime, + Ruby isn’t designed for a team of 200 programmers where you don’t trust + some of them. There are too many ways for them to cause you trouble. + You can use [12]good tooling to scale Ruby to larger teams, but even + that will [13]tend to have exceptions and difficulties. That’s not + really Ruby’s sweet spot. + + In most cases you can cut up a large project into smaller projects. If + one Rails app is too big, you can often separate it into multiple apps, + or a thinner app with more back-end services, or an app and a separate + microservice, or… One way or another there is usually a way to separate + out smaller pieces. Ruby strongly encourages that, as do I. + + There are also not-quite-Rails structures that can scale better. Avdi + Grimm’s (now retired) [14]Objects on Rails was an attempt in that + direction, as is [15]the Hexagonal architecture for Rails, which in + turn has a lot in common with the older and more general [16]N-tier + architecture. + + But at some point you might want to consider a different framework. + [17]Hanami is an obvious choice, designed to be less quick and nimble + than Rails for getting a tiny app off the ground, but more scalable if + you want to use the same code with a lot more contributors. + + I’d still start out in Rails, personally. If you’re building something + quickly to see if anybody cares, I know of no framework that comes + close to its productivity. Wait to rewrite (in a more rigid framework) + until you’re successful and you can afford the drag on your development + speed. + + The other worry here can be performance. If you’re rewriting a project + that is already as large as the current Basecamp… then you’re + [18]actually fine for performance. Rails still scales great for them. + But if you’re looking at something a hundred times larger (which by + definition means B2C, not B2B) then you might have a situation where + your server costs are substantially greater than your engineering + payroll. In that case it can make sense to slow down your engineers to + pay lower server costs. To check this, see what your EC2-or-equivalent + costs are just for your application servers, which are what run Rails. + And check your payroll just for web engineers, which is who writes in + Rails. Normally the engineering payroll is much larger and you should + stick with trading cheap machine time for expensive engineering time. + But at some point the balance may tip and you should consider raising + your engineering payroll to cut your server costs. + +When Does Rails Have the Wrong Assumptions? + + [19]A pirate, a bear and a chimp sit at a wicker table. The bear looks + into a very old-fashioned microscope as the other two look on. They’re + checking the microscope for real-world use cases where Rails might be + wrong. + + Before checking if Rails’ assumptions are right for you, we should see + what those assumptions actually are. + + Before you take my word for it, I recommend taking [20]David Heinemeier + Hansson’s word for it in the form of The Rails Doctrine. It’s a great + document and it covers a lot of ground. + + Indeed, if you want to better understand why Rails isn’t amazing for + large, low-trust teams, you should read [21]“Provide Sharp Knives” in + the Rails Doctrine several times. A lot of Rails’ tradeoffs are + entirely by design. + + Rails also has some simpler assumptions: it assumes you’re writing an + interactive app with server-rendered HTML. It assumes that security is + vital (Rails trades a lot for security) but that you don’t want to + build your own custom security system in most cases. And it assumes + that you either have a small, excellent team doing prototyping work + (“Provide Sharp Knives”) or that you have a possibly-mediocre team that + needs powerful built-in guidelines ([22]“The Menu is Omakase.”) + + Rails also assumes you want high developer velocity at a cost of + technical debt. In other words, it’s designed for building very + quickly. That makes sense when technical execution is not your biggest + risk. For instance: if you’re building a small startup, and you’re + pretty sure you can build the site but people may not buy your product, + you are dominated by market risk. That’s when Rails is perfect. You + want to build very quickly. And even if you build perfectly, you’re + probably going to have to throw away the result for nontechnical + reasons, like “people don’t want to buy it.” + + As part of “high dev velocity, technical debt is okay” Rails assumes + things like, “you’ll want to use a lot of gems” and “dependencies that + work are fine if they speed you up.” + + Rails assumes you don’t mind scaling out application servers + horizontally (by bringing more of them online.) It’s designed to scale + well if you can do that. Rails assumes CPU is fairly cheap and it’s + usually right about that. Relatedly, Rails assumes that the database is + usually your most serious performance bottleneck, which is how web + applications usually work. + + Rails also assumes you’ll have some calculation or data transformation + in your application. It assumes that it’s okay to use some CPU because + you’ll be doing that anyway. + + (When does that last assumption matter? Let’s talk about Evented + Servers and see.) + +What Isn’t Rails Good At? + + [23]The Node.js logo. Sometimes you need it, or something like it. + + While Rails is great at a lot of things, there’s one particular task + that it’s not amazing for: shim servers. + + By “shim servers” I mean servers that do very little calculation but + integrate answers from a few other back-end services and relay the + result. Imagine a server that queries two JSON services and combines + the result with simple string-manipulation, for instance. It does very + little calculation, but it juggles a lot of events. + + And that’s the relevant word: “events.” + + There is a specific kind of app architecture embodied by Node.js and + its relatives called “Evented” programming. It can support many + thousands, or even millions, of simultaneous connections with a tiny + amount of server resources. It can be both high-throughput and + low-latency. Its benchmark numbers are matchless… for the cases where + it works. + + Rails can’t match Evented programming at what Evented programming is + good at. Basically no framework can. There are Evented frameworks for + Ruby (e.g. [24]EventMachine, [25]Async.) Rails is built differently. + + If Evented is so much better, why don’t we use it for everything? + Because it doesn’t work for everything. I emphasise calculation + per-request because an Evented server will fall down and die if you try + to make it do very much calculation per-request. Having one server + handle a million connections is no good if each connection winds up + using a hundred milliseconds of CPU time — that’s simply too many + connections and the latency will be terrible. + + In other words, Rails and Node.js are different tools for different + projects. If you’re thinking, “I should either use Rails or Node for + this” I would recommend looking deeper into your project (and/or your + framework) until it’s obvious which one is the right answer. They do + different things. + +Look, I Just Scroll to the Bottom for the Summary and Criticise It On Reddit + + [26]A chimpanzee in a lab coat stares down at his lap, containing + sections of wooden train track, and his hand holding a toy train. I’m + sure this is the right answer, but I have forgotten the question. + + Rails is the wrong choice if your team doesn’t want to use it or + doesn’t know how. + + Rails is the wrong choice in cases where a different framework is + specifically better, or you have a specific library you need to be + compatible with that isn’t Rails-friendly. + + Rails might be the wrong choice if you’re not rendering HTML on the + server, especially if your project is very small and/or doesn’t use a + database. + + Rails is the wrong choice is you’re not doing prototyping-flavoured + work, preferably with a small, highly-competent team. + + Rails is the wrong choice if your dev team or your app code is too big + and you can’t subdivide the project. + + Rails is the wrong choice if your project wants an Evented server like + Node.js or EventMachine. + + This article is the wrong choice if you’d rather [27]listen to an + entertaining podcast on the same topic. + + If you’re wondering when Rails is the right choice, [28]the Rails + Doctrine is a great first step. + Aug 6 2020 + [29]ruby [30]rails + +You Hunger to Get Better + + Subscribe to get free ebook chapters and an emailed coding class now, + plus videos and articles a few times a month. + + Why this specific newsletter? You want to be an expert. Expertise comes + from learning the fundamentals, deeply. And that comes from the best + kind of practice. I write with that in mind. I won't waste your time. + + (Yes, I also sell things. They're good, but I'm fine if you don't buy + them.) + ____________________ ____________________ (BUTTON) Sign-up + +Comments + + Please enable JavaScript to view the [31]comments powered by Disqus. + [32]comments powered by Disqus + +Read Next + +[33]Computer Science: Just the Useful Bits + + [34]ruby [35]rails + [36]Computer Science: Just the Useful Bits + +[37]Let's Build Course Software: Email Reminders + + [38]ruby [39]rails [40]letsbuild [41]rubymadscience + [42]Let's Build Course Software: Email Reminders + +[43]Free Rebuilding Rails Video Chapters + + [44]career + +[45]The Urban Legend of the 10X Developer + + [46]career + [47]The Urban Legend of the 10X Developer + + [48]Mastodon [49]GitHub [50]Linkedin [51]Mastodon + + [52]Codefol.io © 2020 . Horace theme by [53]JustGoodThemes.. + + [54]Back to top + +References + + 1. https://codefol.io/ + 2. https://codefol.io/ + 3. file:///posts + 4. file:///topics + 5. file:///tags/favourite + 6. file:///feed.xml + 7. file:///about + 8. https://www.codewithjason.com/rails-with-jason-podcast/noah-gibbs-3/ + 9. https://www.codewithjason.com/rails-with-jason-podcast/noah-gibbs-3/ + 10. https://rubymadscience.com/img/assistant_pirate_with_sphere_bigthumb.png + 11. https://en.wikipedia.org/wiki/Side_effect_(computer_science) + 12. https://sorbet.org/ + 13. https://sorbet.org/docs/troubleshooting#escape-hatches + 14. https://www.goodreads.com/book/show/13481927-objects-on-rails + 15. https://medium.com/@vsavkin/hexagonal-architecture-for-rails-developers-8b1fee64a613 + 16. https://en.wikipedia.org/wiki/Multitier_architecture + 17. https://hanamirb.org/ + 18. https://m.signalvnoise.com/only-15-of-the-basecamp-operations-budget-is-spent-on-ruby/ + 19. https://rubymadscience.com/img/dr_bear_microscope_bigthumb.png + 20. https://rubyonrails.org/doctrine/ + 21. https://rubyonrails.org/doctrine/#provide-sharp-knives + 22. https://rubyonrails.org/doctrine/#omakase + 23. file:///posts/when-should-you-not-use-rails/node_js_logo.png + 24. https://github.com/eventmachine/eventmachine + 25. https://github.com/socketry/async + 26. http://rubymadscience.com/img/rails_internals_bigthumb.png + 27. https://www.codewithjason.com/rails-with-jason-podcast/noah-gibbs-3/ + 28. https://rubyonrails.org/doctrine/ + 29. file:///tags/ruby/ + 30. file:///tags/rails/ + 31. http://disqus.com/?ref_noscript + 32. http://disqus.com/ + 33. file:///posts/introducing-computer-science-just-the-useful-bits/ + 34. file:///tags/ruby/ + 35. file:///tags/rails/ + 36. file:///posts/introducing-computer-science-just-the-useful-bits/ + 37. file:///posts/series-build-coding-course-email-reminders/ + 38. file:///tags/ruby/ + 39. file:///tags/rails/ + 40. file:///tags/letsbuild/ + 41. file:///tags/rubymadscience/ + 42. file:///posts/series-build-coding-course-email-reminders/ + 43. file:///posts/free-rr-video-chapters/ + 44. file:///tags/career/ + 45. file:///posts/urban-legend-of-the-10x-developer/ + 46. file:///tags/career/ + 47. file:///posts/urban-legend-of-the-10x-developer/ + 48. https://ruby.social/@codefolio + 49. https://github.com/noahgibbs + 50. https://www.linkedin.com/in/noahgibbs + 51. https://ruby.social/@codefolio + 52. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L9874-9978TMP.html + 53. https://justgoodthemes.com/ + 54. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L9874-9978TMP.html#page diff --git a/themes/v2/layouts/elsewhere/single.html b/themes/v2/layouts/elsewhere/single.html index 559c4f9..b95b812 100644 --- a/themes/v2/layouts/elsewhere/single.html +++ b/themes/v2/layouts/elsewhere/single.html @@ -20,5 +20,6 @@ {{ .Content }} + {{- partial "references.html" . -}} {{- partial "backlinks.html" . -}} {{ end }}