Mathew Kleppin

Magnises LLC

Senior Full-Stack Developer

https://magnises.com Dec 2015 - Present

At Magnises I worked on their main event platform, which included mobile apps (iOS and Android) and a MEAN stack web app. Over the period of a year, I rebuilt the entire stack to remove the accumulated technical debt from 4 other developer studios that worked on them.

Magnises.com on a macbook

I joined Magnises as a part-time developer during the winter of 2015. At the time, they were transitioning from an internally based development team to one that was state side. Several developers, from different studios (and even countries), had been working on various pieces of the puzzle with no central direction or coding style. To help future development we needed to standardize our coding style (we were a team of 4 at the time) and improve our communication with issue tracking.

Having several developers with different coding styles is like having a book written by several different authors. Ideas can be started by one author and not followed through by the others. Likewise, a character might appear and be important in one chapter, and never appear again. It becomes very difficult to manage and developer with. Unifying coding style is not something that happens overnight. Every developer needs to be onboard, given time to adapt, and work on the same things as other developers.

When I started digging deeper into the project, I noticed there were no tests for any of our workflows and bugs popped up often. Our continuous integration was prone to breaking; It a self-hosted black box that no one had access to and took anywhere from 30 to 45 minutes to deploy. The build process itself was broken off into 4 separate pieces. So if you wanted to add an external package, there were 4 separate ways you had to learn use, depending on where you wanted it to be added.

One of the first things that I insisted focusing on was building our test coverage. Over the course of the first 4 months, while working on a few feature sets, I managed to write tests for around 60% of our workflows in Node using AVA, and successfully integrated CircleCI as our continuous deployment service. This lowered deployment times to around 5 to 6 minutes, with included testing, and allowed us to start unwinding the twine of our build process.

It was around this time we made the move to github from bitbucket, and I was also hired as a full-time employee of the company. The move to github brought with it great issue tracking. Previously, the team was expected to keep track of their issues and tasks on a trello task board, which was used very infrequently by everyone else.

With our development staff more productive, and being ahead of our development timeline, I had the time to start building a new dashboard, replacing a lot of the hacky old AngularJS code, and standardizing our front-end coding style. My main goal was to develop reusable modules and services using a web component methodology.

When the ball started to get rolling on this, it became clear there were some issues with the overall brand identity of the new dashboard design. It was being done by a contracted designer from Nike, as we had lost our previous in-house designer to GQ. A large chunk of my time in free-lance was spent doing website and UI design, so this is something I wanted to take charge of. It took a little convincing to get management onboard though, but they agreed something needed to be done.

While the overall design worked for me, there were some inconsistencies in the way the components looked, which is where I focused most of my attention. Much like the way coding style effects developers above, having an inconsistent brand image causes problems with the perception of quality of our products. When you change or evolve a brand image, you want to maintain a consistent style across all of your products, so you update everything to match, with a new style guide.

I am not usually nervous on product launches, as everything has been tested thoroughly and I'm excited to get an improved product into our users hands. When the new dashboard was completed and launched, this was not the case. In order to show things off to investors, we wanted to launch it early, so a lot of the system was put into production without much QA testing. The new design that I had worked on also needed to adapt to mobile and tablet, as about 40% of our traffic at the time was mobile. While I covered a lot of the use cases with device emulators, I was still worried about putting that into practice.

To my relief, there were only a couple of small tweaks that needed to be made in a day-1 patch, and a week-1 patch. Because of the rigorous testing and code style I had focused on earlier in my time at magnises, the system proved to be very reliable. The dashboard was a success! With this, we could start adding more automation into our workflows, helping cut a ton of company costs.

Since the launch of the new dashboard, the largest project we've integrated was adding reservations and a payment system to events. Reservation charges had been done manually by staff, and with an expanding user-base, things were getting very costly for us. It was the most challenging thing I had done so far due to the importance that we created a system that had a robust set of options for refunds, and also integrated into several new APIs.

Magnises Events Page

Because of the success of my previous design work for the dashboard, I was allowed to take the lead the design for this. We have a great marketing team at magnises, so my focus was to empower their fantastic imagery and focus on complementing it the best I could. I ended up doing some cool things with styles, pulling colors from our image and applying them to the various button/icon styles. This is done dynamically for each event and the above image shows how it worked out.

TargetProof

Senior Web Developer

My work at TargetProof has allowed me to learn from some of the best in the security industry, and work along side them to design future focused products. I've worked on several different product designs, promotional material, and built an email security auditing system called Mirror. Mirror now serves as the foundation of TargetProof's consulting business, generating solid leads for the sales team.

I started off at TargetProof as a contractor in 2012, during my freelance days. I built a CMS from a set of design template, then transitioned quickly into doing branding work. The company was in need for a solid brand identity to show off to investors, and I had the expertise that allowed me to do various odd-jobs. From product videos built in Adobe After-Effects, to a unifying style guide, most of everything got my designers touch.

The goal of the company was to develop a P2P identity assertion solution, using the already existing Open-PGP standard. Open-PGP is great for its cryptography, but has been slow on the uptake because its key management isn't user-friendly. Our goal was to build an infrastructure to take care of key management in the back-end for users and start developing a web-of-trust, sharing keys via P2P, storing these connections on our cloud server.

TargetProof email auditing tool, Mirror

At this early stage in a start-up, it was important to have a product, but we didn't have anything yet. To get the ball rolling, I decided to start work on TargetProof's Mirror, an email security analysis tool that would take an email, check the DNS configuration, and verify that the identity information provided was correct.

I didn't quite know what I was signing up for. The complexities of email-security, and the lack of availability of community modules to cover our use case meant a lot of our infrastructure had to be created by hand, by someone who had expert level knowledge of DNS structures surrounding email servers.

It took about 8 months to finish the prototype. After lots of research, and re-writing a mail-server, the report was finally finished. The first version had a simplified UI which toned down the technical data and engineering jargon. It required users to send an email to our domain to analyze. It also included some basic risk tracking and other analytics on how well you fared vs other users who had gone through the system.

Building on the technical success that was our first version of Mirror, I worked on removing the email requirement. A lot of the information about a mail-server can be taken from just an email address. We were requiring an actual email message so we could gather the surrounding DNS info from the message header itself. This was our biggest hurdle to get users in the system, having users email our Mirror program.

Several hundred tests and a complete re-write to our API, we now have Mirror v2, which only requires a single domain to fetch information about it. This allows us greater flexibility in creating future monitoring tools for companies. Also, there was a big increase in our on-boarding capabilities.

Acapella Apps

Senior Web Consultant

Oct 2014 - Dec 2015

A lot of my experience with app's comes from the work I did at Acapella. I was brought on offically as a consultant for one of their larger clients, who was developing a traveling "experience" phone app. As the relationship grew, I got exposed to a lot of new technologies, like real-time streaming and augmented reality applications.

The first application I worked on, called Buzztep, was designed to be a social travel experience app. Users would launch the app and it would track them during their travels, create photo collages, and suggest places to eat. My job was to design the data archatecture that would support various complex relations, and come up with a tech stack that could impliment the archatecture as well.

Mathew Kleppin