@avishgoyal

Building software always starts with a beautiful delusion. You think you’re just taking a neat little script that prints satellite passes to a terminal and giving it a pretty web face. But the second you try to turn it into a real app, the code fights back. You modularize the math, build a safety net so the app doesn’t crash if the external tracking servers go down, and think you’re golden. Then you try to make it smart enough to track things based on where a user is actually standing, and you accidentally unleash an infinite reload nightmare that traps your browser in a loop, forcing you to write a literal memory-check in JavaScript just to stop the page from having a total meltdown. Once you break out of that loop, you realize tracking things in space means dealing with the absolute chaos of time itself. Space math lives in UTC, which is completely useless to a human looking out a window. So you find yourself wrestling with system timezone databases just to translate those raw numbers into normal, local clock times. At the same time, you build a massive, beautifully categorized dropdown menu to track everything from the ISS to random space junk—only to watch the interface develop instant amnesia, resetting itself back to the default option every single time the page refreshes. Fixing it requires writing a client-side script that acts like a digital detective, checking the web address to force the menu to remember what you clicked. But the absolute worst part? The ghosts in the machine. You try to track specific ships, and the app just returns a blank screen. You spend hours digging through raw text lines only to find out the tracking database is silently laced with hidden, non-breaking space characters. They look identical to normal spaces to a human eye, but to a computer, they break strict string matching entirely. After aggressively scrubbing those invisible characters out of the memory loops, you finally cross the finish line by hooking up a live countdown timer that ticks down to the exact second a satellite crosses your sky. You started with a text printout; you ended up surviving a relentless gauntlet of infrastructure fires.

Building a reliable ISS pass predictor has been a lesson in balancing ambition and my own consistent ability to break perfectly good code. I started by moving my entire development workflow to GitHub Codespaces, which has been a lifesaver; it provides a clean, cloud-based environment that keeps my local machine safe from the digital clutter and potential malware risks I encountered during my previous projects. Seriously, I’m pretty sure my machine still has the digital equivalent of an STD from that dock project I made a while ago. I tackled the core prediction engine using the Skyfield and Requests libraries, which allow me to pull live Two-Line Element (TLE) data directly from CelesTrak (which is a website that basically contains all the TLE for almost every satellite), ensuring that every calculation is based on the most recent orbital telemetry. The most significant hurdle I faced was refining the state machine logic within my prediction loop. Without a proper tracker, my initial script would suffer from an existential crisis, mistakenly logging “Set” events before “Rise” events or failing to account for passes that were already in progress when the script began (Please dont judge me, I’m a beginner and tho I have completed half of CS50, it has been a while since I have coded anything…). I solved this by implementing a persistent tracking dictionary that survives outside the loop iterations, allowing the program to safely identify and group the three distinct phases of an ISS pass: the Rise, the Peak, and the Set. Along the way, I navigated some predictable debugging hurdles, such as TypeErrors caused by me trying to force-format a Skyfield Time object as a simple float—which is a fantastic way to make your terminal scream at you—before I finally realized I needed to use proper UTC string formatting. The project is now at a point where it successfully processes raw orbital geometry for my specific coordinates in Greater Noida and exports clean, actionable data. With the backend logic stabilized, my next steps involve refactoring the code into a modular utility for my Flask API and building. Once my exams are finished, I intend to dedicate full-time focus to this project and my upcoming plans for a personal homelab setup, provided I don’t accidentally join a botnet in the meantime.