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?

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...

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?

Some dream features:

* Composable template objects: `union_template = foo_template + bar_template`
* Support for partials or includes.
* Liquid and/or ERb support.
* Dynamic file/dir names.
* Automatic indentation/formatting (think liquid filters).
* Template macros for generating your choice of rdoc, markdown, or textile formatting (ex: ul, li, a, pre)

Ever since my Ore gem template project, I've wanted to write a generic project templating library, so projects could stop re-inventing -gen commands. TIL Python's cookiecutter, which has many of the same ideas. Even uses Liquid Templates. github.com/audreyr/cookiecutte

Also, by defining your rake task as a class, this makes it much easier to test the other non-rake-task-specific helper methods which houses the actual logic.

PSA: if you're library includes a `railties.rb` file, please, PLEASE, include a `my_task.rb` file and `Rake::TaskLib` sub-class that non-rails users can require and initialize.

TIL `Dir.glob("**/*.rb")` is basically the same as `Dir.glob("{,**/}*.rb")`. Has this always been the case?

Been a while since I got to do some random OSS work. One less broken window 😌

It's shocking how many CI/provisioning systems cannot handle repositories with a `.` in their name.

What is the current defacto practice for compartmentalizing/enabling prod vs development specific business logic? if/else statements around methods? Including different environment modules? An adapter pattern?

Show more

A Mastodon instance for Rubyists & friends