jcxplorer

function uuid() {
  var uuid = "", i, random;
  for (i = 0; i < 32; i++) {
    random = Math.random() * 16 | 0;

    if (i == 8 || i == 12 || i == 16 || i == 20) {
      uuid += "-"
    }
    uuid += (i == 12 ? 4 : (i == 16 ? (random & 3 | 8) : random)).toString(16);
  }

chrisroos

Every so often I have to restore my gpg keys and I'm never sure how best to do it. So, I've spent some time playing around with the various ways to export/import (backup/restore) keys.

Method 1

Backup the public and secret keyrings and trust database

cp ~/.gnupg/pubring.gpg /path/to/backups/
cp ~/.gnupg/secring.gpg /path/to/backups/
cp ~/.gnupg/trustdb.gpg /path/to/backups/

or, instead of backing up trustdb...

JennDudley

This is a list of steps to:

• Setup a new Rails app
• Initialize a local repository using git
• Create a new remote repository using GitHub
• Change README.rdoc
• Deploy to a cloud service - Heroku

Assumptions:

• Ruby is installed (v 1.9.3)
• Rails is installed (v 3.2.3)

hurjas

/**
 * Return a timestamp with the format "m/d/yy h:MM:ss TT"
 * @type {Date}
 */

function timeStamp() {
// Create a date object with the current time
  var now = new Date();

// Create an array with the current month, day and time

jozsefDevs

var above = function(limit){
	return function(value){
		return value > limit;
	};
};

var isAbove10 = above(10);

console.log(isAbove10(5)); // false
console.log(isAbove10(8)); // false

consti

# This hosts file is brought to you by Dan Pollock and can be found at
# http://someonewhocares.org/hosts/
# You are free to copy and distribute this file for non-commercial uses,
# as long the original URL and attribution is included.

#<localhost>
127.0.0.1	localhost
127.0.0.1	localhost.localdomain
255.255.255.255	broadcasthost
::1		localhost

jamesob

Most developers would agree that, all other things being equal, a synchronous program is easier to work with than an asynchronous one. The logic for this is pretty clear: one flow of execution is easier for the human mind to simulate than n concurrent flows.

After doing two small projects in node.js (one of which is here -- ready for the blinding flurry of criticism), there's one question that I can't shake: if asynchronicity is an optimization (that is, a complexity introduced for the sake of performance), why would people, a priori, turn to a framework that imposes it for everything? If asynchronous code is harder to reason about, why would we elect to live in a world where it is the default?

It could be argued pretty well that the browser is a domain that inherently lends itself to an async model, but I'd be very curious to hear a defense of "async-first" thinking for problems that are typically solved on the server-side. When working with node, I've noticed

hmartiro

ZeroMQ vs Redis

This document is research for the selection of a communication platform for robot-net.

Goal

The purpose of this component is to enable rapid, reliable, and elegant communication between the various nodes of the network, including controllers, sensors, and actuators (robot drivers). It will act as the core of robot-net to create a standardized infrastructure for robot control.

Requirements:

ericelliott

A Guide to Functional Programming Lingo for JavaScripters

Functional programming gets a bad wrap about being too hard for mere mortals to comprehend. This is nonsense. The concepts are actually quite simple to grasp.

The jargon is the hardest part. A lot of that vocabulary comes from a specialized field of mathematical study called category theory (with a liberal sprinkling of type theory and abstract algebra). This sounds a lot scarier than it is. You can do this!

All examples using ES6 syntax. wrap (foo) => bar means:

function wrap (foo) {

joepie91

While a lot of Node.js guides recommend using JWT as an alternative to session cookies (sometimes even mistakenly calling it "more secure than cookies"), this is a terrible idea. JWTs are absolutely not a secure way to deal with user authentication/sessions, and this article goes into more detail about that.

Secure user authentication requires the use of session cookies.

Cookies are small key/value pairs that are usually sent by a server, and stored on the client (often a browser). The client then sends this key/value pair back with every request, in a HTTP header. This way, unique clients can be identified between requests, and client-side settings can be stored and used by the server.

Session cookies are cookies containing a unique session ID that is generated by the server. This session ID is used by the server to identify the client whenever it makes a request, and to associate session data with that request.

*S