A while ago I wrote about Decoupled, Headless and traditional CMS architecture. The post is about choosing which one is right for you. I wrote about the different architecture characteristics and the consequences it has. Knowing the differences will help you pick the right one for you. Based on that post you could think that you have to choose between Decoupled or Headless. But maybe there is more to choose from.
No matter what kind of business software you’re working with, updating to keep up to date is always necessary. Also with custom software. Although you can make choices in your update and upgrade policy. But do this consciously, because the consequences vary greatly. And you notice that in the extent to which business software supports your users and business. And it also strongly determines how securely your organization works. Have you already made a choice?
Many people think the purpose of a business is to make money. The more money the company makes, the better it goes,' is the thought. Many annual plans are made based on 30% more turnover or 10% more profit. Until a few years ago, we also worked in the same way at Ibuildings. With a larger company with more profit, the rest would be fine on its own. But that’s not how it works, I noticed with myself.
Using APIs and SaaS solutions in the cloud offers organizations many opportunities. But there is also a downside to this development. Many companies and organizations lose sight of their software architecture. This can lead to proliferation of (emergency) solutions and fragmented data. Prevent this by reversing the development process. Start again with your own software architecture.
As a software engineer that mostly practices object oriented programming (OOP) I value principles like SOLID. When architecting apps I prefer a layered approach. I have typical layers like Application, Domain and Infrastructure. This helps me separate concerns and build a maintainable codebase. With this post I want to share how I try to create loosely coupled and maintainable software.
At Ibuildings we work together and organise our work according to the principles of Holacracy. So without a top-down structure. With a work environment in which everyone is responsible for their own work, within appointed roles. But what does Holacracy mean in practice?
Nowadays there is a lot of talk about “Headless” and “Decoupled” Content Management Systems. It seems to be a new trend, but what is the difference with a traditional CMS and why should you choose for a headless or decoupled CMS?
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.
A couple of days ago I was at the Dutch PHP Conference where I went to a talk about [Content Security Policies by Matt Brunt. Although we follow the OWASP top ten list, I never dived into them that much. We have written a bit about them before, but I want to go a little further since they are really handy when trying to prevent XSS attacks.
You develop software together, as a software engineer and customer. This involves a series of translations from the business to the final software. The trick is to limit the number of translation steps, because with every translation you lose nuances. This is possible by bringing software engineers and clients closer together and actually having them develop together. With Gherkin, they can speak the same language and describe software behaviour (BDD). And build even more intensively together.
Are you already in need of technical ‘debt assistance’ for your business software? With the development of almost all software, a technical debt is built up, mainly to achieve results quickly. That doesn’t have to be a problem, as long as you handle it well and consciously.