Targeting a Project in a Solution Folder in MSBuild

Normally, when you invoke the MSBuild task to build a solution file, you can just add TARGETS=”ProjectName”, where ProjectName is just the name of the project, and don’t include the .csproj extension.

I already knew that if your project name includes a period, you need to replace that with an underscore (so the project “MySite.Web” becomes “MySite_Web”).

But the UnitTests project kept coming up as not a known build target name.

Finally, I found my answer in a comment in the answer to “specify project file of a solution using msbuild” on Stack Overflow.

Turns out that when a project appears in a solution folder (as opposed to just being in a directory), you need to include the name of the solution folder, and a backslash. So since the UnitTests project is in the UnitTests solution folder, the MSBuild invocation ends up looking like this:

<MSBuild
    Projects="$(SourceLocation)\$(SolutionName)"
    Properties="Configuration=Release; Platform=Any CPU; OutDir=$(OutputFolder)Assemblies\; WarningLevel=0;" 
    Targets="UnitTests\UnitTests" />

Random Memories of Shakespeare

A Random Memory…

In my mid-twenties, I spent six years living at Lake Tahoe. Literally within a half-mile of the beach. Every summer, I would Volunteer at first the Music at Sand Harbor festival, and then a month later, at the Shakespeare at Sand Harbor Festival. A set of events taking place in the dunes at the Sand Harbor Lake Tahoe Nevada State Park. (The latter event is still around as The Lake Tahoe Shakespeare Festival).

I would work every night at both festivals as one of the security Volunteers. They called it “Security”, but it was really ushering. We were mainly concerned with helping people find a spot for their blanket and then keeping them from going into the environmentally sensitive parts of the dunes. Since I was there every night, and people somehow got the idea I was responsible, after a year or two, I was put in charge of security for both events. Which mainly meant getting there early so I could drag a shovel through the sand to mark where the aisles would go.

People tended to Volunteer for a few nights, so you’d get to know one another. One Volunteer I recall was a young woman named Ashley. She’d arrived early one Saturday and after we’d drawn the aisles, we had some time to kill. I looked at the aisles and commented, “Y’know, those aisles would be a lot easier for folks to see if we marked them with a rope.” Ashley agreed that was probably true, so I asked, “Would you go over to the lifeguard station and ask if we could borrow about 200 feet of shore line?”

Ashley came back about 20 minutes later to report that the lifeguard didn’t have that much available and had suggested she try the park office.

Sadly, the whole thing fell apart at that point because I couldn’t keep a straight face any longer.

(Image by Wikipedia user DimiTalen, used under Creative Commons Attribution-Share Alike 3.0 Unported)

They Keep Killing Glenn

The usual rule with a scandal is that when it first breaks, you start off with the angry denials. This goes on for a few weeks, with increasingly intense press coverage, until at last you get to the next stage, the tearful confession. Well, let’s skip over all that and go straight to the part where the accused becomes the prosecution’s star witness and throws his co-conspirators under the bus in exchange for leniency….

At the 2017 Farpoint convention, I attended the panel for Crazy 8 Press. As nearly as I can remember, most of the Crazy 8 authors were present: Peter David, Robert Greenberger, Michael Jan Friedman, Russ Colchamiro, Aaron Rosenberg and Glenn Hauman. Only Paul Kupperberg was missing (Mary Fan hadn’t yet joined the collective). Kathleen David was sitting in the audience.

The panel started off with comments that the group is looking for ways to boost their book sales, with some dark humor thrown in about how Peter’s book sales skyrocketed after his stroke several years ago. So naturally the question was raised of who was willing to “take one for the team” and boost book sales by having a stroke.

Somewhere in there, the suggestion came up, “Maybe we need to kill someone” to which Glenn replied, “We’re writers. We’re always planning to kill people.” My recollection is that it was Aaron who responded, “Yes, but it’s usually you.” Pandemonium ensued as one author after another took turns suggesting ways Glenn might die.

In short order, they decided to publish an anthology of short stories in which Glenn would die. Once Peter announced the title should be, They Keep Killing Glenn, I knew what I had to do. I pulled $20 from my wallet, marched to the front of the room, and offered it as my contribution to the expected Kickstarter campaign.

And that’s why Glenn says it’s my fault the book was written.


This next part kind of boggles my mind. They Keep Killing Glenn is now available, and this is the list of authors from the book’s back cover

I mean, look at that list of names:

David Gerrold – that’s the guy who wrote one of the most popular Star Trek episodes ever, The Trouble with Tribbles.

David Mack, Robert Greenberger, Peter David, Michael Jan Friedman, Keith R. A. DeCandido – These are Big Names in the world of Star Trek writers. They’ve all been on the New York Times best sellers list. Multiple times.

Paul Kupperberg – that’s another Big Name. He’s the guy who writes the current incarnation of the Archie comics.

As far as I can tell, almost everyone else on that list has been published multiple times and most of them have authored multiple books.

And then there’s that name circled in red. Blair Learn. What’s that name doing there?

Most of what I write is software documentation, describing how the pieces fit together, explaining processes to other developers. And yet somehow, a story I wrote has been included in an anthology with all those big names.

In February of this year, they announced that yes, they really were going to publish the book. And in addition to gathering submissions from professional authors, they were also going to accept up to three submissions from fans. I’ve spent a little time chatting with Glenn over the past several years, and having a story published professionally has been an entry on my bucket list for a while… So I submitted a story titled “R is for Roadster.”

They Keep Killing Glenn will be debuting next month at the Shore Leave science fiction convention, just outside Baltimore. But you can order it from Amazon right now.

George Romero and Monroeville Mall

I’m not really into the horror genre, but in college, I do remember watching the original Dawn of the Dead and laughing at the various scenes shot in Monroeville Mall. I particularly remember watching the heroes drive cars around the lower level and thinking that must have been fun. And, of course, the scene on the ice rink – I grew up in that area and remember skating on that rink. Seeing it used for “zombie hockey” was an odd experience.

For whatever reason, the Twitters dropped a link on me today: it seems a group of fans is putting up a bronze bust of George Romero at the mall.

There’s also a mention of a footbridge from the mall being preserved at the Heinz History Center. I have some vague memories of that bridge. The article includes a link to a story KDKA did in 2015, talking about the bridge’s removal, complete with scenes from the movie and people dressed up as zombies helping to load the bridge pieces into a van. According to the news story, there were plans to put it on exhibit sometime this year.

Photo by flickr user daveynin, used under Creative Commons Attribution 2.0 Generic (CC BY 2.0)

Triumph Bonneville Tail Light Bulb

As much so I can find this again as anything else… A 2014 Triumph Bonneville (doesn’t seem to matter which trim package), uses an 1157 bulb for the tail light / brake light. This is single bulb, with two filaments. The similarly-sized 1156 bulb only has one filament and most likely won’t work with that socket.

The bulb is easily available at any auto parts store.

Also, jpcycles.com has a handy little parts finder.

Panera Bread and What To Do Next

What Happened?

I’m pretty sure most folks go to Panera Bread from time-to-time. Sadly, they have the dubious honor of being the latest big data breach. Worse, they seem to be a pretty good example of how NOT to handle this sort of thing. As near as I can tell from the reports so far, you’re impacted if (A) you have a Panera Bread loyalty card (that includes “I just give them my phone number and they look it up”) or (B) you bought any kind of pre-paid card.

The reports so far seem to say the breach includes names, usernames, email addresses, physical addresses, loyalty card numbers and the last four digits of credit card numbers for probably 37 million people.

Two sources of information:

The place where this gets bad is that Panera was reportedly alerted to the problem with their web site eight months ago and did nothing about it. Houlihan finally got tired of waiting for them to do something and that’s when he passed the story to Krebs. (For comparison, at my workplace, we generally have to fix security problems less serious than this one in under a week.)

Krebs broke the story on Monday, April 2, after first letting Panera know what he was about to publish. They took their web site down and two hours later announced to the world that the problem was fixed and had only affected about 10,000 people

Except they didn’t actually fix it. It doesn’t sound like they even put much of a band aid on it. Following Brian Krebs’ twitter stream from that day is illuminating.

So, as I write this, PaneraBread.com is offline.

That’s the quick and dirty summary.

What do I do about it?

That’s a tough question. I haven’t seen anything yet about passwords being part of the breach, but if you had a login on any of Panera’s web sites, you should think long and hard about whether you may have used that same password anywhere else. If you think you may have, you should go change the password on that other site just to be sure.

(As a semi-side note, here’s my quick password rules.)

One part that’s somewhat concerning is that the breach includes the last four digits of credit cards. That’s not enough to actually use the credit card, but there are a lot of things online where knowing someone’s name and the last four digits of their credit card number is enough information to “prove” you’re that person. (There was a somewhat famous case a few years back where a tech journalist had his PC and iPad wiped after someone got hold of that information.) So you may need to think about getting credit cards reissued (the banks lately have been a bit more proactive about that, so you may get one anyhow).

One other thing you might consider is signing up on the web site https://haveibeenpwned.com (yeah, it’s a funny name). That’s a free online tool (you don’t even need to set up a password), where you can find out if your email address has ever appeared in any of these big data breaches. More interestingly, you can also sign up (again, no password), to get an alert if your email address shows up in any future breaches. (I use this feature to monitor the domains my parents, wife and I use, but it also works for individual email addresses.)

Why would you want to know about breaches? Aside from being a way to find out when your information is exposed, a lot of the breaches you hear about in the news (and a lot of the ones you don’t hear about) include not just an email address, but also a password. And once the bad guys find out how to login as you one system, they try again on other systems (e.g. banks). And with the huge number of passwords most people need to remember these days, there’s an unfortunate tendency to re-use them.

Password rules

Some very basic rules for managing your passwords:

  1. Don’t even think about using “password” as your password. That’s the number one most used password in the world.
  2. Consider using a password manager. No one will ever guess that your password is qwb5Qauz36H9Kleqyotx and with a password manager, you won’t have to remember it.
  3. If you must use a password you can remember, at least use a passphrase. “SixSillySwansSangSonnets” is much more secure than “Tr0ubad0r” (and a darn sight easier to remember the correct spelling).
  4. Never, ever, ever use the same password on two different sites. In short: if one site has a breach and the bad guys get hold of your username and password, they’re going to try using them on other sites as well.
  5. Faithfully following those rules doesn’t guarantee that none of your accounts will ever get hacked, too much of that’s out of your hands. But they’re a solid start and they’ll definitely help limit the damage.

    A non-technical relative admits to not understanding why people would use a password manager. Couldn’t someone just hack your password manager?

    Yes. That could potentially happen. The aforementioned password rules also apply when setting the password for your password manager.

    And you have to ask yourself, which system is more secure? A well-vetted, “battle tested” password manager (and I’m referring to the likes of LastPass, 1Password, or KeePass), storing passwords which are composed of 20 random letters and numbers? Or just using the site’s name with a couple letters and maybe a number?

    And which is easier? Keeping track of a single strong password for the password manager? Or trying to remember what password you used for 30, 40, or more different web sites? (Hint: you’re gonna remember the Six Silly Swans example for a long time.) The main reason people re-use passwords is that they need to keep track of so doggone many of them!

    The idea behind a password manager is that you only have to remember one really good password, and then the password manager remembers the rest of them.

    And the good password managers (I personally use LastPass and KeePass) use heavy-duty encryption. If you use a good password, it’s extraordinarily unlikely that anyone’s going to break into your password manager by brute-force guessing.

    (Image via Life of Pix on Pexels.com under Creative Commons 1.0 Universal)

Finding Your Router’s Public IP Address

It’s easy enough to find your home router’s public facing IP address (the one your ISP assigns) via a Google search; they even make it the first result on the page. But what if you want to find it via a script?

That’s the challenge I’m trying to solve. What’s more, I want to do this without calling something on an external service. I’ll only be looking it up once every five minutes or so, but I’d prefer to not be a nuisance. (And if something goes wrong and my script runs in a tight loop, I’d rather not have the polling hammer someone else’s server.)

I found a script on the Linux & Things blog which almost does what I want. That script doesn’t quite work for me though, my route command doesn’t flag the default gateway.

But that’s OK, the bulk of what that script does is to look up the local network’s name for the router. That’s a nice bit of robustness, just in case the router’s name does change for some reason (e.g. switching from Fios to Comcast, you’d get a new router and the new router would likely have a different default name). But for my purposes, it’s good enough to know that the router’s name is always going to be Fred. (No, not really, that would be silly. My router’s real name is Ethel.)

So from a bash prompt, we end up with this snippet of code:

external_address=$(nslookup Fred.home | grep Address | tail -1 | awk ‘{print $2}’)

That one-liner really breaks down to five parts.

nslookup Fred.home looks up Fred’s entry in the local DNS. What I get is something similar to:

Server: 192.168.1.1
Address: 192.168.1.1#53

Name: Fred.home
Address: 192.168.1.1
Name: Fred.home
Address: 172.217.8.14

Now none of that’s my real network information, but what we’re after is that last “Address” line.

Piping the output of nslookup through grep Address throws away every line which doesn’t contain the word “Address”, leaving this:

Address:        192.168.1.1#53
Address: 192.168.1.1
Address: 172.217.8.14

Getting closer, next, it gets piped through tail -1 which grabs just the last line:

Address: 172.217.8.14

Excellent! That’s almost what we want.

The next step in the chain is to run it through awk '{print $2}' which uses the AWK tool to output just the second token in the stream.

Finally, the entire thing is wrapped in the $() operator, which captures the output of those four steps and allows us to assign them to the

external_address

variable, which allows the external address to be used elsewhere:

external_address=$(nslookup Fred.home | grep Address | tail -1 | awk ‘{print $2}’)
echo $external_address
172.217.8.14

This (obviously) runs at a bash prompt. I’ve tried it out on Ubuntu and the Windows Subsystem for Linux, though I can’t imagine it wouldn’t work on other distributions as well. Most of the magic in this is text parsing. The Windows version of nslookup provides similar output, just formatted differently; there’s no reason a PowerShell script couldn’t do some similar processing to find the address.

Rubber Duck Debugging

A co-worker asked me a question relating to how our software works. As soon as he finished framing the question, and before I could respond, he finished with, “Oh, of course…” and answered his own question. I don’t there’s a techie alive who hasn’t experienced this phenomenon from one side or the other.

There’s a practice called “Rubber Duck Debugging.” In a nutshell, when you have a problem, you explain the problem to the duck so that you can figure it out.

Coincidentally, there’s a rubber duck on top of a bookcase next to my desk. This co-worker and I had gone through similar debugging episodes before, so I told him that going forward, he should first talk to the duck. This particular co-worker works remotely most of the week, so I told him we’d have to find a way he could talk to the duck online.

Sure enough, someone else had already thought of this. Five minutes later, I found the Cyberduck – an Eliza-based chatbot.

Two Git bookmarks

I follow Mark Hamill on Twitter because I find him entertaining. For example, this exchange:

On the other hand, I primarily follow Scott Hanselman because he drops interesting tech nuggets, such as when he retweeted this:

Don’t get me wrong, Scott can be entertaining too, but the git config linked from that tweet is full of things I didn’t even know you could configure! (Six months in, I’m still finding entirely new realms within git that I didn’t realize I didn’t know about!)

Seeing the config sections for the merge and diff tools, I also verified that yes, the bc merge/diff tool referenced in the git documentation really is (or at least, can be) Beyond Compare. I’ve been using TortiseGit for my Git GUI needs, but I also like Beyond Compare. (The default vi-based diff tool is just painful.)

And then I find an article about how to configure Beyond Compare to work with Git.