Content Management Systems (CMS) for the .NET Platform



.NET Utility Libraries Galore

**NOTE** THIS PAGE IS NOW BEING MAINTAINED AND UPDATED AT kind of thing I’m talking about]

Another Free E-Book – Domain Driven Design Quickly

Yet another community gift – this time an e-book about Domain Driven Design. You can buy a print version but the PDF is free, and small enough to easily print out yourself and bind with a clip. The book is by the founder and editor of, and is billed as a summary of Eric Evans (this one, not this one ) famous book, Domain Driven Designimage At this rate I may never have to purchase another book again.

Linxter Offers Durable Messaging for Remote Clients

A discussion on the nServiceBus discussion list has been taking place recently regarding how to have durable messaging on remote nodes, such as smart clients, where the deployment and maintenance requirements of MSMQ aren’t tenable. The main concept being tossed around was a local database to hold un-sent messages at the remote endpoint that could be attached to any transport, making any non-durable transport durable. Ayende went off to build a prototype (but hasn’t reported back, so I’m not sure if it is still in progress, although there were strange noises coming out of his blog recently that suggest he might still be working on it) and it was mentioned that Evan Hoff was building such a thing using Berkeley DB.

One advantage of both of those options is that durability could be bolted on to any transport, such as HTTP or one of the non-durable WCF bindings, without much fuss. However there is at least one commercial service that I’ve talked about before, Linxter, that provides an internet-oriented message transport (or Internet Service Bus, ISB) with lots of cool features. What I didn’t realize, until today, was that the Linxter client API does exactly what was discussed at the NSB forum – provides a local cache for messages via an embedded DB (SQLite in this case), essentially enabling an x-copy deployable, durable, asynchronous messaging endpoint.

Of course, it doesn’t have the flexibility to attach “durability” to any conceivable transport – because Linxter is it’s own transport – but in most cases I don’t think that should be a big issue. The only question now, is, how much will it cost? Apparently pricing will be announced with Beta 3, which is scheduled for July 31st. Version 1.0 is scheduled for August 15th.

Here is the e-mail I received from Lixter’s Jason Milgram explaining the local queue:

Yes, the Linxter API queues messages locally (does this in Beta2), and does not take them off the queue until they are delivered. In Beta 3, we will offer additional reliability and efficiency for file transfers by enabling chunking. For example, let’s say you are transferring a 100MB file, and after transmitting 70MBs you lose your connection,…when the connection is re-established, it picks up from where it left off. We felt that these queuing and chunking features were pretty important especially with wireless connectivity becoming the norm.
The ISB is a distributed system, with failover built into the SDK (API)  as well as on the ISB. If the API cannot connect to a service on a particular set of clustered servers, it will failover to another set of servers. We can also dynamically reprovision server and service assignments for programs.

And here is the updated roadmap [emphasis mine]:

Release dates:

  • July 31st        Beta 3
  • Aug. 15th        Version 1.0

Beta 3 Overview:

  • Linxter SDK for both .NET and Java
  • Reorganization of methods for on demand and scheduled sending
  • Enhancements to Web Manager user interface
  • Web Manager support for both IE and Firefox
  • Standardization of API local datastore to SQLite
  • Availability of Quick Starts – feature based sample apps

On our website we have added the following:

Evaluating Expressions at Runtime in .NET (C#)

SQL Join Resources

This seems to be good SQL join resource.

Beginner’s Mind

Shunryu Suzuki, one of the pioneers of Zen Buddhism in the United States, said this in one of his lectures:

“In the beginners mind there are many possibilities, in the experts mind there are few”

This statement was part of a talk about something a bit closer to the pulse of life than the practice of software development (namely about the practice of finding the pulse of life) but it is nevertheless a resonant concept when applied to any cross section of our human experience, software development included.

Jeff Atwood and Scott Hanselman write about this eloquently. Karl Seguin recently published an e-book about ALT.NET, and in the introduction to the book relates his experience of being able to truly grow as a programmer only after shedding the illusions that he was an expert programmer.

I’m not interested in driving that point home any further. The argument was made very well by the authors above and rehashed endlessly in the comments of their respective blogs.

However, I thought it might be interesting to describe my personal experience of coming to that realization in my own career, and how it has altered (opened up) my view of our industry. image

After many years of writing software for the same company with a tight focus on the task immediately at hand I decided to tune in to some of the chatter of the social web, rather than just digging through it on an as needed basis to solve one particular problem or another. I’ve always been an avid reader of technical books but technical books, especially ones about established (or even emerging) technologies, are very focused on their subject matter. They are, as advertised, about a specific technology, not about the art and practice of programming. I’ve also read a number of the classic books on the art and practice of programming, such as The Pragmatic Programmer, Code Complete, various patterns books, books on Agile, Domain Driven Design, and so on. Those are more enlightening than a technology specific book, and they help you improve your craft in a much more general way, but by and large they weren’t reflective enough to show me how little I knew.

Then I started to pay attention to this gigantic, amazing conversation that is always unfolding in the “blogosphere,” and, slowly, groggily, I started to wake up, to understand how expansive and fluid the world of creating software actually is.

The experience can be described as spending several years climbing a mountain you were born at the foot of, all the while assuming that the mountain was the whole world. As you near the tree line, you begin to catch glimpses of something larger flickering through the gaps between the trees, and then all at once you break through the tree line and behold the entire, sprawling mountain range extending out in all directions and any illusion you may have had about mastering your environment immediately evaporates and you find yourself in awe, and maybe a little bit frightened at the unexpected vastness.

In my case I was faced, on the one hand, with the fact that the sum total of the knowledge I had acquired thus far (struggled to acquire and felt such a sense achievement for acquiring) was barely a drop in a very big bucket. On the other hand, the universe I spent most of my waking hours in just grew without warning to unimaginable size, and now I got to explore it. There are certain times in life where being humbled is the only way to continue to grow, like a rose bush that must be cut back each season before it can bloom.

The first thing I noticed when I broke through the tree line, after recovering from the sheer size of it all, was that each of the other mountains, and the valleys between them, were crawling with fellow explorers. Sure, I had passed a few people on the way up my mountain, and a few people had passed me, but all of a sudden there were thousands upon thousands of other technologists scurrying about everywhere, sporting fanny packs, pocket protectors and laptops. Most were sweating and stomping steadily up the myriad well worn paths, but others were running far ahead, hacking through underbrush, madly scribbling notes as they went,  tossing them over their shoulders by the  fistful; others gave loud, grinning sermons as they strolled along while throngs of followers cheered or broke into raucous fistfights, and still others would stop regularly to draw detailed maps of where they had been, their theories about what lay ahead of them, and very often enough take the time to give lectures and make screen-casts of their experiences pioneering in this enormous, shared adventure of being a technologist.

Personally, I find it to be quite beautiful, and tremendously inspiring.

Of course, not everyone is helpful. There are plenty of angry, impatient and elitist explorers too, yelling at one another from peak to peak, certain their mountain is Mount Sinai, the others are cheap decoys, yadda yadda. This part of the culture is best served by the religion metaphor, though, and there is no avoiding the phenomenon: humans are extremely religious creatures and programmers, to their chagrin, are not immune. How can it be helped? Human life is an absolute mystery, religion is inevitable.

And of course these countless throngs have organized into cliques, tribes, nations, hold elaborate rituals, build massive idols and sprawling temples, go to war, cross-breed, and so on. The same microcosm of human society that is repeated in every other industry, or nation, or religious sect or body politic across the planet and throughout time. Obviously the universe uses design patterns, too.

Anyway, mostly I wanted to relate my experience in order to express my newfound appreciation of our profession, and particularly the staggering social generosity of the luminaries, pioneers, and everyday developers who devote so much precious time and apparently limitless energy to clearing the paths and building the roads on which the rest of us are able to make such amazing progress.

I will close this post with another quote from Suzuki Roshi. This one I’ll leave up to you to interpret.

“My lecture for tonight will be very short, especially after having a good dinner of noodles, which were very long. Our transmission should be a very long, long one. And our transmission is a special noodle.”