ADVERT:  Digital Ocean is giving you two months free VPS.Try it out HERE       Recently someone asked me what I liked about Haskell and if I thought it was the best language. I said I liked it, but it wasn't the best.I like Haskell because it lets me build larger systems, more easily, and with less hassle, than any other lang I've used. It feels much more solid in the hand, like a quality hammer, compared to eg Python, which to me feels fragile, and cheap. I'll put more confidence in Haskell.Haskell solves pretty much all issues that arise for small to medium sized projects and many that arise for large and very large projects. This is unlike Python/Java/C/PHP/Bash/C#/Scala which have issues at all scales. (I will collectively call them Python#++)       As we look at ever larger Haskell codebases, while Haskell allows us to work with them orders of magnitude better than any language I have used, and while it guards us from outright bugs a

 ADVERT:  Digital Ocean is giving you one month free VPS.Try it out HERE   Some unexpected American history for you that might challenge the way you think about the "Discovery of the New World":       When Christopher Columbus first landed in the Americas in 1492, the first language he spoke with the Natives he encountered was Arabic.Columbus thought he was headed to China's imperial court - and he knew that the Chinese would have Arabic-speakers in their court, since Arabic was a global language of trade in much of Asia.Columbus brought along Luis de Torres - an Arab Jewish translator from Iberia - who spoke Arabic to the Cuban Tainos he encountered, hoping they could help the crew find their way to the Chinese court.1492 was also the year that Spanish leaders expelled Jewish and Muslim subjects from Iberia as part of the Inquisition, leading to the forced displacement of hundreds of thousands of people, a complete ethnic cleansing.   

When npm was first released in 2010, the release cycle for typical nodeJS package was 4 months, and npm restore took 15-30 seconds on an average project. By early 2018, the average release cycle for a JS package was 11 days, and the average npm restore step took 3-4 minutes. Extrapolating from historical data, scientists predicted that on 8th November 2019, the release cycle for most JS dependency packages would become shorter than the npm restore time for a typical 'hello world' app or small blog engine. Futurists were already talking about the 'nodularity' - a cultural event horizon beyond which it was impossible to make any rational predictions. With projects already out of date before they'd even finished building, software development as we knew it ceased to exist. Most projects perished. A few hardy survivors worked out how to harness the power of the infinite restore loop and run logic within the installers t

ADVERT:  Digital Ocean is giving you one month free VPS.Try it out HERE       For me a serverless (S-) architecture is much more than a event-driven function as a service (FaaS)...      A S- architecture is an abstraction on top of a (potentially very complex) infrastructure, so that devs can focus on building great features and products and run their code in production without focusing on boring configuration and scalability.This doesn't mean there are no servers and there is no care for infrastructure: quite the opposite indeed.Good S- architectures are robust and resilient modular applications composed by many building blocks. They have great monitoring, operate with great performance, and are very cost effective.        An example of popular S- architectures are CDNs. CDNs are quite complex and handle scale in a transparent way so that organisations can abstract that layer of complexity and delegate a series of tasks to a third party by p

 ADVERT:  Digital Ocean is giving you one month free VPS.Try it out HERE         First off: Kubernetes *is* a complex system. It does a lot and brings new abstractions. Those abstractions aren't always justified for all problems. I'm sure that there are plenty of people using Kubernetes that could get by with something simpler.As an example my son (9yo) wanted me to teach him Kubernetes but I started with simple imperative Docker on the command line on a singleton GCE instance. Once he gets those concepts nailed we'll start talking k8s.  That being said, I think that, as engineers, we tend to discount the complexity we build ourselves vs. complexity we need to learn.When you create a complex deployment system with Jenkins, Bash, Puppet/Chef/Salt/Ansible, AWS, Terraform, etc. you end up with a unique brand of complexity that *you* are comfortable with. It grew organically so it doesn't feel complex.But bringing new people on to help on

ADVERT:  Digital Ocean is giving you one month free VPS.Try it out HERE Today I'd like to talk about feature branching and GitHub—how we got here, what they are (and aren't) good for, why that matters, and what you can do instead. Join me, friends!       First, a definition: "Continuous Integration is the practice of merging all developer working copies to a shared mainline several times a day." That's from about 1998(!).That's what CI is: developers merging to master, often working in pairs, and shipping artifacts, _at least_ once a day. Here's what it's not: a piece of infrastructure, something your DevOps team does for you, or running tests against your feature branches. Why talk about CI? Because most teams who feature branch aren't CIing. It's a process, not a tool. It is something that you as a team choose to do, or not. You don't need a CI server to do CI. You can have one and not do it.      Th