Blog

One software bug regarding risk calculations caused 217 million dollars in investor losses[1]. It was a mistake in basic decimal operations programmed by a software developer. This shows us how important and responsible is a developer’s job. Are you sure that you know how to avoid such mistakes in your own PHP applications?

Are you doing code reviews? No? Yes? In both cases, you won't have too. Just add a couple of YAML lines to your CI. I'm very grateful that Rector is getting traction lately. More and more PHP developers save dozens of hours by running simple CLI commands on their codebases. It's a lot. But you want more laziness, right? Rector can do much more without you even running it.

“First, do no harm” says the Hippocrates. As fault-tolerance experts we say “First, prevent any harm”. It is often said that all software faults are design faults. It easier to prevent the harm at design time. Fault tolerant system design and development techniques will allow developing sustainable 99 % reliable systems.

For the past 4 years, GraphQL has offered developers a compelling new way to think about your API. What does it change for us, PHP developers? In this article, we will see very quickly what makes GraphQL a special protocol. Then, we will have a quick look at the GraphQL landscape in the PHP land before diving in the details of GraphQLite, a framework-agnostic PHP library to serve a GraphQL API easily.

PHP 7.4 brings a lot of exciting new features. One of them is the Foreign Function Interface extension built directly into the core. But what problems exactly this extension is trying to solve? Does this mean that we no longer need to write a PHP extension if we want to use an existing library? In this article, we will discover how to call almost any C library directly from PHP easily, how to overcome common pitfalls, when to use this approach, and most importantly, when not.

When developing an application, our aim as software developers is to make sure it does what it ought to do and to keep the number of defects as low as possible. We should also strive to make our lives easier, to counter external circumstances like tight deadlines and ever-changing requirements causing the exact opposite. That’s why we’re always looking out for tools and practices to help us with our jobs.

When it comes to learning how best to use exceptions in PHP, it is very difficult to find anything more than very basic explanations and tutorials online. While the consensus is that you should use exceptions indeed, there is very little information on how to structure and manage them in a larger codebase. The larger and more complex your projects become, the more important it is to start with a proper structure to avoid expensive refactoring later on. Your client will surely be thankful!

Being the author of BaseCode and creator of Shift gives me a unique insight into writing Laravel applications. I combined 20 years of writing code with supporting over 20,000 Laravel upgrades into 10 tips for crafting maintainable Laravel applications. These may seem fundamental and as such easily dismissed. But any lasting Laravel codebase practices these fundamental elements. Put simply, the more tips you follow the more maintainable your codebase will be.

There are a lot of comparisons between the big three frontend JavaScript frameworks Angular, Vue and React. But there is no winner. Each framework has its advantages and disadvantages and in the end it’s a question of personal preference which framework or library you choose for your application. Every solution follows a different approach. On the one side you have Angular with a lot of structure, best practices and patterns and on the other side there is React which only provides you the basic structure and lets you decide the rest. Vue, the third contender, is located between these two extremes. But how do you start the development process of an application when your tool doesn’t tell you where to begin?

Clean Code vs. Legacy Code. And ever again the dark side of coding spreads further and essentially endangers the sanity of us developers. We come to stop trusting our own code. That increases the pressure on us considerably. Eventually, everything is to run smoothly without causing further costs. That’s exactly what the customer wants. And “technical dept” can quickly become dangerous – even in smaller projects.