DevServer Wiki & Documentation Rss Feed

UPDATED WIKI: Home

quantum00 — Thu, 10 Apr 2008 13:04:32 GMT

Project Description
NetFXHarmonics DevServer is a web server hosting environment built on WPF and WCF technologies that allows multiple instances of Cassini-like web servers to run in parallel. DevServer also includes tracing capabilities for monitoring requests and responses, request filtering, automatic ViewState and ControlState parsing, visually enhanced HTTP status codes, IP binding modes for both local-only as well as remote access, and easy to use XML configuration.

NetFXHarmonics Blog

DevServer Announcement and Overview
http://www.netfxharmonics.com/2008/04/NetFXHarmonics-DevServer-Released

As a Training Tool

NetFXHarmonics DevServer is built on .NET 3.5 using WPF, WCF, and LINQ. DevServer could be used as a training tool to help teach WPF binding, WCF communication, LINQ collection transformation and querying, and .NET 2.0 custom configuration. See the "As a Training Tool" in the "DevServer Announcement and Overview" blog entry for more detailed information how using DevServer as a training tool.

Screenshot

UPDATED WIKI: Home

quantum00 — Sun, 06 Apr 2008 01:25:55 GMT

NetFXHarmonics Blog

DevServer Announcement and Overview
http://www.netfxharmonics.com/2008/04/NetFXHarmonics-DevServer-Released

As a Training Tool

NetFXHarmonics DevServer is built on .NET 3.5 using WPF, WCF, and LINQ. DevServer could be used as a training tool to help teach WPF binding, WCF communication, and LINQ collection transformation and querying. See the "As a Training Tool" in the "DevServer Announcement and Overview" blog entry for more detailed information how using DevServer as a training tool.

Screenshot

UPDATED WIKI: Home

quantum00 — Sun, 06 Apr 2008 01:25:22 GMT

NetFXHarmonics Blog

NEWS FEED

NetFXHarmonics DevServer Released

Saturday, April 05, 2008 | From NetFX Harmonics

Two months ago started work on a project to help me in my AJAX and SOA development. What I basically needed was a development web server that allowed me to start up multiple web servers at once, monitor server traffic, and bind to specific IP interfaces. Thus, the creation of NetFXHarmonics DevServer. I built it completely for myself, but others started to ask for it as well. When the demand for it became stronger, I realized that I needed to release the project on the web. Normally I would host it myself, but given the interest from the .NET community, I thought I would put it on CodePlex. I've only cried twice seen I've put it on CodePlex, but I'll survive.

NetFXHarmonics DevServer is a web server hosting environment built on WPF and WCF technologies that allows multiple instances of Cassini-like web servers to run in parallel. DevServer also includes tracing capabilities for monitoring requests and responses, request filtering, automatic ViewState and ControlState parsing, visually enhanced HTTP status codes, IP binding modes for both local-only as well as remote access, and easy to use XML configuration.

Using this development server, I am able to simultaneously start multiple web sites to very quickly view everything that happens over the wire and therefore easily debug JSON and SOAP messages flying back and forth between client and server and between services. This tool have been a tremendous help for me in the past few months to discover exactly why my services are tripping out without having to enable WCF tracing. It's also been a tremendous help in managing my own web development server instances for all my projects, each having 3-5 web sites (or segregated service endpoints) each.

Let me give you a quick run down of the various features in NetFXHarmonics DevServer with a little discussion of each feature's usage:

XML Configuration

NetFXHarmonics DevServer has various projects (and therefore assemblies) with the primary being DevServer.Client, the client application which houses the application's configuration.

In the app.config of DevServer.Client, you have a structure that looks something like the following:

<jampad.devServer>
</jampad.devServer>

This is where all your configuration lives and the various parts of this will be explained in their appropriate contexts in the discussions that follow.

Multiple Web Site Hosting

In side of the jampad.devServer configuration section in the app.config file, there is a branch called <servers /> which allows you to declare the various web servers you would like to load. This is all that's required to configure servers. Each server requires a friendly name, a port, a virtual path, and the physical path. Given this information, DevServer will know how to load your particular servers.

<servers>
    <server key="SampleWS1" name="Sample Website 1" port="2001"
            virtualPath="/" physicalPath="C:\Project\DevServer\SampleWebsite1">
    </server>
    <server key="SampleWS2" name="Sample Website 2" disabled="true" port="2003"
            virtualPath="/" physicalPath="C:\Project\DevServer\SampleWebsite2">
    </server>
</servers>

If you want to disable a specific server from loading, use the "disabled" attribute. All disabled servers will be completely skipped in the loading process. On the other hand, if you would like to load a single server, you can actually do this from the command line by setting a server key on the <server /> element and by accessing it via a command line argument:

DevServer.Client.exe -serverKey:SampleWS1

In most scenarios you will probably want to load various sets of servers at once. This is especially true in properly architected service-oriented solutions. Thus, DevServer includes a concept of startup profiles. Each profile will include links to a number of keyed servers. You configure these startup profiles in the <startupProfiles /> section.

<startupProfiles activeProfile="Sample">
    <profile name="Sample">
        <server key="SampleWS1" />
        <server key="SampleWS2" />
    </profile>
</startupProfiles>

This configuration block lives parallel to the <servers /> block and the inclusion of servers should be fairly self-explanatory. When DevServer starts it will load the profile in the "activeProfile" attribute. If the activeProfile block is missing, it will be ignored. If the activeProfile states a profile that does not exist, DevServer will not load. When using a startup profile, the "disabled" attribute on each server instance is ignored. That attribute is only for non-startup profile usage. An activeProfile may also be set via command line:

DevServer.Client.exe -activeProfile:Sample

This will override any setting in the activeProfile attribute of <startupProfiles/>. In fact, the "serverKey" command line argument overrides the activeProfile <startupProfiles /> attribute as well. Therefore, the order of priority is is as follows: command line argument override profile configuration and profile configuration overrides the "disabled" attribute.

Most developers don't work on one project and with only client. Or, even if they do, they surely have their own projects as well. Therefore, you may have even more servers in your configuration:

<server key="ABCCorpMainWS" name="Main Website" port="7001"
        virtualPath="/" physicalPath="C:\Project\ABCCorp\Website">
</server>
<server key="ABCCorpKBService" name="KB Service" port="7003"
        virtualPath="/" physicalPath="C:\Project\ABCCorp\KnowledgeBaseService">
</server>
<server key="ABCCorpProductService" name="Product Service" port="7005"
        virtualPath="/" physicalPath="C:\Project\ABCCorp\ProductService">
</server>

These would be grouped together in their own profile with the activeProfile set to that profile.

<startupProfiles activeProfile="ABCCorp">
    <profile name="ABCCorp">
        <server key="ABCCorpMainWS" />
        <server key="ABCCorpKBService" />
        <server key="ABCCorpProductService" />
    </profile>
    <profile name="Sample">
        <server key="SampleWS1" />
        <server key="SampleWS2" />
    </profile>
</startupProfiles>

What about loading servers from different profiles? Well, think about it... that's a different profile:

<startupProfiles activeProfile="ABCCorpWithSampleWS1">
    <profile name="ABCCorpWithSampleWS1">
        <server key="SampleWS1" />
        <server key="ABCCorpMainWS" />
        <server key="ABCCorpKBService" />
        <server key="ABCCorpProductService" />
    </profile>
</startupProfiles>

One of the original purposes of DevServer was to allow remote non-IIS access to development web sites. Therefore, in DevServer you can use the <binding /> configuration element to set either "loopback" (or "localhost") to only allow access to your machine, "any" to allow web access from all addresses, or you can specific a specific IP address to bind the web server to a single IP address so that only systems with access to that IP on that interface can access the web site.

In the following example the first web site is only accessible by the local machine and the second is accessible by others. This comes in handy for both testing in a virtual machine as well as quickly doing demos. If your evil project manager (forgive the redundancy) wants to see something, bring the web site up on all interface and he can poke around from his desk and then have all his complains and irrational demands ready when he comes to your desk (maybe you want to keep this feature secret).

<server key="SampleWS1" name="Sample Website 1" port="2001"
        virtualPath="/" physicalPath="C:\Project\DevServer\SampleWebsite1">
    <binding address="loopback" />
</server>
<server key="SampleWS2" name="Sample Website 2" port="2003"
        virtualPath="/" physicalPath="C:\Project\DevServer\SampleWebsite2">
    <binding address="any" />
</server>

Web Site Settings

In addition to server configuration, there is also a bit of general configuration that apply to all instances. As you can see from the following example, you can add default documents to the existing defaults and you can also setup content type mappings. A few content types already exist, but you can override as the example shows. In this example, where ".js" is normally sent as text/javascript, you can override it to go to "application/x-javascript" or to something else.

<webServer>
    <defaultDocuments>
        <add name="index.jsx" />
    </defaultDocuments>
    <contentTypeMappings>
        <add extension=".jsx" type="application/x-javascript" />
        <add extension=".js" type="application/x-javascript" override="true" />
    </contentTypeMappings>
</webServer>

Request/Response Tracing

One of the core features of DevServer is the ability to do tracing on the traffic in each server. Tracing is enabled by adding a <requestTracing /> configuration element to a server and setting the "enabled" attribute to true.

<server key="SampleWS1" name="Sample Website 1" port="2001"
        virtualPath="/" physicalPath="C:\Project\DevServer\SampleWebsite1">
    <binding address="loopback" />
    <requestTracing enabled="true" enableVerboseTypeTracing="false" enableFaviconTracing="true" />
</server>

This will have request/response messages show up in DevServer which will allow you to view status code, date/time, URL, POST data (if any), response data, request headers, response headers, as well as parsed ViewState and Control state for both the request and response. In addition, each entry is color coded based on it's status code. Different colors will show for 301/302, 500+, and 404.

When working with the web, you don't always want to see every little thing that happens all the time. Therefore, by default, you only trace common text specific file like HTML, CSS, JavaScript, JSON, XAML, Text, and SOAP and their content. If you want to trace images and other things going across, then set "enableVerboseTypeTracing" to true. However, since there is no need to see the big blob image data, the data of binary types are not sent to the trace viewer even with enableVerboseTypeTracing. You can also toggle both tracing as well as verbose type tracing on each server as each is running.

There's also the ability to view custom content types without seeing all the images and extra types. This is the purpose of the <allowedConntetTypes /> configuration block under <requestTracing />, which is parallel to <servers />.

<requestTracing>
    <allowedContentTypes>
        <add value="application/x-custom-type" />
    </allowedContentTypes>
</requestTracing>

In this case, responses of content-type "application/x-custom-type" are also traced without needing to turn on verbose type tracing.

However, there is another way to control this information. If you want to see all requests, but want the runtime ability to see various content types, then you can use a client-side filter in the request/response list. In the box immediately above the request/response list, you can type something like the following:

verb:POST;statuscode:200;file:css;contentType:text/css

Filtering will occur as you type, allowing you to find the particular request you are looking for. The filter is NOT case sensitive. You can also clear the request/response list with the clear button. There is also the ability to copy/paste the particular headers that you want from the headers list by using typical SHIFT (for range) and CTRL-clicking (for single choosing).

Request/Response monitoring actually goes a bit further by automatically parsing both ViewState and ControlState for both request (POST) and response data. Thanks goes to Fritz Onion for granting me permission to use his ViewState parser class in DevServer.

As a Training Tool

When announce any major project I always provide an "as a training tool" section to explain how the project can be used for personal training. NetFXHarmonics DevServer is built using .NET 3.5 and relies heavily on LINQ and WCF with a WPF interface. In terms of LINQ, you can find many examples of how to use both query expression syntax and extension method syntax. When people first learn LINQ, they think that LINQ is an O/R mapper. Well, it's not (and probably shouldn't be usef for that in enterprise applications! there is only one enterprise class O/R mapper: LLBLGen Pro). LINQ allows Language INtegrated Query in both C# and VB. So, in DevServer, you will see heavy reliable on LINQ to search List<> objects and transform LINQ database entities to WCF DTOs.

DevServer also relies heavily on WCF for all inner-process communication via named-pipes. The web servers are actually hosted inside of a WCF service, thus segregating the web server loader from the client application in a very SOA friendly manner. The client application loads the service and then acts as a client to the service calling on it to start, stop, and kill server instances. WCF is also used to communicate the HTTP requests inside the web server back to the client, which is itself a WCF service to which the HTTP request is a client. Therefore, DevServer is an example of how you can use WCF to communicate between AppDomains.

The entire interface in DevServer is a WPF application that relies heavy on WPF binding for all visual information. All status information is in a collection to which WPF binds. Not only that all, but all request/response information is also in a collection. WPF simply binds to the data. Using WPF, no eventhandling was required to say "on a click event, obtain SelectedIndex, pull data, then text these TextBox instances". In WPF, you simply have normal every day data and WPF controls bind directly to that data being automatically updated via special interfaces (i.e INotifyPropertyChanged and INotifyCollectionChanged) or the special generic ObservableCollection<T>.

Since the bindings are completely automated, there also needs to be ways to "transform" data. For example, in the TabItem header I have a little green or red icon showing the status of that particular web server instance. There was no need to handle this manually. There is already a property on my web server instance that has a status. All I need to do is bind the image to my status enumeration and set a TypeConverter which transforms the enumeration value to a specific icon. When the enumeration is set to Started, the icon is green, when it says "Stopped", the icon is red. No events are required and the only code required for this scenario is the quick creation of a TypeConverter.

Therefore, DevServer is an example of WPF databinding. I've heard people say that they are more into architecture and WCF and therefore have no interested in learning WPF. This statement makes no sense. If you don't want to mess with UI stuff, you need to learn WPF. Instead of handing events all over the place and manually setting data, you can do whatever it is you do and have WPF just bind to your data. When it comes to creating quick client applications, WPF is a much more productive platform than Windows Forms... or even the web!

Links

NetFXHarmonics DevServer on CodePlex (I hate CodePlex-- but I know that .NET people visit that more often than the far technically superior Subversion-based Google Code-- I have to kill devenv.exe every 5 or so "check-ins" and when I move my project root folder [which I do often] everything dies! CodePlex [TFS] is a nightmare!).

Squid - Data Feed Framework for .NET 3.5

Monday, March 17, 2008 | From NetFX Harmonics

A few years ago I designed a system that would greatly ease data syndication, data aggregation, and reporting. The first two components of the system were repackaged and release early last year under the incredibly horrible name "Data Feed Framework". The idea behind the system was two fold. The first concept was that you write a SQL statement and you immediately get a fully functional RSS feed with absolutely no more work required. Here's an example of a DFF SQL statement that creates an RSS feed of SQL Server jobs:

select Id=0,
Title=name,
Description=description
from msdb.dbo.sysjobs
where enabled = 1

The second part of DFF was it's ASP.NET control named InfoBlock that would accept an RSS or ATOM feed and display it in a mini-reader window. The two parts of DFF combine to create the following:

Given the following SQL statement (or more likely a stored procedure)...

select top 10
Id=pc.ContactID, 
Title=pc.FirstName + ' ' + pc.LastName + ': $' + convert(varchar(20), convert(numeric(10,2), sum(LineTotal))), 
Description='', 
LinkTemplate = '/ShowContactInformation/{id}'
from Sales.SalesOrderDetail sod
inner join Sales.SalesOrderHeader soh on soh.SalesOrderID = sod.SalesOrderID
inner join Person.Contact pc on pc.ContactID = soh.SalesPersonID
group by pc.FirstName, pc.LastName, pc.ContactID
order by sum(LineTotal) desc

...we have an automatically updating RSS feed and when that RSS feed is given to an InfoBlock, you get the following:

InfoBlocks could be placed all over a web site or intranet to give quick and easy access to continually updating information. The InfoBlock control would also register the feed with modern web browsers that had integrated RSS support. Furthermore, since it was styled properly in CSS, there's no reason for it to be a block at all. It could be a horizontal list, a DOM-based window, or even a ticker as CSS and modern AJAX techniques allow.

DFF relied on RSS.NET for syndication feed creation and both RSS.NET and Atom.NET for aggregation. It also used LLBLGen Pro a bit to access the data from SQL Server. As I've promised with all my projects, they will update as new technologies are publicly released. Therefore, DFF has been completely updated for .NET 3.5 technologies including LINQ and WCF.

I've also decided to continue down my slippery slope of a change in product naming philosophy. Whereas before I would follow the Microsoft marketing philosophy of "add more words to the title until it's so long to say that you require an acronym" to the more Linux or O'Reilly approaches of "choose a random weird sounding word and leave it be" and "pick a weird animal", respectively. I've also been moving more towards the idea of picking a cool name and leaving it as is. This is in contrast to Microsoft's idea of picking an awesome name and then changing it to an impossibly long name right before release (i.e. Sparkle, Acrylic, and Atlas) Therefore, I decided to rename DFF to Squid. I think this rivals my Dojr.NET and Prominax (to be released-- someday) projects as having the weirdest and most random name I've ever come up with. I think it may have something to do with SQL and uhhhh.. something about a GUID. Donno.

Squid follows the same everything as DFF, however the dependencies on RSS.NET and ATOM.NET were completely removed. This was possible due to the awesome syndication support in WCF 3.5. Also, all reliance on LLBLGen Pro was removed. LLBLGen Pro (see my training video here) is an awesome system and is the only enterprise-class O/R mapping solution in existence. NHibernate should not be considered enterprise-class and it's usability is almost through the floor. Free in terms of up-front costs, does not mean free in terms of usability (something Linux geeks don't seem to get). However, given that LINQ is built into .NET 3.5, I decided that all my shared and open-source projects should be using LINQ, not LLBLGen Pro. The new LLBLGen Pro uses LINQ and when it's released, should absolutely be used as the primary solution for enterprise-class O/R mapping.

Let me explain a bit about the new syndication feature in WCF 3.5 and how it's used in Squid. Creating a syndication feed in WCF is required a WCF endpoint just like everything else in WCF. This endpoint will be part of a service and will have an address, binding, and contract. Nothing fancy yet as the sweetness is in the details. Here's part of the contract Squid uses for it's feed service (don't be jealous of the VS2008 theme -- see Scott Hanselman's post on VS2008 themes):

namespace Squid.Service
{
    [ServiceContract(Namespace = "http://www.netfxharmonics.com/services/squid/2008/03/")]
    public interface ISquidService
    {
        [OperationContract]
        [WebGet(UriTemplate = "GetFeedByTitle/{title}")]
        Rss20FeedFormatter GetFeedByTitle(String title);

        //+ More code here
    }
}

Notice the WebGet attribute. This is applied to signify that this will be part of a HTTP GET request. This relates to the fact that we are using a new WCF 3.5 binding called the WebHttpBinding. This is the same binding used by JSON and POX services. There are actually a few new attributes, each of which provides it's own treasure chest (see later in this post when I mention a free chapter on the topic). The WebGet attribute has an awesome property on it called UriTemplate that allows you to match parameters in the request URI to parameters in the WCF operation contract. That's beyond cool.

The service implementation is extremely straight forward. All you have to do is create a SyndicationFeed object, populate it with SyndicationItem objects and return it in the constructor of the Rss20FeedFormatter. Here's a non-Squid example:

SyndicationFeed feed = new SyndicationFeed();
feed.Title = new TextSyndicationContent("My Title");
feed.Description = new TextSyndicationContent("My Desc");
List<SyndicationItem> items = new List<SyndicationItem>();
items.Add(new SyndicationItem()
{
    Title = new TextSyndicationContent("My Entry"),
    Summary = new TextSyndicationContent("My Summary"),
    PublishDate = new DateTimeOffset(DateTime.Now)
});
feed.Items = items;
return new Rss20FeedFormatter(feed);

You may want to make note that you can create an RSS or ATOM feed directly from an SyndicationFeed instance using the SaveAsRss20 and SaveAsAtom10 methods.

As with any WCF service, you need a place to host it and you need to configure it. To create a service, I simply throw down a FeedService.svc file with the following page directive (I'm really not trying to have the ugliest color scheme in the world-- it's just an added bonus):

<%@ ServiceHost Service="Squid.Service.SquidService" %>

The configuration is also fairly straight forward, all we have is our previously mentioned ending with an address(blank to use FeedService.svc directly), binding (WebHttpBinding), and contract(Squid.Service.ISquidService). However, you also need to remember to add the WebHttp behavior or else nothing will work for you.

<system.serviceModel>
    <behaviors>
        <endpointBehaviors>
            <behavior name="FeedEndpointBehavior">
                <webHttp/>
            </behavior>
        </endpointBehaviors>
    </behaviors>
    <services>
        <service name="Squid.Service.SquidService">
            <endpoint address=""
                      binding="webHttpBinding"
                      contract="Squid.Service.ISquidService"
                      behaviorConfiguration="FeedEndpointBehavior"/>
        </service>
    </services>
</system.serviceModel>

That's seriously all there is to it: write your contract, write your implementation, create a host, and set configuration. In other words, creating a syndication feed in WCF is no different than creating a WsHttpBinding or NetTcpBinding service. However, what about reading an RSS or ATOM feed? This is even simpler.

To read a feed all you have to do is create an XML reader with the data source of the feed and pass that off to the static Load method of the SyndicationFeed class. This will return an instance of SyndicationFeed which you may iterate or, as I'm doing in Squid, transform with LINQ. I actually liked how my server-control used an internal repeater instance and therefore wanted to continue to use it. So, I kept my ITemplate object (RssListTemplate) the same and used the following LINQ to transform a SyndicationFeed to what my ITemplate what already using:

Object bindingSource = from entry in feed.Items
                       select new SimpleFeedEntry
                       {
                           DateTime = entry.PublishDate.DateTime,
                           Link = entry.Links.First().Uri.AbsoluteUri,
                           Text = entry.Content != null ? entry.Content.ToString() : entry.Summary.Text,
                           Title = entry.Title.Text
                       };

Thus, with .NET 3.5 I was able to remove RSS.NET and ATOM.NET completely from the project. LINQ also, of course helped me with my database access and therefore remove my dependency on my LLBLGen Pro generated DAL:

using (SquidLINQDataContext db = new SquidLINQDataContext(Configuration.DatabaseConnectionString))
{
    var collection = from p in db.FeedCreations
                     where p.FeedCreationTitle == title
                     select p;

    //+ More code here
}

Thus, you can use Squid in your existing .NET 3.5 system with little impact to anything. Squid is what I use in my Minima blog engine to provide the boxes of information in the sidebar. I'm able to modify the data in the Snippet table in the Squid database to modify the content and order in my sidebar. Of course I can also easily bring in RSS/ATOM content from the web with this as well.

You can get more information on the new web support in WCF 3.5 by reading the chapter "Programmable Web" (free chapter) in the book Essential WCF for .NET 3.5 (click to buy). This is an amazing book that I highly recommend to all WCF users.

Links

March 2008 Web Technology Update

Wednesday, March 05, 2008 | From NetFX Harmonics

Recently a bunch of technologies have been released and/or updated and I would like to mention a few of them briefly.

First and foremost, Silverlight 2 Beta 1 has finally been released and you may download it immediately. There is also an accompanying SDK. You can find a nice development tutorial series on Scott Guthrie's blog. If you are already familiar with WPF, you can just skim this entire series in less than 5 minutes. Given that this technology isn't the same as the full WPF and given that it's designed for the web, there will obviously be differences. It's important to remember that Silverlight 2 isn't simply WPF for the web. I would call WPF 3.5's XBAP support for IE/Firefox "WPF for the web". No, this is possibly the biggest web technology improvement since the release of Firefox 1.0, which in turn was the biggest technology release since the printing press. Alight, alight... since .NET 1.1. It's support for the dynamic language runtime is going to completely revolutionize our web development.

When reading through Scott's tutorial series (serious, at least skim it), it's interesting to note that Silverlight 2 allows cross-domain communication. It does this by reusing the Flash communication policy files. This is really awesome as it means that you can start accessing resources that Flash has been using for a while. Being able to dynamically access resources from different domains is critical to the success of web architecture in the future.

Speaking of cross-domain communication, John Resig and I received a very depressing e-mail the other day telling us horrible news: cross-domain communication will probably be removed from Firefox 3 before it's official release. Apparently a bunch of paranoid anti-architects were complaining about the dreaded evils of being able to access resources from different domains. Um ok. Fortunately, however, Firefox 3 has a feature called postMessage that allows you to get around this. Malte Ubl has produced a library called xssinterface to demonstrate just this concept. You could, of course, get around this completely with some iframe hacks or some other scripting magic.

Speaking of web browsers, I would like to bring people's attention to a technology that I've been following for some time now: Apple WebKit. This is basically the brains inside Safari. I absolutely love the Safari web browser. It's by far and away the easiest web browser to use. It also has the same keyboard short-cuts as Firefox, which is how I'm able to use it. It's also incredibly fast, but I should mention that it uses even more memory than Firefox. My last instance passed 500MB. Given it's lack of an extension or configuration (i.e. about:config) system, it's obviously no where near the same caliber as Firefox though. It is, however, my primary web browser as has been since October '07.

The reason I mention WebKit is because as very few people know, this is an open source project and has nightly binaries released on their webkit.org web site. One of the most interesting thing about nightlies that you can actually watch the progress of development as time goes on. About every month or so I like to get the latest Firefox nightly. It's always interesting to see the major experiments that the developers try about 2 months after a major release of Firefox. There's always some really awesome "teaser" feature in there that later grows into a fully grown technology. The same can be said for WebKit.

None of that is, however, my primary reason for mentioning WebKit. As, most web developers know, the Acid2 test has been the standard for checking a web browsers compatibility with the CSS standard. I've been pushing this test for a long time, but I've never pushed it as the only test. There are many things that a web browser must do and many features a web browser must have before it can be considered appropriate for use. Merely focusing on CSS, while completely ignoring DOM support, JavaScript, and general user usability can lead a browser to be as impossible to use as Opera 9.

As I've said time and time again, I'm not a CSS specialist. Part of the definition of being a professional web develop is that I have a solid understand of the inner workings of CSS including specificity, the various selectors, and how to merge absolute, floating, and relative position on the same elements, tasks "coders" see as nearly impossible to learn. However, my focus is on AJAX interaction as seen from the JavaScript and DOM worlds. Therefore, we need to have a test for browsers that goes beyond the simple Acid 2 test for CSS. I'm not the only one thinking this way, because recently the Acid3 test was published and it tests CSS, JavaScript and DOM support. This is the new standard for web browsers.

So far no web browser has even gotten close, with the lowest score from a web browser being 39% in Safari to the best score being 50% in Firefox 2.0.0.12. However, in terms of non-released software, Firefox 3.0b3 has a score between 59% and 61%, depending on its mood (update: b4 is steady at 67%) and the latest WebKit nighty has a score is 90% (watch WebKit progress on Acid 3 at http://bugs.webkit.org/show_bug.cgi?id=17064). That's phenomenal! The newly released Internet Explorer 8 beta 1 has a score of 17%. Those of you who have naively praising the IE team for being YEARS late on getting near the Acid 2 test need to wake up and realize this is 2008. Time moves-- keep up. Firefox has been close for the longest time and has always had the next-gen's next-gen JavaScript and DOM support, but has only recently completely passed the finish line of the Acid 2 test. So, they are finally off my watch list there, but I will not stop bugging them until they pass the Acid 3 test.

For more information on the Acid 3 test, see John Resig's most entitled "Acid 3 tackes EMCAScript". He's about as passionate as I am for web standards and Firefox and his blog is an invaluable resource for all things JavaScript. His work is so good that I would like to take the time to plug his book he is currently writing: Secrets of the JavaScript Ninja. I absolutely guarantee you that this book will redefine the entire world of JavaScript and will raise the bar incredibly out of the reach of "coders". To all of you coders who think you know JavaScript, do a view-source on the Acid 3 source code (you may want to bring a change of underwear with you).

Lastly, it's not necessarily a "new" technology, but it's so incredibly phenomenal that I need to mention it: Prototype 1.6. It's amazing to me that people actually go out of their way to use ASP.NET AJAX 3.5 (I still find the ICallbackEventHandler interface more productive). ASP.NET AJAX 3.5 is not nearly as bad as extremists think, but the design is still flawed. Prototype on the other hand is absolutely incredible. I've written about Prototype before, but this version 1.6 is even more powerful. There a A LOT of changes from Prototype 1.5. It's so good that I no longer call it "prototype/script.aculo.us". Script.aculo.us is a great animation system, but, honestly, the main reason I used it was for the DOM abstraction in the Builder object. Prototype now has an Element object to help create DOM objects, thus allowing me to remove Script.aculo.us from most of my projects (it's not as complete as the Builder object, but it allows object chaining-- which greatly increases code readability, conciseness and understanding!). The Template object is also amazing as it gives you the ability to go far beyond simple String.Format formatting. The new Class object for OOP is also great. It's so much easier to use than Prototype 1.5. Also, being able to hide all elements with a particular CSS pattern with one shot is very useful! (for example, $$('div span .cell-block').invoke('hide')). It even allows you to use CSS 3 selectors on the most dead of web browsers. It really makes developing for Internet Explorer 6 and 7 bearable! Even if I have to use ASP.NET AJAX 3.5, I'll still including prototype.js. If you do anything with JavaScript, you need Prototype!

Links

Comic Strip #2: .NET and PHP Source Code

Sunday, February 10, 2008 | From NetFX Harmonics

Here's another conversations that I've had with various PHP programmers over the years. Actually, this strip is a combination of three separate conversations wrapped up into one. I think these conversations also give an accurate image of how the ignorant anti-Microsoft cult thinks. Most of the time these people don't even know their own systems and often assume that since I'm a .NET programmer that I'm a complete fool.

Comic Strip: Enterprise .NET/PHP

Saturday, February 02, 2008 | From NetFX Harmonics

Recently I ran across a really awesome web site called ToonDoo. The web site basically allows you to create your own comic strips using a simple, yet feature rich Flash application. Today I learned about a few other web sites that do something similar. In light of the nonsensical anti-.NET drivel I hear constantly from ignorant outsiders, I thought I would put a few of my encounters into a few strips. Here is the first...

Cwalina's Framework Engineering Lecture Posted

Thursday, January 24, 2008 | From NetFX Harmonics

In my mind the single most important aspect of any system is usability. Unless the context states otherwise, when I use the term "optimize" or "efficiency" I am always always talking about usability optimization and efficiency. Things can be fast with a small footprint, but if you can't figure out how to use it right away or continually confuses your methods for your fields, then it doesn't really matter. Fortunately, Microsoft agrees with this. The days of every company writing their own coding-guidelines are gone and we .NET developers been unified under the great Framework Design Guidelines ("FDG") that Krzysztof Cwalina and Brad Abrams have so graciously given us.

To help further the unity in the community, Krzysztof recently posted a lecture on his blog entitled "Framework Engineering: Architecting, Designing, and Developing Reusable Libraries". Here is the abstract of the lecture:

This session covers the main aspects of reusable library design: API design, architecture, and general framework engineering processes. Well-designed APIs are critical to the success of reusable libraries, but there are other aspects of framework development that are equally important, yet not widely covered in literature. Organizations creating reusable libraries often struggle with the process of managing dependencies, compatibility, and other design processes so critical to the success of modern frameworks. Come to this session and learn about how Microsoft creates its frameworks. The session is based on experiences from the development of the .NET Framework and Silverlight, and will cover processes Microsoft uses in the development of managed frameworks.

This video is, of course, not the only video on such an incredibly critical topic. Many years ago, Brad Abrams (and friends) gave a lecture series to Microsoft employees on the topic of framework design guidelines. These videos don't just cover the critically important topic of name guidelines, but also CLR performance topics, interopability guidelines, security topics, as well as various others. It's a video series that's essential to serious .NET development.

More importantly then these videos though, is the classic work produced by Krzysztof and Brad entitled "Microsoft Framework Design Guidelines". At the time of this writing, this book has 28 Amazon.com customer reviews and is still at five stars. Look at a few of the review titles: "A must have for any C# Developer or Architect", "For the individual who wants to rise above the masses", "If you only ever buy one .NET book, make it this one", "AWESOME * 10 = MUST HAVE;" and my personal favorite: "Passionate About Quality?" These reviews give you a good idea of the level of community acceptance that the framework design guidelines have. One reviewer even said "I would pay $5 per page for this book, and have found it to be, by far, the most outstandingly useful technical book I've read." This book covers in detail many of the aspects (and often times more) that have been covered in the videos. In fact, the videos are actually on the DVD that comes with the book.

The book is also not simply a set of laws. Throughout the book Microsoft architects and major Microsoft community leaders like Jeffery Richter make comments on various aspects of the framework. Sometimes they explain why a rule is stated in a certain way and other times they emphasis how crucially important a rule is. A few of the comments in the book explain problems in the .NET framework stemming from the fact that the guidelines were still in development (people used to say C# looked like Java-- well, many people used Java's nearly obfuscated coding standard!) At one point in the book one of the authors explains a usability study for .NET streamed and right-out admitted what most of us already know: .NET streaming is extremely non-intuitive!

Many times I hear people say that the success of the .NET framework comes from it's extremely efficient garage collection model, it's flexible common language runtime (in contrast to Java's platform runtime) and it's powerful JIT model. All those things are crucial, but ease of use is even more at the heart of .NET. Abstraction in framework design can be defined as the increasing of the semantic value or usability of any entity and it's at this point where we can see .NET far outshine Java and PHP. I've all but forgotten how to work with pointers, but it's when I forgot my coding standard that I'll start to become obsolete. It's been said that the success of Windows was driven by the very open nature of the Win16/Win32 API. Similarly, I highly suspect that it's the the beautiful abstraction with extremely high usability that explains .NET's sheer success. There's only so much marketing can do; at some point a product has to stand on it's own (even then, Programmers can see though marketing!). This beautiful abstraction and extremely high usability if course due to the existence and enforcement of the FDG.

To be clear, when I talk about FDG, I'm not simply talking about FXCop rules. I typically break the .NET framework rules down into three levels: CLS-compliance, FXCop compliance, FDG compliance, and the iDesign standard. If you do not strictly enforce CLS-compliance, then you may very well be completely stuck in the next version of .NET. Who knows how non-Microsoft compilers will become. FXCop will catch problems in your CLS-compliance and it will also catch many of the FDG violations as well. The FDG rules, however, also cover various aspects of security and performance that only a human can check. Lastly, when people often mention the FDG, many times what they really mean is the iDesign standard, edited by Microsoft Software Legend Juval Lowy.

In fact, I often use the terms "Framework Design Guidelines" and iDesign standard interchangeably. They aren't the same thing, but in some contexts it's acceptable to mix them. Whereas the FDG is primarily for the public interface of a framework, the iDesign standard covers both the public and internal. The term "iDesign standard" may not be familiar to all, but what represents is. It's been the .NET coding defacto standard since 2003. In fact, when you crack open any APress, Wrox, or Sam Publishing book, you will probably be looking at code following the iDesign standard. Further, the default settings for Visual Studio is the iDesign code layout.

Every .NET developer knows it and just about everyone follows it. Some may think the iDesign standard is optional and since it covers private code and in a sense it is optional, but, to be sure, if you are following the FDG rules and the iDesign standard, you have immediately chopped the learning curve of your system by an enormous factor. Also, if you ever go public with your application (i.e. go open source), you will need to make sure you follow the FDG standard (which includes CLS and FXCop compliance) and the iDesign standard. Otherwise, your system will probably have virtually no acceptance.

In closing, I should mention that Krzysztof Cwalina and Brad Abrams are releasing the 2nd edition of their famous book, due September 29, 2008. You can, of course, pre-order on Amazon. You can be sure that I will!

Links

Dojr.NET (Dojo RPC Library .NET 2.0)

Saturday, January 19, 2008 | From NetFX Harmonics

In my overview of Dojo, I mentioned that Dojo provides a nice service abstraction layer in the form of dojo.rpc. This is an absolutely astounding feature, yet it's so simple. Instead of making all kinds of functions and setting up and XHR object, Dojo allows you to call server methods using a very simplified syntax. The model should be familiar to anyone who has worked with SOAP services. In these types of services, you are given a scheme and, depending on what client you are using, you can create a client-side proxy for all interaction with the service. This is how the dojo.rpc feature works. When you want to access a service, give Dojo the appropriate service metadata it needs to create a proxy and just call your service functions on the proxy.

Using dojo.rpc

In Dojo, this schema is called a Simple Method Description (SMD) and looks something like this.

var d = {
  'methods':
    [
      {
        'name':'getServerTime',
        'parameters':[
          {'name':'format'}
        ]
      },
      {
        'name':'getServerTimeStamp',
        'parameters' :[
        ]
      }
    ],
    'serviceType':'JSON-RPC',
    'serviceURL':'/json/time/'
}

With this SMD data, you create a proxy by getting and instance of the dojo.rpc.JsonService object setting the SMD in the constructor, like this:

var timeProxy = new dojo.rpc.JsonService(d);

From here you can call methods on the proxy and set a callback:

timeProxy.getServerTimeStamp( ).addCallback(function(r) { alert(r); });

Upon execution, this line will call the getServerTimeStamp method described in the SMD and route the output through the anonymous function set in the addCallback function. If you would like, however, you can defer the callback by calling the service now and explicitly releasing the callback later. In the following example, the first line calls the server immediately and the second releases the callback.

var deferred = timeProxy.getServerTimeStamp( );

deferred.addCallback(function(r) { alert(r); });

This is great, but what about the server? As it turns out, Dojo, sends JSON to the service. You can see this for yourself by taking at keep at the Request.InputStream stream in ASP.NET:

StreamReader reader = new StreamReader(Request.InputStream);
String data = reader.ReadToEnd( );

Below is the data that was in the stream. As you can see, this is extremely simple.

{\"params\": [], \"method\": \"getServerTimeStamp\", \"id\": 1}

Providing Server Functionality

Since we are working in .NET, we have at our disposal many mechanisms that can help us deal with various formats, some of which that can really help simplify life. As I explained in my XmlHttp Service Interop Series, providing communication between two different platforms isn't at all difficult, provided that you understand the wire format in between them. In part 3 of that same series, I explained how you could use XML serialization to quickly and powerfully interop with any XML service, including semi-standard a SOAP service. Furthermore, you aren't limited to XML. Provided the right serializer, you can do the same with any wire format. For our purposes here, we need a JSON serializer. One of my favorites is the Json.NET framework. However, to keep things simple and to help us focus more on the task at hand, I'm going to use the .NET 3.5 DataContractJsonSerializer object. If you are working in a .NET 2.0 environment with a tyrannical boss who despises productivity, you should check out Json.NET (or get a new job).

To begin our interop, the first thing we need is a type that will represent this JSON message in the .NET world. Based on what we saw in the ASP.NET Input Stream, this should be easy enough to build:

[DataContract]
public class DojoMessage
{
    [DataMember(Name = "params")]
    public String[] Params;

    [DataMember(Name = "method")]
    public String Method;

    [DataMember(Name = "id")]
    public Int32 Id = 0;
}

Having that class in place, we can now deserialize ASP.NET's InputStream into an instance of this class using out DataContractJsonSerializer:

DataContractJsonSerializer s = new DataContractJsonSerializer(typeof(DojoMessage));
DojoMessage o = (DojoMessage)s.ReadObject(stream);

That's it. Now you have a strongly typed object where you can access the method and parameter information as you need. From here's it shouldn't be too hard for anyone to use this information to figure out what to do on the server. After all the logic is in place, the only thing we have left to do is to return the data, which isn't really that big deal at all. The return data is basically plain text, but you can definitely send JSON back if you like. If you would like to use JSON, you can even the DataContractJsonSerializer to serialize an object to the ASP.NET Request.OutputStream object:

Object r = GetSomething(o);
s.WriteObject(context.Response.OutputStream, r);

What about a more high-level approach that will allow me to simply write my core functionality without messing with mechanics? Anyone using ASP.NET AJAX has this already in both their ASMX and WCF/JSON abstraction, but I wanted this functionality for Dojo (and for direct AJAX access). My requirements were that I wanted to be able to define an attributed service, register it and move on. Therefore, I build a Dojo RPC .NET 2.0 library called Dojr.NET (short for Dojo RPC, of course). Dojr is probably the worst project name I've come up with to date, but it saves me from potential legal stuff from the Dojo Foundation.

Using Dojr.NET

To use Dojr.NET, create a class that inherits from DojoRpcServiceBase and apply attribute DojoOperationAttribute on each publicly exposed method. Be sure to also set the dojo.rpc operation name in it's constructor, this is the name the Dojo client will see. Since .NET uses PascalCased methods and JavaScript uses camelCased function, this is required. Here is a complete sample class:

namespace NetFX.Web
{
    public class CalculatorService : DojoRpcServiceBase
    {
        [DojoOperation("add")]
        public Int32 Add(Int32 n1, Int32 n2) {
            return n1 + n2;
        }

        [DojoOperation("subtract")]
        public Int32 Subtract(Int32 n1, Int32 n2) {
            return n1 - n2;
        }
    }
}

After this, all you have to do is register the class as an HttpHandler in your web.config file.

<add verb="*" path="*/json/time/*" type="NetFX.Web.TimeService" />

At this point our Dojr.NET service is up and running, but how do we call it? Actually, the same way you always do with dojo.rpc; nothing changes. Believe it or not, this is a complete functional example:

var calcProxy = newdojo.rpc.JsonService('json/calc/?smd');
calcProxy.add(2, 3).addCallback(function(r) { alert(r); });

Automatic Service Method Description

But, how did the proxy obtain the required dojo.rpc metadata? If you look closely at the address given to the proxy you will notice that it's suffixed with ?smd. When a Dojr.NET service is suffixed with ?smd, it will automatically generate and return the service metadata. This is similar to putting ?wsdl at the end of an ASMX URI.

Take a look at the metadata that's being automatically generated on the server via the ?smd suffix:

{
  "methods":[
    {
      "name":"add",
      "parameters":[
        {"name":"n1"},
        {"name":"n2"}
      ]
    },
    {
      "name":"subtract",
      "parameters":[
        {"name":"n1"},
        {"name":"n2"}
      ]
    }
  ],
  "serviceType":"JSON-RPC",
  "serviceURL":"http://localhost:3135/Dojo/json/calc/"
}

As you can see, Dojr.NET provides all the metadata required. Literally all you have to do is inherit from DojoRpcServiceBase, apply the DojoOperationAttribute, and register the class to ASP.NET. Everything else will be done for you.

Links

NEWS FEED

DevServer Announcement and Overview
http://www.netfxharmonics.com/2008/04/NetFXHarmonics-DevServer-Released

As a Training Tool

Screenshot

UPDATED WIKI: Home

quantum00 — Sun, 06 Apr 2008 01:24:36 GMT

NetFXHarmonics Blog

DevServer Announcement and Overview
http://www.netfxharmonics.com/2008/04/NetFXHarmonics-DevServer-Released

UPDATED WIKI: Home

quantum00 — Sun, 06 Apr 2008 01:08:24 GMT

NetFXHarmonics Blog

DevServer Announcement and Overview
http://www.netfxharmonics.com/2008/04/NetFXHarmonics-DevServer-Released

UPDATED WIKI: Home

quantum00 — Mon, 24 Mar 2008 23:14:21 GMT

Project Description
NetFXHarmonics DevServer is a web server hosting environment built on WPF and WCF technologies that allows multiple instances of Cassini-like web servers to run in parallel. DevServer also includes tracing capabilities for monitoring both requests and responses, automatic ViewState and ControlState parsing, visually enhanced HTTP status codes, IP binding modes for both local-only as well as remote access, and easy to use XML configuration.