LeaVerou

(function(){
var log = console.log;

console.log = function(str) {
	var css = 'background: linear-gradient(to right, red, yellow, lime, aqua, blue, fuchsia, red); color: white; font-weight: bold;';
	var args = Array.prototype.slice.call(arguments);
	args[0] = '%c' + args[0];
	args.splice(1,0,css);
	return log.apply(console, args);
}

lleo

#!/usr/bin/env node

/*
 * Inspired by: http://stackoverflow.com/questions/4360060/video-streaming-with-html-5-via-node-js
 * Modified from https://gist.github.com/paolorossi/1993068
 */

var http = require('http')
  , fs = require('fs')
  , util = require('util')

mollerse

var gulp = require('gulp'),
  sass = require('gulp-sass'),
  browserify = require('gulp-browserify'),
  concat = require('gulp-concat'),
  embedlr = require('gulp-embedlr'),
  refresh = require('gulp-livereload'),
  lrserver = require('tiny-lr')(),
  express = require('express'),
  livereload = require('connect-livereload')
  livereloadport = 35729,

julian-boolean

$(window).on('resize', function(){
  graph.configure({
    width: window.innerWidth - 20,
    height: window.innerHeight - 20
  });
  graph.render();
});

nzakas

Versioning in a Repository

Lately I've been doing a lot of thinking around versioning in repositories. For all the convenience and ubiquity of package.json, it does sometimes misrepresent the code that is contained within a repository. For example, suppose I start out my project at v0.1.0 and that's what's in my package.json file in my master branch. Then someone submits a pull request that I merge in - the version number hasn't changed even though the repository now no longer represents v0.1.0. The repository is actually now in an intermediate state, in between v0.1.0 and the next official release.

To deal with that, I started changing the package.json version only long enough to push a new release, and then I would change it to a dev version representing the next scheduled release (such as v0.2.0-dev). That solved the problem of misrepresenting the version number of the repository (provided people realize "dev" means "in flux day to day"). However, it introduced a yucky workflow that I really hate

gvn

Eliminating Code Smell With Grunt

by Gavin Lazar Suntop @gvn

Intro

I love clean code. There, I said it. I pride myself on passing strict linting standards and keeping my code easy to read. It's not just a personal proclivity, but a choice I hope benefits other developers.

My general experience with teams has been that code style is something people care about and have strong personal preferences. Typically, at some point people get tired of dealing with inconsistency and a standardization meeting is called. This is, of course, an important discussion to have. The problem that tends to occur is either lack of documentation or lack of enforcement of the agreed upon style. Additionally, new team members or contributors may not have access to a clear set of rules.

LinusU

Usage

Install cordova into node_modules

npm install cordova

Add icons_and_splash.js

rxaviers

People

:bowtie:	😄 :smile:	😆 :laughing:
😊 :blush:	😃 :smiley:	☺️ :relaxed:
😏 :smirk:	😍 :heart_eyes:	😘 :kissing_heart:
😚 :kissing_closed_eyes:	😳 :flushed:	😌 :relieved:
😆 :satisfied:	😁 :grin:	😉 :wink:
😜 :stuck_out_tongue_winking_eye:	😝 :stuck_out_tongue_closed_eyes:	😀 :grinning:
😗 :kissing:	😙 :kissing_smiling_eyes:	😛 :stuck_out_tongue:

guptag

//To run Q.js examples:

    // 1. Open a new browser tab in Chrome and turn on developer toolbar (or open any http site).
    // 2. Copy/Paste this gist in the console and hit enter to run the snippets.
    
// Based on the inspiration from samples @ https://github.com/kriskowal/q  

////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////

wbotelhos

#!/bin/bash

sudo apt-get remove phantomjs

sudo unlink /usr/local/bin/phantomjs
sudo unlink /usr/local/share/phantomjs
sudo unlink /usr/bin/phantomjs

cd /usr/local/share