Keyboard shortcuts, it’s a love-hate relationship. On one hand, they unlock hidden cheat code levels of productivity — on the other, they unlock… What was that again? … Oh yeah, you just can’t remember them! What is it about keyboard shortcuts that makes them so hard to remember? Should you even bother? Is there a reliable way to learn them?
Why is it so hard to remember keyboard shortcuts? Simply put, there’s so many shortcuts to remember, and their use taxes a different class of memory.
Refactoring is the lifeblood of a nimble codebase, but we need to stop hand-refactoring via Ctrl-C/V and start using our automated refactoring tool. Prepare to be convinced, then watch in amazement as you memorize your favorite refactoring tools’ keyboard shortcuts in two hours flat – and remember them forever.
You need an automated refactoring tool Refactoring without tests is dangerous Refactoring without tests and without an automated tool is like walking a tightrope over Niagara falls without a safety net - with your product and entire team standing on your shoulders.
The software engineer bristles with annoyance, then cringes in fear. The cause? They came face to face with an opposable opinion. What are these opposable opinions and is it possible to refactor our brain to respond better the next time we’re confronted with one of them? Read on, fair coder!
Let’s start with this illustration: Have you ever seen a basketball player “palm” a basketball? It’s a coveted feat which greatly enhances a player’s control of the ball.
Venerable old Vim has been with us since its creation by Bram Moolenaar in 1991. It’s light, it’s terse, it has a learning curve like the “Cliffs of Insanity”, and yet it’s still one of the most popular text editors in the world.
Here was my take on Vim, as compared to an adult beverage: Vim. It’s like being gifted a 50-year-old bottle of scotch. Now if you could just figure out how to open it…
Badges? Why don’t I have any stinking badges?
With a flick or your wrist and a flourish of your cape, you unveil your latest open source beauty. It has more bells than a bell foundry, more whistles than a traffic cop convention. But there’s one problem: your OSS-contributing peers all have these cool badges decorating their projects. They’re so shiny and colorful! They imbue an air of legitimacy to their projects, like a detective flashing his badge at a crime scene.
When you first started with git, you quickly got up to speed with committing, pushing, pulling, merging, and the like. But then you noticed a gaping hole in your knowledge - how do you find stuff in Git? Can you revert to a version of a file as it stood three weeks ago, or find out when a bug was introduced? Who was the last person to edit this file?
They always tell you that the great thing about Git is that you [almost] never lose any history. So how do you access and utilize that history?
What is the best laptop for programming? In the previous article we armed ourselves with a comprehensive mobile workstation checklist to see how popular laptops stack up against the needs of a software developer. We considered popular options like the MacBook Pro, Surface Book i7, and the Dell XPS 15. They’re decent machines, but their flaws burn brightly in the harsh light of The Checklist.
So if you’re not bemused by the Big Three in laptop choices – perhaps due to their lack of features or your lack of funds – where can you find a solid programming laptop?
Sometimes new developers ask me, “So, what’s the best laptop for a programmer?” It’s an important question. As a “software crafts(wo)?man”, your computer isn’t just your tool belt - it’s your pickup truck, miter saw, lathe, awl, bulldozer - all rolled into one. You need a reliable and performant machine that empowers you while staying out of your way as much as possible. It’s an important question, but the answer no doubt reminds you of a certain brand of adult diaper - It depends...
These days it’s hard to tell whether the computer saves us more time than it wastes. However recently I had an experience programming in Ruby that demonstrated to me that the computer can be our modern time-saving friend, especially when wielding a language like Ruby, delicately designed to just “get out of your way” and let you program. The story involves number crunching, eyebrow scrunching, and in the end, an unabashed brute-force beauty.
OpenCover analyzes your .NET codebase and generates an XML report rich with detail about the extent and quality of your code coverage. You think you’ve covered your testing bases, but how do you know? What if there’s actually a sneaky runner leading off second base? If so, OpenCover will blow his cover wide open. In this post I will show you how to retrofit your automated build with OpenCover. Then we’ll make the output more human-readable with Report Generator.
If you read my article about Psake, you’ll recall that I started the open source project Resfit in order to experiment with Acceptance Test Driven Development. I started the project with NCrunch and though the 30 day trial ran out, my appreciation for NCrunch’s coverage metrics did not. I found OpenCover, which generates some amazing code coverage metrics. Only trouble is, they’re all in XML - Better suited to be read by a build server than a lowly Developer like myself. That’s where ReportGenerator comes in, which “converts XML reports generated by OpenCover, PartCover, Visual Studio or NCover into human readable reports in various formats”.
It was early one weekend morning and I was trying to integrate AppVeyor with my GitHub project. But there was one problem: my build was failing miserably on AppVeyor. Strangely, it built just fine on my machine; but on AppVeyor the test ToStringShouldReturnResourceKey was failing a string comparison.
Investigating the failure
Fortunately I was using Shouldly, which produces very readable test output when your tests fail. See what you notice in the snippet below.