I just upgraded my blog to the latest version of dasBlog. I also moved to another hosting provider. All content has been migrated, but there may be links that are not working on very old posts. I'll check these in the coming days so everything works as it should. If you happen to run ito problems, let me know.
I'm currently working on a project where we have a lot of semi-independent moving parts. One aspect is that we communicate with different applications, in a BizTalk style manner. We do this using Workflow Services to ensure delivery and have fault tolerance when running inside Windows Server AppFabric (see my post What is Windows Server AppFabric and why should I use it?). However, we wanted to ensure that these Workflow Services all provide the same interface from out side of the application, so we can call into them generically. This by the way happens when a status changes occurs on some entity we use. Getting the Workkflow Services to expose the same contract (more or less) is relatively easy. You just ensure that all services use the name namespace, operation name, and parameters. However, calling those generically through WCF was a bigger challenge. Basically we have a table with state transitions, which can hold some string of information about what to do. The choice we made is to have this string be equivalent to the endpoint configuration in the web.config file. Now all we need is a correct WCF contract, and off we go. That took a little tweaking too, but with the help of the below two posts by Ron Jacobs, we were able to pull it off:
Thanks Ron!
Yes, HTML is great. HTML5 (now just known as HTML) is going to be great. It will finally bring that much needed functionality it’s been lacking all these years, and cross-platform to boot. All the major browser vendors are saying HTML is great, and that their browser supports it best. So what could possibly be wrong? Well, for one the browser really seems to be an out-of-date mechanism to provide rich functionality. As an application platform it’s coming apart at the seams, because users want applications that work awesome on their device of choice. Forget the clunky, lowest common denominator browser-based interface, users want Apps with a capital A!
So while one side of the industry is focusing on standardizing on HTML, the other side (within the same companies) is moving in an entirely different direction. The amazing number of apps available and the growth rate in the Apple AppStore, and the Android and Windows Phone equivalents, is the best evidence that this is actually working better. Cross-platform? Forget it! Cross-platform is slow(er), one size fits all, and most important… not sexy.
Don’t underestimate the importance of being sexy. Let me explain by example. The Dutch government has all laws published on the web at wetten.nl. That means it works in all modern browsers on all platforms, including tablets and phones. There’s no flash involved or anything, so it is truly cross-platform. Also, this is very much in line with efforts of recent years to have the entire government use open standards and open source (see NOIV at http://noiv.nl/service/english/). With mobile touch devices on the rise, the user interface of wetten.nl might need an update to be more suitable to touch and smaller screens. Since the website is all HTML, CSS, and JavaScript, the obvious and NOIV route would be to make adjustments to suite the upcoming devices. But what happened instead? An iPad App was built. Is this a logical choice? Nope, not even close. Even if you don’t look at NOIV and look at reach. The website has a far wider reach, and if you wanted to do something beyond that, well there’s a whole lot more Windows PCs out there than there are iPads. Not to mention that it leaves other devices out in the cold. So really, that much effort (and tax payer money) to build an App that adds nothing? Yep, that’s what “sexy” does.
But wait, isn’t Microsoft betting on HTML with Windows 8? Maybe, but I’m not 100% sure about that one yet. Also, Microsoft isn’t known for its choices when it comes to mobile devices. Microsoft sort of invented the tablet almost 10 years ago, but Apple has taken the credit. Microsoft phones haven’t done particularly well, although Windows Phone shows promise. I love mine actually, but I rarely open the browser on that thing. It’s all apps (yup, guilty!)
Where does this leave us? Well, HTML is going to be around for a long long time, but as things are going it will go back to its original purpose: browse information, and primarily for PCs. PCs which are some are already saying are “legacy devices” (I personally believe we’ll move more to hybrid devices, and different devices connected like with Dropbox, Skydrive, iCloud etc.) For the development community this is actually great. Where previously users were complaining about stuff not being cross-platform, they are now actually demanding customized apps for the specific platform they are using, and the government actually tramples over its own guidelines. This means developers have an excuse to have to build an app for at least two or three platforms, so we won’t be out of a job anytime soon. That said, it means that what’s going on at the server is getting more important, because we have to reuse functionality at some level for the costs not to get out of hand. Enter cloud computing, which is great for developers like me: graphically impaired. This by the way is also great for internet providers, providing they can keep up with the bandwidth demand.
As a developer all I can say is thank you Mr. Jobs for putting users with their nuts in the bear trap, and loving it.
In recent years the development story for Internet Explorer wasn't particularly appealing. If you wanted to fix CSS and JavaScript errors, IE was definitely not the tool you wanted to use. Also, seeing what was going over the wire wasn't possible with IE, and as a result developers flocked to FireFox and other browsers offering (plugins) to help with these issues. You don't have to be a genius to understand that in the long run this wasn't helping IE in terms of market share. And with the renewed focus on webbased (HTML5) apps, Microsoft has stepped up and produced built in developer tools, also known as the F12 developer tools. So, what's in there and what can you do with it? What's taking so long?As with IE8, there are inspector tools for HTML, CSS, and script. Since I am by no means an HTML/CSS guy, I'm not the best judge when it comes to these tools, but for what I need from those I've been pretty satisfied. For me, the new profiler and network tools are much more interesting, because they respectively hook into the browser rendering engine and what's going over the wire with HTTP. If you've been using tools such as Fiddler or HttpWatch, the latter of the two should be more or less familiar. As you can see in the image below, it shows all the HTTP requests going out to the server, when in the timeline these requests were going out, and how long that took. If you've never seen something like this, you can see that this provides great insight into what goes down under the covers.  If you need more details about the timing information, you can select one of the items, and see more. As you can see below, that information doesn't only include HTTP information, but also information about the time it took to render and JavaScript to fire. If there's a page that is slow to appear in the browser screen, this will give you great insight into where your time is going.  Is this functionality better than commercial tools such as HttpWatch? Not at this time, but I have a feeling Microsoft isn't done yet. Tools like that are specialized, and Microsoft is playing catchup. One annoying thing I found is that if I have multiple requests bouncing back and forth, filling in a form, etc. IE9 tools will only show me the last interaction. It could be I'm missing something, but I haven't been able to figure out how to see the whole list of requests since I started capturing, and I'm too lazy to figure it out. That means I find myself going back to HttpWatch for that (at the moment). That said, the tooling is good, so if you don't want to spend the extra dime for other tooling, this will do in most cases. Except of course that this only works in IE9, whereas some of the tools out there work in multiple browsers. But wait... there's more. What I'm I getting?An interesting question is always: what HTML will a certain browser actually get. This is where the F12 tools have another nice new feature. You can change the user agent string the server is receiving, and as a result inspect what happens on the HTML, CSS, script side when other browsers come in. Obviously this doesn't make IE9 behave itself as one of the other browsers, but it can provide nice insights nonetheless, especially to tweak what robots are seeing.
 How will it look?The last thing that I fond really useful is the ability to change the browser so you can check the user experience for users with different settings. As you can see from the image below, you can disable css, script, and the pop-up blocker. In the environment I'm working in now, there's often the need to see whether everything still works if JavaScript is disabled, and there this is a great tool. It definitely beats going into the browser settings and changing these settings every time you have to test.
 Last but not least, you can easily resize the browser screen to fit a certain size. I always used Windows Sizer for this, but having this built in is better, because I rarely use it for anything but webdevelopment.  What's more?
There's a whole bunch of stuff I haven't gone into here, so I advise you to play around with the F12 tools for a while. I'm also betting we'll see a lot more where this came from in the not too distant future. Microsoft is investing heavily in HTML5, and is actually trying to use "the best HTML5 support" as a unique selling point for Windows.
If you're a developer using the Microsoft platform and want to learn Windows Azure development, Developing Applications for the Cloud on the Microsoft Windows Azure Platform (Patterns & Practices) is the book for you. It's a clear book which rides on a good practical case that covers most of the important angles. Because this is a Practice & Patterns book, it also spends quite some time teaching you the right mindset for building (multi-tenant) cloud applications.
The downside of the book is that it really assumes a good familiarity with the Microsoft .NET Framework and C#. Without that, you're not going to understand much of the cases, apart from the high-level cloud information. That said, the book starts with a good explanation of why you would want to build cloud applications, the types of scenario's that fit well, and what Windows Azure (and in more general terms Platform-as-a-Service) development means. The example case really covers most scenario's and choices people will come across, and that means it also covers all the core technologies within Windows Azure. Another great thing about the book is the many links to articles and other (free e-)books that provide deeper insight into a certain aspect or technology. Be aware that Windows Azure is a fast moving platform, with changes on a regular basis. Although most of the core concepts in this book will remain the same for a long time, it can't keep up with all the new developments. I hope new editions will follow to keep up with the changes. 
Reading iOs 4 Programming Cookbook by Vandad Nahavandipoor left me confused about the book’s intentions. The book’s audience is stated as for novice AND experts. That rarely works and this is no exception. That said, there is some good, practical content
The first few chapters cover topics aimed mostly at the novice developer. In a language basics book these chapters would typically be somewhere half way through the book. So this is only useful if you just started to learn Objective-C without reading a book. The cookbook format doesn’t help here, because discussing these topics benefit from a nice flow, which the cookbook format doesn’t have. This goes for a lot of content covered. The content itself is not bad, but it should have been covered textbook style, not cookbook style.
Several chapters are good in the cookbook format, such as chapter 4, which deals with maps and location. It quickly explains how to get things done in a practical manner. The book goes back and forth between content that should be part of a textbook (e.g. gestures, networking) and stuff more suitable for a cookbook (e.g. audio/video, camera).
All in all, I think you can get quite a few handy tidbits from this book, but to be fair, this should be split into two books. One textbook, that really starts at the basics of Objective-C programming and teaches you good programming practices, and one cookbook with the good cookbook stuff from this book and with more practical recipes to give it more body.
p.s. I realize I have a real Microsoft aura around me, so for some it may come as a surprise that I read an iOS book. However, I like to keep myself informed about things outside my comfort zone. I am also reading an Oracle book :).
I sometimes use the Visual Studio Class Diagram when I'm designing a system. Because I like to test my assumptions in such a situation I want to be able to quickly create classes that just work. Unfortunately, when you add a property in a class, Visual Studio generates code like this: public string SomeProperty
{
get
{
throw new System.NotImplementedException();
}
set
{
}
}
In most cases what I need is: public string SomeProperty { get; set; }
Fortunately, the PowerToys for the Class Designer and Distributed System Designer solve this problem. After installing these (and turning it on in the Add-In Manager), the right click menu is enhanced with a lot of new options. One of the is Add->Auto-Imlplemented Property, as shown below. 
Earlier I blogged about finding performance issues in an ASP.NET app "in the large" (see here). I'd like to reiterate that doing this for a web app is critical, because it not only shows you where the bottlenecks are, but also how these affect the entire application. I said I'd follow up on profiling, so here it is...
Once you know what the bottlenecks or "hot spots" are, you can dive into figuring out what the problem is with these pages. This is where profiling comes in. Profiling lets you know what is happening inside your code. It shows you how long a method call is taking and how often a call is made. Both of these are interesting, because performance bottlenecks can be caused by calls taking long, but also by too many calls to a method. Now, I won't get into the details of how to profile with Visual Studio 2010 (you can read Beginners Guide to Performance Profiling for that), but when you use this tooling, you should focus on one page at a time. The profiler will throw a heap of information at you, so dealing with one page is hard enough. Once you have this information you have to determine what's really going on. Is this somehting you can fix by changing a few lines of code, or is there a more structural problem you need to solve? Pages that under no load take 10 seconds or more likely have a structural problem, so you need to check if there is a lot of code being executed that is just waste. Also, be sure to focus on big fish first. You can worry about micro-optimizations (such as a different string compare mechanism) later. That said, you should try to make such optimizations part of your coding guidelines, rather than looking at that afterwards. Micro-optimizations are only really interesting for very high performance apps. A 10th of a second loss here and there isn't going to make a lot of difference apart from maybe needing to scale-out a little earlier.
It is typically a good idea to separate general authorizations of a user from application specific authorizations. This is why we invented Application Roles (Settings Administrator), which are separate from Organizational Roles (System Administrator).When using Application Roles, we can map these roles to Organizational Roles. In organizations using Active Directory, Organizational Roles are typically stored in AD. Application Roles can then be stored using Authorization Manager (AzMan) in XML or AD in Application Mode (separate from the organization AD).
Over the years I've built quite a few applications that use the above model, and it works well if you authorize with roles. But these days I do most of my work using things like Claims Based Authorization, so the question is "Does this translate to teh CBA world? And if so, how?". The answer is that yes, it does translate (very well actually), at least in Windows Identity Foundation.
In the CBA world an application receives a token with claims about the user. Like with roles, this should typically be claims not specific to the application, unless the only source for the claim information lies within (or is only accessible to) the STS. This serves two purposes:
- The token is generally usable across applications, so the STS can deal with this more easily.
- Tokens are not stuffed with a lot of claims.
The latter is actually more important than you might think. Adding more claims means a bigger token, and there comes a point where the token is so large that for instance ASP.NET rejects the request, because it is bigger than the accepted request size (which you should only increase if really necessary).
Now, one of the great things about CBA is that it enables me to create business logic which checks the authorization based on meaningful values, rather than a role. On top of that, I wouldn't want to have a hybrid security system for the claims stuff and the application specific stuff. Fortunately, In Windows Identity Foundation I can add claims to a claims identity, and these claims then behave the same as the claims acquired from the STS token. The only difference is that the issuer is set to LOCAL AUTHORITY, rather than the STS, which means these claims are really only usable locally in my app (or service). The code to add a local claim is easy: IClaimsPrincipal claimsPrincipal = Page.User as IClaimsPrincipal;
IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity;
claimsIdentity.Claims.Add(new Claim("http://MyApp/SomeAppClaim", "SomeValue"));
You can execute code like this when a session starts, and add all application specific claims for the user (identified by an STS claim) to the claims identity. The local claims then get the same lifetime as the claims originally from the token, so you only have to add them once. This way adding application specific claims is still separated from the functional code. Which was the benefit to start with.
Although the above code will definitly work, there is another option when using WCF, known as Claims Transformation. With Claims Transformation you can define policies that define ClaimSets to add to a user's token. This model is much more flexible, as explained in the MSDN article Service Station: Authorization in WCF-Based Services (jumps straight to the Claims Tranformation section). That article is from the pre-WIF era, but you can do similar stuff with teh ClaimsAuthorizationManager in Microsoft.IdentityModel.
|