asciant

# lib/tasks/db.rake
namespace :db do

  desc "Dumps the database to db/APP_NAME.dump"
  task :dump => :environment do
    cmd = nil
    epoch = Time.now.to_i
    with_config do |app, host, db, user|
      cmd = "pg_dump --host #{host} --username #{user} --verbose --clean --no-owner --no-acl --format=c #{db} > #{Rails.root}/db/#{app}-#{epoch}.dump"
    end

asciant

http://www.austinstory.com/integrating-wicked-pdf-paperclip-and-mercury-rails-for-an-editable-web-document-that-can-be-exported-to-pdf/
http://botreeconsulting.com/wicked_pdf-generate-pdf-from-haml-template/
https://gist.github.com/micahroberson/5988843
http://snikt.net/blog/2012/04/26/wicked-pdf/
http://www.sitepoint.com/pdf-generation-rails/

asciant

#!/bin/bash

readonly lm75=0x48 # Slave address with A0, A1, and A2 set to 0v (ground).

while [ $# -gt 0 ]
do
   if [ "$1" == "-debug" ]
   then
      debug=true
   fi

asciant

There are many Git workflows out there, I heavily suggest also reading the atlassian.com [Git Workflow][article] article as there is more detail then presented here.

The two prevailing workflows are [Gitflow][gitflow] and [feature branches][feature]. IMHO, being more of a subscriber to continuous integration, I feel that the feature branch workflow is better suited.

When using Bash in the command line, it leaves a bit to be desired when it comes to awareness of state. I would suggest following these instructions on [setting up GIT Bash autocompletion][git-auto].

Basic branching

When working with a centralized workflow the concepts are simple, master represented the official history and is always deployable. With each now scope of work, aka feature, the developer is to create a new branch. For clarity, make sure to use descriptive names like transaction-fail-message or github-oauth for your branches.