Samuel Flores samflores

de forma geral, a convenção é que em Ruby o == compara se dois objetos tem o mesmo valor, não que são a mesma instância, como acontece em Java. Esse valor pode ser depender do domínio da sua aplicação, mas eu costumo pensar "esses 2 objetos tem a mesma representação em memória?". De novo, em geral. Existem exceções quando isso faz sentido.

'1' == 1 # é falso, pq o valor de '1' em memória seria o encoding desse caractere em unicode/ascii (49) e não 1
false == 0 # é falso, pq o tipo "boolean" é _como se fosse_ um enum que só aceita os valores true e false
# um exemplo que foge a regra, mas "faz sentido" (de acordo com o Rails team), assumindo que User é um model do Rails
u1 = User.new(id: 1, username: 'john.doe')
u2 = User.new(id: 1, username: 'joao.silva')
# pq do ponto de vista do AR dois objetos com o mesmo id representam o mesmo registro, já que se eu salvar os 2 no banco um vai sobrescrever o outro

o === checa se o objeto "aceita" o outro como um similar ou membro. a definição de

Introdução ao Rails - Schola

O objetivo desta tarefa é montar a base de uma nova aplicação Rails de gerenciamento escolar, o Schola. Nessa semana o foco será a criação da aplicação, configurações iniciais e definição dos modelos necessários.

Tarefa 1

Criar o esqueleto da aplicação. Uma nova aplicação Rails usando Sqlite como banco de dados e Rubocop, SimpleCov, RSpec, Shoulda-Matchers e FactoryBot como ferramentas de auxílio ao desenvolvimento. Certificar-se de remover módulos com funcionalidades não necessárias (envio de emails, websockets, etc).

Tarefa 2

Introdução ao Rails - Peeper

Uma famosa plataforma de microblogging tem passado por maus bocados depois de uma recente aquisição. Os mais pessimistas preveêm que ela não sobreviverá por muito tempo e o seu cliente, contanto com isso, contratou você para desenvolver a nova plataforma que irá tomar o seu lugar: o Peeper.

Modelos

User

Campos

Já que estamos falando de semântica, minhas considerações finais:

event handler onFinish naturalmente é feito usando callbacks

está em questão se é semântico chamar esse argumento de callback

O argumento é o valor que é passado no parâmetro de uma função, que nesse caso acontece de ser outra função.

A confusão parece estar no fato de que você está rotulando a função em si (o argumento e não o parâmetro) como callback ou não. E não é isso que estou argumentando. Vou escrever um exemplo só pra ter nomes para chamar as coisas:

Keybase proof

I hereby claim:

I am samflores on github.
I am samflores (https://keybase.io/samflores) on keybase.
I have a public key whose fingerprint is 22CC 40B4 1D5E E988 C9C1 0ED0 D9F4 A3DA AB8F 0645

To claim this, I am signing this object:

	qt.qpa.wayland: Failed to load client buffer integration: "wayland-egl"
	qt.qpa.wayland: Available client buffer integrations: QList()
	qt.webenginecontext:

	GL Type: disabled
	Surface Type: DefaultRenderableType
	Surface Profile: NoProfile
	Surface Version: 2.0
	QSG RHI Backend: OpenGL
	Using Supported QSG Backend: yes

	qt.qpa.wayland: Failed to load client buffer integration: "wayland-egl"
	qt.qpa.wayland: Available client buffer integrations: QList()
	qt.webenginecontext:

	GL Type: disabled
	Surface Type: DefaultRenderableType
	Surface Profile: NoProfile
	Surface Version: 2.0
	QSG RHI Backend: OpenGL
	Using Supported QSG Backend: yes

	## Pay the bills!
	#
	# write the function bellow that tells which bills the user is able to
	# pay with the available budget
	#
	# the budget parameter is a number representing the amount available
	# the bills parameter is a array of hash objects in the following format:
	# [
	# { value: 100, type: :water, priority: 1 },
	# { value: 200, type: :credit_card },

	#include <stdio.h>
	#include <stdlib.h>

	typedef struct node {
	char key;
	int val;
	struct node *next;
	} node_t;

	typedef struct {