Front End Software Engineering in the Service of America’s Pastime
These are exciting, if not volatile, times for front end software web engineering. New libraries and frameworks appear every day. Most have a pretty short shelf life. Tens of thousands of abandoned Github projects exist only to impress potential employers. But a few really stand out as both novel and practical. One of our top front end engineers Rich Goldman describes a project he built that uses React, an open source front end framework by our friends at Facebook, which stands out as the best of its kind, at least for the foreseeable future.
In this first of two articles, I’ll give an overview of how a friend and I took an idea for a simple, monetizable smartphone app from inception to publication. I’ll explain why we chose the combination of technologies we did from the vast array of open source options that were available to us, and I’ll be sure to point out anything we found interesting along the way.
The idea itself is called “Pitch or Perch.” It’s a fantasy baseball app that assigns numeric scores to starting pitchers, which quickly lets users determine whether they should start a given pitcher or bench him. This is normally the most difficult aspect of managing a team, because there are literally hundreds of starting pitchers in Major League Baseball. Beyond their natural talent, pitchers can display a wide variance in quality from start to start. They’re prone to hot and cold streaks; they may be facing a gargantuan offense, such as the historic 2016 Red Sox; they may be up against an ace on the opposing team, which would greatly decrease their chances of getting a win; they may be pitching in a ballpark that has thin air, like at mile-high Coors Field in Colorado, where the average ERA is a full point higher than in any other stadium. These are just some of the factors that play heavily into whether a pitcher is going to hurt or help your fantasy team on a given day. It’s almost impossible to keep track of all this, so an app that uses a good data feed and a set of relatively simple algorithms can quickly help users set their pitching rotation with confidence and move on with their day.
In our case, the user was primarily reading data (just vital pitcher stats and the numeric score), and so the app seemed like an excellent candidate for PhoneGap. We decided the app should just update itself overnight with the next day’s projections. In fact, we didn’t even need the user to log in, because we weren’t collecting any information from them. At some point in the future, we may allow the user to store their pitchers in our database, but with only about 30 or 35 pitchers starting on a given day, it’s not a big concern for launch date: Opening Day 2017.
One feature we believed critical was being able to see at least three days out. A common issue in leagues with daily lineups is that the user might “go dark” for a period of time — usually it’s kayaking with the family or something equally prosaic. They need to be able to set their lineups at least a few days in advance.
With our basic tools configured and in place, we were finally ready to work on the app.
First, we figured out the algorithms we would use to calculate our pitcher scores. This is part of our secret sauce, but we can let on that it involves an amalgamation of projection data from different sources. We tweaked the algorithm to print out a score between 60 and 140 for each pitcher. In line with sabermetric statistics, a 100 represents an average start for a pitcher. A 140 represents a start is 40% better than an average start. Obviously, this part is very difficult to quantify, especially considering leagues have different scoring formats. What might be a great start in one fantasy league might be only mediocre in another. But these approximations are close enough for launch, and we’ll eventually allow users to input their league’s scoring format in order to provide them with more accurate predictions. We’ll be keeping a close eye on our calculations and will likely have to tweak things as time goes on to improve our predictive model.
Now that we had the list of pitchers, the other major view we needed to build was the pitcher’s vital stats that would appear when you clicked on his name in the list. We called this file PitcherDetails.jsx and added the appropriate HTML5 and ES6 to build out that view. Since Gulp was configured to watch our jsx directory, it automatically picked up on the new file and did the proper post-processing and re-deployment via Webpack and Babel.
We needed one more component, called PitchOrPerch.jsx, which was simply the container for both PitcherList.jsx and PitcherDetails.jsx. In React, a container for other components is a component itself. With three fairly simple React components, our content was complete for launch. Next came the styling. We used the new CSS flexbox model — finally supported across modern browsers — to allow for responsiveness across devices, which was critical for our app. Smartphones have a huge range in resolution and pixel density, and flexbox allowed us to support all these sizes with a minimal amount of effort — and without having to include heavyweight dependencies such as Twitter’s bloated Bootstrap library.
Finally, a few too many hours were spent scanning through gigantic font foundries searching for baseball-inspired fonts, and writing arcane CSS to get the fonts to display on every browser and device.
At this point, I hope you have a better understanding of what it takes to build a simple React application from beginning to end. As I noted before, a real-world app requires not only React but a host of other tools and dependencies, as managed by Node Package Manager.
In my next post, I’ll detail the thrilling travails of converting and optimizing our app for our target platforms, iOS and Android, using Adobe PhoneGap. We’ll look at the process of testing and debugging with tools such as BrowserStack, and at getting our apps approved and published in their respective online stores. And finally, we’ll talk a little about our marketing approach and we’ll see how we actually do in the first month of launch, April 2017.