Windows

This worked for me on Windows 11, but your mileage may vary (especially since it hasn’t been under development for a while).

1. Download the installer executable from here. (If you don’t trust me, you can find the same installer from here).

2. Extract the file.

3. Run the installer.

Linux

I’ve only started using this program, so I’m not sure if everything is supported on Linux. Use at your own risk!

WINE

Unfortunately linux does not enjoy a native GUI experience for OpenBUGS. The best I’ve found to progress is using WINE with the Windows version.

Installation Instructions

1. Download OpenBUGS323.zip . (If you don’t trust me, you can find the same compressed OpenBUGS323.zip from here).

2. Extract the folder to OpenBUGS323/

3. Follow the instructions for your distribution to download and install WINE.

4. CD into your OpenBUGS323 folder

5. Run wine OpenBUGS.exe

Note: If your WINE app is rendering really, really small you can run winecfg in the terminal which will open a configuration window. Open the Graphics tab and alter the “Screen resolution” slider until you get to a size that works for you.

If you are using Ubuntu, you can create a custom launcher for it by following these instructions. You can make the openbugs.desktop file similar to how I made mine. Make sure to set your Exec command to match where your OpenBUGS.exe file is located :

[Desktop Entry]
Name=OpenBUGS
Comment=Launch OpenBUGS
Keywords=openbugs;stats;statistics;
OnlyShowIn=GNOME;Unity;
Exec=wine /home/michael/Documents/Applications/OpenBUGS323/OpenBUGS.exe
StartupNotify=true
Terminal=false
Type=Application
Categories=Utility;
MimeType=x-scheme-handler/ghelp;x-scheme-handler/help;x-scheme-handler/info;x-scheme-handler/man;

Native Linux (CLI only)

I did some investigation into the official command line interface for future experimentation and wanted to share it with you below. I also believe this only works on Intel processors.

Installation Instructions

1. Download the tar.gz OpenBugs file.

2. Extract the file either via your OS’s built in toolset, or (if you’re feeling spicy) run the following commands in the terminal:

   1. gzip -d OpenBUGS-3.2.3.tar.gz

   2. tar -xvzf OpenBUGS-3.2.3.tar

3. CD into the directory

   1. cd OpenBUGS-3.2.3

4. Run ./configure

   1. If you get an error saying “In file included from OpenBUGSCli.c:2:

      /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory” you will need to install gcc-multilib

      1. sudo apt-get install gcc-multilib

5. Run make

6. Run sudo make install

For more detailed installation instructions, review the README or INSTALL files located in the OpenBUGS-3.2.3 file.

Usage Instructions

The command OpenBUGS should be accessible anywhere in your terminal. I would recommend reading through the README and man OpenBUGS commands to get a gist of how it works. You can open an interactive interpreter by running OpenBUGS without any arguments.

Mac

I haven’t tested this, however the installation instructions are very similar to the linux + WINE ones that I listed above. Here is what I’ve found may work for you (courtesy of sooahnshin on github and Zero Grau). Note that this may also only work on Intel processors (maybe ones with Apple silicon + the Rosetta layer?).

1. Download the installer executable from here. (If you don’t trust me, you can find the same installer from here.

2. Extract the .exe installer from the zip file.

3. Download and install Homebrew.

4. Open the terminal and run brew install wine

5. In your terminal, to the Downloads folder where you downloaded and extracted the installer exe file.

6. Run wine OpenBUGS323setup.exe

7. Theoretically this should have installed the app. Good luck!

Code

How building my own router, database layer, and template system taught me what Laravel and Django abstract away

I’ve shipped apps with Django and Ruby on Rails, but I always had a nagging feeling that I didn’t truly understand what was happening under the hood. When something broke in the routing layer or a query didn’t behave the way I expected, I was guessing. I was using the magic without understanding the trick.

So I decided to build my own MVC framework from scratch in PHP. No third party libraries, no ORM, no training wheels. Just me, PHP, MySQL, and the question: what does it actually take to make one of these things work?

The result is BoffMVC, and the process of building it taught me more about web architecture than any tutorial or course ever could.

Convention Over Configuration: A Router That Figures It Out

One of the first big decisions I had to make was how routing would work. If you’ve used Laravel, you know the pattern: you explicitly define every single route in a file.

php

// Laravel's approach - manually define each route
Route::get('/user', [UserController::class, 'index']);
Route::get('/recipe', [RecipeController::class, 'index']);
Route::post('/recipe', [RecipeController::class, 'store']);

This works great in production frameworks, but I wanted to see if I could take a different approach: what if the router could figure out which controller to use just by looking at the URL? Instead of maintaining a growing list of route definitions, BoffMVC dynamically resolves the controller from the request.

php

// Router.php - dynamically resolve the controller from the URL
$page = isset($_GET['page']) ? $_GET['page'] : 'home';
$controller_name = ucfirst($page) . 'Controller';
$controller_path = 'app/controller/' . $controller_name . '.php';

if (file_exists($controller_path)) {
    require_once($controller_path);
    $controller = new $controller_name();
} else {
    // Fall back to the home page if no matching controller exists
    require_once('app/controller/HomeController.php');
    $controller = new HomeController();
}

When a user visits example.com/?page=user, the router parses out user, looks for a UserController, and loads it. If that controller doesn’t exist, it gracefully falls back to the HomeController. No route file to maintain, no manual wiring.

The tradeoff here is flexibility. With Laravel’s explicit routing, you can map any URL pattern to any controller method. My convention-based approach means you’re locked into a specific naming pattern. But for this project, the simplicity was worth it and it forced a consistent structure across the whole application.

Before any of that controller resolution happens though, the router first checks the CSRF token to protect against cross-site request forgery. Every form rendered by BoffMVC includes a hidden token field, and the router validates it before processing any request:

php

// Validate CSRF token before processing the request
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    if (!isset($_POST['csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) {
        die('Invalid CSRF token');
    }
}

This was one of those features that I never thought twice about in Django (it just works) but building it myself gave me a real appreciation for how important it is to bake security into the framework layer rather than leaving it to individual developers.

Simulating RESTful Methods Over POST

Here’s a practical constraint I ran into early: HTML forms only support GET and POST. There’s no native way to send a PUT or DELETE request from a form. I’d never had to think about this before because Rails and Django handle it behind the scenes. But when you’re building from scratch, you hit this wall fast.

My solution was to embed a hidden field in every form that tells the controller what the intended method is:

html

<!-- A form that should trigger a DELETE action -->
<form method="POST" action="index.php?page=recipe">
    <input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">
    <input type="hidden" name="_method" value="DELETE">
    <input type="hidden" name="recipe_id" value="42">
    <button type="submit">Delete Recipe</button>
</form>

Then in the controller, I check for that hidden field and route accordingly:

php

// ApplicationController.php - base controller that all others extend
class ApplicationController {
    public function manageRequest() {
        if ($_SERVER['REQUEST_METHOD'] === 'GET') {
            $this->handleGet();
        } else if ($_SERVER['REQUEST_METHOD'] === 'POST') {
            $method = isset($_POST['_method']) ? $_POST['_method'] : 'CREATE';
            switch ($method) {
                case 'PUT':
                    $this->handlePut();
                    break;
                case 'DELETE':
                    $this->handleDelete();
                    break;
                default:
                    $this->handleCreate();
                    break;
            }
        }
    }
}

Every controller in BoffMVC extends ApplicationController and calls manageRequest() after instantiation. This pattern means each controller just needs to implement the specific handler methods it cares about (handleGet, handleCreate, handlePut, handleDelete) and the base class takes care of dispatching.

I later learned that Rails does almost the exact same thing with its _method hidden field. It was a fun moment of convergent design, arriving at the same solution independently because the underlying constraint is the same for everyone.

When Textbook MVC Breaks Down: Discovering the Model Manager Pattern

This was probably the biggest “aha” moment of the whole project. The textbook MVC diagram is clean: Controller talks to Model, Model talks to Database, Model returns data to View. Simple.

In practice, it got messy fast. My User model represented a single user and handled things like saving to the database or updating a password. But where does the logic go for “find all users who signed up this week” or “check if this email already exists before creating a new account”? Those operations aren’t really about a single user object. They’re about managing collections of users.

I ended up splitting model responsibilities into two classes: the Model and the Model Manager.

php

// User.php - represents a single user object
class User {
    public $id;
    public $username;
    public $email;

    public function __construct($data) {
        $this->id = $data['id'];
        $this->username = $data['username'];
        $this->email = $data['email'];
    }

    public function save() {
        $db = new DBManager();
        $db->query(
            "UPDATE users SET username = ?, email = ? WHERE id = ?",
            [$this->username, $this->email, $this->id]
        );
    }
}

php

// UserManager.php - manages collections and queries about users
class UserManager {
    public function getUserById($id) {
        $db = new DBManager();
        $result = $db->query("SELECT * FROM users WHERE id = ?", [$id]);
        return $result ? new User($result) : null;
    }

    public function getAllUsers() {
        $db = new DBManager();
        $results = $db->query("SELECT * FROM users");
        return array_map(function($row) { return new User($row); }, $results);
    }

    public function emailExists($email) {
        $db = new DBManager();
        $result = $db->query("SELECT id FROM users WHERE email = ?", [$email]);
        return !empty($result);
    }
}

The Model handles individual object behavior (save, update, delete itself). The Model Manager handles finding, filtering, and creating those objects. I later learned that this separation is similar to what’s called the Repository pattern in domain-driven design, and it’s essentially what Django’s Manager class does (e.g., User.objects.filter(...)). I arrived at it independently because the single-model approach just couldn’t handle queries that spanned multiple objects cleanly.

This was the moment where building my own framework paid off the most. I went from vaguely knowing that Django has a .objects manager to understanding why it exists and what problem it solves.

The Database Layer: Simplicity Over Abstraction

Established frameworks like Laravel come with full Object-Relational Mapping (ORM) systems like Eloquent, which let you interact with database tables as if they were PHP objects. That’s powerful, but it’s also a huge amount of abstraction to build.

I went the opposite direction. BoffMVC provides a thin DBManager interface that handles connections and parameterized queries, but you write the SQL yourself:

php

// DBManager.php - thin wrapper around PDO
class DBManager {
    private $connection;

    public function __construct() {
        $this->connection = new PDO(
            'mysql:host=' . DB_HOST . ';dbname=' . DB_NAME,
            DB_USER,
            DB_PASS
        );
        $this->connection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    }

    public function query($sql, $params = []) {
        $stmt = $this->connection->prepare($sql);
        $stmt->execute($params);
        return $stmt->fetchAll(PDO::FETCH_ASSOC);
    }
}

Every time a model or manager needs to talk to the database, it creates a new DBManager instance, which opens a connection, runs the query, and returns the result. The pattern ends up looking like this throughout the codebase:

$db = new DBManager();
$recipes = $db->query(
    "SELECT * FROM recipes WHERE user_id = ? ORDER BY created_at DESC",
    [$user_id]
);

Is this the most efficient approach? No. Creating a new connection per query is wasteful compared to connection pooling. A production framework would maintain a single connection (or a pool) across the request lifecycle. But for a learning project, the simplicity of “new instance, run query, get result” meant I could focus on understanding the flow of data through the application without getting bogged down in connection management.

If I were to rebuild this today, I’d implement a singleton pattern for the database connection so that all queries within a single request share one connection.

Views and the Template System

The view layer in BoffMVC collects data from the controller and passes it into .phtml template files. All data that needs to be rendered gets packed into a $RENDER_VARS array:

// RecipeView.php
class RecipeView {
    public function showRecipe($recipe, $author) {
        $RENDER_VARS = [];
        $RENDER_VARS['title'] = $recipe->title;
        $RENDER_VARS['author'] = $author->username;
        $RENDER_VARS['ingredients'] = $recipe->ingredients;

        // Load CSS and JS specific to this page
        $RENDER_VARS['css'] = ['app/view/Recipe/css/recipe.css'];
        $RENDER_VARS['js'] = ['app/view/Recipe/js/recipe.js'];

        // Hand off to the template
        require('app/template/recipe_show.phtml');
    }
}

Templates were broken up into reusable sub-templates: a header, a footer, a navigation bar, and then page-specific content in between. This meant I could change the site-wide navigation in one place instead of updating every page. It’s the same concept as Django’s template inheritance or Rails’ layouts, just implemented more manually.

The Flow of a Request, End to End

To tie it all together, here’s what happens when a user visits example.com/?page=recipe&id=5:

1. The browser hits index.php, which immediately hands off to Router.php.

2. The router checks the CSRF token (for POST requests), parses page=recipe from the URL, and loads RecipeController.php.

3. The controller calls manageRequest(), which identifies this as a GET request and calls handleGet().

4. handleGet() asks RecipeManager to find the recipe with id=5. The manager creates a DBManager, runs the query, and returns a Recipe object.

5. The controller passes the Recipe object to RecipeView.

6. The view packs the data into $RENDER_VARS and loads the appropriate .phtml template.

7. The template renders the final HTML back to the user.

Each layer has a single responsibility, and data flows in one direction. That’s the whole point of MVC, and building it from the ground up made each of those boundaries tangible instead of theoretical.

What I’d Do Differently

The biggest mistake I made was developing the framework while simultaneously building a recipe sharing website on top of it. The framework and the application code became intertwined. Features got added to the framework because the recipe site needed them, not because they were generalized solutions. This made BoffMVC difficult to reuse for any other project.

If I were starting over, I’d develop the framework as a standalone library with its own test suite, and build the recipe site as a completely separate project that imports it. That separation of concerns applies at the project level, not just the code level.

I’d also invest in a few specific improvements. First, a singleton or factory pattern for database connections instead of creating a new connection per query. Second, a more flexible routing system that supports clean URLs (like /recipe/5 instead of ?page=recipe&id=5). Third, better error handling and logging rather than the bare-bones approach I took.

The Point of All This

Building BoffMVC wasn’t about creating something to compete with Laravel. It was about pulling back the curtain on tools I use every day and understanding the decisions that went into them. Every professional framework has made hundreds of architectural choices. Until you’ve faced even a handful of those choices yourself, it’s hard to appreciate why they made the tradeoffs they did.

I now have a much deeper understanding of routing, request lifecycles, database abstraction layers, and the MVC pattern itself. When I work with Laravel or Django now, I’m not just following the documentation. I understand the why behind the patterns, and that makes me a better engineer.

View Code

HF Enhancement Suite (HFES for short) is a userscript designed for the popular HackForums.net web forum. Userscripts are cross-browser add-ons that can add additional functionality to a website. HFES adds a variety of functionality including the ability to subscribe to forums, quote multiple posts at once, and a complete interface overhaul of the private messaging system. Over 5000 people have installed this popular application.

Building a User Base

At the time of I began developing the script, I was already building a good reputation across the site as a trustworthy and knowledgeable user. Like any internet forum, the website was filled with many cliques and I quickly started networking with other "high quality" posters. This networking was important, because when I started this passion project, these influential people were able to quickly become strong champions of the brand I built for myself.

HFES began as a passion script, trying to solve small problems and frustrations I was having with the website itself. It was not until I started discussing it with my colleagues that I realized the problems I were having was shared by other people. I realized, quickly, that tool could become something very special.

I began a small trial with some popular and well respected influencers on the website. As they were heavy users of the site, they would be a prime test subjects and could offer their own advice with their intimate knowledge of the platform. I collected a lot of feedback and held several brainstorming sessions on how to solve these problems with these select individuals. This ended up not only getting great ideas, but also the committed buy-in from these important users.

As soon as I released the script publicly, I encouraged these new brand ambassadors to post their reviews and help other users with any questions. This lent credibility to the project, something very important with a userbase as paranoid as on a site like Hack Forums.

At this time, I decided to focus on growth of the platform. Sourcing new features from the userbase helped early adopters feel apart of the process, exponentially increasing the userbase. The script spread almost entirely by word of mouth, with people voluntarily advertising in their post signatures (a valuable marketing location placed on every post they make).

Monetization

When my userbase started getting into the hundreds, I began adding more ambitious features that needed back-end support. I realized I needed to monetize it to keep it self-sustaining. Understanding the forum and the nature of a userscript, there was no way hide access of the script's features behind a paywall. Not only is it not technically feasible, but I would lose the large userbase entirely and a competitor would pop up immediately.

HFES had to stay free and open, so I decided to choose a freemium model. I could not add any pay-only core features, but I could add non-intrusive cosmetic perks that were visible to all users using the script.

I ended up selecting some small features that added a little icon next to a user's name, an animated username, or a gold bar present at the top of every post. Each feature was progressively more expensive in order to limit overall supply. This ended up making each feature considerably more popular than I originally thought, with people regularly purchasing the most expensive feature or all three at the same time.

Takeaway

In the end, the userbase extended over 5000 individuals and earned me over $4000. However, the money was not the most valuable takeaway from this project. Instead, despite this being one of my first projects, I learned some great lessons:

1. Your personal brand and reputation is a valuable commodity.

2. Engaging respected influencers can quickly build up your own product's reputation.

3. If you respect your users, they will respect and support you.

View Code

Live Site

I have used and made user scripts for almost a decade and they have been a big part of my growth as a developer. When deciding on my Master's thesis, I was excited to research and build something that could help the community.

What are User Scripts?

User scripts are small cross-browser add-ons that can be used to enhance a user’s web browsing experience. These scripts are used to provide quick and unique customizations that directly modify the website a user is visiting. Created by the community, user scripts can add features ranging from adding detailed summary information from a review website into a favorite video streaming service to replacing all images with pictures of cats.

The Problem

The growth of the user script community has stagnated over the past 10 years as official browser extensions have gained popularity instead.

After interviewing technical and non-technical people of whom some were aware of what user scripts are, I realized there are two core problems:

1. User Acquisition: There are no easy to follow and understand explanations of what user scripts are and how to use them in a way that resonates with non technical users. To solve this I built an interactive tutorial that uses modern adult learning techniques, not something ever done in the user script community before.

2. User Retention: To convince a user to try to learn, you have to provide obvious motivation as to why they would want to stay. To solve this, I built a collaborative filter recommendation system to provide relevant, personalized results.

User Acquisition - Interactive Tutorial

Current research into effective adult learning techniques encourage teachers to follow these four core principles:

• Keep the lesson concise.

• Let users practice what they are taught.

• Use rewards as motivation.

• Accommodate the three different learning styles: visual, auditory, and kinesthetic.

To teach users, I created a tutorial that accommodated each of the above. To keep things concise, I broke the system down into two steps: 1) Install a user script manager; 2) find and install a script. To accommodate different visual and auditory learning styles, I included a video explaining how to install a user script manager. Where my tutorial differs than others, is that I created a script that I instructed users to install. When this kinesthetic task is completed, users will be immediately rewarded in the tutorial itself by updating the site itself. Constant feedback from early testers found this easier to understand than traditional wall-of-text tutorials other sites provide. You can check out the live tutorial here.

User Retention - Content Discovery

New and existing users need to be provided a reason to continue learning and using any product. This is especially true with a niche and technical tool like user scripts. The best way to provide this motivation is by clearly showing users scripts that are relevant to them. Other user script hosting sites simply provide a list that can be sorted by top downloads or top rated, but often these are filled with complicated or irrelevant scripts. I believe that implementing a suggestion system, just like successful companies like Netflix and Amazon, would help users find things that are most relevant to them and convince them to stay.

I decided to use a similar type of recommendation system to the large companies: an item-based collaborative filtering recommendation system. This system records every user's interaction with scripts. If a user downloads a script, the interaction is rated higher than a simple visit to the description. The system will then compare every script with each other and, based off of the users that interacted with both scripts, calculate a similarity score.

To calculate this score, I decided to use the Pearson Correlation, a common similarity comparison algorithm. It will take the previously mentioned interaction scores and provide a correlation value representing similarity between -1 and 1.

The correlation is than multiplied by combined interaction scores to provide a final similarity rating.

When a user signs into MonkeyScripts, the website looks at their previously visited and downloaded scripts. From these, it will select several and generate suggestions based off of the scripts most similar to each one. These are then presented to the user as recommended scripts (with a little bit of randomness to keep things interesting).

To provide a simplified example of the result: Imagine Alice likes apples, bananas, and pears. Bob knows he likes apples and bananas. Since we know from Alice that people who like apples and bananas also like pears, we would suggest that Bob try a pear to see if he enjoys it as well. The more data points we have, the more accurate this system becomes.

Takeaway

1. There is a lot more to making and promoting a new website than simply adding cool and modern features. SEO, advertising, content creation, etc takes different skills and a lot of time.

2. Simply based off of the feedback received, this project proved to me that incorporating modern learning and content discovery techniques is a feasible method of lowering the bar of entry for niche and difficult-to-understand communities.

View Code

I finished 3 tutorials but haven’t learned anything!

It doesn’t stick in my head yet

I have been trying to learn coding for sometime now and I have always failed

Tutorial hell is the bane of new software developers. It is the evil boogie man that hides under the bed, ever present. If you’ve ever caught yourself saying one of the above phrases, you too may have been caught in it.

You finish a tutorial, it walked you step-by-step through the process of making a tribute page, but you finish and realize you have no idea how to make a website by yourself. You feel like you just wasted days or weeks of time, maybe even some money. You might even think the problem is with yourself and that you should give up. Everyone else seems to get it, right?

No! The problem isn’t that you can’t understand how to program. It’s that you are approaching it wrong. In this article I’m going to explain my technique for escaping this pit of despair.

Spoiler alert: You can never learn enough to feel confident. No video series will ever make you job ready. You can only really learn how to code by researching and experimenting.

The Loop

New developers are often given the recommendation to just “find a tutorial”, “buy this Udemy course”, or “complete this course”, but I want to posit that this advice misleads. Instead of leading people to self-sufficient success, it gets them stuck using training wheels. Many users on Discord servers explain to me that they complete tutorial after tutorial and still feel like they don’t know what they are doing.

Tutorials and these software engineer YouTube influencers contribute to this issue. Just look at the titles to the courses on Udemy:

• "Complete guide to learning how to program online”

• “From complete beginner to advanced. Learn Webdesign and Become a Professional Front End Web Developer!”

These, and many other courses, are trying to convince you they have the magic secret. That you can sign up for their course and leave job ready. Instead what happens is that people complete the course, realize they have been hand-held the entire time, and have no idea how to code on their own.

Breaking Free

So what is the solution? Break free of the loop by reframing what tutorials are. They shouldn’t be seen as step-by-step instructions, but rather as a guide to lead you to lead you in the generally right direction.

First, come up with an idea of a fun project that motivates you. It can be a chat bot, social media site clone, anything! This should be your guiding principle, and as you learn new concepts strongly consider how this might help you build your goal project.

If you have never programmed before, you’ll need to learn the basics. Choose a language, such as Javascript or Python, that fits best to your goal project. Free courses and textbooks are great for this, but do not feel compelled to finish them. Learn the important fundamentals, do the practice problems to reinforce the ideas, then stop wasting time.

Now is the fun part, find a tutorial that uses the same language you learned the basics in that is similar to what you are trying to accomplish as your goal project. For example, if you are trying to create a chat bot, find a tutorial on how to build a Discord chatbot with Python. If you are trying to recreate Reddit, find an HTML/CSS/Javascript tutorial on how to create a blog.

As you progress through the tutorial, start deviating from the instructions. Use different text, style your entries differently. Your tweaks should be small at first, then larger and larger after. You will have to start googling how to do something different until eventually you are no longer following the tutorial and just using Google to improve your creation.

A couple things to keep in mind:

• If your goal project is a big one with many moving parts, don’t try learning all of them at once. Find a tutorial that adds one feature closer. You don’t want to go from your first Javascript functions to a frontend with React and a NodeJs backend. You’ll get there in time!

• If you are finding things difficult, go through the tutorial exactly as instructed once. Then re-take the tutorial but start tweaking it towards your goal project.

Eventually, with this iterative approach, you will be creating awesome, self-driven projects! Most importantly, as you do your own research and experiment, you will start learning much more deeply than you would following any tutorial.

Last Words

I don’t want you to come away from this thinking that tutorials are bad or that the people who make them are bad. Instead, feel empowered. Tutorials are not mandates from heaven, they merely point you in a general direction. It’s your responsibility to take the reins and make it work for yourself.

This is the approach I still take to this day when learning a new technology, even with a decade of experience under my belt. If it works for me, it just might work for you too!