Introducing Gptlab: A Bridge Between ChatGPT and GitLab

Artur Świerc — Wed, 01 Nov 2023 17:54:31 +0000

What is Gptlab?

Gptlab is an integration plugin designed to bridge ChatGPT with GitLab. Its primary goal is to enable users to leverage GitLab functionalities directly through the ChatGPT interface, offering a unique project management and collaboration experience.

Project's Vision: Teach by Showing

Gptlab isn't just a tool – it serves as a demonstration of how to craft custom plugins for ChatGPT. Many of us have desired to customize and extend ChatGPT's capabilities but it's not always an intuitive task. This project aims to illustrate how this can be practically achieved. If you've ever wondered how to integrate ChatGPT with other tools or services, Gptlab provides an excellent starting point!

Future Developments

The goal of this repository is continuous evolution. In future iterations, the idea is to make it as straightforward as telling ChatGPT, "Do a code review for branch xxxx", and it will seamlessly integrate with GitLab to get the task done. Imagine the potential of effortlessly managing your GitLab tasks via simple chat commands!

Why should you care?

Intuitiveness: By using natural language, you can perform GitLab-related tasks directly through ChatGPT.
Flexibility: With Gptlab, you can integrate your ChatGPT bot with any project on GitLab.
Time-saving: Instead of juggling multiple tools, you can use a single interface for communication and project management.

How does it work?

To get started with Gptlab, simply clone the repository, install dependencies, and fire up the Docker service with docker-compose up. Then, set up your environment variables like GITLAB_PERSONAL_TOKEN, and you're good to go!

The API will be accessible at: http://localhost:3000.

For details on how to connect the plugin to ChatGPT, check out our README.md.

Conclusion

I'm keen on sharing this tool with the broader community and am eager to hear your feedback, insights, and suggestions.

How to make your entity non-anemic, and keep the consistency of the model

Artur Świerc — Sun, 04 Dec 2022 16:10:20 +0000

I remember when I started my way with Tactical Design, everywhere I heard that we have to make non-anemic entities. By anemic entities I mean entities as a data structure, with plenty of setters and no logic.

But, that was tough to find out a solution, to how to make the entity non-anemic.

In this article, I want to show you, how you can change your thinking about entities and make them non-anemic.

First I want to show you the leaking model, I'm sure you've seen it in many projects

A leaking model

Let's consider the example of a leaking model.

As I mentioned before we need it anemic entity. Here we have, a simple User entity with two parameters phoneNumber and phoneNumberAreaCode. Area Code is nothing more than the prefix of the number, for example, +48, and the phoneNumber is the rest.

So having said that, we have the whole phone number with code and number - +48 xxx xxx xxx (Format and number are depending on your country of course).

class User
{
    private ?string $phoneNumber = null;
    private ?string $phoneNumberAreaCode = null;

    public function setPhoneNumber(string $phoneNumber): void
    {
        $this->phoneNumber = $phoneNumber;
    }

    public function setPhoneNumberAreaCode(string $phoneNumberAreaCode): void
    {
        $this->phoneNumberAreaCode = $phoneNumberAreaCode;
    }

    public function getPhoneNumber(): ?string
    {
        return $this->phoneNumber;
    }

    public function getPhoneNumberAreaCode(): ?string
    {
        return $this->phoneNumberAreaCode;
    }
}

As you can guess, those two values shouldn't be persisted separately.

Yep, so what we have to do next? Maybe a service? Yes! A service will be perfect element of something which can set the number and prefix. Like an orchestra conductor!

Here is a service:

class UpdatePhoneNumberService
{
    public function __construct(
        private readonly UserRepositoryInterface $userRepository
    ) {
    }

    /**
     * @throws UpdatePhoneNumberException
     */
    public function update(string $phoneNumber, string $areaCode, string $userId): void
    {

        // format the numbers 

        // check if the parameters are not empty

        // tens of lines...

        // check if the number isn't assigned to any other user

        // again... tens of lines...

        $user = $this->userRepository->findById($userId);

        // finally you can make a set 
        $user->setPhoneNumber($phoneNumber);
        $user->setPhoneNumberAreaCode($areaCode);

        $this->userRepository->save($user);
    }
}

The code is good enough until another dev won't get into the tens of code of your service. And just figure out a better solution.

Make a hacking, if we have User entity with public API (setPhoneNumber and setPhoneNumberAreaCode).

class PhoneController
{
    ...

    public function updateAction(
        Request $request,
        User $user, // logged user
    ) {
        ...
        $user->setPhoneNumber(...);
        $this->userRepository->save($user);
        ...
    }

Oh no! The Dev forgot about an area code!

What's happened here? The new dev forgot about an area code.
That is a leaking model! If you have a few parameters that shouldn't be changed separately, the entity has to check the consistency.

One source of truth should be in the entity.

Ok but how can I change to make it happen?

How we can move the logic to an entity if the entity isn't a service and we can't inject there any objects?

Let's use another building block, a policy. Take a look at the example of a refactored entity.

class User
{
    private string $id;
    private PhoneNumber $phoneNumber;
    private bool $phoneNumberVerified = false;

    public function __construct()
    {
        $this->id = Uuid::uuid4()->toString();
    }

    public function getId(): string
    {
        return $this->id;
    }

    public function updatePhoneNumber(PhoneNumber $phoneNumber, ChangePhoneNumberPolicy $policy): Result
    {
        $result = $policy->canBeUpdated($this, $phoneNumber);

        if ($result->isFailure()) {
            return $result;
        }

        $this->phoneNumber = $phoneNumber;

        return Result::success(new PhoneNumberUpdatedEvent($this->getId(), $phoneNumber));
    }

As you can see now the entity has a method updatePhoneNumber, there are no sets methods. The updatePhoneNumber method takes a parameter ChangePhoneNumberPolicy.

Also we can notice new builidng block a value object - PhoneNumber. So it forces a validation, we can't persist User entity without required parameter.

Let's see the policy.

class ChangePhoneNumberPolicy
{
    public function __construct(private readonly UserRepositoryInterface $userRepository)
    {
    }

    public function canBeUpdated(User $user, PhoneNumber $phoneNumber): Result
    {
        $differentUser = $this->userRepository->findByPhoneNumber($phoneNumber);

        if ($differentUser instanceof User && !$differentUser->isEqual($user)) {
            return Result::failure(new Reason('the phone number is already in use'));
        }

        // ... other conditions ...

        // if the requires changed, you'll change only the policy, or make interface and you'll change your DI config

        return Result::success();
    }
}

Mostly policies will be behind the interface because the logic could change. Sometimes you'll see that policies are injected through a set method, and entities can be built by factories.
Generally, we ended up with one place to change, your model will be consistent and validated. Now you know how to use policy.

I know it is only the beginning, and I brought up only small pieces of a vast subject. To see the solution with controllers, repos, and so on check the github repo

aswierc / procedural-vs-oop

How to make your entity non-anemic, and keep the consistency of the model

But, that was tough to find out a solution, to how to make the entity non-anemic.

In this article, I want to show you, how you can change your thinking about entities and make them non-anemic.

First I want to show you the leaking model, I'm sure you've seen it in many projects

A leaking model

Let's consider the example of a leaking model.

View on GitHub

Forem: Artur Świerc

Introducing Gptlab: A Bridge Between ChatGPT and GitLab

What is Gptlab?

Project's Vision: Teach by Showing

Future Developments

Why should you care?

How does it work?

Conclusion

How to make your entity non-anemic, and keep the consistency of the model

A leaking model

Oh no! The Dev forgot about an area code!

Ok but how can I change to make it happen?

aswierc / procedural-vs-oop

How to make your entity non-anemic, and keep the consistency of the model

How to make your entity non-anemic, and keep the consistency of the model

A leaking model