A couple of weeks ago, I was hiking the DeCaLiBron loop, and I noticed afterwards that none of my heart rate data was tracked! The green heart rate monitoring LEDs wouldn’t even turn on until I reset the watch. I don’t totally fault Garmin for this — like I mentioned, it is an old device. Nevertheless, I decided it was time I found a replacement.

My go-to replacement for this tracker would be a vivosmart 6… if such a device existed. For some reason, Garmin (as of Aug. 12, 2026) has not released or announced a successor to the vivosmart 5. Anyways, the point of this discussion is that without an obvious replacement for my existing watch, I needed to do some market research to discover my options.

Choosing a fitness tracker can be a bit overwhelming due to the number of options: full-size smart watches (e.g., Apple Watch, Pixel Watch, Garmin fenix, etc.), fitness trackers with screens (vivosmart 5, Fitbit Charge 6, etc.), and trackers without screens (WHOOP, Fitbit Air, etc.). Years back, when I bought my vivosmart 5, the idea of going screenless seemed very unappealing. However, I’ve learned to love & hate the vivosmart’s screen. For all of the convenience that screens offer, running water can inadvertently manipulate the touch screen and trigger unwanted behavior, notifications can be intrusive at inconvenient times (I know, I know, I should just remember to turn on “Do Not Disturb”), you have to worry about the screen getting damaged, and the display adds to the overall cost/weight/size of the product.

So, after experiencing all of the pros/cons of a display, I was open to the idea of a screenless tracker. I looked through several options, but the two that appealed most were the Fitbit Air and Garmin CIRQA. The CIRQA appealed to me as it would allow me to stay within the Garmin ecosystem, but without any compelling feature differences over the Fitbit Air (at least for my personal use-case), the 2x price tag was difficult to justify. And so I ordered a Fitbit Air. (Side note: although Garmins and Fitbits are similar in many ways, the corresponding ecosystems place different emphases on health, wellness, and athletics. Depending on your personal motivations for wearing such a device, one may appeal much more strongly than the other.)

After a week of daily use, I have no complaints or regrets. (Well, actually I have one minor complaint if you skip to the end.) I almost miss being able to check the time on my wrist, but I switched my phone to screen-always-on-mode (“screen-on” except when the proximity sensor is covered), and I simply leverage my phone more. The screen of the vivosmart is tap-to-wake, so checking the time was never “instantaneous”, anyways. There are printable adapters for attaching the Air pebble to a regular wrist watch, but for now I’m enjoying the OEM strap. Google has actually facilitated the design of these custom adapters by releasing CAD drawings and design guidelines. Kudos to Google!

Although I haven’t done a detailed analysis of the Air’s accuracy (step count, heart rate, etc.), the numbers I get are very similar to what I was used to seeing on my vivosmart. And I know this is very anecdotal / unscientific of me, but there are plenty of quantitative assessments available online for those who are interested (maybe I’ll do my own “study” in the future…).

All of the above being said, here is what I like the most: the Air is extremely comfortable and lightweight. The Air is like… well, air! Of every wrist-device I’ve worn, it is by far the easiest to put on and forget about. It does everything I want it to do, it looks nice, and it feels great. What more can you ask for? Additionally, I have a mild nickel-allergy that prevents me from wearing many wrist-based products. I was a bit worried about the stainless steel component on the Air’s strap, but so far I haven’t had any issues with it. The black finish on my obsidian-style band may provide an effective skin/metal barrier, and it helps that the stainless steel loop doesn’t directly contact skin (at least for how I wear the strap). Though the two charging contacts may also contain nickel (I couldn’t confirm this), they don’t contact skin either.

One final aspect I’ve really enjoyed is using the Google Health Android app. The Garmin app is not bad, but it doesn’t come with a widget or as much customizability. I do wish the Google Health widget or the Google battery widget would let me see the Air’s battery % (as is the case with the Pixel Buds, from what I’ve seen). As of now, this has been my only true complaint, and I’m hoping this is addressed in a future software update.

Anyways, if you’re considering the Air, I hope I’ve given you something helpful to think about. And whether you get a Garmin, Fitbit, or Apple, the most important thing is to stay active and healthy. :)

When working with DICOM images, I often just need something fast and lightweight: a way to quickly open a specific image (or a small group of images) and move on. I also don’t want extra UI elements taking up screen space. That’s why I built Perspecta.

Perspecta is open-source and MIT-licensed. If you’d like to try it or contribute, you can find the GitHub repository.

Feedback is welcome!

When I’m not fishing with a lure, I like to use a tungsten slip sinker, which is nice for a couple of reasons:

1. Traditional lead sinkers are potentially bad for the environment and bad for you.
2. Tungsten has a higher density than lead ($19.3 g/cm^{3}$ versus $11.3 g/cm^{3}$), arguably making it better sinker material. The primary disadvantage is that tungsten is more expensive than lead (something like ~18x the cost). Thankfully, you don’t need much tungsten to make a good sinker. In my case, I generally use sinkers that weigh under 1 ounce.

Anyways, there’s a component known as a sinker bumper (AKA a ‘shock spacer’ or ‘knot protector’) which sits in between your slide sinker and any knot on your line. The bumper protects your knot from the sinker as it moves along the line. Since the bumper is a simple plastic bead, I thought it’d be a perfect application for my 3D printer.

However, simple searches on Thingiverse and Printables turned up nothing. I’m sure I could have found something (after all, the bumper is just a plastic bead), but I thought I’d design one myself, just for fun. And to make things more interesting, I thought I’d use ChatGPT to create the design.

So my prompt to ChatGPT was:

Write me an OpenSCAD script to generate a sinker bumper.

For which ChatGPT provided this script:

// Sinker Bumper Parameters
$fn = 100; // Increase for smoother circles
outer_diameter = 10; // Outer diameter of the bumper in mm
inner_diameter = 5;  // Inner diameter of the hole in mm
height = 5;          // Height of the bumper in mm

// Sinker Bumper Model
difference() {
    cylinder(h = height, r = outer_diameter / 2, center = true);
    cylinder(h = height + 2, r = inner_diameter / 2, center = true);
}

// Render the Model
translate([0, 0, 0])
difference();

Not bad!

Though I only specified ‘sinker bumper’, ChatGPT generated something with the correct shape and approximately correct dimensions.

The inner diameter is most problematic: 5 millimeters is too big. Instead, I used an outer diameter of 5 millimeters and an inner diameter of 2 millimeters.

After pasting the script into OpenSCAD, here’s what the design looked like:

So, I exported the model as an STL file, converted it into G-code using Cura, and kicked off the print using my Ender-3 Neo.

And here’s how the bumper looks in between a swivel and a sinker:

Though I used PLA for this print, TPU is more elastic and would provide better cushioning. Also, I used 100% fill, so the bumper should sink by itself. But the bumper (or any PLA object) should start to float at around ~80% fill.

If you’re interested, you can download the STL file here.

And this led to a conversation that sparked an idea:

Set up a private chat AI, reachable via Signal messaging.

A few Bash & Python scripts later, our system was up and running.

And we’ve been having a lot of fun with it.

I think others will also enjoy this, so I’m sharing a public repository for the Private AI Project.

Reasons to self-host a chat AI:

• Keep your chat history 100% private.

• Message your AI with end-to-end encryption.

• Stop paying for monthly subscriptions.

Contributors welcome!

See the project here.

I don’t think I can adequately cover the last 5+ years in this short post, but I will say that it has been quite an adventure.

It’s been a road with many challenges yet also many successes.

A pivotal milestone was the creation of MedCognetics, bringing together a team passionate about transforming healthcare and women’s health.

And today, I’m pleased to share this team’s latest milestone of FDA clearance for our breast cancer screening service.

I also want to recognize those who made this milestone possible: not only the fantastic team at MedCognetics, but also some incredible individuals at UTDallas, our partners at UTSW, and many others.

It’s been an absolute honor to work alongside and build relationships with these people.

Thank you, everyone. I look forward to what we can accomplish in the next five years.

The food I ate and the places I saw were unforgettable. Pictures do no justice, particularly for the Taj Mahal.

Visiting the Taj Mahal is the experience of observing, approaching, and finally stepping into a painting. To explore it means to feel as though you’ve entered into another’s imagination.

However, my favorite part wasn’t experiencing the food and the places.

The best part was the people.

The absolute highlights of my trip are the incredible hospitality, sharing of stories, and laughing with others.

Seeing the world is fantastic. But my favorite thing about traveling is the reminder that no matter where you find yourself on Earth, you’ll find people, just like you and me, running this race called life. We have so much in common, despite our differences.

Thank you, India. I look forward to returning someday.

Here’s a link to a book trailer which was straightforward to create. Since my books are compiled with a Python-based framework, changing the compilation process to produce a video file instead of a book PDF was just a few dozen lines of code.

If you’re interesting in getting a copy of the book, please check out the listing here.

Also, if you’ve enjoyed Data Science for Babies, please consider leaving a positive review on Amazon and letting others know what you think!

Some mornings around 7am, Silas stumbles into my office, still half asleep, and asks,

“Dad, did you write another cookie book?”

A moment passes as I finish typing out a line of code, and I usually answer something like,

“No, Buddy, not today.”

However, recently I was able to say, “Yup, a draft is ready! Can you read it and make suggestions?” and then see a smile pop onto his face.

A few revisions later, following lots of good feedback from Silas and Maribeth, I’m happy to release “Entrepreneurship for Young Minds”, a book about entrepreneurship for young kids, as the name suggests.

Although it’s hard to capture all aspects of entrepreneurship in a small number of pages, I’ve drawn from a few themes which I think are important:

• Looking for solutions to problems
• Persevering in the midst of failure
• Avoiding complacency
• Dreaming big

As with my previous books, I’ve written the story to be both educational and fun, and I hope it will inspire future entrepreneurs and young minds who will grow up to change the world.

Please check it out here, and feel free to let me know your thoughts if you do.

Background

The LZSS code I’m presenting here is based on this GitHub project, but I’ve created my own fork with some improvements and optimizations.

For some background on LZSS, Wikipedia has a pretty good description.

The remainder of this post will walk through an implementation of compression followed by decompression.

Compression

Overview

The main function for compression is fairly short:

def compress(data: bytes) -> bytes:
    output_buffer = bitarray(endian="big")
    output_buffer.fromlist = lambda x: output_buffer.frombytes(bytes(x))

    i = 0
    while i < len(data):
        if match := find_longest_match(data, i):
            match_distance, match_length = match
            output_buffer.append(IS_MATCH_BIT)
            dist_hi, dist_lo = match_distance >> 4, (match_distance) & 0xF
            output_buffer.fromlist([dist_hi, (dist_lo << 4) | (match_length - LENGTH_OFFSET)])
            i += match_length
        else:
            output_buffer.append(not IS_MATCH_BIT)
            output_buffer.fromlist([data[i]])
            i += 1

    output_buffer.fill()  # Pad to complete last byte
    return output_buffer.tobytes()

This function takes in a bytes object of uncompressed bytes and returns a bytes object of compressed bytes. To understand how this code works, we’ll walk through a few compression examples.

Example 1

For our first compression example, we’ll compress the bytes object b"zzzzz".

On the first iteration of our loop while i < len(data):, find_longest_match(data, i) will return None because we’re looking at the first byte in our raw data and there are no previous bytes to match against. We’ll walk through find_longest_match in more detail later. So, we append a single bit, 0, followed by the byte b"z" (IS_MATCH_BIT is a bool set to True).

On the second loop iteration, things are a bit more interesting. Since our next 4 bytes b"zzzz" share a common value with our first byte b"z", find_longest_match will return a non-None Tuple containing a match_distance equal to 1 and match_length equal to 4.

Let’s discuss what these values mean. match_distance equal to 1 means that we found a match which is just one previous position away from our current position. match_length equal to 4 means that we matched 4 bytes. In this case, it means that our match of b"z" is repeated 4 times.

Since we successfully found a match, we append a single bit value of 1, IS_MATCH_BIT, followed by values for match_distance and match_length packed into 16 bits (12 bits for match_distance and 4 bits for match_length).

Overall, b"zzzzz" gets packed into 9 bits + 17 bits == 26 bits! Since we pad our bytes object with output_buffer.fill(), our final output is 4 bytes, compressed down from 5 bytes.

Example 2

For our second example, we’ll use a set of bytes which are a little bit more interesting, b"wxyzwxy (although still pretty boring, I know).

For the first 4 bytes, b"w", b"x", b"y", and b"z", find_longest_match returns None for each byte, so we pack these 4 bytes into a total of 4 * 9 bits == 36 bits.

For our next byte, w, find_longest_match returns match_distance of 4 and match_length of 3. Thus, the remaining bytes b"wxy" are compressed to 17 bits. Overall, b"wxyzwxy compresses down to 36 + 17 == 53 bits, down from 56 bits (not a significant change, but hang on for the next example).

Example 3

For this 3rd and final example, let’s suppose our bytes object is b"wxyzwxyzwxy".

As with the previous example, the first 4 bytes will require a total of 36 bits to store. However, the remaining b"wxyzwxy" will be summarized with a match_distance of 4 and match_length of 7 such that our entire bytes object compresses down to 56 bits from 88!

Find longest match

Based on the previous 3 examples, you probably have an idea of what find_longest_match is doing, and now we’ll walk through specifics of how it actually works. Below is its code:

def find_longest_match(data: bytes, current_position: int) -> Optional[Tuple[int, int]]:
    end_of_buffer = min(current_position + MATCH_LENGTH_MASK + LENGTH_OFFSET, len(data))
    search_start = max(0, current_position - WINDOW_SIZE)

    for match_candidate_end in range(end_of_buffer, current_position + LENGTH_OFFSET + 1, -1):
        match_candidate = data[current_position:match_candidate_end]
        for search_position in range(search_start, current_position):
            if match_candidate == get_wrapped_slice(data[search_position:current_position], len(match_candidate)):
                return current_position - search_position, len(match_candidate)

The outer loop of this function, for match_candidate_end in ..., is used to create match candidates, starting with the longest possible candidate and shrinking the candidate length by 1 after every iteration.

For example, if we are working with input data b"ghxyz", and current_position is 1, corresponding to b"h", our first value for match_candidate will be b"hxyz. Since our match search starts and ends with b"g", a match won’t be found and our next match_candidate will be b"hxy.

The inner loop of this function, for search_position in ..., checks to see if match_candidate is identical to any previous byte sequences. The function get_wrapped_slice allows us to find matches where the search sequence is actually shorter than match_candidate as we saw in the first compression example involving b"zzzzz". The code for get_wrapped_slice can be seen here:

def get_wrapped_slice(x: bytes, num_bytes: int) -> bytes:
    """
    Examples:
        f(b"1234567", 5) -> b"12345"
        f(b"123", 5) -> b"12312"
    """
    repetitions = num_bytes // len(x)
    remainder = num_bytes % len(x)
    return x * repetitions + x[:remainder]

Also, if you’re wondering about the LENGTH_OFFSET constant, it exists because we only consider substrings of length 2 and greater and just output any substring of length 1 (9 bits uncompressed is better than a 17-bit reference for the flag, distance, and length). Since lengths 0 and 1 are unused, we can encode lengths 2-17 in only 4 bits.

Here is the declaration for LENGTH_OFFSET along with our other constants:

MATCH_LENGTH_MASK: Final[int] = 0xF
WINDOW_SIZE: Final[int] = 0xFFF
IS_MATCH_BIT: Final[bool] = True

# We only consider substrings of length 2 and greater, and just
# output any substring of length 1 (9 bits uncompressed is better than a 17-bit
# reference for the flag, distance, and length)
# Since lengths 0 and 1 are unused, we can encode lengths 2-17 in only 4 bits.
LENGTH_OFFSET: Final[int] = 2

That’s all there is to it for the compression code!

Decompression

The decompression code is much shorter overall and is covered with the single function shown below:

def decompress(compressed_bytes: bytes) -> bytes:
    data = bitarray(endian="big")
    data.frombytes(compressed_bytes)
    assert data, f"Cannot decompress {compressed_bytes}"

    output_buffer = []

    while len(data) >= 9:  # Anything less than 9 bits is padding
        if data.pop(0) != IS_MATCH_BIT:
            byte = data[:8].tobytes()
            del data[:8]
            output_buffer.append(byte)
        else:
            hi, lo = data[:16].tobytes()
            del data[:16]
            distance = (hi << 4) | (lo >> 4)
            length = (lo & MATCH_LENGTH_MASK) + LENGTH_OFFSET
            for _ in range(length):
                output_buffer.append(output_buffer[-distance])

    return b"".join(output_buffer)

Essentially, this function is just a while loop that decodes bytes until only padding remains.

For our first compression example of b"zzzzz", our compressed bits should look like 00111101 01000000 00000101 00000000. To make this a bit more readable, I’ll change the spacing between groups of bits: 0 01111010 1 00000000 00010100 000000.

For the order in which they appear,

0 corresponds to the no match flag, not IS_MATCH_BIT,

01111010 corresponds to the binary representation for b"z",

1 corresponds to the match flag, IS_MATCH_BIT,

00000000 corresponds to the most significant bits for match_distance,

00010100 corresponds to the least significant bits for match_distance and bits for match_length, and

000000 corresponds to padding bits.

On the first iteration of our while loop, the leading 0 is popped so the if branch is executed and 01010001 is interpreted/stored as b"z".

On the second iteration of our loop, 1 is popped so the else branch is executed and the bits 00000000 00010100 are parsed into match distance and length values.

This simple loop:

for _ in range(length):
    output_buffer.append(output_buffer[-distance])

elegantly utilizes the match distance and length values just decoded.

Summary

That’s all there is to it! If you check out the repo containing this code, you’ll see that everything fits cleanly into less than 100 lines of code.

If you notice any mistakes or have any feedback, please feel free to reach out.

I’ve titled this subsequent book “DevOps for Sponges”, and it teaches software development and operations concepts such as version control, automation, testing, deployment, and incremental design.

Why is the book “for Sponges”? Children are likened to sponges because of their ability to absorb information, and this book was written primarily for young minds.

The book is now available on Amazon, so please check it out and consider sharing with young, future engineers!