amodm

/// created for https://github.com/amodm/webbrowser-rs/issues/75
///
/// Steps:
/// 1. Copy this file as `tests/test_75.rs
/// 2. Run: `RUST_LOG=webbrowser=trace cargo test --test test_75 -- --nocapture`
mod tests {
    use webbrowser;

    #[test]
    fn test_open_default() {

amodm

On limitations of human interface devices (HIDs)

This post is in response to the WeekendDevPuzzle of 2022-02-12, which has submissions from people who chose to share their perspectives on the puzzle. I'll be linking this post to this Twitter thread, to avoid polluting the original one.

Motivation for today's topic

Every piece of technology gets engineered for a certain set of characteristics, e.g. the vehicle that you use, was designed with a certain typical & max capacity in mind. Same is true for the devices we use to interact with computing systems, be it your workstation, your laptop, or your smartphone. But how often do we reflect on those design characteristics?

Today's puzzle is about throwing some light on these devices, with the hope that it leaves us more informed.

Dissecting the puzzle

amodm

On predictability of seemingly simple code

This post is in response to the WeekendDevPuzzle of 2022-02-05, which has submissions from people who chose to share their perspectives on the puzzle. I'll be linking this post to this Twitter thread, to avoid polluting the original one.

Motivation for today's topic

We all have a mental model of how something works. For today's puzzle, the relevant mental model is: the same series of instructions should result in the same time of execution. The astute would be quick to add: in non-noisy environments only. And they'd be correct.

But then where's the flaw in this model? Let's start.

Dissecting the puzzle

The puzzle seems simple enough: a program reads in an array of integers, and counts how many of them are less than a threshold (another parameter to the program). We've been informed that there are no noisy-neighbour issues, and we're measu

amodm

#include <iostream>
#include <string>
#include <time.h>

#define MAX_DATA_SIZE 15*1024*1024

void die(const char *err)
{
    std::cerr << "error: " << err << std::endl;
    std::cerr << "usage: <progname> count <lessthan> <times>" << std::endl;

amodm

Weekend Dev Puzzle

Some time between 2021-22, I ran a list of puzzles designed to push developers into developing a better understanding of the technologies they use on a day to day basis. Each puzzle is designed to be fun, provocative, and short.

This is a complete list of those puzzles. Each link takes you to the tweet where I first posed the problem. If you like any of them, please feel free to share with others.

Edit (2024-01-27): Adding other puzzles to this 2024 onwards. Criteria:

1. Problem statement should be understandable by most in s/w tech, even if the ability to figure it out may not be.
2. Thinking about the problem should lead to clearer understanding of some foundational concept.
3. Should be short.
4. Should be fun to ponder over.

amodm

#!/usr/bin/env python3

###############################################################
# sample program for #WeekendDevPuzzle of 2022-02-05
#
# Sample invocations:
# To generate dataset:
#     ./find.py gen 16000 4096 > data
# To count:
#     cat data | ./find.py count 9999 10000

amodm

On availability aspects of microservices

This post is in response to the WeekendDevPuzzle of 2022-01-29, which has submissions from people who chose to share their perspectives on the puzzle. I'll be linking this post to this Twitter thread, to avoid polluting the original one.

Motivation for today's topic

Unlike the usual peel the onion kind of topics, this one focuses more on how we think & our mental models of architectural decisions. But there's more.

Over the past 15 yrs, programming has become extremely accessible. While that's undoubtedly a good thing, it's become much easier to just rely on best practice, with or without context. Today's puzzle was designed to bring to the discussion table, that context, albeit in a super simplified fashion.

Dissecting the puzzle

Let's dissect the question, and bring out the core elements of it.

amodm

How lambdas & closures are implemented

This post is in response to the WeekendDevPuzzle of 2022-01-22. This thread has submissions from people who chose to share their perspectives on the puzzle. I'll be linking this post to this Twitter thread, to avoid polluting the original one.

Why this topic?

Given that I started these puzzles as a way to peel the onion, so to say, lambdas + closures make for a particularly great subject, because of the large difference between our mental models of them (useful while programming), vs how they're actually implemented.

You see, as programmers, we're quite comfortable with moving data around, be it when we're passing them as parameters to a function, or when returning values. Whether the data is in stack, heap, register, it doesn't matter, nor whether we're passing them by value or by reference. I mean, it does matter, but our mental models aren't too s

amodm

How debuggers work

Writing this post in response to the WeekendDevPuzzle of 2022-01-15. This thread has a bunch of submissions, and it's insightful to go over how we often think about debuggers. I'll be linking this post to this twitter thread, which may also contain some follow up twitter follow ups later.

On Linux

Let's start with a simple piece of code. This is the program we'll be debugging. As you can see, it's a fairly simple piece of code. We will be setting a breakpoint on the crashtest function, crashing the debugger and seeing what happens.

Let's start with running this program (we've compiled using gcc -o testdebugcrash testdebugcrash.c). We'll be running this on Linux for now (the importance of this will be understood later). ![start-program](https://user-images.githubusercontent.com/1546858/149652729-dbfa2104-a

amodm

/*
* Sample code to test what happens when a debugger sets a breakpoint.
*
* Written for #WeekendDevPuzzle dated 2022-01-15
* https://twitter.com/amodm/status/1482206401103818756
*
* Steps to execute this:
*   # compile program
*     gcc -o testdebugcrash testdebugcrash.c
*   # run program