Useful Git commit messages: concept of “why”

Git commit kid meme
Write commit messages like a boss

Big cleaning Fridays – time of the week when the number of “wtf’s/hour” drastically increases. I had to dive into some of the projects that been aside of my daily working routine for a while, and just to refresh the notion of what’s been going on up there, I’ve fired git log on the repository. Oh, how I hate commit messages like ‘minor fixture for …’ and ‘fixed typo for …’! This is how I hate it:

git log review reaction
Git log review reaction


Rule of thumb for useful and reasonable commit messages in Git (I’d say in any Version Control System though):

“Don’t tell how you did the change in the code, but write “why” the change was performed”.

At some point you might use ticket IDs in the commit message, which will bind the change to the initial request/bug, but it won’t properly specify the changes done in the code.

git log --pretty=oneline for the repository – and try to find logic in your commit messages among the project. Especially, if the request affects lots of code, ticket_id would simply group the commits but won’t tell you much about it.

Classical example of ticket_id integration – Asana and Github integration, or mentioning #branchname in Git commit for Github to bind all the diffs to corresponding branch.

For Git commit message best practices – published really good article covering most of the do’s and don’ts.

CakePHP 3 adopts PSR-2

Recently read this article from James Watts:

By adopting PSR-2 we can remove or reduce the code we maintain related to enforcing coding standards – as there are common tools, used by the rest of the community, to validate and revise CS issues, without requiring exceptions.

Looks like it’s time to re-write our internal modules with PSR-2 standards in mind, if we want to share them with open-source community.

Social media: Detoxification

It’s one of those posts at the end of the year, summing up the results of 2014 and preparing for 2015. As the main challenge of 2015, I’ll be slowly leaving social media towards old school writing and mumbling about different daily stuff about technologies, Cyprus and whatever comes to my mind.

  • September 2014 – account closed.
  • December 2014 – Instagram account closed.
  • Facebook account – remains for cross-posting
  • Google+ – do I still have it?
  • Twitter – never been writing there much, mostly used by Social plugin in my blog.

Too much time wasted for repetitive information flow in social media. Enormously small percentage of that data can be considered useful. Plus, most of the people in friends list are known personally – so why spoiling the opportunity of sharing something good personally. Socialize in offline! 😉

Cakephp 2.x: failing Phing using CakePHP testsuites

Digging todays deployment scripts on CI (Continuous integration) machine, I’ve noted that no matter how many Unit tests fail, phing still thought that builds were successful. Teetering on the brink of a heart attack, I’ve started checking stage machines, and production systems, to get the prove of concept. Thankfully, the number of failed tests wasn’t too big, and patches were added shortly, but the issue remained.

It appeared that ExecTask of Phing (no matter how the script is ran), will return success, unless you start comparing the values outside of it. Solution was pretty obvious, but took some time to go through the documentation of Phing/PHPUnit/CakePHP:

PHP functionphobs and doccomment fans

So in PHP functions are basically used in two cases: If the programmer doesn’t yet use OOP or if the script isn’t worth using OOP for. The notion of “helper function” or something like that does not seem to exist…(Reminder: Using classes does not mean your code is object-oriented!)

So true! But what really got me on this article, was this part:

Another tangentially related “standard” practice I feel badly about is the excessive use of doccomments. In most cases phpdoc comments just comment the obvious – at the same increasing the code size by a factor of two or three. I have no problem with doccomments where necessary, but in most cases (at least with well designed code) the behavior should be obvious from the method and parameter names.

Coming from a Perl camp and being a fan of Ruby for few years (still using them here and there), I start catching myself thinking that the world’s been taken over by crazyCamelCaseJavaProgrammers. I do understand that complex projects with huge (no, “huuuuuuuuge!” would be more appropriate here) codebase need concrete descriptive variables, but what happened with readable code? The less readable it becomes the more comments it generates. Sometimes the only expression you get after reading a doc file on the class is “Thanks, Captain Obvious!”. Commenting return statement with “return” comment, or “note: division by zero” and here it comes – division by zero.

I guess that I’m too picky on this one, but by the end of the day remember what this oldie:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.

Docker partners Microsoft

Today, we announced an exciting set of joint initiatives with Microsoft, including:

  • Extending Docker to Windows with Docker Engine for Windows Server
  • Microsoft’s support of Docker’s open orchestration APIs
  • Integration of Docker Hub with Microsoft Azure, and
  • Collaboration on the multi-Docker container model, including support for applications consisting of both Linux and Windows Docker containers

I’d like to provide some context for this announcement, and why we are so excited.
When Docker was launched as an open source project 18 months ago, we had a simple goal:
“To build the ‘button’ that enables any application to be built and deployed on any server, anywhere.”

Great news for Docker. The more the merrier

CakePHP 3.x: first impressions


Having a pint at Octoberfest with Leonid, we have an interesting discussion about recent CakeFest held in Madrid. Apart of crazy stories about haircuts, and alcohol consumption that hotel had to witness those days, CakePHP 3.x was shortly introduced between the pints.

Since, I’ve been heavily using this framework in the last 3-4 years, and some heavy projects are still running on it, I’ve decided to have a look, to get the notion of what to expect, once the 3.x branch get to stable mode.

First impression was merely same as flood victim: in less then a split of a second, you realise how much you’ll have to re-write to comply with 3.x structure. It’s a lot! Almost a full re-write. Damn!



Major improvements and redesigns affected:

  • ORM of Cake
  • Namespaces (namespaces, namespaces, names…)
  • Request/Response are defacto standards
  • Core became smaller, moving towards plug-ins architecture.
  • Composer-friendly.

I guess it’s the time to plan an upgrade, as not much time left for the release of stable 3.0.0 version.

For those of you willing to participate, get your coding kung-fu on the issue tracker in GitHub repo.

You’re using an outdated browser, please use Chrome

Going through, stumbled upon this nice source code:

<!--[if lt IE 7]>
<p class="chromeframe">You are using an <strong>outdated</strong> browser. Please <a href="">upgrade your browser</a> or <a href="">activate Google Chrome Frame</a> to improve your experience.</p>

Just out of curiosity, what would people heavily using IE do, if they’re offered Chrome. Ignore, or upgrade their IE?