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.
Performance issues can creep up in all sorts of places. Finding them is all about knowing where to look. This also depends on how you look, which can be at the application as a whole ("in the large") or at individual functions ("in the small"). The latter is known as profiling. Because (ASP.NET) web applications are all about large numbers (of users), looking at the application as a whole is a good place start. This is where load testing (a.k.a. stress testing) comes in. Load tests will show you which pages are performing poorly, which is the first step in determining where to take a closer look. Load Testing 101: ASP.NET Web Applications is a great starting point to get yourself up to speed with the mechanics of a good load test, even though its from 2006.
One thing in the article that I think is absolutely critical is about creating a single user base line. This will show you which pages are doing well, when run on their own vs. pages that are doing not. The results of that test already give you an indication of where to look. In fact, a full load test may actually skew the results, because fast pages can be held up by slow pages if the request queue fills up. Fast pages can be identified under load from the difference between the best, average, and wordt results. For fast pages these show huge differences (from few tenths of a second to tens of seconds), whereas slow pages have numbers which are bad across the board.
If you're looking for tools to do load tests, checkout the Web Capacity Analysis Tool (WCAT) provided by Microsoft. The downloads can be found here:
An interesting tool you can use with WCAT is the WCAT Fiddler Extension for Web Server Performance Tests. It helps you to record a path through your app with Fiddler, and then use that path in a WCAT load test.
Note: I will cover profiling ("in the small" testing) in a different post.
Op het SDN Event van 13 december heb ik twee presentaties gegeven. Hieronder kun je de aantekeningen downloaden die ik gemaakt heb op de tablet (voor wie er niet bij was: ik heb in plaats van slides mijn sessie gedaan met behulp van tekenen in OneNote).
De demo's bij ASP.NET Aanpassen volgen op korte termijn (vermoedelijk komend weekend... leuk speelgoed voor de kerst).
A while back I blogged about how to deal with unsecured responses in WCF (see this post). I've had several people ask me for the code that you can use in case you can't use the mentioned hotfix. Attached is the code for a message encoder that intercepts the MessageSecurityException thrown by the original encoder. The encoder wraps around the actual encoder you want to use, so you'll have to configure it like this: <system.serviceModel>
<extensions>
<bindingElementExtensions>
<add name="unsecureResponseEncoding"
type="UnsecureResponseEncoder.InterceptingMessageEncodingElement, UnsecureResponseEncoder,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</bindingElementExtensions>
</extensions>
<bindings>
<customBinding>
<unsecureResponseEncoding>
<textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
messageVersion="Soap11WSAddressing10">
<readerQuotas maxDepth="32" maxStringContentLength="8192"
maxArrayLength="16384" maxBytesPerRead="4096"
maxNameTableCharCount="16384" />
</textMessageEncoding>
</unsecureResponseEncoding>
<!-- removed for briefity -->
</customBinding>
</bindings>
<client>
<!-- removed for briefity -->
</client>
<behaviors>
<!-- removed for briefity -->
</behaviors>
</system.serviceModel>
The main thing the UnsecureResponseEncoder does is override the ReadMessage methods of the message encoder. All else is just plumbing to wrap the original encoder and use it as is. In ReadMessage the received message is retrieved and place in a local variable. If a MessageSecurityException occurs, this is caught, and an UnecureResponseException is thrown, which includes the original message. Higher up in the call chain you can parse the original message and extract the fault information. The example below shows an altered proxy call so the proxy actually returns a FaultException<>. SomeResponseMessageContract ISomeService.SomeServiceMethod(SomeRequestMessageContract request)
{
try
{
return base.Channel.Aanleveren(request);
}
catch (UnsecureResponseException exception)
{
if (String.IsNullOrEmpty(exception.ResponseMessage) == false)
{
// Put original response message in XmlDocument so you can manipulate it
XmlDocument xml = new XmlDocument();
xml.LoadXml(exception.ResponseMessage);
// Add namespaces concerning faults, including your custom fault schema
XmlNamespaceManager nsmgr = new XmlNamespaceManager(xml.NameTable);
nsmgr.AddNamespace("soapenv", "http://schemas.xmlsoap.org/soap/envelope/");
nsmgr.AddNamespace("fault", "http://somefaultschema/");
// Retrieve the fault node and extract information.
XmlNode faultNode = xml.SelectSingleNode("/soapenv:Envelope/soapenv:Body/soapenv:Fault", nsmgr);
if(faultNode != null)
{
SomeFault fault = new SomeFault()
{
SomeFaultInfo = faultNode.GetNodeStringValue("detail/fault:SomeFault/fault:SomeFaultInfo", nsmgr),
};
if(String.IsNullOrEmpty(fault.SomeFaultInfo) == false)
{
throw new FaultException<SomeFault>(fault, exception.Message);
}
}
}
throw; // If not properly handled, rethrow original exception
}
}
I've been trying to find a way in which I can easily map competences, books, certifications etc. The goal here is to be able to determine what you need to do to reach a certain competence or certification. Now, there may be some fancy tool out there to do this, or you could just whip up Visio and start drawing, but a) I don't want to buy a new tool, and b) I want this to be interactive.
I just finished a demo that uses the Dependency Graph functionality in Visual Studio Ultimate. I've used similar tooling before (from NDepend) for auditing and reviewing, but this time around I'm using it as part of my solution rather than to review a solution. I've expressed compentencies and books in classes, and if a competence is required for another, I'm adding a reference to it in a prerequisites list. The same happens with books you could read to learn about the competence.
After letting Dependency Graphing do its thing, you end up with a graph such as the one below. The great thing is that it's interactive. You can delete/colapse in the diagram what you don't need, and you can select the items for which you want to see more detailed dependencies. In the graph below, I've selected several constructors to show me all the dependencies.
With everything in code, I could now create a user interface that enables you to query the map for what you still need to do to get to the competence/certification you want.
|