diff --git a/.github/workflows/pr_build.yml b/.github/workflows/pr_build.yml index eddd6271..5578b33a 100644 --- a/.github/workflows/pr_build.yml +++ b/.github/workflows/pr_build.yml @@ -32,6 +32,7 @@ jobs: env: GOOGLE_ANALYTICS_ID: ${{ secrets.GOOGLE_ANALYTICS_TRACKING_ID }} run: npm run build + test-frontend: name: "Lint and test frontend" runs-on: ubuntu-latest diff --git a/content/posts/2017-06-21--pycasia/index.md b/content/posts/2017-06-21--pycasia/index.md index 7b99c338..7cdcee8a 100644 --- a/content/posts/2017-06-21--pycasia/index.md +++ b/content/posts/2017-06-21--pycasia/index.md @@ -9,7 +9,7 @@ source: https://github.com/lucaskjaero/PyCasia --- An open-source python library to work with the CASIA Chinese handwriting database. Reads custom binary filetypes to prepare for machine learning applications. -## Problem - A dataset with a custom binary format +## Problem: A dataset with a custom binary format The CASIA library uses a custom binary format to pack thousands of images into a single file. This allows for efficient processing, but doesn't work with anything else without extra glue code. This library is the glue code that allows this data to be used with off the shelf machine learning frameworks. ## What I learned diff --git a/content/posts/2017-12-01--FFFF-Performance/index.md b/content/posts/2017-12-01--FFFF-Performance/index.md index 19e5a573..da64a1f0 100644 --- a/content/posts/2017-12-01--FFFF-Performance/index.md +++ b/content/posts/2017-12-01--FFFF-Performance/index.md @@ -9,10 +9,10 @@ source: --- I created a suite of performance testing scripts for Free File Fillable Forms, and used these scripts to prepare the site for the predicted traffic of the 2017 tax season as the team's sole performance engineer. -## Problem - unreadable scripts +## Problem: unreadable scripts Existing performance scripts used thousands of opaque json files inside a database, making it very difficult to understand what performance scripts were doing. Everybody who had written the prior scripts had left the company, and the current scripts needed significant changes to accommodate product changes. -## Solution - rewritten scripts with a focus on readability +## Solution: rewritten scripts with a focus on readability I rewrote the performance scripts using the gatling framework, and generalized each tested API with a function. This way, you could read through the main script file and understand what it was doing, without needing to dig into each request. I also added these scripts as a post-deploy testing job, so that every new software version would get a report on how changes impacted the performance of the webapp. ## What I learned diff --git a/content/posts/2019-03-28--RELENG-Docker/index.md b/content/posts/2019-03-28--RELENG-Docker/index.md index 1e6dab38..c496f26e 100644 --- a/content/posts/2019-03-28--RELENG-Docker/index.md +++ b/content/posts/2019-03-28--RELENG-Docker/index.md @@ -9,10 +9,10 @@ source: --- Created a suite of docker containers allowing new hires to begin local development on day one. Prior to the docker setup, local development was a pain point, with no team-member having all micro-services set up locally, and development frequently occurred in local environments -## Problem - painful local development encouraged people to skip steps +## Problem: painful local development encouraged people to skip steps While working on a micro-service based project, you frequently have to work with the interaction between two services. However, if you are not going to be changing anything on one of the services, it is not worth setting that service up locally. It is tempting to just make assumptions about how the other service will work, or to test in a pre-production environment, but this can cause bugs. -## Solution - pre-prepared docker images of all services +## Solution: pre-prepared docker images of all services Creating a docker container made it easy to get a service running locally for testing, usually within minutes. This removed all excuses for testing in pre-prod, and encouraged local testing. ## What I learned diff --git a/content/posts/2019-06-26--Metrics-Dashboard/index.md b/content/posts/2019-06-26--Metrics-Dashboard/index.md index 4f9daec9..8b2fc839 100644 --- a/content/posts/2019-06-26--Metrics-Dashboard/index.md +++ b/content/posts/2019-06-26--Metrics-Dashboard/index.md @@ -9,10 +9,10 @@ source: --- Led a team of three engineers to create a data collection pipeline and release information dashboard to enable leaders to self-serve deployment metrics. This dashboard replaced manual queries from directors, enabling them to get data instantly. -## Problem - Weekly deployment reports required manual SQL queries +## Problem: Weekly deployment reports required manual SQL queries Every week, my director would ask for deployment reports to give to senior leadership. Those reports required different information each time, so they couldn't be automated. Data was also difficult to collect because our deployment tool was built using micro-services, causing data to be stored in different places. -## Solution - A dashboard for deployment metrics +## Solution: A dashboard for deployment metrics We created a react dashboard that showed the last two years of deployment data, allowing filtering by product, team, whether it was in production, and more. We also created a metrics collection infrastructure to store raw user events, letting us answer questions about the level of automation in the release pipeline. ## How it works - Eventing diff --git a/content/posts/2019-12-22--Lucas-Kjaero-Zhang-Website/index.md b/content/posts/2019-12-22--Lucas-Kjaero-Zhang-Website/index.md index 81c0ccb0..fa0b3cef 100644 --- a/content/posts/2019-12-22--Lucas-Kjaero-Zhang-Website/index.md +++ b/content/posts/2019-12-22--Lucas-Kjaero-Zhang-Website/index.md @@ -9,7 +9,7 @@ source: https://github.com/lucaskjaero/lucas-kjaero-website --- A portfolio website to display projects, resume, and contact information. This website is entirely static content, served from an S3 bucket with no backend servers involved. -## Problem - Static content doesn't need a full backend +## Problem: Static content doesn't need a full backend My existing portfolio website used a full backend server and had content in a database. However, I only updated content every six months. This was an inefficient use of money and servers when a static site was all I needed. ## What I learned