Speech Recognition and Synthesis in the Browser

With the recent upsurge of Siri, Google Assistant and Amazon’s Alexa, speech recognition and synthesis have become an increasingly important tool in the developer’s toolbox. Working with speech data can not only improve the accessibility of your application. It can also increase conversion in your webshop, especially when customers shop on their mobile phones. Native apps have a large advantage in this space, as Apple’s SiriKit and Google’s Assistant SDK can get you up and running in a few minutes to hours.

Read more →

Building an AR app in a day

Recently we did a Techrally day at one of our clients, Intergamma. The client provided a couple of subjects of their interest, from voice search to automated classification. With a team of 4, we decided to build an augmented reality mobile app which shows DIY assembly instructions to help a customer 'on the spot'. Did we succeed? Read on...

Read more →

TDD in React

It’s nearly impossible to keep up with the pace JavaScript frameworks pop up nowadays and I believe it’s good to have some focus. For me, this means the big three as defined in this post and more specifically doing basic TDD with React. Read more →

Kubernetes and on-demand CI builders

Let's say you've got a CI/CD pipeline and you would like to run builds in containers. You could just configure Docker on one of your machines and point your builds there, but why not use something a bit more scalable? Enter Kubernetes, a leading container orchestration platform, which luckily offers several options for using its self-contained pods as on-demand CI builders. Things like sharing sources between containers and networking will be handled for you, so all you'll have to worry about is specifying the desired image.

In this blog, I'll be exploring two of those options in commonly used CI tools, namely Gitlab and Jenkins, and will explain how to configure the Gitlab-runner or Jenkins Kubernetes plugin to run on-demand CI builders on a Kubernetes (or "K8s") cluster.

Read more →

The behavioural economics of bugs in robots

All contending teams, without exception, experience a moment at which all members are standing around the table, looking at the robot; this is not what’s supposed to happen. Shouldn’t be a surprise, we told them in advance there would be bugs. Unfamiliar with the codebase and the hardware, it is now their job to find the bugs and fix them. They do know what the robot should do: ‘it should follow the black line, once you press the start button’.

We have been doing these robot challenge workshops for a while now. They’re great fun, for creating a shared understanding between business and IT, or experiencing an acceptance test-driven approach to software development. The mBot robots bring a highly visible aspect to the software’s behaviour.

Read more →

This one crazy DevOps language you should learn (during Advent Of Code)

Random bits I learned about an underappreciated language by having fun during Advent Of Code.

This Friday the 2017 edition of Advent Of Code started, a daily treat of small programming puzzles for the holidays. Kudos to Eric Wastl for creating such a fun competition!

Last year I wanted to add a DevOps theme to my participation, so I choose to write solutions in the most important DevOps language. No, not Go. No, also not Python. Definitely not Java. Number one of course is… Bash: present in all Linux systems, almost all Docker containers, heck, even in Windows now. Gluing together systems for almost 30 years. [More...]

Refactoring to Microservices – Introducing Docker Swarm

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].

An Ubiquitous Domain language throughout testing

One of the biggest challenges as engineers is to write working software and also keep an extensive documentation. Most engineers hate writing documentation, and after they published documentation on a wiki it will die a lonely death. We want to strive for writing a Living Documentation in an Ubiquitous Language. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help you achieve this. Especially when we start writing code, it is really important for the quality of our software to start with tests describing what your application does. We want to write software with empathy in mind, software that is understandable for peers. While software developers are beginning to use the language of the domain (business language) more in their application code, most tests still contain a lot of technical language.

Read more →