JohnShew's Blog

Cloud Foundry and //Build

John_Shewchuk — Mon, 04 Apr 2016 17:55:53 GMT

Last week at Microsoft's annual //Build developer conference, I partnered with Rita Zhang to demonstrate Pivotal Cloud Foundry on Azure. Cloud Foundry is an open source platform as a service (PaaS) technology that makes it easier for large companies to move to the cloud by first supporting deployment to the private cloud and then when they are ready transitioning to the public cloud. For large companies like Ford, the ease of use of Cloud Foundry makes it easier to move to Azure. Data sits in a variety of locations, and in a cloud agnostic world it is key that developers can access it without writing vendor-specific code. Rita has helped to develop an S3 proxy, that supports getting data from both AWS S3 and Azure Storage from a single code base in Cloud Foundry. The S3Proxy solution can be hosted as a standalone Jetty application. In this scenario, the S3Proxy solution is deployed, managed, and scaled as its own application in Cloud Foundry so more apps can leverage it. Some users will use Cloud Foundry to adopt the cloud for the first time, and in these cases the developer can bypass the S3Proxy and use the Azure storage SDK directly in their new application. The S3Proxy allows applications using the S3 API to access other storage back-ends, e.g., local file system, Google Cloud Storage, Microsoft Azure, OpenStack Swift. This application demonstrates how a user can setup S3Proxy in Cloud Foundry to use the same code base to get content from both AWS S3 and Azure Storage.

Highspot, Manifold and Vorlon

John_Shewchuk — Thu, 31 Mar 2016 11:00:54 GMT

I just wrapped up the last keynote here at //build/. It was super fun. There is so much new technology that will help you build great next-generation applications. But there’s just too much to drill into in one blog post. So, like we did last year, we will take a look at each major coding demo in a series of posts – starting with this one. We highlight a great partner and startup – Highspot. Highspot provides a solution for sales and marketing teams to track documents – like PowerPoint - that they send around to customers. As Highspot was getting started, like many startups they built key parts of their application on Amazon Web Services. But a very interesting thing happened recently. They decided that it was critical to meet customers where they are and one of those critical places is in Office. So they became an Office cloud storage provider - you can read more about that in their words here. That started a deeper set of integrations. Onstage I showed what they are working on now. In addition to embedding PowerBI into their app to enable self-service and custom reporting, they’re also building a set of Office Add-ins that connect their system with the Office apps that their customers use every day. One of the channels Highspot uses to expose data to its users is the Office Add-in. We showed how the latest generation of Office Add-ins are actually web apps that run inside Office. And Office runs on many different platforms, so your web app needs to as well. It’s another great opportunity for web developers, Let’s take a quick look at how this works. Here is The Highspot Web app running in the browser. Last year we talked about using Manifold.js to build cross-platform store apps from your web app, all based off the W3C Manifest for web apps. If you have used Manifold.js to build web apps for other platforms, you’ll be excited to see that now it builds office add-ins as well. In the command window simply type: manifoldjs https://addin.highspot.com -p office You will substitute out your URL for “addin.highspot.com” and that builds out the office add-in. Manifold.js produces an app that can be tested and deployed for Office from any platform. And we can test it right away in an Office web app. This works by generating an Office manifold. Sounds awesome right. Well it’s very easy to get this all working. However, in practice it can be challenging to deploy and debug these solutions on a bunch of different platforms. So we announced that Vorlon.js has just added support for debugging Office Add-ins now too. In the example I showed onstage, the add-In was connected with my Vorlon server (which can be executed on Azure or locally). Vorlon lets me see this across all the different platforms. In this case Office desktop and Office for iPad We love developing Open Source community-based tools like Manifold.js and Vorlon.js so partners like Highspot, and developers like you have the tools to easily build and debug for Office or add-ins on many platforms. We’ll continue to drill into other technology scenarios covered in the keynote over the coming days.

A Minimal MVVM UWP App

John_Shewchuk — Wed, 09 Sep 2015 14:16:00 GMT

With the introduction of Win 10 and Universal Windows apps I wanted to try out some of the new XAML features like compile-time binding with x:Bind.

I started by looking for a very simple Universal Windows Platform (UWP) sample that showed how to build an MVVM app with create, read, update, and delete (CRUD) operations over some data source. Surprisingly, I really didn’t find anything specific for UWPs. Of course there are many samples for WPF but they required a rewrite for UWP and they don’t leverage the new XAML capabilities making them more complicated than necessary. Similarly the core UWP XAML samples don’t show how to do CRUD and while they covered new capabilities they include a lot of unrelated stuff that makes them less useful as a starting point for your own apps.

So I thought it would be interesting to see how simple we could make an MVVM UWP example and still support full CRUD. As you can see below the ViewModel for the resulting app is less than 100 lines of code – which is pretty reasonable since we need to cover all the corner cases associated with adds, updates, and deletes – and get those connected to the data layer. The XAML View is also simple – only 25 lines of XAML and no code behind other than initialization.

If you work through this example, you can see how it uses the new x:Bind capability. Creating and debugging bindings in XAML has previously been a little touchy but now with x:Bind you get typesafe code at compile-time which makes it easier to get the bindings right and they run faster. In addition the new x:Bind event capability reduces the complexity of implementing operations on the ViewModel.

Why MVVM?

Before we look at the code, I wanted to touch on whether it is worth the effort to use an approach like MVVM (Model, View, ViewModel). The basics of MVVM are pretty simple…

Model. Think of the models as the business objects. A Model should know about nothing about the user experience - specifically the View or how it is implemented using a ViewModel. The Model only interact with system and data services.

ViewModel. The ViewModel is where you encapsulate any code or data that your UX or View will need. It is important that ViewModel only knows about and encapsulates the Model – but it shouldn’t be responsible for any Business Logic or Business Constraints – that should all be in the model. And on the other side, the ViewModel should know nothing about the specifics of the Views and UX that use it.

View. This is where you create the user experience – in Windows apps you do this declaratively with XAML markup language and design tools. The View uses properties and actions on the ViewModel to get the job done.

Since the MVVM approach is so conceptually simple, why do a lot of people get frustrated with it? One challenge was that historically the approach was fairly opinionated requiring base classes like DependencyObject and implementations often required a lot of coding to do simple things like connecting up a command to XAML. Another challenge was that a lot of developers felt that execution overhead of runtime bindings – and challenges debugging runtime bindings – ultimately led them to abandon binding and simply do imperative code to implement the UX.

With Windows 10 and Visual Studio 2015 many of the challenges have been addressed. As you can see we can now easily build an MVVM app using compile-time bindings that eliminates runtime overhead and reduces the likelihood you will need to debug bindings at runtime. We also show how x:Bind to methods means we don’t need to implement Commands and we show how two new C# language features [CallerMemberName] and nameof can help make it easier to implement INotificationPropertyChanged.

MVVM was already a well-proven approach that has been used to build many sophisticated and great performing apps and now with these new capabilities MVVM is more approachable than ever.

An Overview of the App

One of the key goals was to keep this example as simple as possible. But we also want the example to represent what a developer would actually need to do to build an app using MVVM. And getting all the CRUD operations in place over a real world database or other system isn’t trivial. So here is how we approach this.

At the core of the app is a Business Object – our Model. It is called Organization. It is just an in-memory “database” of People objects and an organization Name. The People collection is just a list where each Person has a Name and Age.

In terms of implementing the model we leverage some scaffolding code that implements a fake data service that pretends to communicate with a cloud service to manage the data – but here our stubbed out service runs locally and just prints messages for debugging / logging purposes. Again, the only reason to do this is so we have a realistic sense of what would be involved with building this over real world data and business objects.

In terms of the user experience all we need is a View that shows the list of people in the Organization and enables the user to Add or Delete People, or Update their Name and Age properties – nothing complicated. Our View is written entirely in XAML with no code behind other than initializing the ViewModel.

Most of code in the sample is focused on building the ViewModel for the Organization business object. The OrganizationViewModel keeps track of a collection of People that is kept in sync with the model. It also keeps track of a SelectedPersonIndex from the collection of people so the View can perform edit and delete operations on the current selection.

All the code can be found here on GitHub.

Building the App – A Walkthrough using Visual Studio 15

Building this app will consist of the following steps:

Create the project
Set up the Data layer. Here will use an existing FakeService that simulates HTTP operations on a cloud service.
Build the Models. This is the Organization class. It will use the FakeService.
Build the ViewModels. This is the OrganizationViewModel that will point to an Organization and provide both state and actions to the Views.
Build the View. We simply modify the MainPage.xaml file to add a list, a couple of edits fields, and a couple of buttons. Then we will use x:Bind to attach these controls to ViewModel.

Step 1: Create the Project

In Visual Studio 15 close any open solutions and then create a new project. Select Blank App (Universal Windows) and name your project. FWIW, I recommend checking source code management and using GIT as it comes in handy as you make changes to your project and later want to publish it.

Step 2: Create the Data Layer

Next right mouse click on the solution and Add a New Folder called Data.

Now right mouse click on the Data directory and add a new C# Class called FakeService.cs.

Replace the namespace and included class with the following code:

As you can see all our FakeService does is simulate GET, INSERT, and DELETE operations against a cloud service. When you run the program you can watch the output window to see the simulated operations on the database.

Step 3: Create the Models

Create another New Folder for Models.

Then go to the Models folder in the Solution explorer and right mouse click to add a class called Organization.cs to this folder. Replace the namespace and class with the following code:

As you can see the Model only depends on the Data layer. And it simply calls the simulated cloud service to load and update people in the organization.

Your project should look like this now.

Step 4: Build the ViewModels

So far we’ve taken care the models - the business logic including connection to the data layer. Now we get to the interesting part of the MVVM work – building the ViewModel.

For those of you less familiar with the MVVM approach, here is a quick summary a two important constructs:

INotificationPropertyChanged. INotificationPropertyChanged (or INPC) is an interface that describes how an object can participate in XAML bindings. The Binding system knows this interface and it uses it observe when properties on your objects have changed. We will wrap the Person object and implement the INPC interface to create the PersonViewModel. And we will do the same for the OrganizationViewModel.
ObservableCollection. Normal Lists and other IEnumerables don’t support notifications of changes that the View will need. The ObservableCollection class does this so we create one of these within our OrganizationViewModel to keep track of the people in the organization. In order to do this we will need to keep the Organization’s collection of people in sync with the ViewModel.

Let’s go. Create a new directory for ViewModels.

And add a Class called PersonViewModel.cs.

Now we could implement our ViewModel and write the straight-forward code for supporting the INotificationPropertyChanged interface. But to save some typing we are going leverage a helper class that make it easy to add INotificationPropertyChange to existing classes.

To do this let’s add another file to our ViewModels directory called ViewModelHelpers.cs and paste in following code replacing the existing namespace and class.

Go back to PersonViewModel.cs and add the following code.

As you can see we’ve created a ViewModel for a Person that is called PersonViewModel. This ViewModel maintains a reference to an underlying Person and we create getters and setters for each of the properties that rely on the underlying Person for the storage and it sends INotifyPropertyChanged events when the property is set. Notice how we use the NotificationBase class to do the default implementation of INotificationPropertyChanged. We also use the SetProperty helper functions to implement our getters and setters. The NotificationBase uses a nice new feature of System.Runtime.CompilerServices called CallerMemberName at compile time so we don’t need to manage the String for property names. Using the NotificationBase is a convenient way to wrap existing business objects that don’t already support INPC. It is good approach especially when the business objects are large – as the pass through capability doesn’t require duplicating fields. Now add a new Class for OrganizationViewModel.cs and add the following code replacing the generated namespace and class.

This is really the core of the application. Let’s look at it in some detail. We create the ViewModel for the Organization class and call it OrganizationViewModel. Like the PersonViewModel it also inherits from NotificationBase to provide a default implementation of INotifyPropertyChanged. Next we add an ObservableCollection property called People to provide a XAML bindable implementation of our List. This ObservableCollection really doesn’t do much other than get loaded through to the underlying model. We initialize the collection in the constructor and when we make changes to the ObservableCollection we update the model. Next we add two fields that are interconnected – a SelectedIndex that we can get and set from XAML and the SelectedPerson that corresponds to the SelectedIndex. Our user interface View will move the SelectedIndex as the user clicks on the list. Once a user has selected a Person the View enables the user to update the properties of the SelectedPerson. Notice that when we update the SelectedIndex we also fire a property changed notification on the SelectedPerson.

We add actions for Add and Delete that are just normal methods on the OrganizationViewModel – no fancy Commands or anything else required. The View will be able to bind to these actions in response to user input. As you can see they send the changes to the collection and the underlying model. One last important part of the model to note: when a property is changed on one of the PersonViewModel objects, they fire an event. We catch event this in the OrganizationViewModel and use to send an update to the underlying model and ultimately to the data service. To enable this we add person.PropertyChanged += Person_OnNotifyPropertyChanged in the Add operation.

Step 5: Create the View

Okay, we are mostly done with the coding part of our application. Now we just need to create the View and we will do that using XAML. Open the default MainPage.xaml file. Paste in the following in place of the existing Grid.

In addition, add the following namespaces to the tag:

xmlns:viewModels="using:ViewModels"

Our view is very simple – it consists of a Grid with two columns. On the left is our list of People. And on the right is our edit fields.

Inside of each Grid columns we have a vertically oriented StackPanel. On the right this StackPanel contains the ListView and the Add button and on the left it consists of the edits fields and the Delete button.

Now let’s review the bindings.

In all cases we are using the high performance x:Bind compile time bindings. This not only Binding runtime overhead but it generates typesafe code ensure everything is hooked up properly before we even run the app.

Most of the bindings should be fairly obvious. On the list view note on the DataTemplate we specific the x:DataType to our ViewModelPerson so that the list can bind to fields in a typesafe manner.

The new x:Bind syntax makes it very easy to simple call the Add and Delete operations on our ViewModel – we simply x:Bind to these methods.

It is important to note that while x:Bind offers a lot of great benefits from performance to IDE support, it is worth mentioning that it is not suitable everywhere. For instance x:Bind it does not support ElementName binding or UpdateTriggerSource.

Now if you tried to compile this right now it would fail. This is great. Because it is based on compile time bindings, Visual Studio catches the fact that we don’t anything called Organization available to bind against.

So go to the code behind page for the View by opening MainPage.xaml.cs. Then add a property called Organization and initialize it. Here is the code.

You will also need add a “using ViewModels” line above. Now the app should compile. Try it out.

One of the most important things to note is that each of x:Binds to properties explicitly set the Mode. It is very easy to forget to set the Mode on an x:Bind in which case it defaults to OneTime. So if you see your user interface start to work but not update – check the Mode.

If you run the code now you’ll note that the edit fields are visible even when there is no SelectedPerson. To address we’re going to use a little trick. We going to add a Converter to the Page.Resources that will let us give us back Visible if there is the SelectedPerson is not null and Collapsed otherwise.

To do this Add a New Folder to the Solution call it Converters. Then Add a new Class to the Converters folder called ObjectExistsToVisible.cs. Here is the code that you should add replacing the generated namespace and class.

Now go back to the MainPage.xaml file.

Add the following to the Page attributes.

xmlns:converters="using:Converters"

And then, in order to use the Converter in our XAML we need to load it so add the following right before the Grid.

Now let’s use the converter. To do this use a x:Bind on Visibility attribute of the right-hand StackPanel – the one with Grid.Column=”2”. The StackPanel should now look like this:

We are done. Try it out.

Next Steps

Hopefully this shows that implementing CRUD on data in an MVVM UWP App can be accomplished fairly easily. We used the new x:Bind approach works over our View and OrganizationViewModel and demonstrated how it helps you find Binding errors at compile-time. We also show using x:Bind to bind events directly to ViewModel methods making it easy to code up actions.

If we wanted to turn this sample into a production application there are a few things you will need to think about:

In terms of improving the solution it is clear we can make the View look a lot better – here we were trying for the simplest implementation.
You would probably want to find and use a MaskedTextBox (or intercept the TextChanged operation and apply Int32.TryParse) on the Age text – otherwise you will run into cases with an exception being thrown when the user enters something that is not an Int32. Related to this, the current default for TextBox is to update the binding when the focus leaves the TextBox. This can cause problems if you navigate away by selecting the list. As mentioned earlier you can use a regular Binding and set UpdateTriggerSource to fire when the text is changed.
When implementing INotifyPropertyChanged we show how to do it manually, but you might want to look into implementing it more automatically through code weaving; e.g. something like Fody Property Changed found at https://github.com/Fody/PropertyChanged. While the Fody approach is great we didn’t use it in this example to keep the number of moving parts to a minimum and also because Fody Property Changed requires some manual steps to get it working with UWP apps.
As you start to deal with larger amounts of data you will want to look into UX virtualization and implementing ISupportIncrementalLoading.
If you want to add sorting and filtering to the list you probably want to leverage a CollectionViewSource – a good simple description of how to do that is here Filtering Data Using CollectionViewSource.

In a subsequent blog post I’ll also show you can use a typesafe implementation of the data set approach to eliminate some manual work – we didn’t include it here since we wanted to keep everything stock. Some of the key benefits of typed data set approach is that you get a data source independent Model and you can use this as a foundation to easily implement sophisticated ViewModels over the data with very little code.

Finally, once you’ve got all the basics running, there are many interesting improvements you can make to MVVM apps. For example, some organization use dynamic lookup and assembly loading to connect together their MVVM components – this can be really handy if you want to be able to be able to update a running version of your application.

Build 2015 and Video Effects

John_Shewchuk — Tue, 12 May 2015 10:06:00 GMT

We’re keeping the coding going with this next post in the series of technical articles following the Build 2015 conference. This post is dedicated to the new video functionality provided in Windows 10. Increasingly, we’re hearing from developers the importance of adding improved user experiences for their apps. Those experiences include not only better design, increasingly the need for improved audio and video functionality has become important. In my last post I showed the audio functionality that we demonstrated in the Build keynote. This post is dedicated to one of the demos that we didn’t have time to show. And it’s pretty cool – focused on video and Windows 10.

So what is so special about the video functionality in Windows 10? I think that’s best seen through a comparison of code. Let’s look at the before and after for doing a relatively simple video effect. In this case we’re simply taking a video effect and adding a greyscale effect to it.

Here is the code in C++ that’s required to do this. As you can see it’s nearly 1500 lines of C++ code to perform this effect. The original version of this app is here. Now if we look at the Windows 10 version of that same code, you can see it’s dramatically simplified and it is easily programmed to in C#.

 
public void ProcessFrame(ProcessVideoFrameContext context) {
   using (var inputBitmap = CanvasBitmap.CreateFromDirect3D11Surface
(_canvasDevice, context.InputFrame.Direct3DSurface))
   using (var drawingSurface = 
CanvasRenderTarget.CreateFromDirect3D11Surface
(_canvasDevice, context.OutputFrame.Direct3DSurface).CreateDrawingSession())
   {
      // TODO 1: create a grayscale effect
      #region grayscale

      // grayscale effect
      var grayscale = new Microsoft.Graphics.Canvas.Effects.SaturationEffect()
      {
         Saturation = 0,
         Source = inputBitmap
      };
      #endregion

As you can see, first we process a frame. Then we create a Direct 3D surface. Next we create a drawing session. Finally, the core code is really as simple as:

 new Microsoft.Graphics.Canvas.Effects.SaturationEffect()	
     {	
      Saturation = 0,	
      Source = inputBitmap	
     };

It’s the deep engineering work that we did with the Windows team that radically simplifies the creation of video effects like this one. In fact in the sample on Github: https://github.com/nmetulev/Effective we’ve added a few other simple effects to show you how to get started.

I’m looking forward to seeing what you do with it.

Build 2015 and Audio Effects

John_Shewchuk — Fri, 08 May 2015 11:34:00 GMT

We’re keeping the coding going with this third post in the series of technical articles following the Build 2015 conference. This post shows you how it is so much easier now to develop apps that have fantastic, responsive audio. The next one will focus on video.

Having great audio and video is a big deal to many developers who focus on have a cool, highly interactive user experience for their apps.

A great example of this is Muzik Official Bluetooth-connected drum sticks. This is a super cool app where you do some air drumming… those Bluetooth drum sticks, and the related C#/XAML app, were only possible because of the new Bluetooth and new low-latency audio APIs that were introduced in Windows 10.

The Build Drummer sample app that I showed uses this new AudioGraph API and its low-latency audio capabilities to show how a simple C#/XAML app can have great audio performance on Windows 10. It is available on Github here – and we know it works with Win 10 build 10074 and Visual Studio 2015 RC. Go grab it.

With a single line of code, we can instruct the audio stack to use the lowest audio latency possible for the devices in the graph.

settings.QuantumSizeSelectionMode = QuantumSizeSelectionMode.LowestLatency;

This sample also shows how simple it is to load samples into memory for playback using normal XAML event handlers.

private async void BuildFileNodes() { // Init all the file input nodes 
  Uri[] uris = new Uri[numSamples]; 
  uris[(int)Samples.Steve] = new Uri
("ms-appx:///Assets/guggs_switch_gears.wav", UriKind.Absolute);
   … 
  uris[(int)Samples.OpenHighHat] = new Uri
("ms-appx:///Assets/Drum-Open-Hi-Hat.wav", UriKind.Absolute);
   // create a node for each uri 
  for (int i = 0; i < numSamples; i++) {
    StorageFile f = await StorageFile.GetFileFromApplicationUriAsync(uris[i]);
    var res = await _graph.CreateFileInputNodeAsync(f);
    if (res.Status != AudioFileNodeCreationStatus.Success) {
       // Give up on this one if the node didn't init properly continue;
    }
    _fileNodes[i] = res.FileInputNode;
    _fileNodes[i].FileCompleted += MainPage_FileCompleted;
    // By default, nodes are started. 
    // But we want to have the nodes start off in the stop state. 
    _fileNodes[i].Stop();
    _fileNodes[i].AddOutgoingConnection(_deviceOutput);
  } 
}

If you saw the keynote, I had a little fun with “Guggs”. He likes to say “Let’s switch gears” so we sampled his voice from last year’s keynote and included it here.

Try out the sample. Once you understand the code, swap in some of your own sound samples. If you want to give your coding skills a little stretch, add in some of the in-box effects like echo or reverb, or the ability to record your performance to a file.

For more information on AudioGraph: https://channel9.msdn.com/Events/Build/2015/3-634

And here’s another example of AudioGraph: https://github.com/Microsoft/Windows-universal-samples/tree/master/audiocreation

It’s the deep engineering work that the Windows team did that radically simplifies the creation of audio effects like this one.

In our next post, we’ll take a look at video processing and the significant work that went into simplifying it – we didn’t get a chance to show this in the Build keynote but I think you’ll find it pretty amazing.

Build 2015 and Vorlon.js

John_Shewchuk — Mon, 04 May 2015 10:41:00 GMT

As promised, here is the second in the series of technical articles following the Build 2015 conference. This post is dedicated to Vorlon.js. So what is Vorlon? It is a new, open source, extensible, browser-agnostic tool for remotely debugging your JavaScript all powered by node.JS and socket.io.

Yep - imagine being able to easily use any browser to debug your web site or web app running anywhere.

What we demonstrated at Build went a little further. In the keynote, I used manifold.js (see my last post for more on that) to turn a responsive web site into mobile applications. In less than a minute, I converted the web site into mobile apps for iOS, Android, Chrome, Firefox, Windows 8, and Windows 10. And on Windows 10 it is a universal Windows app that runs across Windows phone, desktop, tablet and Xbox. Doing that is very easy – and a pretty cool way to quickly create both a web site and all of the mobile apps for the most widely used platforms.

Now with Vorlon, you can debug the web site and any of these mobile apps – all remotely.

There are of course other great tools out there that offer full-featured remote web debugging. Google offers such tools for Android and Chrome. Apple and Microsoft offers tools for their browsers and apps as well. We built Vorlon.JS with node.js and socket.io so it can work anywhere – it works from any browser to any JavaScript execution environment. Right now this also means that Vorlon.js has some significant limitations compared to these other tools – for example, you can’t set breakpoints and step through code – but members of the open source team are working to add these features in the future.

Getting started is easy. Vorlon.JS is available as a node package, installed easily using NPM.

$ npm install –g vorlon

Once Vorlon.JS is done installing, you can now run the server:

$ vorlon
The Vorlon server is running

With the server running, open https://localhost:1337 in your browser to see the Vorlon.JS dashboard.

The last step is to enable Vorlon.JS by adding this script tag to your app / website: