UPDATE: Gaja Kannan attended this presentation and gave me a great link to a post by Torkel Ödegaard concerning IoC container performance. Interestingly, of all the IoC containers out there, Torkel picked the same products as I did (plus StructureMap) for his tests. You can find the post at http://www.codinginstinct.com/2008/08/castle-windsor-dependency-lookup-and.html. Thanks, Gaja, for the link! 

On Thursday, October 2, 2008, I gave a presentation to the Richmond .NET User Group entitled "A Survey of Popular .NET Inversion of Control Containers". It covered Microsoft Unity, Ninject, Castle Windsor and Spring.NET. I talked about the history of the development of Inversion of Control (IoC) and Dependency Injection (DI). I demonstrated the concept in a sample application (linked below). I also discussed Aspect-Oriented Programming (AOP) and how it can be used to create highly cohesive, loosely coupled applications. The slide deck and code is available at the links below.

Source Code (77 kB)   Slides (268 kB)

I am a big C# fan. As a general purpose, imperative, object-oriented language, C# has begun to take on some functional language capabilities that I like very much. LINQ just rocks, for example. And LINQ is a very functionally-oriented technology. It's so easy and expressive to get set-oriented work done using LINQ and it's functional underpinnings are the reason why.

I have been thinking a lot recently about why F# might be important to the future of all software development. If you think about it, there's really little in F# that doesn't already exist in other languages like OCaml and Haskell. But F# is significant and different because Microsoft is behind it and because of the tight integration with the .NET framework. But beyond the who of F# is the why of its importance. And the why, in my mind can be summed up with these five bullet points:

• ORMs are failing to gain mindshare not because they aren't good domain modeling tools (as some complain about). They are failing because the imperative, object-oriented languages in which we use ORMs are unfriendly to sets and tuples.The database is full of nothing but sets and tuples. So we read them into objects and wonder why there's an impedence mismatch. F# is not only set and tuple friendly. You can't really think properly in F# without these first-class constructs.
• Domain Specific Languages (DSL) are becoming more and more important in the marketplace. And functional languages are great for building language compilers. Language parsing into discrete intermediate forms is a problem that benefits greatly from the lambda calculus and functional decomposition. F# is appearing at the right time and place in history to serve in the critical role of helping us to build new DSLs.
• Many of our time-honored design patterns are workflow-oriented. So, why do we shoe-horn them into data structures? Workflows are, by definition, composed of functions invoking higher-order functions. Step 3 invokes on the result of Step 2 which invokes on the result of Step 1. So, why do we code the Visitor Pattern to walk a tree into a data structure like an object? It makes no sense, really. F# allows us to revisit these time-tested patterns and view them in the light of functional decomposition. And the result will allow many who have been unable to grasp those patterns though an imperative lense to "get it" for the first time.
• Service-Oriented Architecture (SOA) is predicated on the idea that strict operation contracts exist that take discrete, strongly-typed inputs and return strongly-typed results. F# rolls like that. There's no object-orientation in SOA, per se. In fact, SOA sort of shuns OOP to a certain degree. And good service design also avoids side effects, another tenet of functional languages. So, if SOA is important, and I think it is, then languages that follow the patterns of SOA will also be important in building compliant architectures. I think good architects will recognize the pattern and find interesting ways to expose services via F#. We will code the guts of services in C# and Java in the future. No question there. But the workflow, scheduling and execution core of SOA will be based on functional languages like F# instead.
• Moore's law is breaking down. Intel and other companies are all moving to put more computing cores into their packages because they can't scale computing power vertically beyond what modern physics will allow. So, they are scaling horizontally to meet customer demand. The problem with this concept is that the marketplace isn't really ready for this kind of change. Massive pools of threads attempting to use Many Reader, Single Writer Mutexes with Starvation Avoidance ain't gonna work, my friends. We need a new model that will make parallelism invisible. But for parallel computing to become invisible, we need to move to a model that doesn't require the programmer to be involved in locking and serializing access to their code. F# is ready to help us think that way. And it's .NET! Beauty, eh?

My boss, Wei Wang, the CTO here at SnagAJob.com announced my resignation to the rest of the Engineering team a few hours ago. It went very well. Although Wei wishes I weren't making this change, he has been supportive of my decision and my reasons for making it. My peers on the Engineering team expressed some regret but they've also agreed to support me through the change. I reciprocated by giving SnagAJob.com a full four weeks of time for transitioning off of the projects I am heading up. It will take at least that long. I predict nights and weekends of effort to get finished in time.

I am anxious to get started as a Lead Consultant, Architect for CapTech Ventures on 25 August 2008. I have friends at CapTech already including Darrell Norton, Mark Hudson, Matt Borgard, Mark DiGiovanni, Mike Diiorio and Sam Nixon. I'm really looking forward to working with all the great professionals there. It's a great company with a reputation for results.

As the Software Architect here at SnagAJob.com, it has been my job to shepherd everyone through a long and difficult re-architecture process which started in May 2007 and ended in March 2008. It took over 47,000 person hours across every department in the company and was successful in almost every way. We started with a group of folks on the Engineering and Product teams who didn't know much about large scale software design. They were good programmers but honestly hadn't made the leap in their own minds to become developers yet. Over the past year and a half, I've worked day in and out to help them make the transition from programmers to developers. Many of them are now making the leap from developers to real software engineers. It's very exciting to see that kind of growth.

Serving SnagAJob.com has been extremely rewarding. Now I can stand silently in our scrums, just smiling and listening to our developers talk with authority about the risks of not having enough unit testing coverage. They talk about their behavioral and integration testing milestones and their mock object strategies as if they had been doing this for many years. They speak with confidence concerning security and n-tier architecture best practices. Service contracts, operation contracts, data contracts and fault contracts are an integral part of their vocabulary now. Their transformation has been nothing short of amazing. I am pleased, to say the least.

But there comes a time for every Software Architect when he must ask, "What's left for me to do?" It's often said that if you hire a salesperson who's not interested in making money, they will fail miserably. That's because their goals are all wrong. A salesperson's goals must be based on selling stuff and making money. And I think it stands to reason that software architects who can't imagine the day when they won't be needed any longer will never be truly successful either. This is because the goals of software architecture (and software engineering to a certain extent) are not the same as the goals for software development. Development is a set of tasks that lead to other tasks whereas design is a constrained short-term effort. Consider these analogies to make my point clear: How many building architects move into the buildings they design and live there forever? How many civil engineers throw out a tent under the bridges they design to keep an eye on them? You see, in the architectural world, good design is self-deprecating with respect to the current effort because it must be a finishable work. Businesses that depend on architecture of any sort would cease to function if this weren't true.

It's not that I can't continue to contribute here at SnagAJob.com. After all, every good architect has served as a software developer at some point in his career. And there's plenty of software development to do at SnagAJob.com. But much of the growth and planning now is vertical in nature, multiplying the business formula that's working well. My architecture is designed to scale for that. I don't need to stay here to watch it do what I built it to do. I believe that my architecture will also scale horizontally to new products and services as well. We've already observed that phenomenon since we released the new system in March. But, again, the team I will be leaving behind knows how to make horizontal growth happen using the techniques that I taught them.

At CapTech my new job will be to engage in a different sort of multiplicative effort. I hope to multiply the success I've had here at SnagAJob.com across many more companies. Jumping back into consulting makes a lot of sense for me at this stage of my career for all the reasons I've outlined above. To reverse (and hack) an old adage, "Software development is a journey but good software architecture is a destination." At CapTech, I hope to bring many companies to that destination so that their ensuing journies may be successful. I will miss my friends at SnagAJob.com sorely. This is an awesome company run by some of the best business minds with whom I've ever had the privilege to work. It's time for me to move on but if you are in high-tech or human resources worlds and you want to grow, check out SnagAJob.com. To my friends at CapTech, I'll see you soon.

I use NHibernate and LINQ to SQL on a site that supports millions of end users. Murray Gordon, an Architect Evangelist at Microsoft, has written a nice synopsis of the Entity Framework Vote of No Confidence debate so far. More than anything else I've read on the subject, this article brings together facts and opinions that seem to ring true from my deep experience.

I'd like to go on record and say that the way this is being handle by the MVPs who signed the petition is unprofessional, in my opinion. Microsoft MVPs are not required to tow the line and agree with everything that Microsoft says and does. But there are ways to communicate with Microsoft that are constructive and there are ways that would make any corporation, including Microsoft, digs its heels into the dirt. This petition used the latter strategy unfortunately. In particular, Microsoft MVPs have channels that the rest of us don't have. They should use them and not the blogosphere to make plain there grievances.

In some sense, I feel as though the signatories of the petition feel like they are playing Continental Congress against King George. But there's no Boston Tea Party here. Microsoft didn't raise any undue taxes from any of us. They simply put out a framework that's clearly a v1.0 product. Microsoft doesn't win with v1.0 products. It wins with version 4 products because as a corporation, it knows how to get the first down (an American football term meaning the team gets to stay on the offensive).

I say let Microsoft run the ball for a few plays and let's see how they do.

Databases are just awful. I don't mean the products themselves but the concept of databases. Stop and think about how absurdly we behave when we write modern software. We generate scads of information in the course of our daily lives. (A scad for me is about 2Gb the last time I checked. May be more or less for you.) Much of this information approximates the lives we lead and the obligations we must honor. But rather than putting that information into a system that has the tools necessary to model the real world from which the data originally emanated, we usually choose to keep it in a place that does an efficient job of storage. When we need to put it back into the real life approximation engine, we shuttle the information in and out of our application servers as necessary. It's been estimated that as much as 50% of the time we spend in development is in bridging the gap between data storage and the business logic of our applications. That number may be an extreme, low or high. But even if this kind of work accounts for only 25% of our time, why would we choose to spend our development budget this way? Data is so simple. It should just be there, fully accessible to me all the time.

Some operating systems do a better job of closing the gap between code and data than others do. For example, the Pick System, originally developed by Dick Pick in the late 1960s uses a hash-based file system to create associative arrays that are super-efficient for many query operations. The only data type in the Pick System is the string. And most importantly, the Pick database engine is not relational. It is a multi-valued instead, meaning that any attribute that needs to have multiple values can just declare them. In the Pick mind, there's never a need to create related tables and join them for query or reporting. A platform that implements this type of database also typically ships with a Pick BASIC compiler which allows for direct manipulation of the query engine and the associative arrays it produces. The BASIC code runs right there in the database, not on a foreign system. Embedded Pick BASIC is not like the SQL CLR. The SQL CLR, for lack of a better term, is bolted onto the side of SQL Server. You can't do any real data manipulation in the SQL CLR. However, in Pick BASIC, you can freely manipulate schema and data directly. Forget for a moment that it's BASIC and you've got something great there. Compiled code running in the database that can manipulate database objects natively. Way cool and circa 1965.

IBM and InterSystems, among other vendors, still sell these databases like hotcakes today because they solve very real business problems for which relational databases are not ideally suited. First of all, they're fast. And I mean smokin' fast for many types of operations, especially high-volume transaction processing applications. This is partially due to the fact that because there are no join operations (in the classical sense), there's usually less work to do to obtain the data you're seeking. But even when there is a sub-select operation that is required to get what you're looking for, the efficiency of the underlying hash-based file system pays off handily. In database terms everything in the database is indexed, always.

My students and colleagues often hear me say that, "Databases are an unfortunate consequence of history." I say this (and believe it) because if you could travel back in time to 1948 and give the ENIAC developers at the University of Pittsburgh a handful of 4Gb DIMM chips and the necessary plans to connect them to their invention, relational databases like Oracle and Microsoft SQL Server would simply never have evolved. I think that the development path would have been more like what Dick Pick envisioned and built instead. Given enough memory early in computing history, associative arrays, set operations and in-memory manipulation of large data sets would have been the norm. However, as we know, memory was severely constrained in the early days of computing. In fact, it's only been in the last few years as new technology has allowed for memory prices to drop dramatically that it has been feasible to conceive of a solid-state database at all. Oracle's TimeTen and Microsoft's Project Code Name Velocity are leading-edge concepts in a new market-segment that will, one day, fully realize Dick Pick's vision, in my opinion. I predict that accessing data from distributed, in-memory databases will become the norm within my lifetime.

Many of the current Object/Relational Mapping (O/RM) debates are centered around my database evolution postulate because O/RM tools attempt the inverse of what the Pick OS does to achieve the same effect. O/RM tools essentially pull as many database semantics (sans execution) into the application tier as possible where the logic of the program is codified. Whether we run Pick BASIC in the database or use an O/RM to marshal data close to our C# code, the desired outcome is the same. But pulling data into an external execution engine as O/RM tools do is pretty close to nightmarish, to be frank. In fact, Ted Neward, whom I greatly respect, calls O/RM the Vietnam of Computer Science today, meaning a quagmire from which one cannot possibly be extricated and for which there is no good outcome. Ouch! What a stinging rebuke from a guy who's singularly qualified to make an assessment in this space. Even Ayende Rahien's blog post from earlier today reveals a sense of desparation about the state of O/RM technology. What a mess we've gotten ourselves into! No O/RM suite that I know of addresses the real problem at hand, i.e. making data access so transparent that you don't even know you're doing it.

We use both NHibernate and Language Integrated Query (LINQ) to SQL at SnagAJob.com for O/RM. They make life easier in some ways but so much more difficult in others. I cannot begin to count up the hours we've spent tuning the session management code in NHibernate to deal with authentication and transaction management issues. And you don't burn up welterweight programmer resources on that kind of work. Your heavy hitters need to be deeply involved because there are architectural design issues at every turn. Every minute that your senior developers and architects are distracted with this kind of stuff, they aren't focusing on what you thought you hired them for. LINQ is better than HNibernate in a couple of ways, chiefly because of the expressiveness afforeded by the IEnumerable<T> extension methods and the query comprehension syntax. But deploying LINQ to SQL or LINQ to Entities in a real-world environment is still not as simple as it should be. And the real goal of transparent data access is still far, far way using NHibernate or LINQ.

If you know of an O/RM suite that makes accessing SQL data more Pick-like as I've described, i.e. more transparent, I'd like to hear about it.

<Interesting Related Story> In 1993 while working for Datastorm Technologies, Inc., I attended Comdex in Las Vegas. At lunch one day, two fellows joined me at the table. The older fellow to my right introduced himself as Dick Pick. I asked him what he did for a living and he graciously and eagerly explained the Pick OS, it's simple power and beauty and a smallish version of his life story. I was impressed but didn't really get it at the time partly because the fellow seated across the table introduced himself as Phil Katz, the inventor of the PKZip file compression utility. For me, Phil Katz's fame overshadowed Dick Pick's because I didn't know any better. So, I didn't engage with Dick in conversation to the degree that I really should have. History, it seems, hasn't been all that respectful to Dick Pick either. Phil Katz has a detailed Wikipedia article about him yet Dick Pick doesn't, for example. Googling for Dick Pick yields scads (there's that word again) of Dick's Pick's Grateful Dead references and nearly nil related to the computer science genius of our time. In retrospect, even being seated with a legend like Dick Pick was a real honor. I wish I had known to take advantage of the opportunity that was given to me. Live and learn. </Interesting Related Story>

Dave Balter has released an e-book entitled The Word of Mouth Manual: Volume II. I am not a marketer but I am familiar with concepts like Dunbar's Number and how the spheres of influence in a community dictate the rate of spread for a message. The popularity of social networking has everyone talking about viral marketing these days. "Let's attach our product to this social network or that one and drive new traffic by word of mouth," seems to be the buzz.

I don't think most people realize how improbable a successful Word of Mouth (WoM) campaign is. Dave Balter's premise in this book is that while you can and should do things to get into a WoM stream, getting into a WoM river is much harder. In fact, he says that when the timing's right, the opportunity picks you, not the other way around. That's some wisdom I think.

In the sphere of influence in which I participate, the real trust zone is very small. This is happening on a wide scale I think which results in the fact that, "Marketers are spending more and more money delivering messages that consumers are trying harder and harder to avoid." WoM marketing is all about raising the influence of the dollars spent. But with such a small zone of trust, can it deliver?

What does this have to do with software architecture, Kevin? Well, as the liaison between the business and technical groups at my company, it's difficult to count how many meetings I've endured where someone touts the brilliance of the latest viral marketing idea they've come up with. And there are real business resources at stake here. Every moment we spend chasing down a bad idea that seems good keeps us from spending time on those that are truly worthwhile. I need the vernacular that lets me challenge those ideas in a constructive way and I found Dave Balter's book instructive to that end.

Download the free e-book from the link above (or click on the book cover to check out Dave's blog) and decide for yourself. It's a quick read. Hey, look at that! The distribution of the book is viral. Pretty cool, huh?

It says it right there in the documentation. But somehow I had never picked up on it.

If you enable Web-garden mode by setting the webGarden attribute to true in the processModel element of the application's Web.config file, do not use InProc session state mode. If you do, data loss can occur if different requests for the same session are served by different worker processes.

We've been using ScaleOut StateServer for some time now. Aside from annoyances like not being able to see performance statistics for the in-memory cache, ScaleOut StateServer is a good product for managing state data in a large web server farm. (Read about my solution to the missing performance counters problem.) We followed most of the best practices for setting up StateServer. But as we approach the 11 million user mark at SnagAJob.com, we have been seeing more and more issues that point to ScaleOut being the root cause of some serious performance issues on our site during peak load.

We were using ten virtual machines running IIS6 with five IIS worker process instances per server. That's fifty worker processes. Not a huge web server farm but not puny, either. In any case, after speaking with ScaleOut support and learning that many of their customers report networking problems while using vmware ESX to host Windows Server and IIS, we decided to go back to InProc session state management for a while. To do this, we had to enable one of the session persistence modes on our load balancers which is far from ideal. Doing that makes things quite a bit less fault tolerant and slows down the deployment process considerably. But we had to do something and this seemed fairly low risk.

When we switched back to InProc session state management mode, we started noticing strange behavior for logged in users. Tests confirmed that the multi-instance web gardens were the culprit. We downgraded to one IIS worker process instance per server and everything is beautiful.

It's completely counter-intuitive to me (and to everyone else I've spoken) that multiple IIS worker process instances operating as a single web garden don't share InProc session state. Logically, it's one server, right? And Microsoft has had support for memory-mapped files in Win32 for more than a decade. Well, as I said, it's right there in the documentation. But an event log warning on application startup would have been nice in this case.

By the way, even though I like ScaleOut StateServer, our fifty IIS worker process instances have been reduced to three (yes, 3) and we are handling our normal volume nicely. We know that our networking environment isn't ideal. Any company that has to be meet the PCI Security Standards is going to jump through some intricate networking hoops. But there's little reason to deploy fifty server instances to solve a scaling problem when three will do.

For twitter.com users, the near perfect depiction of the series of poor architecture choices leading to the current state of affairs shows twitters (birds) airlifting a seemingly blissful whale by threads over the sea. Aside from the fallacy of bliss in losing access to one's tribe, no image could be more apropos for indicating that twitter is down. Twitter is over capacity in so many ways.

I've been thinking and writing code in the personal connectivity space for a decade or more. I even have a patent in the peer presence space. I joined a freaky little start-up that Intel Corporation invested in called The Palace. Time Warner and SoftBank were in that mix, too. In the late 1990s, we had high hopes of turning our vision of inter-personal connectedness into a cash cow. There were distance learning angles, entertainment angles, etc. All painfully 1990s thinking in retrospect.

We made so many mistakes. However, the technology wasn't the real problem. It was our thinking that was specious. Even as our pens stroked out the patents on paper and our keyboards tapped those ideas into great code, we couldn't imagine the power of the tribe that services like twitter.com evoke in the average user. Our Palace code was built very much like twitter. Centralized message dispatch. It did OK at intranet scale but when it came to thousands or millions of users, it was just the wrong way to build the thing.

Success can be a powerful enemy. Hubris, it seems, is a much greater threat to any technology-oriented business. The scale of the Internet guarantees that. As Andy Grove taught me, Only the Paranoid Survive. Paranoia, like hubris, is an equally self-interested set of emotions. But paranoia is sigularly devoid of vanity. And vanity distracts us from truthful ideas like, "It's probably not smart to build a hub-and-spoke protocol for something that has to scale to millions of users."

I agree with Scott Hanselman that microblogging should not be centralized. Except for SMS and directory access, there's just no reason to make any other parts of a system like that centralized.

This was the first time I gave this talk but the attendees seemed to be very receptive. The concerns about security in Silverlight, especially related to the protection of Intellectual Property (IP) and account access are really on peoples' minds. Based on the thoughtful question I received here and in Roanoke 2 weeks ago, I have decided to dedicate a whole chapter in my new book to Silverlight security principles.

In this talk, I discussed the various methods by which a Silverlight application can access remote web services. We didn't have time to get into RSS/Atom syndication but I'll be sure to cover it in a future talk. We also discussed cross-domain policy, another hot security topic, as it turns out. I showed how to enabled a WCF web service for RESTful delivery and then showed how to consume SOAP-based services from Silverlight. We closed by looking at the use of an in-domain, SOAP-based WCF service to act as a proxy for a cross-domain RESTful service that does not allow cross-domain access by policy. Here are the slides and sample code:

WCFRESTDEMO20080517.zip (18.89 kb) - sample code that shows how to make a WCF service RESTful; a Silverlight control is included that demonstrates how to use it; there is also a Digg.com downloader that demonstrates cross-domain functionality from Silverlight.

Twitter20080517.zip (25.59 kb) - sample code that shows how to consume an in-domain SOAP-based service from Silverlight; that SOAP-based service is really a proxy to a RESTful service at Twitter.com. And since Twitter.com's cross-domain policy doesn't allow access from my domain, this example shows how the server-side WebClient class can be used to circumvent the policy limitation.

Silverlight and WCF - NOVA Code Camp 2008.1.pptx (199.39 kb) - my PowerPoint slides from this discussion.

Accessing web services with SOAP can be just as easy as using REST with all the enterprise-class features you've come to expect from WSDL and SOAP. Who says that the cycle of metadata and proxy generation should be so hard? I gave a talk at the NOVA Code Camp 2008.1 that shows how by using the CodeDOM, and the ServiceModel.MetadataImporter, you can generate proxy code dynamically.

In this talk, I also showed how IronPython can be used to add a dynamic "lower edge" to a C# application to make it much more dynamic feeling. Finally, we finished with a discussion about features that may be added to Visual Studio 10 and the C# 4.0 language sprecification to make SOA achievable for many more developers. It was a lively discussion with lots of great questions. Here are the slides and the demo code:

ProxyGen20080517.zip (20.86 kb) - Sample code that demonstrates the use of IronPython and some custom CodeDOM code to avoid generating proxies for WCF integration via SOAP/WSDL. IronPython 2.0 Beta 1 or newer is required to compile this code.

Simple SOA with SuperSOAP by Kevin Hazzard.pptx (208.46 kb) - my PowerPoint slides from this discussion.