What'd we do?

Last year was my first opportunity to officially present alongside my eldest son Christopher. Christopher had been helping with the Lab / Camp the previous two years, and he was interested in taking more responsibility as a co-presenter. Together we presented That Robotics / IoT Lab 2016 both Tuesday and Wednesday afternoons. Building on the previous two years experience, we were able to bring some of the same materials and created a number of new activities for the geeklings to enjoy.

Among the projects the Geekling attendees enjoyed were:

• VexIQ Mini-Kits (Racer, Cycle, Duck Explorer and Plane)
• VexIQ Sensor Lab (utilizing Robot-C Graphical / Classic)
• Drivable / Programmable VexIQ Omni-Vehicle
• That Pi Hunt (utilizing Raspberry Pi / Bluetooth Beacons)
• Arduino Bot
• ESP8266 Sensor Projects (via Feather Huzzah and Sparkfun ThingDev)

I'll talk a bit about the various projects, what went well, what didn't and what we'd likely improve if we have the chance to do it all again this year.

VexIQ Kits / Sensor Lab

In 2016, we had 4 kits the kids could put together, complete with a printed booklet (think LEGO instructions). We had an opportunity to re-use a couple of the kits from 2015, and Christopher and Zac (my younger son) came up with a couple new options. We had a few of each kit, and as in previous years, these were a major hit. The kit creation process allowed both Christopher and Zac to experience the engineering design process, from basic line drawings and brainstorming, through design review, initial construction and digitization (via SnapCAD and Adobe InDesign). Once the instructions first draft was completed, the boys assembled the bots to prove it actually worked and correct any part / direction flaws / gaps.

The 4 kits we brought to camp were the Racer, Cycle, Duck Explorer and Plane. The kits were (mostly) easy to follow and the Geeklings could work with their parents (or other Geeklings) to complete assembly. The first 3 kits (Racer, Cycle and Duck) were all relatively similar in complexity, and could be completed in less than 45 minutes. I felt that the plane kit was a bit of an experiment. The model was more advanced than any of the previous models we had tried, and required a significant amount of time to assemble [average was about 2 hours]. I was impressed that 3 different groups completely finished the project, and 1 more got most of the way through before we ran out of time.

The sensor lab was also a big hit. We had assembled a number of 'sensor plates', essentially a 12x12 Vex IQ Plate, with a brain, controller, motor and all the sensor types we had available (Color, Distance, Bumper Switch, Gyro, Touch LED). We had a 'wall of laptops' that attendees could use to program the sensor array, and some pre-built instructions and construction paper cards to work with the color sensor and Touch LED. There were numerous geeklings who went above and beyond, working with Graphical RobotC to manipulate the sensor input and do lots of cool things. One enterprising family reprogrammed our drivable omni-bot to do a little dance and flash the attached TouchLEDs to make a 'disco bot'. It was truly awesome to see them dig in and take a simple exercise to a whole new level.

Robot Virtual Worlds / Robot-C

We again leveraged the free 'Summer of Learning' (SoL) licenses that are made available via the Computer Science Student Network (CS2N). Unfortunately, the 2016 licenses ONLY covered virtual robot programming through Robot Virtual Worlds, which limited attendees to only a few laptops that could run 'full' Robot-C and interact with the sensor kits above. Previous SoL licenses had included both the Robot Virtual Worlds and standard Robot-C. I'm hoping that this years entry brings that capability back, as we don't have funding resources to purchase full licenses for all our camp laptops.

The RVW license allowed the geeklings to utilize the Robot-C IDE to walk through some exercises using a virtual robot in pre-defined 'worlds', solving problems and learning a bit about programming robots along the way. The nice part about RVW is that it allows experimentation without needing a physical robot to work with. Last year the geeklings again adventured in 'Expedition Atlantis' (a math problem solving game), explored Palm Island (which we visited a bit in 2014) and delved into the Ruins of Atlantis.

Arduino Bot and ESP8266 Sensor Projects

Entirely new this year were a number of 'Internet of Things' projects that the geeklings could try. The wall of laptops included copies of Arduino Studio. A number of folks had loaned us some sensor and bot hardware, and we wanted to give the kids a chance to explore both hardware and software simultaneously, along with providing some projects that might interest the older geeklings.

Accolade Systems loaned us a couple of their Arduino-based robots to use for the camp, and we borrowed a number of sensors from Skyline that worked with the ESP8266 boards that we had on hand (a Feather Huzzah from Adafruit and a ThingDev from SparkFun).

On a whole, these projects were underutilized, primarily because Christopher and I just ran out of time to put together guided samples. If we have a chance this year, I think we'll plan to bring more prepared examples to help lower the barrier of entry on these projects. The geeklings seemed to really enjoy putting together hardware and seeing it 'come to life', so I think a bit more guidance here could have made for a very engaging experience for all.

That Pi Hunt

The final project that the kids could participate in was one I had hoped would be a main draws of the IoT Lab. I had spent some time putting together a Windows IoT Core application which could read Bluetooth LE Beacons, light up some LEDs and 'capture' the beacons by wandering throughout the conference center. We had brought some Gimbal Series 10 Beacons and That Conference loaned us some Kontakt.io Smart Beacons which we distributed around the Lab room and in a couple of the conference hallways. Kontakt.io was also generous enough to donate some goodies for the kids to take with them!

I plan to do a larger write-up / lessons learned on That Pi Hunt, but the end result was a bit of a mixed bag. I think a combination of environmental, software and hardware problems made the process a bit of a frustration for most who tried it out. However, we learned a lot, both about how exciting playing around with hardware can be, and different approaches we'd take if we had to do it all over again. The kids loved to see the simple hardware they had assembled work with the test application that we developed, and it proved a great way to ensure that they had wired everything correctly.

I plan to continue developing the app to hopefully squash the bugs, and add some additional sensor options to the mix. All the code is available in our GitHub Repo in the 'pihunt' branch. Feel free to pull it down and play around with it.

In Closing

That Conference 2016 and specifically That Robotics / IoT Lab felt like a bit of a whirlwind, but we had a ton of fun. As we do every year, we found some things worked better than others, and we plan to take those learnings and apply them to future presentations. If you had a chance to attend last year, thanks for stopping out, and if not, we hope to see you this year!

All the code and examples we used for the lab are slowly but surely making their way out to GitHub. Some of the code was pulled from other samples available on the internet, and some was created specifically for the lab, but all should be available there, with links to the source material where applicable.

That Robotics / IoT Lab Repository

Thanks again to all who make That Conference possible (organizers, attendees and sponsors)! You've created something great, and we hope to be a part of it for many years to come! Don't forget, the Call for Speakers is coming up Feb 1st, 2017 (through March 15th), so start preparing your abstracts!

Originally Published on the Skyline Technologies Blog

Wish List Processing Today

Santa's Super Software Elves (S3E) are constanty looking to improve Santa's ability to process wish lists as painlessly as possible. It's pretty important to all of us at North Pole Central Operations that deserving kids throughout the world get just what they were hoping for Christmas every year. During one of our routine architecture review meetings, the team decided it was time to look into replacing our current Wish List Processing Services with something a bit more flexible and future-proof.

We here on S3E are certainly no slouches when it comes to technology, and we're willing to leverage 'The Cloud' in any way we can to make sure there are presents to open on Christmas Day. We were early adopters of Azure's Platform-as-a-Service Web and Worker roles (PaaS v1), exposing our wish list submission API to those enterprising kids of the world who wished to have direct access to Santa (Of course, we also provided a handy web application that the mail elves could use for manual entry as well). Our current Wish List Processing Service looks a bit like this.

As you can see, there is a standard web / worker role layout with some 'glue' in between to hold the persistent data, and handle communications between the web and worker roles. In this case, we used the various Azure Storage technologies (Blobs, Queues and Tables) to provide that glue. Person data was stored in Azure Table Storage and Workflows were managed by populating the appropriate Storage Queues. The Worker Role(s) handled shuffling data around and making sure the millions of nice kids around the world had something to open Christmas morning.

The Limitations

While our current solution is working well, the scaling capabilities are pretty coarse grained. We can play around a bit with the number of instances of the Web and Worker roles, but we don't really have a way of utilizing any of the 'unused' compute power that our Web/Worker role instances may have. We also have to provide pretty much all the 'glue' code ourselves, making sure the two roles work together seamlessly. There's really no built-in facility to manage those occasional 'uh oh' moments (we have them here at the North Pole too). While PaaS v1 does have the concept of 'deployment slots', leveraging them to manage service health based rollback required a lot of manual scripting.

We also want to be as cost conscious as possible (we elves need to eat too), so getting more from less compute resources seemed like a no brainer. When utilizing Web/Worker roles, you 'scale' one or the other by essentially spinning up a new virtual machine, dedicated to that particular task. Any work sharing arrangement, similar to our current solution, requires manual coding. Getting more done per machine pretty much directly correlates to writing more code.

Enter Service Fabric

One of the promises of Azure Service Fabric is more efficient use of the resources that a given VM provides. This is done primarily by disconnecting the direct relationship that PaaS v1 had between a role instance and a VM. This does a couple things for us right away. First, it lowers deployment time, as the VM does not need to be re-provisioned as part of the deployment process. Secondly, it allows multiple services (roles in PaaS v1) to run on the same VM instance. By default, you don't have control over where your service deploys to, only the number of instances that are deployed. For those interested, however, there are knobs and switches you can use to, say, have a cluster of high CPU or high memory nodes that certain services are deployed to.

Service Fabric, like PaaS v1, does not require you to manually manage your VM instances / images. How this capability is delivered, however, is quite different than before. Service Fabric is really about leveraging a bunch of existing Azure technologies, rather than providing a 'standalone' solution as in PaaS v1. Service Fabric uses technologies like Azure Load Balancer, Azure Virtual Machine Scale Sets and Azure Virtual Networks to provide the operating environment for your services. When you configure a Service Fabric Cluster, whether via the Azure Portal or Azure Resource Manager Templates, you are asking the Azure infrastructure to setup a suite of existing technologies and glue them together into a cluster for you. You can manage then that cluster using the Azure Portal, Azure Command Line Tools or Azure Powershell Cmdlets.

In the diagram above, you can see some of the Azure technologies that are used to create a cluster. At the core, a Virtual Machine Scale Set (VMSS) is used to provide the nodes for the cluster. These nodes are linked together with an Azure Virtual Network, and secured with an SSL certificate that is pulled from Azure Key Vault. With a little additional work, you can secure the management of your cluster, including application deployments, with Azure Active Directory.

The fabric is exposed to the public internet in a couple ways. An Azure Load Balancer sits in front of the fabric and routinely probes the nodes to determine which services (ports) are available on each node in the system (this includes any custom application ports you may need). Secondly, Service Fabric Explorer gives you a window into your cluster to monitor the application(s) running there, and the general state of the fabric nodes. There are toggles that can be used to simulate node failure, loss of state data, etc, so you can safely test failure scenarios easily.

Service Fabric - Service Types

Before we get into the nuts and bolts of the new proposed solution, it will be good to get some vocabulary out of the way. While Service Fabric is really a general purpose 'cluster as a service', the Service Fabric SDK has a number of specific concepts that we'll be leveraging to make everything work.

Services

A Service Fabric 'Service' is a piece of code that runs within the cluster. Each service has address(es) (or endpoints) that can be called to invoke the service functions. All services expose their functionality by declaring and implementing an Interface and utilizing Service Listeners to receive requests from other nodes in the fabric (or from the internet through the load balancer). Services can be either stateful or stateless. Stateless services generally run with a copy on each node of your cluster, they may be truly stateless [just perform operations on data they receive], or state may be managed by an external resource [e.g. a database]. Stateful (or Reliable) services, on the other hand, have state that is managed by the service fabric runtime (this state is potentially further divided by partition).

Actors

A Service Fabric 'Actor' is a named instance of an object that lives in Service Fabric. Actors relate on a certain level to a 'Stateful Service', in that the actor state is managed by service fabric. However, Actors differ in that they are further managed in a turn or queue based manner. For example, if multiple requests are made to the same Actor type (e.g. ElfActor) with the same Actor ID (e.g. Joe), then that Actor will process the requests in the order they are received. Actors also have the ability to fire best effort events to anyone in the cluster that is listening.

Wish List Processing - Revisited

Finally, let's take a look at the proposed architecture for our new 'v2' Wish List Processing service. The elves in S3E have come up with the following high-level diagram of the services that will live in the cluster.

As with our original solution, the primary 'user interface' is a Web API endpoint that runs in the cluster and is exposed to the public internet via the Azure Load Balancer. Future versions may bring over an updated version of the web application portion of the v1 Web Role as a separate service within the cluster. Since these are web apps/apis, they are hosted within a stateless service. When the service receives a new wish list, it looks up the associated person from the 'Person' service.

The Person Service is a stateful service, the service holds all known person data in an IReliableDictionary. This structure provides synchronized maintenance of the dictionary contents across all instances of the service. Furthermore, this particular stateful service is partitioned, which allows us to divide or shard the data into buckets so one set of service instances aren't responsible for all the service data.

Once the API has looked up and assigned the person to the incoming wish list, the list is sent to the 'Review Member Service', which is another stateless service. In this case, the set of reviewers is defined in a configuration value that the service reads on startup. The service takes the incoming wish list data and routes it to the 'Review Committee' actors, who review the list and approve items.
Once the Actor has reviewed the list, it is re-submitted to the Review Member Service. Once all reviewers have voted on the list, the list is sent to the 'Gift Processing Service' so the approved wish list items can be fulfilled.

The Gift Processing Service is a stateful service that holds a series of IReliableQueue instances, one for each type of gift. In addition to the normal interface-based set of operations, the Gift Processing Service has a persistent background process that reads data from these queues and delivers them to the appropriate Gift Maker Actor. Each Gift Maker elf can only make one gift at a time, and are only trained to make a single gift type, so Actors provide a good representation. Once the Gift Makers finish their work, they forward the wrapped gift to the 'Shipping Department', which is a single-partition stateful service which keeps an IReliableDictionary of families and their gifts, so the gifts can be bundled together and sent to the shipping provider, Santa's Sleigh Unlimited (or Amazon Prime Drone Delivery for the technically inclined).

Future Enhancements

We here at S3E rarely sleep, so our wish list of features is extensive. Some future enhancements that we're currrently investigating include:

• Mail Elf Utility - Migration of the existing web application was not part of the scope of our original plan. Instead, we've updated the existing web application to point to the new Service Fabric backed services. In the future, we'd like to bring in the web app as a second 'application' in service fabric, primarily to maintain isolation and separate deployment packages. Service Fabric allows any number of applications to run within the fabric, so there's no problem there, and moving the app will allow us to decommission our existing web/worker roles completely.

• Service Fabric Health Monitoring - We plan to use this to monitor the gift maker queue depth, to know when we should start training new Gift Makers to cope with demand. We also plan to leverage the automated application rollback capabilities that use health monitoring to determine whether or not a new version of your application is 'healthy'. If the upgrade causes these health checks to fail, the upgrade is automatically cancelled and rolled back to a previous working state. This will allow us to extend our continuous deployment model that we use in the test / staging environments all the way to the production system.

• Santa's Naughty & Nice List - We plan to create a Web Application to manage the data in the Person Service such that Santa (and his fleet of Elves on the Shelf) can dynamically update the actual behavior rating of people registered with the service, compared with the self-reporting that we currently accept with the wish list submission process. Again, the plan here is to create a separately deployed application within the same cluster.

• Reviewer Status Monitoring - We hope to start leveraging Actor Events to help better track how long reviewers are spending reviewing wish lists, and how long gift makers are taking to make particular gifts. We plan to link these data streams to Azure Stream Analytics so we can be alerted when reviews are taking too long (reviewing lists can be somewhat of a burnout job, even for elves), or which gifts seem to be the hardest to make (to increase gift maker training)

... and the list goes on, but Actor Timers / Reminders, Logging with EventSource and .NET Core are all on our research backlog. There is also a lot of opportunity to leverage other Azure services, like Azure Service Bus and Azure IoT Hub to automate even more of our operations.

Wrapping it up

At S3E and NPCO, we are always focused on continuous improvement. Moving wish list processing to Azure Service Fabric will address many of the scaling and coordination concerns that we have with our existing Web / Worker Role solution. The move will also open the door to further improvements with less code. Using the Service Fabric SDK and Visual Studio 2015 (and soon 2017) allows us to very quickly wire together our new microservices without needing to worry too much about the details of making them all play nice together. In the end, it's all about getting toys out to those millions of nice girls and boys (and a few parents too). Doing that more efficiently and with fewer operational headaches allows us elves a bit of needed respite, and maybe the occasional vacation to Maui too ;) (even elves have big dreams).

Why you should attend

That Conference 2016 (Aug. 8 - 10) is one of the truly unique experiences that the upper-Midwest has to offer for geeks everywhere. How do I know this? I've been attending, with my family, since 2013. Over 100* presenters and nearly 1000* [or more] of your coworkers, friends and community members will be there... and have I mentioned the bacon smores?!? Just wander over, take a look at these speakers, build your schedule and wonder how you could possibly survive the summer without all this technical goodness and networking with this welcoming community.

If you hurry, all this geek-loving, family-friendly, bacon-consuming, robot-exploring and memory-making joy can be yours for only $399.99... Seriously, $399.99. The only catch? It'll cost you an extra $100 if you buy your tickets after May 1st, 2016. If saving money isn't enough, you'll have a chance to meet with Those Sponsors. Many of the sponsors are among the premier technology firms in the nation, including my employer, Skyline. There's nowhere else that you can find so much local talent, and so many fantastic local employers who are eager to talk with you about how they can help you find your dream career/service provider/etc.

So, I encourage you to check out what is sure to be one of the year's premier technical conferences.

What we're doing

As I mentioned, I've been attending and speaking at That Conference for the last 3 years. For the last two, my focus has been on bringing unique experiences to the families that attend the conference. In 2014, we started with a 3-day Robotics Camp. We took our experiences in 2014 and followed up with a 2-Day Robotics Lab as part of That Conference 2015. The feedback from 2015 was amazing, and we saw a lot of kids get really excited about robotics. Whether it was building projects with family and friends, programming with siblings or throwing some balls around with a drivable robot, there were smiles aplenty.

For That Conference 2016, I've been blessed with the opportunity to present beside my son Christopher, and we plan to take things to the next level with our 2-Day Robotics / IoT Lab. We'll have Vex IQ robots / simple mechanisms, Vex IQ sensor labs and some pre-built Vex IQ bots like we've had previous years, but this year we are adding in some Arduino-based bots and some IoT sensors/kits running Windows 10 IoT. I'll leave the details to future blog posts, but I hope to see you there this year. Stop by and check out our Lab, and take some time to contemplate this little factoid... Christopher is only one of 7 speakers who are children! The conference has over 20 family track sessions over 3 days, and of those, more than 50% are being delivered at least partially by Geeklings!

And if that wasn't enough

Don't forget that this all happens at an Amazing Waterpark!

* Numbers are estimated to protect the innocent (and also because I don't have exact numbers)

Thanks to a bit of luck (my name got pulled from a raffle), I was recently afforded the opportunity to play a prototype of the board game Tiny Epic Galaxies (TEG) - BGG Page. Having never played an unreleased game before [save the print-and-play offerings from various Kickstarter campaigns], I was intrigued to give it a try. After playing numerous rounds with friends and family, what I found was a fairly well balanced game, with equally well developed instructions, that was in turns fun to play and enigmatic.

What is it?

Tiny Epic Galaxies is a 2-4 player light strategy / galaxy building game created by Scott Almes and published by Gamelyn Games. This is the 3rd installment in the 'Tiny Epic' series, preceeded by Tiny Epic Kingdoms and Tiny Epic Defenders. All three games are intended to be 'Micro Games', delivered in small (5x7x1-ish) boxes and playable in 30 minutes or less. TEG departs from the setting/story line of the previous two games, bringing the story to 'space' in the hopes of pulling you into a contest for galactic domination.

Game (Prototype) Contents

How does it work?

The game is played in rounds, with the level of the players' Galaxy determining how many ships they have in play, how many dice they roll and how many victory points their galaxy affords them. Each player takes a turn by rolling the dice and 'locking in' actions. Other players, who have culture points remaining, can piggy-back off the current player's last move by spending one of their culture points to duplicate the last locked action. Players move to and persuade planets to join their Galaxy, gaining victory points and powers they can use with the appropriate dice roll. Once a player reaches 21 combined victory points [from captured planets and the players' Galaxy], all other players have a single turn to match or exceed the winning player's victory point total. In the end, the player with the most victory points has won the 'Quest for Galactic Domination'.

Game Setup

Setting things up for a game is pretty straightforward, just give each player the following components:

• A Galaxy card
• Set of 4 ships
• A cube marker [energy]
• A disc marker [culture]
• A hex cylinder [galaxy level]

Players start with their 'base' Galaxy - A home planet with 2 ships, 2 energy and 1 culture. The remaining two ships are placed in reserve, for use after the Galaxy has been upgraded. The 30 planet cards are then shuffled and the number of players + 2 planets are dealt face-up in the center, with the others held face-down in reserve to be used during play.

Starting Galaxy Setup

Gameplay

Play then proceeds by selecting a starting player. The instructions suggest the last person to finish a sci-fi novel, but we just chose at random [or the youngest player when playing with my kids]. The base Galaxy affords the players 4 dice to roll, so player one kicks things off by rolling their four dice and deciding which to keep and which to re-roll. One re-roll is free, and all additional re-rolls consume one energy.

The Dice

There are 6 possible actions for each die [pictured above]. Actions include basic movement, energy/culture capture, colonization and 'Galaxy action' [officially a 'Colony Action']. As each die is 'locked' the current player performs that action and sets that die aside.
Then any player who has culture points remaining can choose to duplicate the just-locked action by spending one culture point. That player then immediately takes that action, before the current player can proceed with their next action. If more than one out-of-turn player wants to act, actions are performed in turn-order.

The remaining dice are then locked, one at a time, with the current player choosing to use their re-roll(s) at any point during their turn.
If a planned action is nullified by another person's out-of-turn action, the player can use their free re-roll [or spend energy if available] to 'replan' on the fly. Once the player has activated all the dice they plan to use, play proceeds clockwise around the table. The current player does not need to use all their rolled dice, and any dice which are not activated cannot be duplicated by other players.

The Planets

A Planet Card

Each planet arrayed in the center of the table has 4 basic components:

• A - Resource [energy or culture]
• B - 'Colonization' Track [$ or !]
• C - Power / Action
• D - Victory Points

Movement and Colonization

Using a move action die allows a player to move their ship to any planet card that does not currently host one of their ships. Each planet card has two possible landing sites. The first landing site is the planet's surface, which can be occupied by only a single ship. Landing here activates that planet's "power" immediately. The second possible landing site is the start of the 'colonization' track. Any number of players can be vying for colonization of the planet at the same time. When moving a ship that currently resides on a planet card, the player must move their ship OFF the current card. Ships cannot be moved between the colonization track and planet surface without first leaving the planet. The only card which may house more than one ship / player is the player's Galaxy card. Ships that have been displaced, or which move newly into service are placed on the home planet.

Using a colonizing action [$ or !] allows the player to move one of their ships on a matching planet up one 'space' on the colonizing track, towards the colonization symbol. When the symbol at the end of the track is reached, that planet is claimed by the player and becomes part of their Galaxy. Once colonized the planet loses its resource generating ability, but the colonizing player gains both the victory points and planet "power" to use as a 'Galaxy'/'Colony' action. All ships currently occupying the planet card are immediately returned to their home planet.

Resource Gathering

When activating an energy or culture die, players initiate a 'resource gathering' action. Each planet card that provides the activated resource and currently hosts a player's ship supplies one 'point' of that resource to the player's reserves. NOTE: This includes the player's home planet if the activated resource is energy. Energy and Culture reserves have a maximum capacity of seven (7). Once the reserves are full, furthur gathering of that resource has no effect.

Galaxy [or Colony] Actions

The final die face is the 'Galaxy' or 'Colony' action. Initially this action can only be used to 'upgrade' the Galaxy, providing more dice / turn or more ships to deploy. When upgrading the Galaxy, the associated victory points and any additional ships are activated immediately, but new dice do not come into play until the player's next turn. If additional planets have been pulled into the Galaxy, a single planet's power can be choosen instead of the base action. Planetary actions range from purely selfish [+1 culture/energy, combined energy+culture upgrades] to mildy disruptive [steal a culture/energy, move enemy ships down the colonizing track] all the way to devious [move ships to other planets, re-roll unactivated dice]. Planetary actions always override the base game rules/flow, and can be leveraged to great effect by saavy players.

Game in Progress
Player Card

Experience / Impressions

I had an opportunity to play the prototype with multiple groups of family and friends over the last few weeks, and the overall feeling was pretty well spread across the board. It feels rather clear to me that board gaming experience matters. Those who played games often seemed to pick up Galaxies more quickly, while those who didn't game often were more likely to get 'bogged down' in all the rules and potential strategies. The game also benefits from multiple playthroughs. I know I didn't feel entirely comfortable with the rules and strategy until my third game, and I lost a few players midway through their first game due to the perceived complexity.

While a majority of the people I played with were adults, I ended up playing the game most often with my two elementary / middle school aged sons. I would feel safe recommending this game even to elementary school children [say, 7yr+], especially if the children have shown an aptitude for strategy and are interested in board games. After a few rounds, even my youngest son was able to negotiate a reasonable strategy and be somewhat competitive. Middle school aged kids [10yr+] should have no problems picking up the game, IF you can convince them to sit down for a family game night :).

As I mentioned initially, the rules are fairly well written for a prototype. I missed the ability to land on the planet's surface on our first play through, and didn't remember we could re-roll using energy until the middle of the second game. Games, especially with new players, tended to start out pretty slowly. However, once most players understood the rules, play cadence picked up significantly.
While we were never able to get a 4-player game completed in 30 minutes, we were able to keep it under an hour most times. The average play time for our groups was around 45 minutes, and it seemed like the 'sweet spot' was 3 players. Two player games were fun, but the game really opened up once you hit the third player. Four players was equally fun, but the game seemed to get a little more drawn out, and was hard to keep inside the 60 minute window that most of my play sessions had.

Given that this is the third installment in the 'Tiny Epic' series of games, it seems appropriate to compare/contrast this game with the other games in the series. Having backed the Kickstarter for Tiny Epic Defenders, I had a copy of the print-and-play, and have played with many of the same groups where I prototype'd Galaxies. Interestingly enough, it was a pretty even split between the two groups as to which of the two games was preferred. It feels like the 'hook' for Defenders is a bit stronger within my play circles, although I personally prefer Galaxies. While I don't feel that the rule sets between the two games are much different from a complexity standpoint, friends and family consistently rated Galaxies as 'harder to understand', even if they liked it as much or better than Defenders. It may be due to the competitive nature of Galaxies vs. Defenders co-op play which encourages sharing of strategies/suggestions. While I also own Tiny Epic Kingdoms, I have not yet had a chance to play it (it's a Christmas gift for the kids), so I can't make any personal comparisons there.

Clarifications / House Rule Suggestions

As this is a prototype, rule clarifications were to be expected. Gamelyn Games staff were very responsive to Twitter questions, and we were able to get a few questions cleared up pretty quickly. Of course, I didn't always like the answers :)

• Colonized planets are officially replaced at the end of each round. However, in our play sessions, we found that following this rule caused a pretty heavy 'last player handicap' and that play moved much more smoothly [and fairly] if colonized planets were replaced immediately.
• The rules are unclear about how many players can occupy the planet's surface, but based on the explicit call-out of multiple colonizing players, we chose to limit the planet surface to a single ship.
• Planet powers/actions generally override any normal game rule, but some planet rules are somewhat confusing. We usually just decided what the power 'meant' when the planet joined the center of the table, and could usually come to a reasonable consensus quickly.
• Replacing colonized planets immediately helped even out the overall game, but it feels like adding +1 [culture OR energy] by player position would help to further balance play. In this way later players get more opportunity to use previous player actions. I haven't played enough rounds with this rule to tell whether it unbalances the game, but it feels like a good fit thus far.

Conclusion

Overall I was very pleased with the play experience of Tiny Epic Galaxies. The strong blend of luck and strategy combined with relatively quick pacing means that this game will have a place on my game shelf for a long time to come. There is enough of a hook to pull players in, and once the rules are well understood, the game plays quickly. Replayability is high, and the game felt a bit different each time we played. Strategies that worked in previous games were easily countered or non-functional in future games due to the mix of planets and luck of the dice roll.

The Good

• Quick, Light Strategy Game with just enough luck thrown in to keep you guessing
• Multitude of different strategies possible, no 'one sure way to win'
• Accessible to kids [10+ for sure, 7+ is possible]
• 45-60 minute play times [with 4 players]

The Bad

• Some planets actions are unclear
• How you'll feel if you miss out on the Kickstarter [starts Jan 8th, 2015]

The Ugly

• It's not available for Christmas 2014

The Pitch

That Conference 2014 (Aug. 11 - 13) could very well be the time of your life [weddings, children and first dates not-with-standing], but if you don't attend, you'll never know. Over 150* presenters and nearly 1000* [or more] of your closest friends are scheduled to be there... and have I mentioned the bacon smores?!? Seriously, just wander over and take a look at the amazing speaker filled schedule and wonder how you could possibly survive without all this community and technical training goodness.

There's a catch though, ticket sales close next Monday (Aug. 4)! Come join our amazing community of developers [and their families] at what is sure to be one of the year's premier technical conferences.

What we're doing

OK, so sales pitch aside, I've been given the amazing opportunity to run a 3-day Robotics Camp at the conference this year. Why is this amazing? Seriously? Did you not just hear me say 3-Day Robotics Camp? The camp will be held as part of That Conference's Family Track and will take place during the normal session times throughout all three days. We'll be using the VEX IQ robotics system and walking kids through the process from a bin full of parts to a finished robot, with a side of competition and a kicker of badge ribbons.

There have been a lot of folks involved in making this thing a success, but I'll save that for the postmortem report. For now head over and check out our Day 1 abstract and then get those tickets purchased. We look forward to seeing you there!

P.S.

Did I mention it's all happening at a freaking Waterpark!

* Numbers are estimated to protect the innocent (and also because I don't have exact numbers)

Last fall [Sep. 2012], my company Skyline Technologies, put together a Windows 8 DevCamp for our associates.  The purpose of the camp was to accelerate our employees learning of the Windws 8 development stack, have loads of fun and produce some publication worthy apps to the Windows 8 Store.  I've been meaning to write up a postmortem on the whole experience for quite some time, what follows is a postmortem on the DevCamp as a whole AND some specifics about our particular application, and represents my personal opinions on things.  I haven't had a chance to crowd-source the analysis with the other product owners to see if they had similar experiences.

What went right

Participant Sourced Ideas

Prior to the DevCamp, the camp leads sent out a call for proposals to all participants who had signed up for the camp.  Participants were asked to submit 1 or more application ideas which would be voted on by the group, and the top 5 would be implemented as part of the DevCamp.  This was a great opportunity for participants to flex their design and leadership muscles, and most [if not all] of the people whose proposals won ended up as the product owner for their idea.  This was a great way for developers to get a chance to 'own' the end product, providing additional incentive to push through the final publication and delivery process.

Great People, Awesome Team

Skyline, as a rule, hires some of the best people I've ever had the pleasure of working with, hands down.  The group that I worked with to deliver our Windows 8 app, Game Manager - Soccer, was a great mix of seasoned XAML devs, fairly new recruits and seasoned devs with little XAML specific experience.  Nobody on the team had any significant real-world Windows Store [/Modern UI/Metro] development experience to speak of.  Over the two days of the dev camp, and the follow-on work to complete the app for publication we ended up bringing the entire team up to speed on Windows Store development and had a great team dynamic that kept things fun.  I heard similar stories from every other team at the camp, and everyone I've talked to thus far has expressed an interest in doing future camps.

Good Technology Split

It turns out that after the voting was in, and product owners had chosen their desired technology stack, we had an even split between C#/XAML and HTML5/JS.  I was a bit suprised, being a XAML-geek myself, that more teams hadn't chosen the XAML stack.  After going through the camp and talking with my colleagues, the 'HTML5 guys' were equally baffled that anyone would choose the XAML stack.  The even split in technologies meant that our DevCamp participants could really pick and choose a team that fit both an app they were interested in and a technology stack that they had a passion for.  Win-Win for all involved.

Design Work / Project Scope

The team did a great job whittling down and mercilessly cutting scope to be able to fit the v1 release into the 200-300 hr window that the DevCamp required.  Building out screen designs and the planning that went into the application prior to DevCamp weekend made a huge difference in our ability to set focus and successfully deliver the quality of work that came out of the initial weekend.  We had learned this lesson a bit after our last company GiveCamp, and the DevCamp helped solidify that vision/requirement for future camps.  The good thing about needing to cut scope was that it allowed us to focus on quality for the pieces we were able to include, and to enhance the user experience beyond what we could have done had we kept the initial scope intact.

Surface RT

Who doesn't love to get new hardware!  Skyline generously handed out new Surface RT devices to all participants in the DevCamp as a reward for the time they put in on the project.  Not only is this a cool device, but it also allows us to test the application on 'baseline' ARM hardware to ensure that we are meeting the performance requirements of the system.  Using the RT allowed our team to find a number of performance related bugs before we published, which means a better experience for our users, and better ratings for the app overall.

What went wrong

Project Scope

Surprise surprise, scoping is good and bad!  Scoping a project is always hard, and even with the ruthless cutting of project scope, we STILL underestimated the total effort required to deliver the application.  I think a large part of this was caused by some of the items I'll get into below, and was certainly effected by our relative inexperience in the Windows Store app development space, but future efforts will definitely be tempered by this lesson.  In the case of our application, we really targeted what I [as product owner] felt was a minimum viable product feature set, so treading that line will always be hard.  When building/planning your applications, always keep in mind whether your minimum requirements put your project 'out of scope' for an effort such as a DevCamp.

Follow Through

This point is a hard one to swallow, and I don't fault any of our team members for it because, in the end, 'real life' is far more important than 'hitting a date'.  What went wrong in this process is that the scope [covered above] required a significant effort 'post DevCamp' to push through to publication.  As a result, a small portion of the overall project team ended up completely a lion's share of the remaining work and bug identification/fixes.  That extended effort was 'part of agreement' when signing up for the project, but unforseens and real life milestones tend to get in the way of the project plan sometimes.  To be clear, THAT'S A GOOD THING, and one of the great things about working for a company like Skyline.  The work-life balance is extremely important to the company, and to all our team members, so when real-life steps in, the project takes a back seat.  Bad news for the project, good news [usually] for those involved.

Local Data Model

As part of scoping things down, we went with a local in-memory data model for our 'data access' approach.  This was, I think, necessary in the end due to time constraints and project resources, but it did introduce a 'cognitive disconnect' for many on the team whose day-to-day job is n-tier/service-based application development.  It also introduced a number of bottlenecks and data management issues that simply don't exist when you have a 'real' backend to talk to, and when your source of truth doesn't 'handle' identity mapping, concurrency checks, relationships, etc.  In the end, the 'simple' approach which avoided SQLlite or some other 'real' database backend, required a lot of not-so-simple code to ensure we were always maintaining references during serialization/deserialization, passing data around between ViewModels, etc.  To add to this, our application supported data synchronization through the built-in WinRT 'roaming' folder from the start... until we discovered that the current defaults within WinRT limit that storage to 100KB of data.  As a result, we had to eliminate a 'free' feature and replace it with a far more complicated [and error prone] LiveSDK/SkyDrive approach [which we are planning to deliver in our first post-v1 release].

Testing / Feedback

Developing 'commercial' software requires an entirely new level of testing/QA/etc compared with Line-of-Business applications.  Now, to be clear, I think LOB apps could benefit from the robust level of testing and validation that should go into commercial software development, but the reality is that most LOB applications 'feel' more flexible in this department from the business/financial side of the house.  We grossly underestimated the effort required to adequately test the application, and the number of users required to do so effectively.  As a result, bug reports were late getting in and fixed and one or two people ended up doing a majority of the testing [which isn't always fun].  On future projects, having a dedicated 'beta' group that we can publish our application to ahead of time and gather feedback from will be on the top of the priority list.

SIDEBAR

Store Publication

The publication process was... interesting.  To be sure, it only took a couple attempts to get the application certified/published successfully, and I'm very thankful to the testers that helped us out and the team members that fixed bugs like mad, but the feedback from failed certifications needs serious work.  During certification, it was identified that our application experienced crashes, however, the certification results did not include any details about these failures, or what portions of the application were being tested when the failures occurred.  This makes the 'failure' result as close to useless as possible, and forced us to revisit the application and 'fix' things that weren't breaking locally [i.e. 'might' have been bugs] and really go out of our way to just try to guess what they might have tried that could have caused the error.  As an example, one of our team members discovered that if you put 'too much' text in our text boxes, the application would appear to freeze [and sometimes crash].  That's a great find, and certainly not something I would have thought to test for prior to this project, but if that was indeed what caused the crash during certification, it would have been great to have them tell us that so we could address it more directly.  Microsoft, if you're listening, recording a screencast of the testing/certification process that you can attach to failed certifications would go a LONG way towards producing better quality apps and shortening the turnaround time on publication failures.

Conclusion

Overall the DevCamp went better than I thought possible.  The camp was an awesome experience, both from a development and personal standpoint.  Our team did an amazing job and I think all the team members would [and should] be proud of what we were able to accomplish.  The lessons learned from this camp will be applied to the next one, and I look forward to future camps and continuing to make great software for Skyline and its many clients.  Thanks to everyone on the team, and at Skyline in general, for your support in making this camp and the applications that came from it happen!

... And ..., if you're a soccer coach [or know one], go out there and grab Game Manager - Soccer [or any of our other Windows 8 applications]!  Leave us some feedback so we can continue to improve and go out there and build your own Windows Store applications!

Over the last [almost 1 year! ] I’ve been in the process of migrating my website/blog to a new blogging platform.  I had been looking at Orchard CMS for quite some time, and was interested in trying it out for myself before recommending it to friends and colleagues for their sites [those that I maintain and those that I don’t].  Unfortunately, real life tends to intervene when least expected, and the time that I had to dedicate to migrating the blog disappeared.  So, here I am, finally, on the new platform and while the process wasn’t always as straightforward as I hoped, it’s now ‘done’.  I hope to now be able to dedicate some additional time to actually producing content [the driving reason for the initial move].

So… why?

There are a number of reasons, but the driving reason was that my old platform BlogEngine.NET, while it was certainly capable, was starting to feel rather long in the tooth.  It was still WebForms-based, I was moving to MVC development on my sites, and I could never really crack the theming nut to get a look and feel that I was truly happy with.  The platform has served me well over the years, but I do most of my writing with Windows Live Writer, and there appeared to be a bug in BlogEngine.NET that was preventing publishing of posts with ‘too many’ images, or maybe it was ‘too long’… I could never figure out exactly what the problem was, but that was the trigger and was why I haven’t gotten back around to blogging since.

Orchard provides a number of ‘bonus’ features [for me], it’s based on MVC/Razor which is a big benefit as it aligns pretty closely with what I’m ‘used to’, which means I can get up an running on changes/modifications right away.  Its modular system should also allow me to selectively override the portions that I care about without changing the source/original copies of things.  There are a lot of modules already pre-built, which is nice, and I’ve been able to find most of what I need to provide feature parity out of the box.  One thing that’s missing… out-of-the-box reCaptcha support for comment entry, but I’ve found a blog post that outlines the process of getting that added to the comments area, so hopefully I’ll get that worked out soon.

Also, the Orchard theme I’ve used supports out-of-the-box responsive design as well, so it should show up much better on mobile devices, and I don’t have two different themes for the different devices.  This is becoming more important these days, and so having this support without much effort on my part is a big win.

In Closing

Welcome to my new blog, and I hope to get back here posting much more regularly, with both the technical content you’re used to and more observations on the state of technology in general.

Thanks for reading!

In the process of preparing my talk for the 2012 Fox Valley Day of .NET, I decided that the best way to get a reasonable talk laid out is to write a blog series about it .  Maybe that means I’m weird, I don’t know, but it does mean that I’ll actually have some new entries for the blog after far, far too long.  I need to strike that balance between ‘long ass boring’ and ‘you are done already?’, hopefully this will be a good way to get there.  I’ll go into a lot more detail about the project and resulting solution here than I ever could in a talk, so I’ll apologize in advance if you’re attending and see something here you were hoping I’d elaborate on in my session.  If you see these, and have specific questions, I’ll be glad to answer them here or in person.

So, obviously, I’m not going to outline the history of multi-threaded programming, or even the complete history of multi-threaded programming in the context of the .NET Framework. I will start out trying to set the context for the world we’re currently faced with, and lay out what I hope to accomplish in this series. Future articles will delve more deeply into specific topics around Dataflow, and we’ll see our simple app hopefully mature into a full-fledged test-bed for Dataflow experimentation.

Where are we?

The 4.0 .NET Framework introduced a new concept for dealing with multi-threaded programming, the Task Parallel Library [or TPL from here on out].  The TPL sought to pull out the ‘good’ bits of parallel programming, from both best practices to burnt fingers, and roll them into a nice, easy-to-use framework.  For the most part, at least in my experience, Microsoft succeeded in this goal.  Certainly it wasn’t perfect, and there were bits missing [many of which appear in the .NET 4.5 preview], but it was an excellent ‘1.0’.

Those who used the TPL built up various solutions for retrieving the data to process, bundling it up, spinning up tasks to do the processing and generally ‘managing’ the flow of data through your application to get your job done.  Stephen Toub explained this approach very well in his 2011 //BUILD session, talking about the ‘data first’ nature of the existing TPL and some of the limitations of the approach.  TPL Dataflow [TDF] really turns things on their head a bit, switching to a ‘computation first’ model, whereby you setup the computation and then ‘wait’ for data to flow into the network for processing.

To be sure, everything you can do with TDF you can do with TPL or TPL+Rx or TPL+(your library of choice), and many of you have already built similar solutions to the framework.  What’s exciting about TDF is that a lot of the ‘stuff’ that needed to be managed as part of the ‘overhead’ of a project is now handled ‘out of the box’, and we can move from concept to solution quickly and spend more time on the rules/scalability/robustness/documentation side of the equation than we ever had time for previously.

What is TPL Dataflow [TDF] Anyway [in 100 words or less]?

TPL Dataflow is a set of Interfaces (IDataflowBlock, ITargetBlock, ISourceBlock and IPropagateBlock) and some implementing classes that can be used to build data processing networks.  The classes are located in the System.Threading.Tasks.Dataflow namespace, and are part of .NET Framework 4.5 [currently in beta].  The interfaces/classes are designed from the ground up to support multi-threaded, asynchronous programming and can be used to solve many classes of problems that were difficult to do with the TPL natively.

Sidebar: These are .NET 4.5 classes, so you WILL NOT be using them in new ‘Windows 8/RT Metro’ applications as they are not part of the surface area exposed by the new Windows Runtime.  You may be able to use them ‘wrapped’ in a WinRT component, but I haven’t explored that option yet, and I’m not sure that you’d want to in any case.  You WILL be using these classes on the ‘backend’ that you write to service all these ‘consumption’ Metro apps that you are building.

So Where am I Going With This?

The long term goal is a series of articles featuring these little guys (OK, so yes, they are currently big):

I’m sure you’re as pleased to meet them as they are to meet you.   I hope to use these TPLemmings to help demonstrate how to use the various classes that TDF offers, and have a little fun at the same time!  Unfortunately you won’t be able to do any more than meet them today, but I do hope you’ll come back and say ‘Hi’.  After all they’ve got stuff to show you!

Conclusion

This article really serves as an introduction to the series, and gives you an idea of what TPL Dataflow is.  Future articles will cover the interfaces and classes supplied by TDF and go into detail on what types of problems they can solve.  And because I’d be remiss if I didn’t include some ‘code’ in the article, I’ll close with this little snippet.

Save the image above to your HDD, and then create a new [empty] WPF application.  Include the PNG file in an ‘Assets’ folder in the project, and then paste the following XAML into MainWindow.xaml:

    <Image x:Name="lemming" Source="Assets/TPLemming.png" Stretch="None" HorizontalAlignment="Center" RenderTransformOrigin="0.5,0.5">
        <Image.Resources>
        <Storyboard x:Key="Walk" AutoReverse="True" RepeatBehavior="Forever">
                <DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.RenderTransform).(TranslateTransform.X)" Storyboard.TargetName="lemming">
                    <DiscreteDoubleKeyFrame KeyTime="0:0:0.5" Value="-55" />
                    <DiscreteDoubleKeyFrame KeyTime="0:0:1" Value="61" />
                </DoubleAnimationUsingKeyFrames>
                <PointAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.Clip).(PathGeometry.Figures)[0].(PathFigure.StartPoint)" Storyboard.TargetName="lemming">
                <PointKeyFrameCollection>
                    <DiscretePointKeyFrame KeyTime="0:0:0.5" Value="122,0" />
                    <DiscretePointKeyFrame KeyTime="0:0:1" Value="0,0" />
                </PointKeyFrameCollection>
            </PointAnimationUsingKeyFrames>
            <PointAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.Clip).(PathGeometry.Figures)[0].(PathFigure.Segments)[0].(LineSegment.Point)" Storyboard.TargetName="lemming">
                <PointKeyFrameCollection>
                    <DiscretePointKeyFrame KeyTime="0:0:0.5" Value="244,0" />
                    <DiscretePointKeyFrame KeyTime="0:0:1" Value="122,0" />
                </PointKeyFrameCollection>
            </PointAnimationUsingKeyFrames>
            <PointAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.Clip).(PathGeometry.Figures)[0].(PathFigure.Segments)[1].(LineSegment.Point)" Storyboard.TargetName="lemming">
                <PointKeyFrameCollection>
                    <DiscretePointKeyFrame KeyTime="0:0:0.5" Value="244,244" />
                    <DiscretePointKeyFrame KeyTime="0:0:1" Value="122,244" />
                </PointKeyFrameCollection>
            </PointAnimationUsingKeyFrames>
            <PointAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.Clip).(PathGeometry.Figures)[0].(PathFigure.Segments)[2].(LineSegment.Point)" Storyboard.TargetName="lemming">
                <PointKeyFrameCollection>
                    <DiscretePointKeyFrame KeyTime="0:0:0.5" Value="122,244" />
                    <DiscretePointKeyFrame KeyTime="0:0:1" Value="0,244" />
                </PointKeyFrameCollection>
            </PointAnimationUsingKeyFrames>
        </Storyboard>
        </Image.Resources>
        <Image.Triggers>
            <EventTrigger RoutedEvent="FrameworkElement.Loaded">
                <BeginStoryboard Storyboard="{StaticResource Walk}" />
            </EventTrigger>
        </Image.Triggers>

        <Image.RenderTransform>
             <TranslateTransform X="61"/>
        </Image.RenderTransform>
        <Image.Clip>
            <PathGeometry>
                <PathFigure IsClosed="True" StartPoint="0,0">
                    <LineSegment Point="122,0" />
                    <LineSegment Point="122,244" />
                    <LineSegment Point="0,244" />
                </PathFigure>
            </PathGeometry>
        </Image.Clip>
    </Image>

Enjoy!

Introduction

Recently a tweet brought my attention to this blog post by @san0x, regarding the difficulties of binding flagged enumerations to UI fields in a meaningful and easy-to-use fashion.  The post was largely dealing with ways to work around the limitation of the IValueConverter, and its ‘context agnostic’ processing of values during the conversion process.  The IValueConverter does not know the context of the value being converted, only the value itself and an [unbindable] conversion parameter.

Scenario

I’ll avoid going into great detail about the scenario here, as it’s explained in detail in the linked post above, but the main focus is binding a series of checkboxes to a single flagged enumeration value.  The classes I’ll use in my example are adapted from the original post, I’ve included them here as a convenience to the reader.

    public class Species : ViewModelBase
    {
        /// 
        /// The  property's name.
        /// 
        public const string NamePropertyName = "Name";

        private string _name = String.Empty;

        /// 
        /// The species name
        /// 
        public string Name
        {
            get
            {
                return _name;
            }

            set
            {
                if (_name == value)
                {
                    return;
                }

                var oldValue = _name;
                _name = value;

                // Update bindings, no broadcast
                RaisePropertyChanged(NamePropertyName);
            }
        }

        /// 
        /// The  property's name.
        /// 
        public const string FlagsPropertyName = "Flags";

        private SpeciesFlag _flags = SpeciesFlag.None;

        /// 
        /// The properties of the species, as a flagged enumeration
        /// 
        public SpeciesFlag Flags
        {
            get
            {
                return _flags;
            }

            set
            {
                if (_flags == value)
                {
                    return;
                }

                var oldValue = _flags;
                _flags = value;

                // Update bindings, no broadcast
                RaisePropertyChanged(FlagsPropertyName);
            }
        }
    }

    [Flags]
    public enum SpeciesFlag : byte
    {
        None = 0,
        BreathesAir = 0x1,
        BreathesWater = 0x2,
        Photosynthesizes = 0x4,
        Eats = 0x8
    }

Note: My examples use the excellent MVVM Light Toolkit by @LBugnion, but are NOT intended to be examples of best practices when using the toolkit

Potential Solutions

Many developers [myself included], when presented with these types of problems, take a similar route to @san0x, attempting to coerce the value converter into something that is context-aware in any number of ways.  My personal investigations led me to first investigate using WPF MultiBinding [a little used, but occasionally very handy feature].  The promise of the MultiBinding was that I could pass in a number of bound values, and get back a suitable result [true/false].  As things usually go [for me at least], this worked fabulously for the first 50% of the problem, binding from the source –> the CheckBox.IsSelected property worked just as expected with a binding very similar to this:

<CheckBox.IsChecked>
    <MultiBinding Mode="TwoWay" 
                   Converter="{StaticResource FlaggedEnumToBoolMultiConverter}" ConverterParameter="BreathesAir">
      <Binding Path="Species" />
      <Binding Path="Species.Flags" />
    </MultiBinding>
</CheckBox.IsChecked>

This allowed me to reflect the flag value on the CheckBox, and changes to the value were automatically reflected on the UI without a lot of additional work.  The issue, of course, was how to update the underlying object when the CheckBox itself is used to change the value.  This is much harder, because the IMultiValueConverter::ConvertBack method has two problems:

1. Only a single [boolean] value, and [object] parameter are passed to the ConvertBack method.
2. ConvertBack must pass back an array of values, one for each Binding contained in the MultiBinding.

So… we’re stuck… there’s no way to convert from a single boolean back into a Species and its flags while only effecting the single ‘bit’ or ‘bits’ we care about.  We simply do not have enough information available to us as the time of conversion.  Sure, there are workarounds, and one such workaround is listed in @san0x’s follow-up post [using a standard IValueConverter], but in the end, those workarounds all ‘smell’ like hacks to me.  They all involve keeping the context of the binding around in some fashion during conversion.

Reframing the Problem

My suggestion on Twitter was to utilize the ViewModel to expose the individual flags as bindable properties to the View.  This successfully reframes the problem, but does suffer from the requirement that you update your ViewModel every time your enumeration changes [the View needs to be updated with any solution, since we’re using individual CheckBox(s)].  This ‘smells’ better to me simply because it does what ViewModel’s are supposed to do, abstract away the underlying model when necessary to make data binding feasible.  It also doesn’t resort to any of the same hacks required to get binding to work properly, and context is retained because it’s handled by the bound view model.

Proposed Solution

So with the reframing of the question in mind, I moved on to whether or not it would be possible to simplify the process of binding to that flagged enumeration.  I wanted to minimize coding effort, and have the solution work for any general flagged enumeration.  Back in the .NET 1.x/2.x days, I had worked on a number of projects that leveraged the ICustomTypeDescriptor and it’s siblings to provide customized design and run-time behavior for objects and properties.  Silverlight 5 and .NET 4.5 bring the ICustomTypeProvider to bear on the problem, and could be used in those environments.  For this post, since we’re running WPF and .NET 4.0, I’m going to utilize DynamicObject to provide for runtime binding of the flagged enumeration values.

The FlaggedEnumViewModel Class

I’ll start by introducing the class that enables runtime binding and implements the bits necessary for the bindings to resolve properly:

    public class FlaggedEnumViewModel<TEnum>: DynamicObject, INotifyPropertyChanged
    {
        private Func<TEnum> _getter;
        private Action<TEnum> _setter;

        public FlaggedEnumViewModel(Func<TEnum> getter, Action<TEnum> setter)
        {
            if (!typeof(TEnum).IsEnum) 
                throw new ArgumentException("This type must only be used with enumerations.");

            _getter = getter;
            _setter = setter;
        }

        public override DynamicMetaObject GetMetaObject(System.Linq.Expressions.Expression parameter)
        {
            return base.GetMetaObject(parameter);
        }
        public override IEnumerable<string> GetDynamicMemberNames()
        {
            return Enum.GetNames(typeof(TEnum)).Select(i => "Has" + i);
        }

        public override bool TryGetMember(GetMemberBinder binder, out object result)
        {
            if (!binder.Name.ToLower().StartsWith("has") '' binder.Name.Length < 4)
            {
                result = null;
                return false;
            }

            long checkedFlag = Convert.ToInt64(Enum.Parse(typeof(TEnum), binder.Name.Substring(3), true));
            long currentValue = Convert.ToInt64(_getter());

            result = (checkedFlag & currentValue) != 0;
            return true;
        }

        public override bool TrySetMember(SetMemberBinder binder, object value)
        {
            if (!binder.Name.ToLower().StartsWith("has") '' binder.Name.Length < 4)
            {
                return false;
            }

            long checkedFlag = Convert.ToInt64(Enum.Parse(typeof(TEnum), binder.Name.Substring(3), true));
            long currentValue = Convert.ToInt64(_getter());

            if ((bool)value == true)
            {
                currentValue '= checkedFlag;
            }
            else
            {
                currentValue &= ~checkedFlag;
            }

            _setter((TEnum)Enum.ToObject(typeof(TEnum), currentValue));

            OnPropertyChanged(binder.Name);

            return true;
        }

        protected void OnPropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }

        public event PropertyChangedEventHandler PropertyChanged;
    }

In the above code, I’ll call attention to three bits:

1. The constructor takes a ‘getter’ and ‘setter’ argument that wraps access to the underlying flagged enum store.
2. The TryGetMember method handles converting from the flagged value to a boolean
3. The TrySetMember method handles converting from the boolean back to the flagged value

The View/ViewModel

Utilizing the class is fairly straightforward, in my ViewModel, I’ve exposed a property [WrappedFlags] of the FlaggedEnumViewModel type that I use for binding on the UI, and the ‘Species’ property notifies that both properties change whenever the Species property changes.  This is sufficient to enable TwoWay binding on the View.

    public class MainViewModel : ViewModelBase
    {
        public string Welcome
        {
            get
            {
                return "Sample Flagged Enum Editor";
            }
        }

        /// <summary>
        /// Initializes a new instance of the MainViewModel class.
        /// </summary>
        public MainViewModel()
        {
            if (IsInDesignMode)
            {
                // Code runs in Blend --> create design time data.
            }
            else
            {
                // Code runs "for real"
            }

            LoadRandomSpecies = new RelayCommand(() => AssignRandomSpecies());
            WrappedFlags = new FlaggedEnumViewModel<SpeciesFlag>(
                                   () => Species.Flags, 
                                   (v) => Species.Flags = v);
        }

        /// <summary>
        /// The <see cref="Species" /> property's name.
        /// </summary>
        public const string SpeciesPropertyName = "Species";

        private Species _species = new Species() { Name = "Sample Species" };

        /// <summary>
        /// The Species we're working with
        /// </summary>
        public Species Species
        {
            get
            {
                return _species;
            }

            set
            {
                if (_species == value)
                {
                    return;
                }

                var oldValue = _species;
                _species = value;

                // Update bindings, no broadcast
                RaisePropertyChanged(SpeciesPropertyName);
                RaisePropertyChanged("WrappedFlags");
            }
        }

        public FlaggedEnumViewModel<SpeciesFlag> WrappedFlags { get; private set; }

        public RelayCommand LoadRandomSpecies { get; private set; }

        protected void AssignRandomSpecies()
        {
            Random rnd = new Random();
            byte value = (byte)rnd.Next(0, 16);

            Species = new Species()
            {
                Name = "Random Species " + value.ToString(),
                Flags = (SpeciesFlag)value
            };
        }
    }

Lastly, the view code is pretty basic, I’ll just call out one of the CheckBox elements to show how the binding was done:

    <CheckBox Content="Breathes Air" 
               IsChecked="{Binding Path=WrappedFlags.HasBreathesAir, Mode=TwoWay}" />

Conclusion

Transitioning from a converter-based approach to enhancing the ViewModel makes the problem much easier to implement and troubleshoot, it also avoids many of the pitfalls of introducing state to your I[Multi]ValueConverter instances.  Utilizing a DynamicObject class derivative enables you to write much less code and get the same overall benefit at runtime.  In a future post, I hope to find time to walk through enhancing the design-time experience to support setting up bindings in the VS2010 XAML designer.  I look forward to hearing your comments, or seeing alternative solutions to the problem.

Thanks for reading!

Sample Code: WPFBindingFlaggedEnum-20111013.zip (19 kb)

Intro

Everyone who attended //BUILD this year received two things:

1. A new Samsung Developer tablet which I won’t detail here, there’s sure to be loads of information out there beyond what I could provide here
2. A 32GB USB stick with all the Win8 //BUILD bits on it

So, naturally, my quest was to get my laptop and tablet talking to each other, both using the Windows 8 developer preview.  To do that, I needed to get Win8 running on the laptop.  The ‘best’ option I saw, given that the USB stick contains ONLY 64-bit stuff, was to go ‘to the metal’ and create a bootable VHD.

How to do it

The steps here are pretty straightforward, so I’ll just lay them out for you here.  NOTE:  This requires Window 7 Enterprise or Ultimate to be installed on the destination machine:

1.  Create a new empty VHD

1. Right-click your computer and choose ‘Manage’
2. Switch to the ‘Disk Management’ area
3. Choose Action->Create VHD
4. I chose a basic 32GB partition [fixed size] and choose a location.  For this example, I created one on my hard drive in “C:\Virtual Machines\Win8.vhd” and click ‘OK’
5. Right-click on the newly attached VHD and choose ‘Initialize Disk’, I chose the MBR option, then click OK
6. Detach the resulting VHD

2. Plug in //BUILD USB Drive

You can do this step whenever you like while the computer is rebooting, I chose to just do it before I started the reboot process.

3.  Reboot your Computer

This step is crucial, and your machine MUST be setup to boot from any plugged in USB device.

4.  Enter Win8 setup [but not all the way]

When the computer boots, you’ll be presented with the Win8 setup process, choose your keyboard layout and such and enter the setup process BUT DO NOT CLICK ‘INSTALL’.

5.  Enter the ‘Repair’ area

Below the ‘Install Now’ button, there should be a repair link that lets you repair a PC.  Somewhere in this menu is an option to launch a command window [under Advanced –> Command Prompt ??].  Do this and then enter the DISKPART utility.

6.  SELECT and ATTACH the empty VHD

Once in DISKPART, you need to select and attach your VHD [yes, this feels backwards].  This will enable setup to see the drive and continue.  This requires two commands:

1. SELECT VDISK FILE=”C:\Virtual Machines\Win8.vhd”
2. ATTACH VDISK
3. EXIT

7.  Resume installation process

Once done attaching the VHD, you can proceed with the install.  To do this, I just went back up to the root drive ‘X:’ in my case, and typed ‘setup.exe’.  This re-launches the setup UI and allows you to click ‘Install Now’.  During the install process, choose ‘Custom’.

8.  Finish VHD Setup

Inside the custom setup, when choosing the destination for the install, make sure you choose the newly attached VHD [usually the 30ish GB area listed as ‘Unallocated’].  Select that partition and click ‘New’ to create a new partition on the VHD, selecting the default size.  Then click ‘Format’ to format the associated partition.  Finally select the newly formatted partition and click ‘Next’.

NOTE:  The UI will tell you that it can’t install to that partition, but ignore the error and just click ‘Next’.

9.  WAIT… until the install process finishes, and when it starts to reboot, pull the USB stick

I don’t know if this is strictly necessary, but I did it to ensure I didn’t boot back to the USB again in error.  Win8 will have taken over your boot process and will complete the install and present you with the ‘developer preview’ software agreements and whatnot.

10.  There is no #10

'That’s it'!  Everything is working as expected, enjoy your new Win8 laptop!

It should be noted, that just like Win7, when the machine is starting up [after BIOS], you can hit F8 to get the boot menu [this is slow to come up], and choose ‘another OS’ and then choose to boot onto your Windows 7 machine as you used to.  You can probably also use bcdedit to set your Win7 install to be the default and use F8 from there to get into Win8 as desired.  I won’t detail those bits here, since they’ve been covered numerous times on other blogs.

That’s it, and as always, anything you do to your machine using these steps IS YOUR RESPONSIBILITY.  I accept no liability for any damage resulting from following these instructions