Pauloparakleto

name: Ruby

on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    services:
      db:

dhh

# THIS LINUX SETUP SCRIPT HAS MORPHED INTO A WHOLE PROJECT: HTTPS://OMAKUB.ORG
# PLEASE CHECKOUT THAT PROJECT INSTEAD OF THIS OUTDATED SETUP SCRIPT.
#
#

# Libraries and infrastructure
sudo apt update -y
sudo apt install -y \
	docker.io docker-buildx \
	build-essential pkg-config autoconf bison rustc cargo clang \

qoomon

Conventional Commit Messages

See how a minor change to your commit message style can make a difference.

git commit -m"<type>(<optional scope>): <description>" \
  -m"<optional body>" \
  -m"<optional footer>"

kddnewton

Faster Rails tests

Feedback loop speed in one of the biggest contributing factors to overall development time. The faster you get results, the faster you can move on to other things. A fast enough test suite is therefore critical to teams' success, and is worth investing some time at the beginning to save in the long run.

Below is a list of techniques for speeding up a Rails test suite. It is not comprehensive, but should definitely provide some quick wins. This list of techniques assumes you're using minitest, but most everything should translate over to rspec by simply replacing test/test_helper.rb with spec/spec_helper.rb.

• Lead with data
• bcrypt
• bootsnap
• Cache Time::utc calls

subfuzion

Common Options

-#, --progress-bar Make curl display a simple progress bar instead of the more informational standard meter.

-b, --cookie <name=data> Supply cookie with request. If no =, then specifies the cookie file to use (see -c).

-c, --cookie-jar <file name> File to save response cookies to.

chanks

Turning PostgreSQL into a queue serving 10,000 jobs per second

RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.

On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.

So, many developers have started going straight t