Back on the Bike

Work has been overly busy lately, almost draining, as I’m in high season for maintenance.  With very little new work, it’s long been my challenge to keep motivated when switching from “hunter” to “farmer” mode.

Personally, we’ve had a rough streak as a family, too, having to endure now 12 funerals in the last nine months. This is one of the realities you have to face when you and your spouse have a close family, counting a combined (whopping) total of over 100 blood relatives, nearly all of which are older than you.  It’s been a sad couple of seasons at home.

Sweat to the Rescue

I have always found that getting my heart going helps to clear my mind.  I grew up being fairly active playing varsity high school sports and spent six years as a competitive swimmer.  I have cycled from Montreal to Banff on a national relay team benefitting Juvenile Diabetes and have put in over 7,000kms on the bike in the last three years.  But none in this calendar year.

I have always found that getting a bit of time to work the muscles and think through problems can help me make great strides.  In fact, I would argue that some of my best coding – or at least, solving some of my hardest programming challenges – has been away from the keyboard.

100kms and Counting

I’m no longer an ideal candidate for the swim team, nor did I fully grow to a size that any self-respecting volleyball team would give me anything other than bench time, but I do still have my road bike.  Technically, I still have my speedos too, but I’m not getting into those anytime soon! Winking smile

So my wife and I have reciprocally committed to exercise time and appropriate support for each other.  After supper, she heads out for a good brisk walk while the kids and I clean up supper.  When the kids head off to bed and she’s putting the baby down I’ve been jumping on my bike. 

In the last 4 days I’ve been increasing my kms and decreasing my time.  Last night I posted just over 26kms in a cool 54 minutes riding through the city, an average speed of about 29km/hr (18mph).

Today at work I started with more energy, cleaned off some outstanding maintenance issues and was rewarded by getting to spike out a new project out in WCF and WP7.

It’s amazing what a little exercise can do for you.

Adaptive Performance is Evil

I was working on tribute video for good friends of mine this last week using Adobe Premiere Pro CS4.  I have a brand-spanky-new laptop with some pretty rockin’ specs including an nVidia video card that chews through the video processing, for the most part, in real time and as fast as 5 times better.

But I couldn’t get that far into editing. Every minute to 90 seconds Premiere was crashing.

I was getting OpenGL errors, saying “A problem occurred when processing OpenGL commands”, or “Encoding Failed. Could not read from the source” or “The NVIDIA OpenGL driver detected a problem with the display driver and is unable to continue. The application must close”.  There was also one about “lost the connection to the device” and the error numbers from Adobe Premiere were error 4 and error 8.

The culprit? Adaptive Performance. It’s built into the GPU drive and by default turned on. It’s supposed to use less power and save the environment or something.

Turns out I hate planet Earth.

TURN ADAPTIVE PERFORMANCE OFF. At least for Premiere Pro.  If you go into the nVidia control panel you can actually adjust driver settings on a per-application basis (or globally set the feature’s status across the whole OS). Adaptive Performance is a feature that steps down the processing capabilities of your video card to conserve energy and then tries to crank the juice up when you need it.

Unfortunately this causes Adobe Premiere Pro to wig out.

So, turn it off and live happier.

A quick note: I found the solution to this on a gamer site when I was Binging the errors and I’m certain it was related to an OpenGL error. I would like to give attribution here but I don’t remember the name of the gaming community and can’t re-Bing the same results I was getting when I found the fix.

It's been a long, long Long Weekend

Thursday afternoon, as our family was preparing for our July long weekend, we received some terrible, terrible news.  Some of our closest friends’ daughter was killed in an accident on the highway; she was 17 years old.

She was driving up to her parents’ cabin at the lake to visit her mom and was killed instantly in a head-on collision.  Her boyfriend, travelling with her, also passed away.

Haven’t made much sense of things yet.  Because of the type of accident the autopsies had to be done in Winnipeg, about 2.5 hours from here.  As a result, the families won’t have their children back until late today or possibly tomorrow.

As a double whammy, we found out early Saturday that the driver of the other vehicle is another person close to us, an adopted aunt, of sorts, that has been in my wife’s family for years and years. We’ve eaten together every Christmas, Easter and Thanksgiving for the last 17 years (when I started dating my wife).  She’s now in the trauma unit with broken…everything…on life support and requiring many surgeries before she makes it out.  It is nothing short of miraculous that she’s come through this and she has such a long road ahead of her.

My birthday was on July 1, Canada Day.  My wife and kids and I took in the fireworks and had some good family time together, which helped to take our minds off the senselessness of it all.

Funerals are planned for Friday and Saturday for the kids.  We’ll be back and forth to Winnipeg to visit our friend as soon as they allow visitors.  It’s going to be a long week.

Running A Remote NuGet Feed

Following the NuGet docs site to setup a NuGet feed won’t get you one if you follow it (as of Jun 30). There’s one missing step in that doc (it’s here at the end of this one), but I’ve added all the steps below so you can walk through for yourself.

I’ve also created a fork and submitted a pull request to include the missing step, so the online docs should be updated soon.

Setting Up for Eventual Deployment

Create a new site in IIS. 

Edit the Application Pool and make sure the .NET Framework is set to version 4.

image

Get Your Project Together

Open Visual Studio in Administrator mode (right-click, Run as administrator).

Create a new, Empty Web Application project.

Open the Package Manager Console and at the PM> prompt, type

image

Let NuGet do it’s sweet, sweet, beautiful magic.

Right-click on your solution and select Open Folder in Windows Explorer. 

image

There is a packages directory there that has a half-dozen packages installed for you.  Go through your packages directory, and copy the .nupkg files to the clipboard, then return to Visual Studio and paste them in the Packages folder under your project. It only takes a moment to add a few. Again, you’re copying all the .nupkg files from your solution (file system) to the Packages directory in your project (Visual Studio).

image

Press CTRL+F5 and run the site. Click on the packages link and verify that your packages are in the feed.  Sweet.

Publish Your Feed

Close the browser and return to Visual Studio.  Select the project in Solution Explorer, then click on Build –> Publish from the menu.

image

This is why we ran as admin…we need to deploy to our local IIS.  If you’re logged in as admin you should get a successful publish.

Navigate to your site on localhost.

image

Unfortunately, at this point…our feed is empty. Click on the packages link:

image

Lamesauce.  Okay…so now to fix it. 

The Missing Step

Go check your packages directory to the published site.  Empty, ain’t it?

No worries…you have two choices here:

  1. Paste all your packages into the site directory (where IIS is looking)
  2. Change the build action on all your .nupkg files to “Content” and republish your site.

 

I was originally under the assumption that it was a permissions problem or a DLL version problem due to a couple of comments out on the interwebs.  When I had 5 minutes to look at things here this afternoon, it was quickly clear as to what the problem was. 

Hope this helps!

Do Your Like a Good Game of Rock, Paper, Scissors? In the Cloud?

My head is in the clouds.  I just played the most intense game of Rock, Paper, Scissors ever.  It was a “best of 1,999” format.  And my arm didn’t even get tired.  In fact, I played about 40 rounds of it, with 8 different competitors and by the end I was winning every match.

Folks, what I’m talking about is the Rock, Paper, Azure competition that Microsoft is hosting right now, and if you are in the least bit interested in the cloud this is a relaxed, fun way to get yourself started.  Plus: free t-shirts!  Learning cloud development and a free t-shirt? How can you not?!

What It Is

The game is hosted on the Azure platform and every participant has a chance to create an entry bot – the “player” used by the game engine to play out  your game.  You play every other registered player.  Each game is played to 1,000 wins, and the first to 1,000 gets 3 points to their name.  There are leaderboards, prizes and at the end of the practice rounds a Grand Tournament for the ultimate bragging rights.

What You’ll Really Learn

Now, this game isn’t so much about cloud development as it is to walk developers through the process of deployment.  The “bot” project – used to create your player in the game – is set up for you as part of the download.  All you have to do is write a bit of c#, vb or f# to determine what move your bot will play next, and you’re off the races. 

There is one catch: your bot can only be entered into the competition if it’s hosted in Azure.  Said another way, you have to deploy to the cloud to enter and win.  To get your Azure account (free trial) you can visit the getting started page for the contest.

Having Some Fun

Brace yourself, because you may not know this: RPS is serious game.  Seriously.  There are international organizations, widely accepted rules and derivatives, annual competitions with big prize money and the works.

In light of all this seriousness, you can still have fun with this competition.  You just have to remember that a “random” throw isn’t going to get you anywhere.  In my testing, even a bot that favors a particular throw does better than a random bot.

(Really) Getting Started

Once you get through the guide and get yourself running, you’re going to want to get some bots in your local Azure emulator so that you can test strategy.  If you’re only working in one language, simply remove the other projects from your solution (I work in c#).

Other bot developers aren’t going to give you their bots, but you can easily create some pseudo-strategies to make sure you don’t fail in the simplest of cases.  Point in case: an early version of a bot I was making won every time against every bot in my lab, except the bot that through mostly scissors.

So, let’s get started.

  1. Open the BotLab solution with Visual Studio running as Administrator and run the app.  While the Azure fabric is getting going, we’ll create some bots to unleash fury in the lab.
  2. imageOpen the MyBot solution in a new VS instance (you don’t need to be admin here). Build the app by pressing Shift+Ctrl+B. Right-click on the project folder and click “Open Folder in Windows Explorer”.  Here, along with your bin, obj, and properties folders, create a “bots” folder.
  3. Now, back in Visual Studio, imageopen the Properties of your project and navigate to the Build Events tab.  We need to add a new post-build event similar to “copy $(TargetPath) $(ProjectDir)\bots\”.  This will copy our built bot to a bot folder every time we build one.  We’re using this as a technique to build a quick army of bots. Every time we build, our target dir gets cleared, so we want to have a bit of a locker to keep them penned in and out of harm’s way.
  4. Next, go back to the Application tab inside your project properties.  Change the Assembly name to “ScissorBot”.  When you build your app again (Shift+Ctrl+B) your ScissorBot dll will be copied to the bots folder.

Now we’re ready to get some bots together.

Building Some Bots

Go to the MyBot class and you’ll see that we inherit from IRockPaperScissorsBot, which ultimately inherits from IBot.  We have but one responsibility to fill with this contract: MakeMove.

We want to create some bots that will just favor certain moves.  This isn’t likely a strategy that another bot maker will employ, but if by chance they do favor a move, you’ll know that you can fare fairly well against them.  Wow. I don’t think I’ve ever used “fare” and “fairly” side be each before.

Replace the meat of your MakeMove function with the following code:

image

This little guy has an affection for sharp things and will throw scissors better than half the time.  Build your app and make sure the DLL is in your bots directory.

Now do the following:

  1. Change the Assembly name in your project settings to PaperBot.
  2. Modify the above code above to favor paper.
  3. Build your app and make sure PaperBot’s in that bots folder too.
  4. Do steps 1-3 over for RockBot.  Queue epic guitar solo.

 

Now you have some competition…they’re not great, but they’ll give you a fighting chance if your bot can survive against them.

Testing out the BotLab

Now we get to see how things play out. Pop back over the browser that is running the BotLab. You’ll see a window there with a few sample bots in inventory.  Use the form there to select and add the bots you’ve just created. It should look something like this when you’re done:

image

Next, click the “Start Battle!” button and let the rain fall. All bots in the lab will square off against each other and the results will be tabulated for you.  By the way, note how far down the list the Random bot is.

image

Clicking on a bot brings up the game log in a little modal dialog that lets you see how things transpired.  In this way, you can review the details of the way you played and how you won (or lost) as well (or as badly) as you did. This is how I came to discover that when one of my bots was getting into trouble, it panicked and started throwing water balloons.

I do want to point out an interesting thing here that is part of the game rules and critical to winning:

image

Notice that after BigBang has gone up 10-0 there are two draws (ties) and then PaperBot wins?  The points accumulate through a tie, so PaperBot was awarded three points when Scissors cut Paper.  Which brings us to some strategy.

Some Strategy

What if you knew that the points were accumulating?  Well you can. Your class, one instantiated, is stateful for the duration of the game. You can have member fields that hold values and therefore can track some things to gain an advantage.  Using this tip from the RockPaperAzure blog, we are able to build a Dynamite-favoring bot that simply OWNs the competition.  Rename your assembly and modify your bot’s class to the following:

image

Now we’re combining strategies: if we have a tie on the line worth three or more points we’re going to throw Dynamite. If not, we’re favoring a throw (paper).  Now when we check our results we see the following:

image

DynaBot wins every time I run this.  The one mark in the loss column is always against ScissorBot.

Time for some smarts!

Making the Bot a Little Smarter

So, here’s the deal: I want to have a sporting chance in this competition, but I want to throw out some ideas as to approaches you can take to help you win too.  I’ll give you the ideas (and some code) and you work out the details.  I’ll help you with the code once the competition is done Smile.

The first thing I did was start to keep track of the last 20 moves of the other player. This is easily done by adding a Queue<Move> to our class.

image

Next, I moved my _pointsOnTheLine logic to an UpdateStats method.  That’s also where I’ll keep track of the _lastPlays Queue.

image

Now I have the ability to do a bit of analysis on the opponent’s moves.

Next, I wanted an easy flag to see if I was currently winning in the game.  This lets me switch between offensive and defensive strategies. I started by creating a variable that allows me to just check a bool anywhere else in my code.  This is a class-level field.

image

Then, in my UpdateStats method, I do the check:

image

Finally, I wanted a way to set up a playbook.  I created a series of List<Move> collections that easily let me pick my next few moves.  Some examples of that are as follows:

image

To use these moves, I simply created a class-level queue…

image

…and test to see if it’s empty. If it is, I can load up a few plays rather easily…

image

Get it?  If I’m “WINNING”, I foreach over “the Avalance” and add them to the queue.  Finally, I can pop my results back off the queue easily and make plays from my populated playbook:

image

The last thing I did was to create a simple function that returns the throw that beats whatever you pass in.

image

Part of the stats I keep watching for a mirroring strategy (where the other bot just plays whatever I just played).  Now I can easily throw back at the mirror and guarantee a win:

image

Now, obviously I’m not giving away all my secrets here, but you can use strategies similar to this to get the ball rolling.  I wrote three really good bots with different strategies…in a list of 20 bots I created, one of these three always won.  Now, I’m working on the bot that can beat all the bots in my arsenal.

Next Steps

All that’s left to do is deploy your bot to the cloud. Head over to the game site and watch the video on deployment; that is, after all the point of this game: to see how easy it is to deploy a project to the cloud.  When you’ve finished deploying, you can then enter the contest and start kicking bot butt!

Good luck!

HTML5 Boot Camp in Winnipeg

I just had the privilege and pleasure of speaking at the HTML5 Boot Camp Extravaganza in Winnipeg at the Delta Hotel.  The event was hosted and organized by Microsoft Partner of the Year Imaginet and sponsored by Microsoft.  There were prizes for all attendees as well as breakfast, lunch and snacks…not to mention great conversation!

Post-Camp Connection

You can get in touch with any of the presenters through the links below:

David Wesst – blog, twitter Kelly Cassidy – blog, twitter Tyler Doerksen – blog, twitter and me!  James Chambers – blog (you’re already here!), twitter

Hey, what was that site where….?

We covered a ton of content and flew through all kinds of territory.  Here’s some of the links, tools and technologies we covered:

There’s a ton out there, but if you’re looking for something in particular don’t hesitate to ask. 

Thanks, Winnipeg, for participating in this event.  We had 50 folks of all levels of experience in the room, which made for some great questions.  I really enjoyed the format – tandem presentations with lots of dialogue – and hope that you guys did too.

See you at the SIG meetings in the ‘Peg over the next few months!