In our continuing series on observations made at the 2012 Codemash Conference, following is our Codemash Installment #3 of 10. As a reminder, Grand Rapids based, CQL sent seven of its developers to a large software development conference called Codemash. CodeMash is a unique event that educates software developers on current practices, methodologies, and technology trends in a variety of platforms and development languages such as Java, .NET, Ruby, Python and PHP. Different than most conferences, this three-day event ‘mashes’ together ideologies and individual developer experiences to discuss, learn and even attack certain problems.
Building Social Games Using HTML5, Window 8, Azure, .NET
Using HTML5 paves the way for creating social games that run across a variety of platforms, without the pain of developing unique code for each device. Using Azure enables a potentially inexpensive way to scale big for very low cost (I'm more sold on the cloud after seeing some of it in action.) For a social game like Tankster (Scorched Earth on HTML5), Azure Compute is used to host an ASP.Net MVC 3 application in an Web Role which uses WCF to communicate to the gaming client before game startup. As players gather before a gaming session starts, the app server offloads incoming requests to be handled by a combination of an Azure Queue and another Azure Worker Role. The Worker Role process (similar in concept to a Win32 Service) creates a specially named JSON-formatted file on Azure Blob Storage (think Amazon s3) for download among connected clients awaiting the game to start (files contain game info, names, weapons). Clients poll the file frequently looking for the game start signal similar in construct to a command query pattern. According to the team's tests, this is actually quite cost effective since it avoids costly CPU hours polling the "heavier" web app running on ASP Web Role.
Once started, the gaming clients communicate to a Node.js server running on an Azure Web Role to communicate among the gaming clients near instantaneously. Node.js is an open source single threaded, event-driven, non-blocking i/o, very fast, lightweight, perfect for data intensive real time application that run across distributed devices (hence great for games requiring real time communications online). It’s the current “hot thing” in web socket communications (built into HTML5). Microsoft has a program manager responsible for ensuring this works in the Azure cloud.
Using Azure allows a conceptual project to scale up to support increased incoming requests by spinning up more Web and Worker roles. Surprisingly, there is no autoscaling (adding more CPU etc as load increases) built in to Azure, but 3rd-party modules can be used to implement this functionality.
As an interesting note, Azure Storage Services (Blob, Table) maintains 6 copies of data spread across two geographically separate data centers.
Why Our Customers Should Care: Many clients are seeking cost-effective recommendations for how to scale their larger, data intensive solutions. As a software solutions provider, CQL continuously investigates available options including “cloud offerings.” Gaming solutions are large consumers of data-intensive processes, and provide opportunities to test the scalable support options that will house your next critical business application.
TDD in .NET vs. BDD in .NET
Test Driven Development (‘TDD’) gives you courage to improve the code base without breaking existing functionality.
- Typically your unit tests should not be ordered and run independently returning the system to its former state.
- Adhere to the "Highlander" principle...."there can be only one" thing the test is testing.
- TDD zealots would have you believe that you write less code...I agree that certainly you write twice the code when you do TED (test eventually development...writing tests after the fact).
- Certainly many more tenents, all Googleable.
Behavior Driven Development (‘BDD’) helps create test specifications that are easy to read even for non-programmers and allows the design of the software to be driven by its purpose. BDD enables a non-programmer to write stories ("As a admin when I enter Joe as the UserName and 'I wish I could be at Codemash' and press 'add post' I should see a page that shows 'thanks Mr. Non-programmer, sorry you couldn't come”) using an English-like language called Gherkin (e.g., what you just read).
In the context of a MVC web application, a Visual Studio plugin compiles it down to C-Sharp code which calls various tests you write. Running the complete test fires off a browser which increments through the steps, validating the test. Previously, only crummy tools on .Net were available. SpecFlow and Selenium are now more fully featured, compelling way to make this happen. The English-like language tests help ensure that clients get what's expected and what works...not just what works.
BDD allows more non-technical people (e.g., project manager or project sponsor at client) to more fully participate in the software development process.
Why Our Customers Should Care: Testing is critical in the software development process. There are different ways in which developers engage clients to perform these tests, but ultimately any testing process that makes it easier for a non-technical client to participate in the software development process is good for everyone – better outcomes for the developer (faster confirmation/feedback is provided by the client) as well as for the client (more cost effective solutions in a shorter amount of time).
Dynamics In C#
There is room for the ‘dark magic’ of dynamics in a statically typed language like C#. MVC3 is already using it with the concept of a ViewBag (replacement for ViewData["somevalue"] in older versions of MVC). Though typically we are using a more strongly typed ViewModel which I think is better anyway.
Dynamics are much better for dealing with an undetermined API (JSON from the browser, or RavenDB, or Couch, Mongo) or metaprogramming (programs writing programs. A practical example would include https://github.com/markrendle/Simple.Data a dynamically generate data access library.
Nonetheless, the drawbacks are fairly significant so care must be used. Code is much less self-documenting (no contextual documentation), no intellisense (argh!). Really to use it extensively, you better be using a solid TDD approach as a team as it requires quite a bit of discipline.
Why Our Customers Should Care: Data is ‘king.’ Technology that makes it easier to for developers to create solutions for manipulating and exposing this data is extremely important. Customers must be aware that there are definite concerns regarding how this data is treated, and the importance of providing enough time/opportunity for developers to ‘test’ their solutions.
Check back for Codemash Installment #4 of 10.