start new:
tmux
start new with session name:
tmux new -s myname
# -*- coding: utf-8 -*- | |
from django import forms | |
from crispy_forms.helper import FormHelper | |
from crispy_forms.layout import Layout, Div, Submit, HTML, Button, Row, Field | |
from crispy_forms.bootstrap import AppendedText, PrependedText, FormActions | |
class MessageForm(forms.Form): | |
text_input = forms.CharField() |
[default] | |
access_key = asf | |
bucket_location = US | |
cloudfront_host = cloudfront.amazonaws.com | |
cloudfront_resource = /2010-07-15/distribution | |
default_mime_type = binary/octet-stream | |
delete_removed = False | |
dry_run = False | |
encoding = UTF-8 | |
encrypt = False |
/** | |
** ____ _ ___ ___ _ _ | |
** | _ \ | | | \/ | | | (_) | |
** | | \ |__ _ _ __| | __ | . . | ___ _ __ ___ | | __ __ _ _ | |
** | | | | _` | '__| |/ / | |\/| |/ _ \| '_ \ / _ \| |/ // _` | | | |
** | |_/ /(_| | | | < | | | | (_) | | | | (_) | <| (_| | | | |
** |____/\__,_|_| |_|\_\ \_| |_/\___/|_| |_|\___/|_|\_\\__,_|_| | |
** | |
** Quassel Theme | |
** |
In August 2007 a hacker found a way to expose the PHP source code on facebook.com. He retrieved two files and then emailed them to me, and I wrote about the issue:
http://techcrunch.com/2007/08/11/facebook-source-code-leaked/
It became a big deal:
http://www.techmeme.com/070812/p1#a070812p1
The two files are index.php (the homepage) and search.php (the search page)
#!/usr/bin/env python | |
from pygame import camera | |
import pygame | |
import time | |
import cv | |
import os | |
# Recognition |
"Adapted from http://www.slideshare.net/nourybouraqadi/pharo-networking-by-example | |
$! denotes the end of a message | |
" | |
| connectionSock interactSock request stream | | |
connectionSock := Socket newTCP. | |
[ | |
connectionSock listenOn: 8888 backlogSize: 10. | |
interactSock := connectionSock waitForAcceptFor: 15. | |
stream := SocketStream on: interactSock. |
import socket | |
HOST = 'localhost' | |
PORT = 9876 | |
ADDR = (HOST,PORT) | |
BUFSIZE = 4096 | |
videofile = "videos/royalty-free_footage_wien_18_640x360.mp4" | |
bytes = open(videofile).read() |
#说明:
##百度公共库
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t