brianstorti

#Practical Object Oriented Design in Ruby

Design that anticipate specific future requirements almost always end badly.
Practical design does not anticipate what will happen to your application, it merely accepts that something
will and that, in the present, you cannot know what. It does not guess the future; it preserves your options for accommodating the future.
It doesn't choose; it leaves you room to move.
The purpose of design it to allow you to do it later and its primary goal is to reduce the cost of change.

Design is more the art of preserving changeability than it is the act of achieving perfection.

brianstorti

class PriorityQueue
  attr_reader :elements

  def initialize
    @elements = [nil]
  end

  def <<(element)
    @elements << element
    bubble_up(@elements.size - 1)

brianstorti

defmodule CounterWeb.Counter do
  use Phoenix.LiveView

  def render(assigns) do
    ~L"""
    <div>
      <h1>The count is: <%= @val %></h1>
      <button phx-click="dec">-</button>
      <button phx-click="inc">+</button>
    </div>

brianstorti

# Selection sort (very slow on large lists)

a = [9,8,6,1,2,5,4,3,9,50,12,11]
n = a.size - 1

n.times do |i|
  index_min = i

  (i + 1).upto(n) do |j|
    index_min = j if a[j] < a[index_min]

brianstorti

# Bubble sort (inefficient for sorting large data volumes)

require 'test/unit'

def sort(a)
  swapped = true
  n = a.size
  j = 0
  while swapped do
    swapped = false

brianstorti

Levels of testing

Acceptance: Does the whole system work?
We use acceptance tests to help us, with the domain experts, understand and agree on what we are going to build next. We also use them do make sure that
we haven't broken any existing features as we continue developing. Our preferred implementation of the "role" of acceptance testing is to write end-to-end
tests which, as we just noted, should be as end-to-end as possible; our bias often leads us to use these terms interchangeably although, in some cases, 
acceptance tests might not be end-to-end.

Integration: Does our code work against code we can't change?
We use the term integration tests to refer to the tests that check how some of our code works with code from outside the team that we can't change. It might

brianstorti

#DevKit

Download DevKit at http://rubyinstaller.org/downloads
ruby dk.rb init
ruby dk.rb review
ruby dk.rb install

#curl

Download curl at http://www.gknw.net/mirror/curl/win32/ (devel)

brianstorti

#!/usr/bin/env bash

# Usage:
# $ command | timing
#
# Example:
# $ rails server | timing
#   00:00:00 | rails server -b 0.0.0.0
#   00:00:04 | => Booting Puma
#   00:00:04 | => Rails 5.1.3 application starting in development on http://0.0.0.0:3000

brianstorti

man() {
    PAGER="/bin/sh -c \"col -b | vim -R -c 'set ft=man' -\"" command man $@
}

brianstorti

# extracted from http://www.thekua.com/atwork/2011/07/ruby-script-to-capture-http-traffic/

require 'webrick'
include WEBrick
 
class Simple < WEBrick::HTTPServlet::AbstractServlet
  def do_POST(request, response)
    puts "Body: " + request.body
    puts "Header: " + request.raw_header.to_s