cluesque

WITH column_info AS (
  SELECT t.relname AS table_name, c.attname AS column_name, c.atttypid, c.attlen AS length, y.typname AS type
         , pg_get_expr(adbin, adrelid) AS default
         , (regexp_matches(pg_get_expr(adbin, adrelid), 'nextval..(.*).::regclass'))[1] AS sequencename
  FROM pg_class t
  LEFT OUTER JOIN pg_attribute c ON c.attrelid = t.oid
  LEFT OUTER JOIN pg_type y ON y.oid = c.atttypid
  LEFT OUTER JOIN pg_attrdef d ON t.oid = d.adrelid AND d.adnum = c.attnum
  WHERE pg_get_expr(adbin, adrelid) LIKE '%nextval%'
),

cluesque

# Have your health checker execute this
require './liveness_monitor'

puts LivenessMonitor.new.status

cluesque

# Useful for tracking the progress of a large batch job
# Pass in 'counter', a lambda that returns an integer
# This will periodically call the counter,
# track the rate counted things are consumed (or produced)
# and make a prediction about when it completes

# options:
# - divisor: how many times per minute to sample, default 6 (every ten seconds)
# - rolling_window: how many rate samples to average when making predictions (default 10)
# - target: what value are we aiming for, default 0 (consuming a queue)

cluesque

# This goes at global scope (remove it from your other groups)
gem 'pry-rails', require: false
gem 'pry-byebug', require: false

cluesque

DHH's On Writing Software (well?) [episode 2](https://www.youtube.com/watch?v=m1jOWu7woKM) discussed callbacks, specifically the practice of hiding side effects of object creation using `after_save` and `after_commit` hooks.

It implicitly conceeded that `after_commit`, lacking information about what was just committed, was flawed, and uses the common workaround of using an `after_save` to decide to do something based on changes and set an @ivar, and then in the `after_commit` acting on the @ivar found.  Which is fun, but.

It also [at the end](https://youtu.be/m1jOWu7woKM?t=1151) discussed the possibility that in some use cases a caller might want to explicitly prevent side effects from happening.  Think about when audited temporarily suppresses auditing, or perhaps one might want to bulk update some data, without sending the email normally sent when said data is updated.

It teased the presence of a `Suppressible` mixin.  For fun, I wrote it.

Update: turns out the real one is public.  It uses `thread_mattr

cluesque

Keybase proof

I hereby claim:

• I am cluesque on github.
• I am cluesque (https://keybase.io/cluesque) on keybase.
• I have a public key ASBvxQlEpGPq_kkRyixFNNvyPL7H1ag6fwoz4Dmb40Nsrgo

To claim this, I am signing this object:

cluesque

04ac10d9df868268f354c546fb71262375a7fa654841cebc1ce5e3269d2f69de9c614b2235c2311d23e26f55a5c38601e240f0168c8ecc7255b2e940f50fa783b8

cluesque

class Cryptor
  # Usage:
  # cipher = Cryptor.new(key, auth_data: '1234').encrypt(clear)
  # clear = Cryptor.new(key, auth_data: '12344').decrypt(cipher)
  attr_accessor :key, :auth_data

  # The auth_data should be something different for each text, perhaps a database row id?
  def initialize(key, auth_data: 'aad')
    self.mode = mode
    self.key = key

cluesque

d5toqvrtbm8bbu=> SELECT id, created_at FROM widgets WHERE id = 1155301;
   id    |         created_at         
---------+----------------------------
 1155301 | 2014-01-10 02:59:47.856214
(1 row)

d5toqvrtbm8bbu=> CREATE UNIQUE INDEX widgets_pkey ON widgets(id);
CREATE INDEX
d5toqvrtbm8bbu=> SELECT id, created_at FROM widgets WHERE id = 1155301;
 id | created_at 

cluesque

traceroute to 216.81.59.173 (216.81.59.173), 64 hops max, 52 byte packets
...
 8  100gigabitethernet11-1.core1.ash1.he.net (184.105.223.165)  14.978 ms
 9  10gigabitethernet1-2.core1.atl1.he.net (184.105.213.110)  33.392 ms
10  216.66.0.26 (216.66.0.26)  29.782 ms
11  *
12  episode.iv (206.214.251.1)  120.330 ms
13  a.new.hope (206.214.251.6)  73.192 ms
14  it.is.a.period.of.civil.war (206.214.251.9)  98.692 ms
15  rebel.spaceships (206.214.251.14)  68.083 ms