Allen Conway's .NET Weblog

Exploring all things .NET and beyond...

Visual Studio LIVE! Chicago Exclusive Discount Code!

Hey everyone, I have an exclusive discount for you to use for Visual Studio LIVE! Chicago upcoming May 5-8. Use code UGCH05 or click on the following link http://bit.ly/UGCH05Reg to save $500!! 

If you are a software engineer, developer, or IT industry professional you need to check out the main site http://bit.ly/UGCH05 and see the wealth of content to be presented. This is certainly a conference to attend or ask your boss about attending if you have the opportunity.

If you are curious what the conference is like, see my series of related posts directly from the conference by clicking the following link: VSLive! Blog Posts


HTTP Error 405 When Making a PUT or DELETE Call to Web API Service

If you build ASP.NET Web API services and are testing against IIS, you might encounter the following error when trying to execute a HTTP PUT or DELETE:

Error Summary:

HTTP Error 405.0 - Method Not Allowed

The page you are looking for cannot be displayed because an invalid method (HTTP verb) is being used.


Searching the web actually yielded a ton of results but as usual they were wide and plentiful making it difficult to discern the correct solution. I'm using VS.NET 2012 and VS.NET 2013 on Windows 7 and Windows 8 (variations of these), so this solution is current.

Here it is: a combination of updating the values for a few of the HTTP Handlers and modules in the web.config will solve this issue. 1st the solution, which resides within the <system.webServer> section within the web.config file for the Web API project:

<system.webServer>
  <validation validateIntegratedModeConfiguration="false" />
  <modules>
  <remove name="WebDAVModule" />
  </modules>
  <handlers>
  <remove name="WebDAV" />
  <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
  <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
  <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
  <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
  <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
  <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
  </handlers>
</system.webServer>

The explanation:

  1. The default ExtensionlessUrlHandler-* handlers displayed above are set within the %userprofile%\documents\iisexpress\config\applicationhost.config file and do not by default allow HTTP PUT and DELETE verbs. By removing and re-adding the handlers with all of the HTTP verbs we will allow, processing will continue as expected.
  2. Unfortunately updating the handlers is not enough. The WebDAV HTTP Publishing feature will block HTTP PUT and DELETE calls regardless of our previous modifications. WebDAV is a feature allowing access to files and folders via the internet as an alternative to FTP. If you are not using it in the Web API project, then removing the module will free up the restriction on these HTTP verbs. If you want to read more about what WebDAV is, please read this.
After these modifications have been made try using Fiddler or Postman and make a HTTP PUT or DELETE call and it should now work as expected. If you are reading this and are using a HTTP POST for all operations and bypassing a good RESTful design by having multiple POST actions on a controller (only distinguished by the action name in the URL as opposed to the verb defining the route), reconsider and try these modifications if in their absence had previously prevented you from creating that rich RESTful service you initially set out to make.

Creating a Unit Test Using Moq to Stub Out Dependencies

One of the main powers behind a mocking framework like 'Moq' for use with unit testing is the ability to write true unit tests as opposed to integration tests. Remember unit tests should run quickly and provide quick validation of the code being tested. They should be free of using external dependencies and rather focus on testing the code at hand. Examples of these dependencies could be a database, web service, 3rd party component, network share, file, etc..

If all of your unit tests were actually integration tests, it could potentially be lengthy to call and test, and even more challenging to configure. What if you are developing offline and that web service is not available? Should you then not be able to test your code? The answer of course is 'no' you should still be able to test your code.

Use of a mocking framework like Moq allows us to stub out these dependencies with expected behavior, thus allowing the code to be tested independent of the actual integration with that dependency. The primary example of this would be to stub out data access calls that would normally at runtime actually call the database.

The following example relies on the Repository pattern and an Interface provided with the calls that would be implemented to reach out to the database. This abstraction allows Moq to substitute the implementation and behavior to a predetermined expectation for our unit test. If you happen to already be using the Repository pattern but not unit testing, you should be able to fit the code below after understanding it into your solution to being building up some unit tests.

Here is the Repository Interface we are working with for the example:

public interface IRepository<T> where T : class 
{
  IList<T> GetAll();
}

Here is the implemented Repository class. There is a lot more abstraction we could do to the Repository in addition to using the UnitOfWork pattern, but the focus here is on the unit test so this is a basic implementation:

public class PersonRepository : IRepository<Person>
{
  private AdventureWorksEntities db = new AdventureWorksEntities();

  public IList<Person> GetAll()
  {
     var people = from p in db.People
                  select p;

     return people.ToList();
   }
}

In this test project I used Entity Framework and connected it to the 'AdventureWorks' database. I expanded on the Person POCO and added an arbitrary method that would find an employee by 1st and last name. In reality a method like this would probably be on a generic repository that takes an expression as the parameter, but again the focus here is to show how we can unit test this method that uses the Repository without actually calling the database. Here is the Partial Class I added with the 'GetPersonByName' method:

public partial class Person
{
  private readonly IRepository<Person> personRepository;

  public Person(IRepository<Person> personRepository)
  {
    this.personRepository = personRepository;
  }

  public Person GetPersonByName(string firstName, string LastName)
  {

    var allPeople = this.personRepository.GetAll();

    return allPeople.Where(x => x.FirstName.ToLower() 
                                     == firstName.ToLower() && 
                                   x.LastName.ToLower() 
                                     == LastName.ToLower())
                          .FirstOrDefault();
  }
}

The last coding step is to write the unit test. I 1st need to build up a Person collection that will be used by the framework. This can be done in a Setup method with the [TestInitialize] attribute assigned. I will create a simple test that will ensure a valid instance of Person is returned. The idea here is to test the code within the method to make sure that logic is sound and working as opposed to the actual database call itself. I will leverage Moq to inject the Mock Interface into the Person class. If you have not used Dependency Injection, here is another 'plus' for doing it and it's benefits for testing. Here is the complete PersonTest class with the simple unit test:

[TestClass]
public class PersonTest
{

  private IList<Person> people;

  [TestInitialize]
  public void Setup()
  {

    people = new List<Person>()
    {
      new Person()
           {
             Title = "Mr.",
             FirstName = "Allen",
             LastName = "Conway",
             PersonType = "EM"     
           },
      new Person()
           {
             Title = "Mr.",
             FirstName = "John",
             LastName = "Smith",
             PersonType = "SC"
           }
     };

  }

  [TestMethod]
  public void PersonSearch_ShouldFind_ValidInstance()
  {

    //Arrange
    var repositoryMock = new Mock<IRepository<Person>>();
    //Setup mock that will return People list when called:
    repositoryMock.Setup(x => x.GetAll()).Returns(people);
    var person = new Person(repositoryMock.Object);

    //Act (mocked up IRepository will supply the data when calls are made to the repository)
    var singlePerson = person.GetPersonByName("Allen", "Conway");

    //Assert
    Assert.IsNotNull(singlePerson); // Test if null
    Assert.IsInstanceOfType(singlePerson, typeof(Person)); // Test type

  }

}

If you run the unit test above you will see it passes and passes quite quickly (in about 100ms on my machine). Now if I had to actually call out to the database it would have returned the 20,000 rows in the Person table and that is not what I'm testing here. To prove the mock object (in this instance it's actually a stub returning a known state but that's for another post) behaved and returned the collection we expected, right click on the test name and select to debug (I'm using the MSTest runner in VS.NET 2013). If you walk through the code, guess what is returned when the call to .GetAll() on the repository is made within the 'GetPersonByName' method? Our collection created within the test class:



This is only the basics of unit testing and using a mocking framework like Moq, but I put it out there because I see such a disparity between creating unit tests and not creating / using them in our field. It seems like people are 'all in Gung-Ho' or do absolutely none of it. Hopefully this post showed a straight forward and simple example for those wanting to get into unit testing or begin using a mocking framework that are not already doing so today.

Using Pencil to Create Wireframes for GUI Prototyping

image courtesy of link 
If you have ever lifted weights for strength or toning, you probably know there are some muscle groups in your body that are stronger and easier to work out than others. For me the muscles in the middle of my upper back seem to always be the weaker ones.

I offer this analogy as a segue into the 'software engineering' muscles of all the disciplines and hats we must wear. One discipline that I'm not particularly an expert at is UI design. Sure I've used the splash of rich web content on sites over the years, but nothing that's getting awards for style. Listen, I don't spend day in and day out doing it so I don't consider myself a seasoned expert. Like DBAs are to database development, UI/UX Designers make entire careers out of the trade.


However most of us 'all around' software engineers do not have the luxury of working with a true designer, and at some time or another must design a UI from scratch. We probably result to white board drawings, paper and pen, or just going straight to the VS.NET IDE designer to lay down some HTML, XAML, or raw form controls.


One main prototyping tool that comes to mind immediately is Sketchflow. Sketchflow is a great tool which was integrated with Microsoft Blend, and now Blend is a part of the VS.NET IDE install (since VS.NET 2012 - check versioning for support). About a year ago I was also introduced to a free tool named Pencil for creating wireframes for GUI prototyping in applications. The later tool 'Pencil' I will speak about today.

image courtesy of link
I've had mixed opinions about 'prototyping' over the years for various reasons I could write in another post. Most of my angst came from corporate environments where accounting, HR, or some other internal company party was requesting a custom application, and was a bit too overreaching in wanting to design the application which was a slippery slope. In many of these situations it was best to have the end party define the business problem and let the engineers do what they know best: solve that problem via a custom application. 

image courtesy of link
However this is not always the situation and in many environments (especially where the client is paying for an application), a sketch or mock-up of the final product is required. Could you imagine ordering and paying 25k for a car at the dealer that you had no idea what it would look like, but rather would get you from point 'A' to point 'B' because that was your problem? No, you must know what the car looks like as it is a big part of the purchasing decision. "Hey I wanted a 4 wheel mini car not a moon bus!"

Regardless of the scenario, you control how widely exposed the wireframes you create are distributed. You may only use them for yourself to have a visual of what to do when you dig into the HTML, XAML, etc.. You may choose to keep them internal to your development team that you might be delegating the task to for creation. Lastly, you might be required to show a physical design to a client before they will approve of it and allow you to proceed. Regardless of the audience this is a great tool in the toolbox for UI mock-up / sketch / prototyping design.


Begin by downloading Pencil from the 'Pencil Project' website located below:


Pencil Project


Once installed you will see a blank canvas where you can drag shapes, controls, etc. on to the screen. I'm going to pull a few shapes onto the screen that contains a few tabs as seen below:




I just threw that sketch together in a few minutes and is quite rudimentary. However, if needing to really design an application's GUI this tool has a nice set of shapes and controls for your needs. In fact in the newer versions, shapes have peen added for iPhone and Android tablets to mock up screens for these applications as well.


The one gripe I have about the tool is getting used to how to manipulate the shapes. When I 1st dragged an iPad tablet on it was too large for my screen and the 'size' values were grayed out in the toolbar. I'm accustomed to a right-click -> properties -> change values methodology from most application but this does not hold true for Pencil. It takes a little getting used to, but for being 'free' I can not complain. Some controls like a table are defined by pipe delimited values like displayed below:




Lastly the individual mock-ups can be exported a .png files for use in documentation, and the entire Pencil Project file (*.ep files) can be exported for storing in your source or document control systems.


If you have not done any prototyping before, or used some rudimentary tools to attempt the process, give Pencil a try. It might take that design or requirements document to the next level on your upcoming project. Tools such as these will certainly help elaborate and articulate the end product in a visual as opposed to a verbal manner.

Visual Studio LIVE! Orlando 2013 Day 5

Workshop: Deep Dive into Modern App Design and Development
Brent Edwards, Principal Lead Consultant, Magenic 



The day long track with the Modern App team is going to offer a chance to go into detail of the creation of a 'Modern App' and specifically the 'MyVote' application. To review what a Modern App is, it's a combination of mobile, web, and desktop applications across platforms that communicate using APIs exposed in the cloud. If the explanation sounds vague or incomplete it's because it's difficult to explain 'modern.' Shortest explanation might be a cross-platform, available anywhere and get data from anywhere application.

We begin by reviewing the architecture for the voting application. The CSLA.NET Business Object (open source) framework was used in the application, and for a few of the UI endpoints the BL existed on both the client and the server (identical code). The purpose for doing this is to be able to share functionality and behavior both on the client and server. For example we can validate data quickly on the client and check it again in addition to washing through additional rules on the server to make sure it's clean before being persisted to the database. The logical layering of the application is shown below and which layers share the busniess logic (image courtesy of Visual Studio LIVE! and Brent Edwards):




One interesting thing were some of the compiler directives used to differentiate which platform is currently running. These were used in the busniess logic and was a nice way to explicitly tell if we were running on the client or the server. For example the Entity Framework code for CRUD operations were inside of one of these directives thus making this code only run under the proper platform on the server. A directive example looks like the following:


#if !NETFX_CORE && !WINDOWS_PHONE

These are actually what are called 'Conditional Compilation Symbols' that are found under the 'Build' tab in the project's properties.They are pre-defined when the project is created. They can be changed, but it's best to just leave them as their default value and use as needed. The best practice on this is to create a base class with common functionality with additional abstract methods that can have platform specific implementations. Combine this approach with the compiler directives for the cleanest approach. Just simply using compiler directives could create a sea of 'if' statements which we know will lead to some intermingled spaghetti code. I have a feeling the branching on these directives will be ironed out in the years to come and we'll figure out a more unobtrusive way to declare the different platforms for segregating logic.


When building a Win8 app you have to decide which languages to develop in to create the app. The main (2) choices are C#/XAML or HTML/JS. Deciding on which languages to use might be based on the developers background. Web teams might gravitate toward HTML/JS, and WPF/Silverlight guys might choose C#/XAML. However the Windows 8 version of XAML is trimmed down a bit to what you might be used to, and on the JS side the WinJS is a bit picky and makes it more challenging to write. One important note is if you are developing for WinPhone you have to use C#/XAML as the HTML/JS route is not supported. If you want all platforms, you should go with the C#/XAML route.


A brief review of MVVM was given by Brent (this guy knows his stuff on MVVM - read his article Leveraging Windows 8 Features with MVVM for more information). Some of the high points are that it separates presentation from functionality (SoC), promotes testability (because of the former - unit testing), works great with data binding (reduces a lot of the binding code - observables), and makes it easier to collaborate with designers (like a real designer and not some developer making a UI). I'm not sure if anyone doing WPF or Win8 applications are not using MVVM, but one should absolutely use this logical architecture when selecting these technologies.


Quick Informal Poll:
How many are Windows Phone Developers: 1 person

Brent validated something I had wondered about over the years in regards to physical project organization for sharing files. Jason Bock had covered this the other day as well. The use case is when we have multiple projects that need to share a common set of files. In VS.NET, if you have a set of source code files you need to share across several projects, make sure to add them as 'linked' files as opposed to 'Add existing item -> Add.' Using add existing item will make a complete copy of the file to the secondary project. This is a bad idea especially when under source control. The better method is to use 'Add existing item -> Add as link' which creates a pointer to the original file. I've been doing this for a few years already with AssemblyInfo and SolutionInfo files, but wasn't 100% sure on mainstream practices in projects for this process. If you are adding an entire existing project, make sure to follow the same process.


Azure Mobile services was used with the mobile portions of the 'MyVote' app. The nice thing is it provided 'oAuth done easy' with (4) main options: Twitter, Facebook, Microsoft, and Google. The caveat to this is that each different login source used by the client ends up looking like a new and different user. Therefore the client should use the same (or be instructed to do so) method for login to have the same experience. However if you need domain authentication then Azure Mobile Services (and really oAuth) is not the correct route to go.


Push notifications are the ability to have the server push information or updates to the client without 1st being pinged for. Elements like Tiles, Badge, Toast notifications can alert users of new information. For those of you that are not sure what a toast notification is - think visually of the little box that pops up when you receive a message in Outlook.


In Windows 8 'Contracts' are agreements between one or more apps on the system. It provides a consistency to interact and work with other apps. Some sample contracts are search, share, and settings and are the recommended contracts to use at a minimum. In fact if you have internet access anywhere in your app, you need an external privacy policy created and linked to in the Settings charm, and also have a contract for the Settings contract. The Charms menu is off to the right in Windows 8.


You also have to consider which search features are available in you Windows 8 application. The search feature in Windows 8 allows your app to be searched from anywhere in the OS. You have to decide which portions of your app can be searched, and how to parse and return results. In the case of the 'My Vote' app, they allowed the polls to be searched. The Share target can be setup and configured from the application.


The same configuration goes for the 'Settings' charm. You don't want the user to have a huge amount of things to configure, but they should have the settings available to configure their experience. For example a simple 'Log Out' function in the settings menu.


Aidan Ryan, Lead Consultant, Magenic Technologies 




The next phase focused on AngularJS with TypeScript and WebAPI for the web portion of the MyVote application. AngularJS is a complete client side framework for SPAs (Single Page Applications). By complete it literally can do everything in the form of data binding, DI, routing, services, REST client, and Promises. The ng-* directives from Angular are used to add behavior to the markup. It's maintained by Google, so odds are it can outlive a lot of the other fad JS frameworks that come and go in popularity.

TypeScipt is a Microsoft backed product to more closely look like ones writing in a managed language with more concise constructs, yet emits JavaScript. The .ts TypeScript file syntax looks strikingly similar to C#. 


Bundling and minification was reviewed and can be used in both web forms and MVC. 'Bundling' packages up all of your .js files into a single file (single HTTP request). For debugging purposes the raw files are delivered, but in production all of the files are minified removing whitespace and compacting to reduce byte size. This makes the single file being delivered to the client much more efficient. Ordering in the Bundles.Add.Include() statement does have precedence by order added characteristics, so make sure to order correctly.


The idea used here is to tap into an API exposed that can deliver data or information (i.e. WebAPI RESTful service or Azure Mobile Services) and then use a robust JS framework like AngularJS alongside of Typescript to create a complete and fully functional website. In this manner we don't even require ASP.NET (speaking about front end only) and hence one of the main objectives behind SPAs. Aiden used just a sprinkle of C# on the server in the form of custom Helpers to reduce the markup required, but if needed he could have done a purely JS implementation with the framework chosen.


One of the things I always like at these conferences is being able to not only learn but validate things big and small I'm doing on a routine basis. When Aiden was speaking to exception handling he stated that you don't typically want to handle exceptions down in the lower layers, but allow things to naturally bubble up and handle at the highest layer. This is a common practice I use myself. In ASP.NET terms that's in a custom handler for MVC apps, and in Global.asax for web forms applications.


A quick conversation revolved around 'UX Review', which is a cool site where you can submit your site and get honest feedback on your design. This is a great way to not work in a vacuum and get some constructive criticism or checkpoint with the wider community.


The last topic in the portion of this section was around SignalR. SignalR allows push/pull functionality to clients usable in an abstracted manner. The reason I say 'abstracted' is because the amount of code to do something fairly complex under the covers, is actually only a few lines of code. I really like SignalR and I'd say the (2) things I'm most interested in investigating further and using post conference are SignalR and TypeScript.


Lou Miranda, Technical Engineer, Mobility Group, Magenic Technologies 




Post-lunch started out with Lou speaking to modern iOS development. Now anyone reading this blog or who knows me, knows I have enough knowledge to fit in a thimble on the topic of Apple products and development. This is a good opportunity for me to get outside my shell and learn something new.

Lou demonstrated the MyVote app as it looks on an iPad. This reoccurring theme is the one that ties back into the architecture shown at the beginning of the session. All of these different UIs are using the same back end which is the way for now we need to create modern applications.


The thing that did hit home immediately was that iOS apps being developed use the MVC architecture. Xcode is the IDE Lou used, and runs on a mac to create the application.The app project has the following organization: Project file, Assets, Views, ViewControllers, Frameworks, and AppDelagates. iOS app code is written in Objective-C which is a specific set of the C programming language.


Lou was taking us through the Xcode IDE and how the project is arranged. Like any IDE including VS.NET, Eclipse, etc. they have all the main features for project organization and development. I really like the Storyboarding feature which had a graphical display of the forms and their relationship.


I'll be honest though I wasn't going to learn a whole lot as far as being productive about developing Objective-C code using Xcode in the amount of time being presented today. Being that the room is 99% developers on the Windows stack, I'm sure the sentiment is similar. However, iOS is still a major player in the 'Modern App' era, so understanding the technology and languages not so familiar to us in current day could change quickly in the near future.


Xamarin (which unfortunately I did not see as much this week about as I would have liked - too many great sessions) will help us to only have to write C# code which will then compile natively to Android and iOS. This will reduce the need to write natively using Java and Objective-C respectively. The UI portion creation using Xamarin I unfortunately cannot speak to intelligently at this point. The other day I sat at the Xamarin table during the 'Birds of a Feather' lunch in an effort to learn more about the product especially since there is a relationship with VS.NET 2013. To my understanding Xamarin will translate even UI elements cross platform to their equivalent, but you will still need to manage the separate UI projects to customize their independent platform needs. Anyone can happily correct me on this because I'm still in the early learning stages on this technology.


Before anyone panics though, from everyone I've talked with and heard speak, there are developers on hand at companies specifically used/employed for creating these types of applications. Meaning, it would probably be the 'exception as opposed to the rule' for your boss to come over in the middle of your ASP.NET MVC or Win8 project and tell you to install Xcode to create a mission critical iOS applications. If this occurs, scrounge up some dough for Xamarin ;)


One very interesting conversation surrounded the iPad, iPad mini, iPhone, and the other array of portable devices. Testing and QA can be a challenge, but in reality some UAT does need to be done on each device to make sure it operates correctly. If you have a true designer on staff, this will be easier as they know how to develop 'contextually' to the device they are targeting. This is a nice segue into the next presenter, Anthony, that does just this - design applications.


Anthony Handley, UX Practice Lead, Magenic 




Ok I wish I had the opportunity to work with a guy like Anthony (dedicated graphic designer). He is what most of us talk about wanting to have on a team, but most companies look at as a luxury. The result? Programmers turned designers creating the world of grid view black, grey, and green applications which as Billy Hollis shouted from the rooftops all week that we should not be doing. 


As user's personal experiences continues to desire more stylized, rich, and touch based applications, the desire to look at something today that appears to have been done in 1998 using WinForms for VB6 will not fly anymore, or at least not be as competitive. Business productivity applications are not exempt from this issue either, as user's are becoming more sophisticated and accustomed to seeing a more polished design.


It's been a while since I used Microsoft Expression Blend + SketchFlow. Last I used it regularly was when I was doing Silverlight development and using Expression Blend 4. Now it's included with a VS.NET install; just look for the shortcut in the same folder.


SketchFlow is a great prototyping and interaction test tool for WinPhone, HTML Store Apps, WPF, and Silverlight applications. You simply drag controls onto the canvas to begin designing the application. Anthony mentioned that Rocky (Lhotka) encourages the designers to leverage the tool heavily and they should not have to write 1 line of XAML. SketchFlow actually will create the XAML from the prototype, but as he mentioned, this is typically not production ready code so be careful in turning a SketchFlow design into a production system.


You can use the tool in a more broad sense to prototype screens and mock-ups for technologies beyond XAML based applications. Anthony has actually done pixel accurate iPhone app designs using SketchFlow, so you can broaden the use of the tool if needed. Personally I have used more rudimentary yet still very useful (free) tools like Pencil to wireframe up web pages and the like.


The SketchFlow Map provides a nice graphical map of the relationship between the pages within the application. Once you've created your pages and you are actually doing a XAML based application, you can view the XAML and make tweaks if needed. The example that was created was to sketch out the screen for the MyVote application and the authentication screens. 


I can only imagine how awesome it would be to work with a designer that delivers either the completed wireframes or even the full front end using a tool like this to the engineers ready to interact with for the layers below. Developers creating a UI like a designer, or attempting to master Databases like a DBA typically don't do as good of a job as dedicated (design) professionals. The result is the knowledge for the wings off app development runs too lean because we already have our plate overflowing trying to understand the massive amount of language and development features we need to know to be relevant. 


There is a great book called The Pragmatic Programmer that has a great chapter on prototyping and tracer bullets that delves into these topics and there usefulness.


At the very end of the session there was a Q&A on anything from the week. A few points on Xamarin to note. You need Xamarin for Visual Studio or Xamarin Studio to help with the UI layout for Android and iOS and this is an additional IDE with a cost.


One interesting conversation surrounded around 'which technology' to use when creating new applications (the million dollar question by the way). Aiden mentioned WPF is ever present and still be used as a front runner for some of the non-touch, heavy data and analytical applications. This to me is the definition of the 'non-sexy' world which we call corporate america. However there is no '1 size fits all' technology solution, so we must asses our users, their environment, and their problem, to help us decide which technology to use.


Day 5 Wrap Up



That's it! The #Live360 Orlando 2013 conference is in the books. Another fantastic year and I'll look forward to the conference next year. I believe the main focus and theme of the event this year were 'Modern Applications' and 'Where are we going on the Microsoft Stack?' For now I think the answer to the latter is 'steady as she goes.' We'll help decide and pave the future based on the technologies the community gravitates toward combined with the needs and wants of the consumers shaping what we create.

I believe the technologies / methodologies / best practices that stuck out to me the most this week are the following:

  • Modern Application Design (all points end to end)
  • Parallel Design Patterns
  • Entity Framework 6
  • SignalR
  • TypeScript
  • PhoneGap
  • Xamarin
  • UX/UI Design Techniques in the Modern Era
I am thankful to all the great friends and professional acquaintances I made this week. Please keep in touch and to the rest reading this I'll see next year at VSLive!


Award for the biggest thanks deserved:

The #Live360 staff - fantastic conference, thank you!
The Magenic Team - GREAT job on the Modern Apps Live Track. You all are the best, and see you next year!

Visual Studio LIVE! Orlando 2013 Day 4

Building Real-Tim, Multi-User Interactive Web and Mobile Applications Using SignalR
Marcel de Vries, Technology Manager and Microsoft MVP, InfoSupport



I have always enjoyed Marcel's (the Dutch guy as he slides humorously show) sessions and am looking forward to getting some more information on SingnalR in ASP.NET. Great presenters (which honestly all #live360 presenters I've covered are) can combine knowledge, content, and even humor to make those attending have a much better understanding on a topic in just 75 minutes. Marcel is certainly in this category.

Before we get into SingnalR, we need to explore the current push/pull techniques we have. The 1st are web sockets, but they are only partially supported in browsers (still in W3C draft). Server side events (also a W3C draft) are another method that requires the client to have an extra channel for the data to be sent. The proxies also need to understand the content-type:text/event-stream. There is also 'long polling' which is really a fake push/pull method that responds to POSTs when the server has new information to send to the clients.

SignalR allows us to have real-time ability in our web application while extracting away the low level complexities of making the work required occur. It is a part of the ASP.NET web stack. The net result is a super simple and easy to use tool to get real-time information for things like dashboards, collaborations, messaging, or any other type of data that would normally require a Post back to the server or a page refresh. It's a great option right now that has strengths in places where the other frameworks and methods have weaknesses, yet sits atop all of these protocols to make the communication occur. It was advised to use .NET 4.5 because of the support for web sockets which is probably the best method if supported, but SignalR will fall back on the other methods when needed for scenarios like using older browsers (i.e. IE8). You may also dictate via configuration which protocols are allowed if needed. SingnalR does support web sockets, server events, long polling and forever frame.

The persistence connection in SignalR is the base class for our own connection class with overridable methods like 'OnConnected', 'OnReceived', and 'OnDisconnected'. To begin make sure to pull in the SignalR components from NuGet. I love the presenters that are able to articulate new technology with simple examples. Sure we will take it up a few notches in the real world, but if you are trying to sell (I use the word loosely) the technology, show me how easy it is to use. The example Marcel used was a vanilla web app doing chat/messaging. There were literally a few HTML controls, a little jQuery, a few lines of code in C#, and the example was up and running. The C# code was 1 line of code in the event to handle the message. As much as I use ASP.NET I'm amazed I have not yet had a use case for SignalR (I've used long polling in the past). Entry point pain: Low. Gain in user experience: High.

In SignalR 'Hubs' let you provide a semantic API between the client and server. SignalR creates a proxy between the 2 parties. The hub provides dispatch calls to filter clients using Clients.All, Client.Others, and Clients.Caller. You can use the context to read information about the call which seems quite useful and provides ConnectionID, headers, cookies, user, etc.. There is also 'Group' ability to allow arrangement of clients for communication needs. The hub can be set up in the $dcoument.Ready() function, and wire it up to the server proxy method.

Another informal poll was taken attached to a humorous story. Marcel tried to order a cake for his father's birthday recently and when he went to check out there was no 'Buy' button. He had to use Chrome for the site to work :P Oddly my experience has been the opposite. I typically use IE for shopping, knowing many still develop against it by default knowing it's wide adoption for the general public.

How many people are using IE all day long: 40%
How many are using Chrome: 55%
How many are using Firefox: 5%
How many are doing Windows Phone development: 2 people (Marcel: "Wow so many")
How many are doing WinRT: 2 people (Marcel: "Wow Microsoft is really moving along with that")

Ok what I found interesting was the use of other platforms for using SingalR: WinRT, WPF, Android, iOS through ViewModels to the different clients. Azure websites also support SignalR, so connecting a few dots with earlier sessions as well. He demonstrated an example using WinPhone, Android, and a local client using shape movement. A simple orange box was drawn and as he moved it around, the movement was shown identically on the remote device (actually a local emulator). He leveraged Azure in the middle to pass the data between.

Building Data-Driven Mobile Web Apps with ASP.NET MVC and jQuery Mobile
Rachel Appel, Appel Consulting



I have been following Rachel for years on Twitter, so it's finally nice to meet her in person and hear one of her sessions. I had the opportunity to eat lunch with her today and she is a really cool person too! I love her 'Sweet 127.0.0.1 Chicago' on her opening slide :D We engineers are so creative.

She began by going through the overview of ASP.NET MVC and its architecture. I actually think this is quit useful even for some seasoned MVC developers because I believe there are a lot of anti-patterns that exist even in MVC. It's always nice to have a refresher and speak to the purpose of the different components.

There was another good conversation surrounding Entity Framework and a code first approach. It's interesting to hear the preface that "if there is no DBA, or the DBA isn't DBAing this database" then as developers we are more comfortable in code and can have the code create our database. I still have a tad bit of heart burn over the following syntax (which is actually a toned down version of what I really am speaking to):


[Key]
public int ID {get; set;}

Now the above only has the [Key] attribute, but attributes for the SQL type, length, and other constrains can be added as well. I suppose I'm in a limited number that doesn't like SQL notations bleeding over into my code. Probably no more than a DBA would like it if I could place C# code in my stored procedures. I suppose if I have a very straight forward object model that will map well to a simple structure eventually in the database, I could go with the code 1st approach.

The DBContext class is a fancy 'connection' class where we can wire up our different models that are going to work with the database. We then use 'DBSet' with our collections (remember to make 'virtual' if doing navigation properties) to get it wired up. To connect all the dots we initialize the EF classes in Global.asax (for ASP.NET).

One convention in MVC is using a naming pattern to align the DBContext class to the web.config connection as long as the names are the same. This was we can switch between contexts by initializing the class needed at runtime.

A quick review was displayed on MVC scaffolding. To this date features like this are the helpers that can assist those still doing web forms and old ADO.NET calls and help provide a smooth transition to ASP.NET MVC and Entity Framework. Since EF is Microsoft's flagship ORM there is a close relationship to MVC and the ability to rapidly create data driven MVC applications is right there for developers.

One interesting thing I had not know upon reviewing the different view engines is that there is a 'Web Forms Controls' engine. This would create a style similar to web forms but is frowned upon because it's not really the MVC way of doing things (and I agree). However if needed it does exist. Most today are using the Razor View engine and the HTML Helpers. HTML Helpers are kind of like server controls without all of the view state and bloating. The similarity is that the Helpers are there to more quickly create controls in the View without doing it all from scratch.

She did a GREAT job of explaining the testability of Controllers in MVC. In web forms it is really difficult to hook into an entire page and it's event cycle to test it using unit testing. In MVC we can easily just instantiate a Controller instance and test it. Then we can have a complete suite of tests surrounding our controllers. If you are using a more advanced pattern where services are injected into your controller, you can mock up the service and still test the Controller's functionality. MVC in it's raw form is superior to web forms from the testabilty aspect.

Model binding in MVC uses convention to automatically map form data to our models when asking for the object in the parameter list of the Controller. This is another one of my favorite features in MVC. Remember the days of manually mapping form control data back to hydrate objects? The ViewModel or Model used in the Controller POST method combined with model binding delivers a fully hydrated object upon being called.

jQuery mobile is built atop the jQuery framework with support for HTML5 and touch bringin us into the modern era of development. With very change we can get a mobile version of our application up and running quickly. After downloading jQuery mobile, new JS scripts and CSS will be added to the solution. Go to _Layout.cshtml (like a master page from the web forms days), add the script references, and begin to use the data-* (HTML5) attributes to denote mobile in containers and wrappers. 

You will get a Responsive UI now as jQuery goes through and applies the styles to make the page have mobile attributes (like touch enabled). There is no need to create separate Views for mobile either as the data-* attributes will add the CSS and JS needed for mobile, but is unobtrusive to your existing full blown web application. The CSS is really whats making the mobile aspect work, and the jQuery docs have all the information on the data-* attributes.

Side note - I love the quote 'Script Olympics' that Rachel termed for what is occurring in Solution Explorer (VS.NET IDE) with the massive amounts of scripts being automatically added in projects today. The alternative is to point to the CDN which are online versions of the scripts. Just keep in mind, that pointing to a CDN hosted script is not a good idea if internet access is not available for your particular application (i.e. building an intranet application behind 4 walls).

This session did have some review for me, but she prefaced that it would be (review) on some of the topics depending on one's experience. One area I feel I have a decent radar for is those that know how to articulate a topic or set of topics well. If one had never used MVC or EF, Rachel's style of delivery and presentation was second to none. She did a fantastic job of delivering content from the ground up in a simple and easy to understand way.

Anyone hesitant to use MVC or EF before the session has no excuse to not go home and begin building apps immediately. I look forward to hearing her speak again in the future!

Maximizing Entity Framework 6 in Your Web Projects
Adam Tuliper, Technical Evangelist, Microsoft



I'm a big fan of Entity Framework so this session is right up my alley. As usual we start off speaking to code 1st vs. database 1st conventions in EF. Adam prefers code 1st as he does not need a designer view. However, with the productivity tools, you can still engineer the visual design of your code 1st approach. This way if you need a visual you can still have it. This latter feature helps bridge the gap at least from a visual design standpoint which is nice wanting to try code 1st but still want a diagram.

Sometimes we need the ability to be able to see the queries that are generated by EF. Glimpse and Beyond Compare are (2) tools that help us inspect the queries. There is of course the SQL Profiler but it's a bit too disconnected and raw for our needs. These tools run a bit more closely to the application to inspect the EF traffic.

One cool thing I saw in the NuGet package manner that I did not know existed was intellisense. To activate Glimpse add in /glimpse.axd after the URL to get the display in the bottom half of the browser.The queries will be in the 'SQL' tab. In the 'Session' tab you can see the last several sessions to get a history. Click on the 'Model Binding' tab to see how the values are mapping to the model object being posted. Needles to say there is a ton of functionality.

You can also have multiple contexts per DB. 1 option is multiple EF apps per database allowing multiple devs to you the same DB. Multiple contexts per project DB all separation of intent and multiple devs to use the same DB. By using the .HasDefaultSchema() you can dicate which schema the entities have applied to them.

In ASP.NET there is a limited number of threads in the thread pool. If they are all used, subsequent requests must wait until threads are freed up to continue processing. When using 'Async' this limitation is not applied. Async queries hand off processing to a separate system thread. The reason for using Async would be for long running queries.

In EF6 there is now support for stored procedures via a code 1st approach. We could always run a stored proc manually via context.Database.SqlQuery<T>("dbo.my_stored_proc) but there were no annotations for using them. Now there is stored procedure / script support for Insert / Update / Delete only. Why no Select you might ask? Then what's the point of using the power of EF and an ORM. You are supposed to leverage the ORM for data pulls and not be doing it manually. As Adam states: "So if you love stored procedures or you have a DBA that's stronger than you, then this is an option."

We next delved into architecture surrounding an EF implementation. Adam reiterates there is no 1 single solution in practice. Some of the better practices though are using a combination of POCOs and ViewModels. There is no reason to send a huge POCO to a View when you only need 3 fields from it; the ViewModel fixes this.

There are domain patterns like Domain Model and Active record. You do not have to have your domain objects be DDD. Active Record is the '1 record per object' mapped cleanly to the database. This occurs a ton in web forms applications. 

There are data patterns like Direct Access, Web Form Controls (direct binding and access), Repository, and Unit of Work. While the Repository pattern is heavily debated, I really like it. As an architect it is such a small effort, for a clean and well working implementation. How could you ask for anything more? There was also some conversations on layering and when to do it vs. not do it. I wrote an entire post on this recently and feel that layers are fine: Layers Are Cheap, But Doing It Right Is Priceless This 1 paragraph is something I have professional passion about (see key note from yesterday about why I describe the type of passion) and could go on for hours discussing the pros/cons.

Adam began to show what happens when the Controllers begin to get 'fat'. If you are calling EF directly in the controller, you might want to refactor out this logic into another service layer. Also with the approach of fat controllers is that your unit tests against the controller will actually be integration testing since the code within will hit the actual database.

Dependency Injection was brought up and how it helps promte good testing techniques. A couple of quick comments on DI in web forms. Most of us are using MVC which has a dependency resolver built in, but web forms does not. Apparently AutoFac and Spring.NET  have the ability to do both property and constructor injection. A method which I have used is combining a DI framework with using a Service Locator to Global.asax in the page's constructor. One feature of using a DI framework that even without true constructor injection that is useful is the management of mapping concrete types to their Interface counterpart in a single spot. My web form may not be easily testable, but all the methods and layers downstream that are dependent on the Interfaces being injected are tested more easily.

One last tidbit - EF6 allows mocking out an entity context.

Patterns and Tools for Parallel Programming
Marcel de Vries, Technology Manager and Microsoft MVP, InfoSupport



Parallel Programming = AWESOME.Simple principal: do more than 1 thing at a time simultaneously. In the world of multi-core machines, we need to leverage async when applicable.

Here is something interesting: Amdahals law - The maximum scale up that can be achieved is the lowest bit of sequential programming in your application. In a nutshell we are still slowed down by the lowest common denominator. However we can still speed up by a factor the overall programming execution time.

Marcel spoke to the difference between data parallelism and task parallelism. Data parallelism distributes the data across separate parallel computing nodes. In comparison, task parallelism distributes threads across separate parallel computing nodes.

A Task<T> is an asynchronous operation that can return a value of T. While a Task is lightweight we need to make sure we are saving 200-300 cycles of processing in order to make it asynchronous otherwise it is not worth it. Adding 2 integers is not efficient. You really want to offload a chunk of processing to surpass the instantiation of the Task object (which is small but still exists).

To avoid race conditions you need to add lock statements to your code. Hardware locking can be used for better performance via System.Threading.Interlockd.Increment/Decrement, etc.. The best method though is to write lock free code; meaning the code doesn't need to have locking to be accounted for in the 1st place. This can take some serious refactoring though for an existing application.

The Concurrency Visualizer was an awesome tool in VS.NET under the 'Analyzer' menu to show how the code is executing against the CPU available on the machine. This is a great way to analyze how the processing of your application is performing against the cores and how many it is using. In ordinary circumstances only a single core will be used. If you have intensive processing occurring this core can get pegged. If you add asynchronous programming to the process, you will see additional cores utilized and the amount of times to process (should) decrease.



Using Task.Factory.StartNew will issue a new process that TPL will load onto the different cores available. Also note that the order of the tasks being run is not in the order they are created; the order executed if all created at the same time is random. The TPL scheduler is optimized for tasks that run on average between 1 or 2 seconds. Marcel created an example that queued up 100 Tasks each taking a second or so to run. The problem is running that many tasks made the system add threads to the app pool which means down the line processing is not as efficient by over-committing the thread pool. A better approach is to seek out how many threads exist on the machine and then clean up each thread after it's complete.

The next example presented was showing the need to execute a series of unrelated but identical tasks and then create a summary of the data at the end. TPL makes solving this almost trivial using .ForEach(). (INSERT LINK HERE!!!!!!!!!!!!!!!!!)

PLINQ allows using LINQ with parallel task library underneath. It all runs on IEnumerable&ltT> and everything after the .AsParallel() call is executed in parallel on a Task. 

Another informal poll:

How many are doing Win 8 app development: 2 hands
iOS development: 2 hands
Android apps: none
Web Apps: 95%

It appears ASP.NET is alive and well :D

The session was finished off with Async/Await. FINALLY, FINALLY, FINALLY, Marcel did an example that answered one of my questions on using async. Almost all of the examples I see await the Task on the same line of code. Isn't that then still synchronous? I believe yes. The idea and what I have done in practice is to call the Async method, do some independent work (in Marcel's example: DoIndependantWork()) and then await the task. This way we defer to a separate thread so we can do some other work.

However I did get the question in about all of the examples calling 'await' directly on the line calling the 'async' method. To me this was just a synchronous process. Marcel did confirm this to be true as it will block on that call and not proceed until it is done. But, there is still a benefit that I did not realize even with doing this method. Even though the async process is blocking, it is not blocking the UI thread. The result - while that potentially long running async method that is blocking is running, the UI is responsive. This actually is a huge benefit I did not realize. If the MSDN would just place that small tidbit that Marcel delivered it would have been understood much better on my end.

It is important though quantify your code/CPU/thread performance when doing any kind of parallelism. It appears 90-95% of the time when used correctly it will actually speed up execution. However there are some instances where doing TPL, PLINQ, etc. can actually hinder the performance so if there is any questions use metrics to quantify if the process is actually more efficient.

.NET Rocks! & Xamarin: Building Modern Apps Leveraging the Cloud
Andrew Brust, Richard Campbell, Andrew Connell, Carl Franklin, Don James, Rocky Lhotka, Matt Nunn, and Brian Randell


I'm new to 'The Tablet Show' or 'IT Rocks' podcasts but apparently this wrap up session for the mid-section of the conference will take on this format. They are actually about to release their 1000 podcast, so where have I been??

The show is actually really cool and has a nice format. Right now the discussion was surrounding Cordova (PhoneGap) and making Windows development easier across platforms. It wasn't interactive with the audience but rather a reading of some comments from their blog.

Moving on, there was in introduction of the panel on stage which included Rocky Lhotka, Billy Hollis, and Andrew Brust which were all speakers (in addition to the .NET Rocks guys) at the conference.


The discussion jumped right into something I discussed in my previous blog posts about 'What is a Hybrid App?' The explanation was actually long and in depth and not something that can be summarized in a few words. The problem with that type of answer is it does not necessarily clear up the understanding to the masses what a 'Modern App' actually is. However, Rocky came in and articulated well a bit better (or at lease better for my ears to understand) to clear up some of the understanding.

A lot of the conversation converged around how to manage a single platform vs. writing against several. A point was made this movie was seen before in the 90's even with having multiple front ends to a single back end in the likes of VB6 and PowerBuilder for example. The fragmentation that exists is not helping to make any of us in the industry understand understand exactly the clear future path. That might be an oxymoron anyway as knowing the future is not possible. That's why we have words like 'guess', 'crystal ball', 'speculate', and even 'crystal ball' :) The debate or better conversation was each panelist thoughts on what a 'Modern App' entails.

What was really cool, was Rocky mentioned at the beginning of the week getting in an argument with a gentleman about the end of Moore's law. Well it turned out to be one of the .NET Rocks guys on stage that was originally on the other side of that argument, who unknowingly explained in not so many words essentially the end of Moore's Law. Rocky brought up the previous argument and that he finally proved his point, "thank you for agreeing with me." Zing!!

The best conversation though surrounded where do we go in the enterprise in the future? Since we have all these different platforms with and Android, iOS, Windows, there are very few technologies that will work across all systems. Rocky believes that JavaScript and HTML will probably reign supreme. That's because these do run across all of the aforementioned platforms.

I'll step in and provide my own comments which are that I can believe how JS and HTML5 will reign supreme. According to the polls talken this week about 90%+ of the attendees are some type of web developer. Combine this with the fact that multiple platforms in the future will only continue to increase, we will be forced to figure out a way to develop efficiently and not have 6 different versions of the code base. Thus having our hand forced to develop using something that is cross platform and with the vast amount of web developers in the present day, we will naturally gravite (and possibly comfortably) to using JS and HTML5.

CRUD apps going away? All I have to say to this is, not in the busniess and corporate world.

Last question, "where will we be in 1 year?" My best guess is right here in Orlando still trying to figure out where we'll be the year after next. ;)

Wrap Up Day 4


Well the week is flying by and this wraps up the 75 minute session tracks portion of the conference. Being an ASP.NET dev in some fashion for a large slice of the pie, I decided to stick to mostly ASP.NET sessions. By the results of the informal polls and the attendance in these sessions, it appears technologies like ASP.NET, Entity Framework, and even native .NET Framework capabilities (i.e. Parallelism) are all alive and well and quite popular.

We need to be careful to not create panic and worry for the sake of panic and worry about the future. We have never been able to predict the future and many industries move at the speed of a turtle anyway so bleeding edge direction and decisions are not even on the radar for a significant portion of the development world. It's not to say we should be naive and ignore the future thus making poor decisions now (i.e. let's build our new major Enterprise app using Silverlight), but rather we may not need to do an about face just yet. Worst case scenario is we have to write and manage applications for 5 different platforms and the demand for software developers skyrockets. Hummm.... sounds like a good problem to have, and a little bit like natural job security. It's a better conversation to have then having to be concerned about an industry drying up or becoming non-existent. 

Award for quote(s) of the day

"Do you think Windows will ever be free?" (.NET Rocks)

"What were they thinking serving baked beans at a developer conference????" (lunch line - anonymous)

Visual Studio LIVE! Orlando 2013 Day 3

We are right in the middle of the mix of VSLive! 2013, and there is another good day ahead of us all! One thing I wanted to clarify to those of you attending the conference (and reading this) is the agenda of the 'Modern Apps Live' tracks and my own misunderstanding of what the content entailed. My thought prior to the conference (actually all the way back to the Las Vegas conference earlier this year when it was released), was that the session tracks covered 'Win 8 native applications' formerly and widely know as 'Metro Applications.' My thought was, "yeah I'll attend some of those session but Win8 apps aren't in our near future" so probably secondary to my main agenda.


Oops, I made a mistake in my understanding of the content delivered. I figured out immediately on Day 1 when Rock Lhotka presented and showed a slide presenting essentially the logical layers of their 'voting' application that I was incorrect in my assessment. 'Modern Apps Live!' to me should have actually been renamed to 'Modern Application Design Live!' or something to that tune. Literally the word 'modern' threw me off, but should have been taken at face value. Since then I've attended multiple sessions, and the elite at Magenic (image above courtesy of the Magenic.com website) have put together a solid (yes pun intended OO guys) set of training. The point here is, flip a couple of pages in the Live360 agenda booklet and check out some of the sessions. I highly recommend them regardless of position at your company, but especially if you are a senior engineer / architect helping to drive design and technology in your corporation. 

OK, without further of an introduction, let's get to Billy Hollis' keynote today!

There's No Future in the Past: A Critique of Conventional Thinking
Billy Hollis, Primary Guru, Next Version Systems


This quote helps summarize the overall message of Billy's keynote:

"Don't put your preferences ahead of the needs of the user."

Once again Billy showed the slide of the programmer 'addicted' to code (a person with a rolled up dollar bill snorting a screen of C# on a tablet).. I love the non PC nature of Billy's talks at times. He stated someone told him once: "I want 2 testers per developer." Billy's response was, "I'd like 2 blonde bombshells in my bed at night but we can't all have what we want!" We can be so wrapped up in the 'code' and 'process' of creating the application, but we need to expand our horizons and really understand what our users need and think in a different way. Things like MVVM, OOP, SOLID, Agile, etc. are fine but they are not they are not the entire picture.

One interesting point Billy made was this his philosophy is he will not take advice on building software from people that don't build software. I couldn't agree more, but it happens all of the time in the busniess world. If one hasn't developed in 5 years they are too far removed from the current technology and practices that it's difficult for them to offer any valid advice. He would listen to their suggestions, but would test those suggestions to see if they have any merit.

The main message delivered here are placing their desires, knowledge, and understanding of the technology ahead of what the users actually need. 

Another great quote in response to someone writing an article about how TDD changed their life: "If TDD changed your life, your life must of really sucked." It was followed by another testimonial of interviewing a candidate going on and on about TDD. The interviewee leaned over and stated "I'm really passionate about TDD." Billy said, "You know you should really be passionate about your spouse or girlfriend not TDD; the world is like that."

I really enjoyed the conversation around knocking those that say, "Only Agile works", or "Waterfall is stupid." For eons software that was created and maybe still running (i.e. banking software) were built using waterfall and similar project methodologies. The point is you can use what works well, we don't have to behave like blind zombies following some methodology or practice, 'just because'. In fact he states many will use a methodology long after it's effectiveness has expired because that is what they are used to doing.

Be skeptical of gurus, and 'one size fits all answers', and dogmatic statements in our industry. We need to be and think diverse from a team and technology perspective. This is what will help us grow and be effective in a rapidly changing and ever evolving industry.

Data Access and SQL Server in Modern Apps
Steve Hughes, Practice Lead, Magenic


This session looks to be great as their are multiple approaches to creating databases and subsequently the code model that interacts with those databases so exploring and discussing the options are always interesting. Steve is a 'database guy' so his perspective to me is a fresh perspective vs. my own a developer. He also happens to be one of those humble elite in our industry so I'll keep his email handy for questions ;)

He began by exploring the multiple options that we have to ask ourselves when beginning a project that requires a database. I know I have run through these myself so the slide below was spot on for current development (image courtesy of Visual Studio LIVE! and Steve Hughes):


I love the comment that "DBAs thank developers for writing poor queries because it's ob security for them!" 

There are 3 main SQL Server options currently: SQL Server on Premise, SQL Server in an Azure VM, and Azure SQL Database. Obviously when choosing the characteristics like performance vs accessibility (local vs cloud).

He stated that DBAs do not like Entity Framework. This sentiment really spawned from EF version 1-4 which created poor SQL. The developers loved it and stated, "Well the SQL is generated by Microsoft so it must be good right??" Well initially this was not true, but as EF has matured the DBAs began to see the increased efficiency of the TSQL produced and the close relationship between SQL Server and EF (both created by Microsoft) the acceptance began to increase. The current day reality of EF is a nice harmony of performance, testability, and ease of deployment which is helping to make everyone happy about it being Microsoft's flagship ORM.

So let's explore the (3) main ways to use EF: Code First, Model First, and Database First.  I've been a part of Database 1st, and the Voting Application used in the Modern Apps track also used a Database 1st approach. The reason for their selection was simply because Steve was on the project and this makes total sense. Any DBA or the like will always like to create the database 1st and hand it off to the development team as opposed to having code generate the database.

Side note quote from Steve: "Any DB architect that says you must use 5th normal form... fire them :P Maybe in a rare instance, but everyone will dislike them because it will be so hard to find the data; it's all a bunch if keys."

One valid reason to use a stored procedure as opposed to what EF generates is when the SQL generated is not valid. The example provided was needed to issue a series of DELETE statements in a particular order that EF was not doing correctly. Otherwise it's more of an exception than the rule to use stored procedures when using EF.

The BEST remarks were surrounding 'busniess logic in the stored procedures'. I love this topic and have spoke on it before myself (Should I Place My Business Logic In Code Or In Stored Procedures?). Here was Steve's comment, "If you want to add busniess logic to a stored procedure.... don't" Even if it is easy, don't do it. For those that say, "I can make a quick change in production to a stored procedure out in the field..." Don't do this; tell the client to wait a minute. Do a hot fix, decrease inefficiencies in the project methodology, make a change in the release, etc. but don't make field changes to complex logic that shouldn't be in a stored procedure. Remember, SQL is designed to persist and retrieve data and that's what it does well. Leave the busniess logic to a development language in a logical layer that makes sense and keep it out of the database. 

There was a gentleman in the audience who stated, as long as you follow good process and source control what's the difference (advocating for busniess logic in the stored procedures). Steve reiterated, SQL does data CRUD operations really well, but it's a misuse of the tool to try and leverage it for storing and executing busniess logic; that's not what it's made to do. I also responded with, "how do you unit test that logic?" Apparently there are ways to unit test stored procedures that's not just making a integration style test to the database. However it was somewhat of a moot point because as stated, busniess logic shouldn't be in the database. I too have passion on this topic and really dislike placing business rules in stored procedures, so I couldn't agree more with Steve's presentation on the topic.

Something I will have to review offline is a product called DACPAC to submit database schema changes to the DBA before deployment On very small projects Steve was still using a manual deployment process, but for more formal projects a process using scripts or DACPACs should be exercised.

It was interesting to see the Azure DB in the cloud. I have no personal experience with the tool, but it seems intuitive and clean. There are performance tools and monitoring to help show metrics for database debugging. One of the reasons for using the tools is to use an index strategy for EF access. When Steve created the Azure database he had to weigh the options of Table Storage, Blog Storage, or SQL Database. The think to remember is Azure databases can skyrocket in cost if they get too big, so these factors need to be kept in mind. 

A couple of final points to keep in mind to wrap up Azure databases in the cloud - leverage caching (it's a must) and keep in mind availability. Microsoft guarantees (3) 9's (99.9% uptime), so if you need more than that, Azure is not for you.

Learning UX Design Principals Through Windows 8 Apps
Billy Hollis, Primary Guru, Next Version Systems


In this session we are going to get into the human brain and how m\we need to get developers to learn how designs application. Even though I've already seen one of Billy's other talks and was at the keynote, these sessions are extremely valuable because instead of being right in your face it's more, 'think outside the box' material. In our world thinking outside the box is probably not done as often as it should be.

He showed the AT&T site and asked what we all thought of it? As a previous AT&T customer I can vouch that the site was awful and very difficult to navigate. This is the path Billy takes us to not continue to slap and slam stuff together. We need to make apps intuitive, simple, and easy. "Whit space is OK."

We proceeded to an awareness test where 2 teams of basketball players are dressed separately in black and white. The quiz: how many passes does the white team make? The answer is 13 and a lot of people got it, but then the question was asked, "did anyone see something odd?" It turns out in all this complex passing and moving around a dressed up bear moon-walked through the middle. The point, we don't see what we are not looking for; it's called 'intentional blindness'/

In Windows 8 and in modern application design we need to de-clutter and simplify our designs. We may still need to provide a massive amount of information, but we need to change the way we think about presentation and design.

There were (2) other visual examples / quizzes given. On a quick flash of some screens, find the number of screens that contain scissors? Everyone got the answer right. The Billy asked "how many had a paint roller? Uhhhhhh.... we were not looking for that. Exactly. Then the elevator quiz with a picture of the buttons. What sticks out as odd? Everyone says, "there is no floor 13." Yes correct, but not the answer. The ground floor indicated by a 'G' and a star was worn out from being pressed. However it was the label that was worn out and not the button. The visual queue made people gravitate to the label and not the button. It's another example of poor design and how we visualize and interpret what we see.

Fitt's Law: the amount of time required to locate and use an option is smaller if the option is bigger. There is no rule that all button need to be exactly the same size.

An interesting history lesson about Windows 8. Windows 8 was a direct response to the iPad. Microsoft had seen this story with IBM in the 80's and made them irrelevant in 10 years. In an effort to not have Apple do the same thing to them, they came out with Windows 8 which had a focus on the consumer space. Microsoft pretty much had ignored developers and the enterprise for the last few years and are now realizing this mistake. I have spoke about this previously (INSERT LINK HERE) about Windows 8 (formerly 'Metro' apps) were not ready for the enterprise. It appears my thoughts at the time were right.

Billy even showed some slides breaking down the retina of the eye and how we visually break down what we see and in what order. The reason for getting into this low level detail and analyzing of the brain is to better understand how we should design applications.

One example Billy gave that hit close to home was a radiology application that he helped create in reference to the training of the application. Of course Billy's applications if you have not seen before are drastically different than the status quo (data grid disaster we normally create) apps most of us create and use. The trainer of the company selling this software created a typical 3-day training course for the new software as they always had done previously. Billy mentioned how expensive it is to to have Doctors on hand for training, and the ability to train quickly saves time and money. 

Well day 1 of training with the software, the trainer realized after 4 minutes no one in the class was paying attention to her. The reason? Everyone was already using the app on their own. It was designed so well and it was so naturally intuitive to use that everyone took off on their own. Eventually the training course was able to be reduced to 1.5 days. Point, great design.

I would love to see the radiology app he spoke of in the example. The radiology applications doing these sorts of tasks that I have been associated with are jam packed with controls and functionality out of necessity. To make a Windows 8 application with the identical requirements, but blending in touch,, simplicity, and minimalism seems like trying to fit a square peg in a round hole situation considering the requirements, The point is it could answer a lot of questions in a simple 1:1 comparison for bridging the gap from old design to new design methodologies.

Another interesting point made: "Good design is only good design in reference to it's context." A trash can in Alaska takes 2 hands to operate. Here in Florida that seems like a bad design. In Alaska you have to keep the bears out of the trashcan so it's a good design. Keep this in mind when designing applications to know and understand your audience.

To wrap it up for this session, try to avoid what Billy speaks to with a busy and over complicated design.. An extreme example of this is the space shuttle pictured below: 


The designers understand for this scenario the user's need a 'high cognitive load,' or better yet 'rocket scientists'. Since most of us do not have rocket scientists with a massive amount of training using our software, try to avoid the following style of application design which Billy displayed; look somewhat familiar?


Building Mobile Cross-Platform Apps with HTML5 & PhoneGap
Nick Landry MVP, App Artisan, Mobility42


There are several options when doing mobile web development today when attempting to reach users across platforms. Like Xamarin is for native applications, 'PhoneGap' allows us to take our source and compile it to a native shell that runs in the browser. However the application still appears to run in full screen and you don;t see the browser. You can deploy to multiple platforms even the ones fading away.

HTML5 and CSS3 combined with JS will be what we as developers leverage to create our cross platform web applications. There are JS frameworks like jQuery mobile, Kendo UI and, Sencha Touch to name a few. jQuery mobile is the most popular, well documented, and built atop the jQuery framework. Many major web apps have been built with jQuery mobile like Disney, Dodge, United, Chase, and many more.

PhoneGap is an open source project under the Apache License. It is a open source distribution of Cordova. It can be downloaded and read about via the following location: http://phonegap.com/install http://phonegap.com/install It is recommended to take a look at the site to see the full feature set and documentation.

By the way another informal poll which I love was taken in the class and here are th results:

Number of users on a Widows Platform: 100%
Number of users on a Apple OSX platform: 0% (except Nick himself)

PhoneGap creates a web app with a wrapper that allows HTML5 and JS applications to be spawned up and run quickly on multiple platforms. As Nick described, if the UI is and delivery is your main money stream then the simple UI of PhoneGap vs. a product such as Xamarin may not win out in comparison. However if you need to quickly  produce a cross-platform application that reuses and leverages your current web development skills, then PhoneGap may be the right fit.

For testing applications locally when doing Android you will need the emulator installed or an actual Android device connected. When running the PhoneGap application, it will try to run it locally first and if it can't find a device it will look for an emulator. For iOS you will need a Mac. Likewise you will not be able to build a Windows Phone App on iOS. 

When we run the PhoneGap app, it will use the 'remote environment' to build the application. With the free account you can have 1 private app and unlimited public apps. A public app is one where the source code is on something like GitHub and we point to that to have it built. There are some nuances with the PhoneGap Build server and the keys required per platform. Inspect their site for details on the individual keys required. Using 'local build' is typically more useful than Cordova 'remote' builds. 

Once the application is built using PhoneGap, the entry point of the application can be reached via the indiex.html file.

This looks to be a promising tool with a strong open source community following. This is one of those sessions displaying a tool to look at in the future and get hands on in addition to reading about its particulars and understanding its end-to-end usage. If you do happen to buy or read any books on PhoneGap, he mentioned to make sure it was on v3.0 or later as there ahve been drastic changes in the framework since the early versions.

Wrap Up Day 3


A super quick wrap up as it has been an extremely long day today, but very productive! Tomorrow is jam packed full of session so I need to get rested to keep on truckin' (<- yes I said it).

A quick shout out to the Live360 staff and organizers for a great conference so far this year! You always do a great job and thus far this year is on par with the best!

Award for Best Live360 Attendee Luau Dancers :)