When dealing with a dynamically typed language, any effort to tame the beast can pay off. For Erlang, that means Dialyzer specs. The more specs added, the more helpful the tool becomes - but getting to that point can be painful. Here are some warnings I’ve seen, what they mean and how I solved them.
Here’s a few tricks for rendering markdown in GitHub that most people wouldn’t know about. Oh, and they work for new Issues, Pull Requests, and in the Wiki too!
Handling date and times is a thorn in every experienced developer’s side. If you haven’t had the pleasure yet, you will. ;) Coming off a week of standardizing some datetimes across an Erlang app, here’s a few personal thoughts.
If you work with the .NET Framework long enough, you may eventually find yourself tasked with converting one language to another, either by request or necessity. But conversion isn’t always necessary - it’s possible (and easy!) to have one solution with multiple languages.
After writing about so many APIs and having to figure out the auth process for each, I wanted to compare and contrast how some of these services approach authentication and authorization, and why they might’ve decided to do it the way they did.
Have you ever tried to execute a function at some future time in Erlang? You can, with a timer, but the compiler may complain that the function you’re calling via the timer is unused. Why is that and what can you do?
When you find an API to use in your app, you’ll need to access it in a specific language - not always an easy or straightforward task. As long as you’re doing all that work, why keep it to yourself? Let’s look at creating an API wrapper that you can share with others!
Becoming an Erlang developer has not always been easy, but over the last couple of years I’ve learned a few ways to tame the beast. It doesn’t need to become any other language, but there’s definitely room for improving the developer experience!
Concatenating strings and binaries in Erlang can get ugly quick. Let’s make it easier.
As of this writing, my blog runs on the Ghost platform, and I was mildly surprised when I ran a ghost update the other day and suddenly my custom themes and scripts were just gone! Luckily I use DigitalOcean with backups enabled, and I had a backup from just a couple days before. I rolled back, verified my styles and customizations were present, then ran ghost update again. Wiped out. In retrospect, this makes sense. There are going to be updates to Casper, the default Ghost theme, and how should they reconcile that with any local changes I’ve made? They can’t reasonably, so they just overwrite it. WordPress had the concept of child themes, which allowed for extending a base theme, so I attempted to do something similar with Ghost. ...