Skip to content

Instantly share code, notes, and snippets.

% ./force-failure
Building linux binary in build/bin
Building darwin binary in build/bin
# command-line-arguments
clang: warning: argument unused during compilation: '-nopie'
Binaries found in:
build/dist/gh-ost-binary-linux-20190607173922.tar.gz
build/dist/gh-ost-binary-osx-20190607173922.tar.gz
### Building docker image for 5.7.21
Sending build context to Docker daemon 4.608kB
2019-06-05 23:14:38 INFO starting gh-ost 1.0.48
2019-06-05 23:14:38 INFO Migrating `test`.`gh_ost_test`
2019-06-05 23:14:38 INFO connection validated on 127.0.0.1:5722
2019-06-05 23:14:38 INFO User has ALL privileges
2019-06-05 23:14:38 INFO binary logs validated on 127.0.0.1:5722
2019-06-05 23:14:38 INFO Inspector initiated on f17262bbdece:5722, version 5.7.21-log
2019-06-05 23:14:38 INFO Table found. Engine=InnoDB
2019-06-05 23:14:38 DEBUG Estimated number of rows via STATUS: 2
2019-06-05 23:14:38 DEBUG Validated no foreign keys exist on table
2019-06-05 23:14:38 DEBUG Validated no triggers exist on table
@zmoazeni
zmoazeni / concept.md
Created July 17, 2018 19:13
TestLock Concept

The main concept of a Test Lock is basically a mutex between the thread running the tests and the thread handling the server requests.

Our main issue had to do with our teardown destroying database records while a request was ongoing. It's extremely tricky to debug because it's entirely timing based. (Request begins, before_actions are happy, teardown begins, records are destroyed, request sometimes freaks out).

So the idea is that once we TestLock.join, we flip a gate that disallows any new requests, and blocks until the existing request is complete. Then we know we can safely purge the database (and other elements).

module Jekyll
class VersionedPage < Page
def initialize(site, base, dir, version, post)
@site = site
@base = base
@dir = dir
@name = "#{version}/#{post.url}#{post.data["ext"]}"
process(@name)
self.content = post.content
self.data = post.data
@zmoazeni
zmoazeni / gist:d141eb175c98f832e0c3
Last active August 29, 2015 14:13
What setting affects this?
# Application that is upgrading to 4.1.9
{"miles" => 12.45.to_d}.to_json
=> "{\"miles\":12.45}"
# Brand new 4.1.9 application
{"miles" => 12.45.to_d}.to_json
@zmoazeni
zmoazeni / gist:e317b78a8c37a2e2fc2a
Created December 18, 2014 17:49
I've been using this instead of OpenStruct lately
SomeObj = Struct.new(:foo, :bar, :baz) do
def initialize(foo:, bar:, baz: 'is optional')
self.foo = foo
self.bar = bar
self.baz = baz
end
end
p SomeObj.new(foo: 1, bar: 2)
p SomeObj.new(foo: 1, bar: 2, baz: 'overridden')
∴ cd /tmp/
∴ mkdir testing-hashtables
∴ cd testing-hashtables/
∴ cabal sandbox init
Writing a default package environment file to
/private/tmp/testing-hashtables/cabal.sandbox.config
Creating a new sandbox at /private/tmp/testing-hashtables/.cabal-sandbox
∴ cabal install hashtables
Resolving dependencies...
Notice: installing into a sandbox located at
@zmoazeni
zmoazeni / gist:a035f72f0c9d0931f471
Last active August 29, 2015 14:10
Run interpreter and REPL using cabal sandbox packages
cabal exec -- ghci # starts ghci with cabal sandbox set
cabal exec -- runghc ... # runs runghc with cabal sandbox set
def foo(a, bar: 'something else')
puts "a: [#{a}], bar: [#{bar}]"
end
some_hash = { :bar => 'passed as a param' }
foo(1, some_hash) # outputs: a: [1], bar: [passed as a param]
should_i_do_it = false
def foo(bar:, do_it: true)
puts "bar: [#{bar}] do_it: [#{do_it}]"
end
foo(:bar => 'this be bar', :do_it => should_i_do_it)
foo(bar: 'this be bar', do_it: should_i_do_it)