postmodern @postmodern@ruby.social

and finally released spidr-0.6.1 which fixes those pesky opaque URI exceptions.

ffi-hunspell 0.5.0 has been released, which adds support for libhunspell-1.7. Slowly getting a handle on my OSS backlog...

What new things in Ruby-land are worth learning? Feeling a bit rusty [not a pun].

So now that #bundler 2.x is here and now, should we add just `bundler` to our development dependencies, constrain it to `>= 1.0, < 3`, or `~> 2.0`, or `~> 1`?

So where does one post Ruby jobs in 2019?

It would be a nice #mastodon #feature if you could send a toot directly to one mastodon instance, and only the users on that instance would see it. This would allow Rubyists not on ruby.social to send us messages without us having to search/filter for ruby messages from users elsewhere.

Just curious what people use for distributed lock management? What are the currently trusted go-to solutions?

Also cannot find any information on whether GitHub is submitting these advisories to MITRE to get CVEs assigned.

It's nice that GitHub now allows projects to publish their own security advisories (GHSA). It's not so nice that those advisories are not getting submitted to the ruby-advisory-db...

TIL that the oj gem doesn't honor custom class-level .to_json methods, and that the multi_json gem checks for oj first. If oj gets depped in, your custom Foo.to_json methods will cease to work.

While I'm kind of glad Apple finally decided to pick a direction to go in, this move is likely going to disrupt Homebrew which relies on system Ruby; and they can't rely on ruby-build/ruby-install because those in turn rely on homebrew. I suppose this shift is going to finally increase demand for precompiled releases of scripting language runtimes that can be extracted into `/usr/local`. I doubt that Apple will be generous enough to maintain their own precompiled packages of Perl, Python, Ruby.

I have been saying for years now that macOS is no longer a developer friendly platform (unless you work entirely in XCode). This news about Apple removing Perl, Python (2.7), and Ruby, might just be the final nail in the coffin. Each year I watch developers on $birbsite struggle to workaround the issues in the latest macOS release in order to setup a *nix-style development environment, all of which can easily be installed on Linux/FreeBSD with one or two package manager commands.

Realized I've hit peak exec wrapper commands when I typed `docker-compose exec app bundle exec padrino c`. Please stop adding exec wrapper commands to your tools :/

Kind of glad that the `"foo"f` syntax never got into Ruby (or isn't enabled by default?). The dangling `f` seemed awkward. Would have preferred a new symbolic syntax.

Noticing the Local timeline is getting Off Topic.

If you're entire CI (testing and prod builds) is Dockerized, is there a good solution for `bundle install` (testing) vs `bundle install --without development test` (prod)?

Wait, did `load` always search `$LOAD_PATH` for the file or was this added at some point? I thought it always expected absolute or paths relative to the current working directory?
https://ruby-doc.org/core-2.6.2/Kernel.html#method-i-load

Who's idea was it to put rake tasks in `.rake` files? This prevents `require` from being able to find/load them. Instead you need the full path to the files in order to `import` them, which gets ugly when the `.rake` files are in another gem...
https://blog.smartlogic.io/2009-05-26-including-external-rake-files-in-your-projects-rakefile-keep-your-rake-tasks-organized/

You would think the Ruby community would be more familiar with Liquid, given how Jekyll uses it.

I like how cookiecutter uses Liquid both in file/dir names and file bodies. While it's harder to register new Liquid functions, it does prevent arbitrary nasty code from hiding in templates. Although, the Ruby ecosystem is very familiar with ERb. Are there use-cases where ERb can do things that Liquid cannot?