made with esnextbin
<!doctype html> | |
<html ng-app="Demo"> | |
<head> | |
<meta charset="utf-8" /> | |
<title> | |
Preloading Images In AngularJS With Promises | |
</title> | |
</head> | |
<body ng-controller="AppController"> |
if( window.devicePixelRatio !== 1 ){ | |
var c = canvas.getElement(); // canvas = fabric.Canvas | |
var w = c.width, h = c.height; | |
// Scale the canvas up by two for retina | |
// just like for an image | |
c.setAttribute('width', w*window.devicePixelRatio); | |
c.setAttribute('height', h*window.devicePixelRatio); |
forceRerenderOnWebkit: -> | |
@el.parentNode.style.cssText += ';-webkit-transform:rotateZ(0deg)' | |
@el.parentNode.offsetHeight | |
@el.parentNode.style.cssText += ';-webkit-transform:none' |
import { injectable } from 'inversify'; | |
import { Logger } from 'log4js'; | |
import { Socket } from 'net'; | |
import Timer = NodeJS.Timer; | |
export interface KeepaliveOptions { | |
/** | |
* The maximum time in milliseconds an unused socket will be kept alive before it will be closed | |
* | |
* This should be set to a smaller value than the server's keepalive timeout to avoid a race condition |
#!/usr/bin/env node | |
var stdin = process.openStdin(); | |
var stdout = process.stdout; | |
var input = ''; | |
stdin.setEncoding('utf8'); | |
stdin.on('data', function(data) { | |
if (data) { | |
input += data; |
This is a draft list of what we're thinking about measuring in Etsy's native apps.
Currently we're looking at how to measure these things with Espresso and Kif (or if each metric is even possible to measure in an automated way). We'd like to build internal dashboards and alerts around regressions in these metrics using automated tests. In the future, we'll want to measure most of these things with RUM too.
- App launch time - how long does it take between tapping the icon and being able to interact with the app?
- Time to complete critical flows - using automated testing, how long does it take a user to finish the checkout flow, etc.?
- Battery usage, including radio usage and GPS usage
- Peak memory allocation
This example expects to have d3.min.js and d3.layout.min.js in the same directory as pie.js and pie_serv.js. | |
Run with node pie_serv.js |
function worker() { | |
setInterval(function() { | |
postMessage({foo: "bar"}); | |
}, 1000); | |
} | |
var code = worker.toString(); | |
code = code.substring(code.indexOf("{")+1, code.lastIndexOf("}")); | |
var blob = new Blob([code], {type: "application/javascript"}); |
GraphQL has exploded in popularity since its open-source announcement in 2015. For developers who had spent a lot of time managing data transformations from their back-end infrastructure to match front-end product needs, GraphQL felt like a tremendous step forwards. Gone were the days of hand-writing BFFs to manage problems of over-fetching.
A lot of value proposition arguments around GraphQL have been about over/under fetching, getting the data shape you ask for, etc. But I think GraphQL provides us more than that—it gives us an opportunity to raise the level of abstraction of our domain, and by doing so allow us to write more robust applications that accurately model the problems we face in the real world (changing requirements, one-off issues).
An underappreciated feature of GraphQL is its type system, and in particular features like [union types](https: