BeeBot Makes his Debut

Today I had a really great opportunity to see my daughter in action. She had a special show-and-share day in her kindergarten class, and the item she wanted to show off was a robot that she and I designed, programmed and built.
That’s right.  She’s in kindergarten.  And she helped me design and build a robot.  Now for a little backstory.  About three months ago, my daughter came to me and said “Daddy, I want to build a robot.”  How could I possibly deny that dream?  I had picked up an Arduino Uno board a few months prior and had set up some basic projects, but nothing quite like a robot.  This was going to give me a chance to work with the Arduino controller more, and incorporate a Raspberry Pi, which was another device I wanted to get some experience with.  Not to mention the greater opportunity of having a daddy-daughter tech project.
The first thing we did was go through requirements gathering and design.  Heavy stuff for a six year old, I know, but I tried to keep it light.  I asked her to grab a piece of paper and something to draw/write with.  We started by talking about what she would want the robot to do.  Should it talk?  Should it move?  Were there specific “look and feel” items she wanted (i.e. different colored buttons, number of wheels)?  I let her go through her wish list of features and once complete, we ran back through it to see what was going to make the cut.  A few things got knocked out simply due to complexity, as I was planning on coding this in the Arduino IDE initially.  Plus, I wasn’t sure exactly what type of parts I would be able to get and I wanted to keep the requirements in a place where they were realistic.  I also asked her to draw what she thought the robot would look like once it was all done.

Figure 1 – Requirements and Design

Next I set out to find anything I could that would help achieve the goals set forth on the list.  I ended up getting:

• A Raspberry Pi B+ (I would later swap this out for my Raspberry Pi 2 for reasons I’ll include in my technical follow-up to this post)
• A SainSmart L293D motor control shield
• Several micro servos
• A ton of solderless wires (male/male, male/female and female/female)
• A 3.5″ LCD screen that ended up being a dud – later replaced by an Adafruit compatible screen intended for an Esplora device
• Four colored pushbuttons that were special ordered from China
• A four-wheel motorized car base that came with a clear acrylic frame and four DC motors
• A yellow bucket for the body

…and other assorted parts.  Again, more to follow in the technical follow-up post.  We worked together on deciding how to make things works, from how the arms moved to what the buttons would do, how the eyes would work, etc.  We recorded distorted voiceovers for the robot to correspond with each of the buttons.  She drew up pictures that would serve as the mouth for the robot depending on what button was pressed.  Then, some dad magic ensued, and today’s presentation seemed to keep everyone interested.

A closeup of Team Garverick.

The finished product (along with my Surface Pro).

Apache Cordova Demo is LIVE!

Yesterday I was fortunate enough to have my Apache Cordova demo go live on the main Channel9 website.  The demo covers setting up builds on all major operating systems so that when you commit a change, it builds on all OSes simultaneously. In addition, I sat in (virtually) with Anisha Pindoria from the ALM Rangers to discuss sprint 83 highlights, my demo and other get-to-know-you type questions.
To find the S83 review, use this link.
To find the Apache Cordova demo video, use this link.
Candid feedback is welcome!  Please leave comments here or on the respective Channel9 pages.

TFS Build vNext: Mind Your P's and Q's

With the recent movement of the new TFS Team Build (also known as Build.vNext) into public preview, a lot of excitement is building in the ALM community about the features, ease of use and improved experience that the new build system is bringing.  There are blog posts and articles starting to surface about how to set up agents and builds, deploy applications to Azure and set up continuous integration and continuous delivery pipelines.
This is not one of those posts.
Instead, I want to focus on one of the behind-the-scenes features that make vNext tick.  Specifically, I’m talking about minding your P’s (agent pools) and Q’s (agent queues).  Queues are what process incoming messages (triggers) for build requests, and pools are collections of build agents that are available to process the requests coming in from the queue.
There isn’t any official guidance from Microsoft on how queues and pools should be established.  That’s not to say there should be, per se: the queue/pool setup is pretty straightforward and maintains a 1:1 relationship.  That being said, it may behoove you to set up separate queues in certain situations.  For example, you may want to create queues per application to funnel triggers toward a specific pool of agents for development teams or products.  You might also want to split up queues by operating system, in the event you are building apps with cross platform capabilities, and require the native OS components to build them.  In my walkthrough “Building Cross Platform Apps with Apache Cordova and Build.vNext“, I decided to use the OS approach to illustrate how multiple queues would work, as well as helping to isolate the OS-specific functions needed to complete the tutorial.  
Does that mean you have to do that?  Nope.  In fact, for a lot of situations you could just stick with the default queue/agent pool setup and allow the build agents to be selected based on the requirements laid out in the Demands section:

The demands listed (such as visualstudio, vstest, and java) will route the build to any agents that are online and able to satisfy those demands.  There are other settings that also factor into what agent is selected, but the easiest way to control what build goes where is to set up the demands section to have specific needs that match up with agents you have in your build ecosystem.

TFS Storyboarding: Give your Vision a Visual!

While the concept of storyboarding has been around for quite some time, it’s not entirely clear that the practice outweighs the theory when it comes to usage in the field. In addition, some tools can be costly and may not be able to integrate well with your SDLC. One tool that is free of charge, and integrates nicely into an existing SDLC with a minimal learning curve, is the TFS storyboarding add-in for PowerPoint.
The add-in allows you to leverage PowerPoint to put together a step-by-step flow of your concept that is easy to understand and gives developers and other technical colleagues a reference point when reviewing PBIs. Having that visual helps quite a bit when you are trying to establish work items to go along with those PBIs, and gives all parties involved a better sense of security that requirements are being properly conveyed to the team whose responsibility it is to bring them to life.  While not true of every organization, many companies do have Office 2007 or greater, which is half the battle.  In order to install and use the TFS storyboarding add-in you must also have a copy of Visual Studio Premium, Ultimate or Test Professional (2012 and 2013 are supported currently).
You do not need to have TFS in order to use this add-in.  It relies more on Visual Studio than it does TFS or Visual Studio Online.  You can launch storyboarding from both of these platforms, though, which is convenient.  You can also link a storyboard directly to a TFS work item.  A great overview of how to use the add-in can be found on the Microsoft Developer Network’s site.  One of the key features of this add-in is the ability to create, import and export custom storyboarding shapes.  These can be anything from your company logo to screen mock-ups that are specific to internal applications you work with to icons and device types.  There are some great community-backed shapes posted in the Visual Studio Gallery, including iPad/iPhone shapes, Windows 8 shapes and even a nifty branching and merging shape which could be used to storyboard existing or new branching/merging strategies for your code base.  You can also find some re-sizable storyboard shapes in the Microsoft Visual Studio Team Foundation Server 2013 Power Tools extension.
Despite there being a slight learning curve on using the add-in and getting storyboarding started for your team, I guarantee that once you do, figuring out what the customer wants will no longer be a gamble and will more likely be a sure bet.

A Call to Action: Feedback Needed!

One of the best parts of being involved in the Visual Studio ALM Rangers is giving (and receiving) feedback from the field in relation to solutions that have been released, are in flight, or are mere glimmers waiting to be started.  Yet another is being able to reach out to other colleagues to request the same level of feedback!
Please see the links below, which are chock full of great content.  Your feedback, ratings and general enthusiasm around these and other Rangers projects help to keep the community going and gives those of us working on these solutions some great ways to make things better for everyone.
Here are the latest Channel 9 videos:
• Extracting Effective Permissions from TFS
• Monthly Catch-up: S77
Here are the latest announcements:
• Extracting effective permissions and Security Auditing for TFS
• Understanding migrations from on-premises TFS to Visual Studio Online
• Git support included with the extracting effective permissions sample and research completed
• Understanding TFS migrations from on-premises to Visual Studio Online – Part 2: Walkthrough
Feedback for any of the aforementioned items can be left directly on the video or blog pages.  Questions?  Feel free to reach out to me directly.  Suggestions for gap-fillers?  Please submit them via the Visual Studio page on UserVoice!

Migrating TFS to VSO: A Whitepaper Walkthrough

Recently I was fortunate enough to work with some fellow Visual Studio ALM Rangers on a whitepaper detailing the migration of an on-premises Team Foundation Server (TFS) instance to Visual Studio Online (VSO). It’s a good read and the team did a great job putting the narrative together so that it’s easy to follow along. Check it out here: TFS to VSO Migration Walkthrough
Candid feedback is welcome!

Developer VDIs – Options for Throwaway Workstations

We all know that computing hardware is improving and transforming at a steady and fast pace.  This allows us to do things as developers that even three years ago were quite frankly impossible.  One concept that I’ve run into on more than one occasion is that of the Virtual Desktop Interface (VDI). Typically when talking about VDI, one may think of an enterprise environment where everyone has this apparition in the ether of the company’s hypervisor that is their desktop “computer”.  I am not referring to that traditional VDI model.  What I’d like to talk about is developer-centric VDIs, configurations that allow developers to push, test, monkey with, and even destroy virtual machines specifically for proof of concept or other development purposes.
I’ve known plenty of developers who prefer to keep their primary machines “clean”, with no additional goodies outside of an MS Office suite installed.  They instead rely on virtual machines or VDIs on which they write code, compile, test and even deploy to a dev environment.  Within the past two years, a few vendors of interest have shown up, each boasting different capabilities.
Vagrant.  Vagrant is truly a developer’s VDI engine.  It follows a common theme of having images available for download that a dev can then customize if appropriate.  Its main dependencies are on Oracle’s VirtualBox and Ruby, so it can be run on almost any platform.  There are images out there based on Windows and even OSX, though I wouldn’t trust them simply due to licensing issues.  Linux remains the main OS for this particular tool.
Docker.  While Docker is more often thought of as an application deployment mechanism, one of the more popular use cases for it happens to be in implementing IaaS solutions. This means any Docker images could be used to store basic developer needs, and containers could be spawned to allow a developer to perform work without managing a hypervisor or other related resources.  Docker runs natively on Linux, but requires help from VirtualBox on both Windows and Mac OSX.  Another reason to take notice came in the form of an announcement concerning Microsoft’s partnership with Docker and plans to include native support for Docker in the next version of Windows Server.
Nitrous.IO.  This offering is a bit of a different animal, as it’s a free-to-start cloud VM solely for development.  The VM provided is a GNU Linux shared instance with either Node, Ruby, Go or Python installed and configured out of the box.  You can purchase more resources, but in most cases the supplied defaults are enough to do quick prototyping.  Since it’s online, you can push any changes to your distributed SCM system of choice for more concentrated work later.  You can quick preview on a couple of externally-facing ports as well, which makes having a PoC demo really easy if you have stakeholders in disparate locations.
Azure.  Yes, I said it.  If you have an MSDN subscription you are able to get guest OS images that include Visual Studio pre-installed.  For any company with an enterprise Azure subscription and MSDN subscriptions for developers, this is almost too good to be true.  Granted, there are charges for using the VMs, but given the ease of creation/de-allocation and the level of support, it’s truly a great option.  Integration with Visual Studio Online, Application Insights and the litany of other Azure features makes this an excellent choice as well.
Of course, one of the best features of any of these options is the ability to roll back or blow away a machine if something gets misconfigured, corrupted or is otherwise bothersome.  While you can do that with a physical workstation, it’s often frowned upon, especially in shops that have restrictions around what you can (and can’t) install on company hardware.  Sometimes having a disposable environment allows for more experimentation, which could lead to your next big development breakthrough.
Until next time…