Video version available on YouTube:
A certain kind of software developer—or more often, businessperson— likes to talk about a hundred-year programming language, or even a hundred-year framework.
That’s a pretty audacious thing to say. I mean, software development is roughly 65...
In a moment, all of you readers are going to hate Matt Bird. I get it. I hate him too.
He’s a professional screenwriter who also wrote a great book about how to write. You’d think that might excuse him a bit, but no, I’m not letting him off the hook. Some crimes are unforgiveable. You’ll see.
Here...
I’ve been fortunate to work in DevOps and with great Ops folks in my career, including doing enough of that work to get a feel for it. The tools are fun and it’s nice to be able to do basic tasks, but the incredible, invaluable thing was just watching how experienced OpsFolk responded to different events.
It’s not just the smooth, immediate way that they handle warnings and outages, though that is impressive. It’s also their basic understanding that new features, even features meant for robustness and resilience, are basically trouble. It’s not that an undisturbed system will necessarily keep working… But a system you disturb will invariably develop problems of some kind. Deployments tend to break things, and deploy-free weeks like holidays tend to be downtime-free.
But the important part isn’t the fact that they’re right. The important part is seeing a completely different attitude toward the software we write. Our way is valid for what we do, their way is valid for what they do, but it gives us completely different principles (that is, “unwritten rules that underlie everything we say and do”) about software.
Just like “everybody else has an accent,” it feels like everybody else has a mindset - our mindset is just “the right thing.” But seriously, what are the unwritten rules in software development?
And it’s not even just Ops or DevOps. There are a lot of mindsets in the world, and developers are just one of many.
If we’re the fish in the bowl, what does the water look like?
And what would the opposite look like? If software developers get our superpowers from this mindset, what superpowers do other folks get from very different mindsets?
It’s fun to write about different ways to practice coding. But “how to practice” only gets you so far - at some point you have to actually do the practice.
There are a lot of neat programming exercises in the world. This is an example of one I call a “coding study”, and I think it fits my definition of a good exercise.
A coding study is like an artist’s life study, but for code. You’d normally pick your own design. But this is meant as a simple introduction, so I’ll suggest a little more than usual.
The theme today: ivy on a window. I’ll refer to the picture below repeatedly in this post - have a look, then scroll back here as needed or save a copy locally.
One hard thing about exercises is that you need different habits for them than for production code: you’re not trying to write polished, production code. Instead, you’re trying to learn as fast as possible. So at the end, I’ll talk about some intentionally weird things I do in this code and why.
(You can see the five-minute video version of this post on YouTube.)
I’m an old-school programmer. I’ve been doing this for 30 years. I worked for over a decade in C and C++, often on operating systems and device drivers.
If you ask, “how do I get better at programming,” I’m supposed to tell you:
These are all terrible advice.
And they’re all variations on a different, wrong idea: that you should learn about computers and software past all the abstractions, “all the way to the bottom.”
That’s also terrible advice. Let me tell you why.
I often teach developers for my job, so I collect fears. Most teachers do. Your grade school teacher probably told you that you had to pay attention to boring math and/or history so that you could get a job (and not, by implication, live in a van by the river.)
So when I hear the same fear a lot, from a lot of different people, I pay attention.
I’ll bet that you don’t think you know “The Computer Science Thing” well enough. New folks like Boot Camp grads think so. So do recent college grads. And not-so-recent college grads. And veterans who “haven’t been keeping up.”
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...
If your startup does certain things, you wind up with the same business model as Yelp. It turns out you really, really don’t want the same business model as Yelp.
Let’s tell the story of the fictitious Emma Goldfarb founding a seed-stage startup called Review.ly (unrelated to the URL shortener.) Review.ly is going to be a site where people leave reviews of some kind of business. Emma isn’t quite sure about the details. She’s working on it.
Spoiler: she’s in an ugly situation because her startup wants to be like Yelp… And she really doesn’t want it to be.
Where does Emma’s money come from? Advertising doesn’t pay much, unless you have people who are about to buy something online in a trackable way. Emma doesn’t. Most of her reviewers have already bought their thing. Users looking for reviews are (in her case) not going to buy through her, so she doesn’t get paid that way. Some sites can avoid that, but Emma can’t.
Hey, Ruby web developers! Having trouble asking deployment questions?
Not sure what Provisioning or Orchestration are? Getting bad results
Googling your questions, but not sure why?
Let’s go over some deployment vocabulary from your point of view — that makes it a lot easier to Google and to read information about deploying your app to a server, and setting up that server in the first place.
As a nice side effect, you may have an easier time talking to your Ops guy at work.
First, let’s go over what the word “deployment” means:
‘Deployment’ is the process of putting a new application, or new version of an application, onto a prepared application server.
If you are talking to a developer, it may also mean the process of preparing the server, perhaps by installing libraries or daemons. If you are talking to an operations professional, it DOES NOT. They use the word “provisioning” for that.
(Developers are going to keep using the word “deploy” for everything involved in getting our app and its dependencies installed. That’s cool. But don’t be surprised if you confuse your Ops guy.)
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:
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.
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.
If you do Ruby web programming, you’ll often hear about “Rack.” You might hear about it from a Ruby dev you respect, and that you won’t get better at Ruby web stuff until you know what’s underneath.
Or you might have to write a config.ru to use Heroku and you’re thinking, “what’s config.ru?”. It...
Hello, new software engineers! Welcome to the (slightly) dysfunctional BigCo family.
Some of you are coming from Ruby, some Java. A few of you still think we should rewrite everything in Node.js. The whole company, down to the last one-off script.
Good.
We’ve been doing things our way for a...
