DEV Community: David Llop

A Chatbot for OhDear!

David Llop — Sat, 17 Nov 2018 00:00:00 +0000

One day I tried to show a post of mine to a coworker and then I realised my website was down. I had nothing to warn me if that happens at that time and it was kinda embarrassing. Solving it was as easy as login to DigitalOcean and restart the droplet, but it looked very unprofessional.

For how long was my site down? How many people were unable to read my awesome posts?

That was when I decided that I needed some kind of automatic monitor for my website up time.

I remembered Freek tweeting about OhDear!, a new monitoring tool made by him and Mattias, and I decided to take a look.

The documentation looked awesome so I joined as a free 10 days trial to check if it was useful for me. It turned out to be the perfect solution I needed. Taking a look at the docs and learning how to use it (pretty easy indeed) I saw the API section. It ended up being a well structured and simple API. I've worked building API's and consuming them for almost 3 years in the past and I wanted to work on something new. Then this project came to my mind.

A chatbot to interact with this API. To check your website status and receive messages if something is wrong.

I always create my bots to interact just with Telegram by now, I know how it works and it's easy to test the result. This project could work with Facebook Messenger in a future, I'm not discarding that feature 🤔

Once I've installed a fresh copy of BotMan and prepare the app I realised I'd never tested code that interacts with an API that was not mine. I learned TDD and Unit Testing after that API developer period. BotMan offers a great Testing Solution to work with. In fact, it's easier to develop a chatbot with tests since you can check the result instantly.

Then I remembered a few lessons in Adam Wathan's course Test Driven Laravel regarding this matter. You create a class that will return the same payload as the API you want to integrate. Usually your Fake class will extend the current working class to override those methods that perform the actual API call. And that's what I've done for this test suite. This way I was able to develop the entire project without querying OhDear's app.

OhDear offers a PHP Open Source package to interact with their API. I needed to extend a few classes to adapt them into my needs but the rest was pretty easy.

They also have a package to interact with OhDear WebHooks, but this time I was unable to use this package. It's built to work with a secret key saved in a configuration file. My app, otherwise, it's made to interact with multiple users at a time, and each users has a different secret key. I'm currently storing that information encrypted into the database. When a webhook request is received it already contains the username. For example https://deployedbot.com/freekmurze. Then I check the payload with the user's secret key in order to proceed or return an authorization error.

I built this project using the Single Action Controllers approach and I'm pretty happy with the result, It's something I'll consider in future projects for sure.

Most of the times there are just one controller per namespace in this project. But the benefit is also visible in the routes file, since it looks neat and you can use your IDE to click on the controllers name and go directly.

When you work on a chatbot that you want to test, you have two options:

Write the message twice, in controller and tests, and remember to update both if something is modified.
Store your messages somewhere you can call in your controller and tests.

I decided to go with number 2, and also decided to store the messages in Laravel translations files. This project is not multi-lingual (for now 😉) but I think that having the messages there makes it easy to:

Refactor the message.
Read code, it's easy to see ohdear.token.stored than a whole sentence.
Test the message is sent to the user.
Re-use the message in another conversation.
Translate the whole app in a future, since you have all the texts in a single place.

This bot is currently running and you can talk to it here or by searching Mr. Dear on Telegram. You can also deploy it into your own server since it's Open Source. You would find instructions about how to do that in the README.md of the project.

Laravel Multitenancy: Route Model Binding

David Llop — Mon, 29 Oct 2018 00:00:00 +0000

Why write code like this

public function edit($articleId)
{
    $article = Article::findOrFail($articleId);

    return view('articles.edit', compact('article')); 
}

When you can simply do

public function edit(Article $article)
{
    return view('articles.edit', compact('article'));
}

I'm a huge fan of this Laravel feature since I discovered it. You just need to typehint the model in the functiondeclaration and the framework will handle the findOrFail for you. That's it.

But it has a problem though, sometimes you need to check for other fields.

Using our previous example:

public function edit($articleId)
{
    $article = Article::where('tenant_id', auth()->user()->tenant_id)->findOrFail($articleId);

    return view('articles.edit', compact('article'));
}

Would look cleaner than

public function edit(Article $article)
{
    abort_unless($article->tenant_id === auth()->user()->tenant_id);

    return view('articles.edit', compact('article'));
}

This is a common scenario. You have an app to edit articles, and you have to prevent your users to edit otherusers's articles. Basic security rule. But you don't like that kind of code you need to read twice to understand what it does at a first glance.

Well, you could use Global Scopes for sure, but they have a problem: a global scope will be applied to all the queries onthat model, no matter where in the app they occur. So when you need to query all the articles for some statistics or maintenance,you will need to add withoutGlobalScope to that query every single time.

The solution my team and I found was to override the default behaviour of Route Model Binding. Of course Laravel offers youa simple solution, you just have to override a method in your model to have it up and running.

This is the default behaviour:

/**
 * Retrieve the model for a bound value.
 *
 * @param mixed $value
 * @return \Illuminate\Database\Eloquent\Model|null
 */
public function resolveRouteBinding($value)
{
    return $this->where($this->getRouteKeyName(), $value)->first();
}

And this is what we will need to declare in our Article model:

/**
 * Retrieve the model for a bound value.
 *
 * @param mixed $value
 * @return \Illuminate\Database\Eloquent\Model|null
 */
public function resolveRouteBinding($value)
{
    return $this->where($this->getRouteKeyName(), $value)
        ->where('tenant_id', auth()->user()->tenant_id)
        ->first();
}

I know what you're about to say

But David, it's easy to understand what the code does if we check this in the controller

Yeah sure, I'll not do this for every kind of filtering like reedeming a PromoCode with an expiration date. But when youhave a multitenancy app this kind of delegation is appreciated.

I'm with the philosophy of:

A Controller should receive only Entities which it can work without checking conditionals.

I apply this rule also for Request validation using Form Requests.You'll find times in which this rule cannot be applied due to some sort of complicated and arcane checks, of course, butthat's what programming is about 🙂.

Solving my own needs with code

David Llop — Fri, 12 Oct 2018 00:00:00 +0000

I remember joining the web development studies as a way to craft something with computers, something that
is used worldwide daily. Some of my friends were telling me to join native programming or mobile apps, as
I'd be able to build apps for myself, if needed. And I remember thinking:

I can do things for myself on the web, can't I?

I started web development because I liked it back in 2012, I knew that even before writing a single line of code.
I'm happy with my current job and I'm working on some side projects at home too. Sometimes I do it to be on the edge checking out new frameworks, features, packages... But most of the time when I write code at home it's for my own use. Don't get me wrong, I also try to help other people with those projects if it's possible.

My biggest project which paid off, without any doubt, is a chatbot I use everyday to know if I'll find a bike in the city bike system I live, in Girona. I was tired of waking up, walking to the bikes station, realising there's not a single one available for me and walking back to the next station, which is not on the same route.

This bot is used by 5 other users and is open to everyone who wants to use it. I'm thinking about talking about it with more people and users I could find on the stations getting a bike.

I also developed a chatbot for getting control about your debts with friends.
You only need to add it to the chat group you have with your friends and say @friend owes me 100 or I owe 100 to @friend. The idea came when we wanted to register our debts but couldn't decide which app to use that
works for both Android and iOS. We ended up finding an app, but I decided to build this chatbot anyways as an exercise
for myself.

Some years ago, I built my own CMS (like a lot of people out there) as an experiment, and it resulted in a pretty neat tool I used to build a few websites with it and even gain some money.

I already mentioned this at the end of this previous post, but Matt Stauffer gave a talk at Laracon Online 2018 about this topic which I found pretty interesting and it encouraged me to continue doing this, for the major good and my own.

Make your Laravel Jobs multi-tenancy friendly

David Llop — Thu, 19 Jul 2018 00:00:00 +0000

Our team is working hard on a project which can connect to different databases depending on the client.
Here is the wikipedia link: multi-tenancy:

The term "software multitenancy" refers to a software architecture in which a single instance of
software runs on a server and serves multiple tenants.

So the point here is that we have a single installation of our app and depending on the user logged in, it will show the respective data.

When you send a job to a queue, Laravel serializes the class to save it using your chosen driver until a Worker can fire it.
When the job is fired, it tries to restore the models you passed in the constructor from the database using
the SerializesModel trait.

This works totally fine, but sometimes you get a non-trivial requirement, and this time it was our turn.

We don't have a connection defined for each client in config/databases.php configuration file. Instead, we have
the database name in a clients table with the other information, and each User has a client_id to create the relation.
We use a middleware at the beginning of each request to set the connection attributes in the configuration.

The problem began when we started working with jobs: due to the fact that there's no client logged in, there's no way to determine
which connection must be set up. After an intense research, and digging through the framework's code, we figured out a
solution which fitted our needs.

I'm going to show some examples with the database driver, since it's the one we chose for our app. But I'm sure you can
apply the same modifications to your driver of choice.

Our goal here is to set up each job with the connection it needs, so the job must know which client it belongs to.

This step is easy: since we use the database driver, we just need to run this command:

php artisan queue:table

Then we modify the migration file and we add our 'client_id' before migrating

Schema::create('jobs', function (Blueprint $table) {
    $table->bigIncrements('id');
    $table->string('queue')->index();
    $table->integer('client_id')->unsigned()->nullable();
    ...
});

But how will the framework know the way to correctly populate this new field whenever it dispatches a new job? This is where the tricky part starts:

In our config/app.php, we need to specify our custom QueueServiceProvider instead of Illuminate's:

'providers' => [
    ...
    Illuminate\Pipeline\PipelineServiceProvider::class,
    App\Queue\QueueServiceProvider::class,
    Illuminate\Redis\RedisServiceProvider::class,
    ...

From now on, we will organize the extended classes of Illuminate's Queue in the App\Queues namespace

This provider is very simple, it just needs to extends the original class.

namespace App\Queue;

use App\Queue\Connectors\DatabaseConnector;

class QueueServiceProvider extends \Illuminate\Queue\QueueServiceProvider
{
    protected function registerDatabaseConnector($manager)
    {
        $manager->addConnector('database', function () {
            return new DatabaseConnector($this->app['db']);
        });
    }
}

We need to override DatabaseConnector in order to use our own, which overrides connect to use our DatabaseQueue

namespace App\Queue\Connectors;

use App\Queue\DatabaseQueue;

class DatabaseConnector extends \Illuminate\Queue\Connectors\DatabaseConnector
{

    public function connect(array $config)
    {
        return new DatabaseQueue(
            $this->connections->connection($config['connection'] ?? null),
            $config['table'],
            $config['queue'],
            $config['retry_after'] ?? 60
        );
    }
}

Now we need to override the method buildDatabaseRecord to check if we have a client and, if we do,
fill up that field on the jobs table.

namespace App\Queue;

use App\Queue\Jobs\DatabaseJob;

class DatabaseQueue extends \Illuminate\Queue\DatabaseQueue
{

    protected function buildDatabaseRecord($queue, $payload, $availableAt, $attempts = 0)
    {
        $queueRecord = [
            'queue' => $queue,
            'attempts' => $attempts,
            'reserved_at' => null,
            'available_at' => $availableAt,
            'created_at' => $this->currentTime(),
            'payload' => $payload,
        ];

        if (client()) {
            $queueRecord['client_id'] = client()->id;
        }

        return $queueRecord;
    }
}

Okay, so now our jobs have a client_id assigned, the only remaining thing is...
How do we set up the client connection before a job is fired? Yes, you guessed it,
we will need to extend another Illuminate class for that

namespace App\Queue\Jobs;

use App\Models\Client;
use App\Helpers\ClientConnector;

class DatabaseJob extends \Illuminate\Queue\Jobs\DatabaseJob
{
    public function fire()
    {
        if ($this->job->client_id) {
            $client = Client::findOrFail($this->job->client_id);

            ClientConnector::connectByClient($client);
        }

        parent::fire();
    }
}

Lastly, we need to come back to our own DatabaseQueue and tell it to use our DatabaseJob instead
of Illuminate's Queue default by overriding the method marshalJob

protected function marshalJob($queue, $job)
{
    $job = $this->markJobAsReserved($job);

    return new DatabaseJob(
        $this->container, $this, $job, $this->connectionName, $queue
    );
}

The importance of test consistency

David Llop — Tue, 03 Jul 2018 00:00:00 +0000

Recently I've discovered the benefits of including feature and unit tests in my applications which helps me find bugs faster.

Today I found a small bug in one of the largest test suite our team has that I was unaware until today.

This test suite contains many tests that work with dates, like hotel bookings or daily price changes. I discovered the
issue today when the month changed from June to July, let me explain that.

The user needs to be able to modify the price each week but only on certain days, for example every weekend of September.
So the request receives a date_begin, a date_end and an array of weekdays:

/** @test */
public function only_weekdays_selected_are_created()
{
    // ... Preparing required variables and data on the database

    $this->actingAs($user)->post('/prices/create', [
        'price' => 46,
        'date_begin' => Carbon::now()->addMonth()->firstOfMonth(Carbon::MONDAY)->format('Y-m-d'),
        'date_end' => Carbon::now()->addMonth()->firstOfMonth(Carbon::FRIDAY)->format('Y-m-d'),
        'weekdays' => ['wed']
    ]);

    $this->assertDatabaseHas('price_days', [
        'day' => Carbon::now()->addMonth()->firstOfMonth(Carbon::WEDNESDAY)->format('Y-m-d'),
        'price' => 46
    ]);
}

Have you spotted the bug yet? Well, I'll write it down anyway to force myself to remember it.

The code is inserting the first Wednesday of the first complete week into database, which is August 8 2018, and the
assertion is looking for the first Wednesday, which is August 1 2018.

After refactoring a bit, the issue is resolved but it forced me to handle this kind of assertions from another point of
view. Since we are a small team of developers, and all of us needs to write tests on this project, I thought about creating
some kind of helper (it has become an easily used word in programming, don't you think?) to handle that date-stuff for us.

I decided to create a class inside the tests folder and name it TestCarbon. This name is nothing close to definitive
by the way, but is the first thing that came into my mind since it's only for testing and it's related to Carbon.

And this class looks very similar to this:


namespace Tests;

class TestCarbon
{

    public function today()
    {
        return Carbon::now();
    }

    public function firstMondayOfNextMonth()
    {
        return self::today()->addMonth()->firstOfMonth(Carbon::MONDAY);
    }

    public function firstWednesdayOfNextMonth()
    {
        return self::firstMondayOfNextMonth()->addDays(2);
    }

    public function firstFridayOfNextMonth()
    {
        return self::firstMondayOfNextMonth()->addDays(4);
    }

}

Then after refactoring the test, again, it looks like this:

/** @test */
public function only_weekdays_selected_are_created()
{
    // ... Preparing required variables and data on the database

    $this->actingAs($user)->post('/prices/create', [
        'price' => 46,
        'date_begin' => TestCarbon::firstMondayOfNextMonth()->format('Y-m-d'),
        'date_end' => TestCarbon::firstFridayOfNextMonth()->format('Y-m-d'),
        'weekdays' => ['wed']
    ]);

    $this->assertDatabaseHas('price_days', [
        'day' => TestCarbon::firstWednesdayOfNextMonth()->format('Y-m-d'),
        'price' => 46
    ]);
}

I know I know, firstWednesdayOfNextMonth is lying (at least in August 2018), but firstWednesdayInsideFirstFullWeekOfNextMonth
seemed too long for me 😅.

I showed the code to the team and they thought it was a good addition to our test suite. They started to use it with their
own tests and adding methods for returning the dates they use the most. It turned out that I had a few tests
with similar dates but not the same as the three used by TestCarbon. But with this class in mind, instead of
creating new methods for new days, I modified those tests to match this dates and they're still passing. So I was able
to remove some magic dates, so to speak, from the code.

Later, I thought about the Magic string problem and I remembered an app in
which I have a few tests interacting with strings all the time. It was about colors and they were passed
through the request like yellow, green, orange... This time though, while I was creating this TestColors class
into this test suite, I realised and thought

why I'm not using this for the main app too?

So I moved that class to a folder freely named helpers and refactored both the code in the app and the tests. Now it's
using this class which contains all the colors I need as constants such as const YELLOW = 'yellow';. This allowed
me to remove a lot of magic strings from all the application and everything looks even more consistent now.

Running old sites in Laravel Valet - Environment Variables

David Llop — Sat, 17 Mar 2018 00:00:00 +0000

A few days ago my Homestead machine decided to die and not booting again (I'm totally sure I broke something, Joe P Ferguson does an amazing job with that Vagrant machine, the 2nd most downloaded on vagrant boxes site 😱)

The thing is, I already had Laravel Valet installed in my Macbook, so I thought I could run the project on that one for this time.

But old sites usually were made with Apache server in mind and they use environment variables and htaccess (I'll talk about this in another post).

Since Valet does not currently support custom .env files, I found a few custom ways of loading the variables, but all that methods messed up with the code and I don't want to be pending of deleting those lines from index.php before committing to repository. It's too risky.

But checking out the content of this pull request I thought about a similar approach, without touching nginx configuration.

As the official documentation suggest, I created a file called LocalValetDriver.php inside the app directory with the following content

class LocalValetDriver extends LaravelValetDriver
{
    /**
     * Determine if the driver serves the request.
     *
     * @param  string  $sitePath
     * @param  string  $siteName
     * @param  string  $uri
     * @return bool
     */
    public function serves($sitePath, $siteName, $uri)
    {
        return true;
    }

    /**
     * Get the fully resolved path to the application's front controller.
     *
     * @param  string  $sitePath
     * @param  string  $siteName
     * @param  string  $uri
     * @return string
     */
    public function frontControllerPath($sitePath, $siteName, $uri)
    {
        return $sitePath.'/public/index.php';
    }
}

Then inside frontControllerPath I load the environment variables:

public function frontControllerPath($sitePath, $siteName, $uri)
{
    $this->loadEnvironmentVariables();

    return $sitePath.'/public/index.php';
}

private function loadEnvironmentVariables()
{
    // all env variables here
    putenv('VAR=value');
    ...

}

Ignoring the file from repositories (optional)

The only remaining action is to add LocalValetDriver to your global gitignore. This action will prevent this file with sensible information (and also not project-related) to be uploaded to the repository.

In case you don't have a file called .gitignore_global in your home directory, you'll need to run this command first to link it with your git configuration

git config --global core.excludesfile ~/.gitignore_global

Add LocalValetDriver.php to this file

echo "LocalValetDriver.php" >> ~/.gitignore_global

Creating a ChatBot with BotMan

David Llop — Thu, 18 Jan 2018 00:00:00 +0000

Last month I was interested in all this chatbot thing, specially in the features Google Allo has. In that messaging app, you can set a reminder to get notifications about the weather daily in the morning, or to receive jokes / fun facts at specific times.

I had a problem every day with my city bike system. The nearest station from home is used by a lot of people, and some morning there are no free bikes when I arrive there, so I need to walk to the next station (and reach late at work because I'm a lazy person and I always leave home at the last possible moment 😓).

So I thought:

What about a bot that tells you every morning the number of free bikes at a preferred station?

I checked the website of the city bike's company but it’s difficult to use from the smartphone. I needed a better way to know the information of the station every day.

I follow Marcel Pociot on Twitter for almost two years, so I decided to check what BotMan is about since I saw a lot of tweets mentioning it. It is a PHP framework to create bots in an easy way, and also installable in a Laravel app, it was the perfect solution for what I wanted to do! 🙌

A month later, I have a chatbot currently running in production and telling me each morning the number of free bikes my station has, telling me the same information about the station near work from monday to friday. I went a bit further and added a bunch of cool features:

You can share your location and the bot will show you the 3 nearest stations with a link to Google Maps to get directions (don’t worry I’m not storing that information and selling it to local companies).
You can create aliases for a station so that it is easier to ask for information. There are 19 stations right now and it’s difficult to remember all the names, so you can create aliases like gym or home to ask for information about a specific station.
I added some travel information. For example from gym to home and it will show you the availability of the two stations and the distance between them (just in a straight line, sorry guys I’m not Google 😅 ).
You can define a station as a preferred one, so every time you say hello the bot will show you the information of that station. It can’t be quicker in my opinion 🙂.

Reminders are customizable for specific days of the week or timings, and you can choose between getting information about free bikes or free parkings. They are sent using Laravel Task Scheduling feature. It’s amazing how simple it was to have it running.

This is my most enjoyable hobby project. I’m still adding features to it and planning to talk about it with other bike users. My girlfriend is already using it and has some great ideas to add as future improvements.

If you’re curious about building a chatbot or how they work, don’t hesitate to check BotMan’s website or send me a tweet, I'll help you as much as I can. 🤓

I also want to mention Matt Stauffer for his great talk at Laracon Online 2018 about side projects and enjoying what you do (You can get access to this year’s videos for just $25 (20€). I saw it live and I totally recommend watching it.

Adding View models to a Laravel project

David Llop — Mon, 01 Jan 2018 00:00:00 +0000

Since the beggining of 2017 I started to experiment with different kind of codes and patterns I didn't used before.

One of that changes came in November when I was developing the code of this other blog. I saw that I was duplicating a lot of code inside my controllers on the methods for create and edit a resource, in which I use the same blade file.

Some data of that view depends on the model I'm editing or creating. For example, if it's an existing record the title should be Edit post: {$post->title} instead of Create a post. That logic applies to the form action and form method too.

I created a main FormViewModel, and every view model dedicated to a form extends it.

abstract class FormViewModel
{

    public $model;
    public $title;
    public $action;
    public $method;

    public function __construct(Model $model)
    {
        $this->model = $model;

        $this->setTitle();

        $this->setAction();

        $this->setMethod();
    }
}

This view models are forced to declare the methods called on the constructor

protected abstract function setTitle();

protected abstract function setAction();

protected abstract function setMethod();

This is an implementation of the setTitle method in the CategoryDetailViewModel:

protected function setTitle()
{
    $this->title = $this->model->exists
        ? "Edit Category: {$this->model->name}"
        : "Create Category";
}

They can also add more logic in their own constructor, like the PostDetailViewModel:

public function __construct(Post $post)
{
    parent::__construct($post);

    $this->published_at = $this->model->exists
        ? $this->model->published_at->format('Y-m-d\TH:i')
        : Carbon::now()->format('Y-m-d\TH:i');

    $this->categories = Category::select('id', 'name')->get();
}

Using the view models is very easy, the controller only needs to pass this object to the view

public function edit(Theme $theme)
{
    return view('backend.themes.edit', [
        'view' => new ThemeDetailViewModel($theme)
    ]);
}

and the view use the object properties and methods

@section('content')
    <h1>{{ $view->title }}</h1>

    <form method="POST" action="{{ $view->action }}">
        {{ method_field($view->method) }}
        {{ csrf_field() }}
        ...
    </form>
@endsection

Hi, I'm David Llop

David Llop — Wed, 12 Jul 2017 17:18:32 +0000

I have been coding for 4 years.

You can find me on Twitter as @Lloople

I live in Girona, Spain.

I work for GNA Hotel Solutions

I mostly program in these languages: PHP, JavaScript.

I am currently learning more about Laravel, Vue, TDD, Clean Code.

Nice to meet you.