oofnikj

### This file is intended to be sourced from ~/.bashrc ###

# quickly switch between AWS profiles with auto-completion
# uses https://github.com/Nike-Inc/gimme-aws-creds to obtain credentials
# if using static credentials, just comment out lines 13-15

awsp() {
    if [[ -n $1 ]] ; then
        # validate input
        grep -q -w "\[profile ${1}\]" ~/.aws/config || { echo "No such profile $1"; return 1; }

lencioni

/**
 * We often run into a problem with functions that select DOM nodes like
 * `cy.get`, where in between the `cy.get` call and the next item in the chain,
 * the DOM element that `cy.get` found ends up being removed from the DOM. This
 * can affect code as simple as:
 *
 *   cy.get('button').click();
 *
 * When it fails sporadically, it uses the following error message:
 *

brianlittmann

class AwsUploader
	CLIENT = Aws::S3::Client.new
	BUCKET = Rails.configuration.x.aws["output_bucket"]

	def self.upload(file, key)
		CLIENT.put_object({
			bucket: BUCKET,
			key: key,
			body: file,
			content_length: file.size

janickr

with recursive generation1(x,y) as (   --the initial board setup
  select 2, 3
  union
  select 3, 3
  union
  select 4, 3
), 
game(n, x, y) as (
  select 1, x, y from generation1 -- generation 1 is initial board setup
  union all

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.

lucasfais

Sublime Text 2 – Useful Shortcuts (Mac OS X)

General

⌘T	go to file
⌘⌃P	go to project
⌘R	go to methods
⌃G	go to line
⌘KB	toggle side bar
⌘⇧P	command prompt

zhengjia

=Navigating=
    visit('/projects')
    visit(post_comments_path(post))

=Clicking links and buttons=
    click_link('id-of-link')
    click_link('Link Text')
    click_button('Save')
    click('Link Text') # Click either a link or a button
    click('Button Value')