DEV Community: christine

A Simple Tmux Script for Your Daily Dev Session

christine — Mon, 06 Apr 2026 21:31:09 +0000

A couple of years ago I wrote about copying text between tmux panes. At the time I was still figuring out how all the pieces of my terminal setup fit together (a recurring theme, honestly). Since then, tmux has become the first thing I open every morning. I wrote a small bash script that sets up my dev session, and I've tweaked it enough times that I thought it was worth sharing where it ended up.

Where I Started

My first version created a four-pane layout:

+------------------+------------------+
| nvim             | rails server     |
+------------------+------------------+
| lazygit          | claude           |
+------------------+------------------+

Neovim for editing, Rails server running bin/dev (which kicks off Overmind with the full Procfile.dev), lazygit for staging and committing, and Claude Code for when I need a second brain. It felt very productive to look at. Four panes! Everything visible! I am a real developer!

And then I actually used it for a while. The Rails server pane just... sat there, taking up screen real estate while I was writing code that didn't need a running server. Lazygit is great, but I reach for git status and git diff in a regular shell just as often. And four panes on a laptop screen? Everything is tiny.

Where I Landed

Two panes. A shell on the left, Claude Code on the right.

+------------------+------------------+
| shell            | claude           |
+------------------+------------------+

The shell handles whatever I need in the moment: editing, git, spinning up the server, running tests. Turns out I don't need a dedicated pane for each tool. I just need a place to work and a place to think out loud.

The Script

The full script is in my dotfiles, but here's what it does:

#!/bin/bash

# Universal Development Session Script
# Creates a 2-pane tmux layout for any Rails project or worktree
# Usage: ./dev-session [session-name] [directory]

# Configuration
DEFAULT_EDITOR="nvim"
DEFAULT_PORT="3000"

get_current_dir() {
    pwd
}

get_project_name() {
    basename "$(get_current_dir)"
}

get_branch_name() {
    if git rev-parse --git-dir > /dev/null 2>&1; then
        git branch --show-current 2>/dev/null || echo "main"
    else
        echo "no-git"
    fi
}

generate_session_name() {
    local project_name=$(get_project_name)
    local branch_name=$(get_branch_name)

    if [[ "$branch_name" != "main" && "$branch_name" != "develop" && "$branch_name" != "no-git" ]]; then
        safe_branch=$(echo "$branch_name" | sed 's/[\/:]/-/g')
        echo "${project_name}-${safe_branch}"
    else
        echo "$project_name"
    fi
}

SESSION_NAME="${1:-$(generate_session_name)}"
WORK_DIR="${2:-$(get_current_dir)}"

if [[ ! -d "$WORK_DIR" ]]; then
    echo "Error: Directory $WORK_DIR does not exist"
    exit 1
fi

# Reattach if session already exists
if tmux has-session -t "$SESSION_NAME" 2>/dev/null; then
    echo "Session '$SESSION_NAME' already exists. Attaching..."
    tmux attach-session -t "$SESSION_NAME"
    exit 0
fi

# Create session and split into two panes
tmux new-session -d -s "$SESSION_NAME" -c "$WORK_DIR"
tmux split-window -h -c "$WORK_DIR"

# Left pane: shell, right pane: Claude Code
tmux send-keys -t 1 "# Ready for commands (server, etc.)" C-m
tmux send-keys -t 2 "claude" C-m

tmux select-pane -t 1
tmux rename-window "dev"
tmux attach-session -t "$SESSION_NAME"

I alias it in my shell config so I can run dev from any project directory:

alias dev="~/Documents/Repos/dev-scripts/dev-session"

The Parts I Actually Like

It names sessions from your git branch. If I'm on main, the session is just the project name (qualify). On a feature branch, it tacks on the branch name (qualify-fix-event-registry). Slashes in branch names get swapped to hyphens so tmux doesn't choke on them.

This is my favorite part, because I usually have multiple sessions going at once, one per feature branch or worktree. tmux list-sessions gives me a quick snapshot of what I've got cooking:

qualify: 1 windows (created Thu Apr  3 09:15:00 2026)
qualify-add-snapshot-tests: 1 windows (created Thu Apr  3 10:30:00 2026)
rubygems: 1 windows (created Wed Apr  2 14:00:00 2026)

It won't create duplicates. If a session with that name already exists, the script just attaches to it. Detach with Ctrl-b d, go make coffee, come back, run dev again, and you're right where you left off. Sessions survive sleep/wake cycles too, which still feels like magic to me.

It works anywhere. The script doesn't assume Rails or even git. I use it for this blog, for Ruby gems, for random one-off scripts. If there's a git repo, it uses the branch name. If not, you just get the directory name. No fuss.

The Claude Code Pane

The right pane launches Claude Code automatically. I like having it right there instead of in a separate terminal window. I can glance over at its output while I'm working, and Ctrl-b z (tmux zoom) is my best friend here, blowing the Claude pane up to full screen when I'm reading a longer response and then popping back to the split.

The other nice thing is that Claude Code's context stays warm. I can ask it something, go write code in the left pane for twenty minutes, come back and ask a follow-up without re-explaining everything. That alone is worth the dedicated pane.

Things I'd Change

My .tmux.conf is still embarrassingly minimal. It's literally just a scrollback buffer increase. The README in my dotfiles repo documents vim-style pane navigation bindings that I haven't actually configured yet. I will get to it. Eventually. (I tell myself this every week.)

The four-pane version (dev-session-fixed) is still sitting in the repo too. I keep it around for when I'm debugging something where I really do need server logs visible the whole time. But I haven't reached for it in weeks, which tells me something.

Try It

Grab the script from my dotfiles, drop it somewhere in your path, and alias it. The only real dependency is tmux itself. If you don't have Claude Code installed, no worries, that pane just becomes a regular shell.

cd your-project
dev

That's it. Two panes, named after your branch, ready to go.

How to Run a Virtual Lean Coffee for Your Meetup Community

christine — Wed, 01 Apr 2026 23:45:12 +0000

For the March WNB.rb meetup, I tried something different. Instead of our usual speaker format, I facilitated a Lean Coffee online, a structured but agenda-less discussion where attendees set the topics and vote on what to talk about. It went really well, and I wanted to share how it worked in case you're thinking about trying one yourself.

What is Lean Coffee?

Lean Coffee is a meeting format where there's no pre-set agenda. Participants propose topics at the start, vote on what interests them most, and then discuss in priority order with timeboxed rounds. When the timer runs out, the group votes to keep going or move on. Simple as that.

The Setup: What We Used

I used Lean Coffee Table for the board and Google Meet for video. Lean Coffee Table handles the topic cards, voting, timer, and topic flow, and participants don't need to create accounts. I pre-loaded some seed topics to get things started, pasted the Google Meet link into the board, and shared one link with attendees. That was it for setup.

The seed topics were a mix: AI and how it's changing our work, Ruby and Rails in 2026, and some fun wildcards like "If you had to explain your job to a medieval peasant, what would you say?" I put the wildcards in as energy resets if things got heavy, but honestly the group gravitated toward topics that were practical and personal all on their own.

What We Actually Talked About

We had 17 attendees, and between the seed topics and what the group proposed, there was plenty to choose from. The three that got the most votes were:

"What makes good team work in software engineering?" (6 votes) - This one got the most votes, and the conversation did not disappoint. Communication was the obvious starting point, but the group went way beyond that. We talked about shared troubleshooting, actually collaborating on problems together instead of tossing tickets over the wall, and giving gracious feedback, in and out of pull requests. The part that really stuck with me: connecting on a human level and meeting people how they communicate, not just how you prefer to.

"Where do you draw the line on what you let AI write vs. what you write yourself?" (5 votes) - This one got lively. Someone summed it up perfectly: "AI makes it work, I make it right." Everyone agreed that everything feels different now, but the group was surprisingly practical about it. The big takeaway: if you don't understand the generated code, ditch it and write it yourself. Can't argue with that.

"What's the best advice you've ever received?" (5 votes) - OK, this one hit different. The group shared some real gems: "Know what you want, and know how to ask for it." "Done is better than perfect." Someone recommended the book Burnout: The Secret to Unlocking the Stress Cycle (adding it to my list). "The most important project you manage is your life." And my personal favorite: "Would your 85 year old self be proud of you?" I'm still thinking about that one.

Topics We Didn't Get To

That's the thing about lean coffee: you won't get to everything, and that's fine. The voting means the stuff people care about most floats to the top. We had some great ones waiting in the wings: "If your codebase were a kitchen, what state is it in right now?", the medieval peasant question, onboarding strategies, and a few more AI topics. Definitely saving some of these for next time.

One thing I found interesting: the more technical Ruby/Rails topics (Ruby 4.0's ZJIT, Hanami 2.3) got zero votes. People wanted to talk about the human side of building software. I think that says something about where everyone's heads are at right now.

What Worked

Lean Coffee Table + Google Meet was the right combo. The tool handled voting and timers smoothly, and the auto-generated PDF summary at the end meant I didn't have to scramble to take notes during the session.

Seed topics helped, but didn't take over. I pre-loaded a bunch of conversation starters so nobody had to stare at a blank board, but the group also came up with their own topics (onboarding strategies, interview processes, team belonging) that got just as many votes.

Everyone had a voice. The voting and timer mechanics naturally spread things out. No one person can dominate when the group decides what to discuss and when to move on. That matters a lot for a community like WNB.rb.

An hour was the right length. Three topics in depth felt like the right pace. I'd rather go deep on fewer topics than rush through a bunch.

What I'd Do Differently

Next time I'd spend a little more time explaining the format upfront. A few folks hadn't done lean coffee before, and walking through the voting and timer mechanics at the start would have saved some confusion in the first few minutes.

I'd also trim down the seed topics. I had a lot pre-loaded, and a shorter list might push people to come up with more of their own.

Would I Do It Again?

In a heartbeat. Not every meetup needs a speaker and slides. Sometimes the best stuff comes from just giving people space to talk about what's actually on their minds. That's exactly what happened here, and I'd love to make this a regular thing.

Want to Run Your Own?

If you're an organizer thinking about trying a virtual lean coffee for your community, here's the short version of what worked for us:

Lean Coffee Table for the board, voting, and timer. Free, no accounts needed for participants, and it generates a PDF summary when you're done. Honestly this tool did most of the heavy lifting.
Google Meet for video. Nothing fancy, just screen share the Lean Coffee Table board so everyone can follow along. Any video tool works here.
Pre-load 8-10 seed topics across a few categories so nobody stares at a blank board. But keep the list short enough that people feel encouraged to add their own.
5-minute timer per topic, with the group voting to extend or move on. Three topics in an hour felt right.
Share one link. I pasted the Google Meet link into the Lean Coffee Table board and only shared the board link. One less thing for attendees to keep track of.

The voting and timers do a lot of the facilitation work for you, everyone gets a say in what gets discussed, and no single person can take over the conversation. If that sounds like your kind of meetup, give it a shot.

A Note About WNB.rb

Full disclosure: I'm on the WNB.rb board, so I'm obviously not unbiased here. But I genuinely think this is one of the best communities in the Ruby world. It's a welcoming, supportive space for women and non-binary Rubyists, and the people who show up every month are the reason I keep coming back.

WNB.rb is officially a non-profit, and if you'd like to support what we're doing, you can find out more at wnb-rb.dev/sponsor-us. Every bit helps us keep the meetups running, support our speakers, and grow the community.

Why Your GitHub Actions Secrets Don't Work in Reusable Workflow Inputs

christine — Fri, 13 Feb 2026 19:04:40 +0000

We recently migrated our Docker build workflows to use a shared reusable workflow. The migration looked straightforward: extract the build steps, parameterize the inputs, and call the shared workflow with secrets: inherit. CI immediately broke.

Invalid workflow file (Line: 15, Col: 19):
Unrecognized named-value: 'secrets'

The fix took 20 minutes. Understanding why took longer, and every answer led to another "but wait" question.

The Setup

The calling workflow passed a Rails master key as a build arg:

jobs:
  build:
    uses: our-org/shared/.github/workflows/build-image.yml@main
    secrets: inherit
    with:
      build_args: |
        RAILS_MASTER_KEY=${{ secrets.RAILS_MASTER_KEY }}

This fails at parse time. GitHub validates the workflow file before anything runs and rejects secrets in that with: block.

Job-Level `with:` Is Not Step-Level `with:`

This is where it gets confusing, because with: appears in two very different places in a workflow file, and they have different rules.

Step-level with: passes inputs to an action. The secrets context is available here:

steps:
  - uses: docker/build-push-action@v6
    with:
      build-args: RAILS_MASTER_KEY=${{ secrets.RAILS_MASTER_KEY }}  # works

Job-level with: passes inputs to a reusable workflow. The secrets context is not available here:

jobs:
  build:
    uses: org/repo/.github/workflows/shared.yml@main
    with:
      build_args: ${{ secrets.RAILS_MASTER_KEY }}  # fails

The contexts reference documents this in a table. For jobs.<job_id>.with.<with_id>, the allowed contexts are:

github, needs, strategy, matrix, inputs, vars

No secrets.

But the Docs Say Secrets Are Available "From Any Step in a Job"

The secrets context documentation says:

This context is the same for each job in a workflow run. You can access this context from any step in a job.

That's true, for steps. The job-level with: on a reusable workflow call is not a step. It's a job-level declaration that gets parsed and validated with a restricted set of contexts before any job runs.

But I Have `secrets: inherit`

The reusable workflows docs explain that secrets: inherit implicitly passes secrets to the called workflow. And it does. At runtime, the called workflow's steps can reference secrets.RAILS_MASTER_KEY directly.

The problem is that with: is evaluated on the caller side. secrets: inherit makes secrets available inside the called workflow, not in the caller's with: expression. These are two parallel channels:

with: sends named inputs (restricted contexts, validated at parse time)
secrets: sends secrets (available at runtime in the called workflow's steps)

But What About Org vs Repo Secrets?

Doesn't matter for this error. secrets: inherit passes both org-level and repo-level secrets to the called workflow. The error is a static validation failure at parse time. GitHub isn't even looking at which secrets exist or where they're stored. It's rejecting the secrets context in with: regardless.

The Fix

Pass the secret name as a string through with:. Resolve it inside the called workflow where secrets is available.

In the calling workflow:

with:
  master_key_secret: RAILS_MASTER_KEY  # plain string, no secrets context

In the shared workflow, add an input and resolve it in the build step:

on:
  workflow_call:
    inputs:
      master_key_secret:
        description: "Secret name for Rails master key (empty to skip)"
        required: false
        type: string
        default: ""

# In the build step:
build-args: |
  ${{ inputs.master_key_secret != '' && format('RAILS_MASTER_KEY={0}', secrets[inputs.master_key_secret]) || '' }}

The secrets[inputs.master_key_secret] pattern dynamically looks up a secret by name. It's the same approach GitHub's own docs use for parameterized registry credentials. The input defaults to empty, so repos that don't need it aren't affected.

The Takeaway

Two things that look the same in YAML, with: on a step and with: on a reusable workflow call, have fundamentally different context availability. If you're migrating from inline steps to reusable workflows and your secrets.* references break, that's why. Pass the name, not the value.

References:

Contexts reference, context availability table
Reusing workflows, secrets: inherit and workflow inputs
Secrets context, "available from any step in a job"

The Quiet Work that Keeps Ruby Alive

christine — Mon, 09 Feb 2026 22:53:14 +0000

I've written some critical things about Ruby Central. I've also written about choosing to contribute anyway, because the community matters more than the org chart. So when the January 2026 newsletter landed in my inbox, I read it with a specific question: is Ruby Central showing up for the people who make this ecosystem work?

The short answer: yes, in some meaningful ways.

The Gala Awards

Ruby Central is hosting a gala with awards that recognize the kinds of contributions that often go uncelebrated. And the honorees they've chosen say a lot about what the community values right now.

Ruby Heart Award -- Emily Samp

The Ruby Heart Award honors extraordinary compassion and service to the community. Emily Samp is an Engineering Manager at Shopify, where she works on improving the Ruby development experience through open source tools like Sorbet and Prism. She's also an organizer and co-founder of WNB.rb, and current CEO of the group.

That combination matters. Working on Sorbet and Prism makes every Ruby developer's experience better. Co-founding WNB.rb makes sure "every Ruby developer" actually means everyone. She's doing both at the same time, and that's not an accident.

Ruby Guidepost Award -- Saron Yitbarek

The Guidepost Award recognizes mentorship and guidance of the next generation, and Saron Yitbarek is the right person for it. Saron is the founder of CodeNewbie (now owned by DEV), a developer, speaker, and podcaster. I've had the pleasure of seeing her speak at RubyConf and NDC London.

If you've ever been new to programming and found a community that made you feel like you belonged, there's a good chance Saron's work had something to do with it. CodeNewbie created space for people who were just starting out, at a time when "beginner-friendly" wasn't really a thing yet in tech.

Cutting Edge Award -- Nadia Odunayo

The Cutting Edge Award goes to bold experimentation and boundary-pushing work. Nadia Odunayo founded The StoryGraph, a book-tracking app that has grown to over 4 million users as a privacy-focused alternative to Goodreads. I'm a huge fan.

And here's the thing -- The StoryGraph is built with Ruby. Millions of people use it every day who have no idea what Ruby is. That's what pushing the boundaries of this ecosystem actually looks like.

Community Leadership Gem Award -- You Decide

The one that caught my attention is the Community Leadership Gem Award, which is community-nominated. That matters. Letting the community choose who to celebrate instead of a board making that call from the top down is a small but meaningful shift toward the kind of governance I've been asking for.

If you know someone doing quiet, consistent work to make the Ruby community better, nominate them.

New Board Members

Three new members joined the Ruby Central board:

Brandon Weaver has been writing Ruby for 15 years and is known for his conference talks and education work. Having someone on the board who's been in the trenches as a speaker and educator is good representation. He is good people, and will be pushing for communication and transparency with the board. No one knows Ruby like Brandon and I'm really excited to see what he does on the board.

Ran Craycraft is the Managing Director at thoughtbot. Thoughtbot has a long history of contributing to the Ruby ecosystem through open source and mentorship, so this feels like a natural fit.

Jey Flores leads Product Engineering at Code for America and previously worked at Bandcamp. Bringing in someone from the civic tech space broadens the perspective on who Ruby serves and how.

The RubyGems situation showed what happens when leadership stops listening to the people doing the work. Fresh voices on the board could help with that.

WNB.rb and the Volunteers Who Build Community

This is the part of the newsletter that I love is called out but heads up that I'm biased when it comes to WNB.rb. I've been a member of the community since it was founded and have joined up on WNB.rb's board. So the community means a lot to me, and I am so happy it is being shared in the newsletter.

WNB.rb (Women and Non-Binary Rubyists) group is transitioning from a founder-led organization to a community-managed one. That's hard work, and it's how you make something last.

The newsletter highlights two people by name:

Sarah Eggleston, WNB.rb's Deputy CTO, who's helped grow the community and make it a place people actually want to show up to. And Jess Sullivan, the Book Club Lead, who makes it okay to not know things yet. Both amazing people, who care deeply about Ruby and WNB.rb.

That last part is worth sitting with. Jess is normalizing imperfect learning. That doesn't show up on a GitHub contribution graph, but it changes how people experience this community.

WNB.rb's mission of making the Ruby community accessible to marginalized individuals entering tech is worth paying attention to. If you're not already involved, look into it and support the mission.

Looking Ahead

The newsletter also covers some forward-looking items worth noting:

RubyConf 2026 is heading to Red Rock, Nevada, with a new "Ruby Runway" pitch competition for Ruby-based projects
RubyGems.org Organizations is in private beta, adding multi-maintainer gem management (a feature that directly addresses some of the collaboration pain points I've seen firsthand)
Google Summer of Code is looking for Ruby projects and mentors, with a focus on AI/ML and security

What This Means

Governance issues don't resolve in a few months, and trust takes time to rebuild. But spotlighting community volunteers by name, letting the community nominate its own awards, bringing in new board members -- that's Ruby Central showing that it knows the community matters. I'm really liking what I'm seeing with the continued communication.

The newsletter discussed in this post: Ruby Central README: January 2026

Contributing to RubyGems (.org)

christine — Wed, 28 Jan 2026 18:58:44 +0000

A few months ago, I wrote about a move that bypassed the maintainers who had built the RubyGems and Bundler projects for decades. I had some questions about trust, governance, and whether Ruby Central could be a responsible steward of our community's infrastructure.

So it might seem strange that I recently submitted a pull request to rubygems.org.

This post is about that contribution, but it's also about a question I had to answer for myself: Why help a project when you have concerns about the organization running it?

The Short Answer: the code doesn't belong to Ruby Central. It belongs to the community.

When I contribute to rubygems.org, I'm not endorsing Ruby Central's past governance decisions. I'm improving a piece of infrastructure that every Ruby developer depends on, including me, including my team, including developers who have no idea any controversy exists.

The people reviewing my PR weren't board members making decisions. They were developers like me, with their time spent making the Ruby ecosystem better. Withholding contributions punishes them, not the people who had made the past governance decisions.

The Problem That Got Me Involved

My team had adopted a shared GitHub Actions workflow for releasing our gems. Instead of duplicating release logic across repositories, we maintain one canonical workflow and call it a shared gem release, It's similar to this:

# In my-gem/.github/workflows/release.yml
jobs:
release:
uses: our-org/shared-workflows/.github/workflows/ruby-gem-release.yml@main

Clean pattern, common in organizations with multiple gems. One problem: RubyGems.org's trusted publishing feature didn't support it.

When you use a reusable workflow, the OIDC token from GitHub points to the shared workflow's location, not your repository. RubyGems.org expected these to match. Our releases were failing. I needed to revert back the old flow, where we have slight release difference in each repo. Not ideal.

I found https://github.com/rubygems/rubygems.org/issues/4294 from 2023. No one had fixed it, yet.

Choosing to Contribute

I had options. I could work around the limitation. I could complain on social media. I could wait for someone else to fix it.

Instead, I decided to fix it myself.

Here's my reasoning: Open source is bigger than any single organization. RubyGems existed before Ruby Central, and the codebase will outlast whatever governance structure exists today. Contributing good code, code that helps developers, is worthwhile regardless of organizational politics.

If you are going to contribute, you might as well do it well, so here are some tips doing just that and that I kept in mine with my RubyGems feature.

Structure Your Commits Like a Story

Maintainers review a lot of code. Help them follow your thinking: Clear summaries, explanation of why not just what, security implications called out, and reviewer contributions credited.

Write a PR Description That Respects Their Time

Your description is your pitch. Answer these questions immediately:

What problem does this solve?
How does it solve it?
Are there security implications?
How can reviewers verify it works?

Mine looked roughly like: Enables trusted publishing for gems using reusable workflows from external repositories

Short. Scannable. No mystery about what's happening.

Tests Are Your Credibility

Comprehensive tests tell maintainers you've thought through edge cases:

The test names describe scenarios. A reviewer can understand what's verified without reading implementation details. And the security test verifying that mismatched workflows are rejected, matters a lot for authentication code.

Receive Feedback Graciously

This is where contributing gets genuinely valuable. The reviewers know the codebase. Their feedback makes your code better.

I received two pieces of feedback that improved my implementation:

"The validation is tricky to understand. Could we use declarative Rails validations?"

My original:


def workflow_repository_fields_consistency
owner_present = workflow_repository_owner.present?
name_present = workflow_repository_name.present?
return if owner_present == name_present
errors.add(:base, "…")
end

The suggestion:


validates :workflow_repository_owner, presence: true, if: -> { workflow_repository_name.present? }
validates :workflow_repository_name, presence: true, if: -> { workflow_repository_owner.present? }

Same behavior, more idiomatic.

"This query branch is unreachable given your other validation."

Dead code I hadn't noticed. The reviewer spotted that my .or() clause could never match because another validation prevented that data state from existing.

Both changes made the code better. I implemented them, credited the reviewers, and the PR was approved.

The Bigger Picture

After my code contribution was merged, I submitted a documentation PR to https://github.com/rubygems/guides explaining how to configure the new fields. Features don't help if users don't know they exist.

Now every Ruby developer using shared release workflows can use trusted publishing. That's a small improvement for potentially thousands of people.

But here's what I keep coming back to: the people who reviewed my PR, who gave thoughtful feedback, who approved and merged the changes. They're developers who care about the Ruby ecosystem. They showed up, they did good work, and they made the project better.

Open source is ultimately about people, not organizations. The code is written by individuals. The reviews are done by individuals. The community is made up of individuals who choose to contribute their time.

Ruby Central's past governance may have disappointed me. But the Ruby community hasn't.

If You're Hesitant to Contribute

Maybe you have concerns about other projects' leadership. Here's what I'd say:

Contribute to the code, not the org chart. Your pull request improves software that real people use. The maintainers aren't the executives. Don't punish them for decisions they didn't make.

Find a problem you care about. Fix it. Submit the PR. The Ruby ecosystem, our community, is worth contributing to.

The PR discussed in this post is https://github.com/rubygems/rubygems.org/pull/6184. The documentation update is https://github.com/rubygems/guides/pull/410.

Originally Posted on https://christine-seeman.com/contributing-to-rubygems-org/

What Just Happened to RubyGems?

christine — Wed, 24 Sep 2025 04:11:06 +0000

By christine September 23, 2025, edited and updated September 25, 2025

And Why We Should Care

Based on some solid reporting by Joel Drapper and Ellen’s breaking details

So, the Ruby community just went through something wild, and I think we need to talk about it. On September 9th, Ruby Central basically took over the RubyGems GitHub repos and gem ownership without asking the people who’ve been maintaining them for years. It’s… not great.

TL;DR

What happened: Ruby Central asserted control over RubyGems and bundler repos and ownership, blurring lines between running the service and owning the code.
Why it’s a problem: Community‑built code isn’t corporate property; governance requires consent, transparency, and accountability.
Bundler context: André Arko clarified Bundler’s code is community-owned, registered the trademark to prevent unilateral claims, and intends to transfer it to a democratic, community‑led org (his post).

The Story (As Best I Can Tell)

Joel Drapper did some really impressive investigative work here, and here’s what seems to have happened:

The Money Problem: Ruby Central lost $250k a year from Sidekiq after they had DHH speak at RailsConf 2025. That left them pretty much dependent on Shopify for funding.
The Pressure: Shopify apparently said “take control of RubyGems or we’re pulling our funding.” That’s… a pretty clear ultimatum.
The Messy Execution: HSBT went ahead and added Marty Haught as an owner and changed permissions before anyone really talked about it. When people complained, Marty said it was a mistake and some changes got reverted, but Marty stayed as owner.
The Board Vote: Even though Marty warned them about the consequences and suggested alternatives (like forking), the Ruby Central board voted to do the takeover anyway. And Marty went ahead and did it.

Here’s What Really Bugs Me

The whole thing comes down to this: Ruby Central is confusing two completely different things:

RubyGems (the open source code): This belongs to the community. People have been working on this for decades, unpaid, because they care about Ruby.
RubyGems Service (the website and servers): This is Ruby Central’s thing. They run the actual rubygems.org site.

Just because Ruby Central pays some people to work on the service doesn’t mean they own the open source code. That’s like saying you own Rails because you sponsored someone who made a PR to Rails. It doesn’t work that way.

The Communication Has Been Terrible

Honestly, this is what’s been most disappointing. Ruby Central’s response felt like corporate speak with no one willing to put their name on it. Board members keep saying things like “Ruby Central has been responsible for RubyGems for a long time” when that’s just not true—they’ve been responsible for running the service, not owning the code.

So… What Now?

How do we protect community projects?

When corporate money is involved, how do we make sure the community still owns what it built?

What about transparency?

How do we prevent stuff like this from happening again? And when hard decisions need to be made, how do we make sure everyone’s actually talking to each other?

Corporate influence is tricky.

We need corporate support to keep things running, but how do we draw the line between “helping” and “taking over”?

Trust is broken.

Can we still trust Ruby Central to look after our infrastructure when they’ve shown they’ll take over community projects if a big company tells them to?

Look, I get that running infrastructure is hard and expensive. But this wasn’t about infrastructure—this was about taking control of open source code that belongs to the community. And doing it under the guise of “supply chain security” when it was really about corporate pressure just makes it worse. The Ruby community deserves better than this.

What Adarsh adds to the picture

From Adarsh’s as a former Ruby Central director: Mastodon thread

He talks about the very real operational and funding pressures Ruby Central faces.
Underscores the importance of clarity between running critical infrastructure (operator responsibilities, access, accountability) and stewarding community code (governance, consent, legitimacy).
And points toward constructive next steps: explicit agreements, transparent governance, and rebuilding trust with maintainers rather than asserting ownership through access.

The through‑line is pragmatic: secure the service, but do it in a way that respects community ownership and doesn’t burn the social capital the ecosystem relies on.

Quick recap: Bundler, RubyTogether, and community ownership

Bundler belongs to the community: André Arko registered the trademark to protect the project’s name from unilateral claims and commits to transfer it to a democratically accountable, community-led org.
Licenses and code stay open: The code remains MIT; the real issue is governance, not access.
Bottom line: Fund maintainers. Secure the service. According to the RubyTogether merger, Bundler’s code was never Ruby Central’s to claim and he wants to protect the name for the community and keep governance with maintainers.

Sources: Joel Drapper's deep dive, Ellen's initial report, Adarsh (former Ruby Central director), Mastodon thread, André Arko on Bundler & community

Save your sanity – add a modifier key to your MacOS Hot Corners

christine — Tue, 15 Apr 2025 19:57:29 +0000

I like the convenance of using Hot Corners to lock my screen. It just works for me. I know way, way too many keyboard shortcuts. Depends on what I am in, but I have been trying to shove Vim and tmux keybindings into by brain for years…and now with switching over to Cursor I have different ones to remember now.

So, don’t get me wrong, I like keybindings just like any other software dev does…but sometimes you just want to lock your screen. There is nothing like dragging your mouse to a corner and it is just done. That is till you do it to yourself 3 times while on a video meeting, that’s when you start thinking to yourself that there has got to be something better.

And that something is adding a modifier key. Brilliant, simple and you can still use hot corners without going nutty. So how do you stop activating Hot Corners accidentally?

Go to System Preferences > Mission Control, then click on Hot Corners.
Select any of the four active corners of your screen, and a drop-down menu appears. (my new option is the upper right corner)
To assign a modifier key, press and hold the key (Shift, Command, Control, or Option, choose one) then pick an action, like Lock
Screen.

You are in control now! Or should I say command, because now just scrolling to the upper right corner won’t trigger that lock screen. You’ll have to add an extra keystroke for that, and that shouldn’t be too much to remember, just one extra key.

Bringing together Mastodon and WordPress

christine — Wed, 11 Oct 2023 21:48:34 +0000

Reading Time: 2 minutes

WordPress.com announced the release of the ActivityPub plugin on their blogs in October, I don’t use WordPress.com but it did make me aware of the plugin so I decided to give it a go.

I have been on Mastodon (the excellently run ruby.social instance) since November 4th, 2022. Coming from the bird site, it was a bit of a shock but in a good way. But it was also confusing, just like when you had to learn about Git coming from a CVS system like Subversion, one is distributed and one is centralized.

Now, with the ActivityPub plugin, I can make my WordPress site and posts publish to a federated profile and have people reply to that on ActivityPub but show up as WordPress comments. It is it’s own feed! This sounded pretty nifty, but my setup wasn’t just plug-and-play and required a bit more configuration than what was addressed in the WordPress.com announcement.

I am on Flywheel as my WordPress host, and it seems like I might need some additional redirects in my .htcaccess because in my site health, my webfinger kept on 404ing. But Flywheel doesn’t allow direct htcaccess but I can add redirectsthrough the flywheel site. My first attempt at adding a redirect didn’t quite work as expected, I got instead a redirect to “https://wp-json//activitypub//1/.0//webfinger?resource=acct:christine@christine-seeman.com”, which does not work.

Flywheel’s Add Redirect page for a site, this setup turned out to be not be the correct regex.

I am trying to simplify the redirect and make sure it hits the proper webfinger for ActivityPub (Mastadon)

This worked! So I needed to add into my source redirect ^/.well-known/webfinger(.*)$ and then for my destination /wp-json/activitypub/1.0/webfinger$1 and now you can subscribe to my infrequent posts from my blog, hi-from@christine-seeman.com, or from me as an author (which umm not so many other authors on my website) christine@christine-seeman.com.

Best of luck tying your WordPress and Mastodon/ActivityPub together.

How to copy text from one pane – MacOS/Tmux/Alacritty

christine — Wed, 03 May 2023 17:54:19 +0000

My problem? I only want to copy text from one tmux pane, not across two.

But I was finding that my mouse was failing me, and I knew there had to be a better way than just closing out my panes and only having one open. My journey on understanding terminals, shells, editors, and how to use them correctly has been rocky, but I have been feeling in a good place lately. The current setup that I am using is bash shell (starship shell prompt for that added sparkle), Alacritty terminal, Neovim editor, and Tmux for running multiple terminals. I had gotten this all configured, which probably took too much time. Debugging your developer setup is a considerable learning experience, but developers (meaning me) sometimes (all the time) make it more complicated than it needs to be. I probably didn’t need to throw in attempting to theme everything too, but I like my consistent look.

In my search to figure out how to copy the text on one pane, some Linux solutions were close to what I needed but not 100% the way there. This setup got me all the way there with a solution that should fit nicely in my vim workflow.

The suggested Linux setup is a good start but does not work great for MacOS

 bind-key -T copy-mode-vi v send-keys -X begin-selection
 bind-key -T copy-mode-vi y send-keys -X copy-selection
 bind-key -T copy-mode-vi r send-keys -X rectangle-toggle

For MacOS, add the following onto your tmux configuration (for ex. at ~/.tmux.conf). This solution came from a superuser post from user jeremysprofile.

setw -g mode-keys vi
set -g set-clipboard off
bind-key -T copy-mode-vi v send-keys -X begin-selection
# bind y key in copy mode to select and copy to system clipboard
bind-key -T copy-mode-vi y send-keys -X copy-pipe-and-cancel "pbcopy"
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "pbcopy"

The configuration will add some vi key bindings, and then to supercharge tmux copy mode. For copying and pasting, reach for typical vim keybindings. Start with v to select the text, then y to copy/yank the text. Then the text is in your copy buffer and ready for pasting.

Let’s see our new bindings in action.

Hit your terminal, start up tmux ( tmux source ~/.tmux.conf ) and make sure to refresh your config if you already have tmux open.

Split your pane (tmux default keys C-b ")

Load up some text on either side. I am looking at two readme files, one that I loaded up in vim and one that is just cat on the terminal.

Now attempt to use your mouse to highlight some text. You will notice that both sides will highlight.

Frustrating if you want the output from just the right side! Let’s use the new keybindings we added to the tmux configuration instead.

Switch over to tmux scroll mode (C-b [), use your arrow keys to move around, and when you are on the text that you want to copy, use v to make your selection.

What’s this? Only text selected on one side? Perfect! Copy the text using y , and it is ready to put where you need it. In my case, moving to my left pane (C-b then left arrow ), and then pasted (vim p) into my other readme.

Now we have a reusable, memorable solution for grabbing text in a single tmux pane!

How to: Mastodon Verification for your Website

christine — Fri, 11 Nov 2022 17:44:12 +0000

Are you part of the twitter migration? Me too! I chose Mastodon as my social app of choice, and ruby.social as my community.

Learning Mastodon takes time, and I am right there with you. There is one thing that I can be assistance with, helping you figure out how to verify your website link in your profile. I am on WordPress, because it is a cool content management system, allows me as a non-frontend dev to have something that looks halfway decent with a minimal amount of work, and well I believe in dogfooding.

Head on over to your Mastodon profile, and click edit profile

Author’s picture with the option to click “Edit profile”

In your Mastodon Profile metadata section, add in your personal website, then Save changes. Notice the Verification section off to the right of the metadata options? Copy your customized verification link.

You can verify yourself as the owner of the links in your profile metadata. For that, the linked website must contain a link back to your Mastodon profile. The link back must have a rel="me" attribute. The text content of the link does not matter.

Mastodon settings/profile

Mastodon Verification section

Next head to your website and add the link on your site anywhere. For example in a footer/header section where you might have other social links. For my WordPress site, I added a Custom HTML block in my sidebar widget section with my Mastodon profile link.

Screengrab of my default Sidebar section, with the Custom HTML block

To check that everything is correct for verification, check out your page source. As with many things front end, checking on the raw HTML (for us the div tag) is the best way to see what the link actually is using in its metadata. The important part for Mastodon verification is the rel="me" attribute. When I look at my page source, I see that it is there

Page source of christine-seeman.com view in Chrome Developer Tools

That’s it! It might take a bit for your verification to show up on your profile (caching/propagation take time) but you should see that sweet green highlighting eventually to let everyone know that you really do control access to that link.

Updated! What's your bio?

christine — Wed, 28 Sep 2022 19:58:29 +0000

So about 4 years, I found myself in need of writing a biography for speaking at a conference. I reached out to dev.to for ideas.

Since then, I have spoken at a couple more conference and have found myself tweaking that bio along the way. Just like talk descriptions, it always feels like there is room for improvement. You change. Your talk changes. Why shouldn’t you make sure that is reflected in your bios?

So here was a sample format that I started with(taken from a comment on dev.to)

{Name} is from {City, State} where he/she works as an {Title} at {Company}. He/She has {#} years of experience with {Technology Name} with a focus on {Technology Focus}. In his/her spare time, {Name} enjoys {Personal Interest #1} and {Personal Interest #2}.

Ryan

And that did get me one of my first bios:

Christine is from Omaha, Nebraska where she works as a full stack Ruby on Rails engineer at Flywheel, WordPress hosting for creatives. She has 12 years experience as a Java software engineer with a focus on APIs and micro-services and took the plunge into Ruby just this May. In her spare time she is an avid long form reader, lover of all true-crime podcasts and is attempting to work through the primary Ashtanga yoga series.

Now my bio looks a bit like this:

Christine is a lifetime learner from Omaha, NE (in the middle of the USA), where she likes to read too much and eats food that probably took too long to prepare. Professionally she’s helping solve problems on the Identity team at WP Engine. She loves working with Ruby, showing people that long Git commits are impressive, and helping write secure, easy-to-read software that powers authorization and authentication at her company.

What changed from that time?

Well, the company I was at in 2018 was acquired. I have moved around teams 3-4 times and been to many more conferences.

To me, what you want to get out of a bio is, who is this person, and why should I listen to them? And it wouldn’t be wrong to see a bit of that person’s personality. I love whimsy and positivity and have tons of other interests that have nothing to do with why I do it for my career. My career is not my life. I want my bio to show that.

So let me introduce an updated conference bio template:

{Name} is from {Current Location} who enjoys {Personal Passion 1}, {Personal Passion 2}, and {Personal Passion 3} . {They/She/Him} professionally {verb ex. teach, code, design, architect, build…} {tech stack} at {company} and are passionate about {Technology/Professional focus} and have been involved in the field for {#} years. {Last sentence tie it back to your talk experience, ex. I talk about MFA, so I mention that is what I am involved with my career.}

Christine’s 2022 Technical Conference Speaker BIO Template

What do you think? Does this get you what you want to know about your conference speakers?

Oh, hello again Vim

christine — Wed, 06 Oct 2021 21:33:51 +0000

aka How to Install vim-plug in Neovim

Me and Vim have a love/hate relationship.

I love using it… until I remember I don't actually remember the keybindings annnnd then I have to search multiple articles every time I want to do anything in it. Especially leave it.

But here I am again, trying to do development in Vim.. again… for reasons. Mostly it is because sometimes you just want something more lightweight for coding. Maybe you find yourself in a different language then your normal one, or you just want to bust out a tutorial but you don’t want to have to make a brand new project. Or maybe you just want to see what all the fuss is about. Whatever the reason, it feels like there is a certain amount of knowledge you need even to get started. Even to install the darn thing.

So, there I was attempting to push some React into my backend loving brain when I started down a rabbit hole.

I opened the code examples in Neovim (which is Vim, but with some spice) but then I realized I probably would want to be able to do some searching through the code examples. To do that you need Plugins. Then if you want those, you probably want a Plugin Manager... and that there was where my rabbit hole took me. What manager? How do I install the manager? Wait, I need Python? And I am out of date?!? Oof and all I was trying to do was attempt a React tutorial 🤷!

So upon attempting to open my Neovim editor today with multiple errors from my ill-fated and aborted plugin manager journey from yesterday, I was able to get straightened out with some help from Christian. He was able to get me straightened out AND I was even able to get Plugins, and a Plugin Manager installed with much less fuss.

My main problem was installing vim-plug, but into Neovim, not plain old Vim. Whenever you do something custom or slightly different (I’m looking at you bash instead of zsh) it always seems like that exponentially adds to the amount of articles you are going to have to wade through to find the answer.

What I needed to do was create an init.vim file (a configuration file just for Neovim).

touch ~/.config/nvim/init.vim

And then install vim-plug

curl -fLo ~/.config/nvim/autoload/plug.vim --create-dirs https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim

But the important part was where I was putting it, in the .config folder where my configuration file (init.vim) is at, and into the autoload directory.

Then you are all ready to install plugins to your heart content in Neovim.

Create yourself a new nifty ~/.config/nvim/vim-plug/plugins.vim file. For ex. start with adding a different default file explorer plugin NERDTree

call plug#begin('~/.config/nvim/autoload/plugged')

    " File Explorer
    Plug 'scrooloose/NERDTree'

call plug#end()

With your separate plugins file ~/.config/nvim/vim-plug/plugins.vim you need to tell your init.vim file to use (or source) this file. You can do that by adding the following into init.vim

source $HOME/.config/nvim/vim-plug/plugins.vim

Now let’s install and use this plugin.

Open up Neovim, in your terminal type in nvim. Check on your plugins status, one plugin was added into your plugins file but we haven’t actually installed it yet.

So with Neovim open, hit Esc to go into Command mode. Now this may not be needed but if you are in any other state this like Visual mode this gets you back so you can actually put in commands. From there you run

:PlugStatus

Let’s get that plugin installed now, go back into Command mode (hit Esc) and then run

:PlugInstall

View of vim-plug installing plugins

That’s it. The plugin is installed! 🙌🏼
You can now update :PlugUpdate your plugins when you like, and go wild and install some more too.

I wanted to check on how NERDTress was working, so I went back to my React tutorial directory and low and behold I have files! To use my newly installed plugin, I opened up one of my html files, then typed out :NERDTree

Now back to my React learning…phew.