harlow

Make it real

Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.

Ship it

Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.

Do it with style

harlow

backend default {
  .host = "127.0.0.1";
  .port = "8000";
}

# We go BACK to varnish to get it to generate an ESI template that 
# generates a JSON-P response.
backend jsonp_template_backend {
  .host = "127.0.0.1";
  .port = "8070";

harlow

#!/bin/bash
# from here: http://www.codingsteps.com/install-redis-2-6-on-amazon-ec2-linux-ami-or-centos/
# and here: https://raw.github.com/gist/257849/9f1e627e0b7dbe68882fa2b7bdb1b2b263522004/redis-server
###############################################
# To use: 
# wget https://raw.github.com/gist/2776679/04ca3bbb9f085b192f6aca945120fe12d59f15f9/install-redis.sh
# chmod 777 install-redis.sh
# ./install-redis.sh
###############################################
echo "*****************************************"

harlow

{
  "_links": {
    "self": { "href": "/orders" },
    "next": { "href": "/orders?page=2" },
    "find": { "href": "/orders{?id}", "templated": true }
  },
  "_embedded": {
    "orders": [{
        "_links": {
          "self": { "href": "/orders/123" },

harlow

class TaskCompletion
  include ActiveModel::Model
  attr_accessor :task, :complete
  
  validates :complete, inclusion: { in: [true, false] }

  def self.for_task(task, params={})
    new(params).tap do |completion|
      completion.task = task
    end

harlow

# ------------------------------------------------------------------
# Desigining "trending topics in 24 hours sliding window" with Redis
# ------------------------------------------------------------------

redis-cli del tophashes:2010-12-07-08-00
redis-cli del tophashes:2010-12-07-09-00
redis-cli del tophashes:current

echo '=== 8:00 AM ==='

harlow

class BookingPaymentsController < ApplicationController
  def create
    booking_payment = BookingPayment.new(booking_payment_params)
    booking_payment.pay

    respond_with payment, location: balance_trip_path
  end
  
  private
  

harlow

# coding: utf-8
require 'sinatra'
set server: 'thin', connections: []

get '/' do
  halt erb(:login) unless params[:user]
  erb :chat, locals: { user: params[:user].gsub(/\W/, '') }
end

get '/stream', provides: 'text/event-stream' do

harlow

1. Your class can be no longer than 100 lines of code.
2. Your methods can be no longer than five lines of code.
3. You can pass no more than four parameters and you can’t just make it one big hash.
4. When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done.

You can break these rules if you can talk your pair into agreeing with you.

harlow

My issues with Modules

In researching topics for RailsCasts I often read code in Rails and other gems. This is a great exercise to do. Not only will you pick up some coding tips, but it can help you better understand what makes code readable.

A common practice to organize code in gems is to divide it into modules. When this is done extensively I find it becomes very difficult to read. Before I explain further, a quick detour on instance_eval.

You can find instance_eval used in many DSLs: from routes to state machines. Here's an example from Thinking Sphinx.

class Article < ActiveRecord::Base