DEV Community: Rish Pandey

How to implement preference based notifications in laravel?

Rish Pandey — Mon, 19 Apr 2021 00:00:00 +0000

A few days back, I was asked to implement a pretty awesome notification system on one of my client's laravel application, we are calling it, Granular Preference for Notifications.

So the user story goes,

A user can select if they wish to receive a notification via email, broadcast, both or neither. We have a bunch of notifications like newletter, maintenance, invitations, messages etc. Some of these are important to some users, essential for others and outright annoying to some. So, this is a pretty useful and much needed feature.

How I approached this problem?

There is actually an existing laravel package which does something similar and looks promising. I looked at the package and was going use it but instead wanted to have something custom-made for our specific use case.

I figured what we need at most is some way to edit the via() method to return the appropriate channels based on what user has set in their profile.

The documentation shows something like this as well,

/**
 * Get the notification's delivery channels.
 *
 * @param mixed $notifiable
 * @return array
 */
public function via($notifiable)
{
    return $notifiable->prefers_sms ? ['nexmo'] : ['mail', 'database'];
}

How I solved this?

I created a new abstract class classed PreferenceBasedNotification.

<?php

namespace App\Notifications;

abstract class PreferenceBasedNotification extends Notification{
    final public function via($notifiable){}
    abstract public function toMail($notifiable);
    abstract public function toBroadcast($notifiable);
}

Every notification where a user can set a preference will inherit this abstract class and will have to implement toMail() and toBroadcast() and can't implement via() to fulfill the contract.

Why toMail() and toBroadcast() are abstract? It is to make sure that if a user is opting for both mail and broadcast then the notification has to provide it. For via() being final, I decided that individual notifications can not edit the logic to check user's channel preference.

Database Setup

I used two tables to achieve this, one keeps tracks of all the notifications where user can set a preference.

preference_based_notifications

| event_text | description | notification_class |
|-------------|-------------|------------------------|
| New Message | ... | NewMessageNotification |
| New Event | ... | NewEventNotification |

user_notification_preferences

| notification_id | user_id | receive_email | receive_notification |
|-----------------|---------|---------------|----------------------|
| 1 | 1 | true | false |
| 2 | 1 | true | true |

Implementing the via() method

Now the only thing left to do is to implement via(). This method has to check for user preference and based on that return appropriate channel.

final public function via($notifiable)
{
    $viaChannels = [];
    $preference = $this->getPreference($notifiable->user_id);

    if ($preference->receive_email) {
        $viaChannels[] = 'mail';
    }
    if ($preference->receive_notification) {
        $viaChannels[] = 'broadcast';
    }

    return $viaChannels;
}

We can implement a method to check user's preference like this,

private function getPreference($userID)
{
    // get_class returns the class name with namespace
    // we need to get extract class name

    $currentClass = Arr::last(explode('\\', get_class($this)));

    $event = DB::table('notification_events')
        ->where('notification_class', $currentClass)->first();

    if (!$event) {
        return null;
    }

    return DB::table('user_notification_preferences')
        ->where('user_id', $userID)
        ->where('notification_event_id', $event->id)
        ->first();
}

And that's it. We can now look into the user_notification_preferences table and send notifications based on the user's choice.

You can checkout the gist here.

How to add approx read time on posts in Jigsaw?

Rish Pandey — Tue, 12 Jan 2021 00:00:00 +0000

My current blog is developed using Jigsaw and their awesome template.

Jigsaw is a framework for rapidly building static sites using the same modern tooling that powers your web applications.

I absolutely love the design and made little to no changes on it. One thing I very much needed is to show read time on each article. This is how I accomplished it.

Add a new helper in config.php.

'getReadTime' => function ($page, $wpm = 150) {
        $content = strip_tags($page->getContent());
        $word_count = str_word_count($content);
        return ceil($word_count / $wpm);
    }

Use the helper in post-preview-inline.blade.php. In blog template this file is used to give an inline preview of posts.

 <a
    href="{{ $post->getUrl() }}"
    title="Read more - {{ $post->title }}"
    class="uppercase font-semibold tracking-wide mb-2"
    >
    {{ $post->getReadTime() }} Minutes Read 
</a>

Don't see only what you want to see

Rish Pandey — Tue, 14 Jul 2020 00:00:00 +0000

People have strong opinions. Some people are more passionate than others in their values and beliefs, but everyone has them. Making rational decisions where the emotion is strong is hard, overlooking the facts that don’t agree with our values is very often the default mode.

The scientific term for this behavior is Confirmation Bias. A tendency to favor or look for information that supports one’s personal belief, a very common cognitive bias.

Take the example of Ed. He is a person with low self-esteem.

Any person who sends a text and doesn’t get a reply thinks the other party must be busy. In this situation, Ed thinks that the other person doesn’t like him and chose to not reply.

He is biased towards thinking bad about himself and will believe the occurrence or a piece of information that supports his existing belief. For Ed, neglect is the obvious conclusion where ignorance seems apparent.

The same behavior goes to show why eyewitnesses are considered unreliable. The Innocence Project researchers have reported that 73% of the 239 convictions overturned through DNA testing were based on eyewitness testimony, source.

A neighbor who doesn’t care for dogs and thinks dogs are dangerous sees a vicious dog attack an innocent child. A bystander who loves dogs sees the dog defending itself against a menacing child. Neither eyewitness account is reliable due to confirmation bias.

So, what to do?

The first thing is to address that you may have confirmation bias where you have strong opinions.
Be careful and educate yourself when making your mind about things in those areas.
Go out into the world, discuss your thoughts with others. Surround yourself with a diverse group of people, and don’t be afraid to listen to dissenting views.Challenge yourself with disagreements and fruitful dialogs.

The true sake of an argument is to educate everyone involved in it.

Why do we have leap years?

Rish Pandey — Wed, 17 Jun 2020 00:00:00 +0000

How to check if a year is a leap year?

(year % 400 === 0 || (year % 4 === 0 && year % 100 !== 0));

What it means?

Every 4th year is a leap year, except it’s not every 100th year, except it is every 400th year.

But, why?

Leap years exist because the Earth rotates about 365.242375 times a year. We have 365 days in a normal year and this leads to 0.242375 days extra. 29th Februrary exists to make up for this fraction.

So, every 4th year we add an extra day, which makes 366 days that year and 365.25 days on average. Now, we went over the actual figure by 0.007625 days, which is almost a day every 131 years.
So, every 100 years we need to skip the leap day and that means we have (366 * 24) + (365 * 76) per 100 years or 365.24 days per year. We are still lacking 0.002375 days per year. The error is small, almost a day every 421 years. This is still not small enough.
So, every 400 years we add a leap day, which takes us to (366 * 97) + (365 * 303) per 400 years or 365.2425 days per year.

Now the difference is too low and it will take 8000 years when the total difference leads to an error of single day.

Why not go further?

Due to several reasons like the tidal acceleration of sun and moon which slows the rotation of the earth. The actual rotation time of 365.242375 days will have changed by an amount which can not be accurately predicted. And this is accurate enough for most practical purposes.

Stick to your stack

Rish Pandey — Fri, 12 Jun 2020 00:00:00 +0000

In the book, the pragmatic programmer, there is a section where the author compares a programmer to a craftsman. The craftsman or artisan mindset is a great way of thinking about our work. An artisan stands by her choices and work just like we must. Every artisan needs her favorite tools to do their finest work, as we programmers need our favorite programming languages, our editors and our stack.

But, we programmers are fickle creatures and our whole industry is always gawking at another next best thing which is supposed to solve every programmer itch. Every day, we have ten new frameworks (and not enough good libraries). This trend makes us question our own choices so much that if we don’t take up anything new in a few months, it feels like we are getting left behind.

Don’t get me wrong, we need to stay on top of the current technology. But it’s pointless to try and catch up to every new popular thing. What’s more important is, using a stack that you know well, will not let you forgive yourself when you cut corners or make bad structure choices. By allowing us to try new things every time, we start to think that a project is more about learning and less about perfection. And, we let ourselves off the hook and not hold us accountable for the quality of the project.

I know your usual stack may feel boring and stale, the new thing surely looks very fun. It’s good to have fun and learn. There’s always a small chance that a new technology is better for you and for the things you are making right now. But you should know the tradeoffs.

Always staring at documentation for the new thing you are trying out of FOMO is just not productive.

Why should you refactor?

Rish Pandey — Mon, 08 Jun 2020 19:22:00 +0000

You have been working on this feature for a long time. When the client pitched this great new addition, you felt this would take a week. And here you are working on a Saturday and nothing feels right. You start to question everything about your career choices, the impostor syndrome kicks in.

Maybe you are not as great as you think (many of us are not).

It’s not you, it’s Technical Debt

“Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt.”

Martin Fowler

Most of our work as programmers is paved by the need of stakeholders. The client usually wants something at the last moment and the conversation ends with, “just get it done before Y (an unimaginable deadline) or we will start loosing money”.

You need to opt for the “quick way”.

This is the curse of our craft, we have to make compromises that we know will come back to bite us (or another one of us) in the ass. These compromises allow us to meet the client’s deadline and save them money for now. Congratulations, the code is a step closer to a maintenance nightmare now.

You will surely be entertained when the next feature request comes in.

A few years go by. You keep adding features, layer upon layers of new code. Everything built upon the same code base, inheriting every misused design pattern and reflecting all your bad design choices. You are at the mercy of technical debt, if the interest rate is low it slow you down by days or weeks. If the rate is high, maybe you can’t even implement the feature without a rewrite.

Pay the Debt with Refactoring

“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.”

Martin Fowler

Fear not Padavan, refactoring is the way we can repay this debt. Just like any other loan, we keep paying the debt via refactoring and get to keep our sanity.

To get started just remember the boy scout’s rule. Leave your code better than you found it. Make small, incremental changes that leave the code in a better state than it was found.

You should get started with this by,

Naming your variables and functions well.
Extracting each step of logic into a function.
Keeping it DRY and removing duplicate code.