DEV Community: Jennifer Davis

Why your `curl` logic just bit you 🐾

Jennifer Davis — Mon, 09 Feb 2026 05:01:07 +0000

It’s a common strategy to test a new API directly with curl. It feels intuitive, fast, and removes the overhead of a language runtime. For example, if you are testing out the Google Cloud Logging API, you might start with a simple request to list logs from a Kubernetes container.:

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  https://logging.googleapis.com/v2/entries:list \
  -d '{
    "resourceNames": ["projects/your-project-id"],
    "filter": "resource.type=\"k8s_container\""
  }'

The JSON returns perfectly. But then, you move that logic into a Node.js application using the official @google-cloud/logging library.

import { Logging } from "@google-cloud/logging";

export async function readLogsAsync() {
  // Common approach: Initializing the client without explicit auth
  const logging = new Logging();

  const [entries, , response] = await logging.getEntries({
    filter: 'resource.type="k8s_container"',
    resourceNames: ['projects/your-project-id'],
  });

  console.log(entries.length, response.nextPageToken);
}

All of a sudden, the code fails with a cryptic error: Error: Could not load the default credentials.

This happens because of a disconnect between how the gcloud CLI manages session tokens and how the Google Cloud client libraries search for credentials.

While your curl command relies on the explicit token you provided via gcloud auth print-access-token, the client libraries are designed to look for Application Default Credentials (ADC).

Running gcloud auth login authenticates, but it does not create the specific credential file that the Node.js library requires to run locally.

🤫 Authenticate for local development

The most efficient way to solve this is to provide the library with the credentials it is looking for. Run the gcloud auth application-default login command in your terminal.

gcloud auth application-default login

This opens a browser window to authorize your account and saves a JSON file to your local configuration folder. Once this is done, your Node.js code will automatically find these credentials—no code changes required.

🏡 Moving to Production

Once you get your local environment running, you need to think about "productionizing" your code. Hardcoded project IDs and lack of robust error handling are common causes of production outages.

🛡️ Robust Error Handling

In production, your app should handle permission issues or network timeouts gracefully.

try {
  const [entries] = await logging.getEntries({
    filter: 'resource.type="k8s_container"',
    resourceNames: [`projects/${process.env.GOOGLE_CLOUD_PROJECT}`],
    pageSize: 10, 
  });
} catch (error) {
  if (error.code === 7) {
    console.error("Permission Denied: Check your Service Account roles.");
  } else {
    console.error("Unexpected Logging Error:", error.message);
  }
}

🎭 Service Accounts

In production, you shouldn't use your personal user credentials. Use a Service Account with the "Logs Viewer" role.

🌍 Environment Variables

Avoid hardcoding project IDs. Use an environment variable to make your code portable across staging and production environments.

const PROJECT_ID = process.env.GOOGLE_CLOUD_PROJECT || 'your-project-id';
...

export async function readLogsAsync() {
  const logging = new Logging({ projectId: PROJECT_ID });

Structured Logging

Instead of just reading logs, think about how you write them. Using structured JSON logs makes them much easier to query later in the Cloud Logging console.

If you are running on Google Kubernetes Engine (GKE), you don't even need to use the Logging library to write logs. Printing a JSON string to stdout allows GKE to parse your data into searchable fields automatically.

export function logStructuredStatus() {
  const logEntry = {
    severity: "INFO",
    message: "Container health check successful",
    container_info: { version: "v2.1.0", uptime: process.uptime() },
    http_stats: { active_connections: 42 }
  };

  // GKE picks this up and converts it to a structured log automatically
  console.log(JSON.stringify(logEntry));
}

Get started

I'll be sharing a more thorough walk-through on using the native observability features provided with GKE real soon—including how to automate this stuff so you can avoid the manual debugging of credential errors.

In the meantime, dive deeper here:

📖 How Application Default Credentials work – Understand the "magic" behind the lookup.
🛠️ Providing credentials to ADC – Setup guides for every environment.

Giving my droid a personality with ESP32 and Arduino Modulino sensors

Jennifer Davis — Fri, 23 Jan 2026 07:07:07 +0000

In my last post, Willard the Smart Car was undergoing surgery for ghost states and memory leaks. While I continue to debug the "Reflex Layer," I wanted to work more on the emotional response layer.

As a recap, the plan is for the Raspberry Pi to be the Cognition Layer (high-level thinking) and the Arduino Uno (or in Willard's case the Elegoo board) to be the Reflex Layer (movement). That leaves a critical piece for interaction and sensing. I decided to experiment with the ESP32 as the Interaction Layer—the "Feeling Brain" that gives my droid its personality.

The Hardware Pivot: SparkFun & Qwiic

This layer uses the SparkFun ESP32 Thing Plus. I couldn't be happier with the ease of experimentation here, primarily because of the board’s design and the Qwiic (I2C) ecosystem. (I will publish more of my experiments to my GitHub repo uno-sketch-box repo, although kind of regretting my name choice as I'm experimenting with more than just the Arduino Uno at this point.)

One of the biggest challenges with Willard was the bird’s nest of jumper wires taking over the chassis.

The Thing Plus uses the modern USB-C standard, has built-in wireless, and features a Qwiic connector. This allows me to daisy-chain Arduino Modulino sensors with a single cable. I’m spending less time fighting with breadboards and more time imagining what the droid can actually do.

My current interaction stack includes:

Modulino Distance: The droid’s "social eyes."
Modulino Pixels: For visual "eye" expressions.
Modulino Buzzer: The droid’s "voice box."

Sound Engine

I didn't want my droid to sound like a microwave or a digital alarm. I wanted it to have a distinct personality. This led me into a deep dive on Granular Synthesis and Vibrato.

Instead of playing a static frequency, I wrote a sound engine that uses micro-slides in pitch. By rapidly oscillating the frequency with a sin() function and adding tiny 20ms gaps, the buzzer produces a "croaky," mechanical texture.

for (int i = 800; i < 1200; i += 20) {
  int vibrato = sin(millis() / 50.0) * 15; 
  buzzer.tone(i + vibrato, 20);           
  delay(15);                              
}

By starting a sound at a low 300Hz "croak" and sliding it up to a 900Hz "chirp," the droid goes from sounding like a telephone to sounding like it’s asking a question.

// An inquisitive chirp
for (int i = 300; i < 900; i += 10) {
  buzzer.tone(i, 15);
  delay(25); // The gap creates the mechanical "clicky" texture
}

To simulate active awareness when it isn't interacting, I used the same mathematical logic to create a pulse for its eyes. By mapping millis() to a sine wave, the LEDs oscillate in brightness smoothly rather than just staying on.

void idleBlink() {
  int b = (sin(millis() / 2000.0) * 15) + 20;
  pixels.set(0, 0, 100, 255, b);
  pixels.set(7, 0, 100, 255, b);
  pixels.show();
}

Bridging the Social Gap

The goal of this droid is to handle nudging my son that it's time for school in a way that is fun (not too much fun) but gets him engaged and aware of the time.

Currently, I’m using distance as the primary input. In the future, the droid will use vision to categorize what he's doing (e.g., "Is he wearing shoes yet?").

During testing, I discovered that if I set a single distance trigger, the droid "stutters" when my hand sits statically near the sensor. To fix this, I implemented a 250mm "buffer zone." The ESP32 greets you when you enter the 20cm range, but "locks" that interaction until you move past 45cm. Only then does it return to its idle stage (pulsing two blue LEDs).

Here's the ESP32 greeting:

And a nervous "red", I'm a bit too close:

What's Next?

I'm working on image recognition on the Raspberry Pi with the Google Mediapipe and OpenCV libraries to train a facial recognition model. Then the Pi will identify who is in the room, and the ESP32 will decide which personality profile to use in response.

I’d love to hear from you, how do you handle "personality" in your builds? Have you found a way to make simple buzzers sound more organic?

Willard’s First Flight (and Unplanned Disassembly)

Jennifer Davis — Sun, 18 Jan 2026 02:43:07 +0000

In my last post, I was teaching my droid project to "see" and "think" on a Raspberry Pi 5. But while waiting for my Build Hat, I discovered these car kits—a ready-made option to explore physical motion immediately.

Enter the Elegoo Smart Robot Car Kit v4.0, or as my son affectionately calls him, Willard.

The Physical Build

The assembly was surprisingly seamless. Elegoo helpfully provides the three screwdrivers you need, and the bags are neatly labeled. It felt very much like "IKEA instructions meet electronics."

However, I quickly hit a physical "hardware tax." Some of these components are so tiny that getting them into place is a challenge. Even worse, once I got the robot moving, the jerky default programming caused the whole chassis to vibrate. Within minutes, I had bolts and screws flying off the robot like it was undergoing unplanned disassembly! It took some time to figure out where the bits came off of, and I'm not sure if there is some recommended way to actually set this up so that bits don't come off.

Lesson learned: I’ve taken Willard’s wheels off for now. This lets me debug the logic safely on my desk without him shaking himself to pieces or driving off the desk.

The "Hidden" Software Gatekeepers

Even though it’s a kit, customizing your robot car isn't exactly "plug and play." I ran into two gatekeepers that weren't in the printed manual (but were discoverable in the many docs available in the downloadable zip file).

The Upload Toggle: The expansion hat has a tiny toggle switch. If it's set to "App" mode, you cannot upload code. You must flip it to "Upload" to talk to the Elegoo. It’s printed on the board, but so small you might miss it.
The Missing Driver: Due to chip shortages, different serial chips might be installed. My Arduino IDE didn't "see" the board until I hunted down the CH340 driver hidden in the tutorial zip file.

Pro-tip: I’ve switched to the Arduino CLI for faster feedback:
arduino-cli compile --fqbn arduino:avr:uno --libraries . smart-robot-car-firmware.ino

This gives me fast feedback if something needs to be fixed.

And, I need that feedback because I keep finding out new things. One of the most frustrating things to debug in hardware is the Restart Loop. Unlike a computer, where an app crashes and gives you an error, an Arduino often just restarts. Because it boots so quickly, it can look like it's just "ignoring" your code or behaving weirdly, when in reality, it’s crashing and rebooting every few seconds.

Every Byte counts

One of the weirdest hurdles was moving to the CLI. The code compiled fine in the IDE, but the CLI threw a "Sketch too big" error.

ETA: I might be misremembering this step as it might be that it was erroring due to the Global variable size. This is what my usage looks like now

Sketch uses 21166 bytes (65%) of program storage space. Maximum is 32256 bytes.                                           │
│ Global variables use 1208 bytes (58%) of dynamic memory, leaving 840 bytes for local variables. Maximum is 2048 bytes.

It turns out the original firmware was already redlining the Arduino Uno's 32KB limit. Adding even the "negligible" overhead of the Servo library was enough to push it over the edge. I wrote a Python script to see which symbols were eating my space.

import subprocess
# Runs avr-nm to sort symbols by size
nm_output = subprocess.check_output(['avr-nm', '-S', '--size-sort', '-C', elf_file])

This led me to refactor the logic into a non-blocking state machine, reducing the JsonDocument size from 200 to 128 bytes, and replacing sprintf with Serial.write to avoid pulling in heavy string-formatting libraries.

An Independent Eye

The most interesting discovery? The camera isn't connected to the Elegoo brain at all for this kit. It operates on its own IP address. This means for this robot car the "Reflex" layer (Elegoo board) is completely blind to what the camera sees. Even so, this Elegoo kit is incredibly comprehensive; having all the sensors and the camera in one package helps me visualize how much can actually fit into a consumer-level robot.

It also gave me a much-needed reality check on weight restrictions. I’ve been questioning how the Raspberry Pi and the Arduino, along with the LEGO structure, might impede movement. Watching Willard navigate has given me a baseline for how much mass the motors can handle before performance starts to drop. My eventual goal will be to bridge the reflex/cognition gap—having the Pi analyze the visual data and then send high-level commands to my droid's Arduino "muscles."

What's Next

Willard is currently on the operating table. I’m deep in the weeds debugging why his Guard Duty behavior is returning "Ghost States."

Take a look at this serial output:

Current Distance: 13
Current Distance: 12
Alarm triggered!
Guard Duty State: 3  <-- Ghost State Detected

State 3 doesn't exist. This is the classic signature of a Buffer Overflow. Something in Willard's memory is spilling over and rewriting his state variables in real-time.
Next time, we perform surgery to find the leak!

If you've built this car and made modifications or if you have suggestions for other ideas please respond in the comments. So far, I've come up with a "Guard" mode (detecting motion via proximity changes) and a "Dance" mode (multi-color lights and pre-programmed steps).

I'm also considering adding an Arduino Modulino Buzzer module. It uses I2C (Qwiic), which would keep the wiring clean and finally let Willard "speak" with custom tones and alerts.

Reflexes, Cognition, and Thought

Jennifer Davis — Wed, 07 Jan 2026 07:55:39 +0000

In my previous posts, I focused on sharing the basics—making LEDs blink and understanding wiring. Today’s adventure was about expanding on what my droid will actually need to function.

The droid will have a multi-layered "brain." I’ve been working on the Reflex Layer with the Arduino Uno for prototyping. In this post, I’ll review what I’ve learned there and explore the Cognition Layer using computer vision and local AI.

The Reflex Layer: Data Types & Geometry

Before the droid can walk, it has to have a way to traverse the world (or at least my home). I used the Arduino to test the "logic" of movement before ever plugging in a motor.

Visual Odometer

I built a Visual Odometer using 4 LEDs to represent 4 bits of a signed char. I wanted to visualize an "integer overflow." By starting the counter at 120 (near the 127 limit of a 1-byte signed integer), I could watch the moment the droid "lost its mind." As soon as it hit 128, the odometer flipped to -128.

Seeing the LEDs jump and the Serial Monitor report a negative distance was a tactile lesson: pick the right "storage box" (data type) for your sensors, or your droid will think it's traveling backward just because it reached a limit.

Simulating Motion with Light

Since I don’t have something that physically moves yet, I used a photoresistor (light sensor) to simulate "steps." Every time I flashed my phone light, the Arduino registered a movement. I also had the LED change color based on the light being detected so I could see really quickly whether my code was working.

I used the Pythagorean Theorem ($a^2 + b^2 = h^2$) to calculate the "as-the-crow-flies" distance from the starting point. Using the Serial Plotter, I could see the $X$ and $Y$ coordinates stair-stepping while the distance tracked a smooth, calculated curve.

#include <math.h>
// ... logic to detect light pulse ...
if (sensorValue < 400 && !triggered) { 
    xPos += 5; 
    yPos += 3; 
    // h = sqrt(x^2 + y^2)
    hypotenuse = sqrt(pow(xPos, 2) + pow(yPos, 2));
    triggered = true;
}

Adding Some Motion

At this point, I figured I could just add some hardware and experience the spinning of the motor based on the distance traveled. I was a bit surprised when I opened up the servos packaging and discovered that I didn't know what to do with them.

I unpacked the Arduino motor shield figuring it would be obvious where it would plug-in, but nope. While the shield was easily installed, the wiring wasn't straightforward.

I could not figure out where the wires on the Geek Servos were supposed to go.

I tried guessing the connection and successfully saw my LED light up, but there was no spinning motor.

Which is when I realized, that my servo was actually just a motor.

I also realized that I likely needed an external power source to support this hardware. I have other servos to try, but I really want these to work since they are LEGO-compatible. To keep the momentum, I decided to look at the second layer of the brain.

The Cognition Layer: Enter the Raspberry Pi 5

I set up my sparkly new Raspberry Pi 5 from a CanaKit. This is the "High-Functioning" brain. This kit was super easy and the video was very straightforward to follow—a great "intro to building a computer" kit. After a quick setup and package update, I dove straight into Edge AI.

Sidequest: The Screenshot Struggle I spent way too long trying to automate screenshots on the Pi for this blog. I learned the hard way that scrot only produces black screens on the new Pi OS (Wayland). After fighting with grim and slurp, I realized I'd figure that part out later. No screenshots for now!

"I See You"

I hooked up an ELP 2.0 Megapixel camera and installed Ollama to run a local Vision Language Model (openbmb/minicpm-v4.5). I wrote a Python script using OpenCV (cv2) to grab a frame and feed it to the model.

The Result: Success! The Pi analyzed the camera feed locally and described me and the room.

DROID SAYS: 
Observing: A human with glasses and purple attire occupies the center of an indoor space; 
ceiling fan whirs above while wall decor and doorframes frame background elements—a 
truly multifaceted environment!

It took about 3 minutes to process one frame. My droid currently has the processing speed of a very deep philosopher—it’s not going to win any races yet, but it is truly thinking about its surroundings.

The Vision Script (vision_test.py)

Here is the bridge between the camera and the AI:

import cv2
import ollama
import os
import time

def capture_and_analyze():
    # Initialize USB Camera
    cam = cv2.VideoCapture(0)

    if not cam.isOpened():
        print("Error: Could not access /dev/video0. Check USB connection.")
        return
    print("--- Droid Vision Active ---")

    # Warm-up: Skip a few frames so the auto-exposure adjusts
    for _ in range(5):
        cam.read()
        time.sleep(0.1)

    ret, frame = cam.read()

    if ret:
        img_path = 'droid_snapshot.jpg'
        cv2.imwrite(img_path, frame)
        print("Image captured! Sending to MiniCPM-V-4.5...")
        try:
            # Querying the local Ollama model
            response = ollama.chat(
                model='openbmb/minicpm-v:4.5',
                messages=[{
                    'role': 'user',
                    'content': 'Act as a helpful LEGO droid. Describe what you see in one short, robotic sentence.',
                    'images': [img_path]
                }]
            )
            print("\nDROID SAYS:", response['message']['content'])
        except Exception as e:
            print(f"Ollama Error: {e}")

        # Clean up the photo after analysis
        if os.path.exists(img_path):
            os.remove(img_path)
    else:
        print("Error: Could not grab a frame.")
    cam.release()

if __name__ == "__main__":
    capture_and_analyze()

What's Next

I'm going to figure out the motors, but for now, I'm going to focus on refining the Vision + AI pieces. I am going to try using the opencv-face-recognition library and experiment with different, smaller models to see if I can speed up that 3-minute "thought" process!

The RGB LED Sidequest 💡

Jennifer Davis — Mon, 05 Jan 2026 23:00:30 +0000

Welcome back to my journey From Dust to Droid Dreams. While the primary path to building a droid is a long-term mission, sometimes you have to take a sidequest to master the fundamentals of the "nervous system." Today’s mission: Multi-LED color blending and the hidden traps of Serial debugging.

I discovered that I had an RGB LED and decided that I would rewire the existing Red, Blue, and Green LEDs and keep the yellow LED as is. The goal was to create a smooth transition between Red, Green, and Blue using Pulse Width Modulation (PWM), dedicated Yellow LED that glows based on the overlap of the Red and Green channels.

The "Fiddly" Hardware

First lesson of the sidequest: The physical world is messy. I quickly learned that the RGB LED setup is super fiddly. Wires cross over easily, and it requires very careful application of the resistors to keep the signals clean and the components safe.

Encountering the "Lag" Monster

Once I got the LEDs in sync, I wanted to monitor the values changing in real time. This did not work the way I was expecting. Suddenly, the synchronization disappeared—the Yellow LED started stuttering and wouldn't come on at the right time.

Problematic Code:

void updateLEDs() {
  analogWrite(RED, redValue);
  analogWrite(GREEN, greenValue);
  analogWrite(BLUE, blueValue);

  // Serial output inside the main update loop
  Serial.print("R: "); Serial.print(redValue);
  Serial.print(" | G: "); Serial.print(greenValue);
  Serial.print(" | B: "); Serial.print(blueValue);
  Serial.print(" | Y-LED: "); Serial.print(yellowBright);
  // ... this was slowing everything down!
}

At the default 9600 baud, Serial communication is relatively slow. Every time the code reached these print statements, it paused the loop to send data. This created a "hiccup" in the PWM signal, making the LEDs flicker and the timing feel "off."

The Optimization Fix

To resolve the lag and reclaim that smooth fade, I applied two key fixes:

Baud Rate Boost: I increased the speed from 9600 to 115200 (updating it in both the code and the IDE configuration).
Timed Printing (Non-blocking): Instead of printing every single loop, I used a timer (millis()) to update the Serial output every 100ms. This keeps the processor focused on the LED pulses.

void updateLEDs() {
  analogWrite(RED, redValue);
  analogWrite(GREEN, greenValue);
  analogWrite(BLUE, blueValue);

  int yellowBright = (redValue < greenValue) ? redValue : greenValue;
  analogWrite(YELLOW, yellowBright);

  // Non-blocking timer: Only print every 100ms
  if (millis() - lastPrintTime > 100) {
    Serial.print("R:"); Serial.print(redValue);
    Serial.print(" G:"); Serial.print(greenValue);
    Serial.print(" B:"); Serial.print(blueValue);
    // Added a small offset (+5) so the yellow line is visible on the plotter
    Serial.print(" Y-LED:"); Serial.println(yellowBright + 5); 
    lastPrintTime = millis();
  }
}

New Tool Use Unlocked: The Serial Plotter

I also spent some time with the Arduino IDE's Serial Plotter (Tools > Serial Plotter). It’s a fantastic tool for visualizing how the color variables oscillate in waves.

I had to go through a few iterations to get the yellow line to show up properly. Because the values were identical to the Red or Green lines, they were hidden behind them. Adding a small offset (+5) to the print statement finally made the yellow line visible!

A minor mystery: I haven't figured out how to get the line colors in the plotter to actually match the RGB colors I'm outputting. The IDE seems to assign them automatically based on the order of the variables. If anyone has a hack for this, please let me know in the comments! Even without matching colors, seeing the waves overlap in real-time is a huge help for debugging the logic.

Key Takeaways for the Droid Build

Communication Overhead: Consider how much "talking" your microcontroller is doing—it might be slowing down its "thinking."
Visualization over Text: Data is much easier to digest as a wave than as a wall of scrolling numbers.
Timing is Everything: Don't just default to delay. millis() allows for multi-tasking, whereas delay() essentially puts the Arduino Uno to sleep.

Four Sketches and a Rewire: The Path to Droid Brains

Jennifer Davis — Mon, 05 Jan 2026 04:27:14 +0000

In my last post, I was staring at a dark LED, wondering if my 16-year-old hardware was faulty or if I was failing to understand something fundamental. I’ll admit, I struggled with the introductory ELEC 2200 curriculum back at Auburn University (though that may have had more to do with the class being at 8:00 AM after working until 1:00 AM at Taco Bell).

The good news? I found working hardware by switching up the breadboard. The better news? I’ve officially moved past the "Blink" stage and into logic. I’m sharing my progress via a new open-source project: uno-sketch-box.

Pivoting to the "Serial" Heartbeat

Before I found my breakthrough with the physical LEDs, I decided not to let the hardware block me. I jumped ahead to Lesson 4. If the droid's "eyes" (the LEDs) weren't working yet, I wanted to see if its "voice" was intact.

By using the Serial library, I established a "Hello World" heartbeat between the Arduino and my Mac. Seeing that text scroll across the Serial Monitor confirmed that my Arduino had a voice and was ready to communicate.

Crossing the Rev 3 Bridge

While troubleshooting my initial Ladyada kit, I realized I actually had a second "time capsule" on my shelf: the "Emerging Objects" kit from Sparklelabs.

Sadly, the Sparklelabs tutorial has vanished from the web, but the hardware provided was exactly what I needed: a more modern Arduino Uno Rev 3 (identifiable by the red reset button moved to the top left) and a full-sized 830-point breadboard with power rails.

The "Everything is Blinking" Bug

With the better breadboard, the mystery of the dark LED was solved. I finally had a blinking circuit! However, as soon as I tried to scale up to an LED Scanner (think Knight Rider), I hit my first logic bug. I had several LEDs hooked up, but instead of a smooth back-and-forth scan, every single LED was blinking in unison.

The culprit was a physical wiring error that ignored the board's architecture. By moving the power and ground connections to a more stable configuration on the new rails, I was able to see the scanning pattern between the blue and green LEDs—but the red LED stayed dark.

It turns out I was using Pin 13, which is tied to the onboard "L" LED. By moving the jumper cable for the red LED to Pin 8, I finally achieved discrete control. I brainstormed other things that I could try out without moving any physical hardware wiring and decided I would share my adventures so others could try this out as well.

Open Sourcing the Journey: The Uno Sketch Box

I’ve officially open-sourced my learning progress in a new repository: uno-sketch-box. Instead of just following the lessons linearly, I’ve added four projects that serve as building blocks for the droid's future "brain":

LED Scanner: A study in for loops and multi-output management.
Police Strobe: An exercise in timing and alternating state patterns.
Binary Counter: A brain-bender that visualizes numbers in binary using 4 LEDs—because droid logic is all 1s and 0s.
Random Winner Picker: Introducing the random() function for a bit of unpredictable personality.

Automation & Clean Code

I didn't want to leave the code messy, and I wanted a way for others to contribute. I’ve set up GitHub Actions to lint my sketches and ensure they compile correctly on every push. It feels good to bring modern CI practices to this project.

What’s Next? "Input"

I’ve got the LED "Output" figured out with making lights dance. Now, I need to teach the droid to take some input. My Sparklelabs kit has some buttons, and I’m planning to tackle the following:

Visualizing Math & Data Types: Extending on the Lady Ada Lesson 4, Building a "Position Tracker" using the Pythagorean theorem ($a^2 + b^2 = h^2$) to calculate distance traveled, displayed over Serial.
The Odometer Challenge: Testing variable overflows—watching a number jump from 32,767 to -32,768—to ensure I pick the right "storage boxes" (int vs long) for droid sensors.
Interactive Logic: Using a physical button to trigger an LED pattern or reset the binary counter.

Before I move on, I’m polishing the visuals by swapping a green LED for a yellow one and possibly adding a white one.

I’d love to hear your thoughts:

What other LED-related logic projects should I try?
Any creative ideas for projects that combine these multi-LED patterns with button inputs?

Relearning the Arduino

Jennifer Davis — Sun, 04 Jan 2026 01:01:06 +0000

I have a goal: I want to build a real, functional LEGO droid.

It’s an ambitious project involving modern sensors, servos, and logic. But instead of jumping straight into the deep end with expensive new kits, I decided to start with a "time capsule" I’ve had on my shelf since 2010.

I’m dusting off an original Arduino Starter Pack.

My plan is to learn the hardware incrementally, starting with the basics I already own before graduating to trying to build a droid.

The "Lady Ada" Time Machine

The box is labeled ladyada.net/learn/arduino. It’s a trip down memory lane. While that URL still works, the experience today is a bit of a scavenger hunt. The old tutorials are still there, but they often point to newer versions of the site, making the lessons feel a little disjointed.

I wasn't even sure if a board this old would talk to a computer from 2026.

The Modern Mac Roadblock

Hardware might be timeless, but software architecture moves fast. When I tried to upload the classic "Blink" sketch from Lesson 1, my Mac threw a fit:

.../bin/avr-g++: bad CPU type in executable

My M-series Mac chip didn't know how to handle the older Intel-based instructions in the Arduino compiler.

💡 The Fix: If you see this error, your Mac needs to translate older Intel code. Open your Terminal and run:
/usr/sbin/softwareupdate --install-rosetta --agree-to-license

Small Wins, Big Goals

Once Rosetta was in place, the "Blink" sketch compiled perfectly:

Sketch uses 924 bytes (2%) of program storage space. Global variables use 9 bytes (0%) of dynamic memory.

Watching that LED blink for the first time (even if it's a decade late) feels like a win. It’s a small step—just a single light—but it’s the first milestone on the road to a LEGO droid.

Now that the "Blink" sketch works, I’ve moved on to Lesson 3, which introduces the breadboard and external LEDs. This is where the 16-year gap becomes a bit of a headache.

The tutorial images show an older Arduino shield setup that doesn't quite match my Uno and tiny breadboard. I’m currently stuck in "debug mode" with my wiring.

The Breadboard Mystery: Why won't my LED light up?

The Mental Model

In theory, the circuit is a simple loop. Current flows from High (5V) to Low (GND). Along the way, it must pass through the Resistor (to limit current) and the LED (to create light).

The Setup Challenge

I've been experimenting with two configurations, but neither has worked yet:

Option A: 5V → Resistor → Anode (Long Leg) → LED → Cathode (Short Leg) → GND.
Option B: 5V → Anode (Long Leg) → LED → Cathode (Short Leg) → Resistor → GND.

So far, the Uno powers up fine, but my external LED is staying stubbornly dark.

Seeking Your "Droid-Tech" Wisdom

I’m going to keep plugging away and swapping wires, but if any of you have experience with these vintage kits or the specific Lady Ada Lesson 3 layout, I’d love some advice!

Is there a common mistake with these tiny breadboards? I'm determined to solve this before I even think about LEGO motors!

ETA - Success

I switched out the tiny breadboard for a breadboard with rails (another incomplete kit hah!), and wired it up with Option A and that works! I also switched over to the more modern Uno from the other kit(I can tell as the reset button is in a slightly different place) but I'm sure the wiring would just work with the older version as well.

Systems, Leadership, and the Power of 'We'

Jennifer Davis — Sat, 03 Jan 2026 01:47:36 +0000

My career has been defined by "hard things"—from building a noSQL service platform at Yahoo to writing Modern System Administration. Over two decades in the trenches of systems engineering, I’ve learned a vital truth: the secret to tackling complexity isn't just technical expertise; it's the strength of the community around you.

I recently visited Nirvana Soul in San Francisco and was struck by the reminder on their wall: "We Can Do Hard Things."

As an Engineering Manager, I often reflect on how we challenge our teams to reach their full potential without hitting a breaking point. We can do hard things—whether that’s improving operability or overhauling legacy infrastructure—but we can only do them consistently if we build a sustainable foundation.

To me, "doing hard things" in 2026 means:

Fostering Community: Encouraging a culture of experimentation where it is safe to fail, learn, and iterate.
Prioritizing Reliability: Moving beyond "firefighting" mode to build systems that allow for deep work and innovation.
Leading with Empathy: Ensuring the people building the systems are as well-cared for as the systems themselves.

Systems are hard. Leadership is hard. Community building is hard. But the "We" is what makes it possible.

Let’s celebrate your wins

What is one "hard thing" you tackled in the last year that you’re proud of? I’d love to hear about the people or communities that helped you get across the finish line. Let’s start the year celebrating our wins in the comments!

Adventures in System Seeing Day 1

Jennifer Davis — Tue, 02 Dec 2025 05:44:40 +0000

We often think we understand the systems we interact with every day. If you ride a bicycle, you know how it works. But do you?

Join the Advent of System Seeing and follow along with the prompts

To kick off December, my family and I joined Ruth Malan’s "Advent of System Seeing." The Day 1 prompt sounds deceptively simple: Draw a bicycle. The goal isn't art; it is a warm-up exercise for your brain. It forces you to take your fuzzy mental models and make them concrete on paper. When we sat down to do this—covering bubble diagrams, memory sketches, and reflection—we quickly realized that "the system" looked completely different to each of us.

⚙️ The Bubble Diagram

The first part of the prompt asks for a bubble diagram to show key concepts and relationships.

This was where my brain went immediately. My drawing was a network of functional parts, for example, frame, gears, seat, and shock absorbers. My husband, Brian, pointed out that this was a distinct "engineering mind" view. I was defining the system by its internal architecture.

However, even my "engineering" view had gaps. As I described what I was attempting to draw, for example the complex braking systems, Brian noted, "Most bikes don't have complex brakes. Frankie's doesn't have calipers or cantilevers". I was drawing my bike and it's important to make that distinction as there isn't just one perfect bike.

🚴 Sketching from Memory

The next step is to sketch a bicycle from memory without looking at one. This is where the illusion of explanatory depth usually collapses.

Brian struggled to draw the bike in isolation. For him, the system was incomplete without its environment. He eventually drew a rider—a figure resembling Abraham Lincoln—and a cat in a basket. He realized that it was actually easier to draw the mechanics once he placed a human in the center.

This mirrors a reflection from Sebastian Hans, another participant in the challenge: "The system only works at all in connection with its environment. Without the ground, the bicycle doesn't move." Brian couldn't see the system until he saw the relationship between the machine and the user.

🚀 The Visionary Gap

Then there was our son, Frankie. While the prompt asks us to notice what is there, Frankie focused on what should be there.

His mental model of a "functional bike" included rocket launchers and a puppy (heavily influenced by the block style art of Minecraft). His default starting point was actually a tricycle. This sparked a real debate about the boundaries of the system—specifically, does a tricycle count when drawing a bicycle? It was a reminder that users often bring expectations to a system that the designers never anticipated.

💡 Why Mental Models Matter

Ruth Malan sums up the purpose of this exercise: "Our mental models are incomplete, but we don't know this until we really engage with them."

We assume we know how the parts connect. We assume we know what the user needs. But when we are forced to draw it out, we see the gaps.

I saw the mechanical structure.
Brian saw the human relationship.
Frankie saw the potential features.

None of us were wrong, but none of us had the full picture alone. To build better systems, we have to stop assuming our mental model is the only one that matters. We have to pick up a pencil, draw, share our drawing, and then see what everyone else is drawing.

Join us

You can join the "System Seeing" practice yourself. It only takes 15-20 minutes.

Visit the prompt: Go to Ruth Malan’s Day 1 page.
Don't skip the bubble diagram: It reveals how you structure relationships in your head.
Compare notes: Share your drawing (or a link to your drawing) in the comments and let's talk about it! The differences in the drawings are more valuable than the drawings themselves.

The lumberjack paradox: From theory to practice

Jennifer Davis — Wed, 19 Nov 2025 00:42:14 +0000

Previously, I shared my thoughts on Neal Sample’s "lumberjack paradox" and the urgent need to build the systems thinkers of tomorrow. I argued that leaders must move beyond simple efficiency and focus on re-engineering the experience (Dr. Gary Klein) and creating context to ensure we don't lose the path to deep expertise.

But what does "leadership as context creator" look like in practice?

For us in Cloud DevRel Engineering, it isn't abstract. It comes down to how we manage the most fundamental unit of our developer experience: the code sample.

As Neal notes, AI will lead to the "industrialization of creativity"—an infinite supply of ideas and code. In this world, the premium shifts to discernment: the ability to distinguish the quality from the mediocre.

But this isn't a choice between the axe (manual craft) and the chainsaw (AI). The modern expert needs both.

If you only have the axe, you are restricted to the problems that fit within manual reach. It is the perfect tool for the campsite, but it cannot clear the forest.
But if you only have the chainsaw, without the judgment to guide it, you are dangerous. You lack the control to distinguish a clean cut from a destructive one.

You need the deep expertise of the axe to get the precise, consistent outcomes from the chainsaw.

From theory to practice: The catalog as ground truth

In my previous post, I mentioned Dr. Richard Cook's work on "building common ground" and Donella Meadows’ warnings about suboptimization.

In Cloud DevRel Engineering, we realized that our code samples are the primary tool for building this common ground. In Dr. Cook’s terms, they form the "Line of Representation"—the tangible surface that connects the human "above the line" to the complex system "below the line."

When a developer (the human) learns a new platform, the sample is their manual for the "axe." When an AI assistant generates a solution, the sample is the training data that guides the "chainsaw."

When we looked at our systems, we saw suboptimization. By treating samples as low-priority content maintained by individual contributors, we created a fractured reality.

We broke the Line of Representation.

We saw this failure hit on two fronts:

We break the human judgment loop: If samples are inconsistent, developers cannot learn "good" from "bad." We fail to re-engineer the experience (Dr. Klein) necessary to build expertise.
We poison the AI well: AI models ingest our official repositories. The AI learns them, scales them, and feeds them back to the user.

We are currently witnessing exactly how this hand-crafted approach fails at scale.

The high cost of "geological strata" in code

Without central standardization, our repositories accumulated "geological strata"—layers of outdated practices—because manual maintenance cannot keep up with language evolution. This makes it hard to know what is correct today.

Node.js' paradigm tax: Our Node.js repositories contain a mix of callbacks, raw promises, and async/await. A user learning Pub/Sub sees one era, while a user learning Cloud Storage sees another. The AI sees all of it and treats it all as valid, stripping away the context of "outdated" versus "modern."
Python: The contributor long tail: With over 650 contributors, our Python samples suffer from extreme fragmentation. The total cost of ownership (TCO) of manually bringing thousands of older snippets up to modern Python 3.10+ standards is astronomically high, so it simply doesn't happen. This leaves a massive surface area of "technical debt" that the AI happily recycles.

Inconsistent quality creates "false best practices"

When samples are hand-written by federated teams, personal "developer flair" masquerades as industry best practice. Users copy-paste these patterns, inadvertently adopting technical debt.

Java's Framework creep: Instead of teaching the core platform, contributors often introduce heavy frameworks for simple tasks. This increases the "time-to-hello-world" and teaches the AI that simple tasks require complex dependencies.
Python vs. Go: Most Go samples handle errors correctly because the language forces it. Many Python samples show only the "happy path," skipping critical distributed systems patterns like exponential backoff or retry logic. The AI then generates code that looks clean but fails in production.

The hidden cost of incoherence

This is the "suboptimization" Donella Meadows warned about. It is not enough for individual samples to be correct in isolation; they must function as a cohesive unit.

For a human developer, shifting between products that use different coding styles creates friction. They have to spend mental energy decoding the "dialect" of a specific product team rather than focusing on the logic.

For an AI, this lack of cohesion is even more dangerous.

The Context Gap: When our samples for Cloud Storage look structurally different from our samples for BigQuery, the AI treats them as unrelated entities. It fails to learn the underlying "grammar" of our platform.
The Integration Failure: When a user asks for a solution that combines these products, the AI struggles to bridge the gap. Lacking a consistent pattern to follow, it often hallucinates a messy, "glue code" solution that is brittle and insecure.

By allowing fragmentation, we aren't just impacting the docs; we are training the AI to misunderstand how our platform is supposed to fit together.

Get started

We cannot view code samples as static documentation. They are the active constraints of our system—the "environment" we design for our users. If we fail to maintain them, we dull the tools that build developer judgment, and we degrade the quality of the AI they trust.

Coming up next

Next in this series, I will share our structural solution: the "Golden Path." This approach moves us away from isolated automation and towards a human-led, AI-scaled system that improves consistency.

I’ll be focusing more on the strategy in this series, but the execution is its own journey. Using AI to write code is well-known, but relying on it to produce production-ready educational content? Adam Ross, and Nim Jayawardena have shared the technical reality of our team's shift in a post on their 7 takeaways from generating samples at scale with Gemini.

Until then, ask yourself:

Are you trying to automate away your documentation debt without first defining a standard of quality?
Are your samples strong enough to serve as the "ground truth" for the AI models your developers rely on?

Special thanks to Katie McLaughlin, Adam Ross, and Nim Jayawardena for reviewing early drafts of this post.

How do you translate Cloud Computing?

Jennifer Davis — Thu, 12 Jun 2025 03:04:41 +0000

I was reading a web page in español and saw the term "en la computación en la nube" (the translation for cloud computing) and that gave me pause. Is there a shorter version to communicate the concept of hosted/managed compute? How do you convey cloud computing in your primary language? I'm curious as my primary language is English and I'd never considered it before.

It would be great to know the words used and the approximate meaning of those words.

I think "en la computación en la nube" translates to "computing in the cloud" but it might actually have a different meaning contextually that I'm not aware of.

Thanks in advance!

TIL - April 25, 2025

Jennifer Davis — Sat, 26 Apr 2025 05:31:24 +0000

By default, Google Cloud Pub/Sub Push Subscriptions deliver a message to a push endpoint as a Wrapped message in the following (abbrievated) format

{
    "message": {
        "data": string,
        "messageId": string,
        "message_id": string,
        "publishTime": string,
        "publish_time": string
    },
    "subscription": string
}

This is hidden in the Push Subscription documentation and not surfaced in the PubsubMessage reference documentation which shows the following format:

{
  "data": string,
  "attributes": {
    string: string,
    ...
  },
  "messageId": string,
  "publishTime": string,
  "orderingKey": string
}

I haven't verified, but I suspect that the configuration for choosing unwrapped messages is to Enable payload unwrapping

Have you used Cloud Run with Pub/Sub and ran into this? Let me know in the comments.

DEV Community: Jennifer Davis

Why your `curl` logic just bit you 🐾

🤫 Authenticate for local development

🏡 Moving to Production

Get started

Giving my droid a personality with ESP32 and Arduino Modulino sensors

The Hardware Pivot: SparkFun & Qwiic

Sound Engine

Bridging the Social Gap

What's Next?

Willard’s First Flight (and Unplanned Disassembly)

The Physical Build

The "Hidden" Software Gatekeepers

Every Byte counts

An Independent Eye

What's Next

Reflexes, Cognition, and Thought

The Reflex Layer: Data Types & Geometry

Visual Odometer

Simulating Motion with Light

Adding Some Motion

The Cognition Layer: Enter the Raspberry Pi 5

"I See You"

The Vision Script (vision_test.py)

What's Next

The RGB LED Sidequest 💡

The "Fiddly" Hardware

Encountering the "Lag" Monster

Problematic Code:

The Optimization Fix

New Tool Use Unlocked: The Serial Plotter

Key Takeaways for the Droid Build

Four Sketches and a Rewire: The Path to Droid Brains

Pivoting to the "Serial" Heartbeat

Crossing the Rev 3 Bridge

The "Everything is Blinking" Bug

Open Sourcing the Journey: The Uno Sketch Box

Automation & Clean Code

What’s Next? "Input"

Relearning the Arduino

The "Lady Ada" Time Machine

The Modern Mac Roadblock

Small Wins, Big Goals

The Breadboard Mystery: Why won't my LED light up?

The Mental Model

The Setup Challenge

Seeking Your "Droid-Tech" Wisdom

ETA - Success

Systems, Leadership, and the Power of 'We'

Let’s celebrate your wins

Adventures in System Seeing Day 1

⚙️ The Bubble Diagram

🚴 Sketching from Memory

🚀 The Visionary Gap

💡 Why Mental Models Matter

Join us

The lumberjack paradox: From theory to practice

From theory to practice: The catalog as ground truth

The high cost of "geological strata" in code

Inconsistent quality creates "false best practices"

The hidden cost of incoherence

Get started

Recommended Reading

Coming up next

How do you translate Cloud Computing?

TIL - April 25, 2025