Eduardo Trujillo
1 minute

As the result of a short hacking session, I built a simple Node.js bot that forwards items from the Phabricator news feed into a Slack channel:


Phabricator supports calling POST endpoints whenever there is a new feed item (setup through the feed.http-hooks). However, we can’t just forward these directly to Slack. The main task of the bot is to take these requests from Phabricator, fetch some extra information using Conduit and the calling another webhook to deliver the message to a Slack channel.

Right now it seems to be working fine with most object types (tasks, commits, wiki pages). The only side-effect is that the bot will cause Slack notifications appear for your own actions if your username in Slack and Phabricator happen to match.

You can find the code and instructions on how to set it up on GitHub

Eduardo Trujillo
1 minute

Found a quick way of avoiding using the Schema facade for migrations in Laravel:


namespace App\Database;

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Query\Builder;

 * Class BaseMigration
 * Base migration class
 * @package App\Database
abstract class BaseMigration extends Migration
     * @var Builder
    protected $builder;

     * Construct an instance of a BaseMigration
    public function __construct()
        $this->builder = app('db')

Why? This should help with the type hinting provided by some IDEs such as PHPStorm.

To use this class, extend it from every migration you make and replace any mention of Schema:: with just $this->builder->

Eduardo Trujillo
3 minutes

For many programming languages and software packages, data structures such as linked lists and maps, and sorting algorithms like quicksort, are things that come built-in.

In terms of performance and working on higher levels, these built-in packages are a really good idea. In the case of languages like PHP, they are likely faster or better optimized than anything you could write in the language itself due to the internal being written in C.

However, when you want to look under the hood and understand a bit more what you’ve been learning in that Algorithms & Data Structures? class, programming your own data structures can be both fun and satisfying.

So that’s exactly what I ended up doing: Writing my own implementation of popular data structures and sorting algorithms in, oddly enough, PHP.

experimenting with structures

PHP is like a sweet spot between Java and JavaScript. You get an interpreted language without strict typing, but with the added benefit of OOP features like Interfaces and Traits.

The project structure is simple: a bunch of classes neatly organized into namespaces according to the concept they represent, interfaces (for future expandability), and many unit tests to back everything up.

Code quality

Working on this project also reassured me the importance of testing your code, but also of avoiding to repeating your self:

For this project I had decided to try a cool-looking site, CodeClimate, which promised to provide automated code review. Given that this is just a personal experiment and that their service is free for public repositories, I decided to give it a try.

After a few commits, their website pointed out the obvious: many of my unit tests had duplicated code. This led to think about ways of combining logic in unit tests, which is not something I have attempted to do before.

experimenting with structures2

Having setup a namespace for tests, which can be properly defined in Composer using the require-dev key, really helped in getting this done.

After identifying common logic and some refactoring, I had some abstract tests and inheritance setup, which removed most of the warnings on Code Climate, and made it simpler to write new similar tests.


Linked lists, Quicksort, Stacks, Insertion sort were all very simple and straightforward to implement, possibly thanks to the fact that they have been mentioned on many lectures back in school.

However, out of all the data structures I’ve worked on (at least at the time of writing), HashMap was the most complicated one.

I attribute this to the fact that a simple implementation of HashMaps require the use of another data structure to handle collisions and has to be able to grow and shrink depending on the load factor.

Unit testing, again, provided to be very useful since it allowed me to be sure that the HashMap class was working as I expected.

Using my testing approach, I was unable to directly test that the growing and shrinking of the HashMap’s internal array was happening correctly. Given that these are internal operations of the data structure, there are no public methods for querying the status or altering its behavior, and adding methods just for the sake of code coverage seemed wrong, almost like cheating.

So the current tests mainly tries to simulate a real-world scenario in which the HashMap has to expand and contract multiple times, while making assurances that it still works and hasn’t lost data.

Looking ahead

So far this has been an interesting exercise, and I plan to keep adding more data structures/sorting algorithms in the future just to keep my coding skills sharp.

You can take a look at the code or fork it and play with it on GitHub:


Here are some usage examples:

use Chromabits\Structures\Map\HashMap;

$map = new HashMap();

$map->set('hello', 'world');

>> true

>> 'hello'

>> ['hello' => 'world']

Basic quicksort algorithm comparing strings:

use Chromabits\Sorting\Quicksort\QuicksortSorter;
use Chromabits\Sorting\Comparators\StringComparator;

$sorter = new QuicksortSorter(new StringComparator());

$sorter->sort(['z', 'g', 'c', 'a']);
>> ['a', 'c', 'g', 'z']

…or you can find more in the archives.

Copyright © 2015-2021 - Eduardo Trujillo
Except where otherwise noted, content on this site is licensed under a Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) license.
Site generated using Gatsby.