2005 2006 2007 2008 2009 2010 2011 2015 2016 aspnet azure csharp debugging exceptions firefox javascriptajax linux llblgen powershell projects python security services silverlight training videos wcf wpf xag xhtmlcss

March 2008 Web Technology Update

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

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.

.NET and PHP Source Code Comic Strip

Comic Strip: Enterprise .NET/PHP

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

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)

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

Powered by
Python / Django / Elasticsearch / Azure / Nginx / CentOS 7

Mini-icons are part of the Silk Icons set of icons at famfamfam.com