feat: add current work info

src/blog/a_b_testing_with_cloudflare_workers.rs

@@ -57,7 +57,7 @@ return (
             "Fast forward past a couple of days of 'it works on my machine', we finally discovered the cause. The Istio routing wasn't respecting the cookie we had set to ensure people would get routed to the same pod every time. So, for their first request they might get sent to feature-flag-a.pdq.com and get the index.html, this html would then request `feature-flag-a-some-hash.js` which would sometimes resolve to the correct pod and would sometimes 404 because it was going to the wrong pod. The inherent randomness was due to the routing rules we had to assign people to buckets randomly initially. So 50% would get featureFlagA and 50% would get featureFlagB. Which would be correct if the requests were sticky so that once someone got featureFlagA they ALWAYS got featureFlagA. Our devops team wasn't sure what the error was and wasn't sure when they were going to be able to get back to fix it, so it was back to the drawing board for us."
         }
         p{
-            "We have a pretty slick setup for our dev environment that automatically creates a DNS record, new Kubernetes workspace, and deploys a build to that worSo, nkspace whenever a pull request is opened or new commits are pushed to the pull request. This has worked really well for our internal testing and we had worked out most of the issues already. So we thought that we could leverage similar logic to get our to our desired A/B testing state. Adapting the logic to work for A/B testing was pretty easy. Basically just read an environment variable and run the build/deploy pipeline once for each | separated feature flag."
+            "We have a pretty slick setup for our dev environment that automatically creates a DNS record, new Kubernetes workspace, and deploys a build to that workspace whenever a pull request is opened or new commits are pushed to the pull request. This has worked really well for our internal testing and we had worked out most of the issues already. So we thought that we could leverage similar logic to get our to our desired A/B testing state. Adapting the logic to work for A/B testing was pretty easy. Basically just read an environment variable and run the build/deploy pipeline once for each | separated feature flag."
         }
         p{
             "Now we had multiple versions of our site being built and deployed based on our Google Optimize feature flags. We just needed to figure out how to direct people to the correct pod while obfuscating the fact that they were really accessing something like asdflkbeubfdf-1.ab.pdq.com."

src/cv.json

@@ -1,4 +1,30 @@
 [
+ {
+    "company": "Osmos",
+    "duties": [
+      "Implement features independently across our Typescript and Rust codebases",
+      "Work closely with CS team to solve customer problems, ranging from visual bugs to database improvements",
+      "Reviewing code and technical specifications, providing feedback and solutions"
+    ],
+    "notable_achievements": [
+      "Ran standup and other planning meetings while team lead was on paternity leave",
+      "Implemented a brand new notification service in Rust within a month of starting",
+      "Simplified significant portions of our existing logic to be more understandable, maintainable and testable",
+      "Pushed for higher testing standards and updated our CI to enable better e2e testing",
+      "Added analytics to our product to allow Product and Design to make more informed decisions"
+    ],
+    "technologies": [
+      "Rust",
+      "Typescript",
+      "React",
+      "Node",
+      "gRPC",
+      "Protobuf",
+      "K8s"
+    ],
+    "time": "May 2022 - Present",
+    "title": "Senior Software Engineer"
+  },
   {
     "company": "PDQ.com",
     "duties": [
@@ -23,7 +49,7 @@
       "Firebase",
       "K8s"
     ],
-    "time": "January 2020 - present",
+    "time": "January 2020 - May 2022",
     "title": "Senior Software Engineer"
   },
   {