mojavelinux

Using Arquillian without Maven

This project is the end result of the Getting Started Guide, except that the Eclipse project files have been removed and the Maven plugin for copying the dependencies for each container adapter has been added to the respective profile. We'll be using this project merely as a script to download the dependencies from the Maven repository and stuff them into a directory for the purpose of creating a User Library in the IDE.

Dependency export plugin

We add a plugin execution and configuration for the Maven dependency copy plugin to instruct Maven to copy the dependencies a folder in the build directory.

Here's the plugin definition that's added inside the main build element that gets inherited by all profiles:

banaslee

eXtreme Go Horse (XGH) Process

Source: http://gohorseprocess.wordpress.com


1. I think therefore it's not XGH.
In XGH you don't think, you do the first thing that comes to your mind. There's not a second option as the first one is faster.

2. There are 3 ways of solving a problem: the right way, the wrong way and the XGH way which is exactly like the wrong one but faster.
XGH is faster than any development process you know (see Axiom 14).

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

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

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.

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?

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

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

crittelmeyer

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

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.
#