My take on Win8/Metro

Posted on May 29, 2012 by johnvpetersen

I attended the Developer Camp at the Microsoft Malvern Office last week [Thursday].

Kudos to Dave Isbitski and Lindsay Lindstrom for putting on a superb presentation.

Pros:
-  Metro, as a vehicle to display information is nice
-  The ability to pick between C#/XAML and HTML/JS is a plus
-  App suspension and O/S integration for shared features across apps is a plus
-  Very easy to consume Web API’s

Cons:
- Metro requires Windows 8 (not that Win8 is bad, but requiring an O/S rev for an app is costly and often, not practical/feasible)
- I can write a metro-looking app today with the HTML5 stack
- Metro apps represent only one aspect of business computing: reporting/dashboards – with moderate-light data update requirements
- Not X-Platform
—————————————————-
Many companies are just beginning their migration to Win 7. Many are still on XP.  IMO, I see MS’s strategy as proposing that a problem exists and that Metro is the solution. The belief is that this will drive Windows 8 sales. From an OEM standpoint – I see it in the consumer/retail sector. I don’t see it in the enterprise for at least a few years.  As of today, as I understand it, Win8 will not connect to enterprise assets such as Active Directory. No doubt, this deficit will be addressed.

As nice as Metro-style apps are – as of right now – I don’t see it as anything more than a new way to consume information. The bashing of windows borders (chrome), min/max buttons, etc – is a bit of a  straw man argument IMO. Indeed, overlapping windows, multiple scroll bars, etc. is bad. That, IMO, is a matter of bad UI. As is usually the case, the problem is not with the tool, but how the tool is used.

We can build Metro-looking apps today. There is a distinction with Metro-style and Metro-looking. Metro-style apps are built on the WinRT, are integrated into the Win 8 OS, go into suspend mode, etc. The irony is that it is the look and feel of Metro that is being pushed. And given that we can build Metro-looking apps today, I seriously question if there will be a perceived need to migrate to a new OS for the sake of Metro when there are alternatives to get essentially the same look and feel. Never before have we had to have on the critical path – an O/S rev in order to deploy an application. As somebody who is part of a management team that runs a business, these practical business issues are what gets my attention and have me much more concerned. Not a day goes by where I ask myself “How can I sell this?” As consultants, we are, IMO, ethically obligated to serve the best interest of our clients. If asked today about the value proposition on Win8/Metro, given the current landscape, I’m hard pressed to be able to quantify or to conclude if the value proposition is in positive territory.

It seems to me that the WinRT was something that could have sat on the Win7 platform.  I very much like the calls to add Metro to Win7. Metro, as a UI/UX heuristic, is uniquely a Microsoft Contribution to computing. Why not facilitate it being more in the mainstream of open development?  It’s a conundrum.  Metro apps look great. They are very pleasing to look at. They emphasize the information and thereby enhance information consumption. Its implementation however, is very limited. It only covers a portion of what we end up needing to deliver to clients and it requires a specific O/S. It’s not X-platform  – in spite of the fact that you can use your HTML/CSS/JS skills to develop metro apps. I think it will be several years before Win8 gets traction in the enterprise. For the most part, O/S adoption has been something we have not had to worry about. We really don’t care whether they are on Vista, XP or Win7. But for a metro app – you need Win8 – and that entails costs that extend beyond any specific project budget. Let’s remember – O/S revs for the enterprise are a big deal. They don’t happen often. These are at least 5-year decisions. And again, many companies are just making their way to Win7.  Will there be leap-froggers who go to Win8? No doubt the answer is yes. Win7 was and is a compelling upgrade and that means for many, another O/S rev in the near future is not in the cards.

Bottom line, the issue has more to do with business, the business of computing and less do with the technical aspects of computing.

Recommendations:

Be mindful of the UI heuristics that are prescribed in Metro. There is a lot of merit to the science and thought behind Metro and that was one of my big take aways from last week’s developer camp. Much of what Metro prescribes can be adopted today in other areas. On one hand, don’t discount Win8/Metro because it is not available yet. Take time to learn about it. Get Win8 on a VM and play around with it. Eventually, it will be here and as Windows Devs, it’s something we will need to be familar with.  On the other hand, don’t start thinking of a Win8/Metro world just yet. There are apps to be delivered today and tomorrow that won’t lend themselves to Metro. For one thing – it’s very different and companies are often slow to adopt change. The key is to have the “Killer Application” for Metro. IMO, it’s in the area of dashboards/reporting – and general information consumption with some limited data update capabilities. Finally, don’t link the adoption of Dev 11 (Visual Studio v.next) with WIn8/Metro. While Metro apps can only be built and deployed under Win8/Dev 11 – Dev 11 will work just fine in Win7. There are a lot of nice productivity features in Dev 11 that make it a compelling upgrade aside and apart from Metro.

Posted in Metro Style Apps, Opinion, Windows 8 | Leave a comment

Code Query and Rule over LINQ

Posted on May 24, 2012 by Patrick Smacchia

Yesterday, after two years of a relentless development effort, we finally released NDepend v4. Personally, I consider this version as the biggest milestone we’ve ever achieved. The three flagship features are:

  • Code query and rule over LINQ (CQLinq)
  • NDepend.API to let user develop its own static analyzers (+14 OSS Power Tools proposed on top of NDepend.API)
  • VS11 addin support

Developing these features by respecting the following drastic requirements was a real challenge:

  • Features Richness: The code query features set was already rich in prior versions, but we wanted it to be even richer to be able to write easily all the code queries and rules that existing users asked us.
  • Syntax: Queries must be easy to write and to read. Hopefully most NDepend users are aware of the C# LINQ syntax, but the proposed code model API needs to be LINQ-friendly. We started with a three months research effort to define what was the cleanest syntax to express a few dozens of essential code queries. A few natural syntax enhancements were also developed (like the prefix warnif count > 0 to transform a code query into a code rule).
  • Performance: We wanted something like a hundred of queries compiled and executed per second against a large real-world code base, because we want them to be run often in VS without slowing down the IDE.
  • Usability: We wanted query edition to be seamless thanks to code completion, live tooltip documentation and detailed error reporting.  All this without the Roslyn power that is not yet RTM. Also, for v3 users, we’ve developed a CQL to CQLinq automatic converter (and CQL is still supported).

One simple CQLinq code rule that illustrates well all these, is the following one.

Hopefully the syntax is simple enough to convey the underlying meaning to any .NET developer. Only the JustMyCode highlighted word might not be clear. It represents a facility proposed to avoid matching generated code elements, that often are pesky false positive matches for code rules.

After  an instantaneous compilation/execution phase (1 millisecond), the result is displayed with facilities for browsing it and exporting it:

Today, I’d like to focus a bit more on the syntax aspect. Developing for LINQ and with LINQ during the last two years has been a great joy. Everybody agrees that LINQ is very elegant, but it is also a super-extensible technology.

We extended LINQ in several different ways. One way has been to develop a LINQ-friendly fluent API. Often we found convenient to write default code rules with a mix of both Query Expression and Query Operator syntaxes. Takes the following rule for example.

  • First, we define with two fluent sub-queries (expressed with the operator syntax)  the UI layer (types in namespaces using any UI framework) and the DB layer (types in namespaces using any DB framework)
  • Then we use more fluent query operator syntax to check if the UI layer is using the DB layer.
  • Finally the whole query is structured with the query expression syntax.

In a few lines of code, we are expressing fluently a pretty complex and popular requirement, in a generic way adaptable to any situations.

For a few years now, the code metric C.R.A.P (Change Risk Analyzer and Predictor) became increasingly popular in the Java community thanks to the crap4J plugin. The C.R.A.P metric has been exposed by Alberto Savoia in this Artima article dated from October 2007. The C.R.A.P metric is a mathematical formula that helps to determine which piece of code is both complex and poorly covered by tests. Since both code coverage and cyclomatic complexity code metrics are proposed by the NDepend.API code model, it is fairly easy to write a CQLinq code rule to match crappy code:

A popular feature of NDepend is the ability to diff two snapshots of a code base to explore what was changed. This feature being completely integrated with CQLinq, it is now possible to write simple code queries that will match complex evolution requirements. One immediate requirement that comes to my mind, is that a class 100% covered by tests should remain 100% covered by tests, no matter whether it has been touched or not. The following CQLinq code rule detects classes that are not anymore 100% covered by tests (since the predefined base-line), and lists the culprit methods, i.e the method that are not 100% covered anymore:

Hopefully CQLinq is a simple answer to many requirements that formerly demanded significant efforts (imagine the effort to develop the tool crap4J compared to the effort of writing a single CQLinq query). You can download freely and try CQLinq live on your code base, and here you can browse all 200 default code rules.

In future posts I’ll dig into the low-level implementation tricks needed to implement all this.

Posted in Code Query, Code Rule, CQLinq, NDepend, Object oriented programming, VS Integration | 2 Comments

Two ways to work with HTTP responses in ApiController, HttpResponseMessage and HttpResponseException

Posted on May 24, 2012 by Glenn Block

ASP.NET Web API provides two different ways to work with manipulating HTTP response messages from within your API Controller action.

  • Throw an HttpResonseException – This exception allows you to pass in an HttpResponseMessage / set status and headers. Web API will then immediately return the response.
  • Return an HttpResponseMessage – You can simply return an HttpResponseMessage from your action.

So which  should you use when? Are they both identical? Cuong Le recently asked this question on StackOverflow.

The simple answer is no they are not the same.

The main difference between the two is this. The exception is useful to immediately stop processing and exit. For example assume I have the following code

If this code runs and I pass an id that is not present, it will immediately stop processing and return a status code of 404.

If instead I return HttpResponseMessage, the request will happily continue the rest of it’s processing and return a 404. The main difference being end the request or not.

As Darrel said, the exception is useful in cases where in some cases I want processing to continue (as in when customer is found) and in others I don’t.

The place where you might want to return HttpResponseMessage directly is in an HTTP POST to return a status code of 201 and set the location header. In that case I do want processing to continue. That would would do with this code.*

*note: If you are using the beta bits you would create a new HttpResponseMessage<Customer>. I am using the later bits however which require you to use the CreateResponse extension method off of the Request.

Above, I am creating a response which sets the status code to 201, passes in the customer, and then sets the location header.

The response is then returned and the request continues processing.

Hope this helps clarify the difference.

Posted in ASP.NET Web API | 2 Comments

A story on composable systems

Posted on May 23, 2012 by Dru Sellers

<warning>This is a long post that attempts to describe a positive experience leveraging multiple frameworks</warning>

TL;DR. Static Typing / IoC == AWESOME FLEXIBILITY

Recently while working at Dovetail I had the absolute pleasure to provide a solution to a customer request. We were adding SAML authentication to our product, and we wanted to provide an extensibility point to handle unknown users. By default the product would show a not authorized screen if we encountered a valid SAML assertion referencing an unknown user. This was pretty easy to setup, but as I said, we really wanted this to be extensible. What I wanted to support was redirecting the user to a different page, maybe one that a customer has specified which would give the user the information needed to request access to our application through the approved channels. That would have been pretty easy with just a configuration entry, but we decided that really wasn’t enough. We also wanted to be able to handle a request to make a user right there. Well, now we need the ability to execute some code, a configuration file isn’t going to handle that very well. Even if we kept the config file approach we would have to redirect the user to somewhere else in the app, and then figure out how to shuffle all of the required data around. :( It just didn’t feel like a solid solution.

Thankfully, FubuMVC, Bottles and StructureMap came to the rescue. FubuMVC gives us controllers that can easily take dependencies on services (nothing to fancy here, you can do this in ASP.NET MVC too). So our SAML Authentication controller (or action in Fubu land) takes in a service that acts as a policy (SuccessfulSamlAssertionPolicy) it takes a valid SAML assertion, and attempts to locate the user in the database, if it finds them, the policy logs them in, and then redirects the user to the home page. If we can’t find the user, then we invoke the UnknownUserPolicy (another service/policy thing which is injected in the SuccessfulSamlAssetionPolicy) the default implementation of this policy simply redirects them to an error page of ours, but since it’s a interface/class pair, we can easily swap that out. This is where IoC/DI/StructureMap make things really nice.

So, the above may seem a bit complex (I definitely didn’t explain it that well). So lets break it down and make it concrete. I have an interface that looks like this

public interface UnknownUserPolicy
{
    //FubuContinuation is a way to redirect the user
    FubuContinuation HandleUnknownUser(SamlAssertion assertion);
}

we ship with the following implementation

public class DefaultUnknownUserPolicy : UnknownUserPolicy
{
    public FubuContinuation HandleUnknownUser(SamlAssertion assertion)
    {
        return FubuContinuation.RedirectTo<LoginController>(c => c.Login(null));
    }
}

Super easy code, nothing too hard here. We wire it up in StructureMap using a convention, so there is really nothing else to show. Now, lets imagine we have a customer, that doesn’t want them redirected to the login page, they should instead go to: https://silly.corporate.subdomain.company.com/request_access.cfm . Using StructureMap, this is as easy as registering our policy later in the container (after the default registrations) by adding a line like this:

For<UnknownUserPolicy>().Use<CompanyXUnknownUserPolicy>();

That will override the default policy and boom! We have just customized our application for this one customer. So that’s great and all – but I want that in only ONE deployed instance of the application. I do not want to modify the base product for this customer, and this is where Bottles comes to my rescue. :)

Bottles is a framework for assisting us in loading dynamic code in a controlled and predictable manner. Its built with an IoC container in mind, but is completely agnostic of them and FubuMVC entirely. When our application starts up, we go through all the usual stuff for a .Net / IoC project. We initialize logging, spin up our container, blah, blah, blah. The one new step that we add with Bottles though, is to run through every discovered Bottle, and look for ‘StructureMap Registries’ and load them into the container. Now, a bottle is pretty much a glorified zip file holding .Net assemblies — among other things. The bottles, being a separate file from the base product, can be used to modify our existing application. In this case, we have a Customer Bottle that does one thing. It executes that above piece of SM registration code to override the base UnknownUserPolicy. :) WIN.

So, by putting all of these various tools, patterns, and frameworks together, we were able to build a solution that allows for a lot of customizability, does NOT require us to change our base product (would have loved to have had this at the bank), and I think truly encapsulates the changes that customizations for a customer can bring into one easily deployable unit.

There are a LOT of things going on in this post, we have programming to interfaces, we have making small classes that do one thing well, we are using IoC, we are using a web framework that makes redirecting deep in the bowels of the app easy and testable, we have composition, dynamic code loading and a lot of ‘abstractions’ (Yup, learned about those at a young age ;) ). Using all of these has allowed us to add a lot of seams to our application, and it’s this kind of power that keeps our application nimble and easily customizable for any customer.

Posted in Uncategorized | 6 Comments

A Gentle Reintroduction to the Reactive Extensions for JavaScript

Posted on May 21, 2012 by Matthew Podwysocki

One of the things that I’ve been doing since I last blogged has been working on the Reactive Extensions for JavaScript (RxJS).  Since I last blogged, we have had two releases, a version 1.0.10621 SP1 which we released back in December of last year and version 2.0 Beta which was just released a couple of weeks ago.  You can check out the release notes for each version, v1.0.10621 SP1 and v2.0.20327 Beta respectively.  Along with these releases, we’ve also put the packages up on NuGet, create Visual Studio style documentation/intellisense, and put the bindings for third-party libraries and runtimes such as Node.js, jQuery, Dojo, ExtJS, MooTools and others on GitHub.

With the release of version 1.1, it was a complete re-engineering effort to not only maintain parity with the .NET version, which had changed quite a bit since the Reactive Extensions for JavaScript was first released.  Not only did we maintain parity with the .NET APIs, we also made an effort to make it feel more like JavaScript, but camel-casing the names to be more inline with JavaScript itself. For example, the old way of doing things with version 1.0 with C# style API calls:

Becomes camel cased to fit more in line with JavaScript norms.  This move made us rename some of the methods which collide with JavaScript reserved words such as Return => returnvalue, Catch => catchException.

The Reactive Extensions for JavaScript V2 Beta once again tries for parity with the Reactive Extensions for .NET V2 Beta in terms of APIs, but differs as with the current release, we still support the old schedulers of Immediate, CurrentThread and Timeout.  We’ve also added new experimental operators such as imperative operators as if, case, for, while and do while, as well as others such as fork join.  I’ll go over more in detail in subsequent posts.

Conclusion

In the coming posts, I’ll go over in detail, reintroducing the Reactive Extensions for JavaScript, why it’s useful and where you can take advantage of it.  Check us out on GitHub, download us via NuGet or the MSDN Data Developer Center, and give feedback on the forum!

Posted in JavaScript, Reactive Framework | Tagged , , | Leave a comment