Skip to content

Instantly share code, notes, and snippets.

The Importance of UTF8

Text files may seem like the most fanastic, ubiqutous and simple format. Almost all programmes seem to be able to cope with reading and writing them interchangeably, which is great. They aren't quite a simple as you might think. Back in the dark ages of computing, when space was at a premium and even text files seemed large, most people in compuging spoke English, so they thought that a single Byte would be enough to store all the letters. This lead to a nice, efficient, simple encoding called ASCII.

What happened to just ASCII

It turned out that one byte doesn't store enough characters (it only gives you 256 and that includes lowercase and uppercase letters and all punctuation). To fill the gap, hundreds of different formats sprang up. They were all slightly different. Many of these will work fine even if you interpret them as ASCII but some won't.

This was no good, you had to try and guess the format of any text file before you could read or understand it. A sollution

var request = require('request');
module.exports = dropbox;
function dropbox(consumerKey, consumerSecret, accessToken, accessTokenSecret) {
var errors = {
'304': 'The folder contents have not changed'
, '400': 'The extension is on Dropbox\'s ignore list.'
, '403': 'An invalid copy operation was attempted (e.g. there is already a file at the given destination, or copying a shared folder into a shared folder).'
, '404': 'The requested file or revision was not found.'
, '406': 'There are too many file entries to return.'
function getPage(page, numberPerPage) {
numberPerPage = numberPerPage || 20;
return db.messages.aggregate(
{ '$sort': { date: 1 } },
{
'$group': {
_id: "$subjectID",
subject: { '$first': '$subject'},
messages: {'$sum': 1},
first: { '$first': '$from' },
@ForbesLindesay
ForbesLindesay / microdata.js
Last active April 18, 2017 06:54
Parse schema.org style microdata
var request = require('request');
//Decode HTML entities:
var decode = require('ent').decode;
//todo: fix this
var ISO8601 = undefined;
var htmlparser = require('htmlparser');
function parse(domstr) {
@ForbesLindesay
ForbesLindesay / Real World Specification.md
Last active January 4, 2022 22:41
Functional Programming from the perspective of a JavaScript Programmer.

Real World Specification

(aka "Algebraic JavaScript Specification")

This project specifies the behavior of a number of methods that may optionally be added to any object. The motivation behind this is to encourage greater code reuse. You can create functions that just rely on objects having implementations of the methods below, and in doing so you can make them work with a wide variety of different, but related data structures.

Definitions

For the purposes of this, spec, an "entity" is an object that has an [[equivalent]] operation (see bellow) and may implement some or all of the other methods.

Arguments Against Promises for Promises

The argument for avoiding promises for promises is fairly simple. A promise is a representation of a value that will exit in the future. If that value is still a promise, you haven't really got to the final value yet. Conceptually having the promise doesn't really provide anything other than a means to obtain the final value, as such it's of no additional use to be able to get the intermediate nested promises: You might as well just jump straight to the value.

The "JQPFAQPFAWJPFADFFAN" Problem

This problem is explained in more detail by @erights here. The currently proposed [[Resolve]] algorithm only dictates this recursive flattening for unrecognised thenables, not for promises. THe advantage of this behavior is that a user can pick up a Promises/A+ library and return a deeply nested mess of foreign promises objects (all of which were broken enough not to do any unwrappi

Arguments in favor of Promises for Promises

The argument in favor of Promises for Promises is structured as follows:

  1. Examples
  2. Lazy Promises
  3. Remote Promises
  4. Partial Results
  5. Error Handling
  6. Testing

Compilers

This spec aims to define a set of common interfaces that all compilers/transformers/template languages should aim to follow.

Methods

Each method can have either a synchronous or asynchronous version. Implementations should seek to offer the synchronous version where possible and only offer the asynchronous version where it is necessary. The asynchronous versions always take a callback of the form callback(error, result). Asynchronous APIs should take care never to throw synchronously and to never call the callback multiple times.

Each method takes an options object. It should treat the following properties specially if appropriate:

@ForbesLindesay
ForbesLindesay / duplexer.js
Last active December 16, 2015 14:29
Duplexer.js for node v0.10
var vNext = !!require('stream').Duplex;
var DuplexBase = require(vNext ? 'stream' : 'readable-stream').Duplex;
var Readable = require(vNext ? 'stream' : 'readable-stream').Readable;
function Duplex(writer, reader, options) {
DuplexBase.call(this, options);
var _reader = new Readable();
_reader.wrap(reader);
reader = _reader;
var self = this;
@ForbesLindesay
ForbesLindesay / reaperquest.js
Created April 24, 2013 03:17
First stab at a plugable request library with promises and v0.10 streams
var url = require('url');
var http = require('http');
var https = require('https');
var Promise = require('promise');
var sprom = require('sprom');
var Duplex = require('./lib/duplex');
var wrap = require('./lib/wrap');
var through = require('./lib/through');