Kevin T. Coughlin KevinTCoughlin

CSS Layout Debugger

A tweet-sized debugger for visualizing your CSS layouts. Outlines every DOM element on your page a random (valid) CSS hex color.

One-line version to paste in your DevTools

Use $$ if your browser aliases it:

~ 108 byte version

Jekyll & Liquid Cheatsheet

A list of the most common functionalities in Jekyll (Liquid). You can use Jekyll with GitHub Pages, just make sure you are using the proper version.

Running

Running a local server for testing purposes:

OEmbed Liquid Tag for Jekyll

This is a simple liquid tag that helps to easily embed images, videos or slides from OEmbed enabled providers. It uses Magnus Holm's great oembed gem which connects to the OEmbed endpoint of the link's provider and retrieves the HTML code to embed the content properly (i.e. an in-place YouTube player, Image tag for Flickr, in-place slideshare viewer etc.). By default it supports the following OEmbed providers (but can fallback to Embed.ly or OoEmbed for other providers):

Youtube
Flickr
Viddler
Qik
Revision3
Hulu
Vimeo

Overview

We run multiple server processes in two data centers. Each process listens on two ports, one for HTTP and one for HTTPS. HTTPS is terminated by Apache prior to reaching node.js. HTTP goes directly from the client to node.js (through a master load balancer). We do not use clusters. We slice our physical servers into thin virtual machines running SmartOS, each with about 3GB of memory designed for a single node.js process.

Our node.js servers are hapi.js servers using the composer functionality and plugins architecture. We have three sets of plugins loaded: mobile web front end experience (single page app), legacy API reverse proxy, and monitoring.

We also serve original node.js services off another server zone which runs closed source plugins using hapi.

Analytics

Profiler

React 16.4 will introduce a new Profiler component (initially exported as React.unstable_Profiler) for collecting render timing information in order to measure the "cost" of rendering for both sync and async modes.

Profiler timing metrics are significantly faster than those built around the User Timing API, and as such we plan to provide a production+profiling bundle in the future. (The initial release will only log timing information in DEV mode, although the component will still render its children- without timings- in production mode.)

How is it used?

Profiler can be declared anywhere within a React tree to measure the cost of rendering that portion of the tree. For example, a Navigation component and its descendants:

	(function() {
	var CSSCriticalPath = function(w, d, opts) {
	var opt = opts \|\| {};
	var css = {};
	var pushCSS = function(r) {
	if(!!css[r.selectorText] === false) css[r.selectorText] = {};
	var styles = r.style.cssText.split(/;(?![A-Za-z0-9])/);
	for(var i = 0; i < styles.length; i++) {
	if(!!styles[i] === false) continue;
	var pair = styles[i].split(": ");

	--log_gc (Log heap samples on garbage collection for the hp2ps tool.)
	type: bool default: false
	--expose_gc (expose gc extension)
	type: bool default: false
	--max_new_space_size (max size of the new generation (in kBytes))
	type: int default: 0
	--max_old_space_size (max size of the old generation (in Mbytes))
	type: int default: 0
	--max_executable_size (max size of executable memory (in Mbytes))
	type: int default: 0

	var fetch = require('node-fetch')

	async function getDataFromAPI() {
	let response = await fetch("https://api.github.com/users/up1")
	let data = await response.json()
	console.log(JSON.stringify(data, null, "\t"))
	}

	getDataFromAPI()

	import ts from 'typescript';
	import { migration } from '../../migration';
	import { mod } from 'riceburn';

	const inFooJsxTag = (node: ts.Node): boolean => {
	if (!node) {
	return false;
	}
	if (ts.isJsxSelfClosingElement(node) \|\| ts.isJsxOpeningElement(node)) {
	const tagName = node.tagName;

	$version = (Get-Content package.json) -join "`n" \| ConvertFrom-Json \| Select -ExpandProperty "version"
	Write-Host "Version: '$version']"