rondy

{
	"bold_folder_labels": true,
	"caret_style": "blink",
	"color_scheme": "Packages/One Dark Color Scheme/One Dark.tmTheme",
	"ensure_newline_at_eof_on_save": true,
	"folder_exclude_patterns":
	[
		"tmp",
		".git"
	],

rondy

“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.”

rondy

Functional objects on Ruby programming language

Goals

• Less questions asked. E.g:
  • How should I name my objects that carry behavior? They're nouns or verbs?
  • Should I expose attr_readers/writers/accessors?
  • What kind of input should it receive from constructor/initializers? And what about methods?
  • https://hackernoon.com/api-design-temporal-coupling-2c1687173c7c
• More consistent style among classes definitions.

rondy

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!

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

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:

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

https://medium.com/@rondy/66df167c7d54

Categorizing git commits and how it affects the test suite

• If the applied change is a "feature creation" or a "feature evolution" (i.e., it changes the current system behavior), then:
  • It should include a system/acceptance test, or, in case it already exists, ensure that the test will reflect the change.
  • It can optionally include a unit test case, since not every change requires a unit test.
  • A "feature creation" will probably include a good amount of system test and a few of unit tests.
    • Lots of unit test might be a design smell.
• A "feature evolution" (i.e., changing a feature that already exists) will probably include just enough system test and a good amount of unit tests.

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

# encoding: utf-8

module ChainOfResponsibility
  attr_writer :successor

  def can_handle_request?(request); end
  def do_handle(request); end

  def handle_request(request)
    if can_handle_request?(request)