Blake blakewest

General

Are all vars used somewhere?
Do the vars have properly cased, and meaningful names?
Style looks appropriate
No unnecessarily duplicated logic
Code intent is clear upon initial reading
Any code that isn't clear, but is needed, has an effective comment
Are method calls or attribute lookups every called on entities that could be undefined/null?
The functions can appropriately handle unexpected inputs.
Commented code has been removed (comments themselves are fine).

There is good code coverage in tests
Edge case inputs have been thought of in the tests
Background jobs related to this migration have also been migrated
No polymorphic associations (they don't work because they use the migration's model class name)

Important

Have all the soon-to-not-work attr names been globally searched for on the front end?
Have all the soon-to-not-work attr names been globally searched for on the back end?
Have any now unused files been cleaned up/deleted?
Are any data migrations necessary? (If so, consult the Data Migration Checklist)
Have we notified customers of any potential issues?

Inline Manual is our in-app help tool.

I've written an "integration" for it with help-juice that allows you to bring in links to HelpJuice articles right into the app. It ends up looking like this: You can do this using the Inline Manual topic authoring tool, and there's no need to touch our actual code. Here's how it works.

1.) In the inline manual authoring tool, you'll put fields in that tell our app to look up articles in help-juice. It might look like this:

2.) That's it. You're done.

Why We Use This Checklist:

Hint Health is an enterprise software company with only a handful of engineers. We handle payments for big health care clients, and we can't afford to "just try whatever". We have to balance speed with getting things right the first time. This checklist has been iterated on many times, and has proved very helpful in doing that.
The goal here is to 1.) Make sure you build things people want. And 2.) Surface problems and implications of the design as fast as possible, by reminding ourselves of important questions that can easily get overlooked.

How To Use:

Use the top area to consolidate the latest thinking on the feature. (on that point, we don't use this for bugs or chores. only features)
Use the checklist at the bottom to make sure you're asking the right questions, and do a kick ass job of defining, designing, and implementing the feature.
As soon as you're like... "we should build X", stop and do the User Requirements Pipeline. This

Hey there Richard. Ok, here were the items that got me a bit confused:

1.) You linked to this file, but the code that is in the actual tutorial doesn't match up (I assume cause you updated it at some point?). But either way, if someone wanted to download the file, it wouldn't match.

2.) Right after copying that opening file (right above the "Let's build this, shall we?" part, it asks you to build it, but that file won't build, and not because of the reasons you predict in the post. It doesn't build because we're missing some things.. a.) initialModel does not exist. And we also need to set "errors" on the initial model. So I would suggest doing this..

	describe('Coupons', function(){
	// Set up vars that we'll want to use in multiple tests
	var $httpBackend, $scope, $view, $location;
	var merchantData, visit, couponNameField, couponAmountField, createButton;

	// Load your app
	beforeEach(module('my-app'));

	beforeEach(inject(function(_$httpBackend_, _$rootScope_, _$timeout_, _$controller_, _$compile_, _$location_){

	Things to consider when having a 'large' discussion, or design discussion

	Ask each question at the start of a discussion:
	1.) How much data do we have or what is our evidence around the propsed need/problem?
	2.) If there are outstanding questions to be answered, how can we answer them, and should we do that first before continuing?
	3.) Do all of us need to be discussing this right now?
	4.) What question really needs to be answered now?

	Now discuss

	# Used when a practice's patients have been transferred to Stripe from
	# another payment processing platform and we need to associate their Stripe
	# customers with their Hint patients. This is done by matching credit card name
	# to patient name or to email, or to address, or hint hid.

	def get_customers(practice, params = nil)
	response = Stripe::Customer.all(params, practice.stripe_token)
	response.data.each do \|customer\|
	stripe_customer_id = customer.id
	source_with_name = customer.sources.data.find { \|source\| source.try(:name) }

	angular.module('app.services')
	.factory('inlineManualService', inlineManualService);

	function inlineManualService($templateCache, $http, $q, $compile, $rootScope, $timeout, helpJuiceService){
	return {
	onTopicStart: onTopicStart,
	};

	function onTopicStart(player, topic_id) {
	var description = player.topics[topic_id].description;