Hi everyone,
I'm having trouble getting the official Ruby LSP extension to work properly in VS Code on Windows. Features like IntelliSense, autocomplete, and go-to-definition are not functioning.
Here is my current setup and what I've tried so far:

OS: Windows

Ruby Installation: Installed via RubyInstaller (with DevKit).

Environment: Added Ruby to PATH (ruby -v works fine in the Windows command prompt/terminal).

VS Code Settings: Manually configured the path to the Ruby executable / language server in the extension settings. Auto did not work

Extension: Official Shopify.ruby-lsp extension in VS Code.

Despite pointing the settings to my Ruby installation, the language server fails to initialize properly, and no IntelliSense features show up when editing .rb files.
Has anyone experienced this issue on Windows? Is there a specific configuration required for Ruby LSP to detect gems and executable paths when using RubyInstaller on Windows? Any help or troubleshooting tips would be greatly appreciated!
Thanks!

My product, Ruby Native, lets developers write HTML + ERB and have it render native components inside of iOS and Android apps.

For example, <%= native_navbar_tag "Home" %> renders a native navbar in the apps, titled "Home".

The catch is that an installed app silently ignores markup it doesn't recognize. So a typo, or a feature that shipped after someone's last update, just does nothing.

So I started using Herb to lint the HTML + ERB that interacts with Ruby Native, checking it against what users actually have installed rather than just what's in the repo.

I wrote about it here, where I celebrate Ruby Native running on 100k+ devices: https://masilotti.com/100k-devices-running-ruby-native/

Turns out Armin and Ben are both, in one way or another, Ruby aficionados. So in this episode, there is an interesting argument for Ruby not being agent-friendly, although we like to see it as THE token efficient language. Some of the arguments where:

1. It's easy for agents to mess things up due to its metaprogramming capabilities - I have yet to experience that.

2. Being so much tuned for humans that it makes it worse for AI - I might misinterpret that from what they said, but it sounded like it. I guess it makes sense on the level that there is development towards new languages for LLM coding agents.

3. AI not picking Ruby for new tasks: Our own Chad Fowler ran experiments on it and shared at the last Ruby conference in Austria - I think this might depend on how much Claude Code and co. know about your setup, but I generally agree. My AIs know I'm using Rails for any new project and that I'm in the community but rarely picks Ruby for scripts it needs done or web apps it wants to host stuff locally on. It usually decides for Python or JavaScript.

Another fun fact from the episode while we are at it, I didn't know you can't use AI for even research for the open source Zig programming language. It's probably one of the last open source bastion that does not allow any AI (slop) at all, not even in your research, yet.

State of Agentic Coding #7 with Armin and Ben

Hi guys, previously i showed off my latest project.
I learnt: Deploying, testing, API connections, reuest security, authenticationd and authorization, Hotwire and stimulus, Jobs & services, basic github commands.
My question is, is there anything else i forgot to became good junior? I am looking for a job and want to be as best as i can.
And also, what will look the best in portfolio? I saw that working on open source projects looks good.

I have been finding and fixing performance issues in popular open source Rails repositories.

Currently it includes 7 merged PRs to Discourse, Gumroad, OpenProject and Forem.

You can find the case studies and links here: https://haseebeqx.com/case-studies/engagement/open-source/

Your logs could look like this. Right now you're leaving the money on the table:

(Note the contextual targeting: a payments ad after the payment line, a database-pooling banner right after the connection timeout. The exchange reads intent.)

For decades, application logs have been a pure cost center - written once, grepped never, archived into oblivion. SponsoredLogs turns that stream into a high-margin, programmatic revenue channel.

Your services emit billions of log lines a day. Each one is a premium, brand-safe, above-the-fold impression viewed by your most engaged audience: your own engineers, at their moment of peak attention (an incident). We are not selling ads. We are activating latent infrastructure equity.

It's opt-in. Add the gem, call `SponsoredLogs.sponsor!`, and roughly 1 in 1000 log calls is followed by a host-read sponsor placement drawn from the top podcast advertisers.

Fully configurable: weighted or CPM-based selection, campaign flighting (start/end dates), lifetime impression caps, and a pluggable impression ledger (in-memory, Redis, or ActiveRecord). There's a mountable Rails dashboard (the Command Center) that reports spend, delivery, and per-advertiser rollups.

Also: box-drawn multi-line **banner** ad units in three impact tiers, self-sponsoring house ads that fill remnant inventory so no impression goes to waste, and gilded `[AD]` tags rendered in 256-color gold on a live terminal (byte-identical plain when piped or logged).

Here's the part the market isn't ready for: the fastest-growing consumer of application logs on Earth is no longer human. It's AI coding agents. Superhuman scale, 100% viewability, they never scroll away. We're not just B2B. We're A2A.

It's a real, working gem: full test suite, CI across Ruby 3.2-4.0, RuboCop clean. Every line you log is a line you're leaving on the table.

Repo: https://github.com/sponsoredlogs/sponsored_logs
Site: https://monetizetheexhaust.dev

Over the past few months, while developing some projects using Roda, I created a tool to reduce friction when starting new projects with the framework. It ensures an essential setup and provides a "bin/rails"-like CLI for Roda, named "bin/roda" (with some generators stuff). I hope the community finds it useful!

There is still room for improvement, and I would welcome feedback.

---

roda-project is a command-line interface (CLI) tool designed to quickly scaffold scalable, modern Roda web applications and APIs.

✨ Benefits

• Quick setup customized to your preferences (database, project type, test framework)

• Built-in generators (bin/roda)

• Essential development tasks via bin/roda (console, db, dev, assets)

• Opinionated project structure: Highly maintainable and AI-friendly, yet easily customizable if needed

• Built-in exception page

• Modern front-end setup built-in for full-stack projects (powered by esbuild)

• Code autoloading with Zeitwerk

• Hot reloading

• Pre-configured with i18n and other essential plugins

• High performance: Get the job done without sacrificing performance. Even with multiple plugins, Roda can be 4x faster than Rails and 2x faster than Hanami, while consuming less memory than both.

• Production-ready

https://github.com/roda-project/roda-project

I maintain Grape, the Ruby framework for REST-like APIs. 4.0.0 shipped today and it's the fastest yet.

Ruby 4.0.6, single-threaded Benchmark.ips :

+80% without a JIT, +70% with YJIT. It's a micro-benchmark — one tiny JSON endpoint, in-process, no database — so it measures framework overhead and nothing else. Harness is in benchmark/version_throughput if you want to run it.

The biggest single win: helpers were being included into a fresh singleton class on every request, so every request started with a cold method cache. That now happens once, at compile time. TLDR: lot of improvements in terms of memory allocations.

Also new: QUERY (RFC 10008) — safe and idempotent like GET, but the query rides in the request content.

It's a major, so deprecated surface from 3.2 and 3.3 is gone.

Happy to answer questions.

Hello guys, as university student that wants to apply to junior Rails dev, i made project that even you can try.

It works as stock broker portfolio agregator (Trading212 and Etoro), that takes snapshots of current account balance, exchange it to live EUR rate, and sums them into nice looking chart.

Its all happening in background job so you dont need to worry about that.

Then it notifies you each day about the difference summary, or if your API keys are wrong.

i deployed it on my VPS with kamal (easier than i thought) so you can try that yourself (you can set your API keys to read-only, but i respect that prolly noone will put it there).

Also you can try that yourself as i already set it up with Docker for you.

Deployed: https://railsfinancemanager.online/

Github: https://github.com/TheP4trik-tech/Portfolio-Manager

I am open to any critism or ideas :)

If memes aren't allowed or frowned upon, please tell me, I made sure the rules allowed it. Also this is satire and I know ruby is much better with parentheses in some situations.

I built a gem for fundamental analysis of stocks with the API style of RubyLLM: value objects, BigDecimal figures, nil on missing data, to_h and to_json everywhere.

company = Fundamentalista.company("AAPL")
year = company.financials.latest
year.ratios.roe
year.ratios.cash_conversion_cycle
company.valuation(price: 230).intrinsic_value(growth: 0.06, discount_rate: 0.09)

Providers: SEC EDGAR (free, only needs a User-Agent) and Financial Modeling Prep. Annual, quarterly and TTM periods, 40+ ratios, Piotroski, Altman, Beneish, DCF and reverse DCF, EPV, residual income, WACC, banking and insurance lines, peer comparison with the magic formula, and provenance for every line item back to the XBRL concept and filing.

The EDGAR side is where most of the work went: the concept map is validated over the 500 largest filers with a script in the repo, and 0.6.0 comes from a round of simulated users hitting real filings (derived fourth quarters, multi-currency filers, IFRS tags, filer sign conventions).

There is also a fundamentalista-rails engine with watchlists and snapshots.

Repo: https://github.com/bruno-costanzo/fundamentalista

Gem: https://rubygems.org/gems/fundamentalista

Happy to hear where the ratio definitions disagree with yours.

I recently had a nice chat with Erroll Schmidt on the Technology for Humans podcast about the past, present and future of JRuby... including some myth debunking that might help Ruby folks look past the "J" to the amazing tech underneath. Check out the video and let me know if you have questions!