DEV Community: Mashhood Ali

One Small Program Every Day, No Filler, No Excuses

Mashhood Ali — Mon, 09 Nov 2026 09:19:06 +0000

I had a problem that will sound familiar. I kept starting big projects and finishing none of them. A huge idea on Monday, an empty repo by Friday. The green squares on my contribution graph stayed empty, and nothing I had built was something I could show anyone.

So I changed the rule. Instead of one big thing, I would build one small real program every day. Alternating days: one day C++, one day Python. One commit a day, no filler commits, no empty files. Every program has to actually work and be something a person could use.

That became two repos. cpp-foundry for the C++ days, py-foundry for the Python days.

The C++ days

Day one was a grade calculator. You enter your courses with credits and marks, and it prints each course with its grade points and your semester average.

Day three was Two Sum, the classic interview problem. Given an array of numbers and a target, find the two numbers that add up to the target and return their positions. I solved it in one pass with a hash map. For each number, check if the target minus that number was already seen. Time O(n), space O(n). The brute-force double loop is O(n squared), and I left that behind on purpose.

Day five was the LRU Cache. A fixed-capacity cache that evicts the least recently used item. I built it with a doubly linked list for the use order plus a hash map pointing at each node, so get and put both run in O(1) time. It is the kind of problem that shows up in real interviews and real systems work.

The Python days

Day two was a grade calculator in Python. Enter your previous average and credits, then your courses with credits and marks, and it prints each course with its grade points, your semester average, and your new overall average. It works for any semester.

Day four was a log analyzer. It reads a web server access log and prints an operations summary: total requests, unique IPs, status code breakdown, busiest IPs and paths, and the error rate. Lines that do not parse are counted and skipped instead of crashing the run. Standard library only, no dependencies.

How to run them

The C++ programs compile the usual way:

g++ two_sum.cpp -o two_sum
./two_sum

The Python tools run directly:

python3 log_analyzer.py sample.log
python3 log_analyzer.py access.log --top 10

What the streak taught me

A small finished program beats a big unfinished idea every single time. One commit a day sounds easy until you try to keep it up. The rule that saved me was the "real program" rule. If it does not do something useful, it does not count. No placeholder files, no empty commits just to colour a square green.

The streak is still going. One small program, every day.

Repos: https://github.com/MASHHOOD2019/cpp-foundry and https://github.com/MASHHOOD2019/py-foundry

The Smallest App I Have Ever Built, and the One I Actually Open Every Day

Mashhood Ali — Mon, 09 Nov 2026 09:14:23 +0000

Every to-do app I tried wanted something from me. An account. An email. A sync service. A subscription for the feature that lets you delete a task. I did not want any of that. I wanted to write a task down in a terminal and have it still be there tomorrow.

So I built To-Do CLI. It is the smallest app I have ever built, and it is the one I actually open every day.

It is a small command line app in C++. Add tasks, list them, mark them done, delete them. That is the whole feature list, and that is enough. The tasks are saved to a file called tasks.txt, so they persist between runs. You close the terminal, you come back tomorrow, your list is still there.

What it does

The app is built around a simple Task class and file handling in C++. Add a task and it goes on the list as pending. List all tasks and you see each one with its status, pending or done. Mark a task done when you finish it. Delete a task when you do not need it anymore. Nothing else. No categories, no tags, no priorities, no cloud.

I kept it small on purpose. A to-do list is not a project management platform. The moment it grows a login screen, it has failed at its job.

How to run it

g++ TodoCLI.cpp -o todo
./todo

That is it. One file, one compile, no dependencies, no install step.

Why I still use it

I have built bigger things since. Dashboards, APIs, monitors. But this little tool is the one that taught me something useful: the best version of a tool is often the smallest one that still does the job. If a program does one thing and does it without getting in your way, you will keep using it. If it asks you to sign up first, you will not.

If you are learning C++ and you want a first project that is actually useful, a to-do CLI is a good place to start. File handling, a small class, a menu loop. Nothing fancy, and you end up with something you open every morning.

Repo: https://github.com/MASHHOOD2019/todo-cli

Bug Reports Kept Arriving as Messy Chats, So I Built a Tracker That Fits in One Page

Mashhood Ali — Mon, 09 Nov 2026 09:09:43 +0000

When I started doing QA testing, I noticed something fast. Bugs did not arrive as bug reports. They arrived as chat messages. "The login is broken." No severity. No steps to reproduce. No expected result, no actual result. Nothing a developer could act on, and nothing I could hand to a client as proof of the work.

I wanted a proper tracker, but the real ones all wanted accounts, servers, and subscriptions. I was testing small things. I needed something I could open and use in ten seconds.

So I built QA Bug Tracker. A complete bug-tracking tool for manual QA work. Report defects with severity and steps to reproduce, triage by filter and search, track the fix rate, and export the report as JSON or CSV. No server, no install, no framework. Just open the page.

What it does

A bug has the fields a real report needs. Severity, module, steps to reproduce, expected result versus actual result. The lifecycle is simple: report, open, fixed, reopen, plus delete.

Triage is built in. Live search, a severity filter, and a status filter narrow the list as you type. The stats update as bugs change: total bugs, open count, critical-open count, and fix rate percentage.

The export is the part I cared about most. One click gives you a JSON or CSV report, the format a QA tester actually hands to a developer or a client. That was the whole point. A chat message is not a deliverable. A report is.

Everything persists in localStorage, so bugs survive a refresh. On first run, three realistic sample bugs are seeded so the workflow is visible immediately.

How to run it

Just open index.html in a browser. No server, no install, no build step. It works offline.

The severity guide

The tracker uses four levels, and I wrote the guide into it because new testers always ask what counts as what.

Critical blocks core use, like a login button that does nothing. Major means a feature is broken but a workaround exists, like a discount code being ignored. Minor is visual or non-blocking, like a footer overlapping content. Trivial is cosmetic polish, like a typo in a label.

Getting severity right matters more than people think. A report with five "critical" bugs, where four are typos, teaches the developer to ignore you.

What I would add next

Screenshot attachments on bug reports, assignee and due-date fields, and importing a previously exported JSON report back into the tracker. For now it does the core job, and it does it without asking you to sign up for anything.

Repo: https://github.com/MASHHOOD2019/qa-bug-tracker

I Did Not Trust the Cloud With My Passwords, So I Built a Vault That Never Leaves My Machine

Mashhood Ali — Mon, 09 Nov 2026 09:04:55 +0000

I have a lot of logins. Like everyone else, I kept them in my head, then in a text file, then nowhere safe at all. Every password manager I looked at wanted a cloud account and a subscription. I did not want my secrets sitting on someone else's server. I wanted them on my own machine, encrypted properly, with nothing leaving the device.

So I built Secure Vault. An encrypted credential store that runs entirely locally. No cloud account, no server, nothing leaves the device.

How it keeps things safe

The encryption is real. Fernet, which is AES-128-CBC plus HMAC, through the cryptography package. No home-grown ciphers, no clever shortcuts. The key comes from your master password through PBKDF2-HMAC-SHA256 with 600,000 iterations and a random 16-byte salt per vault. That makes brute-force attacks expensive, and identical passwords produce different keys.

The master password is never stored anywhere. Not hashed, not anywhere. The encrypted data itself is the check. A wrong password simply fails decryption. The vault file is created with owner-only permissions, so other users on the machine cannot read it. And passwords are read with getpass, so they never show up in shell history or process arguments.

If you leave the password blank when adding an entry, the vault generates a strong 20-character password for you from the secrets module.

What it does

It is a command line tool with a full entry lifecycle. Create a vault, add entries, read one back, list entry names, delete an entry. Listing never shows secrets, only names.

How to run it

pip install -r requirements.txt

python vault.py init          # create vault, set master password
python vault.py add github    # store an entry (prompts for details)
python vault.py get github    # show one entry
python vault.py list          # list entry names (never secrets)
python vault.py delete github # remove an entry

The honest limits

It is a single machine, single user tool. There is no sync, no sharing, and no recovery. If you forget the master password, the vault cannot be opened, by design. There is no back door and no reset link. That is the trade you make for keeping everything offline.

I tested the full round trip before I trusted it. Create, add, read back, the exact entry comes back. A wrong master password is rejected. Delete removes the entry. An empty vault says so plainly.

If you want your passwords encrypted and nowhere else, this does the job.

Repo: https://github.com/MASHHOOD2019/secure-vault

I Built a Tiny Telemetry System Because the Real Ones Need a Server Farm

Mashhood Ali — Mon, 09 Nov 2026 08:59:42 +0000

I have always liked the idea of telemetry. Devices out in the world, quietly posting readings, and a dashboard somewhere showing what is happening right now. Temperature, pressure, vibration. Simple numbers, but they tell you a lot.

The problem was that every real telemetry stack I looked at wanted a server farm. A message broker, a time-series database, a cluster, a cloud account. I did not have any of that. I had a laptop and an evening.

So I built a small one. A local telemetry ingestion system. Devices POST sensor readings to a REST API, the readings land in SQLite, and a dashboard shows live stats, per-sensor trends, and recent readings. It is the kind of data-logging tool used in industrial operations support, just shrunk down to something one person can run.

What it does

The API takes a reading with a sensor id, a value, a unit, and a timestamp, validates it, and stores it. Bad input gets rejected with a 422, so junk never reaches the database.

The dashboard is served by the API itself. It has stats cards, a per-sensor trend chart, and a recent-readings table, and it refreshes every 3 seconds. There is a statistics endpoint too, totals, per-sensor minimum, maximum and average, and the latest value per sensor, all aggregated in SQL.

There is also a sensor simulator. It generates realistic temperature, pressure, and vibration traffic and posts it every 2 seconds, so you can watch the dashboard move without wiring up a real device. That part turned out to be the most fun. You run it in a second terminal and the whole thing comes alive.

How to run it

pip install -r requirements.txt
uvicorn app.main:app --reload

Open http://127.0.0.1:8000 for the dashboard. The API docs live at http://127.0.0.1:8000/docs, FastAPI generates them for free.

To make demo traffic, open a second terminal and run:

python simulator.py

You can also post a reading by hand:

curl -X POST http://127.0.0.1:8000/api/readings \
  -H "Content-Type: application/json" \
  -d '{"sensor_id": "temp-01", "value": 71.5, "unit": "C"}'

It answers with the id of the stored reading.

How it is put together

The stack is Python 3.12, FastAPI, and Pydantic validation on the API side, SQLite indexed on sensor and timestamp for storage, and plain HTML, CSS, and vanilla JavaScript with a Canvas chart on the front end. The server is Uvicorn. The simulator uses httpx.

Nothing here is clever. That was the point. A sensor posts a number, the number gets stored, the dashboard shows it. If you have ever wanted to see your own data flowing end to end, this is a good place to start.

Repo: https://github.com/MASHHOOD2019/telemetry-logger

My Own Tool Failed on My Own Laptop, and Windows Was the Problem

Mashhood Ali — Mon, 09 Nov 2026 08:44:05 +0000

I built Windows Toolbox to do the jobs every Windows user needs sooner or later. See system info. Clean junk files. Remove preinstalled bloatware. Manage startup apps. Install essential free software. One menu, plain text, nothing hidden.

Then I ran it on my own Windows 11 laptop. I typed python toolbox.py, and the shell told me Python was not found and sent me to the Microsoft Store.

The tool was fine. Windows was the problem. On Windows 11, the python command gets caught by a Microsoft Store shortcut, so the real Python never runs. My own tool failed on my own laptop because of that.

The fix takes a minute

Try these in order.

First, run py toolbox.py instead. The py launcher usually skips the Store shortcut, and the menu just opens.

If py also fails, Python is not installed at all. Install it from python.org, and on the first install screen tick the box that says "Add python.exe to PATH". Then close the shell, open a new one, and try again.

If Python is installed but python still opens the Store, go to Settings, then Apps, then Advanced app settings, then App execution aliases, and turn OFF python.exe and python3.exe. That kills the shortcut and lets the real Python run.

I put the full fix in the repo README too, so the next person does not lose an evening to it.

What the tool does

It is a free, open-source Windows utility in plain Python, standard library only, no third-party packages needed. Pick a number from the menu.

System information shows OS, CPU, RAM usage, uptime, and free disk space. Disk cleanup removes temp files and optionally empties the Recycle Bin. The bloatware remover lists well-known preinstalled third-party apps, Candy Crush, Disney+, Netflix, Spotify, TikTok, and more, and removes only the ones you pick. Startup apps lists what launches at boot, disables them with a backup, and restores them later. The installer grabs popular free software like Chrome, VS Code, VLC, 7-Zip, and Git through winget.

Nothing is deleted, removed, or changed without showing you exactly what will happen and asking first. The debloat list only covers well-known preinstalled third-party apps, never system apps. Disabled startup items are backed up so they can be restored.

How to run it

You need Windows 10 or 11 and Python 3.10 or newer.

python toolbox.py

Pick a number from the menu. Every destructive action asks for confirmation first.

Repo: https://github.com/MASHHOOD2019/windows-toolbox

I Got Tired of Finding Out My Sites Were Down From Other People

Mashhood Ali — Mon, 09 Nov 2026 08:42:56 +0000

A while back, one of my small sites went down. I did not notice. Nobody told me for hours. A friend messaged me about it eventually, and that was the moment I realised I had no monitoring at all.

I looked at the hosted options. They all wanted a monthly fee, or an account, or a server I had to rent. I did not need any of that. I needed something that checks a URL every minute and tells me when it stops answering.

So I built Watchdog.

It is a lightweight uptime monitor that runs on your own machine. You add your websites, it checks them on a schedule, keeps the full history, shows a live dashboard, and pings you on Telegram or email the moment something goes down or comes back up. No Docker. No server to rent. No heavy dependencies. Just Python, FastAPI, and SQLite.

What it does

It monitors any HTTP or HTTPS URL on a schedule you choose, every 60 seconds by default. Every check is recorded: status code, response time, up or down, timestamp.

The dashboard shows per-site status cards, uptime percentages for the last 24 hours, 7 days and 30 days, response-time sparklines, and a recent event log. It polls the API every 15 seconds, so the page stays live.

One thing I was careful about: a site is only marked DOWN after a few consecutive failures. A single slow response should not page you at midnight. You can also pause or resume any site, or delete a site along with its full history.

Alerts are optional. Without them, Watchdog still monitors everything and logs state changes to the dashboard. With them, you get a Telegram or email message the moment a site flips from UP to DOWN, and again when it comes back.

How to run it

You need Python 3.10 or newer.

git clone https://github.com/MASHHOOD2019/watchdog.git
cd watchdog
pip install -r requirements.txt
python app.py

Open http://localhost:8000 in your browser and add your first URL in the form at the top. On Windows you can run it the same way from a terminal, or wrap it in a small .bat file.

To turn on Telegram alerts, copy config.example.json to config.json and fill in your bot token and chat id. For email, fill in the SMTP details in the same file. Restart the app and you are done.

How it works

A background thread checks every enabled site on its own schedule using the standard library, so there is nothing extra to install for the checking itself. Results go into a local SQLite database, one row per check, plus an event row on every state change. FastAPI serves both the dashboard and a small JSON API that the page polls.

The whole thing is one small codebase. app.py is the entry point, checker.py runs the background checks, db.py handles storage, alerts.py delivers Telegram and email. That is it.

If you run any small sites and you are still finding out about downtime from other people, this is for you.

Repo: https://github.com/MASHHOOD2019/watchdog