rondy

OOP Design workshop

Part 1

• Initial step: Plan the user story (goals, acceptance tests).
• Getting familiar with the CEP SOAP API.
• Test as a documentation for external API usage.
  • Introduce spec/use_cases.
• byebug as a tool for API learning & discovering.
• Don't be bothered about duplication while enough use cases are not fully covered yet.

rondy

{
	"auto_match_enabled": true,
	"bold_folder_labels": true,
	"caret_style": "phase",
	"color_scheme": "Packages/User/Xcode_default.tmTheme",
	"draw_white_space": "false",
	"ensure_newline_at_eof_on_save": true,
	"font_face": "Monaco",
	"font_size": 15.0,
	"highlight_line": true,

rondy

# This initializer adds a method, show_mongo, when running a rails console. When active, all
# moped commands (moped is mongoid's mongodb driver) will be logged inline in the console output.
# If called again, logging will be restored to normal (written to log files, not shown inline).
# Usage:
#   > show_mongo

if defined?(Rails::Console)
  def show_mongo
    if Moped.logger == Rails.logger
      Moped.logger = Logger.new($stdout)

rondy

class ProductsController < ApplicationController
  def index
    @products = Product.vitrine(34)
    respond_with @products
  end
end

class Product < ActiveRecord::Base
  def self.vitrine(limit)
    with_state(:published).limit(limit)

rondy

1. Add debugger to Gemfile

2. Run bundle

3. Require debugger on config/application.rb

4. Run git stash save 'debugger'

5. Add the following aliases to .gitconfig:

    debugger = stash apply stash^{/debugger}
    dropdebugger = checkout Gemfile Gemfile.lock config/application.rb
   

rondy

Sometimes a Controller is Just a Controller

Abstract

You grok SOLID. You practice TDD. You've read Sandi's book…twice. You rewatch Destroy All Software monthly. You can pronounce GOOS. You know your stuff!

But some of your coworkers say your code is too complex or confusing for them. You might rush to conclude that must be a them problem.

But doubt lingers: what if they're right?

rondy

Testing front-end for a Sinatra app with RSpec and Capybara

I've used Cucumber quite a bit on my last job. It's an excellent tool, and I believe readable tests are the way to the future. But I could never get around to write effective scenarios, or maintain the boatload of text that the suite becomes once you get to a point where you have decent coverage. On top of that, it didn't seem to take much for the suite to become really slow as tests were added.

A while ago I've seen a gist by Lachie Cox where he shows how to use RSpec and Capybara to do front-end tests. That sounded perfect for me. I love RSpec, I can write my own matchers when I need them with little code, and it reads damn nicely.

So for my Rails Rumble 2010 project, as usual, I rolled a Sinatra app and figured I should give the idea a shot. Below are my findings.

Gemfile

rondy

ORGANIC FRUIT'S WAY

• Escreva um test case que reflita a interação sob a perspectiva do usuário (entrada => processo => saída);
• Comece a implementação pela camada mais próxima do usuário ('controller', 'worker', 'views'). Caso a camada ainda não exista, comece pelo próprio spec file;

require 'rails_helper'

feature 'Awesome feature' do
 scenario 'User can do something awesome that will bring some valuable for him' do

rondy

- (void) getDataFromLocalJSON
{
    NSString *jsonPath = @"response.json";
    NSFileHandle *file;
    NSData *databuffer;
    file = [NSFileHandle fileHandleForReadingAtPath: jsonPath];
    if (file) {
        databuffer = [file readDataToEndOfFile];
        [file closeFile];
    }

rondy

- (BOOL) isConnectedToNetwork
{
  Reachability *hostReachable = [Reachability reachabilityWithHostName:@"www.google.com"];
  NetworkStatus internetStatus = [hostReachable currentReachabilityStatus];
  return ((internetStatus == ReachableViaWiFi) || (internetStatus == ReachableViaWWAN));
}