thefonso

source 'https://rubygems.org'

gem 'rails', '3.2.13'

group :development do
  gem 'sqlite3'
end

group :production do
  gem 'pg'

thefonso

#Introduction

An introduction to curl using GitHub's API

#The Basics

Makes a basic GET request to the specifed URI

curl https://api.github.com/users/thefonso

thefonso

Demo

thefonso

####Angular Testing Part-1

####Why do we test code...in an automated fashion.

Mark Ethan Trostler ( Google )..from Testable Javascript :

You have to write unit tests, so quit messing around and write some.

From the angular docs ( Many people at Google ):

JavaScript is a dynamically typed language which comes with great power of expression, but it also comes with almost no help from the compiler. For this reason we feel very strongly that any code written in JavaScript needs to come with a strong set of tests. We have built many features into Angular which makes testing your Angular applications easy. So there is no excuse for not testing.

thefonso

Calling Helper Methods
Every helper method has its own set of parameters, and often it’s not clear from the documentation which parameters it will accept. How do you interpret the following?

label(object_name, method, text = nil, options = {})
The first few parameters at least take simple values. The object_name parameter will take a symbol pointing to an ActiveRecord object, like :person. The method parameter, though—what method does it take? It actually wants a symbol, say :name, for an attribute from the object specified in the previous parameter. Why would the Rails documentation call that a method? Because it’ll use a method to access the attribute.

The next parameter, text, is shown with its default value, nil. Any time you see a parameter listed as equal to something, that value is the default.

And options? What is options? It looks like lots of methods must have the same options, because they all have the same entry in the documentation, but it’s really just a convention. The actual options, na

thefonso

<section id="todoapp">
  <header id="header">
    <h1>todos</h1>
    <input type="text" id="new-todo" placeholder="What needs to be done?" />
  </header>

  <section id="main">
    <ul id="todo-list">
      <li class="completed">
        <input type="checkbox" class="toggle">

thefonso

import Ember from 'ember';

var Router = Ember.Router.extend({
  location: TodoEmberENV.locationType
});

Router.map(function() {
  this.resource('todos', { path: '/' });
});

thefonso

{{outlet}}

<footer id="info">
  <p>Double-click to edit a todo</p>
</footer>

thefonso

<section id="todoapp">
  <header id="header">
    <h1>todos</h1>
    <input type="text" id="new-todo" placeholder="What needs to be done?" />
  </header>

  <section id="main">
    <ul id="todo-list">
      <li class="completed">
        <input type="checkbox" class="toggle">

thefonso

Effectively Reviewing a Pull Request
====================================

How do they work?
-----------------
- code on a branch or fork
- open pull request
- have people review code
- potentially update the code
- merge pull request