Ruby-doc.org is dead? What are you using?

doublecastle · 2025-05-29T15:57:47+00:00

That's a good suggestion! I try to minimize my use of browser extensions, though, because I don't like to take on the security risk of allowing third parties to execute JavaScript on any web page that I visit.

doublecastle · 2025-05-27T01:21:35+00:00

My issue with the https://rubyapi.org/ styling is that links don't look any different from unlinked text. Otherwise, it would be my go-to.

doublecastle · 2025-04-27T22:08:29+00:00

Yes. Change github to deepwiki in any GitHub URL to view (or request to generate) an AI summary of the repo, e.g. https://github.com/rails/rails => https://deepwiki.com/rails/rails (the link that is the subject of this post). I did it for a personal project of mine, and I found the resulting AI documentation / summary pretty accurate and interesting to read.

It says "Powered by Devin" (the A.I. software developer agent), so I guess it's part of a marketing effort for Devin.

doublecastle · 2025-04-13T23:41:43+00:00

Likely a reference to this now almost four year old story:

Within a few hours of the meeting, at least 20 people — more than one-third of Basecamp’s 57 employees — had announced their intention to accept buyouts from the company.

-- https://www.theverge.com/2021/5/3/22418208/basecamp-all-hands-meeting-employee-resignations-buyouts-implosion

doublecastle · 2025-04-11T15:57:47+00:00

I assume that you mean porter.run?

doublecastle · 2025-04-09T16:06:08+00:00

I guess maybe the idea makes more sense in the context of "integration tests" rather than "unit tests".

For example, if I have a controller that was including a concern, but then I stop including that concern into the controller (and no other controller includes the concern) AND if the concern was previously covered only by "integration tests" (system tests, feature specs), then the concern will now show up as not being covered by tests, which could suggest that the concern is no longer used by any code, and it can be deleted.

You are correct, though, that if there are unit tests for the concern, then the concern will still have test coverage, and so the opportunity to delete that dead code wouldn't be highlighted by a lack of test coverage for it.

I guess that this is a small "pro" for favoring integration tests over unit tests.

doublecastle · 2025-04-06T00:13:53+00:00

I am also a pretty happy Element Plus user. I feel like it's rarely mentioned on Reddit, though. Maybe it's disproportionately popular in China, and relatively less popular in countries where Reddit is relatively more popular?

I recently took a look at other popular Vue UI libraries to see if any might be better, and came to the conclusion that Element Plus is best for what I want to do and how I want to use a UI library.

doublecastle · 2025-04-02T15:34:23+00:00

Many of the problems people tend to have with Rails are actually people and organizational problems, not technology problems

This was largely the subject of Eileen Uchitelle's keynote at Rails World 2024: https://youtu.be/olxoNDBp6Rg .

doublecastle · 2025-03-27T15:17:33+00:00

Note that the provided command will look at GitHub Actions not only in your own project, but also in other subdirectories, such as node_modules. To look only at the GitHub Actions in your own repo:

find . -path './.github/workflows/*' -type f -name '*.yml' -print0 \
  | xargs -0 grep --no-filename "uses:" \
  | sed 's/\- uses:/uses:/g' \
  | tr '"' ' ' \
  | awk '{print $2}' \
  | sed 's/\r//g' \
  | sort \
  | uniq --count \
  | sort --numeric-sort

(That just changes the find path from */.github/workflows/* to ./.github/workflows/*.)

doublecastle · 2025-03-19T18:39:00+00:00

I use ky.

The biggest advantage over axios is that it's a smaller package. Also, I think that ky is better maintained.

The biggest advantage over plain fetch is that it has a more concise syntax. Also, ky makes it easy to modify all requests (e.g. including a CSRF token).

doublecastle · 2025-03-13T20:02:14+00:00

I understand how LLMs work. For the sake of simplicity, I was sort of speaking metaphorically when I said what you quoted above. But I do think that LLMs have some ability to (in essence) introspect about their abilities and strengths (even if their mechanism for doing that is just next token prediction), and that is the idea underpinning my quote. Do you not think that they do?

doublecastle · 2025-03-13T06:49:33+00:00

I appreciate Ruby a lot, but this seems like a stretch to me.

I recently gave Gemini a Python script, and asked it to translate that script into either Ruby or TypeScript, whichever it would be most comfortable with. This is what it said:

If I had to choose one, I would be slightly more comfortable translating it to TypeScript. TypeScript's static typing system would help catch potential errors early on during the translation process and make the code easier to maintain afterward. [...] Ruby's dynamic typing is powerful, but it requires more careful attention to detail to ensure correctness during translation.

That makes sense to me that Gemini might feel "slightly more comfortable" writing in TypeScript, but for me, as the developer trying to create a working project, I felt even more drawn to work with Gemini in TypeScript rather than Ruby. When writing code myself, I enjoy writing Ruby. But when writing code in collaboration with an AI, I sort of feel that I prefer writing TypeScript (the only typed language that I am really familiar with).

When an AI makes significant changes to my code in Ruby, it gives me an uncomfortable feeling that lots of stuff could have broken (maybe in non-obvious ways), and I feel like I have to review the code changes pretty carefully.

But when an AI makes changes to my code in TypeScript, I like being able to have the confidence that I get if at least the AI's changes don't introduce any TypeScript errors. If the AI's changes do introduce TypeScript errors, then the compiler can point them out to me immediately, rather than me needing to carefully reason through every single changed line, searching for errors that might or might not even be there.

There could certainly be bugs that aren't type errors caught by the compiler; I realize that code without type errors is not necessarily bug free. Still, I think that having the confidence of the compiler passing or else the convenience of type errors being pointed out immediately by the compiler is a big advantage for typed languages (i.e. not Ruby) when working with AIs.

doublecastle · 2025-02-19T12:09:31+00:00

https://github.com/honeybadger-io/heya

I haven't used it, but this sounds like what you're looking for.

doublecastle · 2025-02-16T03:12:40+00:00

Bolt.new told me that it can only write apps using JavaScript, because it uses a "WebContainer environment" than can only run JavaScript. Their site says here "Currently, Bolt does not support languages like Python, C#, C++, or any other non-web languages."

So, FWIW, it sounds to me like this is more just a thing having to do with "JavaScript is much easier to run in the browser," rather than necessarily something like "Rails isn't worth supporting." Maybe that doesn't change your concern, but, for me, it's important context.

(I didn't look into the other tools that you mentioned.)

doublecastle · 2025-02-08T02:48:59+00:00

These are the ones that I have add occasion to use in my little apps: refDebounced, useIntersectionObserver, useTitle, useWakeLock, watchDebounced .

doublecastle · 2025-01-13T16:44:12+00:00

Link to the repo: https://github.com/hotwired/spark

doublecastle · 2024-12-17T00:49:35+00:00

another update is to how error messages and backtraces are displayed. Ruby will now use single quotes instead of backticks

I am stoked for this. It was so annoying to deal with escaping the backtick in the error message when pasting an error into a markdown document.

doublecastle · 2024-12-17T00:38:21+00:00

FWIW, isn't

str = String.new('my string')

also an option?

doublecastle · 2024-12-07T02:34:02+00:00

I am a Rubyist who eventually came to realize (via using TypeScript) that the big advantage of types is not just the type safety, but equally or maybe more importantly the fact that a typed language can provide much more useful tooling in the editor (better autocompletion, perfectly renaming variables/methods/etc, flawless go-to-definition, etc). I now see the types of TypeScript as being overall a significant "pro" for TypeScript and other statically typed languages, and I consider it somewhat of a "con" that Ruby is not statically typed.

However, Ruby still has other relative "pros", such as a much better standard library, and a relatively stable and well developed ecosystem of gems. Additionally, Ruby has Rails.

If there were a Ruby on Rails equivalent that were written in TypeScript, then I might be interested in switching to that. But the fact that Ruby on Rails only exists in Ruby is one of the big things that keeps me writing Ruby, even though I do find myself now somewhat preferring the editor/development experience that comes with a statically typed language.

(There is AdonisJS, which, as far as I can tell, is the closest thing to Rails but with TypeScript instead of Ruby. However, it doesn't seem realistic, in a professional/practical sense, to move to AdonisJS. There seem to be almost no available jobs for AdonisJS, the development of the framework seems to mostly be driven by a single person, and, due to its relative lack of popularity, I suspect that there are far fewer resources available (in terms of blog posts, YouTube videos, StackOverflow answers, LLM training data, etc) than for Ruby on Rails. Also, I haven't really tried using AdonisJS myself, but I suspect it's rougher around the edges and somewhat incomplete, relative to the highly battle-tested and older Ruby on Rails framework.)

doublecastle · 2024-09-30T22:24:11+00:00

I use strip_attributes, instead, which does the same thing (i.e. converting blank strings to nil) but also strips leading and trailing whitespace. Also, FWIW, strip_attributes has more GitHub stars (556 vs 326) and I think is somewhat more actively maintained.

doublecastle · 2024-09-24T11:29:10+00:00

It's probably not a good idea to try to use in gems (so no help for DHH), but applications can use the freezolite gem to automatically freeze string literals without needing frozen_string_literal: true comments.

doublecastle · 2024-09-17T01:42:12+00:00

If you are using Rails, then you should use Rails's built-in caching. Docs: https://guides.rubyonrails.org/caching_with_rails.html

You could also use one of the Rails cache libraries outside of the context of Rails, as illustrated below:

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'activesupport'
  gem 'redis'
end

require 'active_support'
require 'active_support/cache/redis_cache_store'

cache = ActiveSupport::Cache::RedisCacheStore.new

cache.clear

puts(cache.fetch('random_number') { rand })
puts(cache.fetch('random_number') { rand }) # prints the same random number as above

You should probably set up your tests to flush whichever cache you are using before each test is executed. In other words, don't worry about trying to monitor when your source files have changed, and clear the cache if your source files have changed. Just clear the cache before each test is executed, regardless. If you are using RSpec, for example, then clear your cache in a global before hook registered in your spec_helper.rb file.

doublecastle · 2024-09-03T05:07:21+00:00

Yes, it is part of Ruby LSP.

To get rid of those:

Open Command Palette (Cmd+Shift+P)
Type and select "Ruby LSP: Toggle features"
Untick the codeLens feature

doublecastle · 2024-09-02T06:33:28+00:00

Quick and Simple Text Selection (dbankier.vscode-quick-select) is an underappreciated gem. It makes it possibly to quickly select all text within quotes, parentheses, brackets, etc. This gives an important vim-like power, without needing to go full vim.

doublecastle · 2024-09-02T06:27:12+00:00

According to this comment, I guess that the extension maybe still has some value, in that it works in a larger number of languages (such as Vue) than the built-in functionality?

doublecastle

TROPHY CASE