Dave Moore dwmoore

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

General rules

Follow standard conventions.
Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
Boy scout rule. Leave the campground cleaner than you found it.
Always find root cause. Always look for the root cause of a problem.

Design rules

React "Hello World" Examples

Below are a small collection of React examples to get anyone started using React. They progress from simpler to more complex/full featured.

They will hopefully get you over the initial learning curve of the hard parts of React (JSX, props vs. state, lifecycle events, etc).

Usage

You will want to create an index.html file and copy/paste the contents of 1-base.html and then create a scripts.js file and copy/paste the contents of one of the examples into it.

This list is based on aliases_spec.rb.

You can see also Module: RSpec::Matchers API.

matcher	aliased to	description
a_truthy_value	be_truthy	a truthy value
a_falsey_value	be_falsey	a falsey value
be_falsy	be_falsey	be falsy
a_falsy_value	be_falsey	a falsy value

This describes the workflow to use Heroku as a staging environment. It assumes you already have an existing heroku app in production.

# rename your git remote heroku to something else like production
git remote rename heroku production

# so now you will push as: git push production master

# create the staging app
heroku apps:create staging-appname

a simple git branching model (written in 2013)

This is a very simple git workflow. It (and variants) is in use by many people. I settled on it after using it very effectively at Athena. GitHub does something similar; Zach Holman mentioned it in this talk.

Update: Woah, thanks for all the attention. Didn't expect this simple rant to get popular.

Capybara Actions

# Anchor
click_link 'Save'

# Button
click_button 'awesome'

# Both above

	# Recently I had need to work on an ActiveRecord model
	# that gained much of its functionality through the
	# inclusion of a Ruby Module. Over the course of the
	# work, I found that many of the models that include
	# the module also included duplicated specs to cover
	# the inherited behavior.
	#
	# Of course, this isn't ideal.
	#
	# In a perfect world, the module's behavior would be

	class AddUserNameForAuthenticationToUsers < ActiveRecord::Migration
	def up
	add_column :users, :username, :string, null: false, default: ""
	add_index :users, :username, unique: true
	add_column :users, :encrypted_email, :string
	remove_column :users, :email, :string
	add_index :users, :encrypted_email
	end
	def down
	remove_column :users, :username

	// 4 spaces to 2 spaces
	%s;^\(\s\+\);\=repeat(' ', len(submatch(0))/2);g

	// Tab to 2 spaces
	:%s/\t/ /g

	class Person
	def initialize(attributes)
	attributes.each do \|attribute_name, attribute_value\|
	##### Method one #####
	# Works just great, but uses something scary like eval
	# self.class.class_eval {attr_accessor attribute_name}
	# self.instance_variable_set("@#{attribute_name}", attribute_value)

	##### Method two #####
	# Manually creates methods for both getter and setter and then