#Jekyll Base64 Encoder A Liquid tag for base64 encoding
Note: this plugin requires Colorize:
gem install colorize
#!/usr/bin/env bash | |
cat $1 | R -rR --slurp \ | |
'unlines' \ | |
'to-lower' \ | |
'match /\w+/g' \ | |
'lodash.uniq' \ | |
'sort-by length' \ | |
'reverse' \ | |
'take 10' |
#Jekyll Base64 Encoder A Liquid tag for base64 encoding
Note: this plugin requires Colorize:
gem install colorize
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
, elem.offsetTop
, elem.offsetWidth
, elem.offsetHeight
, elem.offsetParent
Just some early draft thoughts
Increased modularity is a long-standing request of jQuery. 3.0 should deliver on that. Many authors will use jQuery 3.0 in ES6 codebases, and often alongside frameworks that have overlap in functionality.
That said, a majority of developers will use a monolithic build. jQuery 3.0 must aggressively remove API surface area and functionality from this core build to protect developers from performance footguns. The jQuery team has reasonably voiced concern that removing modules means it's less likely for people to upgrade. While some users do attempt jQuery version upgrades, many freeze their version and never revisit it. I'd like to get more data on this phenomenon as I think we're optimizing API deprecation policy for a small audience.
Lastly, it's 2015 and the gap between JavaScript developers and jQuery developers has never been bigger. Let's bridge that gap. We should encourage the developer to use modern DOM APIs (that don't suck) and polyfill as neccessary.
// | |
// Tests if regular expression matches all valid ES6 import syntaxes. | |
// | |
// ES6 Language Specification Reference: | |
// https://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports | |
// | |
const ES6_IMPORT_REGEX = /\bimport\s+(?:.+\s+from\s+)?[\'"]([^"\']+)["\']/g; | |
const VALID_ES6_IMPORT_SYNTAXES = [ |
_.mixin({ | |
sum : function(data){ | |
return _.reduce(data, function(memo, num){ return memo + num; }, 0); | |
}, | |
mean : function(data){ | |
return this.sum(data)/data.length | |
}, | |
median : function(data){ | |
return this.percentile(data,50); | |
}, |
If you are using backbone
(and backbone.marionette
) in a browserify
managed project, you will likely run into issues with underscore
(at least if you manage your dependencies with npm). Each package, that has underscore as a dependency, will require its own version of underscore
(making your bundle file contain multiple versions of underscore
). Back in the days, you could shim backbone
and underscore
like:
browserify({
shim: {
'underscore': {
path: './node_modules/underscore/underscore.js',
exports: '_'
},
<!DOCTYPE html> | |
<html> | |
<head> | |
<meta charset="UTF-8"> | |
<title>Live demo of Nosy Facetype by Rory Harnden</title> | |
<link href='http://fonts.googleapis.com/css?family=Ubuntu+Mono:400,400italic' rel='stylesheet' type='text/css'> | |
<style type="text/css"> | |
@font-face { | |
font-family: "Nosy"; | |
src: url(NOSY_Facetype_by_Rory_Harnden.otf) format("opentype"); |
Computes a new version of a String value in which certain characters have been escaped, so that the regular expression engine will interpret any metacharacters that it may contain as character literals.
When the escape function is called with one argument string, the following steps are taken:
// Difference in map between underscore/lodash and jQuery/Zepto. | |
// | |
// $ allows filtering at the same time; _ does not. | |
// | |
// In your client-side JavaScript apps that use _ and $, this can come as a | |
// surprise since the assumption is that all your map, each, filter, etc. needs | |
// are fulfilled by _, and you'd be right to use them for speed since they | |
// alias native methods where available. However, sometimes $ can be useful, | |
// and this is one such case where that's true. | |
// |