Over the past years I’ve tried working with lambda functions on and off a couple of times. Each time I got stuck, either clicking in AWS UIs or writing YAML files.

Netlify changes all that by making lambdas easy to use. Below I’ll describe the basics of deploying a function, and I’ll show how the development tools support local development.

The most basic hello world example I could come up with can be found in this repo, tagged basic-javascript-lambda. There’s a simple index.html file (a left over from earlier experiments), and a hallo.js file in src/functions. That’s almost al there is to it, but it needs one specific bit of configuration in a file named netlify.toml, located in the root of the repository.

More

While browsing the Netlify configuration site for my account (in a more or less panicky attempt to find some config item I’d lost track of), I stumbled on an option named split testing. I know this concept as A/B testing, where you try out different versions or options of a site and check analytics to find out which version yields the highest revenue. Netlify tags this option as beta, but at the time of writing I’m pretty happy with its performance. Below is a short introduction on how to use the split testing feature.

More…

Remember when we used to have a production, acceptance testing, integration and development version of a site? And that we struggled to get an extra environment from IT just so our customers could test our work?

Those days are over. Below I’ll show how to set up deploys for every branch. Or every commit. And how to have all of those versions available at the same time. The enabling technology is Netlify.

This post will show how to deploy a site on Netlify, based on a GitHub repository. And the killer feature: each single commit can be deployed to a unique URL with no extra effort at all. This facilitates fast and easy feedback from our clients on the products we build.

more…

Social media has been blamed for locking people in a bubble, only showing them news that is in line with their beliefs. This divides society into different groups that have almost nothing in common. People read what they think they want to read, never seeing a different opinion. At the same time governments and influencers have started to call for filtering. Facebook would have to filter out lies and fake news, so we all see the truth only. The problem with the filter approach is that it will cause opinions to drift toward some bottom line truisms we can all agree on. If we start fining social media for violations, the companies will get more and more conservative, and we’ll end up in a boring world. Like having a perpetually overcast sky and an eternal drizzle. Grey goo everywhere.

This is not what we need. What we need is to be confronted with opinions that differ from what we think is right. So we (i.e. Albert Brand, Arjan Molenaar and myself) started a one-day research project at Xebia, inspired by a feature of my favorite Dutch newspaper, NRC. The feature is called Twistgesprek. The format is that two people discuss a statement during the week. Their conversation is summarized and published in the Saturday paper as a back-and-forth of messages. Quite often I start with a strong opinion about the subject being discussed, but end up with a more thorough understanding of its nuances because of the discussion. Having your convictions challenged and modified is a wonderful gift.
So, the idea was to show people ideas that directly contradict each other.
more

Mutation testing promises to help ensure quality tests. It does this by making changes to a code base and running all tests. If all is well, some changes in code should result in failing tests. So making a bunch of changes like inverting the condition in an if-statement, should cause the tests to fail. If not, the test isn’t good enough.

I’ve tried this technique a couple of years ago, and wanted to find out what had changed.

While trying to upgrade my programming skills, I ran into a new-fangled way to do ifs.

The example below is taken from code that gets a value for a property of a class. A value may or may not be set and if it isn’t the code should use a default.

You can find the code here [on Github].

So my classic go-to solution was to use an if statement like this:

[more…]

My first [Uncle Bob] event was the 2017 [GoTo conference] in Amsterdam, where Robert Martin delivered a talk like he must have done a thousand times. And many of you will probably have seen some version of it way back when. For me it was all new, having managed to somehow avoid the experience for years. He said many things that made sense to me at the time, but what got stuck in my head was the idea of a programming Kata. The advice I distilled from his words was to take a small programming problem and try to implement a solution over and over again. The actual solution would be less important than the act of solving the problem. Allowing you to experiment in a safe and well known environment. Small techniques for problem solving would gradually become part of muscle memory, much like happens, or so I’m led to believe, in martial arts.

I liked the idea and found myself a small problem: read more…

In my [previous blog] I used local images wired together with a docker-compose.yml file. This was an improvement over stand alone containers. Networking is now more robust because code in images uses names instead of IP addresses to access services. This time my goal is to introduce Swarm so I can distribute components over multiple hosts and run more instances if necessary. Next, I’ll describe step one: migrate the docker-compose-single-host setup to a Docker Swarm multi-host version. [More].

In the previous version of the shop landscape (see tag ‘document_v2’ in this [repository]) services were started with a shell script. Each depended on Rabbit MQ to run, so there was a URL with an IP address that depended on whatever address the host it runs on got from its DHCP server. This was brittle, so I decided to introduce docker-compose. Actually, I should say ‘re-introduce’ because my colleague Pavel Goultiaev built a previous version using compose. In this version, I copied and finished his code.

read more

This blog is part of my Trying-to-understand-Microservices-Quest, you can find the previous [installment here].

In a previous installment of our Microservice refactoring effort, I’ve introduced a ShopManager and a Clerk to implement the shopping process (see this blog). I ended up with a JSON document transferred between services. To make life easy for myself I just parsed all of the document using Spring magic. This time I will discuss the downside of this strategy and show an alternative.

read more