jameshwang

# OLD WAY
def subscription
  if parent.present?
    parent.subscription
  elsif current_subscription && current_subscription.active?
    current_subscription
  elsif cancelled?
    subscriptions.detect { |sub| sub.cancelled? } || subscriptions.first
  else
    subscriptions.detect(&:active?) || subscriptions.first

jameshwang

angular.module('datePickerFilter', [])
  .filter('greaterThanDate', ['$filter', function($filter) {
    return function(rows, date) {
      return $filter('filter')(rows, function(row) { return row.occurredAt > date });
    };
  }])
  .filter('lessThanDate', ['$filter', function($filter) {
    return function(rows, date) {
      return $filter('filter')(rows, function(row) { return row.occurredAt < date });
    };

jameshwang

require 'subscription_change_controller'

describe SubscriptionChangeController do
  let(:account) { double('account', update_subscription: true) }
  let(:finance) { double('finance', notify: true) }
  let(:sales)   { double('sales', notify: true) }

  it "updates the account" do
    expect(account).to receive(:update_subscription)
    SubscriptionChangeController.new(account).run

jameshwang

git filter-branch -f --env-filter "GIT_AUTHOR_NAME='Author Name'; GIT_AUTHOR_EMAIL='author_email@gmail.com';" HEAD

jameshwang

Refactoring Ruby Edition

Chapter 6: Composing Methods

Extract Method

Basically just take a block of code and move it out to its own method.

Make sure the variables are passed in as arguments.

Inline Method

Sometimes, we want to make methods to help clarify the code to the reader. However, sometimes, it may be best to just eliminate the method if it's a one liner and makes more sense by itself.

jameshwang

1. What should I test?
2. How should I test things?
3. How do I start trying to rewrite a test for an already given test?
4. What is your workflow when applying TDD in existing code?

jameshwang

Learning Golang

Book

The Way to Go

Types

Elementary default to a zero-value:

1. int
2. float

jameshwang

Test-Driven Development By Example: Kent Beck

Test-Driven Development Patterns

1. Isolate Test: If 1 test breaks, it should be 1 problem to fix. Likewise, if 2 break, then 2 fixes. It shouldn't be that 10 test break and 1 fix fixes them all. Isolating tests encourages you to compose solutions out of many highly cohesive, loosely coupled objects.
2. Test List: Before beginning, write a list of all the tests. However, this doesn't mean write the tests, it means list them. If you write a bunch of tests all at once, you break the cycle of Red, Green, Refactor.
3. Test First: write tests before you write code. Writing tests first helps you think about design and also helps you focus
4. Assert First: try to write your assert/expect/should first. It will show what you want to have pass. Then work backwards to "how" you will make that assert pass. What will you have to setup, mock, stub, etc.
5. Test Data: Try to use real data that makes sense to the reader. Potentially fixtures and factories
6. Evident

jameshwang

#OOD for Ruby Notes

##Chapter 1: Object-Oriented Design

• The world is procedural. One step at a time (like a script).
• OO is about the objects that message back and forth between each other
• You have to "Design" code because that code WILL change. If it never changed, then you can code it whatever way you want and it wouldn't matter.
• By sending a message, the sender has to know something about the receiver. This of course means there's a dependency. And the key to OOD is MANAGING dependencies.
• There is always a battle between what needs to get done NOW vs creating something that is designed better that will take more time. This balance will come with experience (I HOPE)
• Agile is the method that allows design to be an iterative process. This allows for better OO design as well.

jameshwang

package main

import (
	"encoding/json"
	"errors"
	"fmt"
	"log"
	"net/http"
)