derek.broox.com is my general home page, online scrapbook, and development playground. Its primary purpose is to catalog my life and allow me to play with various APIs and web development technologies. It serves up thousands of photos, check-ins, microblogs, blogs, maps, videos, and various other data from my life. Since 2001, it has been a constantly evolving web application.

Amidst the start of the COVID-19 pandemic, the Chicago Venmo team was tasked with launching one of our most ambitious products. We worked closely with PayPal Credit, Synchrony Bank, and several internal Venmo teams to launch a branded Venmo Credit Card product in just 10 months time. I served as a tech lead and cross-company liaison to help architect and lead the development of the Credit Card servicing portion of the product. This included the data syncing, data structures, and API design to power the interfaces that a user sees when viewing or managing any information about their credit card in the Venmo Application. Later, I worked with a small team to add Cryptocurrency Reward functionality and also led the effort to get the Credit Card service's codebase upgraded to a more modern version of Python.

Venmo Payouts is a product that I got to build as a proof of concept and then turn into a full-fledged product alongside a small team of developers. The initial proof of concept was a shotgun hack to power a couple marketing campaigns that would allow merchants like Chipotle to send small payments to users in an effort to get them to buy burritos. After the success of the pilot campaigns, I acted as a tech lead and liaison between the Venmo team and PayPal MassPay teams to architect and build out a highly scalable merchant-to-consumer payout platform. I designed the APIs, data stores, and contracts between PayPal and Venmo.

The Modest Control Panel was a multi-tenant Content Management System that allowed merchants to manage their Modest powered storefronts. Features included the management of store themes, payment gateways, shipping methods, orders, third party e-commerce product syncing, and even generating standalone iOS applications. The back-end of this app was built in Python using the Flask framework. The front-end was initially built with plain Javascript and jQuery, but was eventually migrated to React. As the Modest client application tech lead, I oversaw and greatly contributed to the overall product architecture and implementation of this web application.

Voter Registration SaaS was a thin, skinnable, multi-lingual, voter registration web application built on top of the DNC's Voter Registration API. This app lived in several places - most notably at the hilariously named gottaregister.com, which was mentioned by President Obama in several speeches, on television, within social media and even on reddit. In most states, this application basically acted as a fancy PDF filler that the user could print and mail in. However, it also allowed us to capture their information so that we could follow up and target that potential voter in the future. I inherited this application early-on and was in charge of making sure it was both stable and scalable while overseeing implementation of the campaign's evolving feature requests. It was one of the most interesting applications to scale because it rarely received organic traffic. It would get absolutely slammed when the president or some celebrity mentioned or linked to the application in speeches, on air, or in social media. This was addressed by extensive caching, limiting dynamic content on landing pages, and queueing API requests in the event of API downtime or latency. The queueing backup that I implemented (using Amazon's SQS) saved us thousands of voter registrations alone. We also made this application embeddable and eventually open sourced the core of it.

Call Tool is a phone canvassing web application used by both Obama for America and the DNC. In its simplest form, it provided volunteers with a potential voter to call and a relevant script to read. The volunteer could then record the answers from the potential voter, which were used to learn more about how the campaign should be operating or targeting individuals. Underneath its shell, Call Tool had a fairly complex architecture that proxied all of its data through our Narwhal API and interfaced with a Voter Checkout Service API and synced with 2 of the campaign's vendors. I architected and built the Call Tool web application and its communication with the Narwhal API from the ground up. I also extended several parts of the Voter Checkout Service to make it more performant, tighten protection against fraudulent callers, and better integrate with our vendors. As I took on other tasks on the campaign, I worked with other engineers and oversaw all development on the application.

Narwhal was the famous technology infrastructure behind Barack Obama's 2012 Re-election campaign. It was a Python-based interface and integration layer that allowed us to unify the disconnected pieces of what we knew about voters, volunteers, event-goers, voting locations, etc. I was one of the top 5 contributors to the Narwhal project. The integration side was a small web layer that handled syncing data with our vendors in real-time. Incoming data was saved to a local database and then became queued via SQS for translation and loading (by our integration workers) into the Narwhal interface layer. Here, I extended existing integrations and built some parts to sync voter applicant and precinct data. The interface side allowed us to use this unified data to quickly build dozens of client applications for various tasks across the campaign. I spent most of my time in Narwhal building and extending models and endpoints to support client application needs. The pieces I worked on helped support pollster surveys, phone canvassing, volunteer organizing, image processing, voting location lookup, incident tracking, etc. I also built a thin Ruby Gem that allowed our ruby based API consumer applications to quickly and easily interface with the Narwhal API.

Debate Watch was a web application loosely based on Planned Parenthood's "Pledge a Protestor" program. The basic idea is that you make your opposition pay for negative actions by allowing your supporters to pledge money each time the opposition attempts slander. With Debate Watch, we took some of the Republican candidates' favorite demeaning terms and promoted them on our site along with some fact checking. Obama supporters could then pledge to donate a certain amount of money each time a given word was said during the debate, and of course put a max cap on their donation in case something got out of control. We had a team of word trackers stuffed in a room listening to the debate and tallying the terms in real-time. On the website's front-end the words would then re-arrange and scale in real-time as our pledgers watched. I built the entire back-end of the application along with the word tracker and a small JSON API for consumption by our front-end team. This application was built primarily as an experiment to test some of our scaling and payment infrastructure but managed to be quite fun and also earned us tens of thousands of dollars early on.

Des Moines Alive is a personal project that my friend Nick Leeper and I built to help Des Moines Area folks find awesome local bars and restaurants. In addition to general merchant info, we provided users with aggregated data such as reviews, foursquare tips, merchant tweets, etc. We designed Des Moines Alive to be very lite and easy to navigate. The goal was to provide our visitors with the information they wanted as quickly as possible.

In short, Dipity was an interactive digital timeline web application with a hint of social networking. We built an incredible web-based tool that allowed users to create, share, embed and collaborate on interactive timelines that integrated video, audio, images, text, social media, geolocation and of course, accurate timestamps. Timeline viewers could pan around and zoom into these timelines for a very nice, visually engaging experience. Being that it was all built in vanilla javascript, it even worked, and was incredibly responsive, on mobile devices, ipads, etc.

TowRate was a startup that offered a custom service to towing companies. The site allowed subscribed companies to manage their assets, map routes, and calculate profit margins for every tow. It was built in a way that allowed the towing companies to quickly run these calculations while on the phone, so they could figure out the most profitable way to charge for each tow. On this project, I was in charge of pretty much everything except for the initial design. My job involved data modeling, loads of calculations, back-end development, front-end development, form design, and deployment. TowRate was a very javascript heavy application, using plenty of asynchronous calls for things like sorting, calculating rates on the fly, and grabbing map data from the Google Maps API. The Maps API was used to help determine mileage and time for each tow. From there, the app used extensive math and formulas to help find the best price for each call. Companies were able subscribe to TowRate on a monthly or yearly basis. I integrated PayPal's Web Payments Pro to handle these subscriptions; let users join, autorenew, enter discount codes, cancel accounts, etc. Subscribed companies could also manage their trucks (as well as truck expenses), users, tow rates, tax areas, routes, etc. It provided an all around fleet management solution to any towing company.

SiteMan is a Content Management System that we built at Red 5 Interactive. It was originally built so that mall property owners could manage each of their mall property's websites. However, once we realized how powerful our system was, we decided to generalize the app so that we could deploy it for all of our clients. We rebuilt SiteMan to allow our clients to easily manage a single website or a group of websites. This way, a parent company could edit any of their child company websites, while employees of the child companies would only be able to see and manage their respective site. The front-ends of the sites managed by SiteMan were also completely extracted from SiteMan itself, which was great for 2 reasons. First of all, it allowed us to more easily keep all of our clients' systems up-to-date in that we were just updating SiteMan and not touching their presentation layer. Secondly, it also allowed us to launch new campaigns and designs for clients very quickly without touching the content management system. When we deployed SiteMan for a client it came with a core group of tools like user management, web page editing, file management, audit logs, etc. From there, custom tools could be added as plugins. These tools included functionality like, announcements, events, careers, photo galleries, stores, social networking, etc. We also built SiteMan in a way that allowed users to customize their tool layout. Any user could pick which tools they used the most and arrange them in a way to get a quick snapshot of the exact data that they were interested in. Tools could be added, removed, or sorted at any time - and everything remained just as they left it on their next visit. This application was very Javascript heavy, making extensive use AJAX, dialog windows, and WYSIWYG editing. As such, we had minimal page loads which provided a very streamlined experience for our clients. I am very proud and excited to have worked with such a great team on this app. It was so versatile and simple to keep pushing forward.

The Audit Trail is an internal application that I built for Red 5 interactive. When we built sites for clients, it was often helpful to track all administrative actions that took place in their content management systems. This allowed us to easily troubleshoot content issues - accidentally deleted data, bad actors, security breaches, etc. We were duplicating much of this functionality for several clients, so I whipped up an Audit Trail app. I built it so that it could be deployed in 2 separate ways. The first, and most commonly used way was for our client applications to call a centrally hosted Audit Trail as a service. With most of our clients hitting the same service, we could keep a close eye on what all of our clients were doing. The second way was to install the Audit Trail as a separate app for any given client. We generally only did this if we anticipated a large amount of logs, or if we had a client that managed several sites. The app and service was incredibly useful. Our clients really enjoyed being able to easily see what was being updated and who did the updating.