burningsky250

rabbitmq exchange type:

• direct:

  when a queue is bound to this exchange with a specific routing_key(rk), messages coming into the exchange with topic of the same with the routing_key(rk) will be pushed into the queue. if there are multiple queues bound with the same routing key, the message will be fan-outed to all the queues.

• fan-out

  when a queue is bound to this exchange, whatever the routing key is specified, a message coming into the exchange will be fan-outed to the queue.

• topic

burningsky250

1. network

• fping: fast&concurrent ping to multiple hosts
• jq: json parse in structured way

burningsky250

#!/bin/bash
# bash generate random alphanumeric string
#

# bash generate random 32 character alphanumeric string (upper and lowercase) and 
NEW_UUID=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)

# bash generate random 32 character alphanumeric string (lowercase only)
cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1

burningsky250

import sys
import os
print os.path.join(sys.prefix, "lib","python" + sys.version[:3])

burningsky250

• source： https://stackoverflow.com/questions/34695052/how-is-django-persistent-database-connections-thread-safe

The ConnectionHandler is not a connection -- it only handles connections. It does so in a perfectly thread-safe manner by storing them on self._connections, which is a thread.local instance. The ConnectionHandler overrides getitem to support thread-local connections. When you access connections['default'], it looks if the default attribute exists on self._connections, which is a thread local. If it does, that would be the connection to the default database for the current thread. If it doesn't, it'll create a new one and set it on self._connections. Other threads won't be able to access this connection, since it's set on a thread local object. In the end it pretty much comes down to the public API. Setting a ConnectionHandler on a thread-local object would work as well, but the public API would be more complicated than it currently is, since user code would manually need to check if the

burningsky250

# Autoreloading launcher.
# Borrowed from Peter Hunt and the CherryPy project (https://cherrypy.org/).
# Some taken from Ian Bicking's Paste (http://pythonpaste.org/).
#
# Portions copyright (c) 2004, CherryPy Team (team@cherrypy.org)
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without modification,
# are permitted provided that the following conditions are met:
#

burningsky250

comparison with many ways to construct a big list:

1. list repeat

python -m timeit -n 10 -r 10 -v '[0]*10000000'
raw times: 0.561 0.528 0.519 0.516 0.516 0.557 0.516 0.513 0.516 0.509
10 loops, best of 10: 50.9 msec per loop

hint: create python object 'int' once, repeat it 10,000,000 times.

burningsky250

### Keybase proof

I hereby claim:

  * I am burningsky250 on github.
  * I am burningsky (https://keybase.io/burningsky) on keybase.
  * I have a public key ASCbrlzxFlKZpPrZqTisHAOfIZWY1tstlGF2wiT8-h0v3Ao

To claim this, I am signing this object:

burningsky250

import collections

def dict_merge(dct, merge_dct):
    """ Recursive dict merge. Inspired by :meth:``dict.update()``, instead of
    updating only top-level keys, dict_merge recurses down into dicts nested
    to an arbitrary depth, updating keys. The ``merge_dct`` is merged into
    ``dct``.

    :param dct: dict onto which the merge is executed
    :param merge_dct: dct merged into dct

burningsky250

#!/usr/bin/env python3
# coding=utf-8
import json

from ansible.executor.task_queue_manager import TaskQueueManager
from ansible.inventory import Inventory
from ansible.inventory.group import Group
from ansible.inventory.host import Host
from ansible.parsing.dataloader import DataLoader
from ansible.playbook.play import Play