Category: Programming

A big part of my work has to do with code. I’ve worked as system administrator – installing, patching, and configuring someone else’s code. I’ve worked as independent programmer, writing code on my own. I also programmed as part of the team. And on top of that, I worked as Team Leader and Project Manager, where I had to interact a lot with programmers. Programming world on its own is as huge as the universe. There is always something to learn. When I find something worthy or something that I understand enough to write about, I share it in this category.

Introducing Moby Project: a new open-source project to advance the software containerization movement

Docker Blog is introducing the Moby Project:

The Moby Project is a new open-source project to advance the software containerization movement and help the ecosystem take containers mainstream. It provides a library of components, a framework for assembling them into custom container-based systems and a place for all container enthusiasts to experiment and exchange ideas.

This just had to happen, given the nature of the Open Source and the importance of the container technology for the modern infrastructure.

GitFlow considered harmful, and how we do it

I came across this rather strongly opinionated blog post – GitFlow considered harmful, and I have to say that I mostly agree with it.

In our company, we use a similar approach to the Anti-gitflow, but with even more simplicity.  This is one particular thing I like so much about git is that each person, team, or company can pick the workflow that suits them best.

Just to give you a little bit of context, we have a rather small development team (under 10 people), but we do a large number of projects.  All our projects are web-based, varying from small and simple websites (static HTML), through more complex WordPress sites (multilingual, e-commerce, etc), to business applications like CRMs.  Each project is done by several developers at a time and can later on be passed on to other developers, often much later (another iteration after several month).  Each developer is working on a number of projects at a time.  And we do very fast-paced development, often deploying multiple versions per day.  Given the nature of the projects and the development pace, we don’t ever really rollback.  Rollback is just another step (version) forward.  And we don’t have long and complex roadmaps in terms of which features will be released in which version.  It’s more of a constant review of what’s pending, what needs which resources, and what we can do right now.  (It’s far from ideal project management, but it somehow works for us.  If you think you can do better, send me your CV or LinkedIn profile, and we’ll talk.)

In our case, we do the following:

  • We have one eternal branch, and we call it master.
  • The master branch is always stable and deployable.  Even though we don’t really deploy it directly.
  • Nobody is allowed to commit directly to the master branch.  Initially it was just an agreed convention, but because people make mistakes, we now have this rule enforced with the technology.  Both BitBucket and GitHub support protected branches.  BitBucket, in my opinion, does it much better.
  • All new features, fixes, and improvements are developed in separate “feature” branches.  Most of these are branched off the master.  For large chunks of work, we can create a feature branch, and then introduce incremental changes to it via sub-feature branches, branched off the feature one.  This allows for easier code reviews – looking at a smaller set of changes, rather than a giant branch when it’s ready to be merged.
  • We do code review on everything.  The strongly suggested rule is that at least two other developers review the code before it is merged.  But sometimes, this is ignored, because either the changes are small and insignificant (CSS tweaks or content typos), or we are really in a hurry (we’ll review the changes later).  But whatever the case is, nobody is allowed to merge their own pull requests.  That is set in stone.  This guarantees that at least one other person looked at the changes before they were merged in.
  • We tag new versions only on the master branch.
  • We use semantic versioning for our tags.
  • We don’t deploy branches.  We deploy tags.  This helps with preventing untested/unexpected changes sneaking in between the review of the branch and the deployment.

The above process suits us pretty well.

Using Vim as a PHP IDE

Jon Cairns wrote “Using Vim as a PHP IDE” blog post a good five years ago, but a lot of it still relevant and useful. It covers all the usual – syntax highlighting, syntax checking/linting, tags and auto-completion, coding style and mess detecting, unit testing and debugging. As many other similar guides, he links to a variety of plugins and provides configuration tips.

What Is WP-CLI? A Beginner’s Guide

WP-CLI is a super useful tool, which I use on a daily basis, and I wish more people knew about.  Gladly, there is now “What Is WP-CLI? A Beginner’s Guide“, which explains what it is, how to install it, how to use it, and where to go from there.

Eight Rules for Effective Software Production

Timofey Nevolin wrote an excellent article “Eight Rules for Effective Software Production” over at Toptal.com.  The whole thing is well worth a read, but here are the 8 rules to get you started:

  1. Understand the IT Mentality
  2. Do Not Mix Software Production and Development Methodologies
  3. Use Persistent Storage as an Extension to Human Memory
  4. Stop Wasting Time on Formal Time Estimation
  5. Understand the Cost of Switching Tasks and Juggling Priorities
  6. Use Architecture Reviews as a Way to Improve System Design
  7. Value Team Players
  8. Focus on Teamwork Organization

All of these are good and true, but if I had to pick one, I’d say that rule 4 is my personal favorite.  Sometimes I feel like I’ve spent a good quarter of my life in meetings, discussions, and other estimation sessions.  And looking back at all of them, I have to honestly say that they all of them were a waste of time.  The only useful part of an estimation session is a high-level project plan, but that can be achieved with a project planning session – much narrower goal, much more measurable, and much easier to achieve.