DEV Community: Ilean Monterrubio Jr

Building a Terminal Text Editor: The View (Part 3)

Ilean Monterrubio Jr — Mon, 06 Apr 2026 00:00:00 +0000

Recap

In Part 1, I talked about the origin of this project, the early architectural decisions, and why I picked the GapBuffer with IBuffer as the contract for all future buffer implementations. In Part 2, we got into the details of the Presenter, how it wires the components together, handles user input, manages state, and keeps the Model and View in sync. Now we can move on to the View.

What is the View?

The View is the component that the user interacts with directly. All user inputs are collected and passed to the Presenter, the View doesn't decide what to do with them. It is also responsible for rendering the text the user types, along with any warnings, statistics like word count, and whether the file is unsaved. The View doesn't calculate any of this, it just displays whatever the Presenter sends it. Another example of how all three parts of the Model-View-Presenter separate concerns.

Why FTXUI instead of ncurses

In the proof of concept testing, I used ncurses, the de facto standard library for building terminal interfaces. It worked well for the initial testing, and I see a lot of projects still using it; it's tried and true. While ncurses would have been a great choice, I did a bit more research and found FTXUI, a modern C++ library with components to build interactive terminal user interfaces. I wanted to leverage that it uses modern C++, matching the project's early defined specification of targeting C++20.

The IView Interface

While implementing the other components (Model and Presenter), I mocked up a thin interface for the View, IView. At first, it was only taking character input and not accounting for special characters, and it didn't handle rendering any data. The proof of concept View just took the input, sent it to the Presenter, which would send it to the buffer and log it so I could see the data was actually flowing through the system.

I was thinking of removing it, but after doing more research, I decided to expand the interface instead. Keeping IView as an abstract class means that if someone wants to write their own View for an OS that isn't supported by FTXUI, they can implement the interface and plug it in without touching the Presenter or Model.

class IView {
  public:
    virtual ~IView() = default;

    virtual void run(std::function<void(const InputEvent &)> onInput) = 0;
    virtual void render(const ViewState &state) = 0;
    virtual void exit() = 0;
    virtual std::pair<int, int> getTerminalSize() const = 0;
    virtual void showMessage(const std::string &message, bool isError = false) = 0;
};

A quick explanation, run() starts the event loop and takes a callback for handling input, this is what the Presenter calls in its main loop. render() takes the ViewState we saw in Part 2 and draws it to the screen. exit() and getTerminalSize() do what they say, and showMessage() is how the Presenter displays warnings like the "unsaved changes" prompt from the exit flow.

Rendering the UI

As we showed in Part 2, the ViewState struct defines the contract for how the Presenter sends data to the View:

struct ViewState {
    // Content
    std::string visibleText; // Text currently visible in viewport
    int cursorPosition; // Linear position of cursor in visibleText

    // Status bar information
    int wordCount; // Total word count (primary metric for writers)
    std::string filename; // Current file name (or "Untitled")
    bool isDirty; // Unsaved changes indicator

    // UI state
    std::string statusMessage; // Temporary status message (e.g., "Saved", "Error: ...")
    bool showHelp; // Whether to show help overlay
};

There are three major types of data in the ViewState contract: Content , which tells us the cursorPosition and the visibleText. Status bar information : wordCount, filename, and isDirty which indicates whether the file is unsaved. Finally, the UI state : statusMessage and showHelp.

One of the biggest challenges was how to deal with the cursor, how to move it, and be able to add more to the buffer when the cursor moves. One of the simplest solutions is to break the visibleText into three components: beforeCursor, cursor, and afterCursor.

ftxui::Element FtxuiView::renderEditor() {
    const auto &text = currentState.visibleText;
    const size_t pos = static_cast<size_t>(currentState.cursorPosition);

    auto before = ftxui::text(text.substr(0, pos));

    // Character at cursor with cyan background
    std::string cursorChar = pos < text.size() ? std::string(1, text[pos]) : " ";
    auto cursor = ftxui::text(cursorChar) | ftxui::bgcolor(ftxui::Color::Cyan) | ftxui::color(ftxui::Color::Black);

    auto after = pos + 1 < text.size() ? ftxui::text(text.substr(pos + 1)) : ftxui::text("");

    return ftxui::hbox({before, cursor, after});
}

The cursor is highlighted with a cyan background so the user can see where they are in the text. This challenge existed in both ncurses and FTXUI, neither library gives you a built-in cursor for a custom text editor. You have to simulate it yourself.

Translating Keyboard Input

The View is also responsible for translating raw keyboard events into the InputEvent structs that the Presenter understands. FTXUI has its own event system, so the View needs a translation layer between what FTXUI gives us and what our Presenter expects. The translateEvent() method handles this mapping:

InputEvent FtxuiView::translateEvent(const ftxui::Event &event) {
    if (event == ftxui::Event::ArrowLeft)
        return {InputEvent::Type::ARROW_LEFT};
    if (event == ftxui::Event::ArrowRight)
        return {InputEvent::Type::ARROW_RIGHT};
    if (event == ftxui::Event::Backspace)
        return {InputEvent::Type::BACKSPACE};
    if (event == ftxui::Event::Return)
        return {InputEvent::Type::ENTER};
    if (event == ftxui::Event::CtrlQ)
        return {InputEvent::Type::CTRL_Q};
    if (event == ftxui::Event::CtrlS)
        return {InputEvent::Type::CTRL_S};

    // Printable character
    if (event.is_character()) {
        InputEvent ie{InputEvent::Type::CHARACTER};
        ie.character = event.character()[0];
        return ie;
    }

    return {InputEvent::Type::UNKNOWN};
}

The pattern is straightforward, each FTXUI event maps to one of our InputEvent types. If it's a printable character, we extract the character value. If we don't recognize the event, it returns UNKNOWN and gets ignored. This is the same translation layer that would need to be reimplemented if someone wrote a new View using a different library, another benefit of the IView interface.

What the View Can Do So Far

The View works well for the current state of the project. It renders text as the user types, displays the status bar with the filename, word count, and unsaved changes indicator, captures all input events and routes them to the Presenter, and toggles the help overlay with F1. It is not perfect, newlines don't render yet and the arrow keys can't fully navigate up and down through the text. But for Phase 1, it does its job as the passive layer in the MVP pattern.

Wrapping Up the Series

This wraps up the three-part series on building wordNebula's Phase 1. Across these posts, we went from the origin of the project and why I chose Model-View-Presenter, through the Model with the GapBuffer and IBuffer interface, the Presenter that orchestrates everything and manages state, and finally the View that renders it all to the terminal.

Building each layer independently and connecting them through contracts like IBuffer and IView made the project manageable. I could work on one piece at a time without worrying about breaking the others. That separation is the whole point of MVP, and it paid off.

Phase 1 is complete but far from finished. There's more to build, but for now I'm stepping away to focus on other projects. If you want to explore the code, check out the project on GitHub.

Building a Terminal Text Editor: The Presenter (Part 2)

Ilean Monterrubio Jr — Sun, 22 Mar 2026 00:00:00 +0000

Recap

In Part 1, I talked about the origin of this project and the early architectural decisions. After picking Model-View-Presenter, breaking up the project into Model, View, and Presenter felt like the natural path forward. We tackled the GapBuffer with IBuffer as the contract for all future buffer implementations. With the Model standing on its own, we can move on to the Presenter.

What is the Presenter?

We already hinted in Part 1 that the Presenter is the orchestrator — the one that handles all the application's "business" logic. It is responsible for keeping both the Model and the View up to date. The Presenter takes user input from the View and passes it to the Model, then pulls the updated data from the Model and sends it back to the View for rendering. All communication between the two goes through the Presenter.

Let's take the most common use case of a user pressing a single key stroke. In reality, they will be typing several in succession, and this process gets repeated constantly in the current implementation.

Step	From	To	What Happens
1	User (actor)	View	Presses key
2	View	Presenter	Passes the key event
3	Presenter	Model	Calls insertChar()
4	Presenter	Model	Requests updated text
5	Presenter	View	Sends text to render

We see the big role that the Presenter fills and we will explore how we created contracts between the components to ensure that data is passed correctly. For wordNebula, this also means the Presenter will be where future logic lives.

Wiring It Together

Since this project is using modern C++ I wanted to take advantage of smart pointers and leverage Resource Acquisition Is Initialization (RAII). This way we don't have to explicitly manage memory — this is standard practice in modern C++ for any systems project.

When starting to wire up the different components, including the mock View from the original testing I did before tackling the full project, I had to make some decisions on ownership. Here is how the three components get created in main:

const auto presenter = std::make_shared<WNebulaPresenter>();
const auto model = std::make_shared<WNebulaModel>();
const auto view = std::make_shared<FtxuiView>();

presenter->setup(view, model);
presenter->run();

All three are created as shared_ptr, but inside the Presenter they are stored differently:

std::weak_ptr<IView> view;
std::shared_ptr<WNebulaModel> model;

The Model stays as a shared_ptr because the Presenter needs to own it — it is the core data and must exist as long as the application is running. The View is stored as a weak_ptr to break a circular dependency. The Presenter needs the View to push updates, and the View needs the Presenter to send input. If both held shared_ptr to each other, neither would ever get cleaned up.

The trade-off with weak_ptr is that every time the Presenter needs to update the View, it has to convert it back to a shared_ptr temporarily by calling lock(). If the View still exists, lock() gives us a valid shared_ptr to work with. If it doesn't, we know the View is gone and can handle it gracefully. This happens inside updateView() every time the Presenter needs to render new data to the screen.

Handling User Input

In the exploratory testing, I only worried about character user input — it was just to test if I understood the architecture. For the real implementation, I needed to actually account for special keys: CTRL, BACKSPACE, DELETE, ARROW KEYS, ENTER, and so on.

To handle this cleanly, I created an InputEvent struct that translates raw keyboard input into semantic events:

struct InputEvent {
    enum class Type {
        CHARACTER,
        ARROW_LEFT, ARROW_RIGHT, ARROW_UP, ARROW_DOWN,
        CTRL_LEFT, CTRL_RIGHT, CTRL_UP, CTRL_DOWN,
        HOME, END,
        BACKSPACE, DELETE, ENTER,
        CTRL_S, CTRL_Q,
        ESCAPE,
        // ... other types
    };

    Type type;
    char character = '\0'; // Only valid for Type::CHARACTER
};

This way the Presenter doesn't care about terminal escape codes — it just receives an event type and acts on it. The handleInput method routes each event to the right operation:

void WNebulaPresenter::handleInput(const InputEvent &event) {
    switch (event.type) {
    case InputEvent::Type::CHARACTER:
        onInsert(event.character);
        break;
    case InputEvent::Type::BACKSPACE:
        onDelete();
        break;
    case InputEvent::Type::CTRL_LEFT:
        onCtrlLeft();
        break;
    case InputEvent::Type::CTRL_Q:
        onExit();
        break;
    // ... other cases
    }
}

Each operation follows the same pattern — delegate to the Model, mark dirty if needed, update the View:

void WNebulaPresenter::onInsert(char c) {
    model->insertChar(c);
    isDirty = true;
    updateView();
}

Viewport Management

One of the things I learned along the way, or had to really think about, was the viewport. So far, the initial testing was me writing simple sentences, not full blog entries or longer format text. The area of the terminal is finite, so determining what portion of the buffer to display and how to present it was a challenge.

The Presenter solves this by building a ViewState — a struct that packages everything the View needs to render:

struct ViewState {
    std::string visibleText;
    int cursorPosition;
    int wordCount;
    std::string filename;
    bool isDirty;
    bool showHelp;
};

Every time the Presenter updates the View, it pulls the current text and cursor position from the Model and sends it as a ViewState. The View doesn't know anything about the buffer — it just renders whatever state it receives. Here is the updateView() method that builds and sends that state:

void WNebulaPresenter::updateView() {
    if (auto v = view.lock()) {
        ViewState state{};
        state.visibleText = model->getText();
        state.cursorPosition = model->getCursorPosition();
        state.wordCount = model->getWordCount();
        state.filename = currentFilePath.empty() ? "Untitled" : currentFilePath;
        state.isDirty = isDirty;
        state.showHelp = showHelp;
        v->render(state);
    }
}

Notice the view.lock() — this is the weak_ptr conversion we talked about in the Wiring section. Every time the Presenter needs to update the View, it checks that the View still exists before sending data.

State Management

For managing state in this iteration of the project I kept it simple. The Presenter tracks a few boolean flags — isDirty to know when the file hasn't been saved, isRunning to control the main loop, showHelp to toggle the help overlay, and exitWarningShown for the quit confirmation.

The most interesting one is the exit flow. If you have unsaved changes and press Ctrl+Q, the Presenter warns you and makes you press it again to actually quit:

void WNebulaPresenter::onExit() {
    if (isDirty && !exitWarningShown) {
        exitWarningShown = true;
        if (auto v = view.lock()) {
            v->showMessage("Unsaved changes! Press Ctrl+Q again to quit.", true);
        }
        return;
    }
    isRunning = false;
    if (auto v = view.lock()) {
        v->exit();
    }
}

What the Presenter Can Do So Far

At this stage, the Presenter takes in all input events and determines if it is a special key or character, fully manages the state of the application and document, and keeps the Model and View in sync. It is the glue between the two, and because of MVP, it can be tested independently.

What's Next

In Part 3, I will talk about why I picked FTXUI instead of ncurses and what it offers out of the box that made the View layer easier to build. You can check out the project on GitHub.

Building a Terminal Text Editor: The Model (Part 1)

Ilean Monterrubio Jr — Sat, 07 Mar 2026 00:00:00 +0000

The Idea

The idea for wordNebula came from seeing an interview with George R.R. Martin, where he talks about how he writes his books on a really old computer because his preferred word processor can't run on anything new. After finding out that the program is called WordStar, and some minor Googling, I saw it was entirely terminal-based, and thought that idea was novel.

Growing up in the 90s, I went to an elementary school that gave us weekly computer lab time. I got the chance to use 5.25" floppy disks to play text-based games, and later learned to use the Macintosh computers and play the new versions of The Oregon Trail. So I can see how a writer can feel nostalgic and want to keep using a tool — if it's not broken, why change it?

I am also a software engineer who has used Vim and Neovim, and I see why they have such great appeal. Those tools keep improving and staying up to date, and they are great at being distraction-free, keeping the user's focus on the task at hand.

Why Build Another One?

Starting this project, I did a bit of research. Terminal word processors already exist. The open-source one I found is called WordGrinder — it has been around for a while and is written in C and Lua. It is a great project; check it out if you have the time. While terminal word processors are no longer popular, many writers still use them for the limited distraction and focus they offer.

Honestly, I just thought it was something cool to build, and I just wanted something to work on for me. The overall stretch goal is to make wordNebula a full writer's tool — it would format the output for the user based on a config file or similar setup. The idea is that playwrights and screenwriters could fully write without any distraction or worrying about formatting, and novelists could structure their work by chapter. But that is the future; for now, it is a portfolio project that lets me explore terminal UI development, data structures, and architecture patterns in C++.

Choosing an Architecture

For this project, I decided early on to use modern C++ targeting C++20. Before diving into implementation, my first architectural decision was choosing a pattern: Model-View-Controller (MVC), Model-View-Presenter (MVP), or the newer Model-View-ViewModel (MVVM).

Here is a quick comparison:

Aspect	Model-View-Controller	Model-View-Presenter	Model-View-ViewModel
Mediator	Controller	Presenter	ViewModel
View Role	Active, interacts with Model directly	Passive, passes data to Presenter	Passive, data is bound to ViewModel
Data Binding	Manual updates	Manual, Presenter sends to Model	Automatic via data binding
Testability	Low	Good	Best
Separation	Basic	Better	Best
Best For	Small projects	Medium to complex	Large, data-driven UIs

After researching these patterns and studying block diagrams, I picked Model-View-Presenter. The main reason is that it completely separates all three concerns:

The Model is the text buffer. Its only job is maintaining the buffer — storing text, tracking the cursor, and supporting insertions and deletions.
The View handles the UI layout, how the data is displayed, and capturing the user's key inputs, which it passes to the Presenter.
The Presenter is the orchestrator. It receives input from the View, passes text operations to the Model, then requests the updated data from the Model to refresh the View.

All communication flows through the Presenter. This is the main reason the architecture is testable — and while we all know unit tests aren't fun, we understand why they're important.

Getting My Hands Dirty

With the architecture decision made and the clean separation of concerns giving me the ability to work on different parts of the project independently, I started with a simple proof of concept. I implemented a basic Model text buffer that accepts keystrokes and prints to a log file. It wasn't perfect, but it got me to understand the basic structure and play a bit with MVP before committing to the full implementation.

For this I set up what I called a TextBuffer, which was just a string where I added things to it via a simple Presenter and View with ncurses. I had Copilot help me test it, and what I learned was that I should really start the project by implementing the Model first — it is such a critical part of the project, and it prompted me to do more research on how word processors handle their buffers.

The Model: Choosing a Data Structure

I started doing research on text buffers and saw some really appealing ones. One was the Gap Buffer, which I believe Emacs uses. Another was the Piece Table, used by Microsoft Word, and I found a blog from the VS Code team about their usage of it and their findings: Text Buffer Reimplementation.

After observing this and understanding the differences between them, I picked the Gap Buffer for the initial implementation. This decision became clear once I started to define the use cases — since this is a terminal-based UI, users probably won't be highlighting and removing large chunks of text, so undo and redo can be implemented much later. And also a key difference from any modern code editor: we don't need multiple cursors, only a single one where the user can add to the document.

The idea behind a Gap Buffer is straightforward. You have an array with a "gap" of empty space that follows the cursor around. When you type, you drop characters into the gap. When you move the cursor, the gap moves with it. Here is what that looks like:

Before: [H][e][l][l][o][___GAP___][W][o][r][l][d]
                        ^ cursor

Insert ',':
After: [H][e][l][l][o][,][__GAP__][W][o][r][l][d]
                           ^ cursor

The core of the insertion is simple — move the gap to the cursor, make room if needed, and drop the character in:

void GapBuffer::insertChar(char c) {
    moveGapToCursor();

    if (getGapSize() < 1) {
        expandGap();
    }

    buffer[gapStart] = c;
    gapStart++;
    cursor++;
}

It was also key to use interface abstract classes to make sure I could update the buffer if I ever make a new implementation. This was very important to me because moving into the future we might need flexibility — being able to add undo/redo, or add styling. I was so unsure early on that I thought having that flexibility was very important to have.

The IBuffer interface defines the full contract that any buffer must fulfill. Here is a trimmed version showing the method signatures:

class IBuffer {
  public:
    virtual ~IBuffer() = default;

    // Text Operations
    virtual void insertChar(char c) = 0;
    virtual void insertText(const std::string &text) = 0;
    virtual void deleteChar() = 0;
    virtual void deleteForward() = 0;

    // Text Access
    virtual std::string getText() const = 0;
    virtual std::string getTextRange(int start, int length) const = 0;
    virtual int getLength() const = 0;

    // Cursor Management
    virtual int getCursorPosition() const = 0;
    virtual void setCursorPosition(int position) = 0;
    virtual void moveCursor(int offset) = 0;

    // Smart Navigation
    virtual int findNextWordBoundary(int fromPos) const = 0;
    virtual int findPrevWordBoundary(int fromPos) const = 0;
    virtual int findNextParagraph(int fromPos) const = 0;
    virtual int findPrevParagraph(int fromPos) const = 0;

    // Statistics
    virtual int getWordCount() const = 0;
    virtual int getParagraphCount() const = 0;
};

With this interface, if I ever need to swap in a Piece Table for advanced undo/redo support down the road, I can do it without rewriting the Presenter or View. The full interface with detailed Doxygen documentation is in the repository.

What the Model Can Do So Far

The Model can fully add text at the cursor position, and the gap can grow dynamically. It supports full cursor navigation, text insertion and deletion, word count, and paragraph count. It also has a comprehensive test suite with Google Test. The Model stands on its own — it was built and tested before the Presenter or View ever existed.

What's Next

In Part 2 I will go over the Presenter, which takes the Model and orchestrates everything — coordinating between the buffer and the UI, and managing application state. The Presenter and View are already implemented; you can check out the project on GitHub.

I2C Driver and Simulation

Ilean Monterrubio Jr — Mon, 03 Feb 2025 00:00:00 +0000

Throughout my career, I have worked extensively with microcontrollers and systems on chips (SoCs). These devices often need to communicate with peripherals using protocols such as UART, I2C, SPI, and 1-Wire (W1). These are short-range communication protocols primarily used for interfacing with peripheral devices.

Common peripherals in microcontroller-based projects include real-time clocks (RTC), digital-to-analog converters (DACs), and analog-to-digital converters (ADCs), among others. Whether you're a hobbyist or a professional engineer, mastering these communication protocols is essential for successfully working with embedded systems.

In this blog entry, I will focus on the I2C protocol and how to emulate its read and write functions. I2C is a widely used two-wire protocol that allows multiple devices to communicate over the same bus. Each I2C device has an address, which is either predefined by the manufacturer or, in some cases, configurable by the user or system architect.

When a microcontroller or microprocessor needs to read from or write to an I2C device, it sends the device’s address along with a read or write bit. It then specifies the registers address range it wants to access. Understanding this process is fundamental to effectively integrating I2C peripherals into embedded systems.

Description of I2C Sequence

To understand how I2C transmits data, we’ll focus on the logical sequence rather than the physical wiring aspects.

I2C communication begins with a Start condition , signaling to all connected devices that the master intends to communicate. This is followed by the Address frame , which can be either a 7-bit or 10-bit address, depending on the device specifications. Each device on the bus checks the incoming address and only responds if it matches its own; all other devices ignore the transmission.

Next, the Read/Write (R/W) bit is sent. This bit determines whether the master intends to write (0) or read (1) from the addressed device. The addressed device then responds with an ACK (Acknowledge) or NACK (Not Acknowledge) bit to confirm whether it has successfully recognized the request.

Once acknowledged, data transfer begins in 8-bit (1-byte) sequences. After each byte, the receiving device sends another ACK/NACK bit to indicate whether it successfully received the data. This process continues until all required data has been transmitted.

Finally, the communication ends with a Stop condition , signaling that the bus is now free for other devices.

I2C Data Transfer Sequence

Start Condition – Signals the beginning of communication
Address Frame – Specifies the target device (7-bit or 10-bit)
Read/Write (R/W) Bit – Defines the direction of data transfer (0 = Write, 1 = Read)
ACK/NACK Bit – Confirms receipt of the address by the device
8-bit Data Transmission – Data is sent in 8-bit sequences
ACK/NACK Bit – Acknowledges each byte transfer
Stop Condition – Ends the communication session

By following this structured approach, I2C enables efficient multi-device communication using just two wires.

Emulation of I2C

For this emulation, we will focus on reading and writing a single byte of data while covering the key components of the I2C protocol: the Address Frame, Read/Write Bit, and 8-bit Data Transmission.

In our approach, we will perform two 8-bit data transmissions :

Register Address – Specifies which register we want to access within the device.
Data – The actual data being written or read from the specified register.

Understanding Registers

If you're unfamiliar with registers, think of them as small, high-speed storage locations within hardware. They function similarly to RAM but are much faster and operate at a lower level. Registers are essential for configuring and controlling hardware devices.

Each I2C device has predefined register addresses, which are typically found in the device’s datasheet. However, for simplicity, our emulation will use a structured data representation instead of referencing a real datasheet. The goal is to ensure we correctly read and write data within our emulated environment.

I2C Data Structure

To emulate an I2C device, we will use a simple data structure that mimics the essential components of an I2C transaction. This structure will allow us to simulate reading from and writing to an I2C device.

Data Structure

The following structure represents the key elements involved in I2C communication:

uint8_t: device_address
uint8_t: register_address
uint8_t: data

Write Sequence

To simulate writing data to an I2C device, we follow these steps:

Add the Write Bit to the Address
- The device address is bitwise shifted, and the write bit (0) is appended.
Initialize Local Variables
- Prepare the payload, including the device address and register to write to.
Set Up the Emulated I2C Data Structure
- Assign the device address and register address.
- Clear previous data before writing new data.
Mock the Hardware Write
- Since each embedded platform has unique I2C functions, we emulate this by verifying the address in our data structure and writing the data accordingly.

Read Sequence

To simulate reading data from an I2C device, we follow these steps:

Add the Read Bit to the Address
- The device address is bitwise shifted, and the read bit (1) is appended.
Initialize Local Variables
- Prepare the payload and send the read request to the emulated device.
Set Up the Emulated I2C Data Structure
- Assign the device address and register address.
- Ensure previous data is cleared before reading new data.
Mock the Hardware Write (For Register Selection)
- Before reading, an I2C device typically expects a write operation to set the register address.
- This step emulates sending the register address before reading data.
Mock the Hardware Read
- Read the data from the structure and verify that it matches the expected value.

Closing Note

This exercise is a great way to deepen your understanding of the I2C protocol and demonstrate your knowledge practically.

You can find my implementation on my GitHub account. The repository includes a development container (dev container) for easy setup, allowing you to run the project seamlessly in a pre-configured environment. Additionally, I've provided a CMakeLists.txt file, ensuring cross-platform compatibility while keeping the implementation purely in C for maximum portability.

Feel free to explore, run, and modify the code! 🚀

My First Hackathon Experience: A Journey Back to the 90s

Ilean Monterrubio Jr — Tue, 24 Dec 2024 00:00:00 +0000

I had never participated in a hackathon before this year, but thanks to Eric from Houston Code and Coffee, who encouraged me to step out of my comfort zone, I decided to give it a shot. The event was hosted by Codédex , and the theme couldn’t have been more nostalgic: building a website inspired by the 90s.

As someone who grew up in the 90s and vividly remembers spending time on elementary school computers, and surfing the web during the early days of the internet, this theme struck a personal chord with me. It felt like a perfect opportunity to relive those simpler times while flexing my creative muscles.

Choosing the Track: Reimagining My Personal Website

The hackathon offered two tracks:

Reimagine a Company Website: Adding a 90s twist to a modern company’s website.
Create a Personal Website: Designing a website that reflects your personality with a 90s vibe.

I opted for the personal track, deciding to revamp a portion of my current professional website. To prepare, I dove into a rabbit hole of nostalgia, exploring personal websites preserved by the Wayback Machine and web archives. It was fascinating to see how people expressed their creativity in the era of low resolutions, tiled backgrounds, and vibrant animations.

Design Decisions: A Tribute to 90s Aesthetics

Here are some of the elements I incorporated into my design:

Tiled Backgrounds: I used a repeating star pattern to capture the classic 90s look.
Neon and Clashing Colors: These were essential to evoke the chaotic yet charming visual style of the decade.
GIF Animations: Scaled-up, pixelated animations added movement and energy to the site.
Fixed Resolution: I emulated a resolution of 800x600 pixels so that the site scaled up and maintained its fixed proportions.

The process of building the website took me back to my middle school days when I first learned HTML and CSS in our computer lab. It reminded me of the joy of experimenting with simple yet effective designs. Although I wouldn’t call myself the most imaginative web designer, this hackathon pushed me to think outside the box and experiment with ideas I hadn’t considered before.

Live Demo

Observations and Shoutouts

I want to give a big shoutout to the Codédex team for organizing such an inclusive and beginner-friendly event. They went above and beyond to ensure participants of all skill levels felt welcome. Here’s what stood out:

Comprehensive Workshops: They offered live crash courses in HTML, CSS, JavaScript, and web design.
Helpful Resources: From asset recommendations to hosting service tips, they equipped us with everything we needed to succeed.
Community Spirit: The opening and closing ceremonies fostered a sense of belonging and celebration.

Overall, the hackathon was a fantastic experience. It allowed me to learn, create, and connect with like-minded individuals while indulging in a wave of nostalgia. I’m excited to participate in more hackathons in the future and continue exploring new ideas.

Finding Community in Houston’s Tech Scene

Ilean Monterrubio Jr — Thu, 31 Oct 2024 00:00:00 +0000

Since my layoff in early September, I've been navigating the tech landscape in Houston and documenting my observations along the way. Surprisingly, Houston offers much more in technology than I initially expected. While it’s known globally as the Oil & Gas capital, Houston has a growing tech scene where companies and events span multiple industries, not just energy.

In my search, I found the Ion District, a collaborative tech hub that hosts various events almost daily. To get started with networking, I’ve attended a few groups, mostly at the Ion and the Improving offices—a software development and IT consultancy with an inviting space for meetups and community events.

In my effort to start networking, I have attended three different groups. Two are hosted at the Ion, and the other is at the Improving offices. Improving is a software development and IT consultant company hosting several Meetup groups related to software. They have a dedicated room for these events with free drinks and snacks. This is a step in the right direction to foster innovation and, more importantly, have the innovation stay in Houston.

Events

Given my background in Electrical Engineering and Computer Science, the groups I have attended reflect areas of interest and things I have done in my career. The events are very inclusive, which is excellent. It shows how diverse Houston is and that it accepts everyone as they are.

Code & Coffee

Website

Meetup

Held: Monthly on Sunday

This is the first group I attended. I can be social, but getting out of my comfort zone takes effort. I did get out of my comfort because the first meeting was about 90% first-time attendees. The meetings usually start with everyone signing in and getting a name tag and some time for mingling. Once Eric, the host, gives a short introduction along with the Improving host, which offers a quick rundown about the company (which, in reality, is about a minute, which is brief, in my opinion). The introduction ends with a group circle where we introduce ourselves to each other. After that, it is more mingling; you can work on a project together if someone has one.

This group is very inclusive, both in its diversity and in welcoming new learners and seasoned veterans. There is even a professor who attends and sets up an area of the room where learners can ask questions and work through it together. So bring your computer if that is the case.

Houston Robotics Group

Website

Meetup

Held: Weekly on Saturday

This group is more of a working session, and people come to work on robotics projects. You walk in and meet as many people as you like. If you still need to get a robot project, no pro; the event organizers lend you a kit and set up the beginners to learn to assemble it. They also lend you an Arduino and show beginners how to code the LED blinking light. All levels of robotic enthusiasts are welcome. While yes, there are season roboticists, most of the attendees are University students working on improving skills and knowledge who are happy to help.

Typically, the attendees pick a restaurant for dinner after the meeting, a short ride on the Metro Rail.

Cup of Joey

Website

Held: Weekly on Friday

This is the only general or business networking event I have attended. You sign in and get a name sticker, but you do not write down your name; you write down your purpose in life. Recommendation: Have something in mind before attending. I did not know and was thrown off for a few minutes while I thought of something. Overall, it is just a networking event. Having your purpose on the name tag makes it easier to strike up conversations. You will see the diversity of Houston in this group the most, from the different industries and people of all ages connecting and finding discussions.

Ending Notes

While these are the few I picked to attend, there are more software meet-ups in Houston. Most might be in the Improving offices, and you can find them via the Meetup app.

Those are the ones I have seen; I am sure more exist. Just doing a deep search on apps like Meetup, Eventbrite, and others will show how many more there are.

Beyond the Blinky LED: Building a Command Interpreter for Microcontrollers

Ilean Monterrubio Jr — Thu, 31 Oct 2024 00:00:00 +0000

The blinky LED project is simple: you connect an LED to a digital output pin and add a resistor in line with either the positive or negative terminal. By adjusting the resistor, allows you to control the LED's brightness based on its color and voltage needs. This beginner project gives you a hands-on understanding of how code can control real-world objects.

You completed this project and are now looking for the next one. The next step is to build a command interpreter.

A command interpreter allows you to type commands into your microcontroller and get a response in real-time—just like the terminal on your computer. With this project, you'll build a simple command interpreter that lets you control your microcontroller interactively, a skill commonly used in embedded systems for testing and debugging.

What you will learn

The reason this is an excellent next project is because you will need to learn and understand:

Serial Communication : Transmitting data between your microcontroller and computer.
Setting Baud Rate : Defining the speed for data transmission.
Line Termination : Ensuring that each command the microcontroller understands you type.
Working with Serial Emulators : Testing commands directly from your computer.
String Parsing and Comparison : Break down commands and check them against defined instructions.
State Machine Programming : Creating a structured way for your program to handle different commands logically.

Recommended commands

Set a few commands in your microcontroller command interpreter.

help - Lists available commands. Example: help displays all commands with short descriptions.
echo - Repeats the text you type. Example: echo Hello responds with "Hello."
analog-read - Reads an analog value from a specified channel. Example: analog-read 1 gives a reading from channel 1.
digital-on - Turns a digital output ON. Example: digital-on 2 turns on channel 2.
digital-off - Turns a digital output OFF. Example: digital-off 2 turns off channel 2.

Wrap up

This project is a solid introduction to building embedded command interpreters. As you set up each command, you’ll get a feel for reading analog inputs, controlling digital outputs, and managing serial communication. Even in more advanced systems, serial communication is a reliable and efficient method for testing, debugging, and even real-time control in industrial applications.

With each command you add, you’re expanding your microcontroller’s capabilities. Dive in, experiment, and enjoy the process!