Skip to content

Instantly share code, notes, and snippets.

Rondy Sousa rondy

Block or report user

Report or block rondy

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile

DCI clipping

MVC was meant for reflecting the end user’s mental model but it still makes it too easy to hide the intentions of your program in your code.

  • It’s hard to find bugs in own code
  • It’s fun to find bugs in other people’s code
  • I learn from reviewer’s comments
  • Reviewer learns by reading my cod

Code must be Chunkable! Readable!


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 /
Last active Jan 21, 2018
Queueing Theory references

Queueing Theory references

General content

“Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.”

– Alan Perlis (Turing Award #1, ALGOL)

“Computer Science is the first engineering discipline in which the complexity of the objects created is limited solely by the skill of the creator, and not by the strength of raw materials.”

View sublime.json
"bold_folder_labels": true,
"caret_style": "blink",
"color_scheme": "Packages/One Dark Color Scheme/One Dark.tmTheme",
"ensure_newline_at_eof_on_save": true,
View gist:7422763
"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,
View gist:7372736
# 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 =$stdout)
View vitrine.rb
class ProductsController < ApplicationController
def index
@products = Product.vitrine(34)
respond_with @products
class Product < ActiveRecord::Base
def self.vitrine(limit)
  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

Organização de testes de aceitação

Sabemos que testes de aceitação (ou "feature tests", no linguajar do Rspec) são os testes mais próximos da especificação que é projetada entre developers, analistas de negócios, stakeholders etc. No paradigma ágil, esses testes deveriam refletir os critérios de aceite definidos em uma user story (aqui, sem entrar no mérito da pirâmide de testes).

Há uma questão que parece ser recorrente durante o desenvolvimento desses testes. Como organizamos os arquivos correspondentes a esses testes?

Eis algumas dúvidas que podem surgir:

  • A localização física e o nome dos arquivos deveriam refletir a organização física ou as capabilities do software? Ex:
You can’t perform that action at this time.