Today, this idea came to me. I may try to draw it, but for now, generating three images with Craiyon and assembling them with paint.net feels close enough.

Lately, I’ve found myself looking into UWP development. Tonight I want to share a problem I ran into and a workaround that I found. I’ve created a repo that shows the step by step progression, and this blog post is meant to provide additional context around that. Pre-emptive nitpickers note: for the sake of problem reduction, the code in this repo is not overly concerned with patterns, best practices, error checking, and so on

Today I realized I’ve overlooked a great feature of Hapi.js, so I figured I’d write a quick post about it. What I Was Doing For a server rendered view, I was doing this. var jade = require('jade'); var fs = require('fs'); var template = jade.compile(fs.readFileSync(pathToTemplate)); // later on return template(context); This was fine for what I was doing at the time, since the rendered output was really part of a larger response, and was pretty much the only area in the system where such a thing was being done.

This is part of a series on good commits. In this post, we’ll discuss atomicity and frequency. Remember that this series and the talk from which it came is a description of what has worked well for me, not a prescription of what will work well for you. It’s ok to do things differently. Atomic Commits By an atomic commit, I mean there’s just one reason for change included in the commit.

Me: Have you checked the closet? 5yo: No, I know it’s not there. Me: But have you checked the closet? 5yo: Nooooo. I know it isn’t there. Me: I hear you, but I want to know if you’ve actually looked. (wife comes back with the missing shirt) Me: Was it in the closet? Wife: Yep. As a result, we had a good discussion about the differences between knowing and thinking.