Udooz!

Interstingly, when typing the term "microformats", my hand confuses my brain to type "Microsoft". :) However, it took some period to adopt this standard by major web vendors Microsoft and Mozilla.

What is Microformats?
This is one way of enabling web as semantic. The current web markups are very keen on displaying content on the browsers. As an user we know what is on the page, as a system it just displays it. However, how can develop a system to organize, collect and manage the contents from web pages? Previously, it is impossible. There are millions of terra bytes of content exist in the web. But now, Semantic Web which was initiated by Tim Berner Lee helps us to make this possible.

Microformats are one such standard which reuse existing markup elements to convey semantic of the data. For example, the following snippet shows a hCard telephone contact details.

<span class="tel">
<span class="type">home</span>:
<span class="value">+91.044.111090190</span>
</span>

Oomph

Microsoft Oomph is a toolkit to for web developers, designers and users, making it easier to create, consume, and style Microformats. It comes up with:

• IE add-in to parse Microformats in web pages.
• Pre-defined CSS styles for Microformats.
• A cross-browser HTML overlay for Microformats aggregation.

Visit: http://oomph.codeplex.com/ to know more and download the toolkit.

In 2004, I had bought "Software Factory" book written by Microsoft techies and it was more conceptual and theoretical. This book approaches the model driven development (MDD) in a different perspective, and introduces software factory and domain specific language (DSL) concepts. The theory was successfully implemented in VSTS. Unfortunately, it was not mature and very inconsistent. The software factory and DSL tools were only used by Microsoft itself. They did not touch the heart of ISVs. Event though, I have used Microsoft's Webclient Software Factory (WCSF) and WCF Service Model Factory successfully and bit consistently in one of our product development. I had really seen the benefit of MDD approach from DSL perspective upfront. However, I am expecting the mature and stable version of this.

Thanks God, Microsoft concentrates more on this and came up with "Oslo". The hot core part of Oslo is Oslo Modeling Language "M". The definition for M in MSDN:

M lets users write down how they want to structure and query their data using a convenient textual syntax that is convenient to both author and read.

With Oslo, Microsoft boosts the software factory concept. You can design and develop your application with UML 2.0 standard using M. M is a textual and declarative language which enables you to write down what you want from your data without worrying about underlying technology and platform. M will compile both on Win and Linux.

In parallel, Microsoft is developing Quadrant, a model designer for M which allows you to design graphically.

You can save your models in SQL Server.

Hope, we can see a smart changes in our SDLC by Oslo.

Sans Institute, the largest information security firm in association with software and security giants including Microsoft, Symantec, McAfee, published a hot 25 programming errors under three categories:

• Insecure interaction between components (9)
  
• Risky resource management (9)
  
• Porous defenses (7)
  

Insecure interaction between components

1. CWE-20: Improper Input Validation
2. CWE-116: Improper Encoding or Escaping of Output
3. CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
4. CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
5. CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
6. CWE-319: Cleartext Transmission of Sensitive Information
7. CWE-352: Cross-Site Request Forgery (CSRF)
8. CWE-362: Race Condition
9. CWE-209: Error Message Information Leak

Risky resource management

1. CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
2. CWE-642: External Control of Critical State Data
3. CWE-73: External Control of File Name or Path
4. CWE-426: Untrusted Search Path
5. CWE-94: Failure to Control Generation of Code (aka 'Code Injection')
6. CWE-494: Download of Code Without Integrity Check
7. CWE-404: Improper Resource Shutdown or Release
8. CWE-665: Improper Initialization
9. CWE-682: Incorrect Calculation

Porous defenses

1. CWE-285: Improper Access Control (Authorization)
2. CWE-259: Hard-Coded Password
3. CWE-732: Insecure Permission Assignment for Critical Resource
4. CWE-330: Use of Insufficiently Random Values
5. CWE-250: Execution with Unnecessary Privileges
6. CWE-602: Client-Side Enforcement of Server-Side Security

Our responsibility is to literate these top 25 errors to your colleagues, friends and follow these guidelines during your product development.

More details about the list, visit here.

Design by contract is a popular approach to designing software. This approach prescribes the software designers should define formal verifications, specification of every components in an application. These verifications and specifications should answer the following questions:

1. What does it expect?
2. What does it guarantee?
3. What does it maintain?

These can be achieved by contracts or assertion which can consumed at method level. These contracts normally contains:

• Acceptable inputs for an operation (method/procedure)
• Pre and Post-conditions
  
• Return value
  
• Exceptions
• Side effects
• Invariants (for sub-classes may strengthen)

To use this approach in .NET, Microsoft Research Lab released "Code Contracts" for .NET.

There are three components available in this release. These are:

• Contract Framework APIs
• Binary Rewriter
• Static Checker

The first two are for runtime checking.

Contract Framework APIs
Contract.Requires() - Pre condition
Contract.Ensures() - Post condition (additional helper methods: Contract.OldValue(), Contract.Result())
Contract.Invariant() - Invariants
ContractInvariantMethodAttribute - Method level attribute, so that we can put all invariant objects into a method.

Binary Rewriter
Normal IL code for the above mentioned APIs cannot be executed at runtime. To provide runtime checking for contracts, you have to use binary rewriter which takes the IL and transforms the contracts so that contracts are executed at the exact programming points.

Get a copy of CodeContract here and user manual here.

Visit Functional Programming with C# 3.0_Part 2.wmv to play the screen cast.

Visit Functional Programming with C# 3.0_Part 1.wmv to play the screen cast.

Inside AppManifest.xaml
The file contains the following:

<Deployment xmlns="

http://schemas.microsoft.com/client/2007/deployment"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

EntryPointAssembly="HelloSilverlightApp"

EntryPointType="HelloSilverlightApp.App"

RuntimeVersion="2.0.31005.0">

  <Deployment.Parts>

    <AssemblyPart x:Name="HelloSilverlightApp"

Source="HelloSilverlightApp.dll" />

  </Deployment.Parts>

</Deployment>

The manifest specifies the entry point assembly which should be loaded by the Silverlight host and within the assembly it requires a type derived from System.Windows.Application for start executing the application.

Here, the assembly is “HelloSilverlightApp.dll” and type is “App” in the namespace HelloSilverlightApp.

Warning: System.Windows.dll is part of Silverlight and not the one we used for WinForm development.

I read in some web sites those explained that XAP also contains a set of required Silverlight assemblies which are needed by this application. But I tried with lot of examples, the XAP contains application's assembly and this manifest. Need to check.

Inside HelloSilverlightApp.dll Assembly

It contains two parts:

1. The typical .NET type declaration of specific Siverlight application's App and one or more Page. In this example,

   1. HelloSilverlightApp.App

   2. HelloSilverlightApp.Page

2. Resource: HelloSilverlightApp.g.resources. It contains the declarative artifacts of this application:

   1. page.xaml

   2. app.xaml

I would like to share some of my basic understanding of Silverlight internals in this series.

XAP File

When you build a Silverlight 2.0 application, the final outcome would be:

1. ApplicationName.dll
2. AppManifest.xaml
3. ApplicationName.xap

When a request is made for a page which contains a Silverlight, the server sends the page with the Silverlight part as "xap" file to the client. The XAP is a normal archive file you use archive manager like 7-Zip to extract the content. It contains RequestSilverlightApp.dll and AppManifest.xaml. The silverlight CLR at the client side consumes these. This should be specified in either ASPX or HTML file which is the actual client requested page.

You use OBJECT tag along with DIV and IFRAME to load Silverlight host and specify the target XAP needs to be loaded.

<object data="data:application/x-silverlight,"

type="application/x-silverlight-2" width="100%" height="100%">



<param name="source" value="HelloSilverApp.xap"/>

In your ASPX, you can use ASP.NET server side control to specify Silverlight host and specify the target XAP. In the above declaration, the XAP file has been specified in the "source" parameter.

<asp:Silverlight ID="Xaml1" runat="server"

Source="~/ClientBin/HelloSilverApp.xap" MinimumVersion="2.0.31005.0"

Width="100%" Height="100%" />

In the above declaratin, the XAP file has been specified in the "Source" attribute.