Robert Basic's blog

Archive for the 'Programming' category

Events in a Zend Expressive application

by Robert Basic on August 04, 2016.

Three weeks ago I wrote a post on how to utilize Tactician in a Zend Expressive application. Today I want to expand on that post a little by adding the possibility to trigger and listen to events using the Zend EventManager component.

Using events allows our application to respond to different events that occur during a request. For example, when a user registers a new account, our application can trigger an event, UserRegistered, that can let the rest of our application know when a new registration happens. With the help of the EventManager we attach listeners to that event. When the UserRegistered event is triggered, the event manager will invoke all the listeners that are listening to that particular event.

This allows for a better separation of concerns in some cases, because if we take this approach, our code that deals with registering new users doesn’t care any more what happens after that — do we send out a welcoming email to the user, a notification to the site admins, create a log entry somewhere… It just registers a new account, triggers the event and that’s it.

Let’s see some code

As I mentioned earlier, this post expands on my previous post, so all we are going to add is an event that gets triggered when the Ping command is handled, an event listener that listens to that event and wire it all together with the event manager.

Let’s include the Zend EventManager in our project with composer:

$ composer require zendframework/zend-eventmanager

Next we expand the factory for the Ping command handler. We create an EventManager object that we will pass to the Ping command handler, so that we can trigger events:

src/App/CommandHandler/PingFactory.php

diff --git a/src/App/CommandHandler/PingFactory.php b/src/App/CommandHandler/PingFactory.php
index e995d1a..0737631 100644
--- a/src/App/CommandHandler/PingFactory.php
+++ b/src/App/CommandHandler/PingFactory.php
@@ -3,6 +3,7 @@
 namespace App\CommandHandler;
 
 use Interop\Container\ContainerInterface;
+use Zend\EventManager\EventManager;
 
 class PingFactory
 {
@@ -10,6 +11,11 @@ class PingFactory
     {
         $logPath = '/tmp/ping-command.log';
 
-        return new Ping($logPath);
+        $events = new EventManager();
+        $events->setIdentifiers([
+            Ping::class
+        ]);
+
+        return new Ping($logPath, $events);
     }
}

Later on we will use the same event manager to attach event listeners to our events.

In the Ping command handler we use the event manager, that we pass in as a constructor argument from the ping command handler factory, to trigger events:

src/App/CommandHandler/Ping.php

diff --git a/src/App/CommandHandler/Ping.php b/src/App/CommandHandler/Ping.php
index 538e3af..9768738 100644
--- a/src/App/CommandHandler/Ping.php
+++ b/src/App/CommandHandler/Ping.php
@@ -2,15 +2,19 @@
 
 namespace App\CommandHandler;
 
+use Zend\EventManager\EventManagerInterface;
 use App\Command\Ping as PingCommand;
 
 class Ping
 {
     private $logPath;
 
-    public function __construct($logPath)
+    private $events;
+
+    public function __construct($logPath, EventManagerInterface $events)
     {
         $this->logPath = $logPath;
+        $this->events = $events;
     }
 
     public function __invoke(PingCommand $pingCommand)
@@ -18,5 +22,12 @@ class Ping
         $commandTime = $pingCommand->getCommandTime();
 
         file_put_contents($this->logPath, $commandTime . PHP_EOL, FILE_APPEND);
+
+        $params = [
+            'command_time' => $commandTime,
+            'event_time' => time(),
+        ];
+
+        $this->events->trigger('ping_command_handled', $this, $params);
     }
}

The main part is the call to the trigger method on the event manager. The first argument, ping_command_handled, is the event’s name. We will use that event name to attach to it later. The second argument is the target of the event and usually it’s the object instance that triggers the event. Finally with the third argument we can send out optional parameters with the event which we can access in our event listeners.

Even though we have no listeners attached to the event, our application will continue to work perfectly fine, because an event is not required to have any listeners. It doesn’t make much sense to have events without listeners, but it wouldn’t break our application.

Shhh… Listen!

The simplest way to attach a listener to the event would be to tell the event manager to call a callable every time the event is triggered. This would also mean we need to set up any and all dependencies our event listeners have, at the moment of attaching the listener to the event, even though the event can end up not being triggered at all. All that dependency set up can be costly and wasteful.

Zend EventManager comes with lazy listeners that allows to fetch event listeners from a container-interop compatible container. This lets us to set up the dependency graph for an event listener in a factory, which will be invoked by the lazy listener only when the event we are listening to is triggered. If the event is triggered, the lazy listener will fetch the event listener from the container along with it’s dependencies, but if the event is not triggered, nothing will happen. Super useful!

Let’s attach our event listener to the event using the lazy listener:

src/App/CommandHandler/PingFactory.php

diff --git a/src/App/CommandHandler/PingFactory.php b/src/App/CommandHandler/PingFactory.php
index 0737631..5ce9c7e 100644
--- a/src/App/CommandHandler/PingFactory.php
+++ b/src/App/CommandHandler/PingFactory.php
@@ -4,6 +4,7 @@ namespace App\CommandHandler;
 
 use Interop\Container\ContainerInterface;
 use Zend\EventManager\EventManager;
+use Zend\EventManager\LazyListener;
+use App\EventListener\Ping as PingEventListener;
 
 class PingFactory
 {
@@ -16,6 +17,13 @@ class PingFactory
             Ping::class
         ]);
 
+        $lazyListener = new LazyListener([
+            'listener' => PingEventListener::class,
+            'method' => 'onPingCommandHandled',
+        ], $container);
+
+        $events->attach('ping_command_handled', $lazyListener);
+
         return new Ping($logPath, $events);
     }
}

We create a new LazyListener object and as the first argument to it we pass an array with the actual event listener and method that will be called when the event is triggered. The second argument is the container-interop compatible container, which knows how to build our event listener.

After that we attach the lazy listener to the events we are interested in, in this case the event called ping_command_handled. Once that event gets triggered, the lazy listener will get our PingEventListener from the container and call the onPingCommandHandled method on it.

Let’s quickly tell the container how to create our event listener:

config/autoload/dependencies.global.php

diff --git a/config/autoload/dependencies.global.php b/config/autoload/dependencies.global.php
index 794304e..cf47c99 100644
--- a/config/autoload/dependencies.global.php
+++ b/config/autoload/dependencies.global.php
@@ -21,6 +21,7 @@ return [
             Helper\UrlHelper::class => Helper\UrlHelperFactory::class,
             'CommandBus' => App\CommandBusFactory::class,
             App\CommandHandler\Ping::class => App\CommandHandler\PingFactory::class,
+            App\EventListener\Ping::class => App\EventListener\Ping::class,
         ],
     ],
];

And finally our event listener looks something like this:

src/App/EventListener/Ping.php

<?php
namespace App\EventListener;
use Interop\Container\ContainerInterface;
use Zend\EventManager\Event;
class Ping
{
    public function __invoke(ContainerInterface $container)
    {
        // Grab some dependencies from the $container
        // And return self
        return new self();
    }

    public function onPingCommandHandled(Event $event)
    {
        // Do something with the $event here
        $name = $event->getName();
        $target = $event->getTarget();
        $params = $event->getParams();
    }
}

When the container grabs our event listener the __invoke method will be invoked at which point we can grab the event listener’s dependencies from the container. Once the event listener object is created, the onPingCommandHandled method will be called by the event manager when the event is triggered.

Happy hackin’!

Tags: container, event listener, event manager, events, php, zend expressive, zf.
Categories: Development, Programming.

Missing colors for PHPUnit

by Robert Basic on July 20, 2016.

I ran accross a minor issue today that I never experienced before. The colors for the PHPUnit’s output were missing. I had the colors=true directive set in the phpunit.xml configuration file, but the output was just black and white.

Turns out I was missing the posix extension, which is provided by the php-process package on Fedora. After installing it:

$ sudo dnf install php-process

all was good again in the world of unit testing.

Oh well.

Happy hackin’!

Tags: php, phpunit.
Categories: Development, Programming, Software.

Using Tactician in a Zend Expressive application

by Robert Basic on July 13, 2016.

I spent some time connecting the dots last week, so I decided to put together an example on how to get started with using Tactician in a Zend Expressive application. The example itself is not really useful, but it does show how to setup the dependencies and get started with these two libraries.

Zend Expressive is a PSR7 compatible microframework that provides interfaces for routing, DI containers, templating and error handling. It provides a couple out of the box, so you can either use those, or write your own implementations.

Tactician is a command bus library whose goal is to make using the command pattern easy to use in your applications. It allows to have an object that represents a command, pass it on to the command bus which will figure out which command handler should take care of that command.

Let’s dive in

To get up and running quickly with Zend Expressive we can create a skeleton application. It does some basic wiring for us, like setting up the routing and the DI container.

It also comes with a dummy ping action, at /api/ping, which just gives us the current unix timestamp. This example is going to expand on that and create a Ping command that will be handled by a Ping command handler. The command handler will get some additional dependencies from the container, just to make the example a bit more interesting.

Creating the skeleton application is really easy with Composer:

$ cd /var/www
$ composer create-project zendframework/zend-expressive-skeleton tactician-example

Bring in the Tactician and the tactician-container plugin as project dependencies. The tactician-container plugin allows us to lazy load command handlers from a container-interop compatible container:

$ composer require league/tactician
$ composer require league/tactician-container

Now that we have all our libraries in, let’s change how the container creates the Ping action. Before it was being just invoked by the container, but now we want to create it through a factory:

config/autoload/routes.global.php

diff --git a/config/autoload/routes.global.php b/config/autoload/routes.global.php
index 856f5ab..8335450 100644
--- a/config/autoload/routes.global.php
+++ b/config/autoload/routes.global.php
@@ -4,10 +4,10 @@ return [
     'dependencies' => [
         'invokables' => [
             Zend\Expressive\Router\RouterInterface::class => Zend\Expressive\Router\FastRouteRouter::class,
-            App\Action\PingAction::class => App\Action\PingAction::class,
         ],
         'factories' => [
             App\Action\HomePageAction::class => App\Action\HomePageFactory::class,
+            App\Action\PingAction::class => App\Action\PingFactory::class
         ],
     ],

This will allow us to pass in dependencies to the PingAction class.

The Ping action’s factory is simple:

src/App/Action/PingFactory.php

<?php

namespace App\Action;

use Interop\Container\ContainerInterface;

class PingFactory
{
    public function __invoke(ContainerInterface $container)
    {
        $commandBus = $container->get('CommandBus');

        return new PingAction($commandBus);
    }
}

We are telling the container to get the service called CommandBus and pass it as an argument to the Ping action’s constructor.

Wiring in Tactician

We haven’t yet defined the CommandBus service, so let’s do that next by telling the service manager to create the CommandBus using the App\CommandBusFactory factory:

config/autoload/dependencies.global.php

diff --git a/config/autoload/dependencies.global.php b/config/autoload/dependencies.global.php
index b2b08f5..460c045 100644
--- a/config/autoload/dependencies.global.php
+++ b/config/autoload/dependencies.global.php
@@ -19,6 +19,7 @@ return [
         'factories' => [
             Application::class => ApplicationFactory::class,
             Helper\UrlHelper::class => Helper\UrlHelperFactory::class,
+            'CommandBus' => App\CommandBusFactory::class
         ],
     ],
 ];

This factory sets up the Tactician’s command bus and is the main point of this example:

src/App/CommandBusFactory.php

<?php

namespace App;

use League\Tactician\CommandBus;
use League\Tactician\Handler\CommandHandlerMiddleware;
use League\Tactician\Container\ContainerLocator;
use League\Tactician\Handler\CommandNameExtractor\ClassNameExtractor;
use League\Tactician\Handler\MethodNameInflector\InvokeInflector;
use Interop\Container\ContainerInterface;

class CommandBusFactory
{
    public function __invoke(ContainerInterface $container)
    {
        $inflector = new InvokeInflector();

        $commandsMapping = [];
        $locator = new ContainerLocator($container, $commandsMapping);

        $nameExtractor = new ClassNameExtractor();

        $commandHandlerMiddleware = new CommandHandlerMiddleware(
            $nameExtractor,
            $locator,
            $inflector
        );

        $commandBus = new CommandBus([
            $commandHandlerMiddleware
        ]);

        return $commandBus;
    }
}

Tactician uses a command handler middleware to handle commands. That middleware in turn uses a name extractor to get the command name out of a command, a locator to find the actual command handler and an inflector to figure out the method to call on the command handler to handle the command. Tactician’s middleware system is nicely described in the documentation.

The ClassNameExtractor will extract the command name from the class name.

The ContainerLocator will use our container-interop compatible container to find the command handler, which in this example is Zend ServiceManager.

The InvokeInflector dictates that the command handler needs to have an __invoke method which will get our Ping command as an argument and then it’s up to the Ping command handler to handle the command.

The $commandsMapping array that we are passing to the locator is going to be a map of commands and their handlers. We’ll populate that later on.

In the next step, let’s tell the PingAction’s constructor to accept the command bus:

src/App/Action/PingAction.php

diff --git a/src/App/Action/PingAction.php b/src/App/Action/PingAction.php
index ea2ae22..612fb32 100644
--- a/src/App/Action/PingAction.php
+++ b/src/App/Action/PingAction.php
@@ -5,9 +5,15 @@ namespace App\Action;
 use Zend\Diactoros\Response\JsonResponse;
 use Psr\Http\Message\ResponseInterface;
 use Psr\Http\Message\ServerRequestInterface;
+use League\Tactician\CommandBus;

 class PingAction
 {
+    public function __construct(CommandBus $commandBus)
+    {
+        $this->commandBus = $commandBus;
+    }
+
     public function __invoke(ServerRequestInterface $request, ResponseInterface $response, callable $next = null)
     {
         return new JsonResponse(['ack' => time()]);

Cool, at this point we have everything set up to start sending and handling commands.

Commands and their handlers

The command we are going to create is a simple one:

src/App/Command/Ping.php

<?php

namespace App\Command;

class Ping
{
    private $commandTime;

    public function __construct()
    {
        $this->commandTime = time();
    }

    public function getCommandTime()
    {
        return $this->commandTime;
    }
}

It just sets the command time to the current unix timestamp.

Updating the PingAction to include the creation of our Ping command and passing it on to the command bus to be handled:

src/App/Action/PingAction.php

diff --git a/src/App/Action/PingAction.php b/src/App/Action/PingAction.php
index 612fb32..6cb9334 100644
--- a/src/App/Action/PingAction.php
+++ b/src/App/Action/PingAction.php
@@ -6,6 +6,7 @@ use Zend\Diactoros\Response\JsonResponse;
 use Psr\Http\Message\ResponseInterface;
 use Psr\Http\Message\ServerRequestInterface;
 use League\Tactician\CommandBus;
+use App\Command\Ping as PingCommand;

 class PingAction
 {
@@ -16,6 +17,11 @@ class PingAction

     public function __invoke(ServerRequestInterface $request, ResponseInterface $response, callable $next = null)
     {
-        return new JsonResponse(['ack' => time()]);
+        $pingCommand = new PingCommand();
+        $time = $pingCommand->getCommandTime();
+
+        $this->commandBus->handle($pingCommand);
+
+        return new JsonResponse(['ack' => $time]);
     }
 }

Now is the time to let Tactician know about our command and command handler mapping, so it knows which handler handles which command:

src/App/CommandBusFactory.php

diff --git a/src/App/CommandBusFactory.php b/src/App/CommandBusFactory.php
index ba587f6..b79fbb1 100644
--- a/src/App/CommandBusFactory.php
+++ b/src/App/CommandBusFactory.php
@@ -9,13 +9,18 @@ use League\Tactician\Handler\CommandNameExtractor\ClassNameExtractor;
 use League\Tactician\Handler\MethodNameInflector\InvokeInflector;
 use Interop\Container\ContainerInterface;

+use App\Command\Ping as PingCommand;
+use App\CommandHandler\Ping as PingCommandHandler;
+
 class CommandBusFactory
 {
     public function __invoke(ContainerInterface $container)
     {
         $inflector = new InvokeInflector();

-        $commandsMapping = [];
+        $commandsMapping = [
+            PingCommand::class => PingCommandHandler::class
+        ];
         $locator = new ContainerLocator($container, $commandsMapping);

         $nameExtractor = new ClassNameExtractor();

We’re almost there. I promise.

The command handler is going to be created through a factory, so we can inject dependencies into it:

src/App/CommandHandler/PingFactory.php

<?php

namespace App\CommandHandler;

use Interop\Container\ContainerInterface;

class PingFactory
{
    public function __invoke(ContainerInterface $container)
    {
        $logPath = '/tmp/ping-command.log';

        return new Ping($logPath);
    }
}

It doesn’t do much, it just passes a path to a log file. Of course, in real code, you’d probably pass in some dependency gotten from the container.

The command handler won’t do much either, it’s just going to log the the ping’s command time in the log file we passed in from the command handler factory:

src/App/CommandHandler/Ping.php

<?php

namespace App\CommandHandler;

use App\Command\Ping as PingCommand;

class Ping
{
    private $logPath;

    public function __construct($logPath)
    {
        $this->logPath = $logPath;
    }

    public function __invoke(PingCommand $pingCommand)
    {
        $commandTime = $pingCommand->getCommandTime();

        file_put_contents($this->logPath, $commandTime . PHP_EOL, FILE_APPEND);
    }
}

And finally let the service manager know how to create the Ping command handler:

config/autoload/dependencies.global.php

diff --git a/config/autoload/dependencies.global.php b/config/autoload/dependencies.global.php
index 460c045..2c8e3ee 100644
--- a/config/autoload/dependencies.global.php
+++ b/config/autoload/dependencies.global.php
@@ -19,7 +19,8 @@ return [
         'factories' => [
             Application::class => ApplicationFactory::class,
             Helper\UrlHelper::class => Helper\UrlHelperFactory::class,
-            'CommandBus' => App\CommandBusFactory::class
+            'CommandBus' => App\CommandBusFactory::class,
+            App\CommandHandler\Ping::class => App\CommandHandler\PingFactory::class
         ],
     ],
 ];

Navigating to /api/ping should display the {“ack”:1468171544} response, and the log file at /tmp/ping-command.log should have the same timestamp logged.

That was a lot of code

I know, looks like an awful lot of code just to log a timestamp in a file somewhere. But the point is that even for more complicated commands and handlers the basic wiring stays the same — create the CommandBus factory, set up mapping of commands and handlers and the rest is pretty much the business logic of the application.

Happy hackin’!

P.S.: I’m trying out this new way of providing code samples by using diffs, so it’s easier to follow what changed where. Let me know how it looks, thanks!

Tags: command bus, container, php, tactician, zend expressive, zf.
Categories: Development, Programming.

Creating a PostgreSQL user in Vagrant with Ansible

by Robert Basic on June 28, 2016.

Lately I’ve been playing around with provisioning a PostgreSQL server with Ansible in a local Vagrant machine that runs a Fedora 23 image.

The first task after installing and starting the PostgreSQL server is to create a database user and a database. So far I have found an ugly way, a really ugly way and a nice way to do this.

How it should be done

The proper way to do this would be to use the postgresql_user Ansible module and the become, become_user and become_method directives, like so:

- name: Create a PostgreSQL database user
  postgresql_user: name=project password=project role_attr_flags=CREATEDB state=present
  become: yes
  become_user: postgres
  become_method: sudo

But this fails because sudo expects us to enter the password:

TASK [postgresql : Create user] ************************************************
fatal: [default]: FAILED! => {"changed": false, "failed": true, "module_stderr": "", "module_stdout": "sudo: a password is required\r\n", "msg": "MODULE FAILURE", "parsed": false}

You can read more about privilege escalation in Ansible in their documentation.

The really ugly way

This solution is so bad I’m not even sure I should write it down. It depends on changing the default identification method for local connections from peer to the trust method, so we can use the default vagrant user to create new users without any checks, based only on, well, trust.

- name: Change peer identification to trust
  shell: /bin/sed -i '/^local/s/peer/trust/' /var/lib/pgsql/data/pg_hba.conf
  notify: restart dbserver

- meta: flush_handlers

- name: Create a PostgreSQL database user
  postgresql_user: name=project password=project role_attr_flags=CREATEDB state=present

- name: Change trust identification back to peer
  shell: /bin/sed -i '/^local/s/trust/peer/' /var/lib/pgsql/data/pg_hba.conf
  notify: restart dbserver

- meta: flush_handlers

This is just bad, there must be a better way.

The less ugly way

But still ugly. This is based on running a psql command using the shell Ansible module.

- name: Create a PostgreSQL database user
  shell: sudo -u postgres bash -c "psql -c \"CREATE USER project WITH CREATEDB PASSWORD 'project';\""

This one has an additional problem of that it only works when we run it for the first time, because we can’t create the same user twice. A possible solution would be to wrap the CREATE USER ... in an additional IF NOT EXISTS (SELECT * FROM pg_catalog.pg_user ... query, but that’s just… Ugh. No.

Back to square one

Let’s go back to the way how it should be done, by using the become and become_user directives. But how do we handle the sudo password? We tell sudo to not ask for a password by editing the /etc/sudoers files. The line to add is:

vagrant ALL=(postgres) NOPASSWD:/bin/sh

This tells sudo that the user vagrant on ALL hosts can run the /bin/sh program with NOPASSWD as the user postgres. I’m explicitly limiting the possible commands to /bin/sh as that is the only command we need to be able to run to make things work. I don’t want to add more if I don’t need to.

The Ansible tasks are now:

- name: Enable passwordless sudo
  lineinfile: dest=/etc/sudoers regexp=^vagrant line="vagrant ALL=(postgres) NOPASSWD:/bin/sh"

- name: Create a PostgreSQL database user
  postgresql_user: name=project password=project role_attr_flags=CREATEDB state=present
  become: yes
  become_user: postgres
  become_method: sudo

For added bonus we can cleanup the sudoers file after we are done by removing the line we added.

Happy hackin’!

P.S.: If you want to use a good quality Ansible role for PostgreSQL take a look at this one. Thanks to Gilles Cornu for pointing it out!

Tags: ansible, postgresql, provisioning, vagrant.
Categories: Development, Programming, Software.

Helping juniors debug

by Robert Basic on June 23, 2016.

These days I spend most of my time reviewing code. Lots and lots of code. It’s mostly written by juniors and some of it is good, some of it is bad. I try to be patient, to be a good mentor, to hopefully teach (and be taught), while not letting out of sight that the most important thing is that the code does the right thing in the right way. The business and the users come first, after all.

When I encounter a piece of code that looks like a bug, I run the code myself to verify it. After that I usually ask a short question, something like “Hey, what does this code do? I think there’s a bug in it”. There are times when the author figures it out on their own and fixes it, or asks for help. If the former, great, if the latter, I either give them some time to figure it out on their own, or help them debug it — depending on the difficulty of the bug.

What I don’t do is outright tell them what the bug is, or even worse, how to fix it without giving them the chance to understand the bug. How are they going to learn like that?

Granted, guiding them through the entire debugging process can be slow and difficult, so this might not be a good approach when the deadline is close.

I do believe that taking the time to guide them can be rewarding for all parties involved. They get to learn by doing, get an insight on how a more senior developer works and thinks, and I, the very least, get to improve my communication skills by being forced to explain my thought process in words.

What are you trying to do?

That’s usually my first question. It’s important to understand what they think is going on, so I can guide them better. It also prevents me from assuming they know something that might be fundamental knowledge for a senior, but not so much for a junior.

My end goal is not just to fix a bug, but to actually teach, help them understand what is going on, so the next time they can fix the bug on their own, or prevent it from happening in the first place.

What does the code do?

Next thing I ask for is an explanation of the code, line by line if needed. This is probably the slowest part of this process, but I think it is necessary as it can point out places where their knowledge is lacking. They might don’t understand a language feature, misread how an internal API method needs to be called, think that the code does one thing, but actually it does something else, because hey! that’s how it works. And we’ve all been in a situation when we misunderstood something. It’s OK. Our job is to teach them, just as we were taught.

During this part I try to not interrupt them, I let them finish. I keep track of all the bits they got wrong and go back to those one by one once they are done with explaining the code.

Again I try not to flat out tell them what they got wrong, but to guide them to the correct answer. Asking simple questions like “Are you sure that it’s doing what you think it’s doing?”, or “Have you read the manual entry for that method call?” can be at times enough to make them see their mistake. “Oh, I’m passing a string and it should have been an array!” (side note: PHP 7 can’t come soon enough to all of our projects).

If they just don’t know what they got wrong, explain it to them. Don’t try to skip over any parts that might seem obvious to you — it might not be so obvious for them.

Rinse and repeat for all the parts they got wrong.

Let’s find that bug

Now when they have a better understanding of the code, ask them to find the root cause of the bug. I repeat myself, but guiding them to the moment of discovery is much better than just leading them straight to the answer. Let them have their “A-ha!” moment. I know those moments are the best moments for me.

At this point they should be able to tell you what be a good fix for the bug. If it’s a good fix, great. If not, ask them something like “Do you think doing X would be a better approach?” and explain why it would be.

This is a long process that can take up quite some time, even up to an hour or an hour and a half. You’ll probably need to do it more than once because, well, there are many types of bugs and not all bugs can be debugged the same way, but it is going to be rewarding for both you and the junior. And the more you do it, the faster it will be.

Until one day when they will be teaching the next junior on the team how to debug.

Tags: debugging, mentoring, teaching.
Categories: Development, Programming.