Ljubljana, Slovenia

Code

API Backpressure
It's days like this where I love my job. I'm implementing back pressure for API calls that communicate to an external service. Depending on how overloaded the external service is, my API interface adapts to use caching more extensively, or to use a service friendly request retry strategy, minimizing impact on infrastructure and possibly even resolving problems when they occur. This is done by keeping track of a lot of data - timeouts, error responses, request duration, ratios between failed and successful requests,.
Read more

API development methodology
Let's say you're writing an API service. You need this API to be highly available, distributed, fast... the requirements are several pages long. The problem with API calls is, that one call might not use the same cache objects as another, uses different data sources due to partitioning or other technical reasons. A typical PHP programmer might just create an instance of every cache class, database class and others he might need.
Read more

On PSR-0 standards, namespaces and code (re-)use
When it comes to working on several projects with different people, having a set of standards to dictate code use and code re-use is a good thing to have. PSR-0 is one such accepted standard. It took a while to realize it, as I so often do, that many useful improvements to PHP mean a few steps forward, a few steps back. I'm going to try to list a few patterns which are the cause of some conflict when implementing PSR-0.
Read more

Batch resolving of promises
I tend to have a lot of development ideas stemming from repetitive workloads or from an optimization standpoint. I tend to obsess over inefficient code structures in both. I've literally had dreams that provided me with answers which I implemented during the day. If only we could code at night during sleep. In retrospective, the Pareto principle applied to that subconsciously-influenced code base, meaning 80% of it's usage was fine, and 20% was outside of the scope I was trying to solve and introduced other problems.
Read more

In process performance statistics with Redis
Every once in a while you need to do a sanity check of your code, how it performs and what you can do to improve it. This is most apparent with a code-base that is developed and refactored over a period of several years. There can be several problems that negatively impact performance due to dependency issues or legacy code that should have been removed but was forgotten during a refactoring sprint.
Read more