There are lots of great tools out there. Far too many to try. Here are the ones that I’ve tried, and found worth recommending. Mostly they’re
Quiver is a “Programmer’s Notebook”. I’ve recently switched to it from CodeBox which seems to have been abandoned by its developer. I’ve got some minor quibbles with Quiver, but overall it’s pretty nice and I’ll be bringing all my code snippets and reference material over to it.
You’ve got a lot of software options when setting up a blog. Over the years. I’ve used or tried most of the options including, but not limited to: WordPress, Jekyll, Octopress, and at least 3 custom built systems.
What follows is my thinking on the pros and cons of each option, and why I’m switching back to a static blog system (Hugo this time).
Dynamic blogs, like WP, have a lot going for them:
Mou as your Markdown loving Mac geeks know, is a split pane Markdown editor. It’s been around for years and it’s really quite good. I even donated to its creator in the past to support it. Now he’s put together an IndieGoGo campaign to pay for people to work on it full time, but I won’t be contributing.
Mou was never open source. I’m ok with that. I use a bunch of great proprietary apps. Unfortunately, that means that when its developer (Chen Lou) was busy with his life, Mou languished, and no-one could help improve it. Eventually he decided he couldn’t give it the attention it deserved and tried to sell it. Sadly, I found out about this after the fact or damn would I have been trying to put together the money to buy it.
In Programming Perl Larry Wall (in)famously suggested that programmers had three great virtues: Laziness, Impatience and Hubris. Over the years I’ve kept coming back to those because there’s a real truth to the idea as he originally presented it, but it’s limited, and his definition of “Hubris” has no relation to the actual word. I believe that those may be aspects of real programmers, a great programmer goes beyond that. Building on Larry’s idea, I present you The Five Virtues of a Great Programmer:
Vampire Bug: n. something that worked when you went to bed at 2AM, but when exposed to the light of the next day dies horribly. Typically the exposure proves that it couldn’t possibly have been working at 2AM either.
( as of Sept 30th 2014 )
These are the instructions for how to do it if you’ve already got it configured and need to add a new app / device. If you don’t have it set up already, GitHub’s docs are… probably passable.
This afternoon my intern asked me this simple question. She’s a new developer, and a friend of hers is working in a fresh codebase, with best practices. Everything is nice, and he can keep the entirety of it in his head. She’s working with my team, Support Engineering. We’re the front-line bug squashers at our company. We’ve got a legacy codebase with no tests and brain melting insanity around every bend.
First, it should be noted that not all stories are “User Stories”. For example a developer might be tasked with manually running some script. The Story might simply be “run the fooberry script”.
For everything that effects the UI, use a template:
As a < type of user >
I want < to perform some task >
So that < I can achieve some goal >
Note that it’s all about what the user wants. This isn’t about instructing what change to make to a system. It’s about advising implementers on what the desires of the user are.
Finding the Github pull request associated with a branch.
Work on a large enough project, with other people and sooner or later you’re going to find some commit, or branch, and want to know what was in the pull request that merged it in. Maybe you want to see what other commits got merged over at the same time. Maybe you want to see what the diff was at that point in time. But, how do you get from a branch name to a pull-request.
Writing code is a lot like maintaining a Bonsai Tree. If you stop pruning it it’ll stop being a Bonsai and turn into a bush. Little tweaks, frequently aesthetic ones, will help to keep it beautiful and under control. It will still grow in unexpected directions, as other developers make changes, but careful pruning will keep it balanced, and healthy.
What is “careful pruning” then?
Each file is a branch on our tree. The methods, are leaves. We come in to work and start examining one of the branches. Some days we need to encourage it to grow a specific way by adding a feature. Some days we make little snips to correct a bug. But what happens if, upon examining your branch for other reasons, you discover that it’s grown into spirals and knots. You can’t reach your clippers in to snip the leaves you need. You can’t do much of anything without difficulty and frustration, and frankly, it looks like crap. The unexpected spirals and knots need to go.
