gaubert

########## SETTINGS 

# On startup, lftp executes ~/.lftprc and ~/.lftp/rc. You can place aliases and 'set' commands 
# there. Some people prefer to see full protocol debug, use 'debug' to turn the debug on.

# Certain commands and settings take a time interval parameter. It has the format Nx[Nx...], where N is time amount
# (floating point) and x is time unit: d - days, h - hours, m - minutes, s - seconds. Default unit is second. E.g.
# 5h30m or 5.5h. Also the interval can be 'infinity', 'inf', 'never', 'forever' - it means infinite interval. E.g.
# 'sleep forever' or 'set dns:cache-expire never'.

jehiah

#!/bin/sh

#
# a simple way to parse shell script arguments
# 
# please edit and use to your hearts content
# 


ENVIRONMENT="dev"

halpo

# Makefile for generating R packages.
# 2011 Andrew Redd
#
# Assumes Makefile is in a folder where package contents are in a subfolder pkg.
# Roxygen uses the roxygen2 package, and will run automatically on check and all.

PKG_VERSION=$(shell grep -i ^version pkg/DESCRIPTION | cut -d : -d \  -f 2)
PKG_NAME=$(shell grep -i ^package pkg/DESCRIPTION | cut -d : -d \  -f 2)

R_FILES := $(wildcard pkg/R/*.R)

MohamedAlaa

tmux shortcuts & cheatsheet

start new:

tmux

start new with session name:

tmux new -s myname

piscisaureus

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = git@github.com:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:

dergachev

Vagrant Setup

This tutorial guides you through creating your first Vagrant project.

We start with a generic Ubuntu VM, and use the Chef provisioning tool to:

• install packages for vim, git
• create user accounts, as specified in included JSON config files
• install specified user dotfiles (.bashrc, .vimrc, etc) from a git repository

Afterwards, we'll see how easy it is to package our newly provisioned VM

killercup

/*
 * I add this to html files generated with pandoc.
 */

html {
  font-size: 100%;
  overflow-y: scroll;
  -webkit-text-size-adjust: 100%;
  -ms-text-size-adjust: 100%;
}

sloria

The Best of the Best Practices (BOBP) Guide for Python

A "Best of the Best Practices" (BOBP) guide to developing in Python.

In General

Values

• "Build tools for others that you want to be built for you." - Kenneth Reitz
• "Simplicity is alway better than functionality." - Pieter Hintjens

perrygeo

library(vegan)
library(labdsv)

data(varespec)
data(varechem)

vare.cca <- cca(varespec ~ Baresoil+Humdepth+pH+N+P+K+Ca+Mg+S+Al+Fe, data=varechem)
vare.cca
plot(vare.cca)
summary(vare.cca)

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.