I was given the task to upgrade a small NodeJS server nobody touched in years, and also see if I could do anything about its slow response time to (especially concurrent) requests.
PHP upgrade doesn't always have to be a pain, in this case it was not the codebase that posed a challenge. On the contrary, it was fairly easy to identify what needed to be changed in the code to get it ready for the upgrade. The problem was a custom extension we had to upgrade and recompile, and the restrictions of the pipeline. Here is how I solved the problem.
On this project, we had to reduce the time it took for a background job to deliver downloadable content for the client. The existing message queue solution - RabbitMQ - was not ideal for this, so we had to look for an alternative queuing solution.
This is a success story of bringing unit testing back from the dead. As I have demonstrated in a previous case study, initiative alone is not enough, victory always requires dedication from the entire dev team. Let me explain how we made it happen this time.
Not all stories have a happy ending, but I am a firm believer that we can also learn from our failures. This was one of those occasions, so let's look at the time when I tried to get my unwilling team to adopt unit testing.
I have a great interest in mental health topics and the recent online conversations about the prevalence of overtime particularly in game development prompted me to explore the problem in greater depth.
I was working on a Yii2 application running on an Apache server, where the occasional background job was your plain old cron setup executing some procedural scripts. As the application grew, this solution became unmaintainable and we needed something better.
In 2018 and 2019, I took a brief detour from PHP development to help rework our application with a different stack, a Ruby on Rails backend and a VueJS frontend. This project was special to me because it was the first time I worked with BDD and I was also tasked with being the product owner.
The Vue.js 101 series is about things I wish someone had told me about when I first started working with the framework. Components often need to react to what happens in another component. But how exactly do they know when something is updated elsewhere? Let's explore this one.
Did you ever happen to get annoyed when it didn’t work out the way you wanted for the first try? Which solution works best in specific scenarios? Are there solutions that are superior to others? It may not be so trivial after all!
The Vue.js 101 series is about things I wish someone had told me about when I first started working with the framework. Didn't it seem confusing at first, how Vue components had these methods, these computed variables and the data() function, and it wasn't immediately obvious what's what? You're not alone.
The Vue.js 101 series is about things I wish someone had told me about when I first started working with the framework. Have you ever wondered how can you limit or extend the capabilities of the styles you define on each component? And how do you even structure your styles in a Vue.js application? Let's look into it!
This is an argument for writing better commit messages, in addition to showing some real-world examples. Have you ever refactored commit messages? Are you wondering what's the point? This article might just be the right read for you.
When team cooperation is not working as it should, it can be tempting to cut corners or act like a one-man-band and just try to do your own thing. I'd argue that's almost never the right solution, and you should not give up on trying to improve collaboration.
Is it better to rewrite something that has been there longer than the Great Wall of China? When we consider improving code quality, we might find ourselves in a clamp between the need for cleaner code, and consistency with the old parts of the software. Is there a way out of this dilemma? I am trying to find an answer for just that in this article.