https://www.atkinsondev.com/ Recent content on Craig Atkinson Hugo -- gohugo.io Copyright © 2020, Craig Atkinson; all rights reserved. Sun, 03 Jan 2021 00:00:00 +0000 https://www.atkinsondev.com/post/ai-test-failure-analysis/ Tue, 11 Mar 2025 00:00:00 +0000 https://www.atkinsondev.com/post/ai-test-failure-analysis/ What are some ways we can use GenAI to make developers' lives easier? A couple of years ago I had the chance to use GenAI to help build out a natural-language-to-query-language translator in a software observability system. This capability allowed users to ask a plain-English question such as "What are my slowest requests?" or "Show me my errors". Then using ChatGPT we generated the corresponding query in our system's query language. https://www.atkinsondev.com/post/separate-plumbing-business-logic/ Thu, 13 Jun 2024 00:00:00 +0000 https://www.atkinsondev.com/post/separate-plumbing-business-logic/ Over the course of your career you will hear about many design patterns. From higher-level design patterns like model-view-controller and model-view-presenter to implementation patterns such as observer, singleton, and adapter pattern. These patterns are valuable to establish a consistent design / architecture and separation of concerns in your application. But many of the services we build today are largely integrations between different systems, with business logic sprinkled on top. How can we design the internals of these systems so they are understandable, maintainable, and testable? https://www.atkinsondev.com/post/faster-gradle-builds/ Sat, 18 May 2024 00:00:00 +0000 https://www.atkinsondev.com/post/faster-gradle-builds/ Spend less time waiting for your build to run and more time developing software by enhancing your Gradle build with caching and parallel execution. The fastest part of your build is one you don't even need to run at all. And then run the necessary parts of your build in parallel. https://www.atkinsondev.com/post/how-many-alerts/ Sun, 24 Mar 2024 00:00:00 +0000 https://www.atkinsondev.com/post/how-many-alerts/ Recently I came across a Reddit post where the author wanted to know if their on-call situation was standard or if it was out of the ordinary. The post describes a tire fire, not a production-ready software system: "Is it normal to get alerted multiple times each and every hour of oncall, and then expected to go in to work?" https://www.atkinsondev.com/post/chatgpt-oncall-analysis/ Sun, 26 Mar 2023 00:00:00 +0000 https://www.atkinsondev.com/post/chatgpt-oncall-analysis/ As you've likely seen, ChatGPT is getting a lot of attention lately. I wanted to experiment with it and see what I could learn, so this past weekend I tried out integrating ChatGPT into one of my apps. What was it like to work with and what could I potentially get from it? This is a recounting of my experiment. A while back I built a frontend app to process and analyze a team's alerts from PagerDuty that I called OnCalm. https://www.atkinsondev.com/post/opportunity-cost-software-development/ Tue, 21 Mar 2023 00:00:00 +0000 https://www.atkinsondev.com/post/opportunity-cost-software-development/ Why can't you just add this new feature or fix that lingering bug? After all, it's the time and effort for that change alone - right? But it's not just the cost of what work you choose to tackle - you're also paying the price for all the other work you didn't implement instead. That's the opportunity cost. Opportunity cost is the recognition that we have limited resources, and by choosing one option we are excluding other options. https://www.atkinsondev.com/post/communication-tips-staff-plus-engineers/ Wed, 04 Jan 2023 00:00:00 +0000 https://www.atkinsondev.com/post/communication-tips-staff-plus-engineers/ As a staff-plus engineer, you likely advanced through your career solving challenging technical problems. And now that you've reached the staff-plus level, it'll just be more of that - won't it? Sorry! While in well-crafted staff-plus roles you will have sufficient focus and time for helping teams solve technical challenges, as a technical leader your scope now includes additional areas where so-called "soft skills" are very important. And your work up until this point may have been more on the technical side, so the importance of soft skills can be one of the bigger adjustments that staff-plus engineers such as yourself need to make to be successful in their role. https://www.atkinsondev.com/post/pull-request-review-keys/ Sat, 10 Dec 2022 00:00:00 +0000 https://www.atkinsondev.com/post/pull-request-review-keys/ Over the past 15 years I've reviewed hundreds upon hundreds of pull requests. From pull requests against projects I built and maintain to PRs submitted as promotion portfolio reviews in projects I've never seen or worked on, and everything in between. Over time I've developed a set of four key items I look for in each pull request review - regardless of the circumstances of the change. I'm synthesizing and sharing these keys with you in hopes they're helpful to you as well. https://www.atkinsondev.com/post/android-maestro-mock-rest-api/ Thu, 17 Nov 2022 00:00:00 +0000 https://www.atkinsondev.com/post/android-maestro-mock-rest-api/ Maestro is a great library for writing high-level UI tests that verify your Android app works from your users' perspective. For a more detailed intro into Maestro, please see my recent Maestro intro post. If you're testing an app that makes REST API calls, you'll need a way to verify those parts of the app work correctly. While full tests that access real versions of the APIs can be valuable, there are tradeoffs to using real APIs in Maestro tests: https://www.atkinsondev.com/post/android-maestro-testing/ Sun, 30 Oct 2022 00:00:00 +0000 https://www.atkinsondev.com/post/android-maestro-testing/ For fun I've recently been building an Android app with Kotlin and Compose. With this app, I can set goals for the week and track my progress towards those goals. My schedule is too varied day-to-day to successfully finish daily goals of say, read X minutes a day. But I found that setting goals per week helped me achieve those goals more easily than trying to find time each and every day to make progress on these goals. https://www.atkinsondev.com/post/android-emulator-tests-github-actions/ Thu, 20 Oct 2022 00:00:00 +0000 https://www.atkinsondev.com/post/android-emulator-tests-github-actions/ Tests for your Android application can come in a couple different flavors: Unit tests Connected Android tests You can execute the regular unit tests under the app/src/test directory without any special setup, but for the connected Android tests under app/src/androidTest you'll need a real device or an Android emulator. The connected Android tests can include testing UI interactions, on-device database queries, and more. If you're using GitHub Actions for your CI, you can run your connected Android tests using an Android Emulator. https://www.atkinsondev.com/post/force-multiplier/ Sun, 24 Apr 2022 00:00:00 +0000 https://www.atkinsondev.com/post/force-multiplier/ As you move along in your software engineering career, one of the biggest ways you can have a larger impact is to be a force multiplier. What does it mean to be a force multiplier, you might ask? Having an outsized impact on others beyond your direct contributions. For example, helping level-up the skills of other members of your team so you can all deliver faster and with higher quality vs you alone just working the next development task. https://www.atkinsondev.com/post/improve-developer-productivity/ Wed, 27 Oct 2021 00:00:00 +0000 https://www.atkinsondev.com/post/improve-developer-productivity/ Software engineering teams are a critical component of many companies, where the effectiveness of these teams can have a significant impact on the company's success. Making investments in areas such as these in improving developer productivity will pay off significantly, giving development teams more time to focus on delivering business capabilities and less time spent triaging production issues, fighting flaky tests, waiting for unnecessary build steps, or hunting down false production alerts. https://www.atkinsondev.com/post/open-source-side-project/ Sat, 18 Sep 2021 00:00:00 +0000 https://www.atkinsondev.com/post/open-source-side-project/ On Twitter you'll see jokes about folks purchasing domain names in the hopes of launching a side project. Then that domain comes up for renewal, taunting those never had the chance to launch that side project. A couple of years ago I did the unthinkable - I built and released an open source side project and then purchased the domain afterwards. My open-source project Projektor is by no means wildly popular, but I wanted to share out some of the lessons I learned while building it in the hopes it helps others who are looking to build and release their own open-source side projects. https://www.atkinsondev.com/post/why-write-comments/ Sat, 21 Aug 2021 00:00:00 +0000 https://www.atkinsondev.com/post/why-write-comments/ We've all seen it, code comments that are so obvious they add nothing but noise to the codebase. Redundant comments restating exactly what operation the code is performing. For example, this function's purpose is obvious from its name - adding a comment as well doesn't add any value: 1// Verifies if the auth token is valid 2fun isAuthTokenValid(tokenFromRequest: String) = 3 authConfig.publishToken == tokenFromRequest Or the comment on this block of code, which again doesn't clarify anything beyond what is already understandable from the code: https://www.atkinsondev.com/post/cypress-testing-library/ Thu, 19 Aug 2021 00:00:00 +0000 https://www.atkinsondev.com/post/cypress-testing-library/ If you're writing unit tests for your React components these days, there's a good chance you're using React Testing Library. It supports user-focused testing with reliable selectors to find elements, such as the data-testid attribute or finding an element by role. Specific and reliable selectors are key to make sure tests are resilient against unrelated changes to the component structure breaking existing unit tests. For example, if we have this component with a data-testid element: https://www.atkinsondev.com/post/code-coverage-helpful/ Mon, 05 Jul 2021 00:00:00 +0000 https://www.atkinsondev.com/post/code-coverage-helpful/ Code coverage - how many code lines and branches are accessed during a test - is easy to measure in many languages and test frameworks. And at first glance, measuring code coverage seems like a no-brainer. After all, who wouldn't want to make sure their code is sufficiently tested? But just because a metric is easy to measure, doesn't necessarily mean it is helpful. Why code coverage can be misleading Code coverage tools will measure which lines (and branches) are accessed during a test, but code coverage measurements don't tell you the value of those tests. https://www.atkinsondev.com/post/opentelemetry-jvm-testing-kotlin/ Tue, 29 Jun 2021 00:00:00 +0000 https://www.atkinsondev.com/post/opentelemetry-jvm-testing-kotlin/ The OpenTelemetry Java instrumentation agent automatically instruments many common frameworks but there are times you may want to customize your application's telemetry by adding your own custom spans, adding attributes to existing spans, etc. In that case, it can be helpful to verify the custom instrumentation through automated testing. I recently added custom telemetry to my Projektor test reporting app and documented the steps here that I used to verify it in case this is helpful for others. https://www.atkinsondev.com/post/opentelemetry-honeycomb-kotlin/ Sun, 06 Jun 2021 00:00:00 +0000 https://www.atkinsondev.com/post/opentelemetry-honeycomb-kotlin/ In this post we'll go through my initial journey to add observability to the Projektor test reporting app using OpenTelemetry and Honeycomb. Projektor already has traditional monitoring with metrics around p95 response times for each REST endpoint, counters for successful and failed operations, etc. But I was intrigued to see what additional production insights I could learn from some more advanced observability tools like Honeycomb. Getting started Projektor is written in a JVM language (Kotlin), so I started with Honeycomb's great guide on getting started with Java. https://www.atkinsondev.com/post/react-testing-library-order/ Tue, 06 Apr 2021 00:00:00 +0000 https://www.atkinsondev.com/post/react-testing-library-order/ Recently I was working on sorting rows in a table in React and I wanted to be able to verify the rows sorted into the correct order. The table shows flaky tests (that is, tests that intermittently fail) and is built with Material Table. Material Table conveniently supports sorting out of the box by clicking on the column name. For this app, I'm using React Testing Library for the component tests. https://www.atkinsondev.com/post/customizing-recharts-graph-cypress-testing/ Sun, 14 Mar 2021 00:00:00 +0000 https://www.atkinsondev.com/post/customizing-recharts-graph-cypress-testing/ After I added the ability to collect and store code coverage stats in the Projektor test reporting tool, I wanted to also add a graph that showed the trend of code coverage over time. Then users could track their repo's code coverage to see if was increasing, decreasing, or staying the same. The Projektor UI is built with React, so I explored graphing library options for React. I found different options available, and found that Recharts fit in the sweet spot of being customizable - for example, for making the graph clickable to go to an individual test run - but also high-level enough to encapsulate most of the visualization code. https://www.atkinsondev.com/post/github-api-kotlin/ Wed, 10 Mar 2021 00:00:00 +0000 https://www.atkinsondev.com/post/github-api-kotlin/ Recently as part of Projektor test report project, I wanted to add the capability to comment directly on pull requests with links to the test report, code coverage stats, etc. That way users could get easier and faster access to the information than searching through the CI output to find the link to the Projektor test report. And if the project has code coverage, Projektor can compare the coverage percentage from the PR to the previous mainline build run, quickly telling reviewers whether the coverage increased, decreased, or stayed the same as part of the code changes. https://www.atkinsondev.com/post/postgres-explain-analyze/ Sun, 07 Mar 2021 00:00:00 +0000 https://www.atkinsondev.com/post/postgres-explain-analyze/ Database queries slower than you'd like? With Postgres' built-in explain/analyze capability you can identify what's making the query slow and fix it. In this example, we'll analyze the performance of query called as part of an API GET endpoint. First, we'll seed our test database with enough data to get meaningful query analysis results. If the database has only a few records, Postgres may execute queries differently than if we have >100k records in production and the analysis results may not match what we'd see in prod. https://www.atkinsondev.com/post/database-jooq-flyway-ktor/ Sun, 28 Feb 2021 00:00:00 +0000 https://www.atkinsondev.com/post/database-jooq-flyway-ktor/ One of my goals when I started a learning project a couple of years ago was to get more hands-on experience with Kotlin co-routines, so I explored app frameworks that natively supported co-routines. I landed on Ktor, an open-source framework from JetBrains (creators of Kotlin) that supports co-routines throughout the framework. I've really enjoyed working with Ktor, and the lightweight flexibility of the framework allowed me to easily integrate libraries like jOOQ and Flyway. https://www.atkinsondev.com/post/github-actions-releasing-different-tags/ Wed, 24 Feb 2021 00:00:00 +0000 https://www.atkinsondev.com/post/github-actions-releasing-different-tags/ For the Projektor open-source test reporting project I wanted to keep all the code in a single mono repo to make it easy to work on and manage. But over time as the project evolved it grew into multiple deployable artifacts, and I wanted to be able to release each of those components independently as needed: Server .jar deployed to GitHub releases Gradle plugin deployed to the Gradle plugin portal Node package deployed to the NPM registry The project is built with GitHub Actions, and after some digging I found that GitHub Actions supports executing different actions based on the format of a tag. https://www.atkinsondev.com/post/strikt-kotlin-assertions/ Sun, 21 Feb 2021 00:00:00 +0000 https://www.atkinsondev.com/post/strikt-kotlin-assertions/ When I started writing Kotlin code a couple of years ago, one of the main things I missed after previously writing tests with Groovy/Spock were the easy yet powerful assertions with Groovy's power assert - not to mention the expressive failure messages when a test failed. Groovy's power assert prints out the .toString() of every element in the assertion, making it easier to diagnose what went wrong from reading the test report. https://www.atkinsondev.com/about/ Sun, 03 Jan 2021 00:00:00 +0000 https://www.atkinsondev.com/about/ I'm Craig Atkinson, a principal engineer who is passionate about making an impact through my work. Whether it's through architecting enterprise platforms, building products for customers, mentoring fellow engineers, or creating tools to improve developer productivity. In my 15+ years in the software industry I've worked with companies at various stages, from startups to Fortune 50 enterprises - in a variety of industries, from medical devices, finance, insurance, developer productivity, to retail. https://www.atkinsondev.com/archives/ Tue, 28 May 2019 00:00:00 +0000 https://www.atkinsondev.com/archives/