From the post:
Complex systems like Git become much easier to understand once you figure out how they really work. The goal of this post is to shed some light on how Git works under the hood. We’re going to take a look at some of Git’s core concepts including its basic object storage, how commits work, how branches and tags work, and we’ll look at the different kinds of merging in Git including the much-feared rebase. Hopefully at the end of it all, you’ll have a solid understanding of these concepts and will be able to use some of Git’s more advanced features with confidence.
It’s worth noting at this point that this guide is not intended to be a beginner’s introduction to Git. This guide was written for people who already use Git, but would like to better understand it by taking a peek under the hood, and learn a few neat tricks along the way.
The logstash mascot has to be a contender for best logo for an open source project ever.
I have long been a web content management system nerd and Siteleaf seems like a decent little CMS, especially if you need to provide a CMS for clients.
pjax loads html from your server into the current page without a full page load. It’s ajax with real permalinks, page titles, and a working back button that fully degrades.
The idea is you can’t tell the difference between pjax page loads and normal page loads. On complicated sites, browsing just “feels faster.”
Making a change to an interface that impacts all its consumers requires two thinking modes: implementing the change itself, and then updating all its usages. This can be hard when you try to do both at the same time, especially if the change is on a PublishedInterface with multiple or external clients.
Parallel change, also known as expand and contract, is a pattern to implement backward-incompatible changes to an interface in a safe manner, by breaking the change into three distinct phases: expand, migrate, and contract.
The book cover makes me smile every time I see it.