rianhunter

/*
  This benchmark shows how indirect function calls have nearly
  the same overhead costs as direct function calls.
  
  This is comparing apples to apples, factoring out the savings
  due to inlining optimizations that direct calls usually afford.
    
  From this, it seems that inlining and other generic interprocedual
  optimizations are the main drivers of direct function call optimization,
  not the direct call itself.

djspiewak

Git DMZ Flow

I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.

• Two developers working on independent features must never be blocked by each other
  • No code freeze! Ever! For any reason!
• A developer must be able to base derivative work on another developer's work, without waiting for any third party
• Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
• Developers must be able to work on multiple features simultaneously, or at lea

assaf

#!/usr/bin/env bash
#
# Run nvmish in your current project directory to use the version of io.js/Node
# as specified in package.json.  It will also install that version, if not
# already installed.
#
# If package.json specifies engines.iojs, uses the corresponding version of
# io.js, otherwise, if package.json specifies engines.node, uses the
# corresponding version of Node.js.
#

crittelmeyer

                         _
 _._ _..._ .-',     _.._(`))
'-. `     '  /-._.-'    ',/
   )         \            '.
  / _    _    |             \
 |  a    a    /              |
 \   .-.                     ;  
  '-('' ).-'       ,'       ;
     '-;           |      .'
        \           \    /

jcmvbkbc

# tnx to mamalala
# Changelog
# Changed the variables to include the header file directory
# Added global var for the XTENSA tool root
#
# This make file still needs some work.
#
# Updated for SDK 0.9.2
#
# Output directors to store intermediate compiled files

sr75

http://d.stavrovski.net/blog/post/how-to-install-and-setup-oracle-java-jdk-in-centos-6

# rpm
wget --no-cookies \
--no-check-certificate \
--header "Cookie: oraclelicense=accept-securebackup-cookie" \
"http://download.oracle.com/otn-pub/java/jdk/7u55-b13/jdk-7u55-linux-x64.rpm" \
-O jdk-7-linux-x64.rpm

# ubuntu

eulerfx

There are some clear distinctions between commands and events but there are also some not so clear. I discuss the notion of a command as an interpretation of an event.

Commands are requests to do something, they are named in the imperative tense and capture intent. In CQRS, commands are distinguished from queries because they invoke behaviors therefore causing state changes whereas queries don't. In some frameworks, there is a distinction between commands and events in that one sends commands and publishes events. Commands are sent to a single logical handler whereas events are broadcast to potentially multiple handlers.

Events are characterized as being in the past tense. In addition to naming this imposes the constraint that events can't be rejected - you can't change the past. Furthermore, an event can be regarded as an outcome of a command - a causality relation.

There are perspectives where the distinction blurs. For example, what is the distinction between a command handler and an event handler?

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

branneman

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions

RIAEvangelist

Complete installation process:
 
    sudo apt-get update
    sudo apt-get upgrade
    sudo apt-get install -y  python-software-properties python make build-essential g++ curl libssl-dev apache2-utils git libxml2-dev
    sudo apt-get update
    sudo apt-get upgrade
    cd ~
    mkdir git
    cd ~/git