Active911 Rescue Film

We made a short video saluting the work of fire and rescue personnel everywhere.? This video played for the first time at our booth at FDIC 2015, and now that we are back we wanted to share it with everyone else.

Thanks to everyone who helped us make this, and to all of you out there doing what you do.

It’s Programming with Paul!

Hello, I’m the newest developer here at Active911. I started about 3 months ago and since then I’ve more or less taken over Android development from Jon, implemented the calendar interface you’ll see in the PAR board update, and worked to verify an upcoming change in how we manage your data. I’m going to write about that last one today.

But first a little about me. I’m nearly 21 and I’ve been interested in programming since I was about 11 when I started writing games on my mom’s old laptop. I spent a large part of my free time in my teens learning about computers, programming and generally nerdy things. I went to Pacific University for 2 years, but it felt like a waste of time – I wasn’t really learning anything new. I wanted to see how I could fare in the real world so I applied for a job, and here I am.

Right now all of the data lives in a database on one server. Fetching data in this system is really simple; there’s only one server with the data, so all the clients just need to know where that one machine is. Unfortunately, this approach has two big problems, which I’ll call the scaling problem and the single point of failure problem.

As Active911 grows, so does the load on that server – the scaling problem. Making the machine more powerful helps, but you can only add so much RAM and processing power to one machine, and it doesn’t do anything to fix the single point of failure problem.

Right now every single request for data from the database goes to this one server. If it goes down for any reason, every database request will fail – the server is a single point of failure. It doesn’t really matter how beefy the server is if a tree falls on it. We have a bunch of failsafes like backup generators and not having old trees next to our server room that make it extremely unlikely this will happen, but we’d rather have backups in place to limit our downtime even more.

To do this we’re breaking our database up into a bunch of databases – called shards – and distributing them across many servers. Sharding the database goes a long way to solving both the single point of failure problem and the scaling problem: one server going down isn’t the end of the world because we have a bunch, and many servers working together are more powerful than any one server can be. Of course, the problem with this approach is figuring out how all these servers are going to work together.

For the past couple of months Jon’s been doing exactly that. He’s designed and implemented a sharded database called Bard, and an interface to that database called GUA (Grand Unified API). When a client makes a request for a piece of data, it will make that request to a server running the GUA. That server will send the request to Bard, which will figure out which server that piece of data lives on, fetch it, and return it. The GUA takes the data, does some basic sanity checks, and returns the data to the client.

Jon’s designed the system so data can be located near the people who use it. This means that in the future we’ll have a server in (for example) New York that holds data for users in New York, but doesn’t require any special setup for devices in New York – our service will see where they’re located and automatically store data in the nearest shard. This means our service will be faster, more reliable, and more scaleable.

We’re going to roll out the sharded database in the coming months, starting with the upcoming PAR board features. If all goes according to plan you won’t see any changes as a user, but we’ll be providing a much more reliable, efficient service on the backend, even as we continue to grow.

The Constant Learner: Introduction

Hello everyone!

I guess I am the next developer to introduce myself. I started with Active911 just as it was getting started as a Customer Service Technician, way back in March of 2013 and transitioned into the development side several months ago.

While Active911 was getting off the ground, we relied heavily on Cadpage and the work they had done with their parser library. As Active911 grew, some problems became apparent. Cadpage became unable to support the sheer amount of new parsers and parser adjustments that Active911 required, and the programmer for Cadpage ended up overwhelmed and overworked. About a year into my support role, Active911 targeted this area for improvement and developed some tools to allow parsers to be built and maintained more easily. Knowing how many people were waiting for parsers, the support team worked feverishly on the backlog. Whenever we weren’t on a phone call or handling an email ticket, we were working on a parser trying to get as many departments up and running as we could.

When Active911 decided we needed someone to work on parsers exclusively, I was experienced enough to handle the transition and volunteered. In my free time, I took to learning computer programming from the ground up. After several months of near constant learning, I had become proficient enough to start contributing to Active911 development, so here I am. I build and maintain the parser library, doing my best to make sure your messages come through in a way that is readable and mappable. I also work with our more experienced developers to produce new and exciting features.

In terms of my recent projects, I have been working with the rest of the team to develop a calendar/assignment tab on the main website and tying that into webview to add a PAR board component. I am also working to speed up and streamline the Activation process to help new accounts get the parsers they need faster and more efficiently. Once that is wrapped up, I will begin assisting in the development of the windows tablet.

Here is a brief look at the webview PAR board before it hits beta testing:

Sneek Peek

Behind the Curtain: A Re-Introduction

It’s been a year since I’ve lasted posted here, and quite a lot has changed.

As we continue to grow, we’ve been reviewing our external communication channels, and started exploring new ways to engage with our customers. There aren’t many direct means of contacting our developers, but we do read the forums weekly.

One thing we introduced late last year are developer Q&A sessions. We have had 2 so far in November and February, and our next one is coming up in May. We are planning for the Q&A sessions will coincide with our app updates, which we are aiming to release at the beginning of each quarter.

Aside from the Q&A, we’re going to begin posting regularly on this blog each week, rotating between developers. We’ve added a few new faces to the development team, who you will all meet soon through this blog as well. I will let them introduce themselves in the coming weeks.

Of course this really wouldn’t be a look behind the curtain if I didn’t give you guys a sneak peak of what is coming up. The main focus for the past couple of weeks has been a new feature which will allow creation of “Assignments”.

These could be anything from ordinary station assignments to specific crew assignments or even roster status assignments. The main idea is to give your agency the ability to know who is supposed to be assigned to what at any given time. A simple example would be setting up assignments to represent your multiple fire houses, and scheduling which house everyone should be at each shift.

We’re really excited to roll out this feature in the upcoming month, and will putting out a testable sandbox later this week. Look for a link to it in the upcoming newsletter!