DEV Community: Yechiel Kalmenson

The Friction Is A Feature, Not A Bug: Teaching and Mentoring in the Age of AI

Yechiel Kalmenson — Wed, 22 Jul 2026 15:36:03 +0000

Those who have been following me for a while will know that teaching and mentoring are a Big Deal™️ to me.

Before I got into tech I was a teacher, and still consider myself a teacher at heart. Being a teacher and mentor was never separate in my eyes from being a good programmer and engineer; on the contrary, teaching was a tool that helped me become better at my craft at every stage of the journey.

But in the last few years, and accelerating in the last few months, the landscape for teaching and learning has been changing at a scary pace. The advent of LLMs and "AI" coding assistants has drastically shifted how we acquire engineering skills in ways that we are definitely not prepared for.

All of that has prompted many thoughts and conversations, and I hope to distill some of them in this blog post.

In true Talmudic fashion, this post doesn't contain too many answers and will hopefully leave you with more questions than you started with. But asking the questions is how we start these conversations, and these conversations need to be happening if we are to do right by the coming generation of programmers and engineers.

Don't Spoon-Feed Me

As a student, whether in Yeshiva when I used to spend hours each day poring over dense Talmudic legal debates and esoteric Chassidic philosophy or later while learning Rails and React at the Flatiron bootcamp, I quickly realized an uncomfortable truth about skill acquisition.

My best, most profound learning never happened when a lesson went smoothly; it happened when I was painfully stuck, banging my head against a cryptic error message or wrestling with a concept that just wouldn't click (usually at 2 AM, fueled by cold coffee and sheer stubbornness).

When you strip away that struggle, you get rid of the growth. And when you get rid of the growth, the learning just doesn't happen.

Even if you memorize just enough to pass the test, "easy come easy go." Without that cognitive friction, the knowledge evaporates the moment you close your editor.

The best teachers and mentors I ever had understood this intuitively. When I was staring at a broken script knowing there was probably a stupidly easy fix, they didn’t just swoop in and drop the solution onto my screen (much to the vocal frustration of my sleep-deprived brain).

Instead, they wielded tools like the Socratic method. They would point to a specific line of code and start asking gentle, probing questions to expose my flawed assumptions.

They actively leaned into the friction to create just enough cognitive space for me to connect the dots on my own.

They understood a fundamental rule of our teaching craft: that good mentorship is not about getting to the code. The goal wasn't just to get the tests turning green today; it was to build the mental resilience required to debug the next inevitable failure tomorrow.

And it was these skills that I took with. me when it was my turn to become the teacher, whether it was teaching second graders at the Jewish Online School, as a TA at Flatiron, or when mentoring new teammates joining my team.

The Yes-Man in Your IDE

Fast forward to today, and our industry has largely outsourced that initial layer of mentorship to LLMs and coding assistants. And here is the uncomfortable truth: AI makes a terrible Socratic tutor.

If you’ve spent any serious time pairing (or even just chatting) with modern LLMs, you know they are pathological yes-men. Tell an AI you want to architect a distributed microservice mesh for a todo-list app with twelve active users, and it won't push back. It will chime in with "That is a brilliant insight!" and instantly spit out 400 lines of boilerplate.

AI defaults to blind trust. It rarely challenges a mistaken assumption, and when you ask it why a stack trace is blowing up, it immediately serves up a copypastable fix instead of helping you understand the underlying bug.

By acting like an algorithmic vending machine (error_in => fix_out), AI systematically removes all the cognitive friction from the development process.

In our rush for 10x velocity, we forgot a foundational rule of skill acquisition: friction is a feature, not a bug. That was a load-bearing friction we removed!

This isn't just philosophical speculation; there's hard data to back it up. A recent study by Anthropic (or dive into the raw paper here if you love parsing methodology) took 52 software engineers learning an unfamiliar programming library and split them into two groups: one with AI coding assistants, and one coding by hand.

The overall results were as damning as they were not surprising. The engineers who delegated their coding to AI suffered a 17% drop in conceptual mastery and debugging skills (the equivalent of two full letter grades!) often without completing their tasks meaningfully faster than the manual control group.

Why? Because when you offload the cognitive friction of getting painfully stuck, your brain never builds the deep neural pathways required to evaluate whether the generated code is actually any good.

Now, to be fair, there was some nuance in the data: a handful of the AI-assisted engineers actually outperformed the manual control group. But who were they? They were the developers who refused to trust the AI blindly. They treated the LLM like a study partner, asking probing follow-up questions and manually injecting their own friction back into the process.

For everyone else, the automated yes-man just quietly destroyed their understanding.

The Learner’s Dilemma: Manually Injecting Friction

This dynamic leaves junior developers in a massive bind.

Friends and mentees who are earlier in their career have complained that they feel stuck in a frustrating Catch-22:

On one hand, they have to pragmatically accept the reality that AI isn't going anywhere. If an LLM can generate working boilerplate from a single prompt, you can't just stubborn your way out of using it. Ignoring AI entirely feels irresponsible, considering that you will be using these tools heavily in your day-to-day workflows.

But on the other hand, if you rely on that autocomplete blindly, you get trapped in what's known as "superficial learning." You get a quick answer that allows you to pass a test suite or get a PR approved without truly understanding the mechanics under the hood. You miss out on the "deep learning" where the actual, career-sustaining growth happens.

In my experience, that superficiality is a direct pipeline to developer anxiety and impostor syndrome. True professional confidence doesn't come from hitting Tab to accept a prompt; it comes from code ownership and intense intellectual toil and sweat.

To survive this, diligent learners are now being forced to manually inject friction back into their workflows just to keep their brains from turning off.

A junior developer friend of mine has resorted to explicitly prompting their IDE with guardrail instructions like: "I want to learn how to code it myself, rather than copying and pasting, so enable that however you can."

They take notes by hand (yes, actual paper and pen!) and set physical timers just to recreate the safeguards of active listening that a tool designed for instant gratification systematically tries to bypass.

Why We Need the Messy Web of Context

This need for self-imposed struggle makes total sense when you look at Emily Bender and Alex Hanna’s book, The AI Con, which highlights why friction in information access is actually a feature, not a bug.

Think about what happens when you manually hunt down an obscure bug using a search engine.

You read messy documentation, scan through twelve-comment GitHub issue threads (usually ending with a maintainer closing it as "not a bug" in 2014), weigh the credibility of conflicting answers on Stack Overflow, and stumble across related gotchas along the way.

That messy web of meta-information is where real engineering context is built.

An AI chatbot flattens all of that rich, frustrating struggle into a single, authoritative-sounding (and occasionally "hallucinated") summary. It gives you the answer to your immediate problem while robbing your brain of the surrounding ecosystem knowledge required to solve the next one.

The Chavrusa Model: Pair Programming && The Adversarial Rubber Duck

This brings me to an ancient pedagogical model that survives to this day in Yeshivas (Talmudic academies) around the world, and one that software engineering desperately needs right about now.

In a traditional Yeshiva, you rarely see people sitting in silent isolation reading a book or passively listening to a lecture. Instead, the room is loud, energetic, and filled with people arguing fiercely in pairs.

This study partner system is known as a Chavrusa (from the Aramaic word for "friend" or "companion").

When you learn with a Chavrusa, your partner isn't there to read the text to you, nor do they nod along and sycophantically affirm how brilliant your theories are. A real Chavrusa regularly challenges your logic, pokes holes in your arguments, pushees back against shaky assumptions, and generally refuses to let you get away with intellectual laziness.

You don't master the Talmud by reading cliff notes or listening to a brilliant lecture (though there's some of that as well); you master it through Yegiah (a Hebrew term that translates to intense intellectual toil and sweat).

If you think about it (and as I mentioned in my 2021 RailsConf talk), pair programming is just the tech industry's recreation of the Chavrusa.

And here is the most important part of that system: it's not only the junior member of the pair who's learning in a true Chavrusa.

It doesn't matter if you are pairing with a 10-year staff engineer or a junior developer who just finished a bootcamp; the learning is always a two-way street!

When your partner acts as an adversarial rubber duck (one that actually talks back!), they force you to slow down, articulate your hidden assumptions, and defend your code logic from start to finish. Both of you gain from that friction, and both of you walk away with a significantly better mental model than you started with.

Rabbi Ḥama, son of Rabbi Ḥanina, said: What is the meaning of that which is written: “Iron sharpens iron, so a man sharpens the countenance of his friend” (Proverbs 27:17)? This verse comes to tell you that just as with iron blades, one sharpens the other when they are rubbed against each other, so too, when Torah scholars study together, they sharpen one another.

-Ta'anit 7a

In our rush for 10x velocity, we tried to replace human pair programming with AI copilots. But in doing so, we forgot a critical dependency: we exchanged the adversarial Chavrusa and Yegiah for a sycophantic robo-duck.

Empathetic Balancing Act

A common response I hear from the tech crowd is: "Well, let's just fix this with better system prompts! Let's build guardrails that instruct the AI to act like a Socratic tutor instead of just giving away the answer!"

There are plenty of tools attempting this right now, but I am deeply skeptical that technical guardrails can solve a fundamentally human problem.

First of all, relying on a prompt to withhold answers requires elite learner discipline. Some students can stick to it, but that level of willpower is rare, especially when your cognitive battery is hitting empty.

When a junior developer is staring at a cryptic NullPointerException at 2 AM and their brain is fried, a prompt asking them to "reflect on the lifecycle of the object" is getting bypassed immediately. If all it takes is typing /solution or opening a new browser tab to get the dopamine hit of copypastable code, not too many people I know will power through.

More importantly, LLMs are fundamentally architected to please. Even if you prompt-engineer them to be tough Socratic tutors, their core tuning means that the moment a user expresses genuine frustration, the AI folds like a cheap lawn chair and hands over the syntax anyway.

Why? Because an LLM lacks the quality most important in an educator: empathy.

Mentorship is a human pedagogical balancing act. A great mentor understands the fine line between productive struggle and demoralizing suffering. A good educator can read the room. They notice the heavy sighs, the mounting panic, and the sheer exhaustion.

Sure, as a student I learned best when I was given the tools to figure things out on my own. But sometimes I maxed out my energy on the stupid error message, and all of the leading questions my tutors were asking me felt like they were just causing me to circle and circle around the one insight that would make it all work, an insight my brain just couldn't reach.

That is the point a good teacher knows to step back, smile, say "Hey, JavaScript is just weird sometimes," and hand the exact line of code I needed to get unstuck so I could finally go get some sleep.

An algorithm cannot read a learner's emotional state. It cannot dynamically toggle between a challenging sparring partner and a supportive safety net. Code can never replicate that relationship.

The Unsolved Catch-22

So where does this leave us? If I’m being entirely honest, I have way more questions than answers right now (not exactly what you want to hear from a tech blog, I know!).

We are sitting on a massive, industry-wide Catch-22:

On one hand, it would be borderline professional malpractice to forbid junior developers from using AI. It is the modern IDE (which, back when I was learning to code, gatekeepers argued juniors shouldn't use either—I disagreed then and I disagree now). If juniors will be expected to use these tools on the job, it hardly makes sense not to train them to use them effectively.

On the other hand, the engineers getting that massive 10x velocity boost without introducing architecture-destroying bugs are the seniors who spent years writing code without it.

We know when an LLM is spinning its wheels on a false premise because we have a built-in BS-meter, hard-earned through years of manual debugging.

How does someone without that pre-AI experience build that intuition today? They won't get it from a sycophantic yes-man chat-bot assistant. And manually inventing your own cognitive friction requires a level of self-discipline that is hard to maintain on a tight deadline.

Maybe the future of onboarding relies on doubling down on human pair programming—having juniors shadow seniors for months on end to soak up that pre-AI intuition by proxy. After all, pair programming has always been one of the best onboarding methods, even before Claude. But not all companies are interested in the investment that full-time pairing requires in an industry often obsessed with shipping yesterday.

What I do know is that we cannot afford to ignore the problem or assume that better LLM models will magically fix our talent pipeline.

If we just hand junior developers an oracle and fail to preserve the empathetic, rigorous struggle of the Chavrusa, we are going to wake up in a few years to a terrifying system error: an industry with a massive, AI-generated codebase to maintain, and not enough senior engineers left who know how to maintain it.

What are you and your teams doing to keep productive friction alive? I'd love to hear your thoughts.

Who's Going To RubyConf 2026?

Yechiel Kalmenson — Wed, 10 Jun 2026 00:08:27 +0000

RubyConf holds a special place in my heart. It was the very first tech conference I attended after receiving a scholarship fresh out of Flatiron School back in 2017 (you can read about my experience here), and then in 2021, it was the stage for my first conference talk in Denver.

Now, in another first, I joined the Program Committee for RubyConf 2026 to help put the program together, and what a program it is! We have an absolutely amazing lineup this year, and I'm so excited to see it come to life!

Who else is planning on attending? Let's make plans to meet up and say hi!

Shipping Your Machine: Building a Container in 50 Lines of Code (Part 2)

Yechiel Kalmenson — Tue, 26 May 2026 15:03:07 +0000

Welcome Back to the Jailhouse

In Part 1 of this series, we built the foundation of our container using Go. We successfully used the CLONE_NEWUTS namespace and process forking to isolate our container's hostname from the host machine.

But we still have a massive security flaw. Right now, if we drop into our container's bash shell, we can still see all of the host's files. We could easily cd straight out of our "isolated" environment and mess with the host machine.

Let's lock it down.

`chroot` to Jail

Linux has a wonderful system call called chroot (short for "change root"). It lets us change the root directory (/) for a given process. As far as the process is concerned, the directory we point chroot to is the entire universe. Anything outside of it simply doesn't exist.

Let's update our child() function to set the root directory to our current working directory:

func child() {
    fmt.Printf("Running in new child process %v \n", os.Args[2:])

    must(syscall.Sethostname([]byte("container")))

    // Get current directory and lock the process inside it
    pwd, err := os.Getwd()
    must(err)

    must(syscall.Chroot(pwd))
    // chroot changes the root, but doesn't automatically move us there. 
    // We must explicitly change our working directory to the new root!
    must(os.Chdir("/"))

    cmd := exec.Command(os.Args[2], os.Args[3:]...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    must(cmd.Run())
}

Run sudo go run main.go run /bin/bash.

Crash!

panic: fork/exec /bin/bash: no such file or directory

What happened?

We just told our process that our current directory is the entire universe. So, when we ask exec.Command to run /bin/bash, it isn't looking at your computer's actual hard drive anymore. It is looking inside your project folder for a directory called bin containing an executable called bash.

Because our current directory doesn't have those, it fails! We need an actual root filesystem to provide the basic binaries our shell expects.

(Note: Production container runtimes like runC actually use a more advanced system call called pivot_root for better security, but chroot is perfect for understanding the core concept!).

The Image

To fix this, we need to provide an actual root filesystem that contains the basic folders and binaries (like /bin/bash) that our shell expects.

You can grab a basic Ubuntu root filesystem yourself using Docker. Open a new terminal tab and run these exact commands in your project directory:

# Use docker to start a Ubuntu container and then export its filesystem to a compressed file called ubuntu.tar
docker export $(docker create ubuntu) > ubuntu.tar

# Create a directory called ubuntu-rootfs and unzip your tar file into it
mkdir ubuntu-rootfs
tar -xf ubuntu.tar -C ubuntu-rootfs

This creates a folder called ubuntu-rootfs containing a complete, brand-new Ubuntu file system.

Assuming you have that folder in your project directory, let's change our chroot call to point to it as follows:

    must(syscall.Chroot(filepath.Join(pwd, "ubuntu-rootfs")))
    must(os.Chdir("/"))

Now, when we run sudo go run main.go run /bin/bash, everything works perfectly!

You can run ls / and you will only see the files inside your ubuntu-rootfs directory. Try running cd .. to escape, and you will find yourself in the exact same directory as before. You cannot access the host machine at all.

PIDs and /proc

We're ready for the next step. If you remember, when we ran docker run -it ubuntu /bin/bash back in the beginning of Part 1, one of the ways we could tell we were in an isolated container was by running ps aux and observing only two processes running with very low PIDs.

Let's try to replicate that. While inside our new container, try running ps aux to view the running processes.

It breaks with an error:

Error, do this: mount -t proc proc /proc

The ps command works by reading the /proc directory, which is a special virtual filesystem in Linux that contains live data about running processes. Our isolated root filesystem has an empty /proc folder, and the operating system hasn't been told to attach the live process data to it. Because it's empty, ps fails!

To fix this, we need to do two things:

Give our container its own isolated Process IDs (PIDs) using namespaces.
Mount the proc filesystem so commands like ps can read it.

First, update the SysProcAttr in the run() function to include the PID and Mount namespaces. (Note: CLONE_NEWNS stands for "New Namespace", but it specifically refers to the Mount namespace! It just happens to be the first namespace added to the Linux kernel and back then no one thought they might end up needing more so they just called it "namespace" 🤷).

    cmd.SysProcAttr = &syscall.SysProcAttr{
        Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS,
    }

Next, mount the proc directory inside our child() function, right after we chroot. We will also use Go's defer keyword to ensure we unmount it and clean up after ourselves when the function exits:

    must(syscall.Chroot(filepath.Join(pwd, "ubuntu-rootfs")))
    must(os.Chdir("/"))

    // Mount the proc filesystem
    must(syscall.Mount("proc", "proc", "proc", 0, ""))
    // Clean up after ourselves when the function exits
    defer syscall.Unmount("proc", 0)

Now, run your container and type ps aux. You'll see only three processes running: exe (our Go program) running as PID 1, bash running as PID 2, and the ps command we just ran!

Cgroups (Keeping it Civil)

We have our invisibility cloak (Namespaces) and our isolated universe (chroot). But what happens if we write an infinite while loop inside our container that eats up all the CPU and memory?

It would completely crash the host machine!

To prevent our container from using up all of our resources, Linux uses cgroups (Control Groups). Cgroups act as the bouncer, ensuring no single container uses more than its fair share of resources.

To set up a cgroup, we can lean on a famous Linux philosophy: "Everything is a file." This means we can configure the kernel's resource limits by creating specific directories and writing text into special files.

Let's add a quick helper function to our main.go file to limit the maximum number of processes our container is allowed to spawn to 20:

func cg() {
    cgroups := "/sys/fs/cgroup/"
    pids := filepath.Join(cgroups, "pids")

    // 1. Create a new cgroup for our container
    containerCgroup := filepath.Join(pids, "my-container")
    os.Mkdir(containerCgroup, 0755)

    // 2. Write the limit into the cgroup file (max 20 processes)
    must(os.WriteFile(filepath.Join(containerCgroup, "pids.max"), []byte("20"), 0700))

    // 3. Add our current process to this cgroup
    must(os.WriteFile(filepath.Join(containerCgroup, "cgroup.procs"), []byte(strconv.Itoa(os.Getpid())), 0700))
}

Let's break down what this function is doing:

Create the group: By making a new directory inside /sys/fs/cgroup/pids, the Linux kernel automatically creates a new Control Group for us.
Set the rule: Inside that new directory, Linux automatically generates a file called pids.max. We open that file and write the text "20" into it. This establishes a rule that our process will only be allowed to run 20 sub-processes.
Enforce the rule: Linux also generates a file called cgroup.procs. We get our Go program's current Process ID (os.Getpid()) and write it into this file. This tells the kernel, "Hey, apply the rules of this folder to me!"

Finally, let's call this function inside our run() function, right before we execute our child process:

func run() {
    fmt.Printf("Running %v \n", os.Args[2:])

    args := append([]string{"child"}, os.Args[2:]...)
    cmd := exec.Command("/proc/self/exe", args...)

    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    cmd.SysProcAttr = &syscall.SysProcAttr{
        Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS,
    }

    // Set up our resource limits!
    cg()

    must(cmd.Run())
}

And just like that, our container is officially resource-limited! Because cgroups inherit down to child processes, everything that runs inside our container is bound by this rule. If a malicious script inside tries to execute a "fork-bomb" (a script that endlessly copies itself to freeze the computer), the kernel will step in and aggressively kill it the second it hits 20 processes.

The Reveal

If you put all of this together, we just built Docker from scratch in about 50 lines of code.

Containers aren't magic. They aren't heavyweight VMs. They are simply standard Linux processes wrapped in namespaces, jailed in a specific directory, and policed by cgroups.

In fact, you don't even need Go to do this. You can trigger the exact same isolation using a single line of bash:

sudo unshare --uts --pid --mount --fork --root=/home/ubuntu-rootfs --mount-proc /bin/bash

And there you have it! The next time someone says "it works on my machine," you know exactly what it takes to ship their machine to production.

Shipping Your Machine: Building a Container in 50 Lines of Code (Part 1)

Yechiel Kalmenson — Wed, 20 May 2026 20:09:10 +0000

The "Works on My Machine" Problem

We've all been there. You spend days writing a new feature. You test it locally, everything passes, you push it to production, and... boom. It crashes immediately.

"But it works on my machine!" you cry out to your lead engineer.

And that is exactly what containers are. They are a way to bundle up your application and the environment it runs in—your machine—so that it behaves exactly the same way in production as it does on your laptop.

But what is a container, really?

Most people have an intuition of containers as some kind of complicated application that runs on your computer and simulates another computer. That is the image I had in my head even after working on containers for a few months at Pivotal/VMware... and it's a myth.

The reality is a lot simpler, and a lot more interesting!

The truth is that a container is simply a directory on your computer—like any other directory—with a process running inside of it. What makes it a container and not just another process running inside a directory is that we use some clever built-in Linux features to trick the process into thinking that this directory is the entire computer. As far as this process is concerned, nothing exists outside of the directory we "trapped" it in and that directory is the entirety of its universe.

In this two-part series, we are going to demystify this illusion by building Docker from scratch in exactly 60 lines of Go code.

Note: Because containers rely heavily on the Linux Kernel, this tutorial will only run natively on a Linux machine. If you are following along on a Mac, you'll need to spin up a Linux VM first, as Macs run on the Darwin kernel and don't have these system calls!

Let's get started!

Setting the Stage

We'll be writing our container in Go. Why Go? Because it gives us incredibly clean access to underlying Linux system calls, which we'll need to create our container illusion. This is the reason Docker, Kubernetes, and other cloud-native projects are all written in Go.

Let's try to replicate the core behavior of Docker.

Normally, when using Docker, you run a command like:

docker run -it ubuntu /bin/bash

If you run that (assuming you have docker installed) you will see that you have been dropped into a new shell. This shell looks different than your original shell and you can tell it's completely isolated from the rest of your machine (the host) in a few ways (it's worth opening a new tab in your terminal so you can see these changes side by side):

Your prompt: Everyone's prompt is different, but most have something in the beginning that looks like [username]@[hostname]. The prompt you see now probably looks like root@[some-random-string].
Your hostname: If you type hostname in your host computer's terminal, it will output your computer's actual name. If you run hostname inside your container, on the other hand, you will see that same random sequence of characters from your prompt. Docker assigned this fake hostname to your container at random.
Your File System: If you type ls / inside your container you will see that none of the files from your computer's actual root directory are there, instead you will see a fresh list of files and directories, exactly like you would find in a brand new Ubuntu installation.
Your processes: If you type ps aux in your container you will find only 2 processes with very low Process IDs (PIDs)—typically PID 1 for the shell process you're in and another low number PID for the ps command you just ran. Meanwhile, running ps aux on your host machine will show a massive list of running processes, many of them with very high PIDs.

We will try to replicate this behavior from scratch, with a few minor differences.

Our goal is to run:

go run main.go run /bin/bash

And if we do everything right the behavior will be mostly the same. We will drop into a new shell where:

We will see a different hostname than our existing one.
The root directory we will have access to will not be the root directory of our computer, instead it will be a new root directory.
If we inspect the processes running using ps we will see only the processes running in our program and not all the processes on our computer.

So let's start!

Show Me the Code

Let's build this step by step. Create a new directory on your Linux computer, make a file named main.go, and let's add our initial boilerplate:

package main

import (
    "fmt"
    "os"
)

func main() {
    // os.Args is a list of everything typed in the terminal.
    // [0] is the program name (main.go), [1] is our command ("run")
    switch os.Args[1] {
    case "run":
        run()
    default:
        panic("Invalid argument")
    }
}

func run() {
    // os.Args[2:] takes everything AFTER the "run" command
    // e.g., ["echo", "hello", "world"]
    fmt.Printf("Running %v \n", os.Args[2:])
}

In Go, os.Args captures every word you type into the terminal as a list (a slice) of strings. We are telling our program to look at the second word (os.Args[1]). If it says "run", we trigger our run() function which, for now does nothing but print all our arguments to the terminal.

If we run this in our terminal:

$ go run main.go run echo hello world
Running [echo hello world]

Awesome. It successfully reads our command. But it's just printing text; it's not actually executing the command yet.

To make it execute the command, we need to wire up Go's os/exec package (a package for executing commands on our computer). Let's update our file:

package main

import (
    "fmt"
    "os"
    "os/exec"
)

func main() {
    switch os.Args[1] {
    case "run":
        run()
    default:
        panic("Invalid argument")
    }
}

func run() {
    fmt.Printf("Running %v \n", os.Args[2:])

        // 1. Define the command we want to execute. This includes the third element in our array 
    // (the actual command, in our case "echo"), as well as any optional arguments we may 
    // want to pass to it ("hello world").
    cmd := exec.Command(os.Args[2], os.Args[3:]...)

    // 2. Wire up the plumbing
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    // 3. Run the command and handle any errors
    must(cmd.Run())
}

// A tiny helper function to catch errors and crash the program 
// cleanly if something goes wrong.
func must(err error) {
    if err != nil {
        panic(err)
    }
}

Let's look at what we just added to run():

Define the command: exec.Command takes the program we want to run (like echo) and any arguments we want to pass to it (hello world).
Wire up the plumbing: This part is crucial. By default, when a program spins up a new process, it runs invisibly in the background. By pointing the new command's Standard Input, Output, and Error to our own os.Stdin, os.Stdout, and os.Stderr, we are attaching its "mouth and ears" directly to our terminal so we can actually interact with it.
Run it: We execute the command. Because Go requires explicit error handling, we wrapped it in a tiny must() helper function to keep our code readable.

Let's test it out:

$ go run main.go run echo hello world
Running [echo hello world]
hello world

We actually get hello world echoed back at us by the system!

Even better, we can tell our program to drop us into an interactive shell:

$ go run main.go run /bin/bash
Running [/bin/bash]
root@your-computer:/home/yechiel/docker-clone#

However, this shell is absolutely not a container yet. If you type hostname, you'll see your host machine's actual name. If you type ls /, you can see all your host files. Right now, we have just written a fancy Go wrapper around a regular bash process.

It is time to start building the walls of our container.

Introducing Namespaces (The Invisibility Cloak)

To isolate our process from the rest of the computer, we need to put it inside a Namespace. A namespace is like an invisibility cloak that hides the rest of the computer from our process.

There are different namespaces that isolate different aspects of the system. Let's start with the UTS namespace, which isolates the hostname.

To create a new namespace, we pass a specific "clone flag" to the system call spinning up our process. Update your run() function:

func run() {
    fmt.Printf("Running %v \n", os.Args[2:])

    cmd := exec.Command(os.Args[2], os.Args[3:]...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    // Set up the namespace!
    cmd.SysProcAttr = &syscall.SysProcAttr{
        Cloneflags: syscall.CLONE_NEWUTS,
    }

    must(cmd.Run())
}

If you try to run the command now, you'll get a "permission denied" error. Because changing a namespace requires modifying kernel-level structures, you now need root privileges.

Instead, let's run sudo go run main.go run /bin/bash.

If you run hostname now you will still see your computer's actual hostname. This is because, by default, Linux has your new process inherit the hostname of the host computer.

However, if you manually run hostname container inside this new bash shell, and then type hostname, you'll see your hostname is now container. But if you switch to a terminal tab on your host machine and type hostname, you'll see your actual computer's name hasn't changed at all! Our process is successfully isolated.

Forking the Process

Did you notice something weird when you manually changed the hostname in the last step? Even though typing hostname printed out container, your actual bash prompt likely still said root@your-computer#!

This happens because the bash shell reads the machine's hostname when it first starts up. Changing the hostname after the shell is already running doesn't dynamically update your prompt. If we want our container to feel like a truly isolated environment from the second it boots, we need our Go program to change the hostname automatically before we execute /bin/bash.

Luckily, Go has a function to change the hostname: syscall.Sethostname().

But here we run into a "chicken and egg" problem: where do we call that function?

If we call it before cmd.Run(), it executes on our host machine and changes our actual computer's name (bad!). If we call it after cmd.Run(), it'll only run after our bash shell has already exited (still bad!).

We need a middleman. We need our Go program to cross over into the new namespace, set the hostname, and then execute the /bin/bash command.

To do this, we are going to have our Go program run itself again as a child process.

Let's update our main.go file. We will update the main() and run() functions, and add a brand new child() function:

package main

import (
    "fmt"
    "os"
    "os/exec"
    "syscall"
)

func main() {
    switch os.Args[1] {
    case "run":
        run()
    case "child":
        child() // We added a new command here!
    default:
        panic("Invalid argument")
    }
}

func run() {
    fmt.Printf("Running %v \n", os.Args[2:])

    // /proc/self/exe is a special Linux file that points to the program 
    // currently running. So, our program is calling itself!
    // We pass "child" as the first argument, followed by the rest of our commands.
    args := append([]string{"child"}, os.Args[2:]...)
    cmd := exec.Command("/proc/self/exe", args...)

    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    cmd.SysProcAttr = &syscall.SysProcAttr{
        Cloneflags: syscall.CLONE_NEWUTS,
    }

    must(cmd.Run())
}

func child() {
    fmt.Printf("Running in new child process %v \n", os.Args[2:])

    // We are now inside the namespace! It is safe to change the hostname.
    must(syscall.Sethostname([]byte("container")))

    // Now we run the actual command the user requested (like /bin/bash)
    cmd := exec.Command(os.Args[2], os.Args[3:]...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    must(cmd.Run())
}

func must(err error) {
    if err != nil {
        panic(err)
    }
}

Let's break down the magic happening in exec.Command("/proc/self/exe", args...):

"/proc/self/exe": In Linux, /proc is a special directory that holds information about all running processes. If you check what's in there (by running ls /proc) you will see a whole bunch of directories that have numbers as names. Each number is a PID and that directory contains information about the process with that PID. /proc/self/exe is essentially a shortcut to the directory for the process that's currently running (in our case go run main.go).
args...: We are taking the word "child" and appending the rest of the user's commands (like /bin/bash) to it. The ... syntax in Go simply "unpacks" the list so it can be passed as individual arguments.

So, when you type go run main.go run /bin/bash, here is what happens:

The program starts, sees "run", and triggers the run() function.
The run() function sets up the invisibility cloak (the NEWUTS namespace).
Inside that cloak, it runs itself again, but this time passing the command "child".
The program starts a second time, sees "child", and triggers the child() function.
Because we are now safely inside the namespace, it changes the hostname to container and finally runs /bin/bash.

Let's test it. Run sudo go run main.go run /bin/bash:

$ sudo go run main.go run /bin/bash
Running [/bin/bash]
Running in new child process [/bin/bash]
root@container:/home/yechiel/docker-clone#

Look at that prompt! We've successfully isolated the hostname programmatically before bash loaded. You'll see both print statements execute, and if you type hostname in the new shell, it will say container.

We are still not in a proper container, though. If you run ls /, you will see all the files on your host machine, and you can even use cd .. to "escape" the directory entirely. Worse, if you were running this in a shared cloud environment, you would theoretically be able to see everyone else's files and running processes—a massive security risk! We need a way to lock our process down so it can't escape its designated environment.

In Part 2, we will tackle the final pieces of the container puzzle: jailing the file system, isolating the Process IDs (PIDs) so our container can only see itself, and stopping infinite loops from crashing the host computer using cgroups. Stay tuned!

Who's Going To RubyConf?

Yechiel Kalmenson — Fri, 05 Nov 2021 19:00:05 +0000

RubyConf is starting next week (November 8-0), both in person in Denver and remotely online.

This year it's especially exciting for me; it's my first in-person conference in exactly two years (the vaccine mandates and mask policy helped me feel safe with the decision to attend in person), AND I'll be giving a talk (which you should totally come watch if you'll be there)!

Who else is planning on attending?

Come say hi (either in person or in the discord)!

Talmudic Gems For Rails Developers

Yechiel Kalmenson — Thu, 20 May 2021 01:40:59 +0000

A few weeks ago, I gave a talk at RailsConf titled Talmudic Gems For Rails Developers.

In the talk I discussed lessons I learned from a lifetime of Talmudic study that helped me in my journey as a developer, and which I felt could benefit other developers in their growth.

The talk is geared at any developer looking to grow using the timeless wisdom of the Talmudic sages, not just Rails developers.

I shared a transcript of the talk in the Torah && Tech newsletter issue #123 (if you haven’t yet, you can sign up to the newsletter, and get the first year’s worth of newsletters in book format, at the Torah && Tech website: torahandtech.dev).

The talk has just been posted to YouTube, and I’m happy to share it with my audience!

If you would like to delve into some of the sources I mentioned, you can find links in the source sheet I prepared here.

Happy Learning!

Part 3: Add A Dead-Man's Switch To A Rails Application

Yechiel Kalmenson — Sun, 07 Feb 2021 18:47:58 +0000

Bonus Round!

In part one and part two of this series, we created a working deadman's switch in our rails app.

This part isn't necessary, but it can be helpful.

The deadman's switch we wrote will trip if it isn't reset after seven days (or however long you set it for). That may seem like a safe interval, but it would be nice to have a reminder if you haven't reset it in a few days and the deadline is coming up.

I set my switch up to send me an SMS reminder if I didn't reset it in 4 days, and then every day after that until the switch is either rest or if it trips.

That's what we will do in part three of this tutorial.

Note: this part of the tutorial uses Twilio to send SMS messages. You will need to sign up for a Twilio account. If you use my referral link to sign up, you will get $10 of credit, which should be last a while for our use-case.

Getting Started

The first thing we need to do before getting started is to make sure we have a Twilio account. For our purposes, a "demo" account is enough. A demo account is free; it means you will have to register your phone number to receive texts, and you can't send SMS messages to other numbers, which is fine. Sending an SMS costs money ($0.0075 in the US); the $10 you get at sign-up by using my referral link should cover that for a long time.

After creating an account, follow the instructions to create a new project.

On the dashboard, you will need three pieces of information: The Account SID, Auth Token, and the account phone number.

Save these credentials in a safe place; we will need them for the next part.

Note: It's a bad idea to put API keys in your code as plaintext, especially if you put your code somewhere that's publicly accessible like GitHub. Someone can find them and use them to rack up quite the phone bill! Store them as environment variables instead. Heroku makes it easy to set environment variables.

Text me, maybe?

Now we have everything we need to set up our script to text us when it doesn't hear from us in a while.

First, put the following near the top of your rake task:

include ActionView::Helpers::DateHelper

This isn't strictly necessary, but it will let us use ActionView's time_ago_in_words method to format a nice human-readable message.

Next, let's set up a conditional to send the message only after the specified time that the app didn't hear from you. I set mine up to start bugging me after three days:

if 3.days.ago >= Deadman.last_reset

end

(though for testing purposes, you can make the interval as small as a few seconds so you can trigger the SMS to send and make sure everything is working. Just remember to change it back before pushing to production).

Now, inside the if block, the first thing to do is to construct a message that the script will send:

time_to_trigger = time_ago_in_words(Deadman.last_reset + 7.days)
message_body = "Your deadman switch will trigger in #{time_to_trigger}, please log in to your account and reset it."

You can, of course, edit this to fit your needs and taste.

Next, let's set up a Twilio client using the credentials we got from the Twilio dashboard:

twilio_client = Twilio::REST::Client.new(ENV['TWILIO_ACCOUNT_SID'], ENV['TWILIO_ACCOUNT_TOKEN'])

Finally, you can use the client to send an SMS message to your phone:

twilio_client.messages.create(from: ENV['TWILIO_PHONE_NUMBER'], to: ENV['PHONE_NUMBER'], body: message_body)

The from: field is the Twilio phone number you got from your Twilio dashboard, and the to: field is your personal phone number (make sure to register it with your Twilio account if you're on the free "Demo" tier). The body: field is the message we constructed earlier.

The complete code should look something like this:

include ActionView::Helpers::DateHelper

if 3.days.ago >= Deadman.last_reset
    time_to_trigger = time_ago_in_words(Deadman.last_reset + 7.days)
    message_body = "Your deadman switch will trigger in #{time_to_trigger}, please log in to your account and reset it."
    twilio_client = Twilio::REST::Client.new(ENV['TWILIO_ACCOUNT_SID'], ENV['TWILIO_ACCOUNT_TOKEN'])
    twilio_client.messages.create(from: ENV['TWILIO_PHONE_NUMBER'], to: ENV['PHONE_NUMBER'], body: message_body)
end

And that's it! That's all there is to it!

My Favorite Bash Tips, Tricks, and Shortcuts

Yechiel Kalmenson — Mon, 11 Jan 2021 22:23:39 +0000

If you're on DEV, chances are you spend at least some time in the terminal, maybe even a lot of time.

Over the years, I've picked up a number of tips and tricks from fellow developers. Almost every time I pair program with someone new, chances are I'll notice them doing something neat and ask them how they did it.

Here are some of my favorites.

I use bash as my default terminal, but most of these tips translate to other terminals as well.

Note: This post isn't meant to teach the basics of using the terminal. There are many great resources online (I remember doing Codecademy's Command Line course when I was starting out.

The `-` operator

Do you find yourself switching back and forth between two directories often?

You can use cd - to change to the last directory you were in like this:

~ $ cd directory1
~/directory1 $ cd directory2
~/directory2 $ cd -
~/directory1 $

This also works with git when switching between branches:

~/my-project(main)$ git checkout feature-branch
~/my-project(feature-branch)$ git checkout -
~/my-project(main)$

The `!!` operator

This happens a lot!

You type a command, only to get a "Permission denied" so you have to retype the command again, this time using sudo.

The !! operator echoes the last command you typed into your terminal.

You can use it like this:

$ some-dangerous-script.sh
=> Error: Permission Denied
$ sudo !!
=> Enter password for some-dangerous-script.sh:

{curly brace expansion}

If you ever need to run a series of very similar commands that differ by just a few characters (like for example, if you want to create a few filenames with lightly different extensions) you can use the characters that will be different between two curly braces and the command will run once for each one.

Like this:

$ touch file-{1,2,3}.md
$ ls
=> file-1.md file-2.md file-3.md

You can also pass in a range:

$ touch file-{1..3}.md
$ ls
=> file-1.md file-2.md file-3.md

Search using Ctrl+R

Are you like me? Would you press the up button 20 times to avoid typing out a 7 character command?

This next one was a lifesaver for me!

You can type Ctrl + R followed by the first few letters of the command you want to search through your bash history and bring up the command you need.

(Sorry, I can't think of how to demonstrate that with a code snippet. Just go to your terminal, type in Ctrl + R and start typing).

Aliases

Aliases are a great way to save time and keystrokes. If there's a command or a series of commands you find yourself typing often, it's making an alias can be very helpful.

In order to set aliases, first open the ~/.bashrc file in your favorite editor and check if it has the following lines in it:

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

It should be there already, if it isn't just add it to the bottom of the file.

Next open ~/.bash_aliases in your editor (or create it if it doesn't exist) and add your aliases in the following format:

alias something="definition"

Some playful aliases I have in my .bash_aliases are:

alias please="sudo "
alias yeet="rm -rf

I also have a number of functions defined there, for more complex command series:

mk() {
    mkdir $1 && cd $1
}

gclone() {
    git clone "$1" && cd "$(basename "$1" .git)"
}

The mk alias takes a directory name as an argument, mks the directory and then cds into it.

The gclone alias takes a git repo, clones it, and then cds into it.

After adding aliases to your .bash_aliases they should load automatically every time you start a new terminal session.

If you would like to use your aliases in your current session, run:

source ~/.bash_aliases

That's what I can think of for now.

Do you have any favorite tips and tricks?

Please please do share them! I always love learning new ones!

What Are Your Goals For 2021?

Yechiel Kalmenson — Thu, 31 Dec 2020 15:17:28 +0000

It's that time of year when I usually look back at the goals I set for myself a year ago, see how well I did, and set new expectations for the next year.

This past year of course has been... a year. On December 31st 2019, I don't think any of us imagined where we'd be now, yet here we are.

Looking back at my goals from last year, one thing is clear. I did not necessarily accomplish everything I set out to do, but I also had quite a few accomplishments I would never have imagined in the beginning of the year!

Let's first take a look at what I was hoping for:

Comment on What Are Your Goals For 2020?

Yechiel Kalmenson Dec 27 '19

I'll start!

In tech goals, 2020 is the year of Kubernetes for me. I plan on getting more familiar with the eco-system, and maybe even start contributing to the project!

In career goals this is not an aggressive goal for me, but if I can find a job at a company that has all the pros of where I work now, but in addition to that is a remote-first company I'll be very happy :)

And in personal goals, I'm taking up Krav Maga and organizing a course at my synagogue for next year.

Of those three goals:

Kubernetes: turns out my career took a bit of a turn, I joined a new team where the focus was on a different direction, and I did not end up learning as much as I hoped (never mind getting involved in the community). I still hope to get more into that eco-system, but that's taken a place on a back burner for now.
Finding a remote job: in an ironic twist of fate, my current job is now remote (along with many others), and my company communicated that they will be more open to people working from home permanently, even as offices begin to open. So I'll count that as a goal I fulfilled 🙂
Krav Maga: I did start this one. I put together a group in my neighborhood and we met in my house a few times, but then covid put a halt to that so we'll see when that becomes practical again.

On the other hand, there have been a number of accomplishments this year that I would not have imagined a year ago!

My friend Ben Greenberg and I, published the Torah && Tech newsletter for two years now.

In June, we published the first year's worth of newsletters in the Torah && Tech book:

Yechiel Kalmenson

May 19 '20

Announcing Torah && Tech; The Book.

#showdev #books #learning #coding

2 min read

In personal news, also in June, my family grew as we welcomed our son Meir to the family.

So yes, 2020 has been a year. Here's hoping that 2021 only improves.

What about you? What were your 2020 goals? How did you do on them? What are you hoping to accomplish in 2021?

Looking forward to hearing from you in the comments!

Part 2: Add A Dead-Man's Switch To A Rails Application

Yechiel Kalmenson — Fri, 18 Dec 2020 04:57:34 +0000

Ah Yes, Where Were We?

In part 1 of this tutorial, we learned how to set up the part of the deadman's switch that allows us to reset the switch.

In part 2, we will get to the main part; how to set up a script that will run if something happens and the switch isn't reset in a given amount of time.

Rake It In

The standard way of running scripts in Rails apps (and Ruby environments generally) is using Rake tasks.

Rake tasks are, in their most basic form, Ruby scripts that you can run using the command rake [task-name].

In fact, chances are you've run quite a few already! If you've run commands like rails db:setup, rails db:migrate, these are rake tasks that come built-in with Rails for setting up your database!

We can write our own Rake tasks as well. They usually live in the lib/tasks/ directory of our Rails app, and the files use the .rake extension instead of the `.rb extension Ruby scripts usually use.

Let's start by creating a file lib/tasks/deadmans-switch.rake.

In the file, let's put the following:

`ruby
desc "Deadman's Switch"

task :deadman_switch do
puts "Our first task!"
end
`

At this point, we have a very basic Rake task. If you run rake -T in your terminal, you should get a list of all the Rake asks you have available, including this one:

shell rake deadmans_switch # Deadman's switch

On the left side, we have the name of our task, and on the right, the description that we gave it in the first line following the desc keyword.

If we run rake deadmans_switch in our terminal, we should see the following:

shell $ rake deadman_switch => Our first task!

Of course, at this point, our task does nothing more than print a line to let us know it's there, but we can replace that with any Ruby code we want, so let's do that!

Replace the contents of the task with:

ruby if 7.days.ago < Deadman.last_reset puts "Still alive!" else puts "Executing Deadman Switch!" # whatever you want to do goes here end

This script now uses the .last_reset method we put on our DeadmansSwitch class to check when you last reset the switch. If it was less than seven days ago, it just prints "Still alive!" and exits; if you didn't reset the switch in over a week, it'll execute whatever script you tell it to.

Note: I put a week in my script because I figured that was a reasonable timeframe for my needs. You can change that to 2 days, two weeks, a month, a year, whatever you feel the right timeframe for your needs. Ruby's Time class offers great methods for denoting a timeframe, which you can use similar to the 7.days.ago that I used.

Now if you run rake deadmans_switch in the console, you should get:

shell $ rake deadman_switch => Still Alive!

At this point, you can start working on the actual body of the script, which will be different depending on what it is you need a dead man's switch, so I'll leave you to it.

If you want to test and debug the script by running it and don't want to wait seven days for the switch to expire, you can change the 7.days.ago in your if statement to something more reasonable like 7.minutes.ago. Just don't forget to change it back when you're done.

Have You Been Triggered?

Now that we have a script and a way to ensure it only runs after a given time, there's one more thing we need to do. We probably don't want this script to run more than once.

For local scripts that run using a cron job, this isn't such an issue. You can probably use the script to reset the crontab. But this is a script running on Heroku where we don't have access to the scheduler from within the script, so we'll have to get creative.

One option I explored, which turned out to be a dead-end for reasons I'll explain soon, but I'll include it here anyway purely for its entertainment value, was to put the following on the last line fo my script:

ruby File.delete(__FILE__)

__FILE__ is a Ruby constant representing the current file, so what that line of code does is it deletes the current file once it reaches that line. Sort of like those spy movies where you get a note telling you to destroy it once you're finished reading it.

At first, I didn't think it would work. Spending the better part of last year developing for Windows servers and battling numerous "file in use" errors, I was sure Linux wouldn't let me do it either. But I did it just for kicks, and it turns out Linux is a lot more trusting! You can even try it yourself; create a test file, paste the above line of code, run it using Ruby, and watch it disappear!

While that's a pretty fun solution, unfortunately, it won't work for our purposes. Heroku, as mentioned in Part 1, uses an ephemeral file system, so even if we delete the file containing the script, the next time the app deploys, Heroku will do a fresh pull from GitHub, and our file will reappear.

If we want to keep track of whether our script ran, we will need to use something that persists, like a database entry. Fortunately, I'm a psychic who can see into the future, and if you remember, in Part 1, when we created our deamans_switches table, we added a triggered column, and we will now make use of it.

The first thing we will do is add two more methods to our DeadmansSwitch class in app/models/deadmans_switch.rb:

`ruby
def self.triggered
create(triggered: true)
end

def self.triggered?
    where(triggered: true).size > 0
end

The first one, .triggered, creates a new row in the database, but unlike a regular row, we set the triggered column to true.

The second method, .triggered?, queries the database and checks if there are any rows where triggered is set to true and returns true if there is at least one such row.

Now let's go back to our Rake task and put those to use.

The first thing we will do is add the following line at the end of the script after everything we wanted to run ran:

ruby Deadman.triggered

This will enter a row in the database with triggered: true.

Next, all the way at the beginning of our script, in the very first line, we will put the following:

ruby abort if Deadman.triggered?

This will check the database and see if there are any rows where triggered: true and abort the script if it finds any.

Getting Scheduled

At this point, we have a working deadman's switch. The only thing left is to deploy it along with our Rails app and set up a scheduler to run it.

My app is deployed on Heroku, so the instructions will be for getting set up on Heroku. If you have a different setup, things will work differently for you.

So once you've written up all the code, committed it, and pushed it off to Heroku, here is how to go about scheduling your script.

From the Heroku dashboard, navigate to the "Resources" tab.

Once in the "Resources" tab, find the button that says "Find more add-ons" and click on it.

Search for Heroku Scheduler and install it and provision it to your app.

Once it's installed properly, you should see it under add-ons in your resources tab. Click on the link to the Scheduler and then on the button that says "Add Job."

You will be prompted to set a schedule to run your task (I set it to run every night at midnight) and which command to run, which you should set to rake deadmans_switch.

Hit "Save Job," and that's it, you're all set!

Part 1: Adding A Dead-Man's Switch To A Rails Application

Yechiel Kalmenson — Mon, 14 Dec 2020 02:05:09 +0000

Content Warning

The subject of this post is a bit morbid and deals with contemplating our mortality. If that upsets you, feel free to skip the introduction and go straight to the technical parts of the implementation in the section titled "The Good Stuff."

Introduction

I was recently thinking about the concept of a dead man's switch.

For those who are unfamiliar, a dead man's switch is a process that is designed to run automatically unless someone steps in to stop it. The idea is to increase the resiliency and/or safety of a system by having a safety mechanism that will stop it unless someone consciously steps in and overrides it.

One of my favorite examples is in trains where the breaks are engaged by default. To release the breaks, the conductor has to lift a handle or a pedal and keep holding it. The moment the conductor lets go of the pedal, the breaks will engage and stop the train. The idea behind the switch is that if something were to happen and the conductor was to pass out, the train won't continue barreling down the tracks; instead, it would come to a screeching halt immediately.


A ‘deadman’ pedal in a diesel-electric railway locomotive

Many other systems have similar concepts, even if they don't contain physical switches.

For example, a computer might contain a script designed to run automatically after a few days unless the timer gets reset.

For example, many of us have things we might want to happen in the event that something terrible happens to us. Maybe we want to pass on the passwords to important accounts or notify loved ones about a life insurance policy, or perhaps to wipe out some deep dark secret we want no one to find out about.

One way we could go about it is to set a cron job on our computer to run every day. The cron job could look at a file and see when it was last updated, and if it wasn't updated in, say, over a week, it'll run a script that sends an email or does whatever else it is we want it to do.

There's a limitation with that, and that is that it assumes your computer will be on, which is not a given for my personal computer.

The next best option is to have my switch hosted in the cloud somewhere, though that comes with some expenses, and access to reset the times is a little more complicated than updating a file on my computer.

The idea I came up with was to add the switch to my portfolio site. It's the only website I own, so I could do whatever I want with it. I'm already paying for hosting, so there's no extra expense for the switch, so it made sense for me.

The Good Stuff

This post assumes you already have a Rails app and that you have a rudimentary knowledge of Ruby and Rails.

My Rails app is hosted on Heroku. The tutorial's Rails portion should apply to any Rails app no matter where it's hosted, but some of the parts around running the sitch are Heroku specific. However, there are probably parallel mechanisms for other hosting options as well.

There's one part of the tutorial that requires a Twilio account with an associated project. It's not completely necessary, but if you want your switch to send out reminders as it gets closer to triggering, you might want to create a Twilio account.

Creating the account is free, and if you use my referral link, you'll get $10 SMS credit, which should be more than enough for our purposes.

Our dead man's switch will need a few components:

A way to reset the switch.
A script that will run every day and check if you reset the switch.
- If you did reset the switch recently, the script would abort.
- If you did not, the script would do whatever it is you want it to do.
- Once the script runs, we want a way to keep track of that, so it doesn't run again.

We'll start with the way to reset the switch.

If we were hosting this switch locally, a simple way to do this would be to look at the last time a given file was updated, and then keep updating that file every day.

Unfortunately, that wouldn't work for a script hosted on Heroku. Heroku uses an ephemeral filesystem for its apps, and every time the app gets redeployed, or if it crashes and has to be restarted, or even if it's taken down for routine maintenance, Heroku makes a fresh pull on the repo and any changes you made to the filesystem get overwritten.

We have to find a way to keep track of when the switch was reset, and a way that will persist.

I did it by creating a database table where I could enter rows containing a timestamp and then check the timestamp of the last row added.

Once I was already making a table, I figured I could add an ActiveRecord model to my app. That would give me some built-in ActiveRecord methods to interact with my table to read and update it.

Let's Start Generating!

So let's start by opening up our terminal and generating our migration:

rails generate model CreateDeadmansSwitch triggered:boolean

This command created a number of files. The ones we care about are db/migrate/[migration-id]_create_deadmans_switches.rb containing our database migration for a deadman_switches table that has the standard timestamps columns (as well as a boolean column called triggered) we will discuss later).

The second file we care about is in app/models/deadmans_switch.rb that creates our DeadmansSwitch class.

Let's open up db/migrate/20201211142929_create_deadmans_switches.rb:

class CreateDeadmansSwitches < ActiveRecord::Migration[5.2]
  def change
    create_table :deadmans_switches do |t|
      t.boolean :triggered

      t.timestamps
    end
  end
end

Before we run this migration, let's make one small change:

-    t.boolean :triggered
+    t.boolean :triggered, default: false

We added a default value of false to the triggered column, so that is the value it will contain unless we specify otherwise.

Now we can go back to our terminal and run:

rails db:migrate

That will run our migration and add the deadmans_switches table to our database schema.

Models Models Everywhere

Now that we have our database set up let's look at our model in app/models/deadmans_switch.rb.

Currently, our model is pretty empty:

class DeadmansSwitch < ApplicationRecord
end

Let's add two class methods to our class; one to reset the switch and one to check when it was last reset:

class DeadmansSwitch < ApplicationRecord

    def self.reset
        create
    end

    def self.last_reset
        last&.created_at || Time.now
    end

end

We added two class methods.

The reset method creates a new instance of the DeadmansSwitch class, adding a new row to the database.

The last_reset method looks at the last row in the database and, if it finds one, returns the date and time it was created on; otherwise, it returns the current time (this is to protect against an edge case where we run the app before we rest the switch for the first time).

Routing

Next, we need a route that will listen for, and trigger our switch.

My setup relies on two assumptions that apply to my app.

First, I have an AdminController that handles all the admin-related routing in my app.

Second, in my AdminController, I have a helper method called is_admin? that checks if the current user is an admin.

The details of your app may vary, so adjust accordingly.

In config/routs.rb add the following:

get 'deadman/reset', to: 'admin#reset'

This sets up a route at /deadman/reset and routes it to the reset function in my AdminController and gives us access to a deadman_reset_path function that points to the new route.

If you have your app running, don't forget to restart it in the terminal for any routing changes to take effect.

Next, let's add that function in AdminController (or whichever controller you decided to use for your app):


    def reset
        if is_admin?
            DeadmansSwitch.reset
            redirect_to admin_root_path
        else
            redirect_to login_path
        end
    end

This checks if the current user is an admin (you don't want just anyone who happens upon the URL to have the ability to reset your switch).

If the user is an admin, we call DeadmansSwitch.reset and redirect back to the page that called it; in my case, to the admin page (again, the routing in your app might be different, so adjust accordingly).

What A View!

Now that we have that in place let's use it in our app.

Where exactly you put this in your app depends on the layout of your app. Ideally, you would put it in a part of your app that only you can access, like an admin console or something.

This is what I have in my app, feel free to style it as elaborately, or plainly, as you wish:

<%= link_to "Reset Switch", deadman_reset_path %> <small>(Last reset <%= time_ago_in_words Deadman.last_reset %> ago)</small>

This creates a link to our reset route, followed by a small helpful note which uses the time_ago_in_words helper method to display when the last time you reset the switch.

Here is what it looks like on my portfolio:

So now we have part of our dead man's switch in place, the part where we can reset it every day, so it knows we're still around and doesn't trigger our script.

In part 2, we will speak about how to write the script that checks our switch and runs if we haven't reset it in a while.

What are your favorite Kotlin resources?

Yechiel Kalmenson — Mon, 26 Oct 2020 13:01:57 +0000

Hey all!

I recently joined a new team and we do most of our work with Kotlin.

It looks like a great language to work with, and I'm looking for resources to help me ramp up.
Something for someone familiar with programming concepts, and looking to ramp up on the Kotlin specifics, conventions, and best practices.

I'm a hands-on learner, and I learn best by trying thongs out and breaking them, so those are the resources I'm mostly looking for.

Something like Go's A Tour Of Go.

Any ideas?