weblog.masukomi.org

The Daily Standup Meeting is a core aspect of Agile development. The simplified idea is that you want to start the day with a very quick status check of what everyone’s working on, and helps “…to coordinate efforts to resolve difficult and/or time-consuming issues”.

But, how do you keep track of the things your minions are working on today and deal with your own tasks, and 400 daily interruptions? For me the answer was to put together the Daily Team Tracker Worksheet.

The backstory

Once upon a time there was a Kickstarter to make the world’s most awesome keyboard / case … thing to “Turn your iPad® into a laptop”. As with most hardware projects on Kickstarter the expected delivery date came and went, and came and went again, but I feel the folks at Crux did a great job of keeping the backers informed, and the reasons it got set back almost always boiled down to them not being willing to accept half-assed Chinese manufacturing even if it would have gotten it into our hands sooner.

The thing about today is that we have the power.

We, can destroy this fear.

Not by being stoic. Not by being “strong”. By smiling. By being human. By being the neighbors we wish we were surrounded by.

Go outside.
Smile at a stranger.
Ask someone how they’re doing and mean it.
Listen.

Yesterday’s act was horrific, but I will light up this mother fucking town with smiles, because we are alive, and this world is filled with brilliant people with warm hearts, and their own 200 watt smiles, just waiting to shine.

tldr;

• git’s default configuration with regards to push is potentially very dangerous.
• make sure you’ve run git config --global push.default current
• There are other options for push.default but make sure you read the docs before setting them.
• setting current as your default behavior means no more complaints about setting upstream when pushing.

Perception vs. Reality vis-à-vis git push

When it comes to git push most people think “It pushes my current branch’s updates up to the remote server” but that’s only a small part of what’s happening, and ignorance about the rest can leave you with very upset coworkers. I know, because that’s exactly what happened to me today when I ran git push -f on a coworker’s computer that happened to have the default configuration.

This morning’s shower brought me an interesting series of thoughts that I thought you might appreciate, and it all started with the simple question of “How do you set The Atomic Clock?”

My first thought was that at some point you have to find some other clock and precisely sync up with it. Then again, they may have said “fuck it” and just had Bob press a button when some other clock flipped over, but then I wondered “How do we know what time it is in the first place?”

There are two things that make using vim awesome… no there are about 200,000 but most of them involve adding a few lines to your .vimrc to enable them, or installing a plugin. My .vimrc is just over 300 lines after all these years of use and customization. But, rather than go into all that, I figured some of the vim geeks out there might appreciate a pointer to some of the plugins I use. I’d also be happy to hear suggestions any alternatives to the ones I am running.

We love the game Mage Knight, but the co-op rules are widely regarded as crap. The following rules have been collected primarily from Board Game Geek, an tweaked ever so slightly here, and there, in an effort to make the game cooperative and yet, still balanced.

This document covers:

• Assistive Spellcasting
• Sharing of fame and loot
• Trading of cards, crystals, and units
• Modifications for Interactive cards
• Modifications for Interactive skill tokens

It’s generally good practice to rebase commits on a topic branch into a single commit before merging. It results in a much cleaner commit history, and makes rollbacks easier.

The Question

However, the question was raised: what happens if you…

• fix a bug (commit 1)
• create a Pull Request
• get feedback via the Pull Request
• fix the bug fix (commit 2)
• rebase those two commits together (new tree-ish)
• push that back to GitHub (requires push -f )

The answer is based on understanding that a GitHub pull request has two forms of commenting: * comments on the pull request itself * comments on the commits that the pull request encapsulates. These are the comments made on specific lines in the diff.

Who should read this?

Anyone who’s seen The Sketchnote Army and wished they could do that. Anyone who’s sick of useless meeting notes they never remember, and never go back to read. Anyone who wants a way to provide information to people in a way that people will actually enjoy consuming, and not just skim through.

Lets assume you’ve already cloned a remote repo and have been working with it. Now, someone has set up a second repo out there for the same codebase, and you’d like to interact with both.

*Please note: The following is based on the assumption that you have write privileges to the second repo, but don’t worry, you do essentially the same thing if you don’t and I’ll cover the differences at the end. *