lisswart

Mental Model

A mental model is an explanation of someone's thought process about how something works in the real world (source: wikipedia)

lisswart

PEDAC

Objective	Step	Description
Process the Problem	Understand the Problem	Identify expected input and output Make the requirements explicit Identify rules Mental model of the problem (optional)
	Examples/Test Case	Validate understanding of the problem
	Data Structure	How we represent data that we will work with when converting the input to output.
	Algorithm	Steps for converting input to output
Code with Intent	Code	Implementation of Algorithm

lisswart

HTTP status code symbols for Rails

Thanks to Cody Fauser for this list of HTTP responce codes and their Ruby on Rails symbol mappings.

Status Code Symbol
1xx Informational
100 :continue
101 :switching_protocols
102 :processing

lisswart

How to think about Monads

Initially, Monads are the biggest, scariest thing about Functional Programming and especially Haskell. I've used monads for quite some time now, but I didn't have a very good model for what they really are. I read Philip Wadler's paper Monads for functional programming and I still didnt quite see the pattern.

It wasn't until I read the blog post You Could Have Invented Monads! (And Maybe You Already Have.) that I started to see things more clearly.

This is a distillation of those works and most likely an oversimplification in an attempt to make things easier to understand. Nuance can come later. What we need when first learning something is a simple, if inaccurate, model.

This document assumes a beginner's knowledge of pure functional programming and Haskell with some brief encounters of Monads, e.g. [Functors, Applicatives, And

lisswart

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.

lisswart

## Delete a remote branch
$ git push origin --delete <branch> # Git version 1.7.0 or newer 
$ git push origin :<branch> # Git versions older than 1.7.0

## Delete a local branch
$ git branch --delete <branch>
$ git branch -d <branch> # Shorter version
$ git branch -D <branch> # Force delete un-merged branches

## Delete a local remote-tracking branch