Jack Stouffer

Things I've Worked On

Closed Source Projects

All of the things I have worked on for my job or I decided not to release its code.

A Stand-Up System

In 2013, I was (and still am) working for a company called Apollo America. Apollo has a morning stand-up meeting across the entire company, but at the time, everything in the meeting was done on paper. Graphs were drawn by hand on giant post-it notes that were stuck on the wall, and manually updated every day. News items were written on small sticky notes and stuck onto the giant ones.

Needless to say, this was a lot of maintenance, and it was hard for anyone more than 10ft away from the notes to see anything. So, my first task at the company was to digitize the whole thing into a web site and have it displayed on a huge TV in the cafeteria where the meetings take place. Using Flask for the server, and Backbone.js for the client I made an interface where

  • News items are entered, shown on the screen, and saved on the server during the meeting
  • Every morning at 4:00 AM, the previous day's KPIs are calculated and shown using Google's JS charting library
  • Weekly goal items are listed and can be checked off, which is automatically saved to the server
  • Things that need to be fixed, or "Broken Systems" can be entered, assigned, displayed, and then saved to the server during the meeting

The Backbone code on the browser loaded in all of the existing data from the server by having Flask's templating system dump the data into a Backbone collection when the HTML was rendered to eliminate the need for an AJAX request to the server. The collection has listeners on it to detect when ever a new item was added, modified, or dropped, and sent the appropriate AJAX request to the REST API, which then are saved to the database using SQLAlchemy.

The effect of the change to the electronic version was much more involvement from everyone in the building during the meetings. The chart and KPI screen made it so everyone in the company knows where it was in terms of hitting this months budgeted target and staying profitable. Things were visible by everyone in the room, and there was a certain "coolness" factor that encouraged people to participate by adding news items and talking about things that needed improvement.

A Manufacturing Scheduling System

Another project at Apollo America was to make our work order process for scheduling manufacturing paperless. Scheduling manufacturing was handled by putting printed work orders in a pile at the start of each line in order of when they should be completed. The problem with this system was that it was very tedious for people to schedule things because it required going back and forth and looking at all of the sheets of paper, or looking at a long list of orders in a spread sheet which didn't include all of the necessary information.

I was given the task to make it easier to schedule orders and also take the opertunity to gather more data about the performance of the line. I decided to replace all work orders with iPads using a web view. Each of the manufacturing lines would have an iPad at the end of the line which lists all of the orders in the order which the foreman decided on. Each of the orders had to be marked as started when work on it begins, which would start a timer, and stopped when finished. The resulting time is then sent to the server and then saved. Each of the orders also has the ability to be marked as uncompletable or that the order is causing downtime on the line, each of which is also timed and sent to the server.

The line interface
The interface on the iPad for the SL manufacturing line

The foreman would have an iPad which lists all of the lines and the open orders and decides on what to work on today and what not to, and in what order. There is also an interface which shows all of the orders scheduled for today and their status.

This system makes heavy use of Backbone.js and AJAX. The entire line interface shown above is driven by data sent into a Backbone collection during the rendering of the HTML via Jinja2's serialization. Then the collection is rendered by Backbone templates, each of which tie into events to start and end the timers and send the data to the server automatically. The lines also have a periodic event to check the server for new orders and rearranging of existing orders, so the foreman can adjust if there is a down line or a shortage.

The end result of this system was the ability to completely map out what the factory did in a day, how they did it, how long it took them, and where there was any lost time and what caused that to happen.

A Centralized Parts Database

When I started at Apollo, the engineers were storing product component metadata in three places

  1. Our ERP system
  2. Sharepoint *shudders*
  3. An Access database that drove our schematic drawing software

Needless to say, it was hard for engineers to get info on components, especially when drawing schematics. Also, all of the different locations got out of sync with each other because it was too much work to edit all of them. The engineers wanted for a while to have all of the part information consolidated, so my task was to take all of the information to store it in one database, make it easy for anyone who had permissions to see and edit part information, and to make the information available to the schematic drawing software. Consolidation was just a matter of writing Python scripts to download the data from the various sources and dump it in our MySQL database, and making the data available to the schematic drawing software was just a matter of following certain naming conventions with the columns. The interesting part was creating a web interface to that data.

The parts database interface
The web interface for the parts database

Using Flask with the Flask Admin plug-in, I created a interface that allowed for easy filtering and editing if the part information. Users could click on any part to instantly update it's info, provided they had the proper permissions. Also, users could, for example, filter by all LEDs which had a cost greater than or equal to 2ยข. Users could also stack filters, so you could search for all parts which have more than zero quantity on hand and have the word "green" in its description.

This Site

When decided to create a promotional site, I took it as a personal challenge to see how fast and small I could make this page while still having a responsive, modern design. Not including images, this site is roughly 30kb and it loaded on your computer in (again, not counting images). This site uses plain HTML behind an Nginx server, and the only JavaScript on the page is Google Analytics and code to calculate the page load time for the previous sentence. All this is to point out that I use the right tool for the job. The above projects are very dependent on server side code and heavy use of JavaScript, but many developers use these tools as a crutch.

The ability to cut down load times is a very important skill for web developers. Studies have shown that what would seem like trivial differences (in some cases a half second) in page speed can cause 20% of your users to leave your site before it even loads [1] [2].

Open Source Projects and Contributions

Anything that I have given away as free software or any contributions that I have made to free software projects.

Flask Foundation

Flask Foundation is a simple template that I wrote in order to initially teach myself the Flask web framework for Python. I was frustrated that all of the available examples of Flask code were very platform and deployment specific and very little could be learned from the convoluted code. So, I decided to build a simple, solid foundation for flask applications, built on MVC using the most popular Python libraries, that you can easily construct any Flask website/webapp off of. My solution is different from most Flask frameworks as it does not assume anything about your development or production environments. Flask Foundation is platform agnostic in this respect. Check it out here.

The D Programming Language Standard Library

I have contributed many changes, closed a couple of bugs, and made some new additions to the standard library of the D programming language. To see a list of all of the merged pull requests I have on the standard library, click here, to see all of the open pull requests click here.


date-parser is a translation of the very popular date string parsing functionality of the dateutil library to D, and it can be found here. It started out as just a port of the existing functionality, which only resulted in a 2x faster library than the Python version. But, after optimization and translating it to idiomatic D code, my version is 10x faster than the Python version with space still available to optimize.


Mastering Flask

Mastering Flask is a programming book that I wrote for users of the Flask web framework for Python. It is designed to take the reader from simple web pages with Flask to large scale web apps.

Starting from a simple Flask app, the book walks through advanced topics while providing practical examples of the lessons learned. After building a simple Flask app, a proper app structure is demonstrated by transforming the app to use a Model-View-Controller (MVC) architecture. With a scalable structure in hand, the next chapters use Flask extensions to provide extra functionality to the app, including user login and registration, NoSQL querying, a REST API, an admin interface, and more. The, the book covers how to use unit testing to take the guesswork away from making sure the code is performing as it should. The book closes with a discussion of the different platforms that are available to deploy a Flask app on, the pros and cons of each one, and how to deploy on each one.

The Flask Cookbook

Packt Publishing released a book on Flask web framework best practices, The Flask Cookbook, and I was chosen as one of technical reviewers for the book during the writing process.

© Jack Stouffer