EMS/Fire Tools:

What is Second Due?

Second Due is a piece of software I created for Caroline County Firefighter/EMTs that gives helpful information we can reference en route to a call such as nearest water sources, nearest helicopter landing locations, and routing directions to call. It was created in response to the fact that current solutions such as First Due, Active 911, and Fire Mobile are lacking features that I believe providers would find useful. This program is not affiliated with or endorsed by Caroline County Fire Rescue.

How is Second Due better than First Due?

How does Second Due work?

Front End - JavaScript

Second Due performs most of its functions on the frontend through client-side JavaScript and makes heavy use of the Google Maps API. In the past when I'd write JavaScript, I'd use janky workarounds to avoid asynchronous functions because I didn't want to learn how to use them. After writing JavaScript "the right way", lots of asynchonous functions with promises and callbacks and all that, I found that not only is it better code but it's easier to write and read once you understand it.

Front End - Google Maps API

The Google Maps API proved incredibly useful with this project and had every single feature you could think of already built into it. Need to calculate the time, distance, and major roadways reccomended to take for 10 different routes from one location to many and list them in an array? Google Maps API has already gotchu with minimal work required on your end. Need to display custom county lines and lines subdividing a county? Google Maps API has got your back. Need to be able to search for places with an autocomleting search bar. Don't sweat it with Google Maps API.

Back End - NodeJS Server

I run a NodeJS Server that scrapes data for call information and hospital wait times. The NodeJS server uses websockets to connect with the client side JavaScript and send updates when a call comes out or a hospital wait time changes. Like my client-side JavaScript, I was tempted to be lazy and forgo the asynchronous websockets to transfer data between the client-side JavaScript and my NodeJS server and do some hacky thing where the client-side JavaScript fetches a file hosted on my server every minute and my NodeJS updates that file every minute. I decided to do the right thing and learn websockets, which results in less unnecessary traffic (traffic is only sent when my NodeJS server detects a new call or a change in hospital wait times) and is more elegant.

Back End - PHP and MySQL Server

Even though all dispatch information is broadcasted over public radio, which means anybody can listen to it (even people halfway across the world can listen to our traffic because someone is running an online repeater in Caroline County that lets anyone listen to fire rescue radio traffic in Caroline online), I don't want to be responsible for further sharing that information. To ensure only Caroline County employees can access the call data, I created a user login system that only issues accounts to people with a Caroline County government email and who I have confirmed that they themselves made this account. It has all the security features expected of a login system (that are weirdly missing on even some large websites) such as hashing and salting passwords with the latest algorithms, HTTPS, and anti-brute force detection.

Back End - DigitalOcean Hosting

This whole shebang is hosted on a DigitalOcean server. After running websites off of home servers for 4 years, I'm tired of the headache of involved. This headache includes having to set up auto-updating DNS because I can't get a static IP for my house, hardware breaking down, not being able to scale if your server gets a spike of traffic, and having a computer in your house you always have to have turned on. The price of the DigitalOcean server is 100% worth not having to fix problems totally unrelated to the purpose of my website.