DEV Community: Gabriel Oliveira

How integers are stored in memory

Gabriel Oliveira — Mon, 29 Jan 2024 00:38:38 +0000

This will be a brief explanation of how integers are stored in memory, but let's get started.

The storage of integers in memory depends on various factors, including the programming language, hardware architecture, and the specific type of integer (e.g, 8-bit, 16-bit, 32-bit, 64-bit).

First, let's understand what's the difference between these types of integers (8-bit, 16-bit, etc...).

This difference refers to the number of bits used to represent each integer value.

Okay, but what is a bit?

A Bit is the smallest unit of information that can be stored or transmitted in a computer, a bit can only take 2 values 0 and 1.

Now let's think what a 8-bit integer means.

This type of integer can take values between 0 and 255 because this is only the values that can be represented with 8 bits.

00000000 -> 11111111

One thing to keep in mind is that is about Unsigned Integers.

Okay, again, WTF is this?

Unsigned Integers means that all the bits are used to represent values, without reserving one bit to the signal (positive or negative), so signed integers are the opposite.

Which values 8-bit signed integer can take?

Let's think, if we lose one bit to store the value, we lost some numbers.

8-bit signed integers can store numbers between -128 -> 127.

// in rust 'u8' type means unsigned integer of 8 bits

let number: u8 = 0; // ok
let number: u8 = 255; // ok
let number: u8 = -1; // not okay

I believe that by understanding these concepts, such as signed and unsigned integers and why there are 8-bit, 16-bit... integers, is a good basis for understanding how computers store these values.

Thanks for reading this far and bye! keep studying!

Fake Facade in Laravel

Gabriel Oliveira — Tue, 26 Dec 2023 21:13:27 +0000

Generally, when we work with services within our application that interact with the external world, for example: Sending emails, queued processing, payment providers, it can end up making it difficult to implement automated tests in our application, it is slow and unfeasible to trigger all emails Once your tests run, make a request to a payment gateway, trigger a job to your real queue.

In this article I will talk about an implementation pattern that gets around this problem by facilitating the implementation of automated tests with an example of a payment provider implementation.

What is a Facade?

Facade is a design pattern that allows us to implement a simple interface to abstract a complex system.

Laravel Examples

Mail
Queue

As users of the framework, we do not need to implement email triggering functionality from scratch, queue management, connection to the Database, this is already well abstracted by the framework using Facades.

Email trigger example

Mail::to('email@here.com')->send(new EmailContent);

That said, how would we test whether the email is actually being fired using automated tests?

An alternative is to run the tests with our personal email and check our inbox, but that just thinking about it doesn't seem very efficient.

For that there is this Fake Facade pattern, whose name I invented because I couldn't find a name for it.

If you have already created tests for email dispatching, you probably already know the fake method of this facade:

Mail::fake();

Not all facades implement this method but the objective of this article is to understand what it does and implement it ourselves.

Looking at what the method does we can see that it basically calls the swap method which basically swaps and is behind this Facade.

So basically, before we call the method, the Mail class points to the real implementation of sending emails and after calling the method it points to this MailFake class.

What does this MailFake class do?

Firstly, it needs to implement all the methods that the real implementation has so that no problems occur during the execution of your program.

Let's go back to the example:

Mail::to('email@here.com')->send(new EmailContent);

In the MailFake class, the send method actually just adds the email to an array so we can test this in the future, example:

function dispatchEmail() {
    Mail::to('email@here.com')->send(new EmailContent);
}

it('should dispatch email successfully', function () {
    // Arrange
    Mail::fake();

    // Act
    dispatchEmail();

    // Assert
    Mail::assertSent(EmailContent::class);
});

Now that we understand what the implementation is for and how to use it, let's create our own implementation.

One case where this implementation is viable is integration with payment providers, let's go.

Step 1: Let's create our contract (interface)


interface PaymentProviderContract
{
    charge(Invoice $invoice): Charging;
}

Step 2: Create our Facade


class PaymentProvider extends Facade
{
    public function getFacadeAccessor()
    {
        return PaymentProviderContract::class;
    }
}

Step 3: We create our actual payment provider implementation

class StripePaymentProvider implements PaymentProviderContract
{
    public function charge(Invoice $invoice): Charging
    {
        // Interacts with the stripe api
        return new Charging();
    }
}

Step 4: We point Facade towards implementing Stripe

We can do this in our AppServiceProvider in the register method.


class AppServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->register(
            PaymentProviderContract::class,
            fn () => new StripePaymentProvider,
        )
    }
}

Now every time we call PaymentProvider::charge() it will point to the Stripe implementation because we declared this in our Service container.

Step 5: We create our fake implementation


class FakePaymentProvider implements PaymentProviderContract
{
    private array $chargings = [];

    public function charge(Invoice $invoice): Charging
    {
        $charging = new Charging;

                // Fill charging with invoice informations

        $this->chargings[] = $charging;
    }

    public function assertChargingsCount(int $count): void
    {
        expect($this->chargings)->toHaveCount($count);
    }
}

Step 6: Implement the method to perform the swap on our facade


class PaymentProvider extends Facade
{
    public static function fake(): FakePaymentProvider
    {
        static::swap($fake = new FakePaymentProvider)

        return $fake;
    }

    public function getFacadeAccessor()
    {
        return PaymentProviderContract::class;
    }
}

Okay, now we can safely test our application


function chargeUser(User $user): Charging
{
    return PaymentProvider::charge($user);
}

it('should charge a user', function () {
    // Arrange
    PaymentProvider::fake(); // Swap for fake class

    // Act
    chargeUser(); // now the charge method will be executed by the fake class
    // Assert
    PaymentProvider::assertChargingsCount(1);
});

Okay, now with this pattern implemented we can test only the rules of our application without needing to "test other people's code" which would mean testing Stripe's Api, for example.

We can and should create more auxiliary methods in our FakePaymentProvider class to improve the quality of development and also the effectiveness of our tests.

Single Responsibility Principle in a Laravel Project

Gabriel Oliveira — Wed, 11 Oct 2023 21:58:11 +0000

This principle declare that a class must be specialized in a single subject and have a single responsibility within the software, in other words, a class must have a single or action to perform.

Violate that principle can bring some problems such as:

Lack of cohesion
High coupling
Difficulties reusing the code
Difficulty to implement automated tests

Example

class UserController extends Controller
{
    public function register(Request $request): JsonResponse
    {
        $request->validate([ // Request validation
            'name'  => ['required', 'string'],
            'email' => ['required', 'email'],
            'role'  => ['required', new Enum(UserRoles::class)],
        ]);

        $user = new User();
        $user->name = $request->input('name');
        $user->email = $request->input('email');
        $user->role = $request->input('role');
        $user->password = Hash::make($request->input('password'));
        $user->save(); // Interact with daatabase

        if ($user->role === 'customer') { // Business Rule
            Mail::to($user->email)
            ->send(new WelcomeCustomerEmail($user)); // Email Dispatch
        }

        return response()->json(['id' => $user->getKey()], 201);
    }
}

As we can see above, the class UserController has several responsibilities:

Validate request body
Save user in the database
Business Rule
Send welcome email if user is customer

When actually, the function of a controller is just receive requests and return responses. We must separate these responsibilities into other layer, such as:

Layers
Requests validators (In laravel you can use Form Requests, but in other frameworks you can create some middlewares)
Controller - ( Receive requests and return response )
Repository - ( Interact with database )
Service - ( Business Rule )

Request validator (Form Request)

class UserRegisterRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name'  => ['required', 'string'],
            'email' => ['required', 'email'],
            'role'  => ['required', new Enum(UserRoles::class)],
        ];   
    }
}

Controller

class UserController extends Controller
{
    public function __construct(
        protected UserService $userService
    ) {
    }

    public function register(RegisterUserRequest $request): JsonResponse
    {
        $dto = new RegisterUserDto($request->all()); 

        $user = $this->userService->register($dto);

        return response()->json(['id' => $user->getKey()], Response::HTTP_CREATED);
    }
}

I use a RegisterUserDto, where ‘Dto’ stands for ‘Data Transfer Object.’ This is employed when transferring data across different layers.

Service

class UserService
{
    public function __construct(
       protected UserRepository $userRepository,
    ) {
    }

    public function register(RegisterUserDto $dto): User
    {
        $user = $this->userRepository->save($dto);

        if ($user->isCustomer()) {
            $this->sendWelcomeEmail($user);        
        }

        return $user;
    }

    protected function sendWelcomeEmail(User $user): void
    {
        Mail::to($user->email)->send(new WelcomeUserEmail($user));
    }
}

Repository

class UserRepository
{
    public function save(RegisterUserDto $dto): User
    {
        return User::create($dto->toArray());
    }
}

Now that project is more flexible to implement new features, your code became more readable, in tests, now you can easily utilize mocks for your repository, for example, so you don’t need to interact with the database, which would slow down your tests.

Tip

If you application use the pattern to return created responses with entity id, you can add a helper method in your Base Controller.

Base Controller

class Controller extends BaseController
{
    protected function created(int $id): JsonResponse
    {
        return response()->json(['id' => $id], Response::HTTP_CREATED);
    }    
}

UserController

class UserController extends Controller
{
    public function __construct(
        protected UserService $userService
    ) {
    }

    public function register(RegisterUserRequest $request): JsonResponse
    {
        $dto = new RegisterUserDto($request->validated()); 

        $user = $this->userService->register($dto);

        return $this->created($user->getKey());
    }
}