joepie91

Promises reading list

This is a list of examples and articles, in roughly the order you should follow them, to show and explain how promises work and why you should use them. I'll probably add more things to this list over time.

This list primarily focuses on Bluebird, but the basic functionality should also work in ES6 Promises, and some examples are included on how to replicate Bluebird functionality with ES6 promises. You should still use Bluebird where possible, though - they are faster, less error-prone, and have more utilities.

I'm available for tutoring and code review :)

You may reuse all gists for any purpose under the WTFPL / CC0 (whichever you prefer).

joepie91

Note that this will only be equivalent to Promise.try if your runtime or ES6 Promise shim correctly catches synchronous errors in Promise constructors.

If you are using the latest version of Node, this should be fine.

joepie91

Important warning

You should almost never actually use this. The same applies to fs.stat (when used for checking existence).

Checking whether a file exists before doing something with it, can lead to race conditions in your application. Race conditions are extremely hard to debug and, depending on where they occur, they can lead to data loss or security holes. Using the synchronous versions will not fix this.

Generally, just do what you want to do, and handle the error if it doesn't work. This is much safer.

• If you want to check whether a file exists, before reading it: just try to open the file, and handle the ENOENT error when it doesn't exist.
• If you want to make sure a file doesn't exist, before writing to it: open the file using an exclusive mode, eg. wx or ax, and handle the error when the file already exists.

joepie91

module.exports = function(array) {
	return array.reduce(function(total, subArray) {
		subArray.forEach(function(item) {
			total.push(item);
		});
		
		return total;
	}, []);
}

joepie91

This post has moved here.

joepie91

There's roughly three types of errors:

1. Expected errors - eg. "URL is unreachable" for a link validity checker. You should handle these in your code at the top-most level where it is practical to do so.
2. Unexpected errors - eg. a bug in your code. These should crash your process (yes, really), they should be logged and ideally e-mailed to you, and you should fix them right away. You should never catch them for any purpose other than to log the error, and even then you should make the process crash.
3. User-facing errors - not really in the same category as the above two. While you can represent them with error objects (and it's often practical to do so), they're not really errors in the programming sense - rather, they're user feedback. When represented as error objects, these should only ever be handled at the top-most point of a request - in the case of Express, that would be the error-handling middleware that sends a HTTP status code and a response.

---

Would I still need to use try/ca

tracker1

Directory structure for JavaScript/Node Projects

While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.

Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.

Directories

• lib/ is intended for code that can run as-is
• src/ is intended for code that needs to be manipulated before it can be used

egel

#!/usr/bin/python
# -*- coding: utf-8 -*-

import sublime_plugin
import subprocess
from time import sleep
import sys
 
cl = lambda line: subprocess.Popen(line, shell=True, stdout=subprocess.PIPE).communicate()[0].strip()
log = lambda message: sys.stderr.write("Log: %s\n" % message)

CoolOppo

Source

Vim Commands Cheat Sheet

---

How to Exit

:q[uit]

amitsaha

How does ls work?

I wanted to be really able to explain to a fair amount of detail how does the program :command:`ls` actually work right from the moment you type the command name and hit ENTER. What goes on in user space and and in kernel space? This is my attempt and what I have learned so far on Linux (Fedora 19, 3.x kernel).

How does the shell find the location of 'ls' ?