Petr Kaleta PetrKaleta

PetrKaleta / gist:4434069

Last active December 10, 2015 12:28

Custom Typhoeus based QC Worker Note: I've never tested this code, its just an example

	require 'queue_classic'
	require 'typhoeus'

	trap('INT') { exit }
	trap('TERM') { worker.stop }


	# Generic consumer
	class TyphoeusConcurrentJob

PetrKaleta / classic_worker.rb

Last active December 10, 2015 15:08

This code demonstrates how you can create queue_classic worker which will do concurrent requests to 3rd party APIs.

	# This code is demonstrating a default queue_classic worker.
	# The biggest issue is, that requests made by its jobs are blocking

	require 'rubygems'
	require 'queue_classic'
	require 'typhoeus'

	trap('INT') { exit }
	trap('TERM') { worker.stop }

PetrKaleta / Rakefile

Last active August 29, 2015 14:01

Heroku deploy rake tasks with hooks. Demonstrates how to trigger Sidekiq to quiet or terminate via API before deploy

	# List of environments and their heroku git remotes (id: 'remote_name')
	HEROKU_ENVIRONMENTS = {
	staging: 'staging-remote-name',
	production: 'production-remote-name'
	}

	namespace :deploy do
	# Create rake tasks to deploy on Heroku environments
	# $ rake -T deploy
	# rake deploy:production # Deploy to production

PetrKaleta / gist:704639f9e9bf8798b815

Last active August 29, 2015 14:03

Strange microseconds issue when querying by time

	# Please have a look, how updated_at timestamp is represented in generated SQL

	# In this example everything is OK
	Event.where(Sequel.expr(:updated_at) > Time.at(1405338941.821000)).sql
	# => "SELECT * FROM \"events\" WHERE (\"updated_at\" > '2014-07-14 13:55:41.821000+0200')"

	# In this example, there's a precision issue (see microseconds), why?
	Event.where(Sequel.expr(:updated_at) > Time.at(1405341161.918000)).sql
	# => "SELECT * FROM \"events\" WHERE (\"updated_at\" > '2014-07-14 14:32:41.917999+0200')"