www.AspNetResources.com

New Approach to Usability: Annoy Users

When I saw this article, Microsoft Exec: UAC Designed To ’Annoy Users’, (via Bryant Likes), I thought, “Nah, one of those April Fool’s jokes.” Then I looked at the date—April 10—and realized it wasn’t a joke. In fact, David Cross is quoted saying:

“The reason we put UAC into the platform was to annoy users. I’m serious.”

I was floored. First you create buggy operating systems for years and years, they expose people to all kinds of threats, and now you “fix” it by… annoying them?

Hey, Vista team, great job! I can express my annoyance with your product only in expletives.

Communal Decision Making Sucks

Here’s something revolting I’ve experienced dealing with recently: board of directors. What comes to mind immediately is this excerpt from The Fountainhead:

“Have you ever known a board to do anything? […] A board of directors is one or two ambitious men—and a lot of ballast. I mean that groups of men are vacuums. Great big empty nothings. They say we can’t visualize a total nothing. Hell, sit at any committee meeting. The point is only who chooses to fill that nothing.”

Focus groups are that way. Committee meetings are that way.

“No work is ever done collectively, by a majority decision. Every creative job is achieved under the guidance of a single individual thought.”

This isn’t a warrant for lack of planning or development discipline. My point is, when you rely on communal decision making, what you get is a Frankendog—an ugly creature made of patches.

Bait Station Ahead

Rick is asking, What can you keep in your head?

This isn’t going to be “an open letter to Rick.” I have a ton of respect for Rick. He runs an honest, helpful blog which pulled me out of a hole on many occasions. His post got me to finally distill my observations and opinions for those who feel the same way.

Disclaimer: it took me a day to write this post and two weeks to “sleep on it.” I’m not naming names, pointing fingers, or settling score with anyone. These are general observations. Take them with a grain of salt.

What are your goals?

It all depends on what you want to do and where you want to be in the long run. In the words of The Fountainhead protagonist (I will quote the book liberally here),

“Most of the time will be spent working. I’ve chosen the work I want to do. If I find no joy in it, then I’m only condemning myself to sixty years of torture. And I can find the joy only if I do my work in the best way possible to me. But the best is a matter of standards—and I set my own standards.”

Time is a very limited resource. If you spend all your time chasing every technological fad, you’ll end up nowhere. How do you decide what’s worth pursuing? Read on.

Specialist or generalist?

It depends on your worldview. Do you want to be really good at one thing, or know a wide range of subjects in less depth? I prefer to be a generalist, although I know some things much deeper than others. However, it takes a substantial effort to be a generalist. You have to read a lot and keep your ear to the ground.

Basics don’t change (that much)

The term “bubble” has existed in finances for at least a couple of centuries. In the grand scheme of things, the latest dot-com bubble was nothing new. It had the same age-old mechanisms, and yet a lot of people made a trip to the loony bin.

Compared to finance, the field of computing is very young. Over the years, the same basic principles migrated from one language to another, yet they stayed mostly the same. If you read Steve McConnell’s Code Complete and look at the bibliographical references, some of them go way back.

Knowing technology-agnostic principles of software construction is absolutely essential. The Mort crowd doesn’t get this. They focus on what’s shiny. At the end of the day, the choice of technology matters very little. You can do amazing things with Java, .NET, Ruby, Python, etc. Knowing the principles, you will be an outstanding developer regardless of the technological fads.

A lot of people are stressed out over the torrential downpour of new technologies and tools. Do you have to know them all? No, of course not. What about all those alphas (euphemistically called “CTPs”) and betas? Ignore them. I see people who jump on the bandwagon early and rewrite their stuff over and over with each CTP release. If you’re not yet sick of such a chaotic and unfocused life style—fine. Otherwise tune out!

Case in point: a good friend of mine was presenting at a Code Camp not long ago. He tried to explain the Singleton pattern and drew blank stares from the audience. Now, come. On! This is what the drag-and-drop mentality does to you: you miss the essentials.

“Evangelists” of various stripes and colors

The mission of Evangelists (pun fully inteded) is to sell you on some technology and its tooling. They are in the business of converting and bringing you into “the fold”. It’s not about educating you. Have you ever heard an evangelist give a talk on object composition, separation of responsibilities, refactoring, inversion of control, and such? Not likely.

Microsoft has plenty of marketing dollars to spend, and they do so by way of evangelists creating noise and pitching the latest shiny toy. It’s marketing, not education. Next thing you know, Betrand laments that book authors badmouth UpdatePanel for its abysmal performance and resource hogging. Bertrand, you never told us the whole story about its performance implications. You let the marketing gang do the talking. But smart people filled in the blanks and got pissed off. Do you expect loyalty for sweeping crap under the carpet?

Understand this relationship. Evangelists are good people, but their priorities are fundamentally different from yours. The better they do their job, the further they will advance within the Microsoft org chart.

Think about it: you refuse to sign up for an extra credit card when a solicitor calls. But you keep imbibing everything evangelists serve you, whether you need it or not. Why?

Case in point: Silverlight. In political terms, Microsoft is playing safe here by going to their base (that’s you) instead of Rich Media professionals (the Flash/AIR crowd). The majority of developers don’t work with Rich Media, so the bet is that you will peddle Silverlight in your company.

Understand that you’re being pitched. If you need to master a specific technology, pursue it. Otherwise tune out!

Glory hounds

Recognize also that there will always be people proclaiming the virtues of a new technology or methodology at the top of their lungs. Not because it’s good (it may as well be), but because it’s new and shiny and because they need to generate consulting gigs. Recognize also what keeps them going:

“He’d see that all his wishes, his efforts, his dreams, his ambitions are motivated by other men. He’s not really struggling even for material wealth, but for the second-hander’s delusion—prestige. A stamp of approval, not his own.”

Does it have to stress you out of your wits that there isn’t enough time in the day to follow each loud voice? I prefer to “lead useful, active private [life] in public silence.” This kind of stress doesn’t get to me anymore.

Certifications

In my opinion, certs are meaningless. Don’t kid yourself: certs do not intend to educate you. Prep books are intended to coach you how to pass exams. Of all geek literature, prep books are the most useless.

If you ever come to an interview and all they want to see are your certifications, do yourself a favor and walk out. No need to swim in that cesspool.

Your name is your brand

In them ol’ days, a person could finish high school, go work at the same factory his entire adult life, retire and live on factory pension. Our generation doesn’t get this luxury. Instead, too many employers of today bemoan the lack of “loyalty.” If they only saw their companies were stale and boring they wouldn’t complain.

In this day and age, your name is your brand. You don’t build this brand by joining a crowd of Morts. You need to work on your brand. It takes time and effort.

“You know how most people are, they stick to the beaten path, they pay three times the price for the same thing, just to have the trademark. Courage […], they lack courage.”

And again,

“It’s the hardest thing in the world—to do what we want. And it takes the greatest kind of courage.”

This is, by the way, one of the reasons I don’t join “blogging gangs” (an ensemble of bloggers under one URL). I don’t want to dilute my brand. Neither do I want to dilute that of others.

Where do I go from here?

Read good books and blogs. Go to user groups and Code Camps. Take paid training with a reputable company, if you can afford it. Find an angle you like (mine is web standards and usability) and work it. Develop your individuality and your own brand—your name.

If you have read to this point, congratulations! You now know what Morts never will.

Slides from My Presentation on Usability

This is a presentation I gave back in March at the Connecticut .NET User Group, and in April at the Long Island .NET User Group.

Usability is a subject that is almost never discussed in the Microsoft community so obsessed with drag and drop. I intend to change this.

I’ve been promoting web standards for the past four years, which led me to a much broader subject of usability. I see it an as umbrella over web standards, UI design, graphics design, copywriting, typography, etc.

I intend to give this presentation at a couple of upcoming Code Camps. In the meantime, feel free to grab the “slide deck.” I rolled it into a ~7Mb PDF so you wouldn’t need PowerPoint.

Read Good Books to Be a Better Developer

Oren has published a list of his recommended reading and it reminded I wanted to write a post about this for some time. At the bottom on his post, Oren points to an observation that almost none of his books are on a specific technology. Let me come back to this point in a second.

Remember a picture of my stack of books from three years ago? As I look at my bookshelf now, I see hardly any of them left. At one point, I simply threw away those huge ADO.NET and ASP.NET volumes.

I have a nice library of the patterns books (GoF, Fowler, Kerievsky, Chen, etc), and a few MS AJAX books (gotta know your tools, after all). But the rest are along the lines of Don’t Make Me Think, Prioritizing Web Usability, Programming Erlang, Code Complete, Stop Stealing Sheep, Peopleware, Release It! (review coming), etc.

The time came when I noticed I was switching my focus from web standards topics—CSS, XHTML, JavaScript—to a much broader topic of usability. Usability is not about how this or that technology functions. It’s about how people function. The Microsoft camp pays little attention to the aspect of people. This is when I realized those thick volumes you see on the picture on the left weren’t helpful. They were putting tooling first.

That’s just wrong.

I also realized that to become a better developer you need to lay off of geek literature and read good books. Granted, you need to stay up to date. But try to strike up a conversation with a geek about anything outside of software. Seriously, try it.

What’s a good book? It depends on your mindset and world view. Read about typography—it affects people in powerful ways. Read about accessibility—gain appreciation for people with disabilities. Read about design—it’s about communication and problem solving. Read Peopleware and Release It!. Read Don’t Make Me Think so you don’t start or get yourself involved in religious debates.

My approach is to read one book pertaining to my industry, alternated with a non-geek title.

The Best Design Coding Guidelines Ever

This must be the best video presentation on web standards and SEO. If you are so astounded by the clarity of the material that you can’t remember a thing, below are a few points to take away:

Do your layout with divs
Please don’t use tables even though they work fine
Describe the DOCTYPE so the browser can relate
Check in all browsers
Title everything including links and images
Don’t use <b(old)>, please use <strong> ’cause if you use <b(old)> then it’s all then wrong

Go watch now and enjoy!

How Does MS AJAX Manage to Crash Firefox?

Another day, another idiosyncrasy. I’m implementing the IScriptControl interface and have the following line which crashes Firefox upon page unload:

public IEnumerable<ScriptReference> GetScriptReferences ()
{
   yield return new ScriptReference (
      "MyNamespace.MyScriptControl.Panelbar.js", 
      this.GetType ().Asembly.FullName);
}

Firefox crashes cold with this:

By trial and error, I figured that the following line does not cause crashes:

public IEnumerable<ScriptReference> GetScriptReferences ()
{
 yield return new ScriptReference (
   Page.ClientScript.GetWebResourceUrl (
     typeof (MyControl), "MyNamespace.MyScriptControl.Panelbar.js"));
}

}

Go figure. On a scale of 1 (a hiccup) to 10 (absolutely weird), this issue scores a 10.

Extender Control Just Won't Pick Up Localization

Imagine my surprise when, having gone through the AJAX localization tutorial and this MSDN article up, down and sideways, I couldn’t get my extender control to see resource strings on the client!

Here’s the extender skeleton:

[assembly: WebResource (
    "[blah].js",
    "text/javascript")]

[assembly: ScriptResource (
    "[blah].js", 
    "[blah recources]", 
    "ClientResources"]

namespace MyControls
{
 public class MyExtender : ExtenderControl
 {
  // Lots of stuff skipped
  protected 
      override IEnumerable<ScriptReference> GetScriptReferences()
  {
   yield return new ScriptReference (
       Page.ClientScript.GetWebResourceUrl (
                 typeof (MyExtender), "[blah].js")
    );
  }
 }
}

I don’t remember why I chose GetWebResourceUrl, but that’s precisely where the problem lies. Change the line to this and everything magically works:

yield return new ScriptReference ("[blah].js",
                        this.GetType ().Assembly.FullName);

Gotta love obscure edge-cases.

Usability Blooper: Dollar, You Ain't Helping

Here’s an interesting screenie from Dollar rent-a-car:

Two issues jump out.

Poor copywriting

The message is clear as mud. Too wordy. Also, displaying internal error codes (“Message Business100”) is a sin unto death, figuratively speaking.

UI disconnect

The error message refers to something the UI doesn’t actually display. There is no list to select from. I can kinda-sorta quess I need to start typing because I’m familiar with AJAXy auto-completes, but still…

“Location” up there is ambiguous because I don’t know their location codes. “Location” is an implementation detail from the jargon of Dollar’s IT peeps.

If it were up to me, I’d go with “Type the city or airport where you’d like to pick up the vehicle.”

Any favorite usability bloopers you’d like to share?

One Interesting Use of Explicitly Implemented Interfaces

When you see a discussion of explicit interfaces, it is usually about resolving clashes in their signatures (see Explicit Interface Implementation Tutorial).

To rehash, you’d implement an interface explicitly to

simulate variance (change parameters or return type in “overridden” methods);
hide a member and add an equivalent member with a better name;
force the client to call members only through the interface.

However, here’s another interesting use case very briefly mentioned in Framework Design Guidelines. An explicit interface comes in handy when it “includes mainly members supporting framework infrastructure, such as data binding or serialization.” A good example is an interface whose members are almost never accessed directly.

This got me thinking. Recently, we had a discussion at work whether our domain classes should be aware of their caching environment. Should a domain class implement a (hypothetical) ICacheable?

In the Domain Driven Design canon, you don’t mix persistence to the domain and thus keep it persistence-ignorant as much as possible. Caching is infrastructure, however, so it seems we can implement ICacheable explicitly as a necessary evil and still feel good about it, eh? I don’t know yet. I’m curious how this is going to shape.

Two Press Releases and Bad Copywriting

Compare these two artifacts that came from the gods of corporate communication:

“We strive to quickly leverage existing competitive data to allow us to interactively restore long-term high-impact opportunities to meet our customer’s needs. The customer can count on us to interactively engineer cost effective information in order to seamlessly simplify high-quality data to set us apart from the competition.”

and

“Microsoft today announced a set of broad-reaching changes to its technology and business practices to increase the openness of its products and drive greater interoperability, opportunity and choice. These changes are codified into four new interoperability principles and corresponding actions: 1) ensuring open connections; 2) promoting data portability; 3) enhancing support for industry standards; and 4) fostering more open engagement with customers and the industry, including open source communities.”

The former is from the Dilbert Mission Statement Generator, the latter—from Microsoft (hat tip to Bill Zack). I am thoroughly enlightened now.

Will those people ever learn to speak like humans?

Join the Dark Side

For months now I’ve been using a dark theme for my Visual Studio, and I’m loving it. To someone who spends days and days in front of a computer, a dark-grey “canvas” definitely puts less strain on the eyes.

I don’t remember where I found the original color scheme, but I modified it a bit for my liking. Ever since I started using Consolas, I just can’t use any other font in Visual Studio.

Feel free to grab my Visual Studio 2005 and 2008 theme. Here’s how you install it:

Copy the .vssettings file in My Documents. Visual Studio does some weird things if it can’t find the settings file later, so keep it in My Docs.
In Visual Studio go to Tools | Import and Export Settings…
Choose “Import selected environment settings”. Click Next.
Decide if you want to back up your settings (you probably should, in case you want to go back if you don’t like the new syntax coloring) and click Next.
Click Browse and find the .vssettings file from step #1. Click Next.
Click Finish.

Oh, and if you haven’t configured your Windows box to use ClearType, you’re missing out a lot!

Enjoy!

Collection Interfaces Smell

Going back to Framework Design Guidelines, here’s a guideline pertaining to collections that I disagree with:

8.3.1. Collection Parameters

“✓ DO use the least specialized type possible as a parameter type. Most members taking collections as parameters use the IEnumerable<T> interface.”

public void PrintNames (IEnumerable<string> names) {
   foreach (string name in names)
      Console.Write (name);
}

My grievance with this advice is

it leads to code maintenance nightmare;
it has bad smell of a leaked implementation detail;
it can lead to poor performance of LINQ queries.

Maintenance

I’m a big believer in programming against interfaces instead of concrete implementations. However, when it comes to collections, developers tend to get confused which “least derived” interface (or collection) should do the job. You see IList<T>, List<T>, ICollection<T>, Collection<T>, IEnumerable<T> all used without consistency. Mainintaining this is next to a nightmare.

Implementation leakage

Honestly, I don’t want to care what kind of collection a return type is. Dealing with a specific interface puts me in the wrong frame of mind when consuming the API.

Performance of LINQ queries

Let’s look at a simple operator, such as Last (see ripped source). If the source parameter is an IList<T>, the operator simply returns its Count property. If source implements the vanilla IEnumerator<T>, the code iterates over the entire collection to arrive at the last item. Not too performant, and it’s a simple case!

Using subclasses of generic collections instead

Luckily, the same section in Framework Design Guidelines has the following guideline:

“✓CONSIDER using subclasses of generic base collections instead of using the collections directly. This allows for a better name and for adding helper methods that are not present on the base collection types. This is especially applicable to high-level APIs.”

Collection inheritance is a whole different subject, so I won’t go there. I like the idea of abstracting away from the underlying type, even if it’s as simple as:

public CustomerCollection : Collection<Customer> {}

LINQ-ifying custom collections

While we’re on the subject of custom collections, here’s my approach to making them “LINQ-ready” (same code I demoed at my Philly Code camp LINQ talk):

class CustomerCollection : Collection<Customer>
{
    public CustomerCollection () { }
    public CustomerCollection (IList<Customer> customers) : 
           base (customers) { }

    public static implicit operator
          CustomerCollection (List<Customer> customers)
    {
        return new CustomerCollection (customers);
    }
}

They key here is the implicit conversion operator which takes a list of customers and feeds it to a corresponding constructor. Here’s how to use it in real life:

CustomerCollection result = customers
   .Where ([lambda expression])
   .ToList ();

Nice and concise. Otherwise you’d have to wrap the result with an explicit constructor invocation which gets ugly fast.

Scenario-Driven Design Violated To the Utmost

I like Framework Design Guidelines. It’s a nice guidebook on how to get everyone on your team on the same page and establish common coding practices. While re-reading it, I came across the principle of Scenario-Driven Design (sec 2.2.1) which states the following:

“Framework design should be focused around a set of common scenarios to the point where design process is scenario-driven. We recommend that framework designers first write code that the users of the framework will have to write in main scenarios, and then design the object model to support these code samples.

[…] When designing a framework, you should start with producing a scenario-driven API specification.”

If you subscribe to the Xxxx-Driven Design fashion of the day, you will recognize this advice as the core idea of your methodology. There’s nothing wrong with it. It’s a great idea: put yourself in the shoes of other developers and see how it feels to be them.

Krzysztof (coolest Scrabble name ever!) goes on to say, “There is simply no other way to design a great framework.”

JSON serialization in 2.0

The 2.0 runtime had this handy class JavaScriptSerializer. You could throw anything at it (even anonymous types in 3.5), and it would produce a JSON string out of it with a single line of code!

string json = new JavaScriptSerializer().Serialize (blah);

JSON Serialization in 3.5

Once you upgrade to the 3.5 runtime, all of a sudden you get compiler warnings that JavaScriptSerializer has been deprecated in favor of its older brother, DataContractJsonSerializer.

I’m going to lift a snip from Rick’s blog just to show the contrast:

DataContractJsonSerializer ser = 
   new DataContractJsonSerializer(typeof(Customer));

MemoryStream ms = new MemoryStream();
ser.WriteObject(ms, person);
string json = Encoding.Default.GetString(ms.ToArray());
ms.Close();

All traces of scenario-driven design are gone. This is an example of a typical overengineered Microsoft monstrocity, and we’re not even done yet. You have to go your domain model and decorate classes with [DataContract], and their members—with [DataMember]. All this pollutes your domain model with crap big time.

*sigh* It’s beyond me how someone thought this was acceptable.

Achieving Code Symmetry

In my review of Kent Beck’s latest book, Implementation Patterns, I didn’t mean to present it as completely useless. It has some great points sprinkled throughout. It’s just that they are buried in trivialities. Still, one valuable concept Beck talks about in his book is that of code symmetry.

“Symmetry in code is where the same idea is expressed the same way everywhere it appears.”

Beck gives the following example:

void process () {
  input ();
  count++;
  output ();
}

The second statement is an implementation detail. It’s the how, not the why. For better symmetry, you can rewrite it as follows:

void process () {
  input ();
  incrementCount ();
  output ();
}

A little better. Whereas input() and output() are named after intentions (the why), incrementCount() is named after an implementation (the how).

An even better rewrite would yield this:

void process() {
  input ();
  tally ();
  output ();
}

Another problem with the first sample is that it jumps from one abstraction level to another.

“Code like this is jarring to the reader. Code is easier to understand when it flows, and abruptly shifting abstraction levels breaks flow. What is that bit twiddling in there? […] What does it mean?”

Explaining messages

Explaining message is a “pattern” in Beck’s book that is similar to the principle of code symmetry. He cites the following Smalltalk example:

highlight (Rectangle area) {
  reverse (area);
}

Come to think of it, the name highlight expresses the intention while reverse expresses the mechanics. Why does this matter?

“The distinction between intention and implementation has always been important in software development. It is what allows you to understand a computation first in essence and later, if necessary, in detail. You can use messages to make this distinction by sending a message named after the problem you are solving which in turn sends a message named after how the problem is to be solved.”

The highlight method above is an example of an explaining message. Even if it’s a one-liner, the “main purpose in invoking an explaining message is to communicate my intention more clearly.”

After all, the compiler doesn’t care how you name methods or format code. You’re writing it to communicate with other people. And that’s what Beck’s book is about.

Sleek Use of a Lambda Expression

I can’t recall where I found it, but here's a sleek way to employ a lambda expression:

SomeButton.Click += (sender, e) => { .... };

I’s one of those moments when you say to yourself, “But of course!”

Then there’s also this really short event handler syntax.

Where Is C# Heading?

A friend of mine (let’s call him Morpheus to conceal his identity) and I had a lovely chat about this helpful linkfest on immutability in C# (great posts there, btw!).

Morpheus: yeah it is the F# folks moving some of its concepts to C# 
Me: Yeah, I noticed. Good stuff. 
Me: Wonder what a hodge-podge C# will become soon :D 
Morpheus: just like VB 
Me: Aaaah, who cares about VB :D 
Me: People will still name classes clsXxxxxx :D 
Morpheus: well, if C# gets as convoluted (sp) as VB, then 
what's the difference?

(Morpheus wins this round)

I will leave it up to you to come up with a good answer.

Creepy Implicitness

Generally, I’m not against implicit operators, but this LINQ/XML syntax gives me creeps:

new XAttribute (XNamespace.Xmlns + "foo", "bar")

Took me a while to understand that XNamespace has an implicit operator which allows this string “concatenation.”

Book Review: Implementation Patterns

When I saw Implementation Patterns by Kent Beck due for publication, I thought: “Kent Beck—yay! Patterns—yay! Famed Addison-Wesley signature series—yay!” I snatched a copy as soon as it came out. In retrospect, this book is nothing what I expected it to be.

Quite simply, I don’t understand its purpose. The book is only 143 pages long and is too brief to enlighten beginners and too shallow for advanced developers.

“Patterns” in the title is a misnomer. These aren’t patterns the GoF or Fowler style. They are principles of code construction. This subject is covered way better in Steve McConnell’s Code Complete which, in my opinion, is a must read for everyone who wants to graduate from a closet hacker to a real software developer. In fact, Implementation Patterns covers the exact same ground (in Java) in far less detail. It is, essentially, a mini-Code Complete.

It does contain a quick rehash of some general OO principles, patterns and refactorings, e.g. class, interface, subclass, inner class, conditional, delegation, value object; field, collecting parameter, parameter object, eager and lazy initialization, etc. However, It’s much more a philosophical book than a how-to.

The grand theme of Implementation Patterns

It’s this:

“The goal of this book is to help you communicate your intensions through your code. […] Throughout, the book is focused on programming techniques that enhance communication.”

It’s really about communication (e.g., “Communication with people is the purpose of class names.”) It’s about how to write code, expressive and robust enough for other people to understand; how to code in terms of intension, rather than implementation (McConnell covers this subject very well), etc.

Conclusion

I don’t understand who this book was written for and why. There are plenty of great books for Java and non-Java developers. Besides, since it’s an AW signature series book, it’s way overpriced. If I knew better, I would have passed it up.

Philly Code Camp Sample Code

I’d like to give very belated thanks to everyone who helped put together this year’s first Philadelphia Code Camp, which took place last Saturday. I also want to thank those of you who attended my LINQ presentation, Can we LINQ it? Yes, we can!

Somehow, my talk abstract was not published, so I assume you came on blind faith. I have a conspiracy theory that I got censored due to a reference to communism (just kidding). Here it is in its original wording:

“With the advent of LINQ, we have so many ways to query, filter and transform data collections. In this session we’ll go over all of the Standard Query Operators and see how they work.

Does “lambda function” represent the point of union of the lambdoid and sagittal sutures of the cranium? Does GroupJoin impart the wisdom of crowds? Does EqualAll usher in an era of communism? Come and find out!

Please note: we will not talk about Visual Studio; LINQ to SQL, LINQ to XML, etc in particular, but queryable data sources in general.”

Feel free to download and poke around the sample code I demoed off of. If I were to summarize LINQ, it would be this: LINQ == anonymous methods on steroids.

As if getting from Long Island to Fort Washington, PA weren’t a long hike…

I got to meet Mark Pollack of the Spring.NET fame who reawakened my interest to Spring. If you never met Mark, he’s a great guy. We took a train from NYC and got so carried away with the conversation that missed Philly. Check this out:

In case you can’t decipher, it says: “Allow return. Missed stop.” Thank goodness the next stop wasn’t D.C. Aaaah, good times.