Implementation Thinking

Based on this chat with Gemini I think we have a good plan:

  1. I haven’t taken 15445 Database Systems yet. But afterwards I hope to have the skills to build my own database engine. For now, I’ll use dependency injection: create a generic data store and load interface, and then use SQLite for now. Or maybe use an even simpler JSON-file based storage system.

  2. Create a ledger of events. Events can be OAs, interviews, etc. This way, we have flexible timelines. Each job application has its own mini git history of sorts.

  3. Filter events that are pending/upcoming/TO-DOs into a docket

  4. automatic logging of metadata for easy chartmaking

Main Data Structures

An Entry

an Entry contains

  1. UUID
  2. Category:
  • job application
  • scheduled coffee chat
  • networking event
  • career fair event
  • to be extended…
  1. Title
  2. Company
  3. Tags
  • Finance, Startup, BigTech, etc.
  1. Link
  • a link to the job app board
  1. Notes
  • any important notes, such as a recruiter’s phone number of something
  1. An event ledger
  • consisting of (probably a doubly linked list) of events

An Event

has an id linking back to its corresponding entry

event_type such as OA received, OA complete, interview scheduled, interview done, rejected, accepted, ghosted, etc.

timestamp for when the event_type occurs

metadata which is kinda up in the air what I might need.

For an interview I’d like round number, behavioral vs technical vs general, and probably somewhere to either link to my notes or write notes.

The Transition Validator State Machine

it wouldn’t make sense to go from OA complete to OA received - so basically there’s only a few logically valid state transitions. This is sort of a DFA.

Roadmap from Gemini

Gemini Source: https://gemini.google.com/share/f59576ddbb6f

Building your Job Tracker as a local-first, native desktop application using Raylib allows you to create a high-performance “Game-Style” dashboard that completely bypasses the complexity of web servers or CSS. Because Raylib uses Immediate Mode GUI principles, you can “paint” your “Weekly Pulse” charts and “Job Dockets” directly to the GPU every frame.

Here is your implementation roadmap, categorized by the core concepts and dependencies you will need to master.

1. Essential Dependencies

Raylib (Zig-Bindings): Use the raylib-zig package to interface with the C graphics library. This handles your window, inputs, and 2D/3D drawing.

SQLite (C-Library): Since Zig has excellent C-interop, you will pull in libsqlite3 to act as your “black box” storage engine.

Zig Standard Library: You will rely heavily on std.ArrayList for your in-memory ledger and std.json if you decide to store metadata as blobs.

2. Implementation Roadmap

Phase 1: The “Materialized” Backend

Before touching graphics, you must finalize the data flow.

  • Define the Core Structs: Finalize the Entry (parent) and Event (ledger) structs.

  • SQLite Schema: Implement Single Table Inheritance for entries, where different categories (Coffee Chat vs. Application) use different nullable columns.

  • The Ledger Writer: Create a function to append Event logs to your database whenever a status changes.

  • State Machine Logic: Write a Transition Validator in Zig that ensures an entry’s state only changes based on valid ledger history.

Phase 2: The Graphics Engine & “Docket” View

Get your first window running and displaying live data.

  • Raylib Initialization: Set up a basic $60$ FPS window loop.

  • The “Docket” Renderer: Write a loop that iterates through your “To-Do” applications and draws them as a scrollable list of text cards.

  • Input Handling: Use Raylib’s IsMouseButtonPressed to allow clicking on an entry to “open” its full history.

Phase 3: The “Weekly Pulse” Visualization

Transform your raw timestamps into the visual insights you currently miss in Notion/Sheets.

  • Time Bucketing: Write a Zig function to group your Applied events into weeks ($604,800$ second intervals).

  • “Zero-Count” Filling: Ensure weeks with no applications still appear on the X-axis by pre-populating your bucket list with zeros.

  • Drawing the Line Chart: Use DrawLineEx in Raylib to connect your weekly data points into a smooth timeseries graph.

Phase 4: Automated Insights & Cleanup

Add the “smart” features that automate your workflow.

  • Auto-Ghosting: Implement a check that flags any entry with no ledger updates in the last 6 months.

  • Tag Filtering: Add a “Command Palette” or button row to filter your dashboard by “Field” (e.g., Big Tech vs. Startups).

3. Key Concepts to Master

ConceptDescription
Immediate Mode GUIUnlike web DOMs, you don’t “update” a button; you draw it every frame and check if the mouse is over its coordinates.
Unix Time (i64)Store all dates as integers. This makes the math for your “Weekly Pulse” trivial and ensures SQLite compatibility.
Data NormalizationFetching raw data from SQL and “filling in the gaps” in Zig memory before you hand it to the renderer.
C-InteropCalling sqlite3_step() or InitWindow() from Zig. You will need to manage the transition between Zig slices and C pointers.

Does this “Game-Engine” roadmap feel like a manageable weekend-by-weekend progression, or is there a specific phase you’d like to dive into first?