What Have I Actually Done at My Current Job?

Note: This quite out of date since it was last updated in 2019. I have worn many different hats since then. Still, I like keeping this stuff up here.

If I sat down to work on my resume any day but today, I would probably forget that I was the one who managed much of our development team's Omniture integrations at Truth Initiative Innovations.

Why not create a long-lived, long-updated post that lists out these lesser remembered things, and maybe even some of the morer remembered things?

When it's time to sit down in front of the resume etching machine, I will be ready.

• On 10-14-2020, my dev lead/acting supervisor said:

  Thank you for handling the deploy stuff and the details for [client] You very consistently handle this sort of “getting the end of a project wrangled and live” well, and it’s been a huge load off knowing you have it

• I managed the Omniture Integrations at Truth Initiative Innovations. This includes classifying variables, being the person who knows the stuff about how Omniture works on the team (e.g. I was one of the two people who could remind people what evars and sprops were), and I'd take point on troubleshooting wiley Omniture bugs (like - why wasn't some registration data getting associated with a "person" in Jive, yet other stuff apparently was?).
• At one point, I created a webhook-based system to receive and report page view events to external partners who were paying for that data.
• For a long while, our servers were locking up because of blocking connections to our centralized (cloud) logging provider, and when the server came back online (usually after a hard reboot through the console at the datacenter), we would have lost all logs during that period. I fixed this by investigating our rsyslog config and improving it to not drop these messages when the logging provider was unavailable, and also to not block incoming syslog messages during this period, thus avoiding server lockups altogether. We went from "Oh my god we had better restart rsyslog soon or the server will crash" to "Oh look, we got an alert that rsyslog is experiencing connection problems. It will eventually come back online and send our logs to the logging provider." Because of this blocking and a less than great rsyslog configuration, our local syslog server would block applications' socket connections on the /dev/log socket, and since many important processes (such as sshd!) submitted syslog messages at this location, many processes on the server locked up.
• Created an import mechanism for semi-technical business personnel to compose SMS text message conversations. This involves composing a series of messages, recognized regexes, responses, and API integrations as an artifact that can be uploaded to multiple environments and tested before going to production. This was an improvement from the method of filling out HTML forms for each message and saving them in an instance/environment's DB state with no easy way to replicate this in other environments. In short, I created an artifact format for non-developers to use as a better interface for creating text message conversations.
• Used a couple of Kibana cloud solutions daily to debug production issues and alert on them. Also often led the charge to seriously log as much as humanly/computerly possible in our apps to allow future observability. I wanted people to be able to find the exact code line and related data (db rows, etc.) needed to debug an issue, just by looking at the error log.
• Built development, staging, and production, as well as CI, infrastructure on AWS EC2/RDS with Ansible and Jenkins as well as Heroku and Heroku CI. Also built development infra on Docker (with and without Docker Compose) and Vagrant with Ansible.
• Architected a move from managed multi-server, multi-app VPS hosting to AWS, adding load balancing into the mix for the first time for the application. Automated all AWS infrastructure creation/management in Ansible.
• Designed a test interface for message library admins to simulate user experiences so they could gain confidence that their text messaging programs would work as expected for various users up to 90 days in the future.