Aurelia is a modern web application framework in the spirit of Angular,
with an exceptionally concise and accessible developer experience and
standards compliant implementation. It is hands down my favorite web
framework right now and one I’d strongly recommend for most projects.
One of Aurelia’s greatest claims to fame is the incredible productivity
you can achieve, enabling you to build a full web application in just
days, if not hours.
When building the application becomes that fast, spending a day putting
together your deployment pipelines to roll out your application becomes
incredibly wasteful, so how can we avoid that?
Well, Docker offers us a great way to deploy and manage the life-cycle
of production applications. It enables us to deploy almost anywhere, with
minimal additional effort and in a highly reproducible fashion.
In this post I’ll go over the process of Dockerizing an existing Aurelia
web application built with WebPack, however the same process applies to
those built using SystemJS.
Sierra Softworks has a brand new website, rebuilt from the ground up using the
brilliant Hexo project. A lot of emphasis was placed on making it as
easy as possible for us to publish new content here while minimizing the rate
at which content becomes outdated (something our previous website suffered
from rather badly).
As a result, we’ve tried to move all the project pages to their GitHub repositories
and provide a dynamically generated list of them here. Unfortunately,
not every project we had previously is on GitHub, so we’re busy migrating some
of the older content across to this website.
Until now, all of my work on websites has been done in HTML. Write HTML for this page,
write HTML for that project and so on. HTML is one of those languages which anyone who considers
themselves good with computers should know, but it also leaves a lot to be desired. In the latest version of our website,
I decided to move to Markdown as our primary markup language for documents. Markdown is one of those languages which
continues to grow more popular, especially on very tech-centric sites like StackOverflow and GitHub
and yet if you talk to most people who are merely “good” with computers, they have never heard of it. Somewhat strange given
that Markdown is designed to be an easier to use, easier to read, shorthand version of HTML for writing documents; but I guess
that’s just the way of things.
Code Highlighting is one of those things which doesn’t seem like a big deal, until you see what a difference it can make. The issue is that source code is inherently difficult to read due to the vast number of keywords and punctuation used by compilers to understand what we are trying to tell them to do. In an effort to combat this difficulty, we rely on two different tools.
The first, formatting, is probably the most important; it is the process of making code easier to read through added whitespace, often this whitespace makes no difference for a compiler but by adding newlines and tabs, humans are able to read it considerably more easily.
The second, highlighting, is the automated (or manual, if you’re a masochist) process of colouring different parts of the source code to make it easier for humans to read. This involves colouring specific keywords in certain colours, maybe colouring variable names another etc.
Static websites are synonomous with the dawn of the internet, before database servers became mainstream, before the advent of the CMS and long before the dawn of the web application. Over the years we’ve seen the advent of web development frameworks like Ruby on Rails, Express.js and MVC to name but a few. These frameworks include support for advanced templating engines, database backed page generation and custom routing, but is it really necessary to use such a framework when a static website might address all the same problems at a fraction of the cost.