Open Source

Summarized using AI

Firefighting on Rails

Ethan Vizitei • April 29, 2013 • Portland, OR

In the talk titled "Firefighting on Rails," speaker Ethan Vizitei discusses how the Ruby on Rails framework has been utilized to solve unique logistical challenges within a volunteer fire service organization in Missouri. He shares his dual experience as a software developer and firefighter, explaining the significant constraints faced by volunteer departments compared to career fire departments, particularly regarding communication and information dissemination during emergencies. The main points of the talk include:

  • Background on Firefighting: Vizitei outlines the differences between career and volunteer fire services, emphasizing the need for efficient communication tools in volunteer organizations.
  • Challenges with Traditional Systems: He details how traditional systems like pagers provide limited information, leading to potential miscommunication during emergencies. He highlights the audible nature of pages, which can disrupt personal lives and relationships.
  • Technical Solution: Vizitei introduces a web-based application he developed, which automates the process of notifying firefighters via text messages, allowing them to receive critical information about emergencies without the noise of pagers.
  • Implementation Details: He discusses the architecture of the application, emphasizing its reliance on Ruby on Rails, MongoDB, and various notification services. The app retrieves data from existing web status boards and sends customizable alerts to volunteers based on their subscriptions.
  • Impact of the Application: The talk outlines the positive outcomes from adopting this technological solution, such as improved response times and reduced reliance on outdated methods. This project, although not aesthetically pleasing in terms of coding standards, resulted in significant real-world impact for his fire service.
  • Key Takeaways: Vizitei concludes that the essence of software development should be about solving problems rather than focusing solely on coding excellence. He encourages software developers to leverage their skills for community service, particularly in volunteer fire departments, demonstrating the importance of problem-solving in both firefighting and software development contexts. He invites developers to consider how they can make meaningful contributions to their communities through their technical skills.

Firefighting on Rails
Ethan Vizitei • April 29, 2013 • Portland, OR

It's always inspiring to me to hear about how the technology stack I'm familiar with has been used to solve interesting problems; this is one of the extreme versions of that experience. Over the last few years, Rails has been used to solve several of the logistical pain points of the third largest fire service organization in the state of Missouri, and in this talk we're going to look at how it happened. Along the way we'll look at some of the challenges of working with such an out-of-the-ordinary organization and how Rails fit into addressing some fairly unique requirements and constraints. This is one Rails-in-the-wild case study that you won't want to pass up.

Help us caption & translate this video!

http://amara.org/v/FGaL/

RailsConf 2013

00:00:16.400 Hey, hello! Thank you for coming. This is "Firefighting on Rails." My name is Ethan Vizitei, and I'm a software developer who writes code for a living.
00:00:29.039 I hope that before the end of this talk, you all will change your mind about something. This is where I used to work, at various places, and I liked them well enough.
00:00:41.760 This is where I work now—12 Spokes—and I love it. I can't stress that enough, and there are many reasons why. I could go into them, but it’s not really the point of the talk. Two relevant points: I work about 35 hours a week, which gives me a lot of free time—much more than some people in the industry. The other point is that I don’t work from the office.
00:01:19.840 This is 12 Spokes, but unfortunately, I have a very limited selection of pictures. This is the only picture in existence that has everybody from 12 Spokes in one room, so it got this spot by default. This is where everybody lives, as 12 Spokes is based in Salt Lake City, Utah, and we've got people all over the United States. We are a totally distributed team, which is great because it keeps our overhead down and allows us to live in low-cost-of-living areas near our families.
00:02:05.840 If anyone wants to talk about the merits of having a distributed team or some of the challenges, that’s a great topic I love discussing. Feel free to come see me afterwards; it's worth looking into if you've been thinking about it. The reason this is relevant for today is this: This is where I work every day, which might not seem particularly out of the ordinary until you realize it's in this building.
00:02:49.920 For those of you who don't recognize the distinct construction, this is a fire station—my fire station. I am a software developer during the day and, for about half my life, I'm also a firefighter. I do both, and if that’s not enough cognitive dissonance for you, I did ballet for eight years. These are both huge parts of my life.
00:03:20.480 Every day at work, my worlds are colliding. I have left client calls to go to fires, and I have not gone to fire training because it was really important to get a deployment out that night. It's tough; it’s not an easy part of my life, but I love both parts of it. One of the upsides is that it landed me in the middle of some really interesting projects, which is kind of the point of why I'm here today.
00:03:56.560 I have a wide set of apps that I’ve worked on that have helped the fire service in my area in some way. I was supposed to give a survey where I walked through them and said, "Here's some of the really cool things with Rails I did for the fire service," but I kept coming back to one application—the first one I wrote for the fire service. It was terrible but was also wonderful because of what it did.
00:04:25.599 However, before I can tell you about that app, you need some context. Without understanding the problem, it’s going to be difficult to see what a great solution it was. So, bear with me for a minute while we go away from software development and into firefighting.
00:04:57.520 This is the American fire service. It basically has two sides: career and volunteer. There’s some debate in the fire service industry about these groups. The career firefighters think volunteers don’t have enough time, training, or skill. Volunteers think the career guys are just in it for the paycheck. They're both right for about two percent of the opposite group, but for the rest, it doesn’t matter.
00:05:24.239 Fires don’t burn differently whether they’re covered by volunteer departments or career departments. It’s all the same issues they’re dealing with; it’s a matter of population density. When you have a lot of people living in one area, there’s a higher tax base and greater demand for 911 services. When there isn’t that density, those numbers go down—but you still need some service.
00:05:54.400 That’s where the volunteer service comes in. You might have a picture in your head of a volunteer fire service as small-town operations, but that's not how it is. In the state I’m from, we have 14 stations and a whole bunch of trucks. We cover 492 square miles and operate on the order of 50 calls a weekend, with 15 911 calls for service.
00:06:12.960 And we do it all with volunteers, which we’re very proud of. But there is one significant difference between career and volunteer. This is the Minitor Five Pager made by Motorola—it's a device you don’t see much anymore because it's simple and lacks many modern features. It’s just a speaker with an on/off switch.
00:06:42.720 But it's a decent solution to a challenging problem. When you're a career firefighter, you can have a few paid personnel at a station waiting for an emergency. When a call comes in, there’s a system to alert them with maps and instructions. It’s efficient. However, for volunteers covering multiple stations, especially when emergencies don’t schedule themselves, it creates burnout and availability issues.
00:07:07.920 Our solution involves having at least one person at the station who can drive the fire truck while the others are alerted via pagers. When your pager goes off, you listen, get into your car, and rush to the emergency. It’s a decent but challenging method. The pagers work on specific radio frequencies that open when they receive a tone sequence for a particular station, allowing volunteers to respond if they’re nearby.
00:08:09.440 However, the drawbacks are significant. First, they’re extremely loud, and that can lead to friction at home when they go off during odd hours. Additionally, the communication is audio-only, resulting in limited information available to those not at the station. There's only one channel for communication, and managing it can become complex.
00:08:48.160 To give you a sense of how jarring the situation can be, I’d like to play an actual dispatch recording from my area. Listen closely to the sequence of names and addresses provided as a response to a structure fire. You have to recall important information quickly under stressful circumstances, which becomes problematic when transmissions aren't clear.
00:09:32.160 You might think it’s easy to track quick information when you're on the ground, but when multiple calls come in constantly, it becomes overwhelming. Imagine dispatching 200 people to a fire and only ten recall addresses clearly; that’s not effective.
00:09:57.679 However, there are ways to make this easier over time, as you become familiar with the communication scripts and what information is most pertinent. But as someone who enjoys problem solving, I thought we could improve this process.
00:10:37.679 Why don't we develop a small device that not only alerts firefighters but also provides them with critical information at their fingertips? To clarify, while some companies offer this technology, margins prevent them from making it a viable option for small fire departments, which are often volunteer-based. It didn't seem like a complex task to tackle.
00:11:05.200 As a developer unsatisfied with the existing scenario, I took it upon myself to create a web status board that offers immediate alerts and notifications. I used various technologies like Twilio for texts and MongoDB to store call data in a document format, simplifying the process.
00:11:36.600 The objective was simple: create a mechanism that continuously scans the dispatch web page, gathering current call data and alerting relevant firefighters based on their designated preferences. This system allowed them to receive notifications about specific trucks they were interested in without needing to listen to chaotic dispatch radio communications.
00:12:01.120 The first application I wrote was quite rough but served its purpose effectively. Eventually, it evolved to incorporate useful features, such as linking maps directly to the interface, permitting firefighters to visualize their locations while responding to calls.
00:12:24.080 I realize now that despite its limitations, the application significantly improved the situation for many firefighters in my community. Our notifications now allow personnel to maintain awareness while limiting distractions from their pagers.
00:12:56.440 Coming to fire calls now means that firefighters are better equipped to handle emergencies while also having the benefit of communications that are instant and relevant. When we came in for annual gear checks, some members had forgotten how to use physical maps, relying instead on the convenient system we created.
00:13:36.080 This highlights the impact of making technology work for us instead of against us. But, as developers, some important lessons came out of this experience. For example, don't forget the central reason you create applications or software: to solve problems, not just to code.
00:14:05.600 If software isn’t user-friendly or practical, it won't be effective—even if the code is technically sound. We need to strive for building something valuable for the users and, most importantly, to solve problems with empathy and care. Just as in firefighting, where the goal is to help people in need, the same principle applies in software development.
00:14:47.480 I learned that coding should not be blindly pursued without regard for how people use it. If I spend hours optimizing a system without genuinely contemplating its value for the user, it could render all my efforts inconsequential. This illustrates that, at the end of the day, it's the results that truly matter.
00:15:08.640 Finally, bear in mind that being nice goes a long way. You can change a lot through kindness and consideration, and that’s just as relevant for developers as it is for firefighters.
00:15:50.040 The vast majority of volunteer firefighters are intelligent individuals capable of problem solving, much like software developers. Their skills can contribute greatly to their communities. It’s essential to have people with the right mindset in fire departments, especially when timely responses can save lives.
00:16:25.920 If you work remotely, consider dedicating time during your day to volunteer at a fire station. You could build connections and make a positive difference. Make no mistake—every contribution counts.
00:16:58.720 12 Spokes is amazing, and our code reflects that. If you are interested in software and want to see quality coding practices, come see us.
00:17:18.200 Thank you all for coming to the talk, and I hope you gained some valuable insights that you can apply to your respective fields. Let's strive to solve more problems with the skills we’ve honed, whether in software development or in supporting our communities.
Explore all talks recorded at RailsConf 2013
+93