Satter Ramblings

Microsoft Open Source

I still remember 3/28/2012, the day Scott Hanselman announced on stage that he just open sourced ASP.NET. It was the culmination of a lot of work by many people including myself. I was reading a blog post by Marc Gravell on Open Source and money and immediately thought back to that day.

I was tasked with releasing the products and processes needed to Open Source a Microsoft product. I was given very specific instructions. ScottGu wanted to

• Be able to say Microsoft.
• Protect Microsoft customers.
• Not release any patents without permission specifically do not lose Microsoft money because a royalty patent was given away.
• Not force Microsoft or customers to release source code.
• Be real and transparent.

Why?

Why did Microsoft do this? It is complex but simple at the same time. ScottGu needed to have Azure make money. He could focus on Microsoft's existing customer base. Or figure out how to bring in customers who had never used a Microsoft product. This last part is why the path of Open Source was taken. Open Source would bring in developers. More importantly, it would bring in leading edge developers who were moving to the cloud. Most of Microsoft's customer base were organizations who were not known for being early adopters. Azure required early adopters. 

The target developers wanted Open Source for a variety of reasons. Some for very pragmatic reasons like patching bugs while others were more philosophical about Open Source. And here is something I learned and I'm sure a lot of my readers have learned. Developers do not pay for tools without good reason. Developers tend to either write their own frameworks, adapt one, and sometimes buy a tool, framework, or component. Case in point I am using Refit for writing my REST API Clients. I could write my own, and I have. The only way I would spend money would be for a REST API Client that incorporated caching and automatic replay of calls for a fire and forget REST API environment. 

Developers and the IT industry, in general, have no problem paying for services like hosting. Thus giving away tools for using Azure was a smart move. Developers if they liked what they say would use the tooling. Tooling which naturally leads to the adoption of Azure. Back in 2012, it was a risky bet. Today it looks like a brilliant move by ScottGu.

Process

It was more than just releasing the code as Open Source that made the plan work. Look back at the list. Being able to say Microsoft ASP.NET MVC and Web API gave branding coverage. What is this protect customers? Protect them from what? Open Source! The wrong license could negatively impact customers.  Also, not all Open Source is high quality. 

One of the things the release process required was a pedigree scan of the code. This scan did several things. First scanned for patent usage. Did the code leak a patent or use a patent requiring paying a royalty? This was important as Microsoft made a lot of money from patents back in 2012. Avoiding using patents as patent litigation can be costly even if you win. Microsoft indemnifies its customers for patent infringement by Microsoft products. You can imagine how costly that could become for Microsoft protecting its customers.

The scan does not stop with patents. It detects usage of Open Source. Not to avoid using Open Source. It is about disclosing the usage and ensuring compliance. If ASP.NET, for example, was using an Open Source framework that was GPL not only ASP.NET but also all users would need to Open Source. I am not saying GPL is bad. I am saying Microsoft wanted to ensure compliance. I had to ask the ASP.NET to ship an older version of jQuery due to a compliance concern regarding a component jQuery used that was GPL. Microsoft was working with jQuery to figure out what would happen. Again Microsoft wanted to protect its customers. If customers wanted to use a GPL Open Source product they can. However, Microsoft would not force usage of a 3rd party Open Source.

Finally, the Open Source of a product by Microsoft could not and would not be a publicity stunt. I added a rule no dead product could be Open Source. Open Source would not be a dumping ground for trash software from Microsoft.  Another principal was every team involved while in the beginning would do most of the work. Pull requests must be allowed and reviewed. If it met the criteria, it should be accepted. Microsoft would always be the stewards of the Microsoft Open Source project. The key word is steward. Ultimately it is up to the community to drive the project. Microsoft is a developer, mentor, leader, and guide, not a dictator. I believe that has lead to a robust community around Microsoft Open Source projects.

Conclusion

While charging for Open Source is one way to make money. It is not the only way. In the case of .NET, and Azure, Open Source is a channel for selling products and services. Thus Microsoft Open Source has been beneficial for customers, developers, and Microsoft.

Using Realm with Xamarin and .NET

In writing the app for Patient-Reported Outcomes in Parkinson's Disease (http://www.propd.org), I needed a more robust persistence service. At the same time, I stumbled upon Realm who develops an Open Source Mobile Database and Mobile Platform. In February 2017 Realm released an SDK for .NET and Xamarin. Realm looked to be robust and scalable, features I require for another project. I decided to use Realm for my PRO-PD project. You can find the code (https://github.com/rsatter/PRO-PD) for PRO-PD on GitHub. I released the source code under Apache license.

 

Calling Realm a Mobile Database underplays Realm's real power as a container, not just a database. Adding a Realm server turns it into a distributed container. How one thinks of Realm as a persistence layer or as a container impacts the implementation of an app.

 

Using Realm strictly as a persistence layer might be the quickest to implement. It keeps the object model and architectural layers intact. A set of Realm objects is created for example RealmOrder. Then a Realm service implementation is built or modify the existing service. The add Order could validate the Order before opening a transaction. Then the Order is copied into a realm version of the Order object. I would suggest something like new RealmOrder(order).

 

Realm realm = Realm.GetInstance();

using (Transaction _transaction = realm.BeginWrite())

{

realm.Add(new RealmOrder(order));

_transaction.Commit();

}

 

The container option may require refactoring classes and application logic. The approach of using Realm as a container is best when building new apps. With Realm, you can think of your solution as a problem domain, modeled by domain objects, and the UIs as windows into the problem domain. Think of Realm as a container for the problem domain. The persistence of state between sessions is just one feature of Realm's container management. To get a better understanding of problem domain and architecture, I recommend reading about Clean Architecture design. For a great post on the subject, check out The Clean Architecture (https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html) by Uncle Bob. This excellent article on software architecture had me rethink my approach to software.

 

If you look at the code for PRO-PD, the app is composed of three main parts Services, Models and UseCases, and the UI in the form of Views and ViewModels. Services as a single service called ContainerService managing Realm and DryIoc. The Models and UseCases contain domain objects survey, patient, and report. It then has use case objects that manipulate the domain objects. Finally, the UI is composed of Views and simple ViewModels that are only responsible for managing a single view. Due to Realm and DryIoc, I could easily port the App to the Web, Tablets, wearables, and pcs. I only need to create View and ViewModel implementations. The problem domain code does not change. To get the data to the researchers, I just need to set up a Realm server and turn on synchronization. The passing around the objects is transparent to the app.

 

The core of the app is the SurveyUseCase. This object is just the algorithm for having the user answer the questions of the survey. When the use case runs, it first executes startup code.

 

  realm = ContainerService.GetInstance();

  // Load survey or create survey if it is not already in the DB
  survey = realm.All<Survey>().FirstOrDefault() ?? LoadSurvey();

  transaction = realm.BeginWrite();
  patient = realm.All<Patient>().FirstOrDefault() ?? new Patient();
  if (!patient.IsManaged)
  {
      realm.Add(patient);
  }
  report = patient.AddReport(); 

 

In the above code, the Realm SDK seems to have little impact. Query for the survey. If not found then load it into Realm. Start a transaction for since Realm supports ACID. Then start creating and updating the objects of the problem domain. Once the use case completes, the transaction is either committed or rolled back. To enable an object to interact with Realm it needs to be inherited from RealmObject.

 

There are a few issues. The first is related to Realm use of Fody (https://github.com/Fody/Fody). Fody is an Open Source project that allows for code injection into your compiled code. Rather than insert boilerplate code everywhere, Fody injects it for you post compilation. PostSharp is the oldest tool that does this. The classic example is OnPropertyChanged, my ViewModel classes littered with SetProperty and a field as the backing store.

 

  public bool IsBusy

  {

      get => isBusy;

      set => SetProperty(ref isBusy, value);

  }

 

The Models do not need any thanks to Fody. I need to have Fody do the same to my ViewModels!

 

The issue is Fody needs an XML file included in the projects. Unfortunately, Nuget no longer allows content injection. Thus you need to create the FodyWeavers.xml file and add it to projects that need it.

 

<?xml version="1.0" encoding="utf-8" ?>

<Weavers>

      <RealmWeaver />

</Weavers>

 

The other issue related to Fody is AppCenter blows up trying to build the Android and iOS projects. I kept getting cannot find RealmWeavers. A big thank you to Shawn Dyas in AppCenter support for finding a solution.

 

<PropertyGroup>

    <SolutionDir>..\</SolutionDir>

</PropertyGroup>

 

Conclusion Realm is a very powerful object database with a beautiful object-oriented SDK. I cannot wait to get my hands on the Realm Cloud.

 

Build Your Own Platform

I have been thinking and discussing with some folks about platforms. Currently there are two approaches to building a platform. The first is building the runtime environment. The quintessential example is Windows OS. If you build desktop apps you use tools specifically designed for building applications on the Windows OS like Visual Basic, PowerBuilder and C++ with MFC. With the rise of the web and no browser monopoly, developers had to deal with fragmentation of the platform. The developer tools and frameworks began to become the platform. Essentially the tools hid the OS or Browser from the developer. Developers just needed to learn the framework and then deploy where the app would run. The two biggest runtime platforms today are Java and .NET. Java’s write once run everywhere captured developers attention. While Java failed on the GUI front I believe it was an implementation issue not a problem with the paradigm.

As iOS market share erodes and Android continues to fragment, developers need to tackle this problem of write once run everywhere head on. Which brings us back to the question of building a platform. The difference is that you the developer must pick what constitutes the platform. What I mean by platform is you the developer chose the OS or your tools as the platform. Neither choices is better than the other. Rather the choice defines how you develop your app and constraints that might be imposed by your choice.

MVC 4 - Game Changer

During the //build/ Day 2 keynote, Scott Guthrie announced a new release of MVC. MVC 4 is a developer preview meaning "danger, Will Robinson, danger". However it is definitely worth a look as it makes building mobile web applications easier. It is also what I have been waiting for to get moving on Web LOB Accelerator. Read on for how to build a multi-device site using MVC 4.

WURFL .NET API

The WURFL team has introduced a new .NET API. The first pass does not have a Nuget package but they are working on it. So it should eventually show up on Nuget.

Creating a Multi-Device Web Site

One of the things I have always wanted to do was write the Mobile LOB Accelerator as multi-device application. One of the things that has held me back is the lack of ADO.NET in Silverlight. Yes I know I can use a lot of database implementations for Silverlight. The problem is that I have yet to find a way to spoof in ADO.NET. I would like a class library that device specific UI then consumes. Ah but how about a web site with device specific UI. This is very doable.

.NET 4 on Server Core

In March a version of .NET Framework 4 was released to run on Windows Server 2008 R2 SP1. You can download the RTM version but what do you get?

.NET 4 on Windows 2008 R2 SP1 Server Core

One of the most asked features of .NET 4 is the ability to install on Server Core OSs. I am pleased to let you know that you can now do this with a caveat. You must be running Windows Server 2008 R2 SP1. So you must upgrade your server to SP1 before installing .NET Framework 4 Server Core Profile.

One other thing to note you must also turn on .NET 2.0 support as well as WOW support. While we are installing the Full Framework be aware that not everything will function on Server Core for example WPF and ClickOnce do not work on Server Core.

The WebMatrix is Here

WebMatrix Beta 3is now available. WebMatrix is a lightweight development environment to enable Razor development, a new syntax for .NET web pages. Lightweight does not mean less features. It is very full featured and cool.

Porting LOB Accelerator to iPhone using MonoTouch

People who have read my blog probably knew this was coming. I assisted Rob Tiffany in writing the second version of his Windows Mobile Line of Business Solution Accelerator. So it is only natural that I try and port it to MonoTouch.