Thoughts on work/life balance

Tit Petric published on 2013-09-20 included in Engineering

In many ways I consider that the biggest strain with being a software developer is the intensive intellectual work. It’s draining. In my case, I think about problems, possible solutions. I code, test, fix and deploy changes. It’s stressful, demanding and has the tendency to consume your waking time even outside of work. There is no guaranteed off switch.

A man sits at a bar, his friends walk in. He’s thinking about efficiently pushing hundreds of millions of rows of data into a database. There is no punchline. This is literally my life most of the time, the only change is a bit different thought exercise.

A venture in continous integration

Tit Petric published on 2013-08-26 included in DevOps Observability

Green lines are code deploys and red ones are requests going to a part of the cluster. I had a big deploy today, and I'm glad to come out of it relatively unscathed.

Frameworks now use Composer packages, more code reuse now
Updated structural framework, base classes
Relatively smart and simple dependency injection
Proper exception handling and notification

Obviously there was some breakage. I had to fix about 5 incorrectly implemented interfaces, out of which one was affecting work (3 minutes to fix in production!). There were some conflicts with legacy systems like WAP and a few other breaks due to some structural inconsistencies created over the years. Most of it was a bunch of quick fixes. It’s weird but most of the breaks were due to one quick fix created a long long time ago. In the past we were trying to be intelligent and catch a few programmer errors instead of enforcing a bit of strictness, and now that we enforce this strictness we had a bit of code to clean up. Some bad code was caught before the deploy, and unfortunately due to fragmentation, some was caught after. Due to the changes implemented with the deploy, we’ll be able to run more unassisted deployment CI tasks, which will mainly save us time. And who doesn’t like to use their time creatively? - Tit Petric

Advice

Tit Petric published on 2013-08-12

If I could give advice to any software developer it would be this: Plan your software wisely. If the client needs new features - think about them. Don't just think about if they scale, think about where the project is going. Think about the work you'll do now, and the work you or someone else might have to do down the line because of your decisions. Having a procedure how to scale the work that the client sees is better than having to scale the part of your software which the client never gets to see. Enable your client, don't let your client disable you. Sometimes rebuilding is the only option - and if it comes to that, you most certainly didn't follow my advice up to this point. Learn from your mistakes and rebuild your ruins well. - Tit Petric

API Backpressure

Tit Petric published on 2013-07-18

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,... It's a nice day when I have problems like this. - Tit Petric

API development methodology

Tit Petric published on 2013-07-05

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. This way typical PHP applications end up creating objects which are never used during the course of execution. You can make some assumptions that optimize a few of these cases away, but you usually have overhead. Your API service needs to be fast. I'm trying to keep everything below 10ms, with access to data from SQL databases and cache servers. Connecting to them takes time. I usually don't hit the 10ms goal without bypassing PHP altogether. My (old but current) API layer currently pushes everything out at 22ms and 30ms, at the 50th and 95th percentile. You live you learn - I instantiate database objects and cache objects and things I don't need which take up valuable time from creating and using only what you need. So:

I needed a way to create and connect only to those services I actually need to run. If I only need to connect to Redis, I don’t need to connect to MySQL as well.
Leverage PHP language constructs to this end. Injecting dependencies should be language driven, not programmer driven.

I want you to think about this. Language driven vs. programmer driven - this is the main point. When it comes to programmer driven dependency injection, it will happen that your programmer(s) will be using their time writing methods that will get, set and report missing dependencies. It is a flawed concept from the beginning, as it introduces human error into the equation. The programmer can and will forget to pass a dependency into an object causing a fatal error which doesn’t trigger an exception that could be caught. The problems mount - the programmer requires attention to detail and discipline, and uses his time writing boiler plate code instead of developing new features. You can reduce this risk by implementing your dependencies as language driven constructs. PHP 5.4 introduced traits that could be leveraged to infer dependencies to be injected into objects, after they are instantiated. A typical execution flow would then be:

On PSR-0 standards, namespaces and code (re-)use

Tit Petric published on 2013-05-17

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.