Weeknotes 56

The leaks are fixed. Bathroom still in pieces.

I setup the air conditioner. It was a bit too cold if anything. Sorry, Planet. I’ve never said the phrase “Oh, there’s a nice breeze” as much as this week.

After complaining recently about the poor Ruby docs experience I found Ruby API this week by Colby Swandale.

Ruby API makes it easy and fast to search or browse the Ruby language API docs

I haven’t had a lot of time to use it so far but I’ve very interested in seeing where it goes.

My experiments with different VPN providers continues. ProtonVPN is very fast to connect and I’m pretty happen with it so far. I would still like to try out Mullvad.

Clean up your branch remotes with git remote prune origin. Use --dry-run first to double check what will be removed.

My article on using Git fixup commits got linked to from the GitHub blog – pretty exciting. I only noticed because I happened to log into my analytics (which I never do) and noticed a spike. It is encouraging to actually think that someone is reading what I wrote (however shoddy that writing is).

Jean Boussier wrote that he’d improved Ruby String#<< performance by 30% and brought that improvement over to Rails with “Speedup ActionView::OutputBuffer” too 🔥

All this to say that Rails apps using ERB views should hopefully notice a nice perf improvement with Rails 7.1 and Ruby 3.2. I’d love to give an actual figure but thats' heavily dependent on the templates, so your mileage may vary.

He then followed up with a further improvement!

I merged a third String#« optimization. Overall it’s now 65% faster for UTF-8.

Great work! It always surprises me when someone manages to squeeze out these performance gains like this.

Another new feature in Elixir main – dbg. A macro that you can use on the end of a pipeline and it will output each value in turn – very cool. Lovely work by Andrea Leopardi.

__ENV__.file
|> String.split("/", trim: true)
|> List.last()
|> File.exists?()
|> dbg()

Check out the examples in the Twitter thread.

For a unit test I needed a value from a predefined list, but it could only be used once as the database column had a unique constraint. We’re using FFaker in this project and it was surprisingly easy to create my own FFaker module.

module FFaker
  module Foo
    extend ModuleUtils
    extend self

    DATA = ["Foo", "Bar", "Baz"]

    def foo_bar_or_baz
      fetch_sample(DATA)
    end
  end
end

Calling FFaker::Foo.foo_bar_or_baz will return a value on each invocation.

[1] pry(main)> FFaker::Foo.unique.foo_bar_or_baz
=> "Bar"
[2] pry(main)> FFaker::Foo.unique.foo_bar_or_baz
=> "Foo"
[3] pry(main)> FFaker::Foo.unique.foo_bar_or_baz
=> "Baz"
[4] pry(main)> FFaker::Foo.unique.foo_bar_or_baz
=> "Bar"

Adding unique to FFaker::Foo.unique.foo_bar_or_baz will fail after it has run out of values.

[1] pry(main)> FFaker::Foo.unique.foo_bar_or_baz
=> "Bar"
[2] pry(main)> FFaker::Foo.unique.foo_bar_or_baz
=> "Baz"
[3] pry(main)> FFaker::Foo.unique.foo_bar_or_baz
=> "Foo"
[4] pry(main)> FFaker::Foo.unique.foo_bar_or_baz
FFaker::UniqueUtils::RetryLimitExceeded: FFaker::UniqueUtils::RetryLimitExceeded

The experiment with difftastic is over.

Looking for better Internets? Better Internet Dashboard does a nice job of showing the various developments happening in your local area.

Thoughts on YAML by Avdi Grimm (found via Sam Livingston-Gray).

YAML is a wonderful serialization for computers to write and humans to read. And maybe, occasionally, with great trepidation… to tweak. E.g. Ruby’s YAML::Store is a terrific, under-appreciated tool for small-scale persistence.

YAML should not be composed by humans.

People love to hate on YAML. I’ve never had any particular problem with it, but then again I’ve only used it in fairly primitive ways. I’m sure the problems with YAML exist, but for me it’s a good choice a lot of the time.