Yesterday's news

Here’s one fascinating article on DIMM memory errors (thanks to @codinghorror for the link!)

http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

Basically, the authors partnered with Google to capture and analyze logs from thousands of Google servers over the period of two years.

Their conclusions are basically (interpretation is mine, check actual article for the original):

• learn how to recognize when the server failure happened due to a memory error and replace any DIMMs that had an uncorrectable error immediately.
• don’t hesitate to spend extra money on premium memory that features chipkill error correction capability (e.g. HP Chipspare, Intel SDDC or Sun Extended ECC)
• don’t get religious about temperature in your datacenter, it has much less impact on memory errors than you’d think (unless of course your temp goes through the roof)
• manufacturer / brand is pretty much irrelvant to memory errors as is DDR1/DDR2/FBDIMM nor the chip size etc.
• do burn-in your memory before putting it in PROD and replace any bad DIMMs. (You can use memtest if you want to test for memory errors specifically.)
• do expect more frequent glitches after 10-18 months of DIMM life

• Everybody knows what TDD is — why, it’s when you write your tests first!
• Everybody knows what CI is. Heck, it’s when you have your builds automatically triggered by check-ins
• Everybody knows what MVC is. It’s when you monkey the Ruby On Rails framework
• Everybody knows what DDD is. It’s when you have Repository<T> that encapsulates your CRUD operations

Of course, real definitions of these are very far from the common understanding.

Specifically, when it comes to TDD, it’s not just writing your tests first, it’s also writing your integration tests before the functional tests.

Say, you have a bunch of classes implementing a multi-step process and you want to add a step to it. Say, each of your steps is a separate class. You know what the requirements for the step are, and your first impulse may be to start writing the tests out. Wrong! First of all you should write the integration tests that specify how your new step fits into overall process. This will naturally force you to mock your step (or “stub” or “double”, you know what I mean) in order to inject the mock into the process class. This will in turn require defining the interface of the step (assuming all steps are different). And that, kids, will force you to consider things that you would likely miss if you started with the functional test for the step itself.

That’s what I mean by early integration: integrate before it’s written. TDD = IDD.

More notes as I read Concurrent Programming On Windows by Joe Duffy. I hope these notes may come in handy for somebody lacking the time to read this 900+ pages monster of a book.

• if you don’t know how CPUs work (registers, interrupts, stack, heap etc) you really should learn that to at least some level, it kind of helps
• everybody knows CLR threads are “managed threads” and there’s no guarantee they’re 1:1 with native threads. Guess what. At least on Windows, they are always 1:1. In fact each managed thread IS a native thread that just executes (JITed) managed code.
• It turns out the SQL Server team considered hosting a custom version of CLR that would use fibers instead of threads (I suppose in SQL Server they expected very many threads) but eventually abandoned the idea and went with regular 1:1 threads
• creating .NET Thread object does not actually do anything but saves the arguments of the constructor in the private fields. Actual thread is not created until you call Start.
• another interesting fact about managed Thread object is how it’s used to manage TLS (thread local storage). Both forms of TLS, the static fields decorated with [ThreadStatic] attribute and those allocated with Thread.AllocateNamedDataSlot method are apparently stored as items in a private collection inside the managed Thread object. In case of [ThreadStatic] the compiler subtitutes references to the static field with invocations of a function on the Thread.Current object that returns corresponding item from the collection that represents the TLS. As you see, no magic involved whatsoever!
• When each thread, including the main one, starts, the stack memory is allocated. For .NET programs the default is 1MB per thread. For ASP.NET, it’s 256Kb. The Thread class has a constructor that allows you to specify the stack size. This can be useful to reduce memory footprint if creating very many threads or, on the opposite, to allow deeper recursion by increasing the stack size. The default is stored inside the header of the EXE file and can be changed by EDITBIN.EXE, the tool that comes with Visual C++

This concludes Chapter 3 and gets us as far as page 125.

Some of us, geeks, have very good karma. Take for instance, Ayende or Hanselman — these guys seem to live in the future (or is it we who live in the past?) — no .NET 1.1 apps, no VB6 maintenance, no legacy databases. Legacy databases? What about them? Well as it often happens, legacy databases were grown (not built!) by legacy programmers. And as much as I love legacy programmers, I can’t understand their fondness of varchar fields. I guess it’s all about extensibility. And flexibility. Indeed, how do you extend your schema if not by making your DataProvider field a varchar, even if you will only ever have 3 distinct values in it.

The good thing about NHibernate, is how it isolates me from the legacy database, and the legacy programmer, along with legacy DBA and legacy PM Specifically, I like the ability to map ugly schema to er… almost elegant… object model.
One little tiny aspect of that is mapping varchars to enums.

In the past (where most of us live), that is in NHibernate 2.0, how did we map Enum property to a varchar column? By creating a mapper class like so:

public class GenericEnumMapper<TEnum> : EnumStringType
{
    public GenericEnumMapper() : base(typeof(TEnum))
    {
    }
}

Then, in your mapping file, oh miracle!, you could do something like this:

<property name="DataProvider" column="DataProviderConst" type="My.Namespace.GenericEnumMapper`1[[My.Namespace.DataProvider, My.Namespace]], My.Assembly">

In fact, this is exactly how it works in Fluent NHibernate (I know for sure, cuz that’s where I stolen my from). There, you don’t even need to define your mapper type. Just do Map(x => x.DataProvider, “DataProviderConst”).CustomTypeIs<DataProvider>(); and you’re all done. But, I don’t use Fluent NHibernate. In fact, I don’t even recommend it. That’s why I was glad to see how NH 2.1 included built-in support for Generic EnumString Mapping. Not that the 2.0 way bothered me that much, but, as a true Kaizen practitioner, I always welcome [meaningless] improvements.

To make your life easier, and reduce your learning curve (I’m being satirical here, likely under the influence of Remy Martin), today I gonna show you how to do this trick in NH 2.1. The thing is, there’s now a built in type EnumStringType<T>, which works exactly like our GenericEnumMapper above.  All you need to do is:

<property name="DataProvider" column="DataProviderConst" type="NHibernate.Type.EnumStringType`1[[My.Namespace.DataProvider, My.Namespace]]">

And you are done. What an improvement! Hurray! Cheers! Long live the king! 

Another summary of my notes and thoughts as I read another book, this time Concurent Programming on Windows by Joe Duffy.

Basics (mostly NOT from the book):

• My favorite analogy for noobs: code is the path, while thread is the train that rides the path, hence multiple trains riding same path. As threads execute code, they might have access to same variables/fields/objects which thus becomes “shared memory”.
• We think of some operations as atomic while in reality they are not. Famous example is x++ where x is a shared variable. The ++ is compiled into several operations: getting value, incrementing, putting result back. Depending on exact timing of multiple threads doing this for the same variable some of the increments may get lost.
• Invariant is a logical relationship between several objects that must always hold true. For example one variable stores collection elements and the other collection length. From the perspective of external observer the two should never go out of sync, even though updating them (e.g. when new element is added) is not a single atomic operation.
• In order to create illusion of atomicity and preserve the invariants we use locks.
• Conceptually, basic lock consists of a boolean field and two methods: Acquire and Release.
• Conceptually, Acquire works like this: if lock is False, set it to True and return; if lock is True, wait until it becomes False, either indefinitely or until timeout is expired (if supported) by particular implementation. Release simply resets the state back to False.
• C#’s lock statement works the same way but uses special hidden field of the object that you supply to hold the state of the lock.
• The way lock is used to preserve the invariant is by making each thread acquire the lock before looking at or changing the shared piece of memory, and holding it until its done. This way nobody else can see the memory in intermediate state (while the invariant is broken) or screw its content such as in the x++ example.
• In basic scenarios, all the threads that need to be serialized using the locking technique execute same exact piece of code. Thus the region of code between Acquire and Release is traditionaly called Critical Region. This term shifts focus from the invariant to the piece of code protecting the invariant. In more complex scenarios different pieces of code may use the same lock to serialize access to a shared piece of memory.
• There are many kinds of synchronization primitives: locks, semaphors, monitors, mutexes etc. They differ in details but idea is basically the same: only limited number of people may enter the club, others must wait until somebody exits. BTW same techniques are used in the databases to guarantee ACID properties.
• While lock (aka binary semaphor) allows one person into the club, generic semaphor supports multiple threads holding the lock, thereby encapsulating access to a shared-but-limited resource.
• Another form of lock is a read/write lock, when thread specifies its intent (reading or writing). Such a lock allows multiple reader threads having shared access to the same resource. If thread wants to get a writing lock, it must wait until all readers are out. Once the writing lock is granted, no other readers or writers can get in until it’s free again. The idea is to improve throughput by decreasing contention.

More substantial info (from the book or inspired by the book):

• At CPU level, most kinds of locks (as well as Interlocked.Increment kinds of operations) are eventually compiled into an atomic Compare-And-Swap CPU instruction.
• Design-wise, shared memory + synchronization is just one way of organizing data exchange between agents. The other way is non-shared memory + messaging.
• Conceptually, there are four reasons for synchronization:
  1. to create illusion of atomicity
  2. to preserve invariants
  3. to orchestrate mutilple tasks running in parallel, for example to wait until all worker threads are done processing their chunks and
  4. to restrict simultaneous access to a shared but limited resource
• In the book, reasons 1 and 2 are called Data Synchronization while reason 3 is called Control Synchronization
• While for Data Syncrhronization we use locks, for Control Synchronization we use events (such as ManualResetEvent, AutoResetEvent etc.)
• The nice thing about events, you can wait for any of many or all of many.

All of the above seems pretty obvious so far, but even though I knew all this before, reading the book and writing the notes has helped me to organize the separate facts into a cohesive mental framework. Hope it was helpful for you too.

Enough for now. This has been 77 pages out of 900+ so I’m sure there’s gonna be more interesting stuff to write about.

I really like my Lenovo ThinkPad W500, and I bought it well before Hanselman bought his. The only real issue I have with it is its keyboard. Not the keys themselves (which are pretty nice for a laptop) but rather their location, specifically, the Home / End / Insert / Delete keypad. It’s kind of hard to see at the picture but if you look carefully you’ll see their rather awkward location at the right top corner of the keyboard.

The way I solved this issue is by using a great utility called Key Mapper. It maps keys by adding Registry entries – no need for yet another resident program in your system tray.

As I said in my analysis of my keyboard usage habits, I use Home / End a lot and I like my Delete key not far from my cursor keys. So I figured what I need is to map the Back and Forward keys (the ones above the cursor keys), to Home and End correspondingly. I also mapped my Right Control key to Delete. I may also map the Context Menu key (the one to the left of the Right Control) to Insert, but let’s see if I really need that.

The only trick (and the reason for this post) is getting the mappings to work on Windows 7. As Key Mapper developer says on his blog, Windows 7 dropped support for per-user mappings. Thanks God we still have so called boot mappings which are essentially  per-machine, and Key Mapper does support them. Run Key Mapper as administrator, switch to the boot mappings view (Mappings \  Show \ Boot Mappings), then add your mappings normally and reboot your machine.

IMPORTANT UPDATE: as of October 2009 I don’t use this method anymore as I’ve switched over to free Shrew Soft VPN Client v2.1.5 running directly on my Windows 7 64-bit. Just install it and use File/Import to import your Cisco VPN Client .pcf file (from C:\Program Files\Cisco Systems\VPN Client\Profiles). If that doesn’t work, see this tutorial for detailed configuration instructions. If you don’t have a spare 32-bit system to temporarily install Cisco VPN client in order to get the .pcf file, read on for Windows XP Mode instructions.

As you know, Cisco VPN Client only exists in 32-bit version. As Cisco itself says on its web site, the 64-bit support is implemented only in the brand-new Cisco AnyConnect VPN Client. However, despite its name, AnyConnect will not work with old VPN-Client-compatible VPN servers! Is there any way to run good old 32-bit VPN Client on 64-bit Windows 7?

Luckily for us all, in Windows 7 Microsoft came up with this clever idea of Windows XP mode, which is nothing else but Microsoft Virtual PC prepackaged with image of Windows XP 32-bit SP3. The nicest thing about it is seamless integration between the guest and the host OSes, sort of like VMWare Fusion first pioneered. Thanks to this integration you can install Cisco VPN Client inside the virtual XP machine, and use XP’s Remote Desktop Client directly from Windows 7 to access your remote workstation.

• First, you’ll need new version of Virtual PC plus the Windows XP Mode itself, both available from Microsoft (about ~500Mb download)

• Then, you’ll need the Cisco VPN Client (can’t download from Cisco site, for security reasons, so if you didn’t get this from your NOC department, just google around). Once installed inside the VM, it will magically appear in your Windows 7 Start menu, under Start \ All Programs \ Windows Virtual PC \ Windows XP Mode Applications.

• Finally, in order to run XP’s RDP client you’ll need to manually publish its shortcut from XP to Windows 7. Normally, for a virtual shortcut to appear in Windows 7 you would simply copy it to XP’s C:\Documents and Settings\All Users\Start Menu\Programs but that won’t work for the RDP Client shortcut, because the auto-publishing feature only works for shortcuts pointing to files in C:\Program Files. To work around this limitation all you need is to copy mstsc.exe from C:\Windows\System32\ to C:\Program Files\CopyOfRdpClient\ (we talking about virtual XP C: drive here). You’ll also have to copy RDP Client’s dependencies at C:\Windows\System32\En-us\ to C:\Program Files\CopyOfRdpClient\En-us. Once that is done, simply create a shortcut to the C:\Program Files\CopyOfRdpClient\mstsc.exe in C:\Documents and Settings\All Users\Start Menu\Programs

• You may want to further optimize your workflow by saving RDP Client connection to an .rdp file and publishing that to Windows 7 as well
  

Of course, this is a very simplistic technique. Ideally, you would want to have mstsc.exe running directly on Windows 7 while using XP’s VPN connection. Do let me know if you figure that out.

NOTE: Since Windows XP SP3 includes the new version of the Terminal Services Client, you can use all 6.0 new features, particularly Mstsc.exe /span to enable multi-monitor support!

Today I was prototyping yet another data-driven admin UI using ASP.NET MVC and NHibernate. Naturally, before I could do it my way I had to look around at things like S#arp Architecture (too bloated), Subsonic (didn’t work with my legacy DB), and Ayende’s latest post on the topic (too simplistic). Combining them together produced the kind of design I wanted — very simple and flexible enough. Here’s how. Accessible to absolute beginners, I promise. This post assumes you are familiar with NHibernate and with concept of IoC controllers and that you have your NHibernate entities and mappings all ready and defined (remember, the topic of this post is Hooking Up, not NHibernate 101).

Alright, without further disclaimers, follow on:

1. Download ASP.NET MVC Release
2. Create new ASP.NET MVC project (use File –> New Project, not File –> New Web Site)
3. Download Castle Windsor 2.0, and reference all 4 DLLs in your web project.
4. Download MVCContrib and reference MvcContrib.Castle.dll
5. Download NHibernate 2.1 and reference NHibernate.dll and NHibernate.ByteCode.Castle.dll
6. Reference your assembly with NHibernate mapping HBM files embeded as resources (e.g. Your.Assembly.With.NHibernate.Mappings.dll)

Here’s the code that goes to Global.asax.cs:

using System;
using System.IO;
using System.Web.Mvc;
using System.Web.Routing;
using Castle.Facilities.FactorySupport;
using Castle.MicroKernel.Registration;
using Castle.Windsor;
using Sample.MvcApplication.Controllers;
using MvcContrib.Castle;
using NHibernate;
using NHibernate.Context;

namespace Sample.MvcApplication
{
    public class MvcApplication : System.Web.HttpApplication
    {
        public static IWindsorContainer Container;     // these two don't have to be public
        public static ISessionFactory SessionFactory;  // but I opened them up in case I'll need them somewhere else

        protected void Application_Start()
        {
            //make ASP.NET use castle container to create controllers
            //this way we can inject NHibernate session into controllers

            //create empty container
            Container = new WindsorContainer(); 

            //find all controllers in current assembly and add them to container
            Container.RegisterControllers(typeof(HomeController).Assembly); 

            //tell ASP.NET to get its controllers from Castle
            ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(Container)); 

            //initialize NHibernate from NHibernate.config
            SessionFactory = new NHibernate.Cfg.Configuration().Configure( Path.Combine( AppDomain.CurrentDomain.BaseDirectory, "NHibernate.config"  ) ).BuildSessionFactory();
            //register Factory facility - required for UsingFactoryMethod()
            Container.AddFacility<FactorySupportFacility>();
            //tell container to return SessionFactory.GetCurrentSession() every time ISession is requested
            Container.Register(Component.For<ISession>().UsingFactoryMethod(() => SessionFactory.GetCurrentSession()).LifeStyle.Transient);

            //register MVC routes (standard part of any ASP.NET MVC application)
            RegisterRoutes(RouteTable.Routes);
        }

        protected void Application_OnEnd()
        {
            //dispose Castle container and all the stuff it contains
            Container.Dispose();
        }

        protected void Application_BeginRequest()
        {
            //start new NHibernate session on each web request
            var session = SessionFactory.OpenSession();
            //bind session to the thread so all the code can access it using SessionFactory.GetCurrentSession()
            //this relies on "current_session_context_class" property set to "web" in NHibernate.config
            CurrentSessionContext.Bind(session);
        }

        protected void Application_EndRequest()
        {
            //unbind from the thread
            //no need to close the session as it is already automatically closed at this point (not sure why)
            CurrentSessionContext.Unbind(SessionFactory);
        }

        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                "Default",                                              // Route name
                "{controller}/{action}/{id}",                           // URL with parameters
                new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
            );
        }
    }
}

Add file NHibernate.config and configure it approximately like so:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
  <session-factory>
    <property name="connection.connection_string">Server=XXX;Database=YYYY;Trusted_Connection=False;User ID=AAAA;Password=BBBB;</property>
    <property name="dialect">NHibernate.Dialect.MsSql2008Dialect</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="cache.use_second_level_cache">false</property>
    <property name="cache.use_query_cache">false</property>
    <property name="show_sql">false</property>
    <property name="adonet.batch_size">16</property>
    <property name="default_schema">dbo</property>
    <property name="generate_statistics">false</property>
    <property name="command_timeout">300</property>
    <property name="proxyfactory.factory_class">NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle</property>
    <property name="current_session_context_class">web</property>
    <mapping assembly="Your.Assembly.With.NHibernate.Mappings"/>
  </session-factory>
</hibernate-configuration>

All you need to do now is inject NHibernate ISession into your controllers (this is done automatically by WindsorControllerFactory, just add ISession parameter to controller constructor) and off you go:

using System.Web.Mvc;
using Fortigent.CDI.Common;
using NHibernate;

namespace Sample.MvcApplication.Controllers
{
    [HandleError]
    public class HomeController : Controller
    {
        private ISession db;

        public HomeController(ISession db)
        {
            this.db = db;
        }

        public ActionResult Index()
        {
            using(var tran = db.BeginTransaction())
            {
                var name = db.Get<Customer>(123).Name;

                ViewData["Message"] = "Welcome to ASP.NET MVC! " + name;

                tran.Commit();

                return View();
            }
        }

        public ActionResult About()
        {
            return View();
        }
    }
}

No changes to Web.Config, just compile and run. Like I promised, piece of cake!

Just a summary of the article and a comment from http://www.codinghorror.com/blog/archives/000326.html:

“Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken.”
…
“We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking.”
…
“Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired.”
…
“I think this works in reverse, too – I call it the Disney World Effect. The place is so clean, so perfect, that nobody would dare litter. You’ll see people walk across the street to throw away the tiniest piece of trash. Few people want to be the first person to mess something up.”