Lmst

tiny ruby #{conf} will return on the 1st of October 2026!

More information to come, but for now you can sign up to receive email updates on our site: https://tinyruby.fi

#tinyruby #ruby #conference #helsinki #finland

Hello #ruby people, How can I test using #Rspec that accept method is receive(triggered). The class is here https://codeberg.org/codeDude/romodoro-socket/src/branch/main/lib/romodoro/socket/timer/command_server.rb#L24
I having issues trying to mock and stub the dependencies

$Rspec code # frozen_string_literal: true RSpec.describe Timer::CommandServer do let(:socket_server) { instance_double UNIXServer } let(:socket) { instance_double UNIXSocket } let(:coutdown) { instance_double Timer::Countdown } context "when the CommandServer start" do it "should accept the connection to the socket" do expect(socket_server).to receive(:accept).and_return socket allow(socket).to receive :puts allow(socket).to receive :close command_server = Timer::CommandServer.new socket_server, coutdown command_server.start end end end$

#ruby can change this
```ruby

def response
command = @client.gets&.strip

case command
when "pause" then @countdown.pause
when "resume" then @countdown.resume
when "stop" then @countdown.stop
when "status" then @countdown.status
else raise ArgumentError "ERR: unknown command"
end
end
```
by this
```ruby

def response
command = @client.gets&.strip
@countdown.send command
end
```
and this is awesome

Okay so there are only a couple business days left in the month... I can't break my resolution immediately 😅 📆

So... #Brakeman 8.0 drops tomorrow.

#rails #ruby

Go go Weekly Brain Dump!

- A projects page for my blog
- Taylor gets a new release
- The Taylor website gets the simple.css treatement
- The Taylor website gets a revamped documentation page
- Jumpy Alien has a complete game loop!

https://sean.taylormadetech.dev/2026/01/29/weekly-brain-dump-7.html

#WeeklyBrainDump #blog #programming #ruby #GameDev #CSS #SimpleCSS

I did not survive the #Amazon #layoffs today.

If you’re looking for an energetic #Rubyist hamster who is interested in figuring out hard problems people haven’t solved before, with a track record of doing it at scale, hit me up. I’m also interested if you’re only looking for a fractional CTO to help your company out part time. Or some other collaborative role that might otherwise be hard to describe.

https://ziggythehamster.sh/about/resume.html

#Ruby #RubyFriends

I don't know if anyone from the Rails team is here, but in the off chance someone is, could I get someone to look at this PR again? Looks like I'm not the only one who would love this option… (68 likes!) #ruby #rails #rubylang

Add optional setting to `Schem...

Could someone from the #rails team maybe take a second look at this PR? 🙏🏻 Looks like I'm not the only one who would like this option… (68 likes!)

https://github.com/rails/rails/pull/55414

#ruby #rubylang #rubyonrails

🎉 alchemy_cms v8.0.5 has been released!

https://github.com/AlchemyCMS/alchemy_cms/releases/tag/v8.0.5

#RubyGems #Ruby #Rails #CMS #AlchemyCMS

🎉 alchemy_i18n v5.0.2 has been released!

https://github.com/AlchemyCMS/alchemy_i18n/releases/tag/v5.0.2

#RubyGems #Ruby #Rails #CMS #AlchemyCMS

Contributing to RubyGems (.org)

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.

#code #ruby #rubygems

Highlight of my workday was debugging an issue that turned out to be nothing like what the reporter had diagnosed.

The report suggested that our system was having problems parsing URLs with colons in the pathname, suggesting perhaps an encoding issue. It wasn't until I took a deep dive into the logs that I realised that this was a secondary characteristic of many URLs found in customers' SharePoint installations. And many of those URLs get redirected. And SharePoint often uses relative URLs when it sends redirections. And it turned out that our systems' redirect handler... wasn't correctly handling relative URLs.

It all turned into a hundred line automated test to mock SharePoint and demonstrate the problem... followed by a tiny two-line fix to the actual code. And probably the most-satisfying part of my workday!

#note #testing #http #web #ruby #firstup #work #programming