DEV Community: Dev_Vaayen

Presenting Locust-Orchestrator For Executing Exhaustive Load-Plans

Dev_Vaayen — Sat, 21 Mar 2026 19:26:46 +0000

Hi Everyone... I am a DevOps & QA Engineer and I have been working on performance testing, as of late.

While using Locust, I kept on thinking how nice it would have been if I could just perhaps input a CSV file with all things such as concurrent users, ramp-up and duration because in comparison and to this point, I had to key in all these individual items after each completion of the Load-Test.

To combat this, I created a custom Locust Orchestrator to execute all of my test-plans in the background and let the reports get saved, for later reviews.

Locust Orchestrator

GitHub: https://github.com/dev-vaayen/locust-orchestrator

It's a plain Python CLI, which allows us to specify a complete load test plan and run one after another with reports saved locally without any manual intervention in-between.

What My Project Does:

Performs several load tests based on a CSV file
Prepares an HTML report on each test
Logs when each test starts

The plan.csv that is fed into the orchestrator works like this:

users, spawn_rate, duration
100, 10, 2m
500, 50, 5m
200, 20, 3m

This tool pretty much builds on-top of Locust and runs Locust under the hood, meaning that the usual locust related flags can also be used.

I have been using this custom-orchestrator to execute my own test plans in the background and for viewing the results at a later stage rather than monitoring each run live and manually inputting Test-Configs.

Future plans currently include:

Combined reports in html
History tracking using sqlite db
Maybe a small dashboard using streamlit

I would also like to understand whether this tool can be beneficial to other people as well and what other ideas that you might like seeing implemented in here. In my head maybe it goes without saying but still, please do consider contributing your own ideas as well by visiting the GitHub repository for this at https://github.com/dev-vaayen/locust-orchestrator

[DevLog #02] Gmail-TUI: Replicating Gmail-Web's Navigation

Dev_Vaayen — Thu, 21 Nov 2024 21:56:10 +0000

Thanks to all the kind support on the previous DevLog, I am back with the latest update on my Gmail-TUI application! If you are not aware of this OpenSource project, I am developing a Terminal based UI application that aims to replicate the Gmail-Web experience in terminal, without the need of a Web-Browser:

Read DevLog #01
Contribute in Project's GitHub Repository

Replicating Gmail-Web's Navigation

While the implementation of the Inbox feature is still a work in-progress, I have implemented a better navigation system within the Gmail-TUI than it's previous version - as can be seen above.

In the earlier version, user would directly be prompted to compose a mail and send it, since that was the only feature available at that time. After the recent modifications however, a basic blueprint has been laid for how a User would be able to navigate within this application:

Login-Screen is now shown as the main-page
After a successful-login, Dashboard is displayed with possible options for Composing Mails (Implemented) and Viewing Inbox, Starred and Draft mails (WIP)
Upon selecting the desired option, user is led to a new page for performing option related operations
Exit & Back options have been provided in appropriate pages for a better user-experience

A successful login is currently being validated by sending a 'Login-alert' mail to the person trying to log in. If the email-password does not match, then the 'Login-alert' mail will not be sent to the user and they will be prompted to retry again.

As of now, only the Compose options is functional but after the implementation of the IMAP-Protocol, the remaining options will be modified to perform related operations.

Plans For Now

Okay so to recap, I have been able to since the first DevLog, the following functionalities have now been added into the Gmail-TUI:

✅ A login page for entering email-ID and password
✅ Composing and sending mails
[WIP] Listing received emails with email-IDs in the Inbox
[WIP] Opening the content of the received mail after clicking it
[WIP] Viewing sent email in Sent-Box
✅ Area to choose from the Compose, Inbox, Drafts, Sent buttons

Since networking has never really been my strongest point, I have been working on better understanding the IMAP Protocol that is to be used to display emails in User's inbox but sadly for me, I have been struggling with properly grasping the related concepts. Or rather, I feel like I am unnecessarily prolonging the implementation of the Inbox feature by wanting to learn more and more about IMAP because of just how fascinating it's history really is!

I understand how it's to be implemented in the code now but there's a part of me that wishes I would not move on until I understand each and everything about IMAP, which I realise is quite impractical. I mean, what is the point of trying to capture so much knowledge without even trying to implement it somewhere?

Therefore, I have made up my mind: I will be implementing the inbox feature using whatever knowledge that I have gained so far and ensuring that this feature is present in the next version of the Gmail-TUI.

If you liked reading this DevLog and would like to have a closer look at my development process, please consider following me on X, Reddit and GitHub!

[DevLog #01] Gmail-TUI: Replicating The Gmail-Web Experience In Terminal

Dev_Vaayen — Sat, 02 Nov 2024 18:34:45 +0000

Gmail-TUI is a simple TUI application that aims to replicate the Gmail Web-UI in a TUI-Environment. Is this even possible? I don't even know yet but let's find out! Special thanks to Rivo for their TUI Library.

As shown above, today I was able to implement the composing and sending of Emails using this SMTP guide. The source-code is available in the Project-repository and modifying the code to enhance the project is most welcome!

Some Background

As scary as this is for me, here I am trying to do something new with my life: Publicly writing about my project so that I actually end up completing it and also hopefully getting the much needed feedback along the way!

Just a few days after I had installed Ubuntu, I lost the access to the GUI due to a failed and interrupted update. This led to me being forced to use the TTY-environment (started using the ctrl+alt+fkeys combination) and ending up feeling helpless for a long time as I had never used even the most basic Linux commands.

Months later, this experience led me to look into TUI or Terminal based User Interfaces, which run on Terminals and are like lighter versions of GUIs. This is where the idea of creating my own TUI-Application for Gmail came into mind as I was unable find one that could fit my use-case.

Required Features

To complete this lack of TUI-Application, I would like the Gmail-TUI to borderline replicate the web-version of Gmail, allowing users to perform most of the core tasks by providing following features/functionalities in it:

A login page for entering email-ID and password
Composing and sending mails - Implemented today!
Listing received emails with email-IDs in the Inbox
Opening the content of the received mail after clicking it
Viewing sent email in Sent-Box
A small panel on the left side or an area to choose from the Compose, Inbox, Drafts, Sent buttons.

I will be trying to work on the login-page for now, where the user will enter their credentials, click on login and be redirected to the next page where they would be able to compose mails. Like the web-version, showing the Inbox after signing-in should be done but since I am still studying IMPS that will help with receiving emails, I will be using the Compose-mail section as the placeholder for now.

If you enjoyed reading this, do consider connecting with me on X, Reddit and GitHub!