Tegenwoordig wordt er veel gesproken over “Headless” en “Decoupled” Content Management Systemen. Het lijkt een nieuwe trend te zijn, maar wat is het verschil met een traditioneel CMS en waarom zou je kiezen voor een headless of decoupled CMS? Om die vraag te beantwoorden moet je weten wat headless en/of decoupled betekent.
At Ibuildings we strive to implement Continuous Delivery for all our projects. It helps us build quality software that can be controlled and well managed. My colleague Tom talked about Continuous Delivery before. In this article I want to take you through the technical stuff that enables us at Ibuildings to do continuous delivery.
Progressive Web App (PWA) is a term that has been thrown around quite a lot lately. But what exactly is a PWA? And how do we update our plain old website to be a cool hip PWA? Together we will explore how we can go from our current website to a full-fledged PWA. We will learn a thing or two about service workers, the offline web, and cross-browser compatibility.
In this article I want to talk about the use of behavior driven development (BDD) frameworks. BDD Frameworks let you create executable specifications which you can use for automated testing and documentation.
Popular frameworks include Cucumber, Behat, Behave, etc.
They all implement Gherkin as a specification language.
If you have never heard of BDD or you have never played with BDD frameworks before then please go read the Cucumber documentation website and learn how it can help you in developing software.
At Ibuildings we do not practice BDD a lot. But we do use Behat in most projects. We do believe that projects benefit from BDD, but the required collaboration with the customer is often difficult to achieve. Tom talked about this challenge in his article about Gherkin.
Even though most websites use battle-tested frameworks and libraries which automatically escape XSS, it is still number 7 in the OWASP top ten list. Also big companies like Facebook, Twitter or Yahoo still suffer from XSS from time to time. So we may conclude that it is hard to create a bulletproof defense against it. But if you have a good content security policy implemented you will make it extra hard (if not impossible) for attackers to inject harmful code into your websites.
For many years Ibuildings has had a formalized way of reviewing people's skill sets. This system enables tracking of skills and relative changes in those skills over the years, across the organization. This has been used as a means for estimating a person's salary and appropriate changes to it, as well as opportunities for personal development. In early 2016 we recognized that the technical part of this system needed an update. So I started working on a new list of technical skills.
In the previous parts of this series we looked at how to get rid of complexity at the level of algorithms. After discussing the problem of nulls in your code, we looked at object lifecycles and how to encapsulate them properly. Now that we have objects that can be constructed and changed only in valid ways, we need to look at how they communicate with each other and how we can improve our code with regard to that aspect.
In the first part of this series we looked at ways to reduce the complexity of function bodies. The second part covered several strategies for reducing complexity even more, by getting rid of null in our code. In this article we'll zoom out a bit and look at how to properly organize the lifecycle of our objects, from creating them to changing them, letting them pass away and bringing them back from the dead.
In the previous part of this series we looked at what are basically a lot of guidelines for achieving "clean code". In this part I'd like to take a closer look at something we call null. Our main goal will be: to get rid of it.
PHP is pretty much a freestyle programming language. It's dynamic and quite forgiving towards the programmer. As a PHP developer you therefore need a lot of discipline to get your code right. Over the years I've read many programming books and discussed code style with many fellow developers. I can't remember which rules come from which book or person, but this article (and the following ones) reflect what I see as some of the most helpful rules for delivering better code: code that is future-proof, because it can be read and understood quite well. Fellow developers can reason about it with certainty, quickly spot problems, and easily use it in other parts of a code base.