Robert Basic's blog

Archives for December, 2016

Things I learned in the past four years

by Robert Basic on December 30, 2016.

Since yesterday was my last day on a project after four years and two months, I decided to take a look back on those four years and write down some of the things I learned.

Things I learned about being a better listener, a better communicator, a better team mate, a better programmer.

Leave your ego at the door

This is probably one of the hardest and most important lessons I learned. I’m happy that I learned it early into the project.

Ego gets into the way of the actual programming. There is no place for it. People get defensive about their code, become deaf to advice, don’t take criticism well. This slows down the development process, makes communicating difficult, if not impossible.

Criticism of my code is not criticism of me. If I submit a pull request and the reviewer deems the code not fit for inclusion into the project, there is nothing to get upset about. The code needs improvement. If I know how, I’ll improve it, if not, I’ll ask for help how. It is much better and efficient than getting all protective about the code.

Don’t play the blame game

Joe wrote an excellent piece on the blame game more than 3 years ago.

Removing the blame from the entire process is liberating. When dealing with a problem, don’t focus on trying to find the person, or persons, responsible for the issue at hand, but try to understand what caused the problem, what is the best and fastest way to solve it, and how to prevent it from happening again in the future.

I know I was lucky to be working on a project where this blame game was not being played and that there are a lot of teams and companies where there’s a ton of office politics and everyone wants to survive… But that stuff really isn’t helping any one. If possible, at least try to not play it within your team, with your closest coworkers.

Take responsibility

Admitting to a mistake is hard. It’s scary.

Admitting first to myself that I’m not infallible, that mistakes happen makes taking responsibility a lot easier. And it becomes easier over time.

I believe that people tend to react positively to sincerity. Being honest and upfront that I made a mistake, saying sorry, goes a long way. Yes, the mistake might have repercussions, but I’m an adult and I stand by what I did.

Taking responsibility is the professional thing to do.

It’s OK to say I don’t know

I don’t know.

I’ve said it a lot. I’m still here, still alive, the world didn’t come to an end. No one punished me for it. The only thing that happened is that I learned new things I didn’t know before. And guess what? Learning new things is part of the job.

Saying “I don’t know, can you show me please?” is perfectly fine. If we ask for help, we will get it. People like helping.

Knowing the business domain is important

We, programmers, are a smart bunch of people. We solve problems for a living. Without knowing what is the actual problem the business is trying to solve and just waiting for others to give us a solution which we need to translate into code, takes away the problem solving for which we initially signed up for. The business will also miss out on properly utilizing the experience we gained so far.

Understanding the core domain makes it possible to give ideas, work together with other people (not necessarily programmers) to come up with better solutions. Everyone will benefit from this. The business gains by having yet another smart person helping out, and you by learning new things.

Not everything we learn need to be exclusively about code.

Ask why?

This goes hand in hand with knowing the business domain.

Keep asking why. Why is some new feature being implemented, why do they need it? If you are joining a project that is being developed for some time, ask why were some things done in a certain way. It will both make learning the business domain easier and faster and it will also help with getting to know the codebase.

Asking why shows the business owners that you care, and caring about the same things as they do will only be helpful during the project’s lifetime. They will provide help and explanations much easier.

Onto new adventures

Working on this huge project for this long is something I’m truly grateful for. Not everyone gets an opportunity like this, especially this early in their professional career.

I learned a lot from my friend, partner and mentor, Srdjan, as well as from Luka who joined our small team recently.

I’m certain the new year will bring us exciting new challenges. If you have, or know of a project where the three of us could help out, let us know.

The Code4Hire team is here to help.

Tags: about, learning, me, random.
Categories: Blablabla, Development, Programming.

Issues with Vagrant after upgrading to Fedora 25

by Robert Basic on December 24, 2016.

Fedora 25 was released over a month ago, so I decided it was time to upgrade from 24.

Using the dnf plugin system-upgrade the entire process went smooth. The Fedora Magazine, as always, has a nice post on how to upgrade.

So far I ran into only a couple of minor issues with Vagrant.

The first one, which isn’t really a problem, is that Vagrant got downgroaded to version 1.8.x from 1.9.1 which I had installed in Fedora 24. The fix for that is easy, just install the new version again:

robert@odin ~$ sudo dnf install ~/Downloads/vagrant_1.9.1_x86_64.rpm

The second issue was that, well, vagrant didn’t really want to work. When trying to run vagrant up it would spit out the usual kernel module is not loaded error.

The provider 'virtualbox' that was requested to back the machine
'default' is reporting that it isn't usable on this system. The
reason is shown below:

VirtualBox is complaining that the kernel module is not loaded. Please
run `VBoxManage --version` or open the VirtualBox GUI to see the error
message which should contain instructions on how to fix this error.

Running VBoxManage --version provided a helpful message, for once:

robert@odin ~$ VBoxManage --version
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (4.8.15-300.fc25.x86_64) or it failed to
         load. Please try load the kernel module by executing as root

           dnf install akmod-VirtualBox kernel-devel-4.8.15-300.fc25.x86_64
           akmods --kernels 4.8.15-300.fc25.x86_64 && systemctl restart systemd-modules-load.service

         You will not be able to start VMs until this problem is fixed.
5.1.10r112026

Looking at the list of installed packages with dnf list installed I saw that both the akmod-VirtualBox and the kernel-devel packages are installed.

Running the next command fixed the issue:

robert@odin ~$ akmods --kernels 4.8.15-300.fc25.x86_64 && systemctl restart systemd-modules-load.service
Checking kmods exist for 4.8.15-300.fc25.x86_64            [  OK  ]

VBoxManage shows no warnings any more:

robert@odin ~$ VBoxManage --version
5.1.10r112026

and Vagrant works just fine again.

Happy hackin’!

Tags: akmod, fedora, vagrant, vboxmanage, virtualbox.
Categories: Development, Software.

Using Doctrine DBAL with Zend Expressive

by Robert Basic on December 22, 2016.

The Doctrine project comes with a database abstraction and access layer — Doctrine DBAL — which I prefer over other abstraction layers like Zend DB.

My good friend James, aka Asgrim, has written already how to integrate Zend Expressive and Doctrine ORM.

But what if want to use only the DBAL with Zend Expressive, and not the entire ORM?

It’s pretty easy as all we need to do is write one short factory that will create the database connection using the connection parameters we provide to it:

src/App/Infrastructure/Database/ConnectionFactory.php

<?php declare(strict_types=1);

namespace App\Infrastructure\Database;

use Doctrine\DBAL\DriverManager;
use Doctrine\DBAL\Driver\Connection;
use Interop\Container\ContainerInterface;

class ConnectionFactory
{
    public function __invoke(ContainerInterface $container) : Connection
    {
        $config = $container->get('config');
        $connectionParams = $config['db'];

        return DriverManager::getConnection($connectionParams);
    }
}

Configuration of the database connection is pretty straightforward as well:

config/database.php

<?php declare(strict_types=1);

return [
    'db' => [
        'driver' => 'pdo_pgsql',
        'dbname' => 'database_name',
        'user' => 'username',
        'password' => 'password',
        'host' => 'localhost',
        'port' => 5432,
    ]
];

For other options and possible values, take a look at the configuration documentation.

Next, we configure a container-interop service locator, like Zend ServiceManager to be able to access the database connection in parts of the application where we need it. This configuration consists of mapping a factory name to the ConnectionFactory factory:

config/dependencies.php

<?php declare(strict_types=1);

return [
    'dependencies' => [
        'factories' => [
            'db' => App\Infrastructure\Database\ConnectionFactory::class,
            // other factories ...
        ],
        // other type of dependencies ...
    ]
];

Now all we need to access the database connection is to grab it from the ContainerInterface container somewhere in our application and we’re all set:

src/App/SomeObjectFactory.php

<?php declare(strict_types=1);

namespace App;

use Interop\Container\ContainerInterface;

class SomeObjectFactory
{
    public function __invoke(ContainerInterface $container) : SomeObject
    {
        $connection = $container->get('db');
        return new SomeObject($connection);
    }
}

We can now use this $connection object to further create the query builder, work with transactions, the schema manager and other features the Doctrine DBAL provides us. Nice and easy.

Happy hackin’!

Tags: dbal, doctrine, zend expressive.
Categories: Development, Programming, Software.

Anatomy of a git diff

by Robert Basic on December 20, 2016.

I’m looking at git diffs every day, all day. Diffs hold a lot of information that can be valuable, and I think it’s a good thing to know how to fully read a git diff.

A simple diff looks something like this:

diff --git a/example.php b/example.php
index a5174a9..11aeb84 100644
--- a/example.php
+++ b/example.php
@@ -11,7 +11,10 @@ class Greeter
         $this->name = $name;
     }
 
-    public function greet()
+    /**
+     * Return the greeting message.
+     */
+    public function greet() : string
     {
         return sprintf("Hello %s" . PHP_EOL, $this->name);
     }

This simple example holds most of the information that is needed from a diff.

The first line tells that the diff is in the git format and the filename(s) before and after the changes.

The second line tells about the type of file and its permissions (100644) and the two hashes are just that - shortened hashes of the pre- and post-images. AFAIK, this line is used when doing 3-way merges.

The lines 3 and 4 again deal with the name of the file(s). If it’s a new file, the source - --- - is /dev/null, and if an existing file was deleted, the target - +++ - will be /dev/null.

I’ll skip line 5 for a moment and come back to it later.

The next part, the actuall diff, shows what lines in the current hunk were added and what lines were removed:

         $this->name = $name;
     }
 
-    public function greet()
+    /**
+     * Return the greeting message.
+     */
+    public function greet() : string
     {
         return sprintf("Hello %s" . PHP_EOL, $this->name);
     }

Lines that start with a + sign were added, and lines with a - sign were removed. Lines with no + or - are here just to give us some context of the code. Looking at this diff we see that one line was removed and 4 lines were added.

Now back to line 5 as this is probably the hardest part to understand:

@@ -11,7 +11,10 @@ class Greeter

These numbers always seemed random to me.

This line is, I belive, called “unified diff hunk identifier”, and the format of this line is:

@@ from-file-range to-file-range @@ [header]

which to be honest, isn’t that helpful. The @ signs are just delimiters.

The first pair of numbers, -11,7, means that the current hunk in the source file starts at line 11 and has a total of 7 lines.

The starting line can be confirmed in any editor: $this->name = $name; really is the 11th line in the edited file. That’s easy.

The number 7 means that there are 7 lines in total that have a - sign or no sign at all (contextual lines). If we count the number of contextual lines and lines with a -, skipping the lines with the + at the beginning, we see the total is 7.

The second pair of numbers, +11,10 means that the current hunk in the target file starts at line 11 and has a total of 10 lines.

The number 10 means that there are 10 lines in total that have a + sign or no sign at all (contextual lines). If we count the number of contextual lines and lines with a +, skipping the lines with the - at the beginning, we see the total is 10.

Finally, class Greeter, the [header] part of this line, tells us were did the change happen. This may, or may not, be present.

This example is a simple one, but I think it covers most of the use cases of a git diff output, and it helps us understand the unified diff hunk identifier line (the line with @@s), which is useful to know, especially when editing git hunks manually.

Happy hackin’!

Tags: diff, git, hunk.
Categories: Development, Software.

Editing Vim macros

by Robert Basic on December 15, 2016.

Vim macros are a powerful thing — they let us record keystrokes and play them back later. These macros are recorded to named registers.

One thing I realised about them, is that they can be edited after they have been recorded. This is possible because macros “lives” in the register.

Say, for example, you record a macro of 20+ keystrokes, play it back, only to realize that there’s a single error in the steps. Re-recording the entire macro can be difficult. Instead, paste the contents of that register somewhere, edit it, and then yank it back to that same register.

For a simple example, let’s assume we want to add * around words. We record it to the register a by typing qa (the ^[ is the literal escape character):

bi&^[ea&^[

Play it back with @a and — oh no! that’s not a *, that’s a &!

Vim macro editing to the rescue:

:new # to open a new split
"ap # take the register named "a" and paste from it
:%s/&/*/g # replace all & with *
^v$"ay # jump to start of line, visual mode, jump to end of line, take the named register "a" and yank to it

If we now play back the macro again with @a, we see the *s wrapping the word on which the cursor was, just what we wanted.

Happy hackin’!

Tags: macro, registers, vim.
Categories: Development, Software.