Skip to content

Instantly share code, notes, and snippets.

View ForbesLindesay's full-sized avatar

Forbes Lindesay ForbesLindesay

1.6k followers · 8 following
View GitHub Profile
@ForbesLindesay
ForbesLindesay / test.html
Created September 12, 2012 07:14
Component test starter template
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="mocha.css" />
<link href="../build/build.css" rel="stylesheet"/>
</head>
<body>
<div id="mocha"></div>
<script src="expect.js"></script>
<script src="mocha.js"></script>
@ForbesLindesay
ForbesLindesay / Data Tables.md
Last active October 10, 2015 16:28
Data Tables
@ForbesLindesay
ForbesLindesay / gist:3758491
Created September 20, 2012 21:33
Edit icon
http://www.iconarchive.com/show/oxygen-icons-by-oxygen-icons.org/Actions-document-edit-icon.html
@ForbesLindesay
ForbesLindesay / Program.cs
Created November 23, 2012 03:05
NAct doesn't forward exceptions properly...
using NAct;
using System;
using System.Threading.Tasks;
namespace NActFailureDemo
{
class Program
{
static void Main(string[] args)
{
@ForbesLindesay
ForbesLindesay / formatte.md
Created February 8, 2013 04:09
Someone genuinely sent this to the ES Discuss mailing list, how the hell am I supposed to automate the process of making this kind of thing readible

On 11/30/2011 12:01 PM, Brendan Eich wrote:

On Nov 29, 2011, at 1:19 PM, Nicholas C. Zakas wrote:

The reason I started down this path is because the API, as currently designed, doesn't fit in with the rest of the JavaScript core language. Just to summarize some of my earlier points:

  1. No part of core JavaScript uses namespaces today. Having a top-level Globalization object that [does] nothing other than provide a hook onto which new constructors are placed is a first and doesn't seem very useful. At the very least I'd consider killing the Globalization object altogether and just let the constructors exist in the global scope. Injecting new names into the global scope is risky, since all the good names are already taking by user-defined globals.

The plan we discussed a few weeks ago was to use a built-in module, which could be imported from or declared freely in new opt-in code. Unversioned JS would have to use something like the >

@ForbesLindesay
ForbesLindesay / Test Everything Spec.md
Last active December 14, 2015 09:29
Test-Everything Spec

Test-Everything Spec

This spec aims to define a format for recording the results of tests. It aims to be completely minimal, and can be extended as needed. Reporters should only assume the presense of these features, but may be progressively enhanced when more information is available.

Static Format

Test results consist of a JSON document containing a single "Section"

Section

@ForbesLindesay
ForbesLindesay / octocats.js
Created March 10, 2013 20:46
Download all the octocats using just hyperquest and through
var join = require('path').join;
var fs = require('fs');
var request = require('hyperquest');
var through = require('through');
fs.mkdirSync(join(__dirname, 'octocats'));
request('http://octodex.github.com/')
.pipe(parseURLs())
.pipe(download())
@ForbesLindesay
ForbesLindesay / umd.md
Created March 26, 2013 07:51

Standalone Browserify Builds

Browserify now supports standalone builds thanks to integration with my umd (universal module definition) library. Universal module definition is a simple tool to help you (as a library author) deal with the fact that all your users are probably stuck working on legacy systems with legacy build managers (such as AMD).

The goal on your part is to write your code once, in the easiest module system, and have all your users get a copy that's "optimised" for them. You want to have one file that will work in all the build systems out there. By using the umd library or the standalone option in browserify, you get just this.

Creating a Package

Consider an example package made of two files:

@ForbesLindesay
ForbesLindesay / Transactional Email.md
Created March 28, 2013 04:42
@ForbesLindesay
ForbesLindesay / Inline This.md
Last active December 15, 2015 15:18

You're challenge, should you choose to accept it, is to inline the following @import statements in CSS. What should the result be. "SyntaxError" is a perfectly acceptable answer. If anyone knows what the current spec does, I'd be interested to know, but I'm equally keen to find out what people think the spec should do.

Please place the results of inlining @import statements in each file (except fixture.css) in the comments. Your help is appreciated, and if I meet you in a bar some time, I owe you a pint.