graygilmore

/*
  The Ultimate Hover Color Function
  @author Gray Gilmore - http://code.graygilmore.com

  The goal of this Sass function is provide a hover color that works
  with any color on any background. No longer do we need to bundle
  hover color options with our themes, let Sassy McSasserson take care
  of that for you.

  The hover color, seen in this demo as "After" text, must be visible in

gibatronic

function check_for_virtual_env {
  [ -d .git ] || git rev-parse --git-dir &> /dev/null

  if [ $? == 0 ]; then
    local ENV_NAME=`basename \`pwd\``

    if [ "${VIRTUAL_ENV##*/}" != $ENV_NAME ] && [ -e $WORKON_HOME/$ENV_NAME/bin/activate ]; then
      workon $ENV_NAME && export CD_VIRTUAL_ENV=$ENV_NAME
    fi
  elif [ $CD_VIRTUAL_ENV ]; then

chmouel

# Author: Chmouel Bodujnah <chmouel@chmouel.com>
#
# Pan a zsh tool to complete virtualenv tox targets and tests launched via
# testtools
#
# Demo: http://i.imgur.com/kJsJTjj.gif
#
# When you use zsh just source the file directly and when you are inside a
# project which has been pre-built with tox targets you can start do:
#   pan <TAB>

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.

naftaliharris

#!/bin/bash

# An enhancement to the "python" executable that automatically launches you into the python debugger on error.
# 
# Use it like you would the "python" executable, for example:
# $ trypy somefile.py
# or
# $ trypy somefile.py arg1 arg2
#
# EXAMPLE: 

jprjr

FROM tianon/centos-null:5.9

RUN rpm -i http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
RUN yum -y update
RUN yum -y install gcc git curl make zlib-devel bzip2 bzip2-devel readline-devel sqlite sqlite-devel openssl openssl-devel


RUN useradd -m python_user
RUN ln -s /proc/self/fd /dev/fd

renoirb

Description

Have you ever wanted to have a Vagrant workspace with more than one Virtual Machine, and managed by Salt Stack? I did, but the documentation is not all there yet.

I managed to make it work with the following, hope it will be useful.

To use

See the Complete salty-vagrant setup, but use the current Vagrantfile to have two machines.

JeffPaine

Moved

Now located at https://github.com/JeffPaine/beautiful_idiomatic_python.

Why it was moved

Github gists don't support Pull Requests or any notifications, which made it impossible for me to maintain this (surprisingly popular) gist with fixes, respond to comments and so on. In the interest of maintaining the quality of this resource for others, I've moved it to a proper repo. Cheers!

stevearc

#!/usr/bin/env python
"""
This is a cute little script for easily running shell commands across many
servers using salt.


Copyright (c) 2013 Steven Arcangeli

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in

alecthomas

import itertools
import functools
import fnmatch
import os
from StringIO import StringIO

import yaml
from yaml.parser import ParserError
import voluptuous as V