mrmartineau

Stimulus cheatsheet

• Website: https://stimulusjs.org/
• GitHub repo: https://github.com/stimulusjs/stimulus
• Handbook: https://stimulusjs.org/handbook/introduction
• Discourse: https://discourse.stimulusjs.org/

Lifecycle callbacks

• initialize: once, when the controller is first instantiated
• connect: anytime the controller is connected to the DOM

dhh

#!/usr/bin/env bash

# Abort sign off on any error
set -e

# Start the benchmark timer
SECONDS=0

# Repository introspection
OWNER=$(gh repo view --json owner --jq .owner.login)

zhengjia

=Navigating=
    visit('/projects')
    visit(post_comments_path(post))

=Clicking links and buttons=
    click_link('id-of-link')
    click_link('Link Text')
    click_button('Save')
    click('Link Text') # Click either a link or a button
    click('Button Value')

ProGM

Arel Cheatsheet on Steroids

A (more) complete cheatsheet for Arel, including NamedFunction functions, raw SQL and window functions.

Tables

posts = Arel::Table.new(:posts)
posts = Post.arel_table # ActiveRecord

Table alias

erichurst

# MySQL.  Versions 4.1 and 5.0 are recommended.
#
# Install the MySQL driver:
#   gem install mysql2
#
# And be sure to use new-style password hashing:
#   http://dev.mysql.com/doc/refman/5.0/en/old-client.html
development:
  adapter: mysql2
  encoding: utf8

dteoh

Setting session variables in an RSpec Rails request spec

You are writing a spec with type: :request, i.e. an integration spec instead of a controller spec. Integration specs are wrappers around Rails' ActionDispatch::IntegrationTest class. I usually write controller tests using this instead of type: :controller, mainly because it exercises more of the request and response handling stack. So instead of writing something like get :index to start the request, you would write get books_path or similar.

One of the issues with using type: :request is that you lose the ability to

lewispb

module SessionSystemTestHelper
  def sign_in_as(user)
    visit root_url # any fast-to-load page will do

    cookie_jar = ActionDispatch::TestRequest.create.cookie_jar
    cookie_jar.signed[:session_token] = user.sessions.create.token
    page.driver.browser.manage.add_cookie(name: "session_token", value: cookie_jar[:session_token], sameSite: :Lax, httpOnly: true)
  end
end

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

fiftin

1. Dump the data only sql to file
  $ pg_dump --data-only --inserts YOUR_DB_NAME > dump.sql
2. scp to local

3. Remove the SET statements at the top
  such as:
    SET statement_timeout = 0;
    SET client_encoding = 'SQL_ASCII';

4. Remove the setval sequence queries

return1

# install dependencies
sudo apt-get install libcurl4-openssl-dev libncurses5-dev pkg-config automake yasm

# clone cpuminer
git clone https://github.com/pooler/cpuminer.git

# compile
cd cpuminer
./autogen.sh
./configure CFLAGS="-O3"