peterc

SELECT
  schema_name, rel_name, table_size,
  pg_size_pretty(table_size) AS size
FROM (
  SELECT
    nspname AS schema_name,
    relname AS rel_name,
    pg_table_size(pg_class.oid) AS table_size
  FROM pg_class, pg_namespace
  WHERE pg_class.relnamespace = pg_namespace.oid

mkllnk

#!/bin/sh

set -e

APP_PATH="$HOME/apps/openfoodnetwork"
CURRENT_PATH="/home/openfoodnetwork/apps/openfoodnetwork/current"
SHARED_PATH="/home/openfoodnetwork/apps/openfoodnetwork/shared"
CONFIG_PATH="/home/openfoodnetwork/apps/openfoodnetwork/shared/config"
BUNDLE="$HOME/.rbenv/shims/bundle"
GEM_PATH="/home/openfoodnetwork/.gem"

r00k

#!/bin/sh

# Set up Rails app. Run this script immediately after cloning the codebase.

# Exit if any subcommand fails
set -e

# Copy over configs
if ! [ -f .env ]; then
  cp .sample.env .env

peterhurford

Using py.test is great and the support for test fixtures is pretty awesome. However, in order to share your fixtures across your entire module, py.test suggests you define all your fixtures within one single conftest.py file. This is impractical if you have a large quantity of fixtures -- for better organization and readibility, you would much rather define your fixtures across multiple, well-named files. But how do you do that? ...No one on the internet seemed to know.

Turns out, however, you can define fixtures in individual files like this:

tests/fixtures/add.py

import pytest

@pytest.fixture

franciscoj

Ruby: ivar vs readers

Spoiler alert: Readers win.

1. You don't rely on the instance state.
2. You've better protection againt typos. @ivar might not exist and nothing will fail ivar will complain.
3. They're easier to mock in specs in case you need to.
4. They properly wrap the state so that refactors are easier
5. they can be aliased
6. they can be alias_method_chained

PurpleBooth

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

caarlos0

SELECT bl.pid AS blocked_pid,
  a.usename AS blocked_user,
  ka.query AS blocking_statement,
  now() - ka.query_start AS blocking_duration,
  kl.pid AS blocking_pid,
  ka.usename AS blocking_user,
  a.query AS blocked_statement,
  now() - a.query_start AS blocked_duration
FROM  pg_catalog.pg_locks bl
  JOIN pg_catalog.pg_stat_activity a ON a.pid = bl.pid

mikestone14

Pointing a GoDaddy domain to a Heroku app

https://devcenter.heroku.com/articles/custom-domains http://thenomadicfreelancer.blogspot.com/2012/08/pointing-godaddy-domain-to-your-heroku.html

1) Custom Subdomains

For each custom subdomain use domains:add in the Terminal.

wandernauta

#!/usr/bin/env bash

#
# This is sp, the command-line Spotify controller. It talks to a running
# instance of the Spotify Linux client over dbus, providing an interface not
# unlike mpc.
#
# Put differently, it allows you to control Spotify without leaving the comfort
# of your command line, and without a custom client or Premium subscription.
#

tomas-stefano

Capybara Actions

# Anchor
click_link 'Save'

# Button
click_button 'awesome'

# Both above