Constantly Learning - Brett Hardin

Always Be Knolling

2016-01-15T00:00:00+00:00

Joshua Tree

2016-01-05T00:00:00+00:00

Apple Pencil

2015-09-10T00:00:00+00:00

Getting Things Done

2015-06-25T00:00:00+00:00

Automatically Clear Your Downloads Directory

2015-03-17T00:00:00+00:00

Information Is Not Secure

2015-03-05T00:00:00+00:00

Use The Defaults

2014-11-11T00:00:00+00:00

When I was 13-years old I competed in the Blockbuster video game championships. The start of the competition was to be the best in your hometown. I destroyed the local competition by beating both secret levels in Sonic the Hedgehog 2. Upon winning Blockbuster invited me to represent my city in the state finals.

The game we would be playing was NBA Jam. The competition would be a single- elimination head-to-head tournament.

Upon winning the hometown championship you received a free game. I chose NBA Jam to hone my virtual basketball skills before the state competition.

For those of you that don’t play video games, you can customize your controls. On a Sega Genesis system there are three buttons: A, B, and C. I didn’t like the default setup on NBA Jam which is as follows:

* A - Shoot
* B - Turbo
* C - Pass

I preferred the following:

* A - Turbo
* B - Pass
* C - Shoot

Before changing the defaults, I of course, read the rules for the state finals. It explained that changing the button configurations was optional. I read this as: it is optional for the player to change controls.

The state final was an all-day event. When I showed up to play my first game I explained to the man setting up the station that I needed to change the controls. He responded that it was an optional rule and the coordinators chose to use defaults.

“Optional in this case meant it was up to the tournament coordinators. The “coordinators crushed my chances of winning because I had not learned to use the “default controls.

Although I attempted to play the best I could, with controls I didn’t know, my opponent destroyed me.

Losing this way was demoralizing. I didn’t know how good I was because I couldn’t use my custom controls.

Since losing, I never change defaults.

From that moment forward, any game that I played, I would only use defaults. I completely ignore control configuration screens. I don’t even open them.

I recently changed from Bash shell to zsh. Upon making the transition I asked my colleagues which themes they use for oh-my-zsh. Sean sent me this screenshot:

I was immediately turned off because it didn’t look like a default shell. I already knew zsh, by default, didn’t look like this because I had already installed it and had it working. But, if I had seen this screen first, I would have not installed zsh.

Sean has all kinds of customizations. A status bar at the bottom, a left and right column, and even a quote. When moving to a remote system (through ssh) this type of configuration takes a while to setup. I don’t want to configure a new remote system to be effective. It takes too long.

I have some customization, such as git aliases, but Sean’s setup is ridiculous.

Anywhere I can, I choose vanilla. When presented with options, use the defaults.

P.S. For those curious, I decided on the “muse” theme. Here is what it looks like:

Chess and Computers

2013-08-17T00:00:00+00:00

Peter Thiel and Garry Kasparov were recorded having multiple conversations during a day in which they hung out.

At one point during the video they discuss computing power and speed. Kasporav known for playing Deep Blue, a computer designed to play chess, stated that humans associate computing power with chess playing. He believes humans associate chess playing with wisdom.

As computers get better at playing chess, society thinks that computers are improving at solving all problems. People who play chess, like Kasparov, are assumed to be intelligent because they are good at a game. But, is this true?

Kasparov dedicated a large portion of his early life to playing chess. He began training at the age of 10. Although he may have had a natural affinity and love of the game, practicing, and studying is what made him great.

To the layperson, someone who plays chess is deemed intelligent. So, this association naturally expands into computers.

If a computer can beat a human at something we deem as human and intelligent then they are becoming smarter at everything.

There are many things that computers don’t do well. Computer scientist group these problems into the category of NP problems.

Humans, including programmers and visionaries, are very poor at estimating time to complete complex tasks. We overestimate things we don’t understand and underestimate things that we do.

Until we have a technology breakthrough (e.g. quantum computing) we will still have machines which are poor at solving a certain class of problem.

Stamina to Continue

If you have the stamina to continue, the opponent will collapse.

Garry Kasparov

At one point, Thiel asks Kasparov what strategy he uses when playing simultaneous games. Kasparov says he focuses on keeping each game equally matched and waiting for his opponents to make a miscalculation.

Use Other People's Code

2013-08-04T00:00:00+00:00

Some developers use other people’s code while others write programs which do the same thing themselves. I’ve been fortunate enough to work for two startups who’ve had founding developers who were able to write code incredibly fast. However, faster isn’t always right.

A common attribute of developers who code fast is they roll their own code instead of using known software which does the same thing. Their reasoning is that they can build it faster than reading the documentation and implementing someone else’s code. Although this could be accurate it can either hurt the development team later on or it shouldn’t be done in the first place. Speed and iteration in a startup is the second most important thing for a startup behind customer development.

Swizec Teller:

After hours of debugging I finally traced the issue down to spaces in item names. Turns out id=”a word” doesn’t work. Who’d’ve thought? (hint: everyone)

But that’s an easy fix right? The point is, all you have to do is replace spaces with dashes. Simple.

But you’re wrong. You are creating a slug. It looks easy, but is actually very complicated. Luckily others have solved the problem already. Better than you.

That is the major problem. Developers that are able to code amazing software are often the ones who don’t really grasp the concept that someone else is better than them. They understand the idea, but they don’t grasp the concept.

He continues:

Why spend an hour looking for and learning how to use a gem instead of solving the problem in two minutes of coding?

That is the exact thinking of these types of developers. Don’t be this type of developer.

Developers who open source the code you are going to rewrite will continue supporting the code. Once you develop the code, you won’t maintain it or look for areas to optimize. The developer that has open sourced their code to do the same thing you are solving will. Other developers will contribute to the solution also. It’s like having a bunch of developers on your team that you don’t have to pay.

In addition, when new developers join your team they won’t have to learn your custom code base. They may already have experience with the open source solution which gives you a huge leg up in terms of speed of development.

I’m sure other industries have this same problem. It’s hard to find a good analogy, but the first that comes to mind is bakers. If a baker decides he wants to create a cookie, he just grabs the ingredients needed and starts baking. However, the Neiman Marcus cookie is pretty good and will get the job done. Why doesn’t he just use that recipe instead?

Foundational Rules of Code Testing

2013-07-24T00:00:00+00:00

I’ve been doing a lot of refactoring tests lately and have identified some anti-patterns. From talking with other developers it seems some of these rules are widely understood, while others aren’t. Even though something is understood, it doesn’t mean the community has adopted it. I know a lot of programmers who don’t even write tests.

If you are serious about programming and your test suite these are the rules I’ve identified which should always be followed.

Don’t have more than one assertion per test

This is a fairly simple one. If you are testing more than one thing or state in a test, don’t. Break it up into two tests. There are a few reasons for this. First, it’s easier to trouble shoot the failing test.

Replace this:

it 'has three ingredients' do
  ingredients = Shortbread.ingredients
  ingredients[0].should == "sugar"
  ingredients[1].should == "butter"
  ingredients[2].should == "flour"
end

With this:

it 'has three ingredients' do
  Shortbread.ingredients.size.should be(3)
end

describe 'ingredients' do
  it 'include eggs' do
    Shortbread.ingredients include("eggs")
  end

  it 'include butter' do
    Shortbread.ingredients include("butter")
  end

  it 'include flour' do
    Shortbread.ingredients include("flour")
  end
end

Note: If order is important, you could also check this under ingredients description. This is a good thing to point out in the earlier test though. Is order important? If another developer comes along and has the first test to work with, who knows…

Don’t start your test descriptions with the word ‘should’

It is implied the test should do something. Otherwise, it wouldn’t be a test. Rather than use the word should, start the description with a present-tense verb.

Replace this:

it 'should have three ingredients'

With this:

it 'has three ingredients'

Don’t overload classes or class methods in tests

It can be tempting to overload a class method in your test. Rather than having the method be called, you overload it to make sure it isn’t called. This can have unintended side effects.

If a test which overloads a method is called with a test that tests this method, bad things will ensue.

Use method stubbing for this and localize it to the individual test. Don’t let the test bleed into other tests.

Don’t use global variables

I normally see this used in conjunction with overloading class methods. Although a programming language gives you the tools, it doesn’t mean you have to use it. I like languages that give you enough rope to hang yourself with, however, when junior developers develop in these languages, bad things can happen.

Tests should be independent

One test should not rely on another test. Each test should be able to ran independently. Rspec and other testing frameworks provide ways to build upon the state of the test but still allow the test to be executed independently. Nothing can get your test suite in more trouble than breaking this rule.

One good way to ensure your test suite does this is by running the tests in random order. Rspec has supported running tests in random order since 2.8. Check your test suite documentation on how to do this.

Tests should leave state the way it was found

This is one of the hardest things to do. If one test sets up a database state, make sure you unwind that database state on tear down. If not, you, or someone on your team, will write a test which relies on this database state. Once tests are written this way, it’s hard to unwind.

Have I missed anything? What rules do you use while writing tests?