I had this thought this past week that we tend to believe that if we are in motion, we are accomplishing something. That being busy somehow equals being productive. And then I started thinking about how this is almost universal. It doesn’t just impact how we program, which I’ll get to eventually, but it impacts all of our life.
This probably doesn’t happen all that often, but this last week I came across the need to know which browser I was running my selenium test against. I figured that buried deep in the object structure of Selenium, there MUST be a way of finding out what browser I was currently running. As it turns out, I was right. The situation that caused this requirement is that the place where I’m currently writing most of my code is upgrading all the Firefox browsers. I was asked to make sure the code we were running still works with the new browser. When I did, I found that some of my tests broke even though the test itself still succeeds when it is run manually. In fact, they only broke when running against this new version of Firefox.
Over the past ten years, I’ve successfully implemented various types of screen scraping in order to provide data to my clients. Most of these implementations have involved accessing HTML and parsing out the data we needed for the web application.
My latest implementation of this made use of the HTML Agility Pack and managed to incorporate the e-Labels For Education site into the Labels For Education site. (No links, because the e-Labels program is being phased out.) Recently, I’ve been spending a lot of times on some site doing the same thing over and over again. But most of the sites I visit now implement some kind of AJAX so that doing a simple web request to a page without also loading and parsing the JavaScript ends up giving me a page with no useful data at all. Unlike the work I’ve done in the past where this was sufficient.
This, combined with my recent work implementing Jasmine unit test for JavaScript and running them in the PhantomJS headless browser has had me thinking, wouldn’t it be great if I could do similar kinds of screen scraping, or even browser automation, but use something like an embedded version of PhantomJS to get the work done.
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”
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.
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.”
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.
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.
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?
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,