Gaël Marziou gmarziou

Ansible Logging To Elasticsearch

Turns Ansible log outputs into plain JSON strings and sends them to an Elasticsearch cluster.

Place the script in your playbook's plugins/callbacks/ directory.

Vagrant with Ansible Provisioner on Windows

Long story short, ansible does not work on a Windows control machine, so you basically have to:

either run ansible --connection=local ... in the target vm
set up a separate control vm where ansible is installed via shell provisioner

Below are Vagrantfile examples for both approaches

Within the Target VM

Hibernate documentation - https://docs.jboss.org/hibernate/core/4.2/devguide/en-US/html/ch16.html#d5e4669

Multi-Tenant Data Architecture - http://msdn.microsoft.com/en-us/library/aa479086.aspx

Hibernate: Discriminator based multi tenancy using filter? - http://stackoverflow.com/questions/12894357/hibernate-discriminator-based-multi-tenancy-using-filter

Manage Connection Pooling in multi-tenant web app with Spring, Hibernate and C3P0 - http://stackoverflow.com/questions/21223894/manage-connection-pooling-in-multi-tenant-web-app-with-spring-hibernate-and-c3p

Using Hibernate to Implement Multi-tenant Cloud Architecture - http://www.devx.com/Java/Article/47817

Change the email address for a git commit.

$ git commit --amend --author="Author Name <email@address.com>"

or

$ git commit --amend --reset-author

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.

This is how I debug SystemStackError when there is no stack trace.

My first attempt was:

begin
  a_method_that_causes_infinite_recursion_in_a_not_obvious_way
rescue SystemStackError
  puts caller
end

	//*
	//* See the JS Fiddle: http://jsfiddle.net/sxcjmoj5/3/
	//*
	//*
	// make sure ngSanitize module is installed:
	// https://docs.angularjs.org/api/ngSanitize
	//
	// To convert links from plaintext, you must use the linky filter which is included with ngSanitize
	// https://docs.angularjs.org/api/ngSanitize/filter/linky
	//

	var gulp = require('gulp');
	var gutil = require('gulp-util');
	var sass = require('gulp-ruby-sass') ;
	var prefix = require('gulp-autoprefixer');
	var uglify = require('gulp-uglify');
	var concat = require('gulp-concat');
	var filter = require('gulp-filter');
	var sourcemaps = require('gulp-sourcemaps');
	var minifycss = require('gulp-minify-css');
	var browserSync = require('browser-sync');

	#
	# Vagrantfile for testing
	#
	Vagrant::configure("2") do \|config\|

	# the Chef version to use
	config.omnibus.chef_version = "11.4.4"

	def configure_vbox_provider(config, name, ip, memory = 384)
	config.vm.provider :virtualbox do \|vbox, override\|

	{
	"directory": "bower_components"
	}