(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.
(defun open-finder-1 (dir file) | |
(let ((script | |
(if file | |
(concat | |
"tell application \"Finder\"\n" | |
" set frontmost to true\n" | |
" make new Finder window to (POSIX file \"" dir "\")\n" | |
" select file \"" file "\"\n" | |
"end tell\n") | |
(concat |
(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.
// Create our server | |
var server; | |
server = http.createServer(function(req,res){ | |
// Set CORS headers | |
res.setHeader('Access-Control-Allow-Origin', '*'); | |
res.setHeader('Access-Control-Request-Method', '*'); | |
res.setHeader('Access-Control-Allow-Methods', 'OPTIONS, GET'); | |
res.setHeader('Access-Control-Allow-Headers', '*'); | |
if ( req.method === 'OPTIONS' ) { | |
res.writeHead(200); |
;; Grateful thanks are given to Brian Marick (@marick) for helping me | |
;; write these. I got the original idea while reading through | |
;; http://xahlee.org/emacs/elisp_idioms.html, but couldn't work out | |
;; the elisp regexes. Brian Marick (@marick) stepped in and helped. He | |
;; took my tortured and broken camelcase-region and turned it into | |
;; something that actually worked. I then created | |
;; camelcase-word-or-region. I then wrote the snakecase versions but I | |
;; see now that all I did was copy the camelcase defuns over and, | |
;; meaning to go back and finish them Real Soon Now, forgot all about | |
;; them. I've had a quick look (2011-02-27) but elisp regexes are |
The Critical Rendering Path is the sequence of steps the browser goes through to convert the HTML, CSS and JavaScript into actual pixels on the screen. If we can optimize the critical rendering path, we can make our pages faster.
When you type an URL and hit enter, the browser sends a request to the server. The server returns a response with the HTML to the browser, which somehow needs to convert the markup into something that we can see on the screen.
The browser follows a well defined set of steps and it all starts with processing the HTML and building the DOM.
LOADING=false | |
usage() | |
{ | |
cat << EOF | |
usage: $0 [options] dbname | |
OPTIONS: | |
-h Show this help. | |
-l Load instead of export |
#!/bin/bash | |
LOADING=false | |
DEBUG=/dev/null | |
usage() | |
{ | |
cat << EOF | |
usage: $0 [options] <DBNAME> |
var detectBackOrForward = function(onBack, onForward) { | |
hashHistory = [window.location.hash]; | |
historyLength = window.history.length; | |
return function() { | |
var hash = window.location.hash, length = window.history.length; | |
if (hashHistory.length && historyLength == length) { | |
if (hashHistory[hashHistory.length - 2] == hash) { | |
hashHistory = hashHistory.slice(0, -1); | |
onBack(); |
Eric Bidelman has documented some of the common workflows possible with headless Chrome over in https://developers.google.com/web/updates/2017/04/headless-chrome.
If you're looking at this in 2016 and beyond, I strongly recommend investigating real headless Chrome: https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md
Windows and Mac users might find using Justin Ribeiro's Docker setup useful here while full support for these platforms is being worked out.