One of these things is window management. Working at a fully remote company means you might spend countless hours on video calls for meetings, interviews, or even social events. Sometimes you’ll have a Zoom/Skype/Slack/whatever window open and that is great. Other times you’ll have to juggle video, notes, documentation, etc.

Regarding remote interviews, I think I hit my sweet spot:

Video at the top

Throughout this Covid-induced period of constant video calls, I’ve found the trick of aligning the video thumbnails of people on the call with the camera, so it looks like you are looking at them when you look at their video. This shows more presence on your part, you don’t look constantly distracted (like people with two monitors where the camera is not on the main monitor they look at).

Notes, script and comms

The bottom half of the screen can be split as you want. In my case, we have an interview script that guides us through the sections we have to evaluate and allows us to provide less biased and more standard interviews (i.e. everyone gets pretty much the same questions). I also take notes about the interview as it goes along, ideally without looking at the keyboard (to keep a stronger feeling of engagement). We usually have two interviewers per interview, so I also find it useful to have Slack open so the other interviewer and I can quickly sync about the interview pace or last minute change of plans.

Credits

Thank you to Dmytro Shylin for the Figma monitor mockup.

Use at your own risk. 🤓 Before implementing any functionality that makes running copied code easier, be aware that the internet’s a bad place. There’s always a chance that a command has malicious intent or even includes hidden commands.

This made me think: maybe I can build upon his example and add a small layer of protection, to prevent accidental errors when working a bit absentmindedly — we all do that from time to time.

Ask for confirmation before

Follow his tutorial and, when you get to the part when you’re writing the script, instead of simply executing the commands it gets, ask the user for explicit confirmation before proceeding. Use this as the content of your $ executable:

#!/bin/zsh
read -p "Are you sure you? [y/N]: " -n 1 -r
echo # move to a new line
if [[ $REPLY =~ ^[Yy]$ ]]
then
    exec "$@"
fi

I used someone’s else suggestion in order to ask for confirmation, but this is a simple way of adding a small confirmation step. Anything that is not y or Y will skip the execution. This will hopefully help with the hidden commands issue Stefan made me aware of.

1. Write the scraping script
2. Add SMS notifications
3. Deploy and run it automatically (this post)

Welcome back! Now that we have a script that checks a page and we added SMS notifications, let’s make sure we get this up and running — executing our script regularly.

Create a Heroku account

This tutorial relies on Heroku for the simple fact that it allows us to be abstracted from most server-side hassle and we can focus on the project at hands. If you have the project we’ve been building tracked with Git, this will be smooth.

Make sure you have a Heroku account and install their CLI. Then log in through it so that you have access to your Heroku account using terminal commands.

Deploy your app

After making sure you’re on the project folder, run heroku create to make a new empty application on Heroku. This doesn’t deploy your code yet.

Before we send our code to Heroku, make sure you have the following lines on your package.json — it will help us to run our script with the last amount of work:

{
  "scripts": {
    "start": "node index.js"
  }
}

To send your code to be run by Heroku, execute the following: git push heroku main. This will take a while and will output a lot of text, keeping you up to date with the remote state of the dyno Heroku is setting up for you. At the end, you’re greeted with a message with a link, something like https://hidden-socks-12321.herokuapp.com/ deployed to Heroku. In our case, this is not important since we don’t have a page to look at — we’ll get an SMS notifications whenever we find what we want.

Schedule regular jobs

Our script is on Heroku, so we’re just missing one last step: making sure it runs regularly. Head out to your dashboard where you’ll see all your current applications. Find the one we just created and select it.

On you app’s page, go to “Resources” then click “Find more add-ons”. You’ll be greeted with a long page full of possible addons, but we’re looking for one on the Dynos section. Find Heroku Scheduler and click on it. You’ll see a button near the top right corner of your screen that says “Install Heroku Scheduler”, press it and, on the next screen, type the name of your app and click “Submit Order Form” — don’t worry, this addon is free.

The addon is now enabled and we can see the options we have available. You should be back on your app’s page, on the Resources tab, where you should see your newly installed addons. Click on it to access its configuration page.

On this new page, click “Create job” to show a right-side panel where you can pick if you want to run your script every:

• 10 minutes
• Every hour at 00, 10, 20, 30, 40 or 50 minutes in the hour
• Every day at a certain time (in 30 minutes increments)

Pick the frequence you want, pass the command we have to run the script (npm start) and click “Save Job” at the bottom.

One last step, a missing buildpack

Heroku has this concept of buildpacks that they define as “(…) scripts that are run when your app is deployed. They are used to install dependencies for your app and configure your environment.”

For this particular project, there is one we must add to have access to Puppeteer, created by Jon Tewksbury. It will help Heroku installing all the necessary dependencies (like Chrome) so that our script runs without problems.

On your app’s dashboard page, go to the Settings tab and scroll down to the section Buildpacks. Click “Add buildpack” and paste https://github.com/jontewks/puppeteer-heroku-buildpack in the text input of the modal you get. Click “Save changes” and you’re ready to go.

Buildpacks are used the next time our apps are deployed, so just to be sure everything is in place, let’s trigger a redeploy of our app by pushing an empty commit:

git commit --allow-empty -m "Trigger deploy after buildpack" && git push heroku main

Conclusion

That’s it! You have now created, deployed and scheduled a web scraper that notifies you with an SMS whenever it finds what it is looking for! There are numerous other ways to do what we’ve accomplished, however, I’ve found this the most Pareto-like way of spinning something up whenever I have the need to automate checking up on a website. I’ve optimised for simplicity and speed of MVP on these blogs, not for flexibility or power.

As a last tip, if you are looking for logs to see what is happening with your app from time to time or you’re trying to debug something with it, on your app’s dashboard you should see a “More” button on the top right corner. Click on it to expand the options available and you’ll see a “View logs” item. That’s where you can take a closer look at the logs Heroku collects from your running applications.

1. Write the scraping script
2. Add SMS notifications (this post)
3. Deploy and run it automatically

Welcome back! Now that we have a basic script that checks for the data on a page, let’s add an SMS notification that will inform us of the current headline we find.

Create a Twilio account

We’re going to use Twilio for this, they have a free API that we can quickly reach out to and send a few SMS through it. Head out to https://twilio.com/try-twilio and create your account (if you already have one, read along).

After creating your account and logging in, we want to create a new project (sometimes also called account on their platform). These are containers for your applications (nothing to do with Docker, though).

Look for the Create New Account button or go straight to twilio.com/console/projects/create. Pick a name for your account and click Verify:

The next screen asks you to verify yourself. Yeah, it’s a bit annoying, but this also helps them to prevent some less benevolent agents from using their platform, so it’s cool.

Write your phone number down, go to the next page, type the verification code you got on your phone, submit and you’re almost there! The next screen asks us for some goals, in order to send us to the right place and the right features we intend to use. I’ve picked the following for this example:

After this, we are finally greeted with our account dashboard and… there is a lot of stuff. 😅 Luckily, we’re only here for one thing: a phone number to send SMS from. If you scroll down a bit, you should see a Get a Twilio trial phone number header. Click the button below it, Get a trial phone number. You should get a modal with a suggested phone number.

There is nothing special with the phone number we’re looking for, so grab the first one you get by clicking on Choose this Number. Press Done on the next modal and we have now a number! We’re very close to being able to send messages…

Small gotcha

In order to prevent free accounts from being used to spam people, you’ll only be able tos end SMS to verified numbers. You can check the only one you got so far (the one you used to sign up) at twilio.com/console/phone-numbers/verified. If there are other numbers you want to message through your script, you should add them here now.

Integrate Twilio in our script

We’re ready to use Twilio and send some SMS. To do that, we’ll need their npm package, so install it by running npm install twilio (if you have npm 5 of above, this should save the package on your package.json).

Start now by creating a separate file where we’ll put out notification code, notify.js. This will be our base code to send notifications:

const twilio = require('twilio');

module.exports = {
  sendSMS(msg, toNumber) {
    const fromNumber = process.env.TWILLIO_PHONE_NUMBER;
    const accountSid = process.env.TWILLIO_ACCOUNT_SID;
    const authToken  = process.env.TWILLIO_AUTH_TOKEN;

    const client = twilio(accountSid, authToken);

    return client.messages
      .create({
         body: msg,
         from: fromNumber,
         to: toNumber,
       })
      .then(message => console.log(message.sid))
      .done();
  }
}

The code above is almost straight from their documentation (which is excellent, by the way!) and I’m always amazed about how little code you need to send SMS!

You can also notice how we have three lines accessing process.env.*. You do this in Node to access environment variables, i.e., values that you can set on the fly when you run the command. Think of it as function arguments, but for Node scripts.

With our notification module ready, go back to your index.js and we’ll import it to give it a spin:

 const puppeteer = require('puppeteer');
+const { sendSMS } = require('./notify');
+
+const toNumber = process.env.MY_PHONE_NUMBER;

 (async () => {
   const browser = await puppeteer.launch({
@@ -19,7 +22,7 @@ const puppeteer = require('puppeteer');
   const header = await getText(firstArticle, 'h2');
   const summary = await getText(firstArticle, 'p:first-of-type');

-  console.log(`${header}\n${summary}`);
+  sendSMS(`${header}\n${summary}`, toNumber);

   await browser.close();
 })();

The text we were passing to console.log we’ll not send to our phones with the new sendSMS method we created. Don’t forget to also get the number you are sending this message to (should be the same you used to register to Twilio) through an environment variable as well.

Run the code

We have everything in place now, there are just a few consideration to have before heading to a terminal and running all of this.

The process.env.* variables we set in our code must be provided by us in some way — I say this becuase we can do it in several ways, but we’ll follow the simplest. When running our index.js script, we’ll pass these environment variables inline. Here’s an example (make sure you use your own credentials that you get from the console page):

TWILLIO_PHONE_NUMBER="+19293949596" \
TWILLIO_ACCOUNT_SID=ACDCadbfe2ce33c691a6dcfdce6e3617bb \
TWILLIO_AUTH_TOKEN=face0a31ee17c4a2c9b3c0vfefeffa1f \
MY_PHONE_NUMBER="+447663342007" \
node index.js

The backslashes allow us to split a long command into multiple lines, for readability’s sake. Instead of harcoding this sensitive data into our code, we extracted it to configurable variables. This will permit us to easily set up an integration pipeline in the future that will run this script automatically, and also to make this project reusable by other people with their own Twilio credentials.

And that’s it for the time being! You now have a script that send you an SMS with dynamically fetched data.

See you around soon for the third part of this article…

1. Write the scraping script (this post)
2. Add SMS notifications
3. Deploy and run it automatically

I’ve had a few situations in the past where I was waiting for something to get updated on a website and just kept refreshing the page every so often… But when you don’t know when that update is going to happen, this can get tedious and hey, we’re programmers, we can build something to do this for us. 😃

“Puppeteer is a Node library which provides a high-level API to control Chrome” and it’s the one I usually use just because it makes building a simple web scraper super simple. Let’s dig in and build a Minimum Viable Product that, for the sake of this example, grabs the top news from The New York Times’ Today’s Paper.

Project start

Begin by creating a package.json that will hold the project’s dependencies. You can use npm init for this, but for simplicity’s sake, I’ll create a stripped-down version:

// package.json
{
  "name": "web-scraper-with-puppeteer",
  "version": "1.0.0",
  "private": true
}

Now we add our only dependency, Puppeteer. Run this on the terminal:

npm install puppeteer

Your package.json has changed a bit now, here’s the difference:

 {
   "name": "web-scraper-with-puppeteer",
   "version": "1.0.0",
-  "private": true
+  "private": true,
+  "dependencies": {
+    "puppeteer": "^9.1.1"
+  }
 }

Let’s start with our main script now. Open up a brand new index.js and write the following:

// index.js
const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    headless: false,
  });
  const page = await browser.newPage();

  await page.goto(
    'https://nytimes.com/section/todayspaper'
  );
  await browser.close();
})();

For now, this is a simple script that you can run right now with node index.js in order to see if everything is going well so far. You should see a Chrome window opening up (because we specified headless: false) and closing as soon as the page stops loading. So far so good! Let’s now grab from the DOM the first article on the page.

Add the next lines to your script to grab the first article and just output its HTML, so we can see if we’re retrieving the right thing:

   await page.goto(
     'https://nytimes.com/section/todayspaper'
   );
+
+  const firstArticle = await page.$eval(
+    'article:first-of-type',
+    e => e.outerHTML
+  );
+
+  console.log(firstArticle);
+
   await browser.close();
 })();

Run your script with node index.js and you should see a lot of HTML inside an <article> tag on your console. We’re almost there!

Now, we don’t want the full article, only its headline and summary. Looking closer at the HTML we get, we see an h2 and the first p that look promising. Let’s refactor our code a bit to have firstArticle as a variable we can use, create a function to be used for both the header and the summary, and pluck both of them to show on the console:

     'https://nytimes.com/section/todayspaper'
   );
 
-  const firstArticle = await page.$eval(
-    'article:first-of-type',
-    e => e.outerHTML
-  );
+  const firstArticle = await page.$('article:first-of-type');
+
+  const getText = (parent, selector) => {
+    return parent.$eval(selector, el => el.innerText);
+  };
+
+  const header = await getText(firstArticle, 'h2');
+  const summary = await getText(firstArticle, 'p:first-of-type');
 
-  console.log(firstArticle);
+  console.log(`${header}\n${summary}`);
 
   await browser.close();
 })();

Go ahead, run that on the terminal and you show see two lines, the top on as the header and the bottom one as the summary of the article!

To be honest, that’s it! 🎉 A web scraper doesn’t need to be fancy or complicated, it really depends on what you are trying to fetch from a page. I had one running for a few days a while back (which I’ll write about on a following article) and it was basically doing thigs on another page, just checking if a specific string of text has changed already or not.

Having said that, there is so much more you can do with Puppeteer — the sky is the limit. Check their documentation to see the available methods, official examples of wild things you can use it for, and you can even use it to automate performance work!

See you around soon for the second part of this article…

This gave me an idea for a project. A short newsletter (with an RSS feed as well, for people with email fatigue) that, every fortnight or so, would introduce you to someone that (in some way) propelled Computer Science forward, someone you should know a little about.

This eventually led me to Heroes of Computer Science and I’ve sent three issues so far: Ada Lovelace, Grace Hopper and Alonzo Church.

I have many more people to go through, but so far, I’m really enjoying discovering about new personalities and re-learning about names I already knew about but not that well.

If you have a suggestion for someone to be spotlighted on this project, let mw know through this simple form! I’d love to get more ideas for future issues. 🤩

Here’s a new part of my .gitconfig:

[alias]
    main = !git checkout main && git pull --no-tags
    sync = !git main && git switch -
    fuse = !git sync && git rebase main

This week I added these three alias to my .gitconfig but, if you notice, they are not “regular” alias. The ! at their beginning tells Git that these are not alias to Git commands, but rather bash commands.

This gives you a simple but powerful way to chain executions, so I created three related alias that I can call depending on my goal:

• If I finished working on a branch and I want to get back to main and start with the most recent codebase, I’ll run git main. Notice the --no-tags, this is motivated by working on a large monorepo and not needing all the tags of the packages we keep updating;
• If I’m working on a branch and I want to quickly get any changes made to our main branch but come back to the branch I’m in right now, I’ll call git sync. As a note, git switch - gets you back to the branch you were before you moved to the current branch you are now;
• Finally, if I want to bring the current branch I’m at up to speed with the latest code we’ve shipped, I’ll use git fuse. It will do everything I described on the other commands so far and rebase our main branch onto the current branch I’m at.

What’s the difference between this.something = 'else' and this.set('something', 'else') in tests?

The answer is surprisingly simple (at the surface, we don’t need to get deep into Ember’s reactivity): this.set is the way you have to trigger re-render in test. For example, if you set a value with this.value = 'test' and render a component that will use that this.value, changing the value of this.value now will not re-render the partial. If, instead, you set that value with this.set('value', 'test'), whenever you change it again with this.set('value', 'something else'), the template will automatically re-render.

Small caveat (like everything in like): re-rendering will only occur if the value you are reassigning is different that the value previously there, as it seems.

As a break from my daily work with JavaScript and to keep my skills sharp, I’ve picked Ruby for it. Its performance shouldn’t be a problem for this kind of brain teasers and its syntactic sugar is always welcomed.

While trying to solve the second part of day 14, I found myself hogging my computer over and over again, trying to validate my algorithm. I was forced to fire up Activity Monitor and kill one of my ruby processes over and over again, which would be consuming several gigabytes of RAM! What was happening??

Even after finding a possible solution I was happy with, this kept happening — which meant I couldn’t get the answer to the puzzle. After stopping, reflecting a bit, and probing a few parts of the code, I had an idea — and it worked!

The challenge is about reading an input file and, with the values you get, write certain numbers in memory so you can sum them all up in the end. In my case, I was using an array to emulate the program’s memory and its indexes as the memory addresses.

This worked out well for a while… until I tried to write a value to the index 14694662143! 💥 This was the culprit and, while I can’t find the maximum number of an array’s index in Ruby, I found a few places that seem to point out that I was way above the realm of possibility.

The fix was actually quite simple:

• instead of using an array ([]) to keep the addresses and arr.compact.reduce(:+) to sum all the numbers hold,
• I just changed it to a hash ({}) which still allows me to keep the values and use arr.values.reduce(:+) to sum them.

I guess Ruby tries to allocate an array as big as your index whenever you do something like this. If the index is quite big, Ruby will obey you but create some headaches. A hash won’t, you’ll only allocate what you assign, nothing in between.

To go around this, I finally started playing around with Dokku on DigitalOcean. There is even an app available straight from their platform, so the support seems to be solid. The premise is simple: create a $5 droplet on DigitalOcean with Dokku installed on it (which you can do straight from here) and you’ll be able to use it as your personal Heroku.

The deployment process is quite similar. Here’s a sample output of what I get when I push a Ruby on Rails app to my own Dokku droplet (a few details removed/changed for privacy reasons):

$ git push dokku master

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 309 bytes | 309.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
-----> Cleaning up...
-----> Building dokku-test-app from herokuish...
-----> Adding BUILD_ENV to build environment...
-----> Warning: Multiple default buildpacks reported the ability to handle this app. The first buildpack in the list below will be used.
       Detected buildpacks: multi ruby nodejs
-----> Multipack app detected
=====> Downloading Buildpack: https://github.com/heroku/heroku-buildpack-ruby.git
=====> Detected Framework: Ruby
-----> Installing bundler 2.1.4
-----> Removing BUNDLED WITH version in the Gemfile.lock
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.5.8
-----> Installing dependencies using bundler 2.1.4
       Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 bundle install -j4
       Using rake 12.3.2
       …
       Using webpacker 3.6.0
       Bundle complete! 29 Gemfile dependencies, 74 gems now installed.
       Gems in the groups development and test were not installed.
       Bundled gems are installed into `./vendor/bundle`
       Bundle completed (0.79s)
       Cleaning up the bundler cache.
-----> Installing node-v12.16.2-linux-x64
-----> Installing yarn-v1.22.4
-----> Detecting rake tasks
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       yarn install v1.22.4
       [1/4] Resolving packages...
       [2/4] Fetching packages...
       [3/4] Linking dependencies...
       [4/4] Building fresh packages...
       Done in 87.94s.
       Webpacker is installed 🎉 🍰
       Using /tmp/build/config/webpacker.yml file for setting up webpack paths
       Compiling…
       Compiled all packs in /tmp/build/public/packs
       Asset precompilation completed (308.00s)
       Cleaning assets
       Running: rake assets:clean
-----> Detecting rails configuration

=====> Downloading Buildpack: https://github.com/heroku/heroku-buildpack-nodejs
=====> Detected Framework: Node.js

-----> Creating runtime environment

       NPM_CONFIG_LOGLEVEL=error
       USE_YARN_CACHE=true
       NODE_ENV=production
       NODE_MODULES_CACHE=true
       NODE_VERBOSE=false

-----> Installing binaries
       engines.node (package.json):  unspecified
       engines.npm (package.json):   unspecified (use default)
       engines.yarn (package.json):  unspecified (use default)

       Resolving node version 12.x...
       Downloading and installing node 12.19.0...
       Using default npm version: 6.14.8
       Resolving yarn version 1.22.x...
       Downloading and installing yarn (1.22.10)
       Installed yarn 1.22.10
       !     node_modules checked into source control
       https://devcenter.heroku.com/articles/node-best-practices#only-git-the-important-bits


-----> Restoring cache
       - yarn cache

-----> Installing dependencies
       Installing node modules (yarn.lock)
       yarn install v1.22.10
       [1/4] Resolving packages...
       [2/4] Fetching packages...
       [3/4] Linking dependencies...
       [4/4] Building fresh packages...
       Done in 45.75s.

-----> Build

-----> Pruning devDependencies
       yarn install v1.22.10
       [1/4] Resolving packages...
       [2/4] Fetching packages...
       [3/4] Linking dependencies...
       [4/4] Building fresh packages...
       Done in 16.75s.

-----> Caching build
       - yarn cache

-----> Build succeeded!
       !     Unmet dependencies don't fail yarn install but may cause runtime issues
       https://github.com/npm/npm/issues/7494

       Using release configuration from last framework (Node.js).
-----> Discovering process types
       Procfile declares types -> release, web
-----> Releasing dokku-test-app...
-----> Deploying dokku-test-app...
 !     Release command declared: 'rake db:migrate 2>/dev/null || rake db:setup'
       D, [2020-10-24T18:04:32.244136 #13] DEBUG -- :    (2.0ms)  SELECT pg_try_advisory_lock(7827836239135902150)
       D, [2020-10-24T18:04:32.272390 #13] DEBUG -- :    (2.9ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
       D, [2020-10-24T18:04:32.281930 #13] DEBUG -- :   ActiveRecord::InternalMetadata Load (0.8ms)  SELECT  "ar_internal_metadata".* FROM "ar_internal_metadata" WHERE "ar_internal_metadata"."key" = $1 LIMIT $2  [["key", "environment"], ["LIMIT", 1]]
       D, [2020-10-24T18:04:32.290196 #13] DEBUG -- :    (0.3ms)  BEGIN
       D, [2020-10-24T18:04:32.291934 #13] DEBUG -- :    (0.3ms)  COMMIT
       D, [2020-10-24T18:04:32.292759 #13] DEBUG -- :    (0.4ms)  SELECT pg_advisory_unlock(7827836239135902150)
-----> App Procfile file found
       DOKKU_SCALE declares scale -> release=0 web=1
=====> Processing deployment checks
       No CHECKS file found. Simple container checks will be performed.
       For more efficient zero downtime deployments, create a CHECKS file. See http://dokku.viewdocs.io/dokku/deployment/zero-downtime-deploys/ for examples
-----> Attempting pre-flight checks (web.1)
       Waiting for 10 seconds ...
       Default container check successful!
-----> Running post-deploy
-----> Configuring dokku-test-app.Dokku...(using built-in template)
-----> Creating http nginx.conf
       Reloading nginx
-----> Renaming containers
       Found previous container(s) (11c86d03fec9) named dokku-test-app.web.1
       Renaming container (11c86d03fec9) dokku-test-app.web.1 to dokku-test-app.web.1.1603562703
       Renaming container (154edf6916aa) inspiring_mayer to dokku-test-app.web.1
-----> Shutting down old containers in 60 seconds
       11c86d03fec92a9f08e4d3c1dfa33ffad428d621ed951195684ab5255a529f19
=====> Application deployed:
       http://dokku-test-app.Dokku

To 151.242.42.151:dokku-test-app
   92bf7df..a5b5166  master -> master

P.S.: If you are interested in trying out DigitalOcean, you can use this referral link and get $100 straight into your account to spin up some droplets and try it yourself.

Troubleshooting

Since everyone runs into a few hiccups when we’re trying something new, I’m going to keep this section as a living document of issues I’ve ran into while playing around with Dokku. Whenever I find a new issue that I’ve solved, I’ll come back to this blog post and update it.

virtual memory exhausted: Cannot allocate memory

This one took me a while to find a solution for, but I believe that was just because I was not using the right terms. The documentation even has a solution for it, it just took me a while to notice it. While installing the sassc gem, my droplet was running out of memory. This seems to happen because DigitalOcean’s basic droplets only have 512MB available, which might not be enough in a few situations. The documentation provides some instructions to follow that solved my issue, by creating a bigger swap file (acting like extra RAM):

cd /var
touch swap.img
chmod 600 swap.img

dd if=/dev/zero of=/var/swap.img bs=1024k count=1000
mkswap /var/swap.img
swapon /var/swap.img
free

echo "/var/swap.img    none    swap    sw    0    0" >> /etc/fstab

Further reading

• The Ultimate Digitalocean Dokku Deploy Guide (Rails & other environemnts)
• The Ultimate Guide to Dokku and Ruby On Rails 5