Software Developer in West Chester, PA, United States

This is a blog site I developed independently using WordPress and hosted on AWS Lightsail. The site acts as a home platform for Absolutely Boxing.

The site uses WP Page Bakery for the layout and incorporates plugins such as Yeost SEO, Google Analytics, Advanced Ads, Popup Anything, and NewsLetter.

Initially, our company was on Great Plains. We moved to Quickbooks in 2011. I helped facilitate that migration.

We created IIF files from our home system and introduced them to Quickbooks. I helped the accounting team troubleshoot errors that came up during the migration and forward flow.

We migrated back to Great Plains in 2013 and wrote an integration through eConnect. As we already had the IIF files created, we wanted to continue to use them I wrote an integration in an internal WinForms App (C#, .NET, SQL, ADO.NET) for reading the IIF files and importing them into Great Plains.

Later we migrated one of the child companies back to Quickbooks. I needed to integrate into Quickbooks using the QB SDK and added branching to the application to understand if the account needed to be in Great Plains or Quickbooks.

For four years, I was the point contact and lead developer (and in most cases, the only developer) for our PCI Compliance Testing.

This included dealing with our compliance vendor, preparing staff for interviews with the vendor, performing a battery of tests against our public-facing websites, and hardening security deficiencies.

I worked with a security vendor who would perform penetration testing on our web applications and evaluate our network for sensitive information. Remediation procedures included code changes, process changes, writing SQL Agent Jobs and BI suites to remove sensitive data after a certain time. I also sanitized databases, and logs of sensitive information.

In order to facilitate automated account imports coming from Student Housing clients, I wrote an integration with Real Page's platform.

Real Page then informed us that we needed to move to a newer RPX platform to support accelerated rent clients. RPX was a REST API that required acknowledging an account had been picked up along with supporting documents for the account.

The accounts came in XML format which then needed to be converted using XSLT to a format that was friendly for our host system, Latitude. XSLT was used to create a variable record format file.

The command center is an internal web application that is used to warehouse data, create articles, and manage workflow statuses for the Absolutely Boxing WordPress Site.

The site directly integrates with WordPress to upload images, tags, categories, events, and full articles.

The application is .NET stack, using Web API and MVC with a knockout front end.

The site also connected with a Python bot that monitors Twitter for the latest gossip from premium sources–generally promoters or boxers themselves. The bot then categorizes the tweet as interesting or uninteresting and creates an alert for the user to review the tweet and write an article for it.

Other features include a sophisticated workflow to manage article status, data aggregation modules, Hangfire for automation, and NLogger for logging.

I built this bot specifically to reference my TopTal profile. The bot itself is a small web application using Node.js as a server, and Bootstrap for the layout. You can ask this blog about me and my experience.

The bot is built using Dialogflow for the back end. I monitor it periodically to retain the model based on responses I am seeing from users who visit it.

It is deployed on a Heroku instance. I manage the subdomain from Plesk on my home server's network and ensure SSL is enabled on the site. If the certificate were to fail, Chrome would not allow access to the microphone.

In the early days of Enterprise Recovery (ER), we had clients looking at a website connected to an ER-Enterprise database, and representatives working out of a system that had been in place before ER. We lacked the tools to import and export transactions and accounts into the ER database, but had those in the previous system.

My role was to create a series of database jobs that automatically imported to the previous system, then synced that data back to a new one. We also had some functionality to take notes in the ER system, and those needed to be brought back into the old system.

The challenges here were ensuring the transactions were in sync, and the accounts were balanced. If the accounts were out of balance, I wrote a script to categorize the type of error, and later wrote a script to automatically correct the ones that didn't need further research.

This project was pure SQL using MS SQL and leveraged the SQL Agent for automation. I was also the designer of the database and responsible for its optimization.

This was one of my first true C# and MVC projects. The site was designed to solve the problem of allowing clients to pay online, automatically.

I was involved in the initial design and development of the site in a junior capacity. Over the course of the project's lifespan, I came to own this site, and was responsible for new features, optimization, security hardening, managing the DNS, and managing the IIS configurations.

We had several challenges with the site. First and foremost, our customers used different payment vendors (First Data, iTransact, ClearComm). This meant that we needed to integrate to them in different ways without the use of Rest API.

We also needed to separate the sites to prevent sensitive data from being exposed on the web application level from our internal network. To accomplish this, we wrote an internal API that restricted the type of data that could be displayed in the web application. We configured a firewall on each level, and ran semi-annual pen testing on the site, and annual security hardening.

I was part of a team working with microservice architecture using AWS and Azure for deployment. My role was to design an API that was capable of syncing payments, invoices, and attachments with third-party systems such as Quickbooks and Great Plains.

The API needed to be extensible to reduce the development time of ongoing integrations that may be required. The API itself was promise-based in Node.js using Express. It was backended with an MSSQL database that connected and used the Sequelize ORM.

I helped Okta write an article for their blog. The article required me to write a simple Node.js application with a PostgreSQL database, then use the Okta Single Sign-on provider to authenticate users.

I worked with Okta to write an article about using their single sign on application in conjunction. Okta was integrated into a small application with Node.js backend and Postgres SQL for the database. The application used PugJs for the view engine.