国内从 Docker Hub 拉取镜像有时会遇到困难,此时可以配置镜像加速器。
Dockerized 实践 https://github.com/y0ngb1n/dockerized
国内从 Docker Hub 拉取镜像有时会遇到困难,此时可以配置镜像加速器。
Dockerized 实践 https://github.com/y0ngb1n/dockerized
This document describes about installation and configuration of IPMI simulator. | |
We need: qemu-kvm, OpenIPMI, OpenIPMI-tools | |
1) Install the qemu-kvm. We need the qemu, which have the IPMI pacthes. | |
Use the source https://github.com/cminyard/qemu/tree/stable-2.2-ipmi | |
./configure, make and make install | |
2) Download the OpenIPMI libraries, from http://sourceforge.net/projects/openipmi/ | |
Follow the process documented in lanserv/README.vm | |
./configure --prefix=/opt/openipmi/usr --sysconfdir=/opt/openipmi/etc \ | |
--with-perlinstall=/opt/openipmi/usr/lib/perl \ |
alembic
is great but lacks an out of the box way to set up running migrations against a specific database (e.g. development
, test
, production
). The following adjustments to its env.py
and alembic.ini
allow us to target a specific database:
Example:
alembic -x db=development upgrade head
env.py:
Flask-SQLAlchemy has some nice built-ins (e.g. accessing query
directly on classes). To continue leveraging these nicities while still inside of a Celery worker, we need to make sure we setup/teardown in a similar fashion to Flask-SQLAlchemy does on Flask.
Flask-SQLAlchemy uses create_scoped_session
at startup which avoids any setup on a per-request basis.
https://github.com/mitsuhiko/flask-sqlalchemy/blob/2.0/flask_sqlalchemy/__init__.py#L668
This means Celery can piggyback off of this initialization.
# ASIA | |
_ = '173.194.36.%s' # del 印度 新德里 | |
SG3 = '173.194.38.%s' # 新加坡 | |
TW3 = '173.194.72.%s' | |
SG4 = '173.194.117.%s' | |
JP2 = '173.194.120.%s' | |
_ = '173.194.123.%s' | |
JP1 = '173.194.126.%s' | |
HK1 = '173.194.127.%s' | |
TW1 = '74.125.23.%s' |
""" | |
Add copy to clipboard from IPython! | |
To install, just copy it to your profile/startup directory, typically: | |
~/.ipython/profile_default/startup/ | |
Example usage: | |
%clip hello world | |
# will store "hello world" |
#! /usr/bin/env python | |
"""{escher} -- one-file key-value storage. | |
What? | |
This is a toy application to manage persistent key-value string data. | |
The file {escher} is *both* the application and its data. | |
When you run any of the commands below, the file will be executed and, | |
after data change, it will rewrite itself with updated data. | |
You can copy the file with whatever name to create multiple datasets. |
#include <vector> | |
#include <list> | |
#include <map> | |
#include <set> | |
#include <deque> | |
#include <stack> | |
#include <bitset> | |
#include <algorithm> | |
#include <functional> | |
#include <numeric> |
(function($){ | |
$(document).ready(function(){ | |
$('.section-header').each(function(){ | |
var $this = $(this); | |
// use .add() and .nextUntil() to get both the .section-header | |
// and .section-item elements into a single set for our .wrapAll() call | |
$this.add($this.nextUntil('.section-header', '.section-item')) | |
.wrapAll('<div class="section-container"></div>'); |
''' | |
Cache the generic relation field of all the objects | |
in the queryset, using larger bulk queries ahead of time. | |
Improved from original by Daniel Roseman: | |
http://blog.roseman.org.uk/2010/02/22/django-patterns-part-4-forwards-generic-relations/ | |
''' | |
def cache_generics(queryset): |