Otto Schnurr

Simplicity

2020-12-12T00:00:00+00:00

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible you are, by definition, not smart enough to debug it.

— Brian Kernighan

Any word you have to hunt for in a thesaurus is the wrong word.

— Steven King

If you love writing code – really, truly love to write code – you’ll love it enough to write as little of it as possible.

— Jeff Atwood

Make everything as simple as possible, but not simpler.

— Albert Einstein

“C” is for cookie. That’s good enough for me.

— Anonymous

A Different Kind of Software

2019-04-08T00:00:00+00:00

What makes machine learning different? What implications does it have for how software is developed?

My second installment in the “Demystifying Machine Learning” video series. More details can be found on my machine learning blog.

An Unlikely Robot Apocalypse

2019-01-18T00:00:00+00:00

My first attempt at recording a series of videos that try to unwrap some of the mystery surrounding machine learning. More details can be found on my machine learning blog.

A Programmer’s Guide to Joining the Circus

2018-08-15T00:00:00+00:00

There was a time in my life when I wanted to bring more right-brain thinking into my career. The division between technical and creative work always seemed somehow artificial and pervasive. Like some unexpected obstacle in the road. A Monty Python bridge of death where you are stopped and forced to choose. Creative or technical. Design or implementation.

Once you make the choice, you live with it. There’s no going back. Not without significant personal cost. No crossing the streams.

I knew this but I didn’t like it. With technical experience under my belt, why should creative pursuits be placed out of consideration?

What to Do?

At the time I was employed at Midway Games helping them update their sports animation engine from C to C++. I had been working there for almost four years.

Animation was a fascination for me. It felt full of promise. A hallowed ground where technical and creative ambition intersect. I started poking around on the web and ran across a new animation school. The courses and instruction were on-line. The mentors were professional animators. The founders of the school hailed from Pixar and Industrial Light and Magic.

Yoda and The Incredibles. Big time stuff.

The more I considered it, the more interested I became. This was 2005. I was single. No kids. No commitments. What would be the harm in seeing if Animation Mentor would even consider me?

A Left-Brain Defector

In May of 2005 I sent in my application. To my surprise, they accepted me into their character animation program. I decided to go for it full time and see where it would lead. When I handed in my 4-week notice at work and explained why, the reaction from my engineering colleagues ranged from perplexed to dumbfounded.

I may as well have joined the circus.

I was wandering into territory not many software engineers dare tread. “What’s your favorite RGB color?” they’d ask. “How can you consider yourself an artist if you don’t even have a favorite RGB color?”

Colors would be the least of my concerns.

As it turned out, my adventure into training for a creative vocation was not at all what I had expected. New cracks of consideration started showing up in this thing that I had called my career and I was unprepared to deal with them.

Looking back thirteen years later, if I could somehow reach back and give that person some advice this is what it would be.

Ghost of Otto’s Future

You are going from a left-brain field into a right-brain field. That’s going to have a stronger emotional component than you’re used to. The disappointments and challenges you’ll face won’t be on an intellectual level that can be reasoned out.

Should I learn more Python or continue getting better at Swift?

Instead, you’ll be wandering into a subjective arena.

I know I need to learn overlap better but the work of this other student over here is blowing my mind. I don’t even understand how they’re doing it. At this point, I don’t know if better overlap will really even make a difference in my work.

(hint: It will.)

The biggest difference between a programming guru and an animation guru is that the animation guru will seem like a magician. You can make decent guesses at how a programming guru got good at their craft. In contrast, the animation guru’s skill will seem like a mystery. Like a professional surfer, the better they are, the more effortless they are going to make animating look (even though for most people, animation is quite difficult).

Expect to run into students like this. The biggest gift you can give yourself is to try to not worry about it and avoid comparing yourself to them as much as you can.

You are not there to be better than them. You’re not even there to try and be as good as them.

You’re there to turn yourself into the best animator that you can be, starting from where you are right now.

A big trap that can get in your way is feeling bad about your work. It’s hard because portfolio is important. It will be emphasized. But the most important thing isn’t your work. It’s the time you will get to spend working on the work.

The pro surfer makes it look effortless because they’ve spent a ton of time in the water doing it. Less time out of the water thinking about it.

As much as you can (without burning out), treat this situation as an unprecedented opportunity to invest time in the animation craft. Regardless of how good or bad you think your work is, invest as much time as you can. Be that surfer that is in the water as much or more than anyone else.

The students you will meet and the friends you will make are going to be your greatest career resource. Many of them will enter the animation industry (not just the best ones). Even decades later, many of them will still be there.

Soon after school is done, they are not going to remember how good or bad you animate. They’re just going to remember what it’s like to hang out with you.

Finally, if you do nothing else, go get “The War of Art”. Read it often. Use it to help keep your internal Resistance at bay.

“Look in your own heart. Unless I’m crazy, right now a still small voice is piping up, telling you as it has ten thousand times, the calling that is yours and yours alone. You know it. No one has to tell you. And unless I’m crazy, you’re no closer to taking action on it than you were yesterday or will be tomorrow. You think Resistance isn’t real? Resistance will bury you.”

— Steven Pressfield

Prologue

The program lasted 18 months.

Until that point in my life, I had always thought of myself as having super power. A secret internal pool of something called “attention to detail” that was somehow inexhaustible. When necessary, I could pull out as much of it as I needed and recruit it for the situation at hand.

With animation however, I had met my match. The attention to detail that the art form requires from animators is staggering. When a director asks to put the cup in a character’s left hand instead of its right hand, the professional animator will deliver. Even if it means rebuilding the entire performance to do so. Untold amounts of painstaking work gets discarded when necessary.

For someone with software engineering sensibilities, this brute-force accountability to detail is an anathema. It’s seen as a liability that quickly gets trained out of us early in our careers. Concepts like abstraction and re-usability come to an engineer’s aid to manage these kinds of things. Without them, a project can quickly get out of control.

In 2006, character animators didn’t have such luxuries (at least not yet). In a world where word processors give us the power of editing with cut and paste, character animation in a production sense still belongs to monks in the monastery where manuscripts are re-written in ink by hand.

A Left-Brain Returns

The Pragmatic Programmer says you can’t simply gather requirements. You have to dig for them. That was my plan in 2007. I was a strange bird who had crossed the streams. A software developer who had seen a glimpse of what it was like to animate.

Not long after I finished the animation program, I landed a new job working for two Pixar alumni on a character animation tool.

Complexity

2018-03-28T00:00:00+00:00

The Programmers’ Credo: We do these things not because they are easy, but because we thought they were going to be easy.

— Maciej Cegłowski

The key to performance is elegance, not battalions of special cases.

— Jon Bentley and Doug McIlroy

First you learn the value of abstraction. Then you learn the cost of abstraction. Then you’re ready to engineer.

— Kent Beck

Hello Capture and Motion

2017-09-21T00:00:00+00:00

We’ve been working on a couple new iOS apps at work. Both released this week.

Persistence

2017-08-27T00:00:00+00:00

The best writing is rewriting.

— E. B. White

Opportunity is missed by most people because it is dressed in overalls and looks like work.

— Thomas Edison

Play a game you can win. Lose as much as you need to, to get there.

— David Allen

Reliability

2017-06-26T00:00:00+00:00

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilisation.

— Gerald Weinberg

Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

— Henry Spencer

… In fact, never ever use gets() or sprintf(), period. If you do, we will send evil dwarfs after you.

— FreeBSD Secure Programming Guidelines

Simplicity is prerequisite for reliability.

— Edsger Dijkstra

Courage

2017-05-11T00:00:00+00:00

Life shrinks or expands in proportion to one’s courage.

— Anais Nin

Jekyll Notes

2017-04-03T00:00:00+00:00

Most of this information comes directly from documentation at jekyllrb.com.

To learn Jekyll, first understand Liquid.
To learn Liquid, first understand YAML.

YAML

When data is easy to view and understand, programming becomes a simpler task.

Where JSON is designed for portability, YAML is designed for readabilty.

“YAML Ain’t Markup Language” (abbreviated YAML) is a data serialization language designed to be human-friendly and work well with modern programming languages for common everyday tasks.

To achieve readability, YAML is more complex to parse than JSON. Consequently, YAML is able to cover JSON as a superset. Valid JSON is also valid YAML.

Primitives

maps
sequences
scalars (strings and numbers)

YAML excels in working with those languages that are fundamentally built around the three basic primitives. These include the new wave of agile languages such as Perl, Python, PHP, Ruby, and JavaScript.

Syntax

Colons map keys to values.

time: 20:03:20
name: John Doe

Dashes designate a sequence

# Comments start with a hash.
# Three dashes start a YAML document.
---
- John
- Jane

Sequences and maps may commingle.

-
   name: apple
   color: red
-
   name: banana
   color: yellow

fruit:
   - apple
   - banana
vegetable:
   - carrot
   - onion

More YAML syntax here.

Liquid

Liquid is a ruby implementation that parses markup embedded with template expressions.

<ul id="products">
  {% for product in products %}
    <li>
      <h2>{{ product.name }}</h2>
      Only {{ product.price | price }}
      {{ product.description | prettyprint | paragraph }}
    </li>
  {% endfor %}
</ul>

Once the templates are compiled, Liquid evaluates them with supplied parameters to “render” new markup as output.

Primitives

Liquid offers two kinds of markup.

Output markup pipes content through filters:

    Hello {{ 'dave' | capitalize }}.

Tag markup applies control logic

{% if user %}
  Hello {{ user.name }}.
{% endif %}

Building with Jekyll

Overview

Jekyll is a simple, blog aware, static site generator. It’s the engine behind GitHub Pages.

Unlike blog engines that use a database, Jekyll parses files from a directory structure to statically generate a website.

Jekyll at its core is a text transformation engine.

Consequently, source text for a Jekyll website can live in version control.

Jekyll parses meta data from source files using YAML. Liquid injects this data into template code for output.

Blog posts may be written as Markdown source files and then injected as {{ content }} into template code.

Installation

verified with: MacBook Pro (Mid 2014), OS X 10.11.6

Using these OS X instructions:

sudo gem update --system
xcode-select --install
sudo xcodebuild -license
brew install ruby
sudo gem install -n /usr/local/bin jekyll bundler
bundle update
bundle install

Local Blog

jekyll new myblog
cd myblog
bundle exec jekyll serve

Alternate Instructions

The steps outlined here seem to be specifically catered to the Mac.

Basic Commands

Compile current folder into _site/ directory:

jekyll build

Compile current folder into <destination> folder:

jekyll build --destination <destination>

Compile <source> folder into <destination>:

jekyll build --source <source> --destination <destination>

Watch the current folder. Automatically compile changes into _site/:

jekyll build --watch

_config.yml is considered “global” configuration. Changes there are not watched. Instead the executable must be restarted.

The destination folder is always cleaned on rebuilds. Don’t put anything there unless you add it to keep_files.

Source Structure

Taken directly from jekyllrb.com.

.
├── _config.yml
├── _data
|   └── members.yml
├── _drafts
|   ├── begin-with-the-crazy-ideas.md
|   └── on-simplicity-in-technology.md
├─(gem)─ _includes
|        ├── footer.html
|        └── header.html
├─(gem)─ _layouts
|        ├── default.html
|        └── post.html
├── _posts
|   ├── 2007-10-29-why-every-programmer-should-play-nethack.md
|   └── 2009-04-26-barcamp-boston-4-roundup.md
├─(gem)─ _sass
|        ├── _base.scss
|        └── _layout.scss
├── _site
├── .jekyll-metadata
└── index.md

_config.yml: Build configuration.
- An alternative to loading up jekyll build with a bunch of command-line arguments.
_drafts/: Articles that are not published.
_includes/: Reusable code/content to share across pages and posts.
- Invoked using liquid tag, e.g. {% include header.html %}
_layouts/: Contains templates for posts.
- Chosen using the YAML front matter of each post.
- A post is injected into a template using {{ content }}
_posts/: Where the articles live.
- The filename convention for each article is specific: YEAR-MONTH-DAY-title.MARKUP
- The resulting link for each article is configured using permalink
_data/: Data files that jekyll loads and makes available at build time.
- Supported formats: .yml, .yaml, .json, .csv
- Example: members.yml would be available as site.data.members.
_sass/: Contains Sass partials that compile into a main.css
_site/: The default destination targeted by jekyll build.
- Any previous content in this directory is clobbered
  - Unless added to keep_files.
.jekyll-metadata: Private file for tracking incremental builds.

Any remaining files in the source directory are converted by jekyll if:

Then contain YAML front matter and …
They have an .html, .markdown, .md or .textile file extension.

Example: index.md

Otherwise, files and folders in the source directory are copied into the target destination as is.

Configuration

There are a variety of global options that can be specified either in _config.yml or as command-line arguments (or both).

source directory, destination directory
files to include or exclude
timezone, character encoding
drafts, future and unpublished posts
build environment
incremental and profile builds

You can also specify default values across specific areas of the site (for known and custom variables).

Here’s the complete list of default options that Jekyll runs with.

Content in Jekyll

YAML Front Matter

---
# The first line segment starts a YAML "document".
# In Jekyll, this document is known as "YAML front
# matter". It is the indicator to Jekyll that a file
# should get sent through the text engine.

# YAML front matter doesn't have to contain anything.
# However if it does, the information there becomes
# available to the the Jekyll build including this `page`
# containing the front matter.

title: Describing YAML Front Matter
custom_variable: custom values

# The second line segment ends the front matter.
---

All the stuff here is processed as `{{ content }}` in layout files.
...

Predefined front matter variables for all files: layout, permalink, published

Additional front matter variables for posts: date, category, tags. date helps give a post more precision if necessary for sorting different posts that occur on the same day.

Blog Posts

Add posts into the _posts/ directory with the format YEAR-MONTH-DAY-title.MARKDOWN.

Linking to Other Posts

Use post_url to refer to other posts in the site. This inoculates the link against changes in markup and permalink format.

Linking to Assets

You can use {{ site.url }} to innoculate against changes to the location of the blog (e.g. going from blog.example.com to example.com/blog/).

You can [get the PDF here]({{ site.url }}/assets/doc.pdf).

You don’t need to do this if you know the blog will always be at the root.

You can [get the PDF here](/assets/doc.pdf).

Access to Posts

All posts are available in site.posts.

A variety of post components are available including url, title and exerpts.

Static Pages

A static page (as opposed to a post) is content that is not date-based.

Place marked up files with front matter in the source directory or in subdirectories and those files will appear as HTML pages (in the same subdirectories) in the destination directory.

Static Files

Files that aren’t converted and just copied by Jekyll are collected in site.static_files. These files still have some Liquid properties: path, modified_time, name, basename, extname.

You can assign additional front matter to these files using defaults in _config.yml.

Variables

Collections

A collection (like posts and pages) is a namespace for a sequence of items. You can create custom collections (e.g. members, apidocs).

Declare the collection type in _config.yml:

collections:
  members
  apidocs:
    output: true
    permalink: /api/:path/:title:output_ext