Slimming down Docker images

It’s been a while since I posted anything about Docker.  That’s mostly because I still don’t really use it for anything – playing around locally, testing and learning doesn’t count yet.

But just to keep the ball rolling, here are a couple of handy links for the ideas on how to improve your Docker images, so that Docker uses much less space, benefits more from caching, and brings up the containers faster:

Both articles are around the same theme – choose your  base image carefully, try to minimize the layers, use only what you need, and don’t forget to clean up the disk space with “docker system prune“.

17 Tips for Using Composer Efficiently

Martin Hujer has collected 17 tips for using composer efficiently, and then added a few more after receiving the feedback on the blog post.  I was familiar with most of these, but there are still a few that are new to me.

Tip #7: Run Travis CI builds with different versions of dependencies

I knew about the Travis CI matrix configuration, but used it only for other things.  I’ll be looking into extending it for the composer tests shortly.

Tip #8: Sort packages in require and require-dev by name

This is a great tip!  I read the composer documentation several times, but somehow I missed this option.  It is especially useful for the the way we manage projects at work (waterfall merges from templates and basic projects into more complex ones).

Tip #9: Do not attempt to merge composer.lock when rebasing or merging

Here, I’m not quite sure about the whole bit on git attributes.  Having git try to merge and generate a conflict creates a very visible problem.  Avoiding the merge might hide things a bit until they popup much later in the CI.  I guess I’ll have to play around with this to make up my mind.

Tip #13: Validate the composer.json during the CI build

This is a great tip!  I had plenty of issues with composer validations in the past.  Currently, we have a couple of unit tests that make sure that composer files are valid and up-to-date.  Using a native mechanism for that is a much better option.

Tip #15: Specify the production PHP version in composer.json

This sounds like an amazing feature which I once again missed.  Especially now that we are still migrating some projects from PHP 5.6 to PHP 7.1, and have to sort out dependency conflicts between the two versions.

Tip #20: Use authoritative class map in production

We are already almost doing it, but it’s a good opportunity to verify that we utilize the functionality correctly.

 

Defensive Programming : Object Calisthenics

I came across this nice and somewhat strongly opinionated video on Defensive Programming:

Marco Pivetta makes quite a few good points with I agree (and a few with which I disagree).  One thing that he mentioned though I haven’t heard about – Object Calisthenics.  Which turns out to be yet another set of rules and best practices for the object-oriented design and programming.  Here are the rules to get you started:

  1. Only One Level Of Indentation Per Method
  2. Don’t Use The ELSE Keyword
  3. Wrap All Primitives And Strings
  4. First Class Collections
  5. One Dot Per Line
  6. Don’t Abbreviate
  7. Keep All Entities Small
  8. No Classes With More Than Two Instance Variables
  9. No Getters/Setters/Properties

Read the whole article for explanations and examples.

Nginx Performance Tuning – Tips & Tricks

Here are a whole lot of “Performance Tuning – Tips & Tricks” directly from the Nginx team.  I’m sure you’ve seen bits and pieces of these all over the place, but it’s nice to have them all together and from the credible source as well.

The 2018 Guide to Building Secure PHP Software

The 2018 Guide to Building Secure PHP Software” is an excellent guide to writing modern PHP applications with security in mind.  It covers a bunch of the usual topics, but provides fresher solutions than most other similar guides.

On Empathy & Pull Requests

I’ve trained more people on the subject of pull requests than I care to remember.  But I’ve never came close to explaining the best practices as well as this Slack Engineering blog post does:

Basically, your reviewer is totally missing context, and it is your pull request’s job to give them that context. You have a few options:

  • Give it a good title, so people know what they’re getting it into before they start.
  • Use the description to tell your reviewer how you ended up with this solution. What did you try that didn’t work? Why is this the right solution?
  • Be sure to link to any secondary material that can add more context — a link to the bug tracker or a Slack archive link can really help when describing the issue.
  • Ask for specific feedback — if you are worried that the call to the `fooBarFrobber` could be avoided, let them know that so they can focus their effort.
  • Finally, you should explain what’s going on for your reviewer. What did you fix? Did you have any trouble fixing the bug? What are some other ways you could’ve fixed this, and why did you decide to fix it this way?

Not every pull request needs every single one of those things, but the more information you give your reviewer, the better they will be able to review your code for you. Plus, if someone ever finds a problem in the future and tracks it down to this pull request, they might understand what you were trying to do when they make a follow-up fix.

Give your reviewer all the context they need to get up to speed with your bug so they can be an informed, useful code reviewer. It’s all about getting your reviewer onto the same page as yourself.

Google Developer Documentation Style Guide

Google Developer Documentation Style Guide” is a guide for Google developers on how to write the developer documentation.  As someone who have been involved in technical documentation for years now, I find a general lack of such guides from other companies interesting and slightly disturbing.

Kudos to Google for the effort and for sharing with all of us who are trying to improve the technical writing.

On Semantic Versioning

First of all, you should know that versioning is important.  Even the worst versioning practices provide more value than no versioning at all.  At work, we are big fans of the Semantic Versioning, and we use it for all our projects, plugins, and libraries.  And I think, you should do too.

In general, Semantic Versioning works great for us.  But there were a few bumps recently, with more and more libraries dropping support for PHP 5.6 and requiring PHP 7.  I can’t blame them – after all PHP 5.6 has reached its end of life quite a while ago.

It’s not what the maintainers do, but how they do it that I have an issue with.  I’ve been thinking about writing a blog post on the subject for a few month now.  Never got to it.  And yesterday I came across this blog post by Paul Jones, which is so much better than whatever I was about to say.  Paul explains the problem in detail and suggests the “System” addendum to Semantic Versioning:

I opine that requiring a change in the public environment into which a package is installed is just as major an incompatibility as introducing a breaking change to the public API of the package. To cover that case, I offer the following as a draft addendum to the SemVer spec:

  • If the package consumer has to change a publicly-available system resource to upgrade a package, then the package upgrade is not backwards-compatible with the existing system, and the package SHOULD receive a major version bump.

Using “SHOULD” makes this rule somewhat less strict than the MUST of a major version bump when changing the package API.

Coming back to PHP 5.6 vs PHP 7, that would suggest that maintainers who drop support for PHP 5.6 SHOULD bump up the MAJOR release of the library.   And I wholeheartedly agree with that!

P.S.: For those of you who don’t or can’t use Semantic Versioning for whatever reason, checkout Paul’s blog post on Semantic Versioning vs. Romantic Versioning.

Clean Code SOLID principles applied to PHP

clean-code-php is an excellent set of examples for the SOLID principles as applied to PHP programming:

Software engineering principles, from Robert C. Martin’s book Clean Code, adapted for PHP. This is not a style guide. It’s a guide to producing readable, reusable, and refactorable software in PHP.

Not every principle herein has to be strictly followed, and even fewer will be universally agreed upon. These are guidelines and nothing more, but they are ones codified over many years of collective experience by the authors of Clean Code.

Inspired from clean-code-javascript