Douglas Domingos :: CompSci@UFCG

My First Thoughts on Fedora Linux

Sat, 04 Jan 2025 00:32:27 -0300

Introduction

Since my first contact using Linux back in 2020, I’ve tried out many distributions, such as Ubuntu, Linux Mint, Kubuntu, and most recently Pop!_OS. But, as you may already known, these are all Debian-based distributions, so aside from graphical interfaces, they function in the exact same way.

Having expanded my knowledge in Linux throughout the last year, I now feel confortable enough to tweak with more cutting-edge systems. My first idea was to try Manjaro KDE, as Arch-based distributions seemed quite interesting. Yet, after playing around with Fedora through LiveUSB, I’ve decided to stick around with it for now.

The opinions shared in this post are based on the following use cases:

Software Development, mainly in Java, JavaScript and Python environments
Casual tasks and applications (e.g. music and video streaming, web browsing, etc.)
Gaming (i.e. lightweight games via SteamOS and Proton)

I’ve also considered the opinions of other users posted on the Reddit community r/Fedora, which I recommend you to follow for troubleshooting and customizing configurations.

The first contact

Something noticeable even before installing Fedora is that it’s very lightweight - it’s shipped only with Firefox, LibreOffice Suite, and basic applications/utilities. This also applies for GNOME Shell, the graphical interface of Fedora Workstation, which offers a pure, vanilla experience. Sure, finding and testing GNOME extensions for basic funcionalities (e.g. adding app shortcuts to the desktop) is quite annoying, but it’s a classic “install and forget” type of job.

The real deal-maker for me was the package repositories: many of the softwares I use are avaliable in DNF with more recent versions than those in APT-based distributions. Also, Fedora comes with Flatpak pre-installed, only requiring you to add the FlatHub repositories before installing software.

However, not everything is perfect: Fedora’s preference for open-source software means that you may need to manually install proprietary drivers, such as those for Nvidia GPUs, and media codecs like H.264. Fortunately, most of these can be found in RPMFusion - Fedora’s third-party repository. So far, I only had to install a few video codecs for VLC, without any struggles with hardware compatibility. Therefore, your experience with Fedora may vary, depending on your hardware specifications and which programs you use.

Software compatibility

One of my biggest concerns when moving away from Pop!_OS was that some applications I use wouldn’t be compatible, without any satisfactory alternatives. Thankfully, this was not the case, as Fedora’s repositories provided pretty much all the packages I needed. But again, for third-party packages and proprietary software, you may have to reach out for RPMFusion, which is very easy to setup and use.

On the rare ocasions where the softwares you need is not within Fedora’s repositories nor RPMFusion, you can also use Flatpak - a package manager that allows you to install and execute containerized applications, keeping their dependencies separate from the system. I personally prefer flatpaks over native packages, though I’ve seen many users recommend the opposite.

The only cases I believe you may have to opt for alternatives are for packages and applications distributed only through Snap or PPAs. For Snap, however, it’s probable that you’ll find your software within Flatpak or RPM repositories, which was my case for Hugo SSG - the framework used in this website, distributed in Fedora through DNF.

Support and resources

It’s important to highlight that Fedora has far less online resources when compared to Ubuntu/Debian distributions, which means that you may have difficulties finding solutions for technical problems, specially if you have little experience with Linux.

Despite that, I’ve found Fedora to be very similar in usability with Ubuntu distributions so far. The most noticeable difference between the platforms are the package repositories, as Fedora (and RedHat Linux distributions) enphatizes the adoption of Open-Source software, and thus requires add some overhead configuration to allow proprietary packages - which are easily set with only two commands in your terminal.

Although Fedora has proved to be stable and easy to use up until now, I’d still recommend Debian-based distributions for those who have no experience in Linux, or simply have no time to spare on debugging configurations.

TL;DR

With my current experience, Fedora stands out on the following:

Offers a true vanilla GNOME experience, leaving all customizations for the users
Allows users to choose whether to install proprietary software (through RPMFusion) or not
Packages within RPM repositories are offered in more recent versions than in APT

However, I see some possible drawbacks of this migration:

Being a cutting-edge distribution, Fedora may be less stable than Ubuntu
Specific applications may not be available for Fedora
Potential reduced compatibility with older hardware (based on some reports from other users)

Some of this aspects may change as my experience with Fedora evolves, so expect updates in the future.

Creating a Multiboot USB Drive with Ventoy

Wed, 20 Nov 2024 18:49:01 -0300

Introduction

During a deploy of our custom Linux Mint images in one of the labs at UFCG, I’ve learned about Ventoy – an interesting tool for creating bootable USB drives. Of all the tools I’ve used for this task (like Rufus and Etcher), Ventoy catched my interest for three reasons:

It does not require flashing the ISO into the USB drive
It allows you to add multiple ISO files to the USB drive, without tweaking with disk partitions
It allows you to choose which image to boot from at startup

Ventoy is also very easy to install and use, as it provides packages with graphical interface for Linux, so you don’t have to worry with cryptic shell commands. But that’s boring, so we’re going to get our hands dirty anyways 🥱

How Ventoy works?

While installing Ventoy on an USB drive, it will create two main partitions:

The EFI partition (formatted as FAT), where Ventoy’s bootloader and configurations are stored, and only 32MB in size
The main partition (usually formatted as exFAT or FAT32), where you can place your ISO files

When booting from the USB drive, Ventoy’s bootloader will look for ISO files inside the main partition and list them at the boot menu. Please note that the disk layout may vary, depending on whether you choose the MBR or GPT partitioning scheme.

Using Ventoy on Linux

As mentioned before, we’ll be installing Ventoy through CLI – like real Linux users would. So, you’ll need to download the binary packages (e.g. ventoy-1.0.XX-linux.tar.gz file), which are avaliable at SourceForge. I recommend unpacking the tarball at /opt for convenience.

Inside the package, you’ll see a bunch of executable files. Since we won’t use a graphical interface, our focus is in the Ventoy2Disk.sh script.

If you wish to install Ventoy using a graphical interface, execute one of the files labeled with the VentoyGUI prefix. Please note that you have to choose the executable with the same architecture as your machine (e.g. VentoyGUI.x86_64 for 64-bit machines).

You may also use an Web UI by executing the VentoyWeb.sh and opening your browser at http://localhost:24680

If you plan to use Ventoy frequently, it might be interesting to add the executables to your $PATH. For that, I have an article on how to install packages manually on Linux, which you can find here.

Installing Ventoy on a USB drive

Now that we have the package set up on our machine, let’s take a look on how to use Ventoy2Disk.sh. After running the script without any arguments, we get the following output:

[...]
Usage: Ventoy2Disk.sh CMD [ OPTION ] /dev/sdX
 CMD:
 -i install Ventoy to sdX (fails if disk already installed with Ventoy)
 -I force install Ventoy to sdX (no matter if installed or not)
 -u update Ventoy in sdX
 -l list Ventoy information in sdX

 OPTION: (optional)
 -r SIZE_MB preserve some space at the bottom of the disk (only for install)
 -s/-S enable/disable secure boot support (default is enabled)
 -g use GPT partition style, default is MBR (only for install)
 -L Label of the 1st exfat partition (default is Ventoy)
 -n try non-destructive installation (only for install)

Although the text is pretty straightforward, we need to find which device is our USB drive – specified by /dev/sdX. For that, you can use the lsblk command to list all the block devices in the system. Here’s a sample output for this command:

user@host:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
[...]
sda 8:0 0 238,5G 0 disk
├─sda3 8:3 0 237,5G 0 part /
└─sda4 8:4 0 1G 0 part /boot/efi
sdb 8:16 1 7,5G 0 disk
├─sdb1 8:17 1 7,5G 0 part /media/dougsilva/Ventoy
└─sdb2 8:18 1 32M 0 part
[...]

USB devices are usually mounted at the /media directory. In my case, the USB drive is represented by sdb device, so I must pass /dev/sdb as the installation device to the Ventoy2Disk.sh script. Below are some examples on how to configure your installation:

# Install Ventoy on /dev/sdX. This will fail if Ventoy is already installed.
sudo ./Ventoy2Disk.sh -i /dev/sdX

# Force install on /dev/sdX, ignoring any existent Ventoy installation
sudo ./Ventoy2Disk.sh -I /dev/sdX

# Install on /dev/sdX while keeping a 500MB free space at the end of the device
sudo ./Ventoy2Disk.sh -i -r 500 /dev/sdX

# Install on /dev/sdX with GPT partition style and labelling the main partition as "Multiboot USB"
sudo ./Ventoy2Disk.sh -i -g -L "Multiboot USB" /dev/sdX

Please note that installing Ventoy WILL ERASE ALL DATA FROM THE DEVICE, so you should backup any important files from the USB drive before installation. Also, while installing through command-line, be careful to not mistake your USB drive for another device.

You can also use the fdisk -l command to list the devices of your machine with a more verbose output. This allows you to search for a device with grep (i.e. fdisk -l | grep "YOUR_DEVICE").

Booting up the USB drive

After the installation is complete, you can simply drag-and-drop your ISO files into the main partition, reboot your machine and boot from the USB drive. If you had no unpleasant surprises during installation, you should see the following screen:

From here, simply choose which ISO you wish to boot, and select the Boot in normal mode option. For more information about boot modes, read the documentation.

Some machines have a hot key for entering the Boot Menu at startup, so you don’t need to manually change the boot order in your BIOS. Please check out this list for reference.

Considerations about Secure Boot

Since Ventoy 1.0.76, Secure Boot support is enabled by default. This means that Ventoy should work whether Secure Boot is enabled in your machine or not.

If Secure Boot is indeed enabled in your machine, you should see the screen below when booting Ventoy for the first time. Please follow these instructions in Ventoy’s documentation on how to allow Ventoy on Secure Boot.

However, if you see another error screen while booting Ventoy, your system may not support Ventoy on Secure Boot. As such, you’ll need to disable the option in your Ventoy installation and your BIOS.

Conclusion

Until now, Ventoy has proved to be a handy tool for testing Linux distributions and keeping backup ISOs for system recovery. It’s easy to install and use, it’s lightweight and also quite fast when compared to similar tools.

While I have not tried installing a system through Ventoy, I plan to try it out soon with Fedora, and if everything goes as expected, I may use it to setup a dual-boot installation with Windows in the (not so) far future.

Automating tasks with Github Actions

Fri, 01 Nov 2024 17:35:48 -0300

Introduction

In software development, it’s common to have some tasks that need to be executed regularly, at a specific time or in a certain order. Usually, teams would write dedicated scripts for these tasks, which adds complexity and diverts focus from the main product.

That’s where CI/CD platforms comes in, streamlining development workflows by automating repetitive tasks so developers can focus on the actual software. Here, we’ll be exploring one of these platforms: GitHub Actions.

What are GitHub Actions?

GitHub Actions is a CI/CD platform integrated directly into GitHub, which allows you to easily automate tasks within repositories. Each repository can have multiple workflows, represented by YAML files located in the .github/workflows/ directory. As you’ll see, this makes workflows easy to write and understand.

You can define workflows triggered by various events, such as pushes and pull requests, and use them for a wide range of tasks — testing, deploying to production, enforcing code style, and much more. Workflows can even be scheduled, combined with other workflows, and used to update your repositories. Plus, you can leverage actions created by other developers!

Setting up an workflow

New workflows can be added to your repository in two ways:

Through GitHub, where you can choose from many template workflows and adjust them as needed
By manually creating the workflow file inside .github/workflows

Regardless of your choice, describing workflows is writing YAML files. And, to fully understand the structure of a workflow, let’s create one that simply prints “Hello Actions!” at each push made to the repository.

Workflow structure

Implementing our “Hello Actions” workflow is as simple as this:

name: Simple Action

on: push

jobs:
 print-msg:
 runs-on: ubuntu-latest

 steps:
 - name: Print message
 run: echo "Hello Actions!"

Now, let’s understand what each part of this code does:

name, as it suggests, defines the name of the workflow. While it is optional, I strongly recommend to always specify the workflow name — not only for readability, but also to allow workflow composition.
on defines the events that will trigger the workflow’s execution. You can specify multiple triggers for the same workflow, and even restrict the event scope (e.g. pull requests to a specific branch, or changes made to a specific file).
jobs describe the actions performed by the workflow. An workflow can have multiple jobs (that are executed on parallel by default), where each job is identified by an unique name.
- Each job must define the environment it runs on (which is specified by the runs-on key)
- A job describes the tasks it executes as a sequence of steps. Each step can execute commands, setup tasks and even other actions

Example 1: Automating tests for pull requests made to the `main` branch

Automating tests plays a crucial role at code maintainabilty, as it ensures that changes made to the codebase do not break what previously worked. Such task can be easily achieved with GitHub Actions by setting up an workflow that is executed for every pull request made to the repository.

Consider a project written in Java with Maven as build tool. We want to automatically run all test classes for every pull request made to the main branch. This can be achieved with the following workflow:

name: Run tests with Maven

# The workflow only runs for pull requests made to the "main" branch
on:
 pull_requests:
 branches: "main"

jobs:
 run-tests:
 runs-on: ubuntu-latest

 steps:
 # Checks out (e.g. clones) the repository into the Actions runner
 - uses: actions/checkout@v4

 # Install the required Java version
 - name: Set up Java 17
 uses: actions/setup-java@v4
 with:
 java-version: "17"
 distribution: "temurin"
 cache: maven

 # Run tests with Maven
 - name: Test with Maven
 run: mvn test

Example 2: Scheduled updates of a repository

In my old website, I’ve set up Next.js to regularly fetch my repository list from GitHub API, so that my project list would always be updated. After migrating to Hugo, I kept wondering on how to implement this functionality with as little overhead as possible.

It turns out that GitHub Actions was perfect for my scenario. Simply write a workflow that fetches data from GitHub API and commits the updated list into the repository. After some googling (and a little help from ChatGPT), I was able to come up with an working solution.

While I chose to use Python for the fetch script, you could write a similar solution in plain old Shell Script (though the equivalent code would likely be much more verbose) or in any language you prefer.

First, here’s my Python script for fetching and parsing the data, at .github/scripts/fetch_data.py:

import requests
import yaml


def fetch_github_repos(username: str):
 """Fetch the repositories of a user from GitHub API

 Args:
 username (str): The username of the account to be fetched

 Returns:
 The contents of the response as a JSON object
 """

 FETCH_URL = f"https://api.github.com/users/{username}/repos"
 response = requests.get(FETCH_URL)

 if response.status_code != 200:
 print(f"Failed while fetching data: HTTP {response.status_code}")
 return []

 return response.json()


def convert_to_yaml(repo_list: list):
 """Given the contents of the request, create the equivalent YAML file.

 Args:
 repos_data (list): The JSON structure of repository
 """

 # Order repositories by most recent updated
 repo_list = sorted(repo_list, key=lambda repo: repo["updated_at"], reverse=True)
 projects = []

 for repo in repo_list:
 # You can add more properties here
 project = {
 "link": repo["html_url"],
 "info": {"title": repo["name"], "description": repo["description"]},
 "tags": repo["topics"],
 }

 projects.append(project)

 data = {"projects": projects}

 # Saves the project list as a YAML file
 with open("./data/projects.yaml", "w") as outfile:
 yaml.dump(data, outfile, default_flow_style=False, sort_keys=False)


if __name__ == "__main__":
 convert_to_yaml(fetch_github_repos("your_username"))

As for the workflow file, at .github/workflows/fetch_projects.yaml:

name: Update project list

# Actions allow you to define environment variables too!
env:
 SCRIPT_PATH: .github/scripts/fetch_projects.py

# Gives the workflow write permissions over the repository
permissions:
 contents: write

# Workflow is scheduled to run every Sunday at 00h00
on:
 schedule:
 - cron: "0 0 * * 0"
 workflow_dispatch: # this allows us to manually run the workflow in GitHub

jobs:
 update-list:
 runs-on: ubuntu-latest

 steps:
 - name: Checkout
 uses: actions/checkout@v4

 - name: Set up Python
 uses: actions/setup-python@v5
 with:
 python-version: "3.10"

 - name: Install dependencies
 run: pip install pyyaml requests

 - name: Run script
 run: python ${{ env.SCRIPT_PATH }}

 - name: Commit changes to repository
 run: |
 git config --global user.name "<your-username-here>"
 git config --global user.email "<your-email-here>"
 git add ./data/projects.yaml
 git commit -m "chore(actions): update project list"
 git push

Cron syntax: Cron schedules are specified by strings composed of five fields in a M H DM MN DW format, as described below:
M H DM MN DW
| | | | |
| | | | └── Day of the week (0-7, where 0 and 7 = Sunday)
| | | └───── Month (1-12)
| | └──────── Day of the month (1-31)
| └─────────── Hour (0-23)
└────────────── Minute (0-59)
So, 0 0 * * 0 means “at 00h00 of any day of any month on Sunday”

Also, to ensure that the updated list is avaliable in the website after the script is executed, I’ve added a “hook” to trigger the build workflow every time the Update project list workflow is executed — thus the importance of always naming your workflows:

# ...
on:
 # ...
 # Specifies that the "build" workflow should execute after the
 # "Update project list" workflow is completed
 workflow_run:
 workflows: ["Update project list"]
 types:
 - completed
# ...

Conclusion

GitHub Actions, as well as other CI/CD platforms, are a powerful tool to master. While I do believe this post may help you with the basics, I recommend taking a deeper look into the GitHub Actions documentation.

Also, feel free to use any of the workflows you’ve seen here in your projects. Try adding some new features, or combining them with your own.

That’s it for now. See ya! 👋

Installing software in Linux, the "hard" way

Sun, 15 Sep 2024 13:34:18 -0300

Introduction

Picture this: you’re setting up the packages and tools to develop your brand new application. Everything is going smooth, until you found out that one of the softwares you need is only avaliable as package of executable binaries, without any installers and nowhere to be found in your package managers. Seems like quite the overhead, right?

Well, not to worry! Because today we’re out to get our hands dirty and learn how to install ANY PACKAGE in a Linux system ‒ and you might just learn a few new tricks about Linux along the way.

I. Housing the package

The first step to solve our problem is to define where the package will be stored in our system. In practice, you may use any directory you’d like, but to keep things organized, let’s use the /opt directory.

The /opt directory is reserved for installing software and packages that are not part of the system’s core components, i.e, not necessary for your system to function properly.

When installing your package, you should create a new directory (preferably with the package name, like /opt/<package_name>) to avoid mixing up files of different packages.

You may have noticed that inside your package, there’s a /bin directory that contains some executable files. At this point, we can run these files, but we’ll have to specify the full path of the file every time.

II. Make your package avaliable with `$PATH`

To avoid having to pass the full path of the executables each time we run the software, we’ll make use of the $PATH environmental variable to specify the path of our installation.

The $PATH variable is a special shell variable that defines a list of directories where executable files are located. Each directory is delimited by a colon (:)

You may specify new directories in $PATH by exporting the variable with the new value (export PATH=/new/dir/path:$PATH).

Now, there are two ways of adding a executable to $PATH:

Adding a Symlink to the executables

Symlinks are (roughly) files that “point” to other file paths or directories. This allows us to access files accross the file system (and even other file systems), without specifying the full path.

You can create new symlinks using the command ln -s TARGET LINK_NAME, where:

TARGET is the path of the file which the symlink will point to
LINK_NAME is the path where the symlink will be created

To make it avaliable in $PATH, we may create a symlink inside a directory that is already in $PATH. In this case, let’s use the /usr/local/bin directory to store our symlink.

To create our symlink, simply run the following comman:

# Replace the placeholders with the proper names of your directories/files
ln -s /opt/<package_name>/bin/<filename> /usr/local/bin/<filename>

Once created, the executable will be avaliable in your shell. Try it out by typing the name of the symlink in your terminal.

Trade-offs of using symlinks

This approach is pretty straightforward and easy to setup. We don’t need to edit the value of $PATH, thus avoiding possible configuration errors. Also, by placing the symlink inside /usr/local/bin, we make it avaliable for all users of the system.

Unfortunately, there are also drawbacks. If you need to add multiple executables, you’ll need do create one symlink per executable. You may create a symlink to the /bin directory of the package, but you’ll still need to specify the name of the executable.

Links in Linux
Links are a powerful tool in Linux, allowing you to create shortcuts between files and directories, organizing your files easily, and much more. I recommend reading this RedHat post about linking in Linux.

Adding the package directory to `$PATH`

If you want a more robust solution, you may effectivelly edit the $PATH variable to include your package directory. For that, we’ll need to create a configuration file to export our updated $PATH.

The /etc/ directory contains configuration files of system applications, e.g. service management, network, SSH, and many more. Be careful when making changes to files here.

Similar to /opt, Linux also has a directory for storing system-wide configuration files: the /etc directory. Actually, there’s the /etc/opt directory, which is intended to store configuration files for applications installed in /opt.

To create the configuration file, head to /etc/opt and create a new file, named as <package_name>rc. Inside it, paste the following code and replace the placeholders with the correspondent paths:

# Replace "PACKAGE_HOME" with the name of your package
export PACKAGE_HOME=/opt/<package_dir>
export PATH=$PACKAGE_HOME/bin:$PATH

To load the settings into your shell session, run source /etc/opt/<config_file> and check your $PATH variable with echo $PATH. If the directory of your package is there, your configuration file is working.

Now, you might have noticed that the configurations aren’t loaded automatically when you open a new terminal. To address this, simply add this configuration to one of the following files:

# This loads "PACKAGE" into $PATH
[ -f /etc/opt/<config_file> ] && source /etc/opt/<config_file>

For only one user, append the load configuration at the end of ~/.bashrc
For all users, create a shell script (with the .sh suffix) in /etc/profile.d/ with the load configuration

Trade-offs of using `$PATH`

One advantage of this approach is that every executable inside the /bin directory will be avaliable in your shell. Also, you may choose to make it avaliable for only one user or for all users, by simply placing the load configuration in a different file.

However, tweaking with the $PATH variable may break your shell configuration if you’re not careful enough. The same goes for editing files inside /etc/profile.d; it’s best to create a new file rather than edit an existing one.

If you’re installing an application with a graphical interface (not CLI-based), you’ll likely want to add it to your desktop menu for easier access. In this case, we’ll need to take an extra step.

The entries in your desktop menu are located in the /usr/share/applications directory. Each application has a .desktop entry file, containing settings for how it is displayed in the menu.

To add a desktop entry file for your application:

Create a new .desktop entry file with the name of your application

Open the file and add the following configuration, replacing the placeholders with the correct settings:

[Desktop Entry]
Version=1.0
Type=Application
Name=<APP_NAME>
Icon=/opt/<PACKAGE_NAME>/<ICON_FILE>
Exec="/opt/<PACKAGE_NAME>/<EXEC_FILE>" %f
Comment=<APP_DESCRIPTION>
Categories=<KEYWORD1;KEYWORD2;>

Save the file and run sudo update-desktop-database

Now, the application is avaliable in your app menu, without the need to start it through the terminal.

Summary

Install your package in the /opt directory
Use symlinks or edit your $PATH variable to include the package executables for an user or all the system
If the package is not CLI-based, add a .desktop entry file at /usr/share/applications to add the package to your desktop menu

Conclusion

Although application support for Linux platforms is pretty decent today, you’ll eventually come across a situation like the one we’ve discussed here. Also, you can automate this process by creating shell scripts to setup the files for you.

Well, that’s it. Until next time! 👋

About me

Mon, 01 Jan 0001 00:00:00 +0000

Name Douglas Domingos

Location Campina Grande, PB - Brazil

Education B.Sc Candidate in Computer Science

Skills Frontend, Backend, DevOps, Cloud

Interests Game Development and Digital Art

Undergraduate student in Computer Science at the Federal University of Campina Grande (UFCG).

As a pragmatic software engineer, my goal is to deliver reliable, high-value solutions to end users, regardless of the technologies involved. I believe that exceptional products are born from the synergy of flexible teams, clear communication, and decisions strictly guided by solid metrics and tangible impacts.

Behind the pragmatism, however, lies the soul of an artist. I’m fascinated by how the experiences and creativity of a team are translated into the problem-solving process. For me, the true beauty of software architecture lies in the way teams extract the most out of the available resources to build incredible user experiences.

Beyond DevOps and Infrastructure, I have a strong interest in Pixel Art and Game Development. After all, creating games is what brought me into programming, and this passion is still alive, more than ever. Today, I invest part of my free time in traditional and digital art, as a way to express what can’t be contained within the boundaries of an IDE.

With plans to debut as an Indie GameDev at some point in the future, I’m convinced that my technical background, alongside my artistic side, will merge into a genuine identity that will be etched into every story I plan to tell.

Personal projects

Mon, 01 Jan 0001 00:00:00 +0000

CaringHands

An web platform that allows families and caregivers to manage medications and medical exams for their patients with much more simplicity and convenience

#react
#tailwind-css
#spring-boot
#postgresql
#aws-ec2
#github-actions

Image Filters

An image processing application focused on performance, with multiple filters (e.g., Binarization, Sobel, Gaussian Blur) implemented using only built-in features of Go's standard library.

#go
#concurrent-programming
#pixel-manipulation
#study-project

Expense Tracker API

REST API built with Spring Boot and JWT Authentication for finance management

#spring-boot
#spring-security
#oauth2
#jwt-auth
#postgresql
#swagger-ui

Professional Experiences

Mon, 01 Jan 0001 00:00:00 +0000

Dec 2025 – Present

Development of an experimental, multi-tenant ERP solution, built on top of Frappe Framework and ERPNext, implementing custom modules and integrating with third-party services.

Python
Frappe Framework
ERPNext
Web Development

Feb 2025 – Nov 2025

Development of a web service for document analysis and information extraction with Python and Clojure, integrating LLMs, OCR and natural language processing techniques to enhance data processing capabilities, as well as managing cloud infrastructure on AWS for scalable deployments.

Python
Clojure
LangChain
Large Language Models
Optical Character Recognition
Amazon Web Services

Dec 2023 - Jan 2025

Mainentance of a custom Linux environment used for coding exams in the university's computer labs, ensuring system stability and cheating prevention.

Linux
System Administration
Bash
Shell Scripting

Douglas Domingos :: CompSci@UFCG

My First Thoughts on Fedora Linux

Introduction

The first contact

Software compatibility

Support and resources

TL;DR

Creating a Multiboot USB Drive with Ventoy

Introduction

How Ventoy works?

Using Ventoy on Linux

Installing Ventoy on a USB drive

Booting up the USB drive

Considerations about Secure Boot

Conclusion

Automating tasks with Github Actions

Introduction

What are GitHub Actions?

Setting up an workflow

Workflow structure

Example 1: Automating tests for pull requests made to the `main` branch

Example 2: Scheduled updates of a repository

Conclusion

Installing software in Linux, the "hard" way

Introduction

I. Housing the package

II. Make your package avaliable with `$PATH`

Adding a Symlink to the executables

Trade-offs of using symlinks

Adding the package directory to `$PATH`

Trade-offs of using `$PATH`

III. Updating the desktop menu (BONUS)

Summary

Conclusion

About me

Personal projects

Professional Experiences

Backend Developer

Software Engineer Intern (R&D)

Linux System Administrator

Douglas Domingos :: CompSci@UFCG

My First Thoughts on Fedora Linux

Introduction

The first contact

Software compatibility

Support and resources

TL;DR

Creating a Multiboot USB Drive with Ventoy

Introduction

How Ventoy works?

Using Ventoy on Linux

Installing Ventoy on a USB drive

Booting up the USB drive

Considerations about Secure Boot

Conclusion

Automating tasks with Github Actions

Introduction

What are GitHub Actions?

Setting up an workflow

Workflow structure

Example 1: Automating tests for pull requests made to the main branch

Example 2: Scheduled updates of a repository

Conclusion

Installing software in Linux, the "hard" way

Introduction

I. Housing the package

II. Make your package avaliable with $PATH

Adding a Symlink to the executables

Trade-offs of using symlinks

Adding the package directory to $PATH

Trade-offs of using $PATH

III. Updating the desktop menu (BONUS)

Summary

Conclusion

About me

Personal projects

Professional Experiences

Backend Developer

Software Engineer Intern (R&D)

Linux System Administrator

Example 1: Automating tests for pull requests made to the `main` branch

II. Make your package avaliable with `$PATH`

Adding the package directory to `$PATH`

Trade-offs of using `$PATH`