The following MySQL command will show you long-running processes (exceeding 5 seconds in this case).

select * from information_schema.processlist where command <> 'sleep' and time > 5;

You can run it from console to view those happening now, or you could make a script to poll it periodically, with something like:

echo "select * from information_schema.processlist where command <> 'sleep' and time > 5;" | mysql > long-running.log

(See also

View sidekiq_utils.rb
Class SidekiqUtils
def self.queues { |name| }
def self.find_queue(name)
self.queues.find { |q| }
View gist:e21eecf4c4e27da5f2ae14265127245a
- name: Backup original my.cnf
copy: remote_src=true src=/etc/mysql/my.cnf dest=/tmp/my.cnf.recent
- name : Update my.cnf
template: src=my.cnf.j2 dest=/etc/mysql/my.cnf owner=mysql mode=0644
# diff returns error code if different, so we ignore "errors"
- name: Check if my.cnf changed
command: diff /etc/mysql/my.cnf /tmp/my.cnf.recent
ignore_errors: true


It's important to have useful test data during development and debugging, resembling real-world data. It can be cumbersome to setup and maintain though. This is a mini-framework to help with seeding in Rails using a Domain Specific Language approach.


  • I got tired of maintaining seeds.rb idempotently. Too dangerous to run this directly into production and overall, cumbersome to make it idempotent (ie work whether or not the objects already exist). So I decided to just make something that's just used for development, starting from an empty DB each time. I'm now maintaining a separate folder of individual data migrations to be performed in production. There's also separate fixtures for testing (separate data than this for performance reasons, and because tests need different kinds of data).
  • It's modular enough for parts to be invoked during testing.
  • The modularity is also part of a domain-specific language approach to seeding, as can be seen in the examples.

Sometimes it gets into inconsistent state. For testing purposes, we don't want to debug it, we just want to start again.

  1. kill elasticsearch if it's running
  2. brew info elasticsearch
  3. Look for a line like `Data: /usr/local/var/elasticsearch/elasticsearch_foo/
  4. rm -fr /usr/local/var/elasticsearch/elasticsearch_foo
  5. restart elasticsearch and enjoy your tabula rasa

Something I noticed after settiing use_transactional_tests = false is that fixture files need to be present even if they don't have any data. An empty yml file means the model will be reset after every test run, i.e. you won't have side effects from creating new instances in a test.

It feels off to see an empty file (or just commented) and keep it in the project, but you need to do it.


Expanding on the README...

(Work in progress, read at own risk as some info may be wrong)

Set "main" database

This is the initial database Rails uses. If there's a core database in the system, specify this one.

In config/database.yml (not shards.yml). Simple version:


The code here is a tech demo showing how to switch between databases in Rails 5, in a thread-safe manner.


The simple way to switch databases is:

ActiveRecord::Base.establish_connection :user_shard1
puts User.find(1) # this is executed on the database keyed on "user_shard1" in database.yml
ActiveRecord::Base.establish_connection :development

I used successfully to sell a domain, but I did learn later there's a potential fraud as they only take control of the buyer's funds, not the seller's domain. The domain is still transferred directly from seller to buyer. There's potential fraud where the seller hides the domain after you xfer it, and tries to get their money back from the escrow.

Not sure how much of an issue in practice, it partly will depend on your confidence in the buyer (escrow actually told me they know the buyer well so I was fairly confident). Ideally you should find a good escrow that takes both sides before swapping them, but not sure if there are any trusted names that do this tbh.


First, DNS problems - Linode pointed me to (mainly need to up sudo apt-get update && sudo apt-get upgrade, possibly reboot)

As quick fix, appended dns-nameservers to /etc/network/interfaces and running "sudo service networking restart".

vi /etc/apt/sources.list Append:

deb xenial main testing
deb-src xenial main testing