This is now an actual repo:
var express = require('express'); | |
var sys = require('sys'); | |
var oauth = require('oauth'); | |
var app = express.createServer(); | |
var _twitterConsumerKey = "YOURTWITTERCONSUMERKEY"; | |
var _twitterConsumerSecret = "YOURTWITTERCONSUMERSECRET"; | |
function consumer() { |
# This goes in _plugins/excerpt.rb | |
module Jekyll | |
class Post | |
alias_method :original_to_liquid, :to_liquid | |
def to_liquid | |
original_to_liquid.deep_merge({ | |
'excerpt' => content.match('<!--more-->') ? content.split('<!--more-->').first : nil | |
}) | |
end | |
end |
/**********************************************/ | |
/* | |
/* IR_Black Skin by Ben Truyman - 2011 | |
/* | |
/* Based on Todd Werth's IR_Black: | |
/* http://blog.toddwerth.com/entries/2 | |
/* | |
/* Inspired by Darcy Clarke's blog post: | |
/* http://darcyclarke.me/design/skin-your-chrome-inspector/ | |
/* |
<!DOCTYPE html> | |
<html> | |
<head> | |
<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js'></script> | |
<script> | |
$(document).ready(function(){ | |
function debug(str){ $("#debug").append("<p>"+str+"</p>"); }; | |
if(typeof WebSocket === 'undefined') { | |
alert("Your browser does not support websockets.") | |
} |
// This is the main application configuration file. It is a Grunt | |
// configuration file, which you can learn more about here: | |
// https://github.com/cowboy/grunt/blob/master/docs/configuring.md | |
// | |
module.exports = function(grunt) { | |
grunt.initConfig({ | |
// The clean task ensures all files are removed from the dist/ directory so | |
// that no files linger from previous builds. |
Authored by Peter Rybin , Chrome DevTools team
In this short guide we'll review some new Chrome DevTools features for "function scope" and "internal properties" by exploring some base JavaScript language concepts.
Let's start with closures – one of the most famous things in JS. A closure is a function, that uses variables from outside. See an example:
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
/* bowling.js - Track a bowling score | |
* devict.org coding challenge. | |
* To see it in action go to: | |
* http://dev.bullercodeworks.com/bowling.html | |
*/ | |
// To keep bowling score, we must first write a DOM manipulation framework. | |
function B(els, attrs) { | |
// Turn 'this' into an array of passed in elements. | |
function B(els) { |