Last time we talked about why I’m building course software in Rails from scratch, and built out a basic skeleton of database tables and a first trivial view.
Today, let’s add a theme, build out the view a little more and generally make it look better. I think “Let’s Build” series look better with...
Lots of you loved my old post on this. Thanks! But thanks to many fine questions,
especially by one guy on Twitter, it’s time for an update! And also, naturally,
the same things you loved last time. I’m not heartless.
Sometimes you’re sure that’s not the right place for that piece of code, but where...
Are you deploying a Rails app? Here are lots of things you’ll probably have to
watch for as you do… I’ve been writing an open-source
gem and a (edited to add: now defunct) for-pay online
class about this for months now. Let me share some things.
There are lots of big reasons that deploying a Rails app is hard. And lots of
well-known, big tasks. But when you’re provisioning a server and deploying
your application to it, lots of little things go wrong too.
I feel like the big things get a lot of respect already. Let’s look into some
of the under-appreciated little things you have to get right in order to make
a good deploy happen.
For starters, a lot of these small issues can require a lot of debugging. You
know those two-line fixes that take three hours to find? Deployment is full of
those. Here are some of mine to speed you on your way.
All Things Great and Small
You can’t compile recent Ruby on a VM with less than approximately 1GB of RAM. The amount varies a bit, of course.
If you’re new to Ruby on Rails, you may be new to the old debates (pro and con) about how “Rails doesn’t scale.” You might wonder why people say that, or where it came from.
Let’s talk about that.
As far as “Rails Doesn’t Scale”, the main arguments go something like:
1) Ruby is slow, often up to 50x slower than C, so the server will eventually collapse.
This isn’t actually a scaling argument. But it’s true that Ruby is slow. Not 50x any more, closer to 5x (up to maybe 20x), but still, that’s not terribly speedy.
Rails doesn’t help Ruby here. A lot of the metaprogramming techniques it uses are among the slowest things Ruby does. I wrote a book about how Rails uses those techniques called Rebuilding Rails. They’re awesome, but they’re not speedy.
In practice, Ruby and Rails apps often “farm out” the slow stuff. The database is the traditional place to put the heavy lifting, but you’ll see Redis and Cassandra used in similar ways. Want Ruby to be fast? Call to something that isn’t Ruby, and is designed for speed :-)
Pure Ruby is quite slow, but just as scalable as any other language or library. It doesn’t get somehow slower as you add more.
2) Ruby/Rails leaks resources, so large or long-running projects don’t work
There was once more truth to this. Ruby had a few leaks and Rails exercised Ruby like nothing else. Also, ActiveRecord encourages large amounts of garbage per request, which was easy to mistake for leaks.
You’ve made it mostway through your free Ruby on Rails Internals class. Today we’ll be poking around the Rails source code. If you have money but not time, Rebuilding Rails lets you find a lot quickly… But in case you have more time, we’ll see where in the Rails source you can learn the same things...
A reader recently asked me why Ruby web app deploys usually have a web server (NGinX, Apache) and an application server (Unicorn, Thin, Puma, Racer, Mongrel, Passenger, Jakarta, TorqueBox or whatever I’ve forgotten this week).
Actually, he asked, “why do I need to run NGinX and Unicorn?” It’s a fair...
Ruby on Rails is divided into several separate pieces. If you know what they are and what they do, you can use them individually. You can also look up documentation more easily, and you’ll know where to look for source code to a particular method, and which of several similarly-named methods does...
A fellow asked me how he could store information per-user in Rack. This was my (brief) response:
Generally with the cookies object. Specifically, Rack has a “session”, which encodes a session identity into the cookies object, usually with some or all of your data.
Rails is a heavyweight framework and it does a lot of awesome stuff by default that only a few other frameworks provide. But most of the benefit goes right out the window when you’re using it to write a simple REST API. Lemme ‘splain.
Evan Light recently used the wonderful phrase ”Use Rails Until It Hurts”. He meant that Rails has built-in mechanisms for organizing your code and objects, and they usually result in simpler, cleaner code that mixing Rails with non-Rails.
I say your startup should use Rails until it hurts. And it...
I hate all the “requires” at the front of Ruby files. I know what methods I’m using, but I have to write it in both places. Not exactly DRY. Rails skips them — you just use the classes you want. How can I automatically load my files like Rails does? Read on.
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.)