DEV Community: Jeff Dwyer

VSCode Plugin For Feature Flags

Jeff Dwyer — Fri, 17 Nov 2023 20:45:59 +0000

There's nothing like a cool editor extension. I'm so excited that I can edit feature flags right in VSCode. We thought about what would be cool and here are 3 things we came up with:

Autocomplete for Feature Flags: No more typos leading to bugs! Get suggestions for flag names as you type.

Hover to Know: Curious about a feature flag's status? Just hover over it in your code to see its current settings.

Personal Overrides: Test flags in your local setup without messing with the team's settings.

If you're interested to learn how we did this, check out Hands-On LSP Tutorial: Building a Custom Auto-Complete which takes you step by step through adding an autocomplete of your own to VSCode.

Feature Flag & Dynamic Log features we shipped this summer

Jeff Dwyer — Fri, 15 Sep 2023 16:17:44 +0000

Tagged Logging vs Structured Logging

Jeff Dwyer — Wed, 13 Sep 2023 17:07:58 +0000

Understanding Tagged vs. Structured Logging

What's Tagged Logging?

Tagged logging allows you to prepend tags to your log messages. For instance, using ActiveSupport::TaggedLogging, you can tag logs with "Auth API" or user IDs.

class Permissions
  def get(user)
    logger.tagged("Auth API") do
      uri = URI("https://auth.example.com/permissions/?user=#{user}")

      logger.info { "Fetching #{uri}" }
      permissions = Permissions.parse(Net::HTTP.get(uri))
      logger.info { "Got permissions #{permissions.to_s}" }
    end
  end
end

# Log Output
#[Auth API] Fetching https://auth.example.com/permissions/?user=bob
#[Auth API] Got permissions admin, writer, reader

Pros:

Enhances log readability.
Avoids repetition by tagging once for multiple log lines.

Cons:

Not machine-friendly. While the text version looks good, the JSON format can be confusing, especially when searching for specific tags.

Structured Logging: A Better Alternative?

Structured logging provides a more organized way to log messages. Instead of tagging, you structure your logs with key-value pairs.

Example:

log.info "hello", user: "1", team: "The best team"

Output:

Text Log:
INFO hello user=1, team=The Best Team

JSON Log:
{severity: INFO, message: "hello", user: 1, team: "The Best Team"}

This approach is more machine-readable and fits better with modern log aggregators.

Libraries Supporting Structured Logging:

Note: Lograge offers structured logs for Rails requests but lacks custom structuring.

Why I Wrote This

I'm building a dynamic log library and wanted to understand the best approaches to structured and tagged logging.

In Summary:

Tagged logging is user-friendly but not machine-friendly.
Structured logging offers a more organized and machine-readable approach.
Tagged logging does have nice nesting behavior, though you can achieve that with the semantic logger gem as well.

Thoughts on: Time-traveling Ruby Logger

Jeff Dwyer — Fri, 11 Aug 2023 19:37:45 +0000

I've been thinking a lot about application context, the core things that our application knows: the current user, the instance it's running on, details about the request.

Pretty often we know all of the context right up front and the beginning of a request, but sometimes we don't figure out this context until later in the request. Sometimes this is annoying. It might be nice to log things details of the request along with the userID at the beginning of a request, but we don't actually know the userID right at the beginning. Or we might want to log more details of the processing, but only if the request errors later on.

I like the ideas in: Time-traveling Ruby Logger

I wonder if there are other ways to extends this thinking. The buffer is a bit like a promise queue that will get called later with more information. I'm curious if this gets other peoples' thoughts flowing too.

7 Ruby Feature Flag Tools Compared

Jeff Dwyer — Wed, 07 Jun 2023 14:05:56 +0000

How many log levels are there?

Jeff Dwyer — Tue, 25 Apr 2023 16:02:10 +0000

I'm building a tool to allow you to change the log levels of your application at runtime. In order to do that, I need to show you a dropdown of the various log levels. Something like:

I started with Ruby so I put in DEBUG INFOWARN ERROR FATAL.

Of course, then I wanted to do it for Java, so I had to add TRACE.

Then Python wanted CRITICAL so... spreadsheet time.

Here's the sheet I ended up with. It was a fun tour.

I wrote up some details and ideas / humor about why I think each language chose what it chose here, but just take a look at the grid, I was surprised by how many there are.

A Gotcha With Gauges

Jeff Dwyer — Mon, 24 Apr 2023 00:10:57 +0000

I had a gotcha recently trying to use a Gauge metric that I wanted to share.

I love metrics and I use Micrometer as a Facade for them.

Typical usage looks like the following, although you can also annotate a method with @Timed which is delightful.

SimpleMeterRegistry oneSimpleMeter = new SimpleMeterRegistry();
Counter counter = registry.counter("page.visitors", "age", "20s");
counter.increment();

I typically use counters and timers and they have always been pretty straightforward.

We're building a system for dynamic config now and as part of that I wanted to track the current number of connections. Counters and Timers aren't right for this sort of thing however, what I needed was a Gauge, which should work right out of the box.

I did something like the following and thought that would be it:

class ConnectionHolder
  private final AtomicInteger connections;

  @Inject
  public ConnectionHolder(MeterRegistry meterRegistry) {
    connections =
      meterRegistry.gauge(
        "config.project-connections",
        Tags.empty(),
        new AtomicInteger()
      );
  }

  @Scheduled(fixedDelay = "1m")
  public void recordConnections(){
    projectConnections.set(calculateConnections());
  }
}

I made 2 connections to test it out and looked at the metrics. I was very surprised to see my numbers all over the place! Sometimes zero, sometimes one, sometimes 2.

The Problem

Trying to use Gauges exposed a setup problem in my DataDog metrics. The core issue is that Gauges are not additive in the same way as Counters. Here's what I mean:
If server A writes a metric counter:apples=2
And server B writes a metric counter:apples=1

Both of those metrics will be saved in the time period and we can add those together and get 3.

Gauges however, are stored differently.

If server A writes a metric gauge:apples=2
And server B writes a metric gauge:apples=1

The metrics backend will only store the most recent value: gauge:apples=1.

In my case, this meant we had a minute by minute race conditions between the two running pods.

The Solution

The solution is proper metric tagging. We need each server to be tagging the result as having come from it. This prevents the backend from clobbering our values here.

gauge:apples=2,pod:abc123
gauge:apples=1,pod:xyz789

The problem in my case was that DataDog was not sending stats through my Datadog sidecar and was sending them straight to the Datadog API, which bypassed the functioning tagging process that was working for APM.

For more info, there are full details in this post, which gets into the details of passing the pod ID into the containers and setting the tagging explicitly.

Takeaway

You can forget about the underlying way that stats are collected with counters, but gauges are less forgiving. Keep that in mind and happy counting.