After that little excursion, an idea popped into my head.

Basically, I’d been wanting to make a database project, since I’d never done the whole create and populate tables from scratch thing before. My idea was to scrape all the courses currently being offered during the Fall 2025 semester, chuck the data into a relational database, and create a real-time map visualization of what classes were going on around you—a “course map” of sorts.

The first step was figuring out where to get the data from; I’ve seen a bunch of “UIUC course this or that” projects before, so I was sure there was a way to get that data. I ended up stumbling across this github repo that had basically all I needed to get started.

Since I wanted to visualize in real-time which classes were happening, I would need to know more than just what classes were being offered—I needed all the sections of those classes in order to figure out their start and end times. Turns out that the scraper from the repo used the /schedule and /catalog directories interchangeably when requesting data from the course explorer, which I didn’t notice at first. Only when I saw a slight inconsistency in the URL when switching between tabs did I realize the difference. I needed to scrape data from /schedule because that’s where all the course section information was.

Once the scraping URL was figured out, I got to automating it. The first thing to tackle was the course explorer “directory structure”. I use quotes because the main “directory” is really just an XML file that contains links to other XML files, but I’ll just treat it like a folder. Here’s how it’s organized:

schedule/2025/fall
├─ AAS
├─ ...
├─ CS
│  ├─ 100 (CS Orientation)
│  │  └─ AL1
│  ├─ 101 (Intro Computing)
│  │  ├─ AL1
│  │  ├─ ...
│  │  └─ AYS
│  ├─ ...
│  └─ 598 (Special Topics)
│     ├─ AO2
│     ├─ ...
│     └─ YLL
├─ ...
└─ YDSH

To access every section for every class, we need to do a tree walk through all majors (AAS-YDSH), collecting the sections (AL1, AL2, etc) for each of that major’s classes (100, 200, etc).

I saved a local copy of every XML file that I scraped so I wouldn’t have to repeat the process if something went wrong during scraping, effectively checkpointing my scraping progress based on saved files. This ended up coming in handy when one of my requests was denied, causing my script to skip a class or two. I was able to instantly restart scraping from the skipped classes thanks to the checkpoint.

To prevent this post from dragging out too long, I’ll rapidfire the last couple points I wanted to make.

• Database table structure: I decided on three tables: classes, sections, and buildings. Each section references an external class ID and an external building ID.
• Data cleaning: While populating the database, I ran into format errors due to missing section end times, room numbers, and other attributes. For simplicity, I filtered out everything that did not fit my schema. I also filtered out online classes for obvious reasons.
• Visualizing it: My frontend relied on leaflet.js to render course locations, which required each building’s longitude and latitude data. The data I scraped from the course explorer did not contain coordinate information, so I used Geoapify’s Address Autocomplete API to figure out the exact locations for each building I scraped. Again, for simplicity, I deleted any sections with buildings that the API could not locate.

After adding some UI components and making the app somewhat presentable, I briefly hosted it with Vercel, Supabase, and Fly.io, and was able to use CourseMap out in the world. Here’s a screen recording I took outside Grainger library.

You can find the source code here.

I first found out about RealWorld Cursor Editor and the massive online sphere of cursor making (check it out!) after seeing a classmate using an animated cursor. The sheer amount of creative potential being unleashed within that tiny 32x32 pixel canvas was truly something to behold. As I was browsing, I saw a Terraria slime themed cursor pack, and I instantly knew what I needed to make: Terraria critter cursors. Terraria was a huge part of my childhood, and memories of playing it as a kid have given the game a special place in my heart. Terraria’s pixel-art nature made it an especially good candidate for cursor creation—the small critters would fit really nicely as cursor pets. What made it even better was that I had access to the game’s sprite animations, so all I needed to do was copy them into the cursor editor.

Here are some of my favorites:

The process was pretty tedious, involving a lot of cutting up animation frames and pasting them into the editor. I figured that if I was just going to be copying and pasting frames, I could definitely automate the process, but that deserves its own blog post. This post is more of a showcase of some stuff I found pretty cool. Hope you did, too.

Anyways, I wanted to play around with Ocaml on my own and get comfortable with its various features, and, more generally, with functional programming. And in order to do that, I’ll be implementing Conway’s Game Of Life in Ocaml. Any readers unfamiliar with the Game Of Life should take a minute to skim the wikipedia page. Essentially, there’s a 2D grid, and we refer to each block in the grid as a cell. Cells can be either alive or dead, and every timestep, a cell will change (or stay the same) based on the aliveness or deadness of its eight surrounding neighbors. The only user input to this game is the initial grid state. Afterwards, the cells act autonomously.

I’ve never implemented Game Of Life before, so I started by coding in Python, a language I am quite comfortable with. Almost immediately, I ran into a bug—let’s see if you can spot it.

This is a snippet of my Python code, which shows a function that computes the update that should occur given the current state of the 2D grid.

class GameOfLife:
    ...

    def update(self):
        # each cell's action is independent of all other cells at every timestep
        # so we need each cell to have a reference to the previous state
        reference_grid = self.grid.copy()
        for x in range(self.height):
            for y in range(self.width):
                # store whether or not the cell is alive
                is_alive = reference_grid[x][y]
                
                # count how many neighbors are alive
                alive_neighbors = self.get_num_alive_neighbors((x, y), reference_grid)
                
                # a living cell with less than two living neighbors or more than 3 living neighbors dies
                if is_alive and (alive_neighbors < 2 or alive_neighbors > 3):
                    self.grid[x][y] = False
                    continue
                
                # a living cell with 2 or 3 living neighbors stays alive
                if is_alive and (2 <= alive_neighbors <= 3):
                    continue
                
                # a dead cell with exactly 3 living neighbors comes to life
                if not is_alive and alive_neighbors == 3:
                    self.grid[x][y] = True
                    continue
                
                # otherwise, do nothing

Did you spot it? Look right below the function declaration, the line with reference_grid = self.grid.copy(). Basically, I was storing the grid as a 2D array, AKA a 1D array containing other 1D arrays. By using Python’s built-in list.copy() method, I assumed that I’d be doing a deep copy of the entire 2D array, so that no change I made to the original list would show up in the copied list. However, list.copy() performs a shallow copy, which creates a copy of the list you provide, but not the items inside that list. Since the items I was storing were lists themselves, which are mutable in Python, I was unwittingly referencing the same contents from the original list in my “copied” list.

There’s nothing like a good bug to drill an important concept into your head. Had an LLM just generated the correct code, I wouldn’t have covered the gap in my knowledge, which is why I’m writing all the code by hand.

A couple hours later, the OCaml implementation is working! Honestly the time spent on this project was probably split 40/60 setting up the local OCaml environment (I tried and failed to get it to work on Windows, but luckily Ubuntu worked) and actually writing out the code. Anyways, it was definitely worth it. I practiced using Array functions like fold_left and had fun translating my programming intuition from Python over to OCaml.

Here are some highlights—the full code is on my Github.

When creating the 2D array to store the grid state, I quickly learned the difference between Array.make and Array.init—the former creates an array with copies of whatever initial item you pass in, while the latter calls a function for every element created. For Arrays, this is especially important, as they are mutable.

let init_grid h w = Array.make h (Array.make w 0)

and

let init_grid h w = Array.init h (fun _ -> Array.make w 0)

have very different behavior, and this reflects the lesson I learned while writing my Python implementation.

At the beginning, I was hesitant to use Array library functions, instead opting to write out all the details myself. In this snippet, I wrote a function to get the number of alive neighbors of a certain cell.

let get_alive_neighbors cell =
  let rec num_alive neighbors =
    match neighbors with
      | [] -> 0
      | cell::cells -> let x, y = cell in if grid.(x).(y) = 1 then 1 + num_alive cells else num_alive cells
  in num_alive (get_neighboring_cells_wraparound cell)

I noticed that the same functionality (value-based aggregation) could be achieved with fold_left, so I revised my initial code.

let get_alive_neighbors cell = Array.fold_left (fun r -> fun (x, y) -> if grid.(x).(y) = 1 then r + 1 else r) 0 (get_neighboring_cells_wraparound cell)

By using fold_left, much of the boilerplate code was removed, allowing me to focus on the core functionality.

One last thing I noticed was that the constraints of functional programming forced me to think differently about how I went about my implementation. In my Python code, I took the easy route and stored an entire copy of the grid every time I needed to make an update. In OCaml, however, it wasn’t obvious to me how I’d be able to replicate what I’d done in Python, and that’s what helped me arrive at a better solution: storing only the cells that need to be toggled instead of the entire grid. This circumvents the issue I had in my Python code, which incrementally updated the grid, necessitating a previous grid to be stored. Now, the cells that need to be toggled are stored without modifying the grid, then the grid is updated all at once, saving a ton of space.

Sometimes the best thing we can do to make progress is to go back to basics.

In 2014, when I was ~9 years old, my mom sent me to a summer camp for stop-motion, where I produced my first full-fledged animated film. It’s still on Youtube, if you want to give it a watch (warning: I had a couple screws loose as a kid).

Anyways, what’s the point of this blog post? I’m going to live my animation dreams, after all, right? What do I even mean by that? In short, I want to relive those pure moments of creative discovery and exploration that I had as a kid. It was easy back then; children are blessed with the gift of unlimited novelty in anything they do. In order to get at that experience, I’ve downloaded an app for 2D animation to see how much creative energy I can release.

I’m going to play around with it see what I can cook up.

Fast forward…

Not too shabby for a first time, but there’s plenty of room for improvement. This was a pretty fun little project, and I’ll post updates if I decide to make more short animations.