Tom Granot TomGranot

Common Options

-#, --progress-bar Make curl display a simple progress bar instead of the more informational standard meter.

-b, --cookie <name=data> Supply cookie with request. If no =, then specifies the cookie file to use (see -c).

-c, --cookie-jar <file name> File to save response cookies to.

To remove a submodule you need to:

Delete the relevant section from the .gitmodules file.
Stage the .gitmodules changes git add .gitmodules
Delete the relevant section from .git/config.
Run git rm --cached path_to_submodule (no trailing slash).
Run rm -rf .git/modules/path_to_submodule (no trailing slash).
Commit git commit -m "Removed submodule "
Delete the now untracked submodule files rm -rf path_to_submodule

PSQL

Magic words:

psql -U postgres

Some interesting flags (to see all, use -h or --help depending on your psql version):

-E: will describe the underlaying queries of the \ commands (cool for learning!)
-l: psql will list all databases and then exit (useful if the user you connect with doesn't has a default database, like at AWS RDS)

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.

	#!/usr/bin/env ruby

	# if limiting to one chapter, ./audiobook.rb 05
	LIMIT = (ARGV[0] =~ /\A[0-9][0-9]\Z/) ? ARGV[0] : false

	BASE = Dir.pwd + '/'
	NUMS = BASE + 'ChapterNums/'
	DRUM = BASE + 'DrumFills/'
	GUIT = BASE + 'GuitarChords/'
	URLS = BASE + 'URLs/'

	(originally written in 2009 and posted to livejournal! https://jdimpson.livejournal.com/6812.html

	The last article teaches how to use socat by comparing it first to cat then to netcat. It skimped on socat's UDP-related features, because netcat only implements a subset of them. This article picks up where the last one left off, with respect to UDP. After this article will be one more that discusses advanced socat features.

	It turns out there are a lot of subleties when dealing with UDP, even before multicast is mixed in. We'll abandon the comparisons to netcat, as we've exceeded what netcat can do. But first a quick reminder of one way socat does UDP.

	socat as a UDP server on port 11111.

	socat STDIO UDP-LISTEN:11111

	mkdir ~/vim
	cd ~/vim

	# Staically linked vim version compiled from https://github.com/ericpruitt/static-vim
	# Compiled on Jul 20 2017
	curl 'https://s3.amazonaws.com/bengoa/vim-static.tar.gz' \| tar -xz

	export VIMRUNTIME="$HOME/vim/runtime"
	export PATH="$HOME/vim:$PATH"
	cd -

	# ----------------------------------------------------------------------------------
	# r u s t f m t - C O N F I G
	# ==================================================================================
	#
	# Version: 0.7.1
	# Author : Robbepop <robbepop@web.de>
	#
	# A predefined .rustfmt.toml file with all configuration options and their
	# associated description, possible values and default values for use in other
	# projects.

	#!/bin/bash

	#
	# Efstathios Xagoraris <sxagoraris@gmail.com>
	# Validate YAML files using ruby
	#


	if [ $# -eq 0 ]
	then