UPDATE (2021-03-31): I've posted an improved version of this guide with newer versions of the software.
I hate when my images turn out like this:
UPDATE (2021-03-31): I've posted an improved version of this guide with newer versions of the software.
I hate when my images turn out like this:
This worker script will evaluate your origin response, and replace html comments marked as fragment:key
with a respective prefetch defined in a X-Fragments
response header.
Your origin must include the X-Fragments
header, specifying the a comma separated list of prefetch requests to make for that response.
< HTTP/1.1 200 OK
Recently, Let's Encrypt launched free wildcard certificates. While this is good news in and of itself, as it removes one of the last remaining reasons for expensive commercial certificates, I've unfortunately seen a lot of people dangerously misunderstand what wildcard certificates are for.
Therefore, in this brief post I'll explain why you probably shouldn't use a wildcard certificate, as it will put your security at risk.
It's generally pretty poorly understood (and documented!) how TLS ("SSL") works, so let's go through a brief explanation of the parts that are important here.
The general (simplified) idea behind how real-world TLS deployments work, is that you:
# This task will notify Sentry via their API[1] that you have deployed | |
# a new release. It uses the release timestamp as the `version` | |
# (like 20151113182847) and the git ref as the optional `ref` value. | |
# | |
# This task requires several environment variables be set (or just | |
# hardcode the values in here if you like living on the edge): | |
# | |
# ENV['SENTRY_API_ENDPOINT'] : API endpoint, https://app.getsentry.com | |
# ENV['SENTRY_ORG'] : the organization for this app | |
# ENV['SENTRY_PROJECT'] : the project for this app |
/* bling.js */ | |
window.$ = document.querySelectorAll.bind(document); | |
Node.prototype.on = window.on = function (name, fn) { | |
this.addEventListener(name, fn); | |
}; | |
NodeList.prototype.__proto__ = Array.prototype; |
#!/usr/bin/env node | |
// This plugin replaces text in a file with the app version from config.xml. | |
var wwwFileToReplace = "js/build.js"; | |
var fs = require('fs'); | |
var path = require('path'); | |
var rootdir = process.argv[2]; |
$.rails.allowAction = function(link) { | |
if ( ! link.attr('data-confirm') ) return true; | |
$.rails.showConfirmDialog(link); | |
return false; | |
}; | |
$.rails.confirmed = function(link) { | |
link.removeAttr('data-confirm'); | |
link.trigger('click.rails'); | |
}; |
/* | |
Minimal Facebook Messenger | |
========================== | |
1. Make a Fluid (http://fluidapp.com/) instance of https://facebook.com/messages/ | |
1. a. (You need to buy the paid version of Fluid to modify UserStyles) | |
2. Apply the below CSS as a Userstyles stylesheet | |
3. Like magic, you can now message without all the cruft of Full Facebook | |
server { | |
listen 80; | |
root /var/www/craft.dev/public; | |
index index.php index.html index.htm; | |
server_name craft.dev; | |
location / { | |
try_files $uri $uri/ @rewrites; |
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.