When developing a Rails app, have there been times when you’re wondering “what properties/columns does this model have”? The easiest way to find out is by inspecting db/schema.rb, but that gets annoying quickly. If only there’s a way to keep your schema closer to you. Enter the annotate gem.
Ruby
Running Chrome Headless, Selenium and Capybara inside GitLab CI and Docker
Selenium + Chrome Headless fail with mysterious errors when run in GitLab CI and Docker. Here’s why, and also how we fixed it.
Why Ruby app servers break on macOS High Sierra and what can be done about it
People who have upgraded to macOS High Sierra and who are using a preforking app server such as Puma or Unicorn (with the right settings), may have noticed this error:
objc[81924]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
This cryptic error is triggered under the following conditions:
- You are using Unicorn with
preload_app, or Puma in cluster mode, or iodine in prefork mode, or Passenger in smart spawning mode. - And you are using MRI.
- And your application uses a gem that is either directly or indirectly linked to the macOS Foundation framework.
This error is caused by changes in how fork() behaves in High Sierra. This article covers:
- What is this and why did Apple change it?
- How are the Puma, Unicorn and Passenger authors responding to this?
- What can you do about it, and do you need to do anything at all?
- What should the wider Ruby ecosystem do?