(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
- name: ensure github.com is a known host | |
lineinfile: | |
dest: /root/.ssh/known_hosts | |
create: yes | |
state: present | |
line: "{{ lookup('pipe', 'ssh-keyscan -t rsa github.com') }}" | |
regexp: "^github\\.com" |
I wanted to figure out the fastest way to load non-critical CSS so that the impact on initial page drawing is minimal.
TL;DR: Here's the solution I ended up with: https://github.com/filamentgroup/loadCSS/
For async JavaScript file requests, we have the async
attribute to make this easy, but CSS file requests have no similar standard mechanism (at least, none that will still apply the CSS after loading - here are some async CSS loading conditions that do apply when CSS is inapplicable to media: https://gist.github.com/igrigorik/2935269#file-notes-md ).
Seems there are a couple ways to load and apply a CSS file in a non-blocking manner:
# | |
# Name: nginx-tls.conf | |
# Auth: Gavin Lloyd <gavinhungry@gmail.com> | |
# Desc: Nginx SSL/TLS configuration for "A+" Qualys SSL Labs rating | |
# | |
# Enables HTTP/2, PFS, HSTS and OCSP stapling. Configuration options not related | |
# to SSL/TLS are not included here. | |
# | |
# Additional tips: | |
# |
window.console.clog = function(log){ | |
var message = typeof log === 'object' ? '%cLooks like you\'re trying to log an ' : '%cLooks like you\'re trying to log a ', | |
style = 'background:url(http://i.imgur.com/SErVs5H.png);padding:5px 15px 142px 19px;line-height:280px;'; | |
console.log.call(console, message + typeof log + '.', style); | |
}; |
App configuration in environment variables: for and against | |
For (some of these as per the 12 factor principles) | |
1) they are are easy to change between deploys without changing any code | |
2) unlike config files, there is little chance of them being checked | |
into the code repo accidentally | |
3) unlike custom config files, or other config mechanisms such as Java |
# Feel free to change this path of course (and keys_zone value as well, but also change the usage of it below). | |
proxy_cache_path /var/www/cache/resized levels=1:2 keys_zone=resizedimages:10m max_size=1G; | |
# Gzip was on in another conf file of mine...You may need to uncomment the next line. | |
#gzip on; | |
gzip_disable msie6; | |
gzip_static on; | |
gzip_comp_level 4; | |
gzip_proxied any; | |
# Again, be careful that you aren't overwriting some other setting from another config's http {} section. |
<VirtualHost *:{PORT}> | |
ServerName www.yourdomain.com | |
ServerAdmin mail@domain.com | |
DocumentRoot /var/www/yourdir/ | |
<Directory /var/www/yourdir> | |
Options Indexes FollowSymLinks | |
AllowOverride all | |
Order allow,deny |
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