Forem: Anas Abuelhaag

Build for Your Community: CampusOps - Event Management for Student Activities

Anas Abuelhaag — Mon, 02 Mar 2026 00:34:31 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built this for university student activities and campus clubs. Managing events as a student organizer is often chaotic. You have to juggle marketing, logistics, catering, and keeping track of RSVPs—usually scattered across WhatsApp groups, Google Forms, and messy spreadsheets. This app is dedicated to the incredible community of student leaders who tirelessly organize events, workshops, and gatherings on campus, making student life vibrant and engaging.

What I Built

CampusOps is a sleek, premium event management and operation dashboard designed specifically for student organizations to solve the friction of planning events. It provides a centralized hub to manage every aspect of an event without forcing users to go through tedious signup processes.

It features a streamlined three-level access model:

Public View: A beautiful landing page where students can discover upcoming campus events and RSVP seamlessly (with built-in duplicate prevention).
Organizer Dashboard: Accessed via a secure, easily shareable organizer_code, this view gives event staff a real-time Kanban board to track tasks (across teams like Logistics, Marketing, Registration) and manage attendee check-ins.
Admin Control: Accessed via an admin_code, admins can create new events, dynamically generate access codes for their organizing team, and oversee all global operations.
Rapid Deployment Form: From the homepage, any authorized student can 'Initialize a Hub' by filling out a quick, elegant form (event title, date, location, and capacity) to instantly spin up a completely new event dashboard.
Data Portability (Export Everything): At any point during or after an event, organizers can click the Export Excel button in their attendee table to instantly download all RSVP and check-in data to a CSV. This makes it insanely easy to generate post-event reports or sync lists with campus administration.

To top it off, CampusOps features a modern, "liquid glass" neumorphic UI that makes organizing events feel less like a chore and more like a premium software experience.

Demo

You can try out the live web application here: https://campus-ops.vercel.app

Code

Here is the full source code for the project:

a-elhaag / campus_ops

This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.

Learn More

To learn more about Next.js, take a look at the following resources:

Next.js Documentation - learn about Next.js features and API.
Learn Next.js - an interactive Next.js tutorial.

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more…

View on GitHub

How I Built It

CampusOps was built with a modern, full-stack ecosystem:

Framework: Next.js (App Router) for seamless full-stack React development and API routes.
Database: PostgreSQL hosted on Neon, which provided fast, reliable, and incredibly smooth serverless database provisioning.
ORM: Prisma for elegant, type-safe database schema and queries.
Styling: Tailwind CSS combined with custom CSS rules to achieve the sophisticated liquid glass / neumorphic UI design.
Package Manager: pnpm for fast dependency resolution.
Architecture: The app uses zero-auth, code-based access control. This makes it incredibly fast to deploy and share among student teams with zero onboarding friction.

Built with Google Gemini: Handheld Arcade Console with Raspberry Pi Pico

Anas Abuelhaag — Thu, 26 Feb 2026 13:06:58 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

For this project, I designed and implemented a handheld arcade console powered by a Raspberry Pi Pico (RP2040) and developed entirely in MicroPython. Instead of building another web-based application, I focused on a physical embedded system that integrates hardware interfacing, real-time rendering, and structured game logic.

The Hardware Architecture

The console architecture consists of:

RP2040 (Raspberry Pi Pico)
ST7789 240×240 SPI TFT Display
Analog joystick connected via ADC0 (GPIO26) and ADC1 (GPIO27)
Two action buttons using internal pull-ups (GPIO3, GPIO10)
PWM-driven buzzer on GPIO21

On top of this hardware layer, I developed seven fully playable games: Snake, Pong, Space Shooter, Flappy Bird, Dodger, Cave Flyer, and Dino Runner.

Hardware Planning, Wiring, and Pin Configuration

Before wiring the system, I used Gemini to reason through GPIO selection and ensure the wiring scheme aligned directly with the MicroPython initialization code.

Pin Mapping Table

Pico GPIO	Peripheral	Connection
GPIO6	SPI SCK	ST7789 SCK
GPIO7	SPI MOSI	ST7789 MOSI
GPIO13	SPI CS	ST7789 CS
GPIO11	Data/Command	ST7789 DC
GPIO12	Reset	ST7789 RST
GPIO26	ADC0	Joystick X
GPIO27	ADC1	Joystick Y
GPIO3	Digital Input	Button A
GPIO10	Digital Input	Button B
GPIO21	PWM Output	Buzzer

ST7789 Driver Framework and Implementation

Rather than copying fragmented examples, I designed a structured LCD driver framework. To support efficient graphics rendering, I implemented a framebuffer-based display driver class (ST7789_FB).

import framebuf

class ST7789_FB:
    def __init__(self, spi, width, height, reset, dc, cs):
        self.width = width
        self.height = height
        self.spi = spi
        self.rst = reset
        self.dc = dc
        self.cs = cs
        self.cs.value(1)
        self.init_display()

        # Allocate Full Framebuffer
        self.buffer = bytearray(self.width * self.height * 2)
        self.fb = framebuf.FrameBuffer(self.buffer, self.width, self.height, framebuf.RGB565)

    def write_cmd(self, cmd):
        self.dc.value(0)
        self.cs.value(0)
        self.spi.write(bytearray([cmd]))
        self.cs.value(1)

    def write_data(self, buf):
        self.dc.value(1)
        self.cs.value(0)
        self.spi.write(buf)
        self.cs.value(1)

    def refresh(self):
        self.write_cmd(0x2A)
        self.write_data(bytearray([0, 0, (self.width-1)>>8, (self.width-1)&0xFF]))
        self.write_cmd(0x2B)
        self.write_data(bytearray([0, 0, (self.height-1)>>8, (self.height-1)&0xFF]))
        self.write_cmd(0x2C)
        self.dc.value(1)
        self.cs.value(0)
        self.spi.write(self.buffer)
        self.cs.value(1)

Memory Considerations on RP2040

A 240×240 display using 16-bit RGB565 color requires 115,200 bytes (~112.5 KB) for a full framebuffer. The RP2040 provides 264 KB of SRAM, meaning nearly half of the available RAM is consumed by the framebuffer alone. This constraint influenced several architectural decisions:

Fixed Allocation: The framebuffer is allocated once during initialization to prevent heap fragmentation.
Zero-Buffer Loops: No large temporary buffers are created inside game loops.
Selective Rendering: Rendering logic avoids unnecessary full-screen redraws to save clock cycles.

Debugging Screen Orientation (The Real Fix)

One major issue involved mirrored output and inverted color mapping. I prompted Gemini:

"In MicroPython on RP2040, my ST7789 display is mirrored horizontally and colors look swapped. I'm using SPI and setting MADCTL to 0x00. What configuration should I check?"

Gemini pointed toward MADCTL bit flags and RGB/BGR order.

Initial (incorrect): self.write_data(bytearray([0x00]))
Corrected: self.write_data(bytearray([0x40]))

(Setting the register to 0x40 specifically flips the MX/Row Address Order bit, correcting the hardware-level mirroring).

Demo

Build It Yourself

Full source code including the ST7789_FB driver, all 7 game implementations, and the menu system is available here:

Check out the source code on GitHub

What I Learned

AI generates quickly. Hardware validates ruthlessly.
AI accelerates engineering, but embedded systems enforce discipline.

Clear constraints produce better AI responses.
Deep hardware understanding is required to verify AI-generated suggestions.

Drift CLI - Terminal-Native AI Assistant for Safe Command Execution

Anas Abuelhaag — Sun, 15 Feb 2026 22:54:14 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Drift CLI is a terminal-native, safety-first AI assistant that integrates directly into your shell. Powered by local LLMs via Ollama — it requires no cloud dependency and maintains full privacy.

Drift transforms how developers interact with their terminal by translating natural language queries into safe, executable shell commands. Press Ctrl+Space to convert English into commands like:

drift find all python files modified today
drift explain tar -czf archive.tar.gz src/
drift /commit  # Generate commit messages from staged changes
drift /test    # Auto-detect and run project tests

Key Features:

Natural Language to Shell: Press Ctrl+Space to get executable commands with rich previews
Safety First: Automatic blocklists, risk scoring (🟢 LOW, 🟡 MEDIUM, 🔴 HIGH), dry-run defaults, and confirmation prompts
Local-First Privacy: Runs entirely on your machine via Ollama (no API keys, no cloud tracking)
Smart Workflows: Plan → Preview → Confirm → Execute → Explain → Undo keeps every run recoverable
18+ Slash Commands: /git, /commit, /test, /build, /find, /clean, /lint and more with contextual awareness
Memory System: Tracks your preferred tools, risk tolerance, and workflows with export/import utilities
System Maintenance: drift doctor, drift config, drift setup, drift update keep your environment healthy

Demo

Installation & First Run (Zero Setup)

git clone https://github.com/a-elhaag/drift-cli.git
cd drift-cli
pip install -e .

# Auto-installs Ollama, starts server, and pulls the model on first use
drift what is the time now

Safe Command Execution with Preview

$ drift reorganize my project to use src layout

╭─ Plan ────────────────────────────────────────────────╮
│  Summary: Reorganize project to src/ layout            │
│  Risk: 🟡 MEDIUM                                       │
│                                                        │
│  $ mkdir -p src                                        │
│  $ mv *.py src/                                        │
│  $ mv tests/ src/                                      │
│    → Restructure project files                         │
╰────────────────────────────────────────────────────────╯
Execute? [y/N]: y
✓ Command executed successfully

Slash Command Integration (ZSH)

/commit    # Generates commit message from staged changes
/test      # Auto-detects test framework and runs tests
/build     # Detects build system and creates build commands
/git       # Analyzes repo status and suggests next actions

History & Undo Safety

drift history              # Browse all past queries
drift undo                 # Restore files from last snapshot
drift cleanup --keep 5     # Free space while keeping backups

Memory & Learning

drift memory show          # Your learned preferences
drift memory stats         # Usage totals and risk distribution
drift memory export backup.json  # Portable preferences
drift memory insights      # Reveal context sent to LLM

My Experience with GitHub Copilot CLI

GitHub Copilot CLI was instrumental in accelerating the development of Drift CLI. Here's how it transformed my workflow:

1. Rapid Implementation of Complex Features

When building the safety engine, I used Copilot CLI to:

Generate the risk-scoring algorithm based on command patterns
Create Pydantic validation models for JSON responses from Ollama
Build the snapshot/undo system for file recovery

Command: github copilot explain to understand shell command syntax before wrapping them in Python

This helped me write more secure subprocess calls and handle edge cases

2. Testing & Debugging Efficiency

Used Copilot CLI to generate comprehensive pytest test suites for command execution
Asked for help writing integration tests for the Ollama client
Quickly stubbed out test fixtures for different command scenarios

Result: Full test coverage completed 3x faster than manual writing

3. Documentation Generation

Generated inline code documentation and docstrings using Copilot
Created comprehensive README sections and API docs
Drafted slash command catalogs with descriptions

4. Architecture & Design Decisions

When designing the modular system:

drift_cli/
├── core/        (executor, safety, history, ollama client)
├── ui/          (display, progress)
├── commands/    (history_cmd, memory_cmd, etc.)

I used Copilot CLI to explore design patterns, ask "what's the best way to structure this?" and get instant guidance on:

How to properly handle subprocess execution with safety
Caching strategies for LLM responses
Async patterns for long-running commands

5. Error Handling & Edge Cases

Used Copilot CLI to:

Handle malformed Ollama responses gracefully
Implement timeout logic for stuck processes
Create meaningful error messages for users

6. CI/CD & Deployment

Asked Copilot CLI for:

GitHub Actions workflow for automated testing
Installation script best practices
Version management strategies

Key Impact

Before Copilot CLI: Manual context switching between documentation, Stack Overflow, and trial-and-error
After Copilot CLI: Stay in terminal, ask questions, get answers instantly, implement features without context loss

The AI assistance helped me focus on what to build (the safety-first architecture, the memory system, the slash commands) rather than how to write boilerplate code. This improved code quality and reduced development time by approximately 40%.

Drift CLI itself is a testament to what's possible when AI meets the terminal — and building it with GitHub Copilot CLI showed me how powerful terminal-based AI assistance truly is.

Tech Stack

Language: Python 3.9+
CLI Framework: Typer
LLM: Ollama (local, privacy-first)
Validation: Pydantic
UI: Rich (beautiful terminal rendering)
Shell Integration: ZSH hotkey binding
Testing: Pytest
Package Dependencies: httpx, setuptools

Try Drift CLI: https://github.com/a-elhaag/drift-cli/