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
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?
As a result, we had a good discussion about the differences between knowing and thinking.