An excellent article about why static types are necessary for successful, large projects has appeared on /r/programming.
This article is very on-point about most things. It brought back memories of struggling with exactly the same kinds of problems as the author describes in languages like Clojure.
The new generation of statically typed languages with proper type inference is simply objectively better, mathematics can not be argued with - and if you get the correctness benefits without having to explicitly type your code (Thanks Hindley & Milner!) then what reason is there to not use them?
Or so you would think. The author makes this hopelessly optimistic prediction:
This is my bet: the age of dynamic languages is over. There will be no new successful ones.
Unfortunately this is where he collides with reality and with what I call "the rampant anti-intellectualism" of the IT industry.
A while back I gave a talk about Kubernetes, Google's container orchestration system. It was a short overview of Kubernetes concepts and a hands-on demonstration of setting up an ElasticSearch, Logstash & Kibana stack on Kubernetes.
In case it is interesting for anyone, the slides and material from the talk are available here. If you happen to be in Oslo and want to know more, I will be giving this talk again on Saturday at Hackeriet!
Also this blog is running off a tiny Kubernetes cluster as of version five. As the data-store for the blog is based on
acid-state, I had to do some interesting modifications to the blog setup - including using Data.Acid.Remote for the first time. Stay tuned for an upcoming blog post about that ...
At Nordcloud we frequently set up configuration management infrastructure
for customers, the common tools obviously being Puppet, Ansible and so forth.
The traditional way to set up a Puppet environment is based around a central
Puppet master on which the manifests are placed. This master compiles the
Puppet catalogue which is then fetched by the nodes.
Authentication between nodes and Puppet master relies on a relatively complex
In my opinion many of the features that you get from using a Puppetmaster-based
setup are not strictly necessary in a lot of environments, and the way that it
works contradicts how I believe configuration management should work in 'cloud'-
In those environments it is desirable to have node configuration be fully
autonomous, such that a node can take care of its own configuration without
relying on a central system like a Puppet master.
If you want to know about these 10 things I hate, check out this cool article after the fold.
I've been sick more in the two years in Sweden than in the ten years before that.
Why? I have a theory about it and after briefly discussing it with one of my roommates (who is experiencing the same thing) I'd like to share it with you:
Normally when people get sick, are coughing, have a fever and so on they take a few days off from work and stay at home. The reasons are twofold: You want to rest a bit in order to get rid of the disease and you want to avoid infecting your co-workers.
In Sweden people will drag themselves into work anyways, because of a concept called the karensdag. The TL;DR of this is 'if you take days off sick you won't get paid for the first day, and only 80% of your salary on the remaining days'.
Many people are not willing to take that financial hit. In combination with Sweden's rather mediocre healthcare system you end up constantly being surrounded by sick people, not just in your own office but also on public transport and basically all other public places.
Oh and the best thing about this? Swedish politicians often ignore this rule and just don't report their sick days. Nice.
This is the first in a series of blog posts about how to manage a cluster of CoreOS machines using Ansible.
CoreOS is a minimal Linux distribution focused on providing a highly-available Linux base for servers, with all applications run in Docker and service discovery plus scheduling happening through etcd and fleet.
I'll assume some familiarity with CoreOS concepts such as cluster discovery and also a general knowledge of how Docker and Ansible work. Go read up on those otherwise - it's lots of fun!
All code for these blog posts is collected in my example repository. Every blog post has an associated tag, for this post it's basic-setup.
So let's get started. In this post we will cover how to run Ansible on CoreOS machines and what we can do with it. In the end we'll provision a cloud-config using Ansible.