It amazes me how rare the skill of debugging software is. It is even more amazing to me that after programming for over 27 years now, I still have trouble with this. So, as a checklist for myself, and as a possible help to others along the way, I offer you “How to Debug Your Code”
Dave's Notebook
JavaScript Scope
If you’ve been programming in any other environment than JavaScript for a while, you may be making assumptions about JavaScript Scope that just aren’t true. One of those assumptions is how variables get evaluated when you run the JavaScript code and what variables are visible and at what point in the code they are visible.
Just as a test to see how well you know your JavaScript, let’s create a few tests scenarios.
Why Is It Called “Inversion of Control”?
There is a guy I’m working with who is trying to wrap his head around design principles. He’s been watching a lot of PluralSight videos. As he was processing information about Inversion of Control, he asked the natural question I’ve never actually considered before. “Why is it called Inversion of Control? Normally, when you talk about ‘Inversion’ you are talking about reversing something or negating something. That isn’t what we are doing here.”
The Parable of The Road Line Painter
Way back in the day when lines were first being painted on roads. The early lines were painted by hand. In those days, a painter was hired and given a stretch of road to paint. The first day he got on very well. In fact, he was one of the best line painters they had ever had. His lines were perfectly aligned, there were no unpainted areas in the space where there should be paint, and he managed to get 500 yards of road painted. The average line painter normally did 250 yards in the first day. The managers who had hired him were quite pleased.
Setting up SpecFlow
I’ve been asked to train a group of developers in the use of SpecFlow so that they can use it to write Selenium Tests. So, in an attempt to “kill two birds with one stone” I thought today’s post would cover how to get the SpecFlow environment setup. Not only will it help me prepare for the training session I will be leading, but it will help me when I need to set this up the next time because it tends to be a bit confusing when you setup a new project. You’ll see why in a bit.
Installing SpecFlow
Code Comments & Agile Programming
A long time ago, in a galaxy far far away, we were forced to name variables and methods with very short names. When I started my career, I was programming Clipper and C. Clipper was a dBase compiler, so it only had 10 characters available for variable names. You could write longer variable names if you wanted, but only the first 10 mattered. I think at the time, C gave us 32 characters. But now, we aren’t so limited. And so the argument goes, if you use long variable names, you shouldn’t need to comment your code. I’ve argued as much.
Of course every time you bring this subject up, you will inevitably find someone who will say, “But don’t we need comments to at least explain what the code was supposed to do? After all, code is generally hard to read.” Well, yes I guess it is if you are new to the language. But should every foreign movie have subtitles? Would you want native language movies to have subtitles because other people in the room might not understand it? Must we dumb everything down to the lowest common denominator? If so, where will it stop?
Cracking the Programmer's Interview Code
Several comments this week contribute to this week’s post.
The first, and the one that pushed me to write this post, is a discussion over at Simple Programmer on a post called “Cracking the Coding Interview” where I made the following statement,
Run NUnit from Visual Studio
For the purposes of this post, I’m going to assume that you already have the NUnit Test Runner installed. The question you are looking to get answered is, “How do I run NUnit from Visual Studio” or even more importantly, “How do I DEBUG NUnit test from Visual Studio”. The following step by step should help you.
Right click on the project in Solution Explorer that represents your test project.
From the resulting menu, select “Properties.” In the resulting window, select the “Debug” tab from the left-hand side of the window.
You will want to select “Start external program” and point it to the UNnit runner that got installed when you installed NUnit.
Now, whenever you run this project, with or without the debugger, NUnit will start up.
Note: there is no reason to pass parameters telling it what DLL you want to run because it will load the last DLL it had up.
But, if you wanted to do that, you could pass the location of the DLL as a parameter to the GUI runner.
There are other parameters you can use.
TDD Gamification - Turning Test Driven Development into a Game
When I was in college, there were some guys I hung out with who played this game called “Questions” which they got from some book. Actually, it was a play. Anyhow, the basic rules are:
- You can’t answer a question with a statement
- You can’t hesitate or make a false start
- You can’t repeat a question that has already been used
- You can’t ask a rhetorical question
- You can’t ask an unrelated question.
There was also this podcast at DotNetRocks where they were talking about a beer app and how they had added game elements to the app by adding badges for various types of beer to get you out of your comfort zone. Maybe there is one for “My first beer that I liked” because I’ve yet to find something I like. But give me a good Merlot! All of this got me to thinking about how we might turn Test Driven Development into something of a game. There are several people who have already addressed the Gamification of TDD
How to Become a Better Programmer
As you advance in your career, you will inevitably want to improve as a programmer. And as you search the Internet and read various web post on the subject you will also inevitably end up with a bunch of task you should perform that will make you better. For example, if you’ve been following this blog lately, you’ll notice that I’m a big proponent of Test Driven Development. You would naturally expect me to state that to be a better programmer, you should practice Test Driven Development. There has also been a lot of emphasis recently on good basic programming principles like DRY and SOLID. The list could go on. Here are a few you may be interested in experimenting with:
- Code Reviews
- Paired Programming
- Learn and Implement Design Patterns
- Reduce Method/Class Complexity
- Practice Code Katas
- Participate in the Community
- Start a Blog
- Participate on StackOverflow
- Read and Comment on other people’s Blogs
And while all of these and more are good ideas, none of these ideas will actually MAKE you a better programmer. Why? Because becoming a better programmer is mostly about becoming a better person.