Forwarding mail to your Gmail account with Mailgun

also: How to set up Mailgun on Digital Ocean

I’ve been using Mailgun to send myself e-mails from my server with scraped data, logs, warnings and errors for a while now and it’s been working peachy. The free tier offers more than enough to satisfy most non-commercial users and it’s all a breeze to use – especially given the helper libraries the service provides in a host of different languages including NodeJS.

Digital Ocean logo

In my other article (linked above), I go into a bit more detail on how to set it up on your own $5/month Digital Ocean server, but that focused more on sending mail. Just the other day, I configured it to also receive mail. Or, rather, to forward it to a Gmail account I made just for this.

It turns out it’s really easy, but I did run into some annoying issues that caused me to lose quite some time over this. So let me walk you through troubleshooting said issues just in case the same happens to you.

Read More

Lint as you type with Neovim and Neomake

Related:


An exchange with commenter flndr8 on my first Neomake post inspired me to talk a little bit about ‘lint-as-you-type’ functionality in Neovim.

I’m not sure what the exact term for it is, but what I mean by lint-as-you-type is a kind of IDE-like feature that would run a linter on your code while you are editing the file. This in contrast with the ‘lint-when-you-save’ approach, which I covered briefly in my previous two articles on this subject.

Now, if this feature is high on your wishlist, I’ve got good news and bad news. The bad news is that, as far as I know, there is no optimal way (yet) to get this in vim. So if you consider this a killer feature, you may want to consider using a real IDE like WebStorm.

However, the good news is that you can get very close indeed. So if lint-when-you-save just doesn’t cut it for you, and you are willing to change the way you use vim a little bit, you might still get what you want.

Read More

offline-arch-wiki and arch-wiki-md-repo online

There were some serious delays as I struggled with some issues (particularly ones relating to automating git pushes, to not getting kicked off from the server for launching thousands of requests at the same time and, ehm, to going on an unexpected trip with my girlfriend to celebrate my birthday!) but I finally have part of my arch wiki project working roughly the way I want it to.

First, I built a little tool to scrape every article in the official Arch Wiki, convert it to markdown, save it to the filesystem and store it in a json object. Later on, I’ll come back to it to clean up the code, add more info to the database and maybe to fix all the interlinking going on in the articles. I might also allow it to take any similarly structured wiki instead of just the Arch one, but we’ll see, this already took a lot longer than expected..

Sadly, I think I made some mistakes in how I structured the requests. I originally thought that performance would be better if I collected all the article urls first, then fetched all their html, then converted them all and then saved them all. Now I’m thinking I would have been much better off if I’d just did all that asynchronously to every url instead of waiting for the whole promise arrays to resolve before moving to the next step in the pipeline. I might go back and do it over to check how that would impact performance. Realistically though, I probably won’t, since it works, you know?

Next, I used the above tool to set up an automatically updating repository on github containing all Arch wiki articles in markdown format. It should always be pretty current as it updates itself with the most recent changes every six hours.

Anyway, I could move on to building a command line arch wiki browser now, but I have some other work to take care of first. When I get back, I’ll go for the CLI arch wiki browser, or I may start working on something else I’ve had in mind, or maybe I’ll even finally build out my landing page for this website! But we’ll see, I really just wanted to post a quick update on my recent github activity and jot down some thoughts about how it went and what I’ll do next. See you next time.

Huge Arch update!

I’ve been using Arch Linux as my daily driver for almost six months now and this has been by far the biggest update I’ve seen so far! Just wanted to share this whopper of an update:

huge pacman update

In case you’re wondering, the reason for this is the switch to the new C++ ABI. In my case everything went right, but if you’re wondering what to do here and for some reason you never read the Arch News article, all you need to do to make sure everything keeps working peachily is rebuild your non-repo packages.

The Arch team provided a handy little script to identify the packages in question:

1
2
3
4
5
#!/bin/bash
while read pkg; do
mapfile -t files < <(pacman -Qlq $pkg | grep -v /$)
grep -Fq libstdc++.so.6 "${files[@]}" 2>/dev/null && echo $pkg
done < <(pacman -Qmq)

For me that just came to a half dozen packages and it took less than twenty minutes to rebuild them against the new ABI.

When I first started using a rolling release distro, I feared I’d have to deal with breaking changes all the time. In practice, I only had everything break after an update once in six months, and that was because I’d been running the proprietary graphics drivers (shame on me). Even then, it was relatively easy to boot from a live USB, chroot in and fix my setup. Apart from that, everything’s been smooth sailing, including this humongous update!

End IIFEs in })(); or }()); ?

Before I deleted my previous blog, I took a look at my pageview statistics and it turned out that the post that got by far the most views was one about stylistic differences in immediately invoked function expressions (IIFEs). That means that quite a few people are still a little confused about this whole thing, so allow me to clarify it once more.

An IIFE is an extremely common JavaScript design pattern. It’s how you create modules, define private variables and methods and safeguard the global namespace from pollution. Here’s what an IIFE looks like:

1
2
3
(function IIFE() {
// ...
}());

If you’ve done any work involving JavaScript relatively recently, you’ve most likely seen these all over the place. The subject of this post though is the fact that an IIFE can also look like this (note the last line):

1
2
3
(function IIFE() {
// ...
})();

Read More