FAQ

A: Every Restify 4.x app should use bluebird instead of native Promises.

Q: How do I do that?

A: At the beginning of your app (where you load dotenv) you should add the following:

global.Promise = require("bluebird");

Q: Awesome! 🎉 Now I can just use all the neat-o bluebird promise methods!

A: That is not a question. Also, please don't. Please treat every Promise in your app like a native Promise and don't invoke bluebird methods without explicity using bluebird. If you fail to do that, it will be nearly impossible to undo this hack revert this temporary (albeit clever) solution. So, to be clear:

If you're feeling confused about GitHub's new review requests feature (as opposed to the existing ability to assign people to issues and pull requests) here's my take.

When review requests were first rolled out, they were not very useful because there was no way to see a list of pull requests you had been requested to review. Thankfully, that deficiency has been fixed!

Now, review requests unleash a great way to manage workflow on pull requests.

When you create a pull request, you add a review request for one or more reviewers. In addition, assign the pull request to the reviewer to signal that you are awaiting their action.

When the reviewer finishes their review, they should either merge the pull request (LGTM!) or assign it back to you (or someone else) for action -- respond to a comment, answer a question, revise code, etc.

Then when you respond to feedback, you assign the pull request back to the reviewer, and the cycle repeats.

There is additional explicit signaling in the review request workflow that you can use, too.

And that's fine until you start getting ultra-fancy. Ultra-fancy, as in, the load-balancer is configured to support PROXY protocol. I'm not going to get into the reasons why we ended up being so ultra-fancy that we wanted to enable PROXY protocol on our load-balancer. Truth is, we don't need it. But the upshot of why this causes problems is that the headers added to each request are different. And not just different. There is literally nothing in the proxy headers that indicates that the client request was made via https vs. http.

So... luckily our app is hosted on Amazon AWS in a VPC that is not reachable from the internet. In other words, there's no way a request could reach our nginx process other than via an https request that hits our load-balancer. Which means, we can just -- gulp -- hard-code it.

The relevant configuration in the nginx config:

server {
# ...
# This is empty because of PROXY protocol
if ($http_x_forwarded_proto = '') {
# So we hard-code the protocol as https, i.e., "secure"
set $http_x_forwarded_proto https;
}
location @node {
# ...
# This is the header Koa will rely upon
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
}
}

By the way -- and I hope this isn't burying the lede too much here -- but if your app only relies on reading those secure cookies, you don't need to worry about this michegas. A user's browser doesn't know or care about what's behind your SSL-terminating load-balancer using PROXY protocol to talk to nginx proxying to your node app. All a user's browser knows about is the https request that hits the load-balancer. Only if you need to set a secure cookie do you possibly need to know about this.

Background

So... we're using Amazon Web Services Elastic Beanstalk for one of the apps I'm working on. It's pretty easy to get started, but it's also really easy to find that you’re fighting Elastic Beanstalk to get it to stop doing something stupid.

I was fighting one of those "stupid" things the other day: http-to-https redirect.

Let's say you have a web application that requires users to login with a name and a password. You don't want users' passwords getting sent over the internet without being encrypted, of course. So you enable SSL and serve content over https.

But sometimes, users type your domain name (like, “google.com”) into the address bar, which defaults to http. Or they follow a link to your app that mistakenly uses http instead of https. In any event, you don’t want users who are trying to get to your app to get an error message telling them there’s nothing listening on the other end of the line, so you need to be listening for http requests but redirecting them to https for security.

Now, our app is written in Node.js, and we’ve configured Elastic Beanstalk to point internet traffic to an Elastic Load Balancer, which terminates SSL and proxies traffic to the backing servers, which are running our app behind nginx. This might sound like too many levels of indirection, but nginx is optimized for serving static content, while Node.js is optimized for dynamic content, so this is a pretty common setup.

And this is where Elastic Beanstalk gets stupid.

When we configured our app to listen for both http and https traffic, Elastic Beanstalk directed all of that traffic to nginx — and configured nginx to direct all of that traffic to our app — without giving us any way to redirect http traffic to https.

I imagine lots of apps want to respond to both http and https traffic while redirecting insecure http requests to secure https requests. Maybe I’m wrong.

Anyway, I want to do that. And I found it insanely difficult to accomplish.

We have a number of private npm packages, and I needed to create a new user, grant that user read-only access to our private packages. The npm docs are great. Really great. Go there for details. But here are the key commands for this (probably common) series of steps.

Remove user from a team

I received a "high memory usage" alert. Already panicking, I logged into New Relic and saw this terrifying graph:

That's a graph of memory usage, starting from when the server was created. For the uninitiated, when memory usage grows and grows and grows like that, chances are very, very high that you've got a nasty memory leak on your hands. Eventually, your server is going to run out of memory, and the system will start killing processes to recover some memory and keep running -- or just crash and burn.

The funny thing about this particular server is that I had already identified that this server was leaking resources, and I thought I'd fixed it.

So, I started to investigate.

Running free -m confirmed that nearly all the memory was in use. But top (sorted by MEM%) indicated that none of the server processes were using much memory. Huh?

After some time on Google and Server Fault, I ran slabtop and saw that nearly all server memory was being cached by the kernel for something called dentry. This server has 16GB of RAM -- I'm no expert, but I'm pretty sure it does not need 14GB of cached directory entries. I know I can free this RAM, and with some more help from Google I find the magic incantation is:

echo 2 > /proc/sys/vm/drop_caches

After 5 terrifying seconds during which the server seemed completely locked up, the memory had been freed! But apparently, something about the way this server was acting was causing the kernel to keep all these directory entries cached. In other words, this was probably going to keep happening. I didn't want to have to create a cron job to manually clear the cache every 4 hours, but I wasn't above it.

More reading told me that maybe I was worried about nothing. Looking closely at the peaks of that graph, I saw that the kernel was freeing up memory.

So maybe I was worried about nothing! Still, I didn't want New Relic alarms going off all the time. And what if the server needs memory more quickly than the kernel can free it? It seemed like something I shouldn't have to worry about.

By default, Homebrew gets installed under /usr/local. This is great, because it doesn't require you to use sudo to install and upgrade packages. But the downside is that it turns your /usr/local directory into a git repository. If you don't have any conflict with this, then by all means, stick with the default.

I had a conflict. Specifically, I use nave for node version management. Unfortunately, both Homebrew and nave drop a README.md in /usr/local, which means nave frequently modifies a file that's under Homebrew's version control and brew update breaks.

Solution

I decided to "move" my Homebrew directory to ~/Homebrew. Here are the steps I followed:

I didn't document this as I did it. Hopefully, I didn't forget anything.

Performance management is often a source of great frustration for employees who do not clearly understand their goals or what is expected of them at work. They may feel conflicted about their duties and disconnected from the bigger picture. For these employees, annual reviews and developmental conversations feel forced and superficial, and it is impossible for them to think about next year’s goals when they are not even sure what tomorrow will throw at them. (emphasis mine)

This is something we've been struggling with at my job. We use quarterly OKRs to set goals for all employees, but many of our OKRs (for me and my direct reports) lose relevance after 2 or 3 weeks.

So, I'm still looking for ways to help me (and my team) measure our performance and set clear, relevant goals.

I want to reprogram the way I think about the state of my data models.

Think of a blog post. Before I publish it, it's unpublished. After I publish it, it's published. If I unpublish it, it's unpublished again. Maybe I edit it and republish it. Published again.

I (and a lot of programmers, I think) tend to think of a thing like a blog post as having a state. Maybe in the MySQL database, blog posts are in a posts table having a state or status column. It's an ENUM type, probably.

But state is really just whatever the most recent change represents. Like git -- state is like HEAD. And too often, I don't think about saving the history of states when I should.

So, resolved: consider whether any new data model having a state or status should instead (or also) have a history.