ryanflorence

var Toggler = require('./toggler');
var React = require('react/addons');
var assert = chai.assert;
var Simulate = React.addons.TestUtils.Simulate

describe('Toggler', function(){

  var toggler, el;

  beforeEach(function() {

calebd

extension Array {
    
    func first() -> Element? {
        if isEmpty {
            return nil
        }
        return self[0]
    }
    
    func last() -> Element? {

silviopaganini

acéfalo
aidético
aids
amadoras
amateur
anal
ânus
arde
ardencia
arder

joostrijneveld

# Heavily depends on:
# libqrencode (fukuchi.org/works/qrencode/)
# paperkey (jabberwocky.com/software/paperkey/)
# zbar (zbar.sourceforge.net)

# Producing the QR codes:
# Split over 4 codes to ensure the data per image is not too large.
gpg --export-secret-key KEYIDGOESHERE | paperkey --output-type raw | base64 > temp
split temp -n 4 IMG
for f in IMG*; do cat $f | qrencode -o $f.png; done

getify

Here's a quick proposal for something that I think would help npm packages (used as dependencies) be leaner, reducing burden of disk-space and bandwidth, especially for CI type setups which re-download tons of packages over and over again. My idea is inspired from Help People Consume Your npm Packages.

TL;DR

Add .npmignore-minimal file with things in your package that are not-strictly-necessary (readmes, tests, etc) to filter out of minimal-package installs. npm install still installs full package. npm min-install (or npm install --production) installs only the filtered down package contents (aka "minimal-package").

Details

This proposal pairs/parallels devDependencies, but extends this "optional" idea to your whole package structure.

chee

// bizarguments is a v8 anomaly

function abc() {
  return def();
}
function def() {
  return abc.arguments[0] * 2;
}

abc(50); // >> 100

olivierlacan

• http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
• http://blog.8thlight.com/uncle-bob/2014/04/25/MonogamousTDD.html
• http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
• http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html
• http://david.heinemeierhansson.com/2014/slow-database-test-fallacy.html
• http://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html
• https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric
• http://articles.coreyhaines.com/posts/active-record-spec-helper/
• http://martinfowler.com/bliki/UnitTest.html

rwaldron

/*!
 * jQuery JavaScript Library v2.1.1pre
 * http://jquery.com/
 *
 * Includes Sizzle.js
 * http://sizzlejs.com/
 *
 * Copyright 2005, 2014 jQuery Foundation, Inc. and other contributors
 * Released under the MIT license
 * http://jquery.org/license

XVilka

THIS GIST WAS MOVED TO TERMSTANDARD/COLORS REPOSITORY.

PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!

mikeal

Children are created, raised, cared for and we hope that they will live a long and proud life only to end long after their creator's has ended. They are their creator's legacy.

Your code is not your child, it is an animal raised for slaughter. Your code will die. It will die before your death. Your code's entire purpose is to die. Your code enables some new function and if successful that new function will grow, it will mature, it will eventually outlive the usefullness you've provided. When successful your code creates value that outlives it and the faster the better. When unsuccessful a mercy killing is most appropriate.

Believing that our code is our children makes us territorial, protective. Nobody is allowed to kill it, only improve it. The idea that our code can be perfect, that it can change to handle so many new concerns leads to the birth of frameworks and plugin systems. These systems brutalize creativity by forcing new value to conform to the standards of our aging children.