flower.codes

Eloquent Interactions Redux

2024-02-20T06:24:00+00:00

Eight years ago, I published an open source implementation of the command pattern for Laravel called Eloquent Interactions.

While my library found some use in my professional life, it has largely sat unused for the past six or so years... at least by me; but last week, that illusion was shattered when I received an email from a developer in Australia whose company was using the library pretty heavily, but my relative abandonment made it impossible for them to upgrade their system to the latest version of Laravel.

To be clear, this email was kindly and respectfully written, and the developer was asking if I had any recommendations for a replacement library he could use to unblock the version upgrade.

I told him I would do him one better and catch Eloquent Interactions up to support the latest version of Laravel. Realistically, it would be as straightforward as updating the dependencies, but because I haven't actually used Eloquent Interactions in years, I wasn't entirely sure if that would be enough (spoiler alert: it was).

Turns out, I wrote unit tests for my little library.

If you are a developer, and you aren't writing unit tests, you are either wasting time now or you are setting yourself up to waste time later.

In order to catch Eloquent Interactions up to support the latest versions of both Laravel and PHP, I decided to do a few things:

I migrated the continuous integration workflow to GitHub Actions from Travis-CI.
I updated support for PHP 7.2.5 through 8.
I updated support for Laravel to versions 7 through 10.
I built out a test matrix that runs the unit tests for every combination of PHP and Laravel versions.

Migrating from Travis-CI to GitHub Actions

This was a surprisingly simple move that really took the form of a simple config change. Here is the original Travis-CI config file (.travis.yml):

language: php

php:
  - '5.6'
  - '7.0'
  - '7.1'
  - '7.2'

sudo: false

before_install:
  - travis_retry composer self-update

install:
  - travis_retry composer install --no-interaction --prefer-dist

script: vendor/bin/phpunit

Essentially, what it does is installs all of the library's dependencies using Composer, and then runs the unit tests (via PHPUnit) for every version of PHP defined in the php array up above (in this case, versions 5.6 through 7.2). As you can see, PHPUnit and Composer do most of the heavy lifting here. No complex setups required.

But, like I said, I've been done with Travis-CI for quite a while, and the more external accounts I have to maintain to keep this library running, the more headache I'm inviting into my life. So the first thing I did was convert the Travis-CI config to a GitHub Actions config (placed in .github/workflows/main.yml):

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        php-versions: ['5.6', '7.0', '7.1', '7.2']

    steps:
    - uses: actions/checkout@v2

    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: $
        coverage: none

    - name: Validate composer.json and composer.lock
      run: composer validate

    - name: Install dependencies
      run: composer install --prefer-dist --no-progress --no-suggest

    - name: Run tests
      run: ./vendor/bin/phpunit

While this script is just a tiny bit longer, it essentially does the same thing. The only exception is that you have to explicitly checkout the repository code and setup the PHP support. Otherwise it will run the same unit tests on every branch push and pull request for PHP versions 5.6 through 7.2.

Upgrading PHP Version Support

PHP 5.6 has been in end-of-life for five years now. Nobody should be using it. Hell, all versions of PHP 7, and even PHP 8.0 are EOL as well. While I could have excluded all end-of-lifed versions of PHP, I decided to support and test the minimum versions of PHP supported by Laravel 7 (which I decided was to be the most backwards-compatible version Eloquent Interactions would support).

Doing a little research, this landed me on PHP 7.2.5. So the next thing I did was update my test matrix to use PHP versions 7.2.5 through 8.3 (the current version of PHP):

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        php-versions: ['7.2.5', '7.3', '7.4', '8.0', '8.1', '8.2', '8.3']

    steps:
    - uses: actions/checkout@v2

    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: $
        coverage: none

    - name: Validate composer.json and composer.lock
      run: composer validate

    - name: Install dependencies
      run: composer install --prefer-dist --no-progress --no-suggest

    - name: Run tests
      run: ./vendor/bin/phpunit

We're not quite done yet, though. We also have to update the project's composer.json file to indicate that those versions of PHP are supported:

{
    "name": "zachflower/eloquent-interactions",
    "description": "An implementation of the interactor pattern for Laravel.",
    "keywords": ["interactor", "laravel", "library", "eloquent"],
    "license": "MIT",
    "authors": [
        {
            "name": "Zachary Flower",
            "email": "zach@zacharyflower.com"
        }
    ],
    "require": {
        "php": "^7.2.5|^8.0",
        "illuminate/validation": "~5.3|~5.4|~5.5|~5.6",
        "illuminate/support": "~5.3|~5.4|~5.5|~5.6",
        "illuminate/console": "~5.3|~5.4|~5.5|~5.6"
    },
    "require-dev": {
        "mockery/mockery": "~1.0",
        "phpunit/phpunit": "~5.0|~6.0|~7.0",
        "orchestra/testbench": "~3.0"
    },
    "autoload": {
        "psr-4": {
            "ZachFlower\\EloquentInteractions\\": "src/EloquentInteractions"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "ZachFlower\\EloquentInteractions\\Tests\\": "tests/"
        }
    },
    "extra": {
        "laravel": {
            "providers": [
                "ZachFlower\\EloquentInteractions\\EloquentInteractionsServiceProvider"
            ]
        }
    }
}

This is pretty straightforward. What we needed to do to indicate support for the new PHP versions is update the php directive in the require object to ^7.2.5|^8.0. In other words, we told Composer that the minimum versions of PHP that are supported are everything above just before to the version with the next breaking change (which is what the ^ symbol indicates).

Upgrading Laravel Version Support

Alright, well, we're halfway there. I didn't feel like testing whether or not Laravel 5 properly ran on PHP 8.4, so I decided to go ahead and upgrade both Laravel and its dependencies. Like I said above, I wanted to support as far back as Laravel 7, so I updated the illuminate/* dependencies (which are libraries provided by Laravel, and the only ones required for Eloquent Interactions to work):

{
    "name": "zachflower/eloquent-interactions",
    "description": "An implementation of the interactor pattern for Laravel.",
    "keywords": [
        "interactor",
        "laravel",
        "library",
        "eloquent"
    ],
    "license": "MIT",
    "authors": [
        {
            "name": "Zachary Flower",
            "email": "zach@zacharyflower.com"
        }
    ],
    "require": {
        "php": "^7.2.5|^8.0",
        "illuminate/validation": "^7.0|^8.0|^9.0|^10.0",
        "illuminate/support": "^7.0|^8.0|^9.0|^10.0",
        "illuminate/console": "^7.0|^8.0|^9.0|^10.0"
    },
    "require-dev": {
        "mockery/mockery": "^1.0",
        "phpunit/phpunit": "^8.0|^9.0",
        "orchestra/testbench": "^5.0|^6.0|^7.0|^8.0",
        "dms/phpunit-arraysubset-asserts": "^0.5.0"
    },
    "autoload": {
        "psr-4": {
            "ZachFlower\\EloquentInteractions\\": "src/EloquentInteractions"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "ZachFlower\\EloquentInteractions\\Tests\\": "tests/"
        }
    },
    "extra": {
        "laravel": {
            "providers": [
                "ZachFlower\\EloquentInteractions\\EloquentInteractionsServiceProvider"
            ]
        }
    }
}

Now we're cooking with gas!

As you can see, I indicated support for all major versions of Laravel from 7 through 10. I also (not directly indicated here) updated the development dependencies (namely phpunit/phpunit and orchestra/testbench) to be compatible with the indicated Laravel versions.

As it stands, what this file now does is indicate which versions of which dependencies it can run on. If someone running Laravel 7 on PHP 7.3 installs Eloquent Interactions, I am signing off that it is supported.

No pressure, right?

Putting It All Together

Okay, so we have an updated Composer file, and a GitHub Actions runner. Now what?

Remember our PHP version matrix? Well, we're going to have to make that a bit more complicated. Because beyond just the PHP version, we need to also test the different Laravel versions supported by each version of PHP:

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        include:
          - php-version: 7.2.5
            laravel-version: '7.*'
          - php-version: 7.3
            laravel-version: '7.*'
          - php-version: 7.3
            laravel-version: '8.*'
          - php-version: 7.4
            laravel-version: '7.*'
          - php-version: 7.4
            laravel-version: '8.*'
          - php-version: 8.0
            laravel-version: '8.*'
          - php-version: 8.0
            laravel-version: '9.*'
          - php-version: 8.1
            laravel-version: '8.*'
          - php-version: 8.1
            laravel-version: '9.*'
          - php-version: 8.1
            laravel-version: '10.*'
          - php-version: 8.2
            laravel-version: '8.*'
          - php-version: 8.2
            laravel-version: '9.*'
          - php-version: 8.2
            laravel-version: '10.*'
          - php-version: 8.3
            laravel-version: '8.*'
          - php-version: 8.3
            laravel-version: '9.*'
          - php-version: 8.3
            laravel-version: '10.*'

    steps:
    - uses: actions/checkout@v2

    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: $
        coverage: none

    - name: Validate composer.json and composer.lock
      run: composer validate

    - name: Pin Laravel version
      run: composer require "illuminate/validation:$" --no-update

    - name: Install other dependencies
      run: composer install --prefer-dist --no-progress --no-suggest

    - name: Run tests
      run: ./vendor/bin/phpunit

Two things should stand out here:

A number of PHP and Laravel version pairs have been created, allowing us to explicitly test different versions alongside one another.
A new CI step, called Pin Laravel version explicitly installs a specific version of Laravel in order to install the other dependencies properly.

So, everything looks good (albeit a bit complex). Let's test it out:

There was 1 failure:

1) ZachFlower\EloquentInteractions\Tests\InteractionTest::testInvalidInput
Failed asserting that an array has the subset Array &0 (
    'meters' => Array &1 (
        0 => 'The meters field must be a number.'
    )
).
--- Expected
+++ Actual
@@ @@
 array (
   'meters' =>
   array (
-    0 => 'The meters field must be a number.',
+    0 => 'The meters must be a number.',
   ),
 )

Shit.

Looks like Laravel changed the validation messages at some point (which turned out to be for Laravel 10). Thankfully this is just in the tests (no actual library code is broken), so in order to get things working, all we need to do is update our tests to detect which Laravel version is being used and assert accordingly.

Here is an example of that change:

if (version_compare($this->app->version(), '10.0.0', '>=')) {
  $this->assertArraySubset(['meters' => ['The meters field must be a number.']], $outcome->errors->toArray());
} else {
  $this->assertArraySubset(['meters' => ['The meters must be a number.']], $outcome->errors->toArray());
}

Laravel (or, more specifically, the Laravel Orchestra test bench) very helpfully provides us with a way to check the underlying version, so all we have to do is check it and update our assertions accordingly.

And that's it! After that final tweak, everything built properly and all of the tests successfully ran, so I tagged the new version (officially v1.0.0 because this is a major breaking change) and deployed it to Packagist for my new pen pal's usage.

By all accounts, it's working swimmingly out in the wild.

This is post 032 of #100DaysToOffload

Pulse Check — February 19, 2024

2024-02-19T13:00:00+00:00

It's been a few weeks since I published my last Sunday Reboot. In fact, I've published just about nothing in February altogether.

... it's been a long month so far. Not a bad month... just a long one.

While I won't bore you with all of the details—or spoil some upcoming stories I'll be writing about—the last few weeks have had me doing a bunch of stuff I didn't expect (and a few things I did):

I gave some engineering leadership advice and guidance to an old friend's startup, making me consider taking the leap into leadership coaching.
I gave a guest lecture to a high school computer science class about password security and (more importantly) insecurity, making me want to do more teaching.
My wife and I took a short staycation at the oldest and (probably not) haunted hotel in Colorado, The Brown Palace, making me want to spend a few months in a historic location to do nothing but write.

In addition to the existential shit, I also:

Met with a real estate agent to start the process of listing our home for sale in the Spring.
Turned 0x25 years old.
And, finally, started the process of petitioning to join a local Masonic Lodge.

Like I said... it's been a month.

Alongside all of that, I missed a few Sunday Reboots, and decided that the weekly format isn't doing me any favors. I love routine, but the chaos of family life makes personal routines difficult to maintain, so I have made the decision to end my Sunday Reboots, and instead replace them with something that feels more... flexible: the Pulse Check.

The intent of the Pulse Check will be much the same of the Sunday Reboot, but with less of a focus on a specific day of the week or consistent cycle, and more of a focus on the things I actually got out of the Sunday Reboots, which is a personal reflection on the things I'm thinking about, engaging with, and consuming.

I may post weekly, but I also may post monthly. What I'm focusing on now is the content and not the schedule.

Same great flavor, exciting new package.

Pondering...

"Don’t hope for better. Just be better." — Mark Manson

I've been doing a lot of "hoping" lately, so this quote is a particularly valuable reminder that change doesn't come from wishes and dreams, it comes from action. If I want to change my circumstances, or the trajectory of my life, I need to actually do something about it, instead of just thinking and talking about it.

That said, knowing what to do is sometimes just as challenging as actually doing the thing. There are no easy answers in life, which is especially frustrating to my engineering brain that really wants things to fit into nice little boxes.

Sorry, brain. Life doesn't work that way. You're gonna have to go make some mistakes and learn a few things the hard way, just like the rest of us.

Enjoying...

Birthdays are weird.

For the sole achievement of surviving one more year, we reward people with cards, cake, and presents.

While I've gotten fewer presents as I get older (believe me, I don't need more things), I did get two gifts this year that I am pretty excited about. The first is an espresso machine from my wife—which is really a gift for the both of us—however the second is something the entire family went in on: a reMarkable 2 writing tablet.

Holy shit this thing is cool.

A while back, I wrote a post about embracing single-purpose technology, and while I've strayed a bit in the last year, I still have a deep appreciation for devices that do one thing and do it well; and the reMarkable is no exception.

A wafer-thin E Ink digital tablet, the reMarkable 2 is for writing and writing only. Sure, while it does also support eBooks and PDFs, the thing I am most excited about is the ability to thin out the things that I own (including the way-too-many half-used notebooks cluttering up my drawers and bookshelves) by providing a simple and distraction-free place to keep handwritten notes.

While I know digital handwritten notes are generally against the "plaintext only" ethos of sustainable digital formats, I have come to a personal understanding that any time I write something by hand, I almost never refer back to it.

The point of handwriting, for me, isn't for memory; it's for thinking.

Why waste paper for something so ephemeral?

I should caveat that it's only been about a week with this thing, and while I love it so far, short-term excitement shouldn't be construed as a purchase endorsement just yet; give me a few months and I will report back on how we are getting on.

Habituating...

I've never been great at maintaining habits.

To be honest, the one habit I've been able to keep more consistently than anything over the last few years has been reading; but that's about it.

Intermittent fasting has been... intermittent, writing tends to come in waves, meditation is mediocre, and don't even get me started on going to the gym.

That said, I have made a few discoveries over the years about how I can better trick my brain into maintaining habits for longer than I used to (meaning instead of dropping a new habit within a week, it might take a month or two to lapse).

The most important thing, for me, has been tracking. The reason my reading habit has stuck so well is because I made it easy, and I tracked my progress; and I didn't just have some app track my progress on my behalf, I actually took the time to log and track my reading by hand.

The "by hand" part has turned out to be the key.

Automatically tracking the number of days meditated in the Calm or Balance app isn't habit-building; but making a notch in my pocket notebook every day I meditated has been a lot more effective.

I have to actively track the habit in order to keep the momentum going.

Unfortunately, my pocket notebook tracking system has added to the deluge of things I have had to keep on my person at all times, which at this point has me carrying way too many things. Right approach, wrong system.

So I've gone back to using a gamified todo app on my phone (one I have used in the past), called Habitica, with the notable change that I have actually started using the habit-building feature instead of the todo list features.

So far it's been going really well, however if you are using (or interested in using) Habitica and don't yet have a party, please reach out! While soloing is fun, it's designed to be a multiplayer experience.

Tinkering...

While I don't intend to read any real eBooks on my new reMarkable tablet, I did discover that it is the perfect device for reading digital magazines and programming books (something a tablet and traditional Kindle both haven't met the mark for me before).

So, aside from the books I am currently reading, I've loaded the thing up with a bunch of issues of Make and MagPi magazines, some Arduino and Raspberry Pi project books, and a handful of other electronics and programming books. The form factor is just perfect enough for this type of content, and has been inspiring to flip through (as I've been wanting to improve my aptitude for hardware-based projects).

The first thing I am looking at tinkering around with is the classic magic mirror. I think I have an old monitor in my basement to sacrifice to the cause, and definitely have a microcomputer laying around somewhere too—and even if I don't have either of those things, I have a few old laptops I could cannibalize to achieve the same effect.

Hell, I'm sure my first generation iPad is up to the task if I get really desperate, though it's hardly within the spirit of the project.

And, I know, It's not the most innovative of projects, but I've always wanted to make one, and figure it's about time to actually get hands-on.

This is post 031 of #100DaysToOffload

Repositories Are at the Center of Development and Production

2024-02-02T12:00:00+00:00

As mentioned in last week's Sunday Reboot, I've recovered a few of my old posts from the Wayback Machine—all from my time at the now shut-down Fixate.io (via their blog, Sweetcode). These are all freelance topics, so the style of writing is a bit different than normal (for me, at least), and the topics are a little wider-ranging than I would normally write about here. I can't quite remember who this piece was originally intended for. I believe it might have been Wercker in 2016 (now owned by Oracle), but I'm not 100% sure.

Have you ever tried to build a new development project without the support of a version control system? It sucks.

We’ve all done it, though. It’s where we start as developers. The software development learning curve is steep enough without having to tack on a Git or Mercurial tutorial as well, so we tend to get a crash course in FTP and learn about version control a little later.

This project management wild west should be a temporary state, however. A professional project should never be passed around via USB drives and FTP transfers. Without a version control system, there is no developer accountability and an obvious smell to the project that alludes to bigger architectural and design issues.

But once you start utilizing a version control system to safely manage your project, what then? Sure, it helps keep developers accountable, and ensures quality backups, but what about deployments?

Release management is where we start to find differing opinions. I’ve worked on projects that have had wildly different deployment workflows. From pulling down repository changes directly on production servers to copying release-ready code to production servers, I have seen it all.

My personal opinion is that if you are managing your own production servers, it is best to leave them ignorant of a version control system. While it is fairly common to simply do a git pull on the production server, this approach is insecure and unsustainable as your development team grows.

The safest and most reliable deployment method I’ve had experience with is atomic deployments. Atomicity is a concept that describes a transaction that either completes successfully, or doesn’t happen at all. This is ideal for deployments because if your deployment workflow fails at any point along the way, the production environment is unaffected. Unit tests, uploading and building code, and cleaning up artifacts should all happen in a safe environment that is only released to the end user if it all completes successfully.

While there are a lot of tools that can be used to accomplish atomic deployments (Heroku, DeployBot, Wercker, etc), the central piece involved with each one of them is that they are all backed by a version control system. This is important for a few reasons, the primary reason being that there is always a record of the state the code was in for each and every release.

The more documentation, processes, and planning you have around your deployment workflow, the safer it will be. A version control system gives you the power to quickly and easily roll your production services back to various states of being with little more than a couple keystrokes or mouse clicks. This centralized system also normalizes the process for every single developer on a project, which means that what I deploy is no different than what you deploy.

Another benefit of version control systems is that integrating with multiple third-party services is as simple as sharing your private repository. A centralized repository can be shared with distinct services that handle everything from unit test coverage analysis to release management, automatically and with little overhead.

Unfortunately, there is one major drawback of version control systems, and that’s the management of private data. While it is technically possible to add passwords, API keys, and encryption keys to a repository, it is a really bad idea, even if it is privately hosted. The reason for this is that the likelihood of a breach increases for every developer on the project, and every third-party service that consumes your repository.

All it takes is for one of your developer’s accounts to get hacked in order to compromise the entire organization. This isn’t a theoretical issue, either; it has happened to many companies before. While you can enforce two-factor authentication within your organization, not every service offers it, and not everyone bothers to set it up.

While keeping secure information out of your repository can be incredibly inconvenient, there are a lot of services that provide options that mitigate the pain. Heroku is a great example of this. Environment variables can be managed directly from within the Heroku dashboard; for non-Heroku hosted applications, environment variables can still be managed at the operating system level, or even the application level through the use of one of the many dotenv packages available.

When utilized properly, or even improperly, utilizing a private repository on a version control system is one of the most useful things you can do for a project. There’s nothing like the feeling you get from being able to understand what is happening with your project, when it is happening, and why.

Working with Serverless Log Data

2024-01-30T12:00:00+00:00

As mentioned in last week's Sunday Reboot, I've recovered a few of my old posts from the Wayback Machine—all from my time at the now shut-down Fixate.io (via their blog, Sweetcode). These are all freelance topics, so the style of writing is a bit different than normal (for me, at least), and the topics are a little wider-ranging than I would normally write about here. This particular piece was written and then subsequently cancelled for Twistlock in about 2018 (now owned by Palo Alto Networks).

When it comes to software development, log storage has historically been what you might call a “known known.” Log data is typically written to standard output, to standard error, or directly to a file using whatever mechanism the application’s operating system or programming language chooses to use. While different technologies can follow slightly different standards, “finding” logs generally requires you to look in only a few places.

But, as new technologies hit the scene that allow us to develop and scale applications in new and exciting ways, the patterns that we’ve taken for granted in the past have started to change. Program execution, data management, log storage — All of these things can feel unintuitively designed as a result of the new paradigms established by the technology running them.

One such change developers are just now learning to deal with is finding, accessing, and analyzing the log data coming out of serverless platforms. Most commonly implemented as “Functions as a Service,” these serverless platforms execute encapsulated business logic in fully managed stateless, event-based virtualized environments. Because these environments are ephemeral (only alive for as long as the requests take), traditional methods of accessing log data aren’t very practical.

So, how do we extract and analyze log data generated from within a serverless environment?

For the most part, the answer to this question is dependent entirely on the serverless provider. While diving into the logging methods for every serverless vendor isn’t all that practical, let’s take a look at how the three largest cloud providers handle serverless data.

AWS Lambda

By default, all native logs within a Lambda function are stored in the function execution result within Lambda. Additionally, if you would like to review log information immediately after executing a function, invoking the Lambda function with the LogType parameter will retrieve the last 4KB of log data generated by the function. This information is returned in the x-amz-log-results header in the HTTP response.

While these methods are great ways to test and debug issues associated with individual function calls, they do not do much by way of analysis or alerting. Thankfully, the log data that is stored in the Lambda function result is also stored in CloudWatch, Amazon’s log aggregation service. To access the CloudWatch logs for a given function, you will need to know the log group and log stream names, which can be retrieved by adding them to the function call logs and retrieving them in the x-amz-log-results response as mentioned above. As an example, this context can be retrieved and logged in Node.js like so:

console.log(‘logGroupName =’, context.log_group_name);
console.log(‘logStreamName =’, context.log_stream_name);

Azure Functions

Similar to AWS Lambda, logs written within Azure Functions are stored within the function execution results in the Azure Portal. One thing worth pointing out is that Azure Functions offers custom logging mechanisms, rather than utilizing the built-in methods offered by each language. For example, the Node.js implementation requires using a context.log() method, rather than the standard console.log(). As above, this is valuable when debugging functions during development; however, it hardly helps with monitoring and analysis. To accomplish this, Azure Functions offers a built-in integration with Azure Application Insights, Microsoft Azure’s Application Performance Monitoring platform.

It is important to note that, while AWS Lambda automatically writes logs directly to CloudWatch, some assembly is required to store Azure Functions logs in Azure Application Insights for an existing function (although the option to store logs in Azure Application Insights is made available upon function creation). Configuring Azure Application Insights for a given Azure Function is outside the scope of this article, so I highly recommend reading about the process here.

Google Cloud Functions

While utilizing the built-in logging methods in Google Cloud Functions is the proper way of writing log data, Google Cloud Functions logs everything written to standard output at the INFO log level, everything written to standard error at the ERROR level, and all internal system messages at the DEBUG level. To access these logs, the gcloud command can be used at the global level, on an individual function, or even for a specific execution, like so:

$ gcloud functions logs read
$ gcloud functions logs read FUNCTION_NAME
$ gcloud functions logs read FUNCTION_NAME –execution_id EXECUTION_ID

Additionally, as with AWS Lambda and Azure Functions, Google Stackdriver can be used to analyze and monitor logs from Google Cloud Functions. Stackdriver offers both a dashboard interface as well as a REST API for querying, analyzing, and alerting on log metrics. Interestingly, Stackdriver also offers second-party triggers for reacting to specific logs.

Taking Things Further

Serverless platforms, as with all new technologies, have introduced new paradigms into the software development lifecycle. But with the proper integration of the provider’s built-in log aggregation and application performance monitoring tools, the log data generated by these serverless functions can be analyzed just as easily as with other tools (if not more so). And with a little work, this data can be pulled into third-party performance monitoring platforms for even more end-to-end analytics and monitoring.

How I Read

2024-01-29T12:00:00+00:00

I was at coffee with a close friend on Friday, and the subject of reading came up.

He, like most people, reads a few books a year, but I tend to read a lot more than most people—last year, I read about 40 books, but in the two years prior I broke 80. As with most habits, I tend to read less when I'm overwhelmed, and 2023 was a particularly stressful year for me, but 40 books is still no small feat compared to most people.

The thing is, I am by no means a fast reader. In fact, I am often frustrated by how little progress I tend to make in a single session. So, how can I still knock out between one and two books a week (on average)?

When I really put some thought into that question, the answer ultimately comes down to a few things: commitment, variety, and availability.

First, Commit...

When something is important to you, you tend to make time for it. I'm not a gym rat—more like a pizza rat—so I don't think I'll ever wake up at the ass crack of dawn for the sole purpose of sweating my ass off; but I will absolutely wake up early to read.

My kids wake up to get ready for school at 6:15 in the morning in order to catch the bus at 7:15. I start work at around 8:45, which means I need to be dressed, ready, and walking out the door by 7:45 if I want to have time to commute, purchase an overpriced Americano, and do a mindfulness meditation in my car before the ritualistic torture that is "my job" begins.

As you can imagine, my mornings can be chaotic, overwhelming, and (often) shitty; but reading helps. So I wake up at 5am, make some tea, and retire to my office where I turn on some lo-fi beats, flip the heater and essential oils diffuser on, and cozy up in the recliner to read for the next hour.

If it sounds a little ritualistic, it's because it is. I need to start my day off right, and this has been the best way for me to at least reach a healthy baseline.

...But Not Too Much

If you visit my library page, you'll see that I almost always have more than one book in progress. There are a few reasons for this, but the main one is that I like to have different books to meet different moods.

Sometimes I want to read a graphic novel (which is absolutely still reading), or a philosophy book, or a biography, or a technical book, or a fucking self help book; which means that having a few different books in progress gives me some variety to choose from.

If you only read one book at a time, then you are at the whims of just that one book. If you don't feel like reading about leadership principles or how awesome Tim Ferriss's life is, then something that should be enjoyable becomes a slog.

Give yourself options and let your reading follow your moods in order to make a dent in your massive book backlog.

I'd also like to call out that another side benefit to reading multiple books at the same time is synchronicities. I experienced this a lot in college, where the materials from one course overlapped in weird and unexpected ways with other ones I was taking, resulting in a kind of feedback loop that helped the subjects sink in better.

Reading is no different.

You'd be surprised how seemingly different books complement each other, allowing you to create connections that you might not have otherwise noticed if you single-threaded your reading.

Make It Easy

One of the key components to habit building, as per James Clear, is making it easy.

To repeat myself from about 4 sentences ago: reading is no different.

While I read multiple books at the same time, I am careful to deliberately read multiple books on multiple mediums at the same time.

WTF does that mean?

It means that I almost always have a physical book in progress (you know, the kind printed on dead trees), a Kindle book in progress, an eBook in progress (Moon+ Reader Pro for Android is a must-have), and sometimes even an audiobook in progress.

By having access to a book at all times, I'm more likely to read that when I have a moment than scroll social media (although I also don't have social media or news apps on any of my devices, and relegate entertainment apps like Netflix to my tablet only).

You may be wondering why I maintain a distinction between Kindle books and eBooks; in short, it's because they are read on two different types of devices. Sure, I can read a Kindle book on both my phone and Kindle device, but that convenience doesn't apply so readily to eBooks acquired outside of the Amazon ecosystem (and, while I know that you can upload external eBooks to the Kindle, the highlights don't automatically sync to Readwise, which is how I backup and reinforce what I read and learn).

So I keep them separate, and it works for me.

Finding Your Zen

There's a common refrain about time management that it's not that we don't have the time to do the things we want to do, it's that we don't make time.

While that is technically true, the reality is more complicated.

It's not that we don't make the time, it's that we don't have the energy to do what we want with that time.

If you want to read more—or do anything more, for that matter—it's not just about prioritizing it. It has to fill your cup. You have to work it into your life in a way that doesn't feel like a chore, but instead like a gift.

I not only love to read, I need to read. It's how I keep cool when the world feels like it is falling apart around me. It's what slows me down and brings me to my center.

This is post 030 of #100DaysToOffload

Sunday Reboot — January 28, 2024

2024-01-28T17:16:00+00:00

Happy Sunday, friends.

It's been a fucking week, so this issue has taken me a lot longer to knock out that it normally does. I think I've spent at least 4 hours, time-on-screen, working through it (as opposed to my normal 45 minutes).

There's not much say about why that is. Those who know me probably know why, and those who don't are more than welcome to shoot me an email and ask. I welcome and enjoy hearing from anyone who reads these posts.

The big theme for this past week has turned out to be "Retrocomputing" (that's right, I made it one word, fight me). I've been feeling more nostalgic than usual, probably in no small part due to increased stress and anxiety—there's something about looking back to a time when things were personally simpler to both calm your nerves and make you frustrated with the present state of things.

I don't have much else to add today, so I'll jump into the reboot, and hope that next week's is a bit more fruitful.

Pondering...

"If our lives are oceans, then our days are waves; some big, some small." — Ryder Carroll

I pulled out Ryder Carroll's book, The Bullet Journal Method, just to pick through it again recently and this highlighted quote jumped out at me because, lately, life has felt like a fucking tsunami, with wave after wave pounding the rocks that are my soul.

The quote is a good reminder that every day won't bring a tidal wave of dread and anxiety, but at the moment I'm exhausted.

I think, though, that the key isn't to just learn to put up with the waves and hope things get better before the rocks get pounded into sand; it's to relocate to a calmer beach. I'm sure those of you who read my reboots have noticed this recurring theme, but at the moment my beach feels like its on an island and I missed the last boat to the mainland.

My wife came home from a brunch with some friends earlier today, and said that it feels like we're living life on "hard mode," and damn if that isn't the truth; so my mission at the moment is to figure out where the damn settings menu is so I can turn down the difficulty from "Nightmare!" down to a more manageable "Hey, not too rough."¹

Learning...

I just completed Class 3 of the Halt and Catch Fire Syllabus and am so happy that I've started doing this. While I had already bought into the cult following of this show long before discovering the syllabus, the added layers of emulators, historical RFCs, and selected readings alongside the episodes is like turning a good steak into a five star, four-course meal.

It's interesting to consider how "personalization" was such a revolutionary concept in the early 1980s. It wasn't their utility that turned computers from an appliance into a necessity, but the underlying fun that can be had with them.

I remember when I got my first computer—back in a time when families had "computer rooms" and you had to wait your turn to use it. I was obsessed from day one, and still remember the feeling that real magic was happening underneath all of the plastic and wires. Personally, I feel like I've lost a lot of that wonder, but rewatching this show so intentionally is helping revive some of that feeling again.

Looking ahead to Class 4, we will be wrapping up Season 1 and pondering the cultural, societal, and environmental impact of the personal computing revolution on the world in the early 90s through today.

Hobby...ing...

A little over a week ago, I revived the MUD Coders Guild blog with a post about wrapping the 30-year-old Envy MUD source code in a Docker container. While it's the first post we've shared in four years (things kind of fizzled out when COVID hit), I've been having fun tinkering around with the Envy MUD source code again.

To be clear, Envy isn't my favorite DikuMUD variant (the grandpappy of most 90s and early-aughts codebases), but it is the core codebase that my favorite variant was based on—Eye of the Storm (EoS).

Envy is my tinkerable of choice right now because it is a very paired down version of EoS; in other words, it has the core components of what I love about EoS, but has a lot more room for experimentation.

While my life is overwhelming enough right now to keep this project moving slowly, I do intend to drip out more legacy MUD content over the coming months because (if I'm being perfectly honest), it's one of the few things brining me joy at the moment.

Reading...

Continuing down my forays into retro computing, I've been reading a lot of blog posts and essays lately. A few have been plucked from the Halt and Catch Fire Syllabus, but others have found their way to me more organically:

The Dumbing-Down of Programming (Parts One and Two) — Ellen Ullman shares her experience of buying and installing the Linux operating system instead of Windows in 1998, reflecting on the profession of programming and how technical expertise has changed. The author contemplates the layers of complexity that have been added to the (then) modern programming tools and the temptation to rely on wizards and shortcuts rather than truly understanding the underlying code.
Where Have All the Websites Gone? — "It’s a technical marvel, that internet. Something so mindblowingly impressive that if you showed it to someone even thirty years ago, their face would melt the fuck off. So why does it feel like something’s missing? Why are we all so collectively unhappy with the state of the web?"
Memories from Old Lan Parties — Some top-notch reminiscing about late 90s, early 2000s LAN parties. While the article does a good job aggregating and posting a large list of anachronisms, one thing that I personally miss from LAN parties is the IRL of it all. Multiplayer gaming used to be a social affair true to the word "party," (except for nerds). It wasn't just about gaming, but fellowship and togetherness.
I Used Netscape Composer in 2024 — A absurdly delightful post about recreating a web page (the author's personal website) using Netscape Composer. TBH, I loved this so much I will likely be doing something similar (although, for the sake of variety, I might use the copy of Macromedia Dreamweaver I still have installed on my old Windows tablet PC).
10 Weird HTML Hacks That Shaped The Internet — Tedium is an excellent blog in its own right, but this particular article hits home for me. As a matter of fact, I utilize a handful of these hacks on this very blog in order to better maintain its backwards compatibility.

Not everything is "vintage computing" related, but they do all hold similar themes around the concept of low-and-slow-tech (as it would be defined today, not 30 years ago), and are doing everything they can to reinforce my desires to slow the fuck down and live a more reasoned life where the technology I use is something that I either enjoy or get real value out of, rather than simply ~~deal with~~ accept.

Footnotes

https://doom.fandom.com/wiki/Skill_level#Doom,_Doom_II_and_Final_Doom_skill_levels ↩

This is post 029 of #100DaysToOffload

How Cloud9 Kept Me on Track after a Hardware Failure

2024-01-26T13:30:00+00:00

As mentioned in this week's Sunday Reboot, I've recovered a few of my old posts from the Wayback Machine—all from my time at the now shut-down Fixate.io (via their blog, Sweetcode). These are all freelance topics, so the style of writing is a bit different than normal (for me, at least), and the topics are a little wider-ranging than I would normally write about here.

If I remember correctly, I wrote this one around 2016 to help the company try and bring on Cloud9 as a customer (before they got acquired by Amazon). It is a true story (I did use Cloud9 in a pinch for one whole day to get some work over the line), but I honestly don't know if the sales pitch worked.

Earlier this year, the GPU on my MacBook failed about 2 days before a big project deadline. I needed to code, and Cloud9 saved me.

Thankfully, the repair was covered by Apple as a known issue for my particular model, but taking a sudden week off of work to get it fixed isn’t something my clients would have been too happy about. I still had a ton of work to complete, but at least I didn’t have to buy a new laptop.

While I (like most nerds out there) have a handful of “vintage” computers stuffed in the various nooks and crannies of my home, none of them could be considered “developer” ready. Trying to run a virtual machine on a 7 year old laptop I bought at Walmart for $100 is one of the more painful things I’ve ever failed at, so my traditional development environment wasn’t going to work out.

Enter Cloud9

Cloud9 is a cloud-based development environment powered by Docker that packages a powerful IDE and built-in terminal in an easy-to-use browser-accessible interface. With the ability to import projects from GitHub and BitBucket, Cloud9 was the perfect solution to keep my projects on track with the least amount of overhead.

Cross-Platform

Because Cloud9 is cloud-slash-browser-based, it is cross platform and usable on pretty much any device that can run Google Chrome. This was incredibly useful for me because running Google Chrome is pretty much the only thing my old laptop is capable of doing anymore. The big advantage to this is, had I not had another laptop, is that I could have picked up a cheapo Chromebook (or even borrowed a computer from a friend) without losing any functionality.

Unfortunately, because Cloud9 is browser-based, many of the standard keyboard shortcuts I’m used to have to be thrown out the window. A few of my browser’s keybindings take priority over the Cloud9 keybindings, which means some of the muscle memory I built over the years is rendered useless.

While missing my standard keybindings is a bit of a pain, I think this issue might be remedied with a dedicated Chrome app, or even a lightweight cross-platform desktop app that adds some wrapper functionality around the website (think Slack or Franz).

Containerization

While Cloud9 couldn’t run my projects’ Vagrant provisioners out of the box, each workspace provides a containerized Ubuntu container which I was able to manually provision with minimal effort (it took less than 30 minutes to get a development environment up and running). It is worth noting that this time could have been drastically reduced if I was using a shell provisioner instead of Puppet.

Because of the popularity of containerized development environments like Docker and Vagrant, I think that providing some support for the configuration files of those platforms would go a long way to making Cloud9 a powerful development environment replacement. It would allow remote teams to quickly hop onto a workspace, provision it, and pair program a problem without very much overhead.

Cloud9 definitely helped me out of a jam, and I would recommend it to anyone who is in need of a fast, lightweight, and affordable development environment.

CI/CD/CV: Emphasizing Continuous Visibility

2024-01-25T09:18:00+00:00

Original Title: Error Tracking and Continuous Visibility: Why to Track Errors Across the CI/CD Pipeline

User-generated error reports are valuable for identifying the pressing issues in your application. Yet they are also notoriously unreliable and difficult to read.

To a user, every problem is a major one, and the tone of voice that often accompanies user-generated reports can be difficult to parse and diagnose. Users just want their problems fixed. Asking them to run through a series of tests to find reproduction steps and appropriate error messages can be trying at best. At worst, the users don’t follow through, and you can’t get the details you need to fix a problem.

This is why error tracking solutions like Rollbar and RayGun are so important. They provide the continuous visibility that you need to maintain user expectations, without the subjectivity and inconsistency of user-generated error reports.

Continuous visibility means the ability to trace errors at all stages of the CI/CD workflow. Continuous visibility is much easier than relying on post-deployment error reports to identify and attempt to trace software problems. As I explain in this post, with the help of tools like Rollbar, you can find and fix errors throughout your continuous delivery process, and, ideally, avoid releasing user-impacting bugs into production altogether.

Achieving Continuous Visibility at All Stages of the CI/CD Pipeline

Why integrate error tracking into all stages of the development process? Because integrating error tracking into production and staging environments, as well as post-deployment environments provides transparency into the health of your application, eases the diagnosis of issues, and identifies problems before users even know they exist.

In addition, by integrating error tracking into your entire workflow, it becomes easier to identify environment-specific errors by tracking exactly which environments and branches your errors exist in.

Test Suites are Not Enough

You might be thinking: “I run software tests pre-deployment, so I’m covered. I already have continuous visibility into my CI/CD pipeline.”

In reality, however, software testing is not the same thing as error tracking, and it doesn’t deliver the same type of continuous visibility. Your Jenkins (or TeamCity, or Bamboo, or whatever CI server you prefer) integration tests help you do what their name implies: Test code as you integrate it into your codebase. Meanwhile, software usability, performance and quality tests using platforms like Selenium or Cucumber help you to verify that your application works as expected, but not find every application error, or identify the root cause of errors.

In short, a typical test suite may show you what failed, and possibly even how. Yet not every exception results in a failed test. Plus, in the case of poorly written tests—which happens to the best of us—or integration tests, a successful test may trigger an exception that you never see because you aren’t looking for it.

APM Is Not Enough

Just as pre-deployment software test suites aren’t enough to provide continuous visibility, post-deployment monitoring also fails to deliver all of the visibility you need in order to guarantee a positive user experience.

SolarWinds, Nagios, Splunk and the like are all great tools, and you should include them in your stack. But don’t make the mistake of thinking that they cover all of your post-deployment visibility needs. They will help to notify you when something in your application breaks or experiences a service degradation, but in most cases they won’t identify application errors. Your Web app could even be spitting out error messages that your users see, as long as the application continues to run, an APM tool generally won’t notice there being a problem.

APM tools look for performance patterns that seem out of the ordinary, and for services that stop being available. They often lack the ability to track errors at the application level unless those errors cause the application to go down entirely.

Achieving Where Error Tracking Fits In

All of the above is why error tracking is so important. Adding error tracking to all stages of your CI/CD pipeline bolsters the visibility that automated testing provides pre-deployment, and that APM provides post-deployment. Error tracking offers unique visibility that other types of tools don’t provide.

In addition, error tracking tools help you not only to identify problems before they reach a production environment, but also to identify exactly when tricky issues get introduced into the codebase.

Identifying the when of an error is particularly important. Not every issue is guaranteed to be raised by customers immediately after a deployment. It can therefore be difficult to identify exactly how long something has been a problem. With a thorough testing routine that involves automated tests as well as error tracking tools like Rollbar, exceptions are far more likely to be raised almost immediately. This will give you much more insight into your application, both in and out of test process.

When it comes to tracking errors, there is no such thing as too much data. By integrating error monitoring into your CI/CD process, you can achieve Continuous Visibility into a great deal more than your test suite and build process.

The Value of Error Data: Identifying Trends

Error data is useful not just for fixing a particular problem, but also for identifying trends in your development process, and tracking how well your team resolves issues as they happen. If an issue is identified in a production environment, the next step in the process should be replicating that issue in your test suite, and then pushing up a fix for it. If you can replicate a problem in your CI/CD suite, you can track the exact moment when it gets fixed, and verify that fix immediately. Once you mark the error as resolved in your error tracking solution, it can continue monitoring the error in production, and notify you if it reoccurs.

Ultimately, the power of exception monitoring isn’t in the identification of issues, but in the tracking of them. Knowing the who, what, where, when, and why of an issue will provide far more insight into your application than ever before, and by integrating this information into other areas of your application development process—like code reviews and retrospectives—you will be far more prepared to handle issues when users run into them.

Post-Mortem Incident Report Do’s and Don’ts

2024-01-23T19:44:00+00:00

Original Title: 8 Tips to Create an Accurate and Helpful Post-Mortem Incident Report

Stuff breaks, it’s inevitable. People make mistakes, technology breaks down, and processes aren’t infallible. But, when incidents happen, what can we do about it? What can we learn?

As with all things, learning isn’t a binary action, it’s a process. And, when an incident occurs, organizations typically conduct a post-mortem analysis and generate a post-incident review to uncover what went wrong and why. These reports are critical for identifying where our processes and guardrails break down so we can learn how to do better next time.

Post-mortem incident report tips

When it comes to incident response, committing to learn from it is half the battle. The other half is setting up a successful process for continuous education by creating accurate and helpful post-mortem incident reports. While the goal of these reports is to provide you with the information you need to grow, there are a few things you should (and shouldn’t) do to ensure you’re getting the most out of them.

1) Don’t assign blame

We’ve all heard about “blameless post-mortems.” But, what does it really mean to be “blameless” in DevOps and IT? While it doesn’t mean there are no consequences for malicious actions, a blameless culture recognizes that everyone makes mistakes and that consequences without context will de-emphasize learning and continuous improvement over time.

When creating a post-incident review, it’s critical to avoid assigning blame to any one person. Instead, focus on where the process broke down (or where more process is needed). It doesn’t matter if Joe pushed the button or Jacob wrote the function – those actions may have contributed to the incident but the true failure is almost always a lack of checks and balances along the way.

2) Do take responsibility

A good post-mortem report should avoid pointing fingers, everyone involved should take responsibility for both the process and the incident itself. In order to foster a blameless culture, it’s important to emphasize the fact that everyone owns the quality process. When a problem that “you caused” gets re-framed into a problem that “we own,” it allows engineers to focus more clearly on what can be done to make things better rather than waste time trying to deflect blame.

3) Don’t procrastinate

When should you perform a post-mortem? If your answer to that question wasn’t “immediately,” then you’re not doing them soon enough. While it may sound counterintuitive, you should always create a post-mortem incident report while the proverbial incident iron is still hot. This way, the incident is treated with an appropriate level of criticality and all of the details are still fresh in everyone’s minds. If you wait too long to recap and evaluate, details will be missed, passion will be low and the need to improve the process won’t feel so urgent. If you’re going to conduct a post-incident review, do it now or don’t do it at all.

4) Do gather information

When it comes to post-mortems, data is like time – it’s better to have too much and not need it than not enough and need more. Start by establishing a timeline of what exactly happened and then flesh it out with as much detail as possible. This should include the sequence of events that led up to the incident, how and when the incident itself occurred, who was impacted, how many support cases were generated, who responded to the incident, how quickly, what the response team did to resolve the incident and anything else you can think of. This post-mortem information will be invaluable in determining the root cause and will make identifying areas for improvement significantly easier.

5) Don’t be vague

Details, details, details. When creating a post-mortem report, don’t be vague. While the minutiae may seem unimportant, these details can be crucial to root cause analysis. More importantly, by putting as much detail as possible in the report, you eliminate the need to regroup unnecessarily with the incident response team, ensuring that learnings can be extracted directly from the report itself.

6) Do define clear owners

While “we” should always take responsibility, it’s important to identify who owns any action items that come out of the post-incident review. As the saying goes, “if everyone owns it, nobody owns it.” By defining clear owners for action items, you ensure any work that needs to get done as a result of the incident report has a person accountable for it.

7) Don’t lose focus

Engineers like solving problems. Unfortunately, a post-mortem isn’t always the time to do that. Don’t get me wrong, the purpose of a post-mortem is to identify what went wrong and how we can prevent it from happening in the future but it’s not always the time to get into the weeds when it comes to technical problems. In some cases, a post-mortem is a great place to do a root cause analysis. However, some problems have nuanced technical causes that require deeper investigation. While many of us may want to dig into these problems right away, they should be identified as action items coming out of a post-incident review rather than being allowed to distract from the goal of the entire process.

8) Do use a consistent template

The best way to maintain focus when creating a post-mortem incident report is to use a fixed template. When time is critical, it’s important not to waste it by performing a post-mortem without an agenda. A fixed template can be used for every post-mortem at your organization to ensure the timeline, discovery, ownership and focus all follow a consistent pattern. Templates can, in turn, allow you to perform post-mortems on your post-mortem workflows to further improve the overall process over time.

Always be learning

Incidents happen. But, that doesn’t mean we can’t do something about them. By defining what a high-quality and clearly defined post-mortem incident report looks like, you can ensure the lessons learned with each incident aren’t lost. Eliminating blame, taking responsibility, gathering information, and focusing on tangible outcomes are all critical steps towards building a failure-tolerant culture that can learn from its mistakes.

Techmento Mori

2024-01-22T06:29:00+00:00

Shhhhhh! This post is for RSS subscribers only. Look here for more information (and to join in on the fun).

I've written before about my love for thrift stores.

While I'm going through a pretty serious purging phase right now, I still enjoy taking a stroll around my local thrift store after dropping off a trunk full of ~~junk~~ donations—on the off chance someone has donated something on my mental shopping list.

Well, that actually happened this week (as it so often does); but first, some background.

In The Beginning...

A while back, I replaced my Google Wi-Fi mesh network with Nighthawk routers that I flashed with the dd-wrt firmware, and while it worked (and felt nice to "own"), the coverage of an individual router was subpar for the size and construction of my house (the damn network trunk is in the basement) and multiple routers provided better coverage but our devices (phones, tablets, etc.) didn't do a great job picking the closest access point.

I generally don't mind managing this stuff, but I've been thinking about my own mortality more lately (don't ask me why), so I've been considering what the second-order effects of my death on my family might be. Beyond the first-order effects (such as grief and finances), the second-order effects are the answers to questions like "if I died tomorrow, would my wife be able to deal with a technology problem given our current setup?"

Turns out, the answer is a resounding "hell no!"

The curse of a tinkering nerd is that we make the people around us hopelessly dependent on our presence to get through the day (or week). Something break? We fix it, not because we're the ones who can, but because we're the ones who set up the whole complicated system in the first place.

So, one simple answer to the more complex question of "what are the consequences of the consequences of my death?" is to simplify the technology setup in my home using commercially available and well-supported consumer technology.

The first phase to moving in that direction is moving our Wi-Fi setup back to the Google Wi-Fi mesh network. It's simple to manage, is well documented, and "just works." So, I restored the three access points we had, and threw the Nighthawk routers in a box to donate.

Behold, Hope!

While this setup is simpler and plays nicer with our devices, the access points aren't quite good enough to get coverage where it needs to be. I need a fourth one to properly extend the network to a relatively dead corner of our home, but I also have no intention of spending any real coin to get one.

Enter, my quiet stroll around the thrift store.

Like I said above, I maintain a mental shopping list of things that I don't need, but could use that I reference whenever I enter a thrift store. Sometimes it's simple, easy to find stuff (like a calculator for my ham radio exam, or paper for my typewriter), but other times it's more specific, like the brand new leather Samsonite laptop bag I found one hour after my late grandmother told me about her gratitude for said company that gave her, an unmarried single mother in the 1950's, a job and a future.

For some reason, I've always had luck finding what I need, and this time held no exception.

After my drop off, I knew that I wanted to find a fourth Google Wi-Fi access point to extend my network (which, I'm sure you guessed, I did find on the shelves for just a couple bucks), but another item on my mental shopping list also revealed itself.

But Wait, There's More

About a year ago, I picked up a fancy new folding phone, with the deluded consumerist reasoning that "I can read books on it!" While I do read a lot of books on the phone, it hardly has the weeks-long battery life of the Kindle I promptly gave to my wife, and has a hell of a lot of distractions baked in as well (when was the last time your Kindle alerted you of anything while you were reading?).

I'm not quite ready to ditch the folding distraction machine yet, but I have been wanting a single-purpose digital device again that lets me read books (and nothing else) while still syncing all of my notes and highlights to Readwise, and the Kindle fits that bill pretty well.

But, as you can imagine, my "problem" and my wallet are often in disagreement.

I'm not about to fork over another couple hundred bucks just for the privilege of fewer distractions and a better battery life; so, "a Kindle" made its way onto my "synchronicity shopping list."

A Kindle that I found on the shelf last week for $2.99.

Interestingly, this baby is the now-discontinued Kindle Touch, a fourth generation Kindle (the first with the integrated touch screen, I believe), and is the exact model of my first Kindle (that I gave away to my sister-in-law a few years ago). It predates the integrated backlight, and hasn't received any updates from Amazon in quite some time, but can still be registered and download purchased books.

What I like most about this particular model is that it is also incompatible with the newest "look at all of our ads!" trend in the latest Kindle models, with a simple home screen and not a ton of bells-and-whistles.

For my needs, it's well worth the $3 and 45 minutes I spent to acquire and refurbish it.

This is post 028 of #100DaysToOffload