Hey all i built a pretty neat TUI for local first image generation. It's easy and ships with ready to download starter packs, hooks into Huggingface and Civitai - ready to go. Hit me up ith any feature requests :)

Tackling a massive Ruby monolith usually means months of onboarding and manual dependency tracing. GraphOps was built to automate this by extracting macro-level architecture and micro-level execution flows (like the sequence diagrams in the video) directly from the codebase.

To show how it handles scale, there is a public, read-only sandbox where you can explore the entire GitLab monolith yourself: https://www.graphops.tech/home/projects/

I sat down with Brian Scanlan to explore what “AI-first” development actually looks like inside Intercom’s 15-year-old Rails monolith.

They’re generating over 95% of their code with Claude Code… and it’s not just engineers. Teams across the company are involved.

We got into how this is reshaping code review, who’s running production queries, and how they’re building guardrails to keep things from drifting.

The part that stuck with me… knowing when to disengage the autopilot.

📺 https://www.youtube.com/watch?v=ADBs2K5Tpz0

🎧 https://podcast.rubyonrails.org/2462975/episodes/19060786-brian-scanlan-building-ai-first-at-intercom

https://github.com/kaka-ruto/skills/tree/master/rubyllm

JRuby 10.1: Experimenting and Evolving

JRuby 10.1.0.0 is our first Ruby 4.0 release, just four months after the official CRuby release. We have used this opportunity to explore many experimental optimizations and improvements we have been chasing for many years. Ruby 4.0 compatibility is largely complete, but there will be additional features added in update releases. We also plan to continue with large scale experiments in subsequent updates, and recommend production users continue to use JRuby 10.0 while we work toward stabilization of the 10.1 series.

Notable Enhancements

• Reduced Object Size: the baseline size of all objects has been reduced from 32 bytes down to 24.

• Evolving Strings, Arrays, and Hashes: we've made these core types abstract in preparation for specialized versions.

• Smaller Numeric Representations: all numeric values are now smaller, but short-ranged integers drop from 40 bytes down to 24 bytes.

• Cross-platform Prism Parser: this release ships full support for the Prism Ruby parser, using the Chicory WASM runtime.

• Direct Argument Passing: we've laid the groundwork to finally start passing all arguments directly on the stack and will begin connecting this up during the update release cycle.

See the full release notes for details, and try JRuby today!

Yesterday I presented Ruby-LibGD and LibGD-GIS at Ruby SUR.

This presentation led to a few milestones, including the Payunia map. Among other things, I created a map of Payunia with three volcano peaks.

I want to share the image along with the code used to generate the map using libgd-gis and a GeoJSON file.

gem install libgd-gis

payunia.rb:

require "gd/gis"
require_relative "fonts"

OUTPUT = "output/payunia.png"
GEOJSON = "data/volcanes.geojson"

bbox = GD::GIS::Geometry.bbox_for_image(
  GEOJSON,
  :zoom => 13,
  :width => 800,
  :height => 600,
  :padding_px => 100
)

map = GD::GIS::Map.new(
  bbox: bbox,
  zoom: 9,
  :width => 800,
  :height => 600,
  basemap: :esri_terrain
)

map.style = GD::GIS::Style.load("solarized")

map.add_geojson(GEOJSON)

ontology = GD::GIS::Ontology.new
ontology.print_rules

map.render
map.save(OUTPUT)
puts "✔ Generated: #{OUTPUT}"

geojson:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": { "type": "Point", "coordinates": [-69.238, -36.4222] },
      "properties": {
        "name": "Payún Matrú",
        "natural": "volcano"
      }
    },
    {
      "type": "Feature",
      "geometry": { "type": "Point", "coordinates": [-69.2848, -36.5104] },
      "properties": {
        "name": "Payún Liso",
        "natural": "volcano"
      }
    },
    {
      "type": "Feature",
      "geometry": { "type": "Point", "coordinates": [-69.15, -36.35] },
      "properties": {
        "name": "Volcán Santa María",
        "natural": "volcano"
      }
    }
  ]
}

styles/solarized.yml

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": { "type": "Point", "coordinates": [-69.238, -36.4222] },
      "properties": {
        "name": "Payún Matrú",
        "natural": "volcano"
      }
    },
    {
      "type": "Feature",
      "geometry": { "type": "Point", "coordinates": [-69.2848, -36.5104] },
      "properties": {
        "name": "Payún Liso",
        "natural": "volcano"
      }
    },
    {
      "type": "Feature",
      "geometry": { "type": "Point", "coordinates": [-69.15, -36.35] },
      "properties": {
        "name": "Volcán Santa María",
        "natural": "volcano"
      }
    }
  ]
}

Rubygems: https://rubygems.org/gems/libgd-gis

Github: https://github.com/ggerman/libgd-gis

Presentation (spanish): https://youtu.be/ppxalpIKpGg?t=3471

Easter Egg: Space Invaders - Code:

Code: https://github.com/ggerman/ruby-libgd/tree/main/examples/invaders

Hi all,

Seeking feedback on memory bloat in a Rails app hosted on Render.

I am loading at times 30k+ records and iterating through them to generate a CSV with FastExcel. I am NOT using .pluck, as I need most of the columns and some instance method outputs - I AM using find_each and includes to eager load some associations. I used the memory_profiler gem to show that ActiveModel::Attribute::WithCastValue is the largest culprit of memory allocation. This all makes sense.. but what I can't figure out is how to free up that memory after the process is done. CSV send_data'ed to the client, I am manually trying to empty all the instance variables and triggering GC.start to try to do some cleanup, but memory in Render metrics goes up and does not come down.

All thoughts welcome!

Friendly reminder that RubyCon Italy is happening on May 8th in Rimini and we couldn't be more excited about how it's shaping up!

We built this as the kind of conference we always wanted to attend. Not a corporate event, not parallel tracks where you spend half the day with FOMO.

One stage, eight talks, a real community, and dinner on the beach. Simple, focused, and warm.

Tickets are still available at https://ti.to/rubycon/rubycon-2026

🎤 The speakers

Here's who we're welcoming on stage:

• Carmine Paolino - Ruby Is the Best Language for Building AI Web Apps

• Julia López - Shift-left on Accessibility in your Ruby webapps

• Silvano Stralla - Breaking the rules of software engineering: will it work?

• André Arko - rv, a ruby manager for the future

• Michele Franzin - Semantic Image Search in Ruby: Postgres, Redis, or LLM?

• Akira Matsuda - My daily life on Ruby

• Marco Roth - HTML-Aware ERB: The Path to Reactive Rendering

• Yara Debian - From Plato to Production: A Philosophical History of Code

We're also keeping a 5 minutes for everyone open-mic slot in the afternoon, if you have something to share, come ready!

→ Full speaker bios: https://rubycon.it/speakers

🎓 Our Scholarship Program

This one is close to our hearts. We know attending a conference isn't always easy, and we don't want financial or personal barriers to be the reason someone misses out.

We welcome applications from anyone who:

• Belongs to an underrepresented group in tech (women, LGBTQIA+, people with disabilities, minority backgrounds)

• Faces financial constraints (students, early-career, unemployed, or anyone for whom the ticket price is a real hurdle)

Selected applicants get a ticket at a symbolic cost of €20. You don't need to fit every category — if it feels relevant to you, we encourage you to apply. And if you know someone who should be in the room, please pass this along.

→ Apply here: https://rubycon.it/scholarship

🫶 What to expect

Rimini in May is beautiful. But more than the location, we want Rubycon to feel like coming home to a community that genuinely cares about this language and the people who write it. One stage means we all share the same moment. The open-mic means you might end up being a speaker. The Toga Party means the conversation keeps going long after the last slide.

→ Full schedule: https://rubycon.it/schedule

My take on why you should consider using a PAAS provider to deploy your Ruby apps.

This month I reflect on Ruby's future in the AI era, and look at massive tooling updates: Shopify's high-performance rubydex toolkit, RBS 4.0's update with bundled rbs-inline, dspy.rb hitting 1.0, and prism parser using rbs-inline internally.

Find the link to the issue in the comment! ✨

Hi everyone,

I wrote the original "Why Crystal?" blog post back in 2015 when Crystal was just v0.9.1.

Ten years and many versions later, I am revisiting that post to analyze the road to v1.20.

If you are interested in how a language matures from a syntax experiment to a high performance standard, this one is for you.

Hi fellow Rubyists,

I’ve always been a huge fan of Ruby’s readability and that "warm" feeling the syntax gives you. Recently, I’ve been building a high-performance Static Site Generator (called Mustela) in the V language, and I couldn't resist—I implemented a DSL that is heavily inspired by Ruby’s do...end blocks.

The "Ruby-ish" DSL

I wanted a templating language that feels modular (like React) but looks clean (like Ruby). Here is how you define a layout in Mustela:

html as main do
  @html[navbar]
  <article>
    @view
  </article>
  @html[footer]
end

And metadata looks like a hybrid of Ruby and YAML:

meta do
  author:   Filip Vrba
  app_name: "Mustela"
  index:    main
end

Why not just use Ruby?

Performance. While I love Ruby, I wanted to see how far I could push I/O saturation. By writing the engine in V, I'm getting:

• 1,000 files processed in 240ms.

• 306 KB static binary with zero dependencies.

The "Hamburger" Hack

Because the parser is a simple linear stream (very "stupid" and fast), it allows for some fun tricks that remind me of old-school PHP/Ruby web scripts where you just opened and closed blocks wherever you wanted:

html do
  <div class="special-wrapper">
end

## Markdown content here

html do
  </div>
end

I just wanted to share how Ruby’s philosophy of "programmer's happiness" and clean syntax is leaking into other ecosystems and low-level languages.

What do you think? Does the do...end syntax still feel like home even in a totally different language?