start new:
tmux
start new with session name:
tmux new -s myname
--colour | |
-I app |
class ZendeskTicketsJob | |
extend Resque::Plugins::ExponentialBackoff | |
@queue = :low | |
FIELDS = ['zendesk_id', 'requester_id', 'assignee_id', 'group', 'subject', 'tags', 'status', 'priority', 'via', 'ticket_type', 'created_at', 'assigned_at', 'solved_at', 'resolution_time', 'satisfaction', 'group_stations', 'assignee_stations', 'reopens', 'replies', 'first_reply_time_in_minutes', 'first_reply_time_in_minutes_within_business_hours', 'first_resolution_time_in_minutes', 'first_resolution_time_in_minutes_within_business_hours', 'full_resolution_time_in_minutes', 'full_resolution_time_in_minutes_within_business_hours', 'agent_wait_time_in_minutes', 'agent_wait_time_in_minutes_within_business_hours', 'requester_wait_time_in_minutes', 'requester_wait_time_in_minutes_within_business_hours', 'reservation_code', 'requires_manual_closing'] | |
def self.perform(url) | |
`rm /tmp/zendesk_tickets*` | |
`wget #{url} -O /tmp/zendesk_tickets.csv.zip` | |
`unzip -p /tmp/zendesk_tickets.csv.zip > /tmp/zendesk_tickets.csv` | |
Once in a while, you may need to cleanup resources (containers, volumes, images, networks) ...
// see: https://github.com/chadoe/docker-cleanup-volumes
$ docker volume rm $(docker volume ls -qf dangling=true)
$ docker volume ls -qf dangling=true | xargs -r docker volume rm
Concurrency is a domain I have wanted to explore for a long time because the locks and the race conditions have always intimidated me. I recall somebody suggesting concurrency patterns in golang because they said "you share the data and not the variables".
Amused by that, I searched for "concurrency in golang" and bumped into this awesome slide by Rob Pike: https://talks.golang.org/2012/waza.slide#1 which does a great job of explaining channels, concurrency patterns and a mini-architecture of load-balancer (also explains the above one-liner).
Let's dig in:
# Thee will be more information here when I share the entire problem space I'm working on, but | |
# in short, this is preview material for my second talk in a series called "What Computer Scientists Know". | |
# The first talk is on recursion, and goes through several examples., leading up to a problem based | |
# on a simple puzzle that initial estimates based on performance of a previous puzzle would take years | |
# to solve on modern computers with the techniques shown in Ruby. That sets the stage for improving the | |
# performance of that problem with threading, concurrency, and related tuning. | |
# | |
# The second talk is on threading and concurrency, touching on algorithmic performance as well. | |
# Using some knowledge of the problem (board symmetry, illegal moves, etc), we reduce the problem space | |
# to about .5% of what we initially thought it was. Still, the initial single threaded solution took more |
# Original Rails controller and action | |
class EmployeesController < ApplicationController | |
def create | |
@employee = Employee.new(employee_params) | |
if @employee.save | |
redirect_to @employee, notice: "Employee #{@employee.name} created" | |
else | |
render :new | |
end |
############################################################################### | |
## Monit control file | |
############################################################################### | |
## | |
## Comments begin with a '#' and extend through the end of the line. Keywords | |
## are case insensitive. All path's MUST BE FULLY QUALIFIED, starting with '/'. | |
## | |
## Below you will find examples of some frequently used statements. For | |
## information about the control file, a complete list of statements and | |
## options please have a look in the monit manual. |
List moved
Please use https://github.com/bf4/learning to fork and pull changes.