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.
What are Git hooks? Can you do anything useful with them? Also, since Git hooks come from Linux, is there anything special you need to do to get them working on Windows?
What are Git hooks?
Git hooks allow you to run custom scripts whenever certain important events occur in the Git life-cycle, such as committing, merging, and pushing. Git ships with a number of sample hook scripts in the
repo\.git\hooks directory, but they are disabled by default. For instance, if you open that folder you’ll find a file called
pre-commit.sample. To enable it, just rename it to
pre-commit by removing the
.sample extension and make the script executable (
chmod +x pre-commit if you’re on Linux, or just check your NTFS execute rights if you’re on Windows). When you attempt to commit using
git commit, the script is found and executed. If your pre-commit script exits with a 0 (zero), you commit successfully, otherwise the commit fails.
If you take a look at the default sample pre-commit script, it does a few helpful things by default, like disallowing non-ascii filenames since they cause issues on some platforms, and checking for whitespace errors. This means that if you enable this script and have “whitespace errors”, like lines that end in spaces or tabs, you’ll fail to commit and have to remove the whitespace before you can commit.
What cool stuff can I do with Git hooks?
Since you’re working with scripts, you can do pretty much anything with Git hooks. That being said, just because you can do something… Yeah, you know. Git hooks can make the behavior of common Git tasks like committing, pushing and pulling nonstandard, which can annoy people, especially if they’re just trying to get used to the glories of Git. But here are a few examples of what you might accomplish with Git hooks.
What is Psake and why do you want it? Psake is a build automation tool written in PowerShell. That means you don’t have to mess around with MSBuild scripts and trying to force procedural code into a declarative XML format - which is just weird. Psake frees you from the shackles of awkwardness. But how does it work?
With Psake, you write a PowerShell script consisting of one or more build “tasks” which you can invoke from PowerShell, or even from a continuous integration build server. You invoke your build task via the
Invoke-Psake function or, more commonly, via a
build.bat script. Each build task can depend on zero or more other build tasks, and it’s possible to set a default build task. Each build task can do whatever you’d like, including cleaning your solution, building your assemblies, running your acceptance tests, running your unit tests, generating code coverage reports, packaging the binaries in a zip file, a NuGet package, etc. If you dream it, Psake will build it.
Many of us cut our teeth on the elegant simplicity of the Linux command line, with its dazzling zero-based array of infinitely chainable commands. Then, with a dull thud you found yourself dumped rudely into the Windows environment, where things on the command line weren’t quite so peachy, to put it mildly. In fact, working in the old Windows command line was almost as fun as working in the trash compactor of the Death Star. Fortunately, with the advent of PowerShell, the dystopian landscape of the Windows console started to put forth a few shoots and sprigs of greenery. In this post I hope to show you some of our favorite Linux commands translated to their equivalent PowerShell cmdlets.
Many believe that to be successful, the members of an Agile team have to be a bunch of highly skilled full-stack hot shots. Some even go so far as to say that you should only hire skilled developers, or “senior” developers. Are the pundits just a bunch of arrogant elitists? Unfortunately, their elitist views aren’t entirely without merit. At their core, Agile teams are supposed to be self organizing and largely autonomous. Take the Scrum framework for example: the Product Owner decides *what* to build, but it’s up to the team to decide *how* to build it. Why is that dangerous if the team is composed of junior developers?
Many programming books are “recipe” style books. I suppose they appeal to us “Novices” on the Dreyfus model of skill acquisition: Just gimme the recipe, and no one gets hurt. Or maybe they appeal to that other short-sighted fellow with a hankering for fish:
“Please sir, can I have a fish? I’m really hungry… I’ve got a family you see, and um, bills, and rent, a mortgage on my phone, and the Evernote subscription is killing me…”
Well, Code Complete is not that book. Author Steve McConnell catches the fish, deftly removes the hook, and after dangling it in tantalizingly front of your face for a few seconds, throws it back in the water.
“You want a fish? Go and get it.”
Then, when your face resembles a flabbergasted house cat who’s just been deprived of its favorite squeaky toy, he puts a hand on your shoulder and leads a stunned you over to a plush red armchair that he just happened to bring down to the river, an armchair hand-embroidered with the words, “Codito ergo sum.”
Cristoforo Colombo (a.k.a Columbus) knew how to sail, navigate, sell a proposal. He was commissioned to find a new route to India. He didn’t find India. Fortunately for him and his career, he found something even more lucrative.
You’ve got skills, right? Coding skills, architectural skills, fried skills, skills gumbo, nun-chuck skills… But if you’re commissioned to write a piece of software that takes your stakeholders to India, how will they feel when they wind up somewhere in the Caribbean? You could pull a Columbus and try to convince yourself and everyone else that they really are in India:
You: “But this is India, I tell you! See? Look at those Indians. You there! Yes you, Indian! Come hither at once!” Stakeholder: Raises a doubtful eyebrow. Takes a long, exasperated breath. “Indian”: “Oye papi. ¿Sabe? Tu ta loco.”
The point is: you know how to code, but are you coding the right thing? How do you know? That’s where Specification by Example comes in.
In Part I of Read to Remember we discussed how SQ3R can help improve your reading retention, even up to 400% if you weren’t doing any sort of review or deep processing before.
Andy Hunt, in Refactor your Wetware, makes a strong case for incorporating mind-mapping into your learning regimen.
But how does mind-mapping help your brain? Isn’t it for grade-schoolers?