One summer in high school, I had a mandate from my parents to get a job. If I was going to work thirty-plus hours a week, I wanted more than minimum wage. Growing up in Orlando, Disney World was an attractive place for teenagers to work during the summer. They paid a whole $1.10 over minimum wage ($4.25 at the time, for a whopping $5.35).

In the end, my illustrious career working for The Mouse didn’t last long. I quit after four days (that’s a story for another time). But during that time I learned two valuable lessons:

1. Some days your boss is The Mouse, some days your boss is “The Rat”. (I had The Rat unfortunately).
2. The customer may not always be right, but they’re still our customer.

 Software customers

Working in software development, there is always a customer. Sometimes it is an actual paying customer, other times it’s another department within the company. Both types of

A few years into my career, I noticed I was only working with the (even then) outdated “classic” ASP. I certainly did not want to work with ASP forever. This .NET thing was new and cool, and it seemed to fix 90% of my complaints with classic ASP. My company had various projects underway. One was a rather large (and important) Java project. I pulled a few strings and got put on the project.

I few things I should note: I would have preferred a .NET project at the time, but the company didn’t have one (I don’t recall if there wasn’t one, or just one that I could be placed on). I had done some work with Java back in college, yet I was worried it wouldn’t be smooth transition. I had worked exclusively with ASP and Visual Basic 6 (VB6) since college, and felt comfortable with those languages. In addition, .NET had VB.Net, the successor to VB6. Taking up Java at this time seemed a little

As I prepared to give a presentation tomorrow night, I stumbled upon a great article explaining how to setup Visual Studio for a “presentation mode.” Presentation Mode are the font sizes required so the folks sitting in the back row don’t repeatedly say “can you zoom in a little?”

I’ve written about presentations before, but failed to go into any detail about configuring your IDE of choice. Mine for tomorrow will be Visual Studio. Since it’s been a while since I’ve presented, I didn’t quite remember the required settings to change the fonts. And Visual Studio has a lot of settings:

Thankfully, I found the article I mentioned above, and saved myself a small fortune of time trying to find and toggle all the correct settings. I’ve perfected the following quick process for my presentations.

 4 simple steps to a better presentation

Step 1: Download this Visual Studio settings files

Step

 Playing the game

Like any many fixed systems, the supposedly fair system of user reviews is horribly broken. The process was ripe for gaming. And gamed it has been. Companies optimize their apps and websites to get you to leave ★★★★★ reviews. EA, with their Dungeon Keeper on mobile platforms has optimized this to the extreme:

Clicking “5 Stars” take you to the store to give that ★★★★★ rating. While clicking “1-4 Stars”…

Emails, as far as I know, don’t show up as app store reviews. Instead, you get ushered away from app store to some back room where no one knows what was said. That, in theory, leads to more ★★★★★ reviews and a higher score. EA’s tactic may have gone unnoticed if it wasn’t for other issues with the game.

 “Beating” the system

Less than satisfied users on the other hand, in response to all the ★★★★★ reviews, or perhaps just in anger and spite, leave ★ reviews and

I started a new project at work a few months ago. Literally, a new project, as in File -> New Project. It was very liberating (and scary) to not worry about the company’s main code base that was 10+ years old. While in decent shape, nothing that old is going to be without problems. I call those problems technical debt. (You also don’t get all the niceties and helpers that someone else has spent 10 years perfecting, but I digress).

Like any project, my new project started accruing technical debt. I was faced with the decision that every project is: pay back the debt or build shippable (and thus profitable) features. Most projects choose the latter. That’s probably the right decision in some cases. But being scared that one day the new project would be the old project, I couldn’t live with the decisions made weeks earlier. They didn’t sit right with me.

The other developer and I decided

 Update

Google Authenticator no handles this situation correctly, and this article is less useful than it once was.

 Original Article

Microsoft recently added two factor authentication. You should add this to your account. It’s a good thing.

I recently tried on my Android phone to scan the barcode, but it wasn’t working. My co-workers and I figured out that the Google accounts we already had setup on the Android authenticator app shared the same email address. Both Google and Microsoft were using that for their account name, so the second account wasn’t being added.

To get around this, I manually added the account and gave it a name other than my email address. I now have notmyrealemail@gmail.com“ for Google and "Microsoft” for Microsoft.

If you use Visual Studio, you don’t get integration with version control unless you use Team Foundation Server or install a plugin.
This is an adaptation of this fantastic guide, originally written for TortoiseSVN. This guide also works for git (or any version control system), just change the commands.

 Creating External Tool entries

The first step to setting up the integration is to create external tool entries for the various commands you’d like to launch from Visual Studio. Using the following steps, you’ll have one or more hg commands at your disposal.

1. Go to “Tools -> External Tools” menu item.
2. Click “Add”.
3. Name the tool in the “Title” textbox. I’ve chosen “hg annotate”, “hg diff”, and “hg log”.
4. In the “Command” textbox, put the path to TortoiseHg, typically “C:\Program Files\TortoiseHg\thg.exe”
5. Fill out the proper arguments. The $(ItemPath) variable points to the current file

As browsers become more and more capable, and JavaScript proliferates to all corners of the software development world, it was only a matter of time before we saw the rise of JavaScript game libraries.

A library that caught my eye recently was Crafty. Crafty embraces common JavaScript practices and patterns that not only make HTML5 games simple to write, but a joy to code.

 The basics

First, you must define a “viewport” for the game to run in. Crafty supports both the newer <canvas> element, as well a plain old <div> elements for less compliant browsers. To define a viewport, you only need to make a single call:

Crafty.init(600, 400);

Crafty uses an “Entity Component System”. Basically, each “thing”, be it the player, an enemy, a bullet, a platform, or even the score, is a simple object that has one or more attributes attached to it. Instead of inheriting a bunch of classes or

I’ve long maintained that the hardest errors to find in a software application are those of omission. Omissions can be many things, but ultimately are missing data that was not noticed or changes in functionality that did not occur. Depending on your application, missing data or functionality can be annoying, costly, or worse.

 If it doesn’t happen, it’s not an error, right?

When determining how to test an application, you often test based on what you expect the application to do. It’s a very reasonable approach, right? Given some input A, expect result B. You’re happy and move on. But what about C? It doesn’t always occur – should it have occurred when B occurred? How can you be sure? In fact, there are probably conditions when C should not occur. This just got complicated.

 How do you find something that’s not there?

Sometimes the volume of data is overwhelming. Imagine verifying