Month: March 2004

Dare and Rory and others have been conversing on a subject very close to my heart (and my work) — mapping XML code to objects.

In his post, Dare demonstrates how having dynamically typed properties would make it easier (and more elegant) for developers to write code vs. doing the same thing in a statically typed language. He then laments that there is no system today that would combine both strongly and dynamically typed features.

Although JavaScript is not a strongly typed language, it is a dynamically typed one. I thought it might be interesting for y’alls to continue exploring the building of a type dynamically. I make a weak attempt of strengthening the type system, but it is not something that should mislead you to think that JS type system is suddenly “cured“.

Consider the following code fragment (complete code and results of its execution can be seen here):

var entry = new entryType("Happy New Year!", "1/1/2004");
entry.subject = new typedXmlElement("Happy New Year, Yay!", "xs:string", "dc");
entry.requireModeration = true;
entry.subject.longDesc = new typedXmlElement("Common holiday with gifts and stuff", "xs:string", "myns");
entry.subject.longDesc.modifiedOn = new Date();
// write complete XML of this entry
var xml = entry.serialize();

In my humble opinion, the beauty of dynamic types is that it elevates a type instance to the level of a type and brings the sense of evolution to type. One can see it as bringing more “realism“ to the OOP: I am an instance of a Person, but, though sharing the same traits, a generic Person and I are different — I am a semantic singleton, a one-of-a-kind type-and-instance-in-one. As I evolve, I gain (or lose) new methods and properties, yet remain the same instance that I was born.

I may be wrong (or under-educated), but it seem that SOA, the “next big thing“ looming on the horizon, would benefit from  dynamically and strongly typed language of some kind.

Sittin’ in the hotel room, looking through the freshly acquired DevDays materials… Although the folks who organized it managed to put together a good collection of information and links to more information, I can’t shake off a feeling that I’ve watched a trailer rather than a full-length feature. It seems that the speakers, having only an hour to talk, sped up past the meat of the topic and just ran through the basics. I guess I was really expecting more from the threat modeling talk, but I understand how it can’t be covered within one hour.

On a positive note, I did have a good conversation with Jeff Prosise about the process of book writing. Also met Doug Turnure, who also recently started his blog and seems to be having the same “non-commental” issues. I can’t offer any good advice, except, to paraphrase Don Park’s post:

 “Keep feeding your Tamagotchi“.

Although concurrency management is somewhat represented in C# with the lock statement, there’s plenty more to be found in System.Threading namespace. Starting from Monitor class, which is what the lock statement is based on, to the ReaderWriterLock and the Mutex class. There’s even an Interlocked class, which provides very nice facilities for atomic operations.

In debugging deadlocks, I found myself using the Monitor.TryEnter method in order to determine the actual place of a deadlock. It basically operates as your standard Enter, except after a specified time span, it times out and returns false as the return value. Otherwise, when the thread is acquired, it returns true.

Inspired by a neat hack by Peter Golde, I created a simple wrapper — the ImpatientLock — for the TryEnter method, which allows adding the deadlock debugging statement with minimal modification to the existing code:

// lock(obj)
using(ImpatientLock.Try(obj))
{
   // .. do stuff
}

Except in the case of ImpatientLock, the exception is thrown, documenting the stack trace and thus pointing out location of the deadlock. Here’s the complete source code for the ImpatientLock, just in case you find it useful.

using System.Threading;

public class ImpatientLock
{
  public static IDisposable Try(object obj)
  {
    return new DisposableLock(obj, DisposableLock.DefaultTimeSpan);
  }

  public static IDisposable Try(object obj, TimeSpan timeSpan)
  {
    return new DisposableLock(obj, timeSpan);
  }

  private class DisposableLock : IDisposable
  {
    private static readonly TimeSpan DefaultTimeSpan = TimeSpan.FromMinutes(5);
    private readonly object Obj;
    public DisposableLock(object obj, TimeSpan timeSpan)
    {
      Obj = obj;
      if (!Monitor.TryEnter(obj, timeSpan))
      { 
          throw new ImpatientLockException();
      }
    }

    public void Dispose()
    {
      Monitor.Exit(Obj);
    }
  }

  private class ImpatientLockException : Exception
  {
    public ImpatientLockException()
      :base("Your time's up. I am quittin'!")
    {
    }
  }
}

In case you are battling deadlock issues, there are a couple of really good articles on the subject — most notably this one by Dr. GUI, and this one by unknown (to me) MS folks. There are also some pretty intriguing applications that attempt detection of potential deadlocks by analyzing the call tree of your code, although I found those too simplistic to detect anything realistically serious.

UPDATE: Ian Griffith has more information about this technique over at his blog, enhanced and updated with the help of Eric Gunnerson.

I’ve done some reading (and posting) on the excellent ASP.NET forum and, by far it seems, the most frequent cause of the issues that people have with their code is making the distinction between server side and client side of a Web application. I am not exactly sure why. Maybe the problem stems from the fact that most of today’s Web development platforms allow (and encourage) using the “tossed salad” declaration of server side and client side: your server-side code is mixed together with your client-side code.

ASP, ASP.NET, ColdFusion, JSP, PHP, and other scripting language platforms all attempt to marry DHTML and server-side logic in a single file. I am not saying that they are doing it wrong — there are far too many more of them than just me. But looking at posts full of confusion and hacking burn-out makes me wonder if the cow of architecture and strategic thinking was sacrificed to the gods of convenience.

It stands to reason whether it would be better to engineer your development platform in a way that would encourage architectural thinking rather than aid the hapless member of a cargo cult in quickly hacking something together. Something that inevitably becomes a piece of “regrettable software” — software that is painful to build, painful to use, and painful to maintain.

In the meantime, there’s definitely a market for a “know thy (sever|client) side” training. Speaking of which, trying to learn by coding in one of the “tossed salad” platforms may lead to a Gordian Knot of concepts in the students’ head. So, if you are trying to learn Web development platform from scratch, be that ASP.NET or ColdFusion MX, make sure to keep the layers separate:

• Start from HTML
• Grok CSS
• Learn JavaScript
• Move on to the server side language

Just not all at once.