I’ve written about Elixir configuration
in an earlier post,
describing the differences in the configuration styles. If you don’t know how Elixir
configuration works, I suggest reading it also. In this post, I will demonstrate a system
for configuring an Elixir project using the config/runtime.exs system introduced in
Elixir 1.11. This system is how I configure my projects, so feel free take it as inspiration, but
it’s not a law that you have to follow.
Configuring Elixir applications is a common problem point for new developers and I’ve seen many
questions about it in the community chats. So I thought to write down my knowledge in case it helps
I’ve long had certain issues with modern
web development, and I even wrote a
little tool of my own to help
me manage such an environment. So I look for ways to minimise the complexity of my setups while still
maintaining some modern conveniences. Now I’ve started to use a setup that relies on TypeScript and
modern browsers’ builtin features. This is a very minimal setup consisting just of TypeScript, plain
CSS, and maybe a tiny build script.
I was doing some Node.js V8 profiling work at the office near the end of the day and noticed my profile processing was taking a long time.
I figured it is just processor intensive and left it running for the day while I went home. To my surprise, the next day it was
still running! htop showed me it had accumulated 12 hours of CPU time and was still not finished. This led me to track down
a related issue and how to fix it.
When improving Code::Stats’s Atom plugin, I wanted to add the plugin version
as the User-Agent header: code-stats-atom/x.y.z. I used the fetch API and set the header there but it did nothing!
By googling a bit I found that User-Agent used to be a “dangerous” header that wasn’t allowed to be set in browsers.
It was only recently allowed, but Chromium
has not implemented support for it.
People commented so nicely on my first build tool FBU
that I decided to push it to the Elixir package manager Hex.pm. I renamed
it, though, since people pointed out that it could be used to build anything, not just the
front end. So now it’s called (still unimaginatively) MBU: Mix Build Utilities.
EDIT 2017-04-04: I have since renamed the project to MBU: Mix Build Utilities and published it on
Hex.pm: hex.pm/packages/mbu. I have edited the links and code examples in this post to
tl;dr I wrote my own build tool using Elixir’s Mix:
It’s no secret that I somewhat dislike the state of modern
is the ecosystem and tooling around it. There’s a lot of innovation and hard work going on
in very many fragmented projects, resulting in reimplementations of already solved problems
and a ton of half working, alpha quality, 0.x versioned packages with unknown support status.
With these packages, you start your project by building an elaborate house of cards that is
the build system. And you dread the day when you need to touch it again.
What better way to spend a slow weekend than by writing another blog engine? Plenty, actually, but that’s what I did
anyway. The result of this work: Mebe! This blog is now powered by a wonderful mix of
Elixir and Phoenix. It has all the features that Laine
had, with the addition of an actually working Disqus comment system. It’s also search engine indexable, which I thought
I didn’t care about, until I didn’t have it anymore. Not that I’m aiming for tons of visitors, but writing about some
tech problem I have fixed is kind of pointless if no one can find the post by googling for it.
I had some free time this weekend, so I decided to pick up on an old piece of code I wrote back when I started learning
Elixir. It’s a URI parser I called Nurina (the word nurina is Finnish and means
grumbling or complaining — it sounded funny and it contains the word URI). It’s not really a well put together piece of
code but more of a learning excercise. I also decided to avoid using regular expressions entirely and instead used
pattern matching to parse the whole URI — an additional challenge.