About me

Michael L Perry

Improving Enterprises

Principal Consultant

@michaellperry

User login

What’s so special about Windows Phone?

I’ll be presenting at DalMob this Tuesday evening. DalMob is a mobile development group that crosses all of the platforms. Most of the attendees are iPhone and Android developers. I’m going to demonstrate the key features that make Windows Phone different from a developer’s perspective. These are:

  • Panorama and pivot
  • Live tiles
  • Storyboard animation
  • Data binding

Demo code is borrowed from Chris Koenig. Slides are borrowed from Megan Donahue on Advanced Application Design for Windows Phone at Mix’11.



Correspondence presentation from Dallas .NET User Group

The recording of my Correspondence presentation is up on UserGroup.tv. This one covers Silverlight out-of-browser applications. I used Thought Cloud as a demo, and opened it up for the audience to participate. It makes for some interesting on-screen shenanigans.



DevLink app results

DevLink 2011 was a fantastic conference. I met some well-known members of the development community. And I met some brilliant people. Occasionally, these were one-and-the-same!

I presented two sessions at DevLink. The first was on the CAP Theorem. I’ve posted the slides and demo for your perusal. The second was on Correspondence, the same session I gave at Dallas TechFest the week prior. Both sessions were well attended, though I did have problems with my live coding demo in the Correspondence session. Fortunately, the first demo had already gotten the point across.

Like I did for Dallas TechFest, I created a conference application using Correspondence. I pushed this app to the Marketplace for attendees to use. This time, I got 30 downloads out of about 650 attendees, and only one review. So the overall percentage was lower this time around, but still useful.

The one reviewer gave the app 4 out of 5 stars, with the following comment:

So far I really like it. It seems a little slow but I like the format a lot better than the eventboard program.

The EventBoard application that he references was the official app available on the Windows Phone and iPhone platforms. It’s really cool to be favorably compared with a professional app. I think the primary differentiator between the two is that, where EventBoard is all about the event, my app was all about the attendee. The first page of my app shows your schedule. The first page of EventBoard shows a list of events.

Performance enhacements

The reviewer noted that the application seems a little slow. This is because of performance problems in Correspondence. I made some improvements, but was unable to get them into the Marketplace in time. More performance enhancements are on the way.

The first enhancement was to reuse the IsolatedStorageFile object rather than recreating it. Every example of using isolated storage that I’ve seen follows the same pattern:

public class IsolatedStorageStorageStrategy : IStorageStrategy
{
    public static IsolatedStorageStorageStrategy Load()
    {
        var result = new IsolatedStorageStorageStrategy();

        using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication())
        {
            using (BinaryReader input = new BinaryReader(store.OpenFile(ClientGuidFileName, FileMode.Open)))
            {
                result._clientGuid = new Guid(input.ReadBytes(16));
            }
        }

        return result;
    }
}

Isolated storage is notoriously slow. It was easy to isolate the slowness to the creation of the IsolatedStorageFile object. So I just changed the pattern:

public class IsolatedStorageStorageStrategy : IStorageStrategy
{
    private IsolatedStorageFile _store;

    private IsolatedStorageStorageStrategy(IsolatedStorageFile store)
    {
        _store = store;
    }

    public static IsolatedStorageStorageStrategy Load()
    {
        IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication();
        var result = new IsolatedStorageStorageStrategy(store);

        using (BinaryReader input = new BinaryReader(store.OpenFile(ClientGuidFileName, FileMode.Open)))
        {
            result._clientGuid = new Guid(input.ReadBytes(16));
        }

        return result;
    }
}

This was low-hanging fruit. Other performance enhancements that I have in the queue are:

  • Pooling the Stream objects instead of opening and closing files.
  • Switching from XML to binary serialization of facts for HTTP communications.
  • Pulling more facts at a time from the server.
  • Evaluating SQL CE as an alternate storage strategy.


The CAP Theorem and its Consequences

Here you will find the slides and code from my talk “The CAP Theorem and its Consequences”. The slides are in Silverlight, so use these controls to navigate:

  • Page down/up to go forward and back by slide.
  • Arrow down/up to go forward and back within a slide (Definitions, Proof, Choices, and Event Sourcing).
  • Scroll wheel to zoom in.
  • Drag to pan.

You can also download the source code and run the examples yourself. Run databases.sql to create the three databases. Populate the databases with test data in accounts “12345”, “23456”, and “34567”. The application transfers money among these accounts.

Get Microsoft Silverlight

For more information, please read the summary article.



Dallas TechFest 2011

I presented two sessions at Dallas TechFest this year. I also attended some excellent sessions, hung out with old friends, and made some new contacts. Thanks to Tim Rayburn, Teresa Burger, Shane Holder, and other organizers, this was a fantastic event. They’ve really set the bar high for next year.

My sessions

My first session, Provable APIs, was very well attended. This talk presents techniques that you can use to ensure that people consuming your API do so correctly. These techniques take advantage of the compiler, and the type system in particular. I present samples in C#, but the techniques work well in any statically typed language.

The session was very well attended. We had people using not only .NET, but also Java, and C++. We even had some dynamically-typed languages represented including JavaScript and Ruby. Although they don’t have a compiler and static type system to leverage, they can still use some of these techniques.

The audience was extremely interactive. They posed some excellent questions. They were particularly interested to see a refactoring of the .NET Socket class, with its notoriously error-prone API.

My second session, Correspondence: Occasionally-Connected Windows Phone Apps, was not as well attended. Those that did participate were rather quiet during the theory portion, but started to interact during the demo. Based on their feedback, I will move the demo to the beginning of the talk, and save the theory only for after I get questions about how it works.

The app

The demo for the Correspondence session was actually the Dallas TechFest 2011 Windows Phone 7 app. I got some great feedback from people who were using the app during the conference. I also saw a few bugs that others reported and that I experienced myself. I’ll be rolling out bug fixes for upcoming conferences.

All told, I had 22 downloads of the app. Out of those, I received 2 ratings with feedback, for an average of 4.5 stars. 22 downloads out of a possible set of about 200 attendees, only about 30% of which carry Windows Phones, is pretty decent reach. And to get 10% of the downloads giving feedback is excellent. Sure, the absolute numbers are too low to make any generalizations, but I’ll take what I can get.

The DevLink 2011 app is in the Marketplace now. If you are attending DevLink and you carry a Windows Phone 7, please give it a try.

Old friends and new contacts

Tim, Teresa, and Shane are all old friends, so to see them pull off such an outstanding conference was a real treat. As an added bonus, I got to see a good friend from work present in his first conference. Girish Gangadharan presented on JQuery, and packed the room. Actually, I didn’t see him present because my Correspondence session was at the same time. But I saw pictures, so I know it was a full house.

I also got to meet some new folks. Devlin Liles from Improving Enterprises and Jay Smith from Tyson Foods are active members of the open source community. Their tools help out user groups and event organizers across the country and the technology spectrum. I look forward to working with them on community-centered open source projects.

I had a great time at Dallas TechFest this year. I’m looking forward to following up on all the contacts I’ve made, to applying all the techniques that I’ve learned, and most importantly to participating next year.

Now on to DevLink.



Correspondence

Correspondence is a collaboration framework for occasionally-connected clients. Express your model once, and it gives you local storage, synchronization, and push notification across devices. We currently support Silverlight, Windows Phone, WPF, and MVC 3. Android is coming soon.

Collaborative framework

LogoPeople don’t just own one computer anymore. Now they have a desktop, a laptop, and a phone. They want their data to seamlessly flow across all of their devices.

People take their devices with them. These devices aren’t always connected. And even when they are, people don’t want to wait for them to connect to a central server. Everyone should have their own data on their own device for immediate access.

People use software to collaborate with each other. Some domains are overtly collaborative, such as social networking and gaming. Others are more discreet, like customer relationship management and project planning. Actions performed by collaborators affect the user experience.

Systems built with Correspondence

We have built a number of systems using Correspondence.

  • HoneyDo List: Todo lists that you can share with your family.
  • Commuter: A continuous podcast playlist for iTunes on Windows.
  • Faceted Reversi: Head-to-head reversi game for Windows Phone.
  • Dallas TechFest 2011: Personal conference schedule for Windows Phone.
  • Thought Cloud: Collaborative mind mapper (demo).

Slides

The slides for the presentation are rendered in Silverlight. Once the page loads, click on it to give it focus. Then use Page Down to progress through the presentation. Hit F11 to enter full-screen mode. The sample code used in this presentation is on GitHub.

Videos

Get started

These are the resources you will need to build an occasionally connected Windows Phone 7 or Silverlight application using Correspondence.

  1. Install the NuGet Package Manager through the Visual Studio 2010 Extension Manager. Detailed instructions on the NuGet project site.
  2. Add the Correspondence.WindowsPhone.AllInOne or Correspondence.Silverlight.AllInOne package to a Windows Phone 7 or Silverlight 4 application.
  3. Follow the walkthrough on the Correspondence project site to learn how to build a Correspondence model.
  4. Sign up for a synchronization server API Key. Put the API key in your POXConfigurationProvider.


Speaking at Dallas TechFest

I’ll be presenting next week at Dallas TechFest. I’m doing two sessions: Provable APIs and Correspondence for Windows Phone 7.

Provable APIs is a session that I originally created for the Q.E.D. lunches at work. It shows how you can use regular features of your compiler – not even the new contract validation stuff – to verify that people are using your classes correctly. If you create your APIs provably, then your users will find it a pleasure to work with your code.

Correspondence is a library for building occasionally connected clients. I used it to build the Dallas TechFest conference scheduling app for Windows Phone 7. In this session, I take apart the conference app and show you how you can build your own great user experiences.

As an added bonus, I will reveal the Correspondence logo at the conference. Come out and see it before I post it on the project site.



Microsoft MVP in Client Application Development

MVPLogo

I have received the Microsoft MVP award in Client Application Development. While this award is intended to recognize community leadership, I feel that it is only possible because of the support I get from the community. Thank you for attending my talks, asking great questions, and encouraging me to learn and to teach. This recognition will open even more doors for us to converse. And for that I am grateful.

Special thanks go out to Chris Koenig, who gave me little pushes, key opportunities, and finally the nomination that lead to this award.



Thought Cloud

Capture thoughts and share them with others.

Get Microsoft Silverlight

Right-click and install on this computer for off-line use.



Approaching an ideal from two directions

The ideal specification is unambiguous. After reading such a specification, the consumer should have no question as to the correct behavior of the system described.

The ideal code is not extraneous. There are no implementation details written in the code that were not part of the problem domain. Such details would not have been described in the specification, and could therefore not be verified as correct. If they can’t be verified as correct, then they must be arbitrary. If more than one arbitrary implementation choice could lead to a correct program, then why must the programmer make the decision? And why must he express that decision in code? The computer could figure it out.

As specifications approach their ideal lack of ambiguity, they remain firmly in the state of having no extraneous parts. The specification doesn’t contain implementation details. The customer doesn’t care how it is implemented. They just want it to be correct, and optimized for cost and speed.

As code approaches its ideal brevity, it remains firmly unambiguous. Since code is executed by a deterministic computer, the computer knows at any point what the program will do. There is no question.

Specification, in trying to become unambiguous, is approaching code. Code, in removing extraneous details, is trying to become specification.

Example: a checkbook ledger

If we were to write ideal specifications for a checkbook ledger, we would use only terms from the problem domain. We would define a transaction. We would say what a user could do with a transaction. And we would describe the reaction of the system to those operations. These statements would leave no doubt as to the correct behavior of the system. For example, we could write:

  • A transaction is a named, dated event that either increases or decreases the balance of an account by some positive amount.
  • A user can create a transaction, giving the name, date, and amount of increase or decrease.
  • A user can change the name, date, or amount of a transaction.
  • A user can void a transaction.
  • The system displays transactions in chronological order.
  • The system displays the running account balance of each transaction, that being the previous transaction’s running account balance plus the current transaction’s increase or minus its decrease.
    • The chronologically first transaction, having no previous transaction, assumes a prior balance of zero.
    • A voided transaction does not increase or decrease the prior balance.

If we were to write ideal code for a checkbook ledger, we would only solve the business problem. Storage, communications, and representation details would be handled by our chosen frameworks. We wouldn’t have to describe how a transaction is turned into bits on the network, nor would we have to generate SQL statements to persist or query them. For example, we might write this code:

Transaction(BelongingTo: Account) {
    Name: string
    Effective: date
    Change: [Increase, Decrease]
    Amount: decimal {Amount > 0.0}
}

Void(Voided: Transaction) { }

Account {
    Transactions {
        Transaction t : t.BelongingTo = this
        where not exists Void v : v.Voided = t
        order by t.Effective
        select {
            t,
            RunningBalance = (prior.RunningBalance ?? 0.0) +
                (t.Change = Increase) ? t.Amount : -t.Amount
        }
    }
}

The code verifiably satisfies the specifications, because it says no more and no less than the specifications do. In fact, besides the syntax, the code is the specification. The two artifacts, each evolving toward its own ideal, have ended up in the same place.

Programming languages of the future

No programming language yet developed is as concise as the above code. But we are getting closer. Modern frameworks raise the level of abstraction to remove implementation details from application code. Languages are moving away from the imperative style and adopting declarative and functional styles.

Today, programs are be specified by a Business Analyst, who is skilled in decomposing and unambiguously describing business processes. And programs are written by developers, who are skilled in constructing solutions from technical components at all levels of abstraction. But when programming languages finally do reach this level of brevity, a new discipline will emerge. Neither skill set will be sufficient to solve business problems with software. One person will create this artifact, an executable specification, using a mix of these two skill sets. This person will possess the mind of a mathematician.