rargulati

iex(3)> deck = for rank <- [ "2", "3", "4", "5", "6", "7", "8", "9", "10", "J", "Q", "K", "A" ], suit <- [ "♣", "♦", "♥", "♠" ], do: {rank, suit}
[
  {"2", "♣"},
  {"2", "♦"},
  {"2", "♥"},
  {"2", "♠"},
  {"3", "♣"},
  {"3", "♦"},
  {"3", "♥"},
  {"3", "♠"},

rargulati

* Development process

** Feature Tracking

The first step of development should be to have a task card. Typically
the team leads will create the cards, but this won't always be true---sometimes
you'll find a bug or take a bug from a Flowdock conversation. At that point you
can ask your team lead to handle the card, or you can do it yourself. If you
create a card that you're intending on working on immediately, make sure to put

rargulati

### Keybase proof

I hereby claim:

  * I am rargulati on github.
  * I am raj (https://keybase.io/raj) on keybase.
  * I have a public key whose fingerprint is D6AC 85E8 A1F6 1983 36BF  6E7A 9577 BE90 64B9 C7CE

To claim this, I am signing this object:

rargulati

#!/bin/sh

# Prevent any type of push to master without an explicit confirmation.
# On file creation (save and exit), set `chmod +x pre-push`, or this won't execute.
# TODO: create branch when user selects `no`.

protected_branch='master'
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')

if [ $protected_branch = $current_branch ]

rargulati

### Keybase proof

I hereby claim:

  * I am rargulati on github.
  * I am raj (https://keybase.io/raj) on keybase.
  * I have a public key whose fingerprint is 904F 9ECD D479 900D 86A2  2CBB FB2A 43E0 E108 4F2C

To claim this, I am signing this object:

rargulati

-- Now you can see how it works in 2012!
CREATE TABLE employement_se2212 
	(
      First varchar(10), 
      Last varchar (15), 
      title varchar (18), 
      age int(2), 
      salary int(7)
    );