Swyfft is off and running

For a little over a year, Swyfft, the company I joined last April, has been working to revolutionize homeowners' insurance. And we've got some seriously cool stuff going. Most of it I can't talk about - it's full of algorithms and analytics and patented this-and-that. But the result is straightforward enough: you go to our website, put in an address, and two or three seconds later, get a quote. I think we're the first insurance company to pull this off, and it's very cool.

Of course, a fast quote wouldn't be terribly helpful if it didn't also save people money. And we've got tricks up our sleeve there, too. Naturally, we can't save everyone money: claims are what they are. But Sean Maher, our very smart, nay, brilliant CEO (I'm not above bootlicking), has worked some magic there as well. And we think we can assess the sorts of risks a property is likely to face as well as or better than insurance companies who've had billions of dollars and decades trying.

Our systems, the piece that I'm most intimately involved with, have been more-or-less ready since late last summer. But the business side has taken quite a bit longer: negotiating the contracts, maneuvering through the regulations and licensing agencies, that sort of thing. But we're up and running now, and the response we've seen so far is promising and exciting.

Everyone has to start somewhere, and our initial market is small: coastal Alabama. But that's just the start. As we get initial metrics, and start to increase traction, we aim to be all over the Gulf Coast, and eventually, nationwide.

I love Swyfft, I love what I get to do every morning, and I can't wait to knock the socks off our industry.

Thoughts on Ruby vs C#

I’m about to start in on a new project, and I need to make a decision about what language to get started in. I’ve spent nearly all my career coding on the Microsoft stack, which lately has meant C# and ASP.NET MVC (and several fruitless years on Silverlight, sigh). However, I’ve been spending some time playing with Ruby on Rails lately, to see if I should make the switch. These are my initial thoughts after some investigation – but although I feel reasonably confident about my assessment of the C# side of things, I’m less confident in my ability to assess the strengths and weaknesses of Ruby. So I would be very interested in hearing other folks’ perspectives.

To start with, there are some areas where the RoR ecosystem is hands-down better than anything Microsoft has put together.

1. Getting started. You can get started faster in Rails, largely due to the Rails scaffolding infrastructure.  Nothing MS has really compares to the elegance of the various “rails generate” commands, especially when you consider how they can be extended, i.e., through the Rails Composer. It’s much easier to add flexible functionality to the Rails scaffolding infrastructure than it is to add the equivalent functionality to Visual Studio, and so not surprisingly, more folks have done it.
   
2. Extensibility. Third-party libraries integrate much deeper into Rails than into ASP.NET MVC. The structure of Ruby, its dynamic and open type system, and the dominance of the “convention over configuration” mindset, make a number of tasks much easier, such as adding an authentication or authorization system to an existing website. It's possible to write C# code in such a way that you can make it highly modular, and it's more common to do that these days than it used to be. (The newish ASP.NET MVC system is modular in precisely that way, so that at runtime or for testing purposes, you can replace many of the individual modules.) But you have to work to make it that way: not too hard, but it is work, and there's always the chance the author of the third-party library will forget to make some critical piece modular. And because you have to work with named interfaces, even a universal convention doesn’t give you the same results in C# that it does in Ruby.  For instance, in ActiveRecord, the convention is that every model has an “Id” property, so you can assume that you can check the Id property of any model. You could only do this in C# if every model from every library inherited from a System.Web.IModel interface – which of course isn’t going to happen. This means that it’s a great deal more work to interact with other libraries: you can’t  just assume that there’s going to be a User model with an Id property that you can pull up and talk to. Whereas you can do this sort of thing almost free with Ruby. It's sort of like what you would get if every class in every library in C# were partial and injectable. 
   
   Another way to put it is to say that Ruby (and other dynamic languages) are willing to be wrong. This reminds me of the genius of Tim Berners-Lee when he first created HTML. Other folks had taken runs at it before he did, but they were all hampered by the fact that they had a compilation step, which would ensure that you never linked to a page that didn’t exist. TBL made the wild assumption that you didn’t need to do that: it was OK to be wrong, to link to a page that didn’t exist, and you’d recover from it. This removed the need for a controlling central authority, and thus the web was born. You have the same kind of wild and woolly but incredibly valuable ecosystem growing up around Ruby.
   
3. Gems. Even though C# is still a more popular language than Ruby by most measures, the Ruby community has succeeded in providing an enormous and high quality suite of tools and libraries: larger and generally higher quality than what the C# community has so far succeeded in providing. This may be changing: MS is releasing almost all their new frameworks as open source, NuGet means that it's becoming much easier to discover and keep up with open source libraries, and GitHub has produced a system for managing contributions that even C# guys want to use. But it’s going to take a while for C# coders (and their managers) to come around to the idea that they should be spending some portion of each day contributing to public projects up on GitHub.
   
4. Unit tests. I also really appreciate the ease with which it's possible to write unit tests in Ruby. The flow you can get into with Guard watching which files have changed, running the appropriate tests, and then telling you which things you've just broken, is really cool. And the DSLs for writing mocks in Ruby are much more intuitive and simpler than writing mocks in C#.

There are also a number of ways where the MS ecosystem is pretty closely matched to Ruby. NuGet works somewhat differently from bundler: bundler is more flexible, while NuGet is more foolproof. But having used both, they both seem to get the job done. The same is true of the general MVC architecture, or the ORM's they each use, or the routing specifications, or the asset pipelines, or the rollout and hosting systems. They're all fairly comparable. I'd guess that AWS and Heroku are more mature than Azure and AppHarbor, but without doing a detailed comparison, it's hard to say just how much.

But there are several relevant areas where C# is definitely superior to Ruby.

1. Performance. Even die-hard Ruby aficionados admit this. Any individual routine will run dramatically faster in C# than in Ruby, but beyond that, C# ongoing improvements around the async/await keywords means that it's possible to write highly scalable asynchronous code almost for free. Even if the Ruby community manages to implement some sort of JIT to address the single-threaded performance issues, it seems unlikely that they'll be able to address the overall scalability issues anytime in the near future. There are many websites where this simply isn’t a consideration; but there are plenty of others where it’s still a pretty big one.
   
2. Static typing. I totally get the advantages of dynamic typing and the value it can contribute to an ecosystem. But even so, for writing my own code, I remain a huge fan of static typing.  Like unit tests, it's a great way of catching large classes of errors as early in the development process as possible. (Another way of looking at it is that it's an extension of the DRY principle: you only need to tell the system once how a class needs to behave, rather than repeating those expectations in every class or method that depends on that class.) I wish the C# static typing system was more flexible than it is: it should work more like TypeScript does, which looks at the actual signature of a class rather than at the interfaces it says it implements. That would enable a whole lot of “convention over configuration” in the C# world. But even as it is, I’d argue that C# can catch the same amount of errors with 50% fewer unit tests than Ruby, as the type system catches those errors for you. Since probably half your time in Ruby is spent writing unit tests, that's a significant time savings. This especially becomes noticeable when you've got large code bases that you need to refactor - and that leads into #3.
   
3. Refactoring. It's a little counter-intuitive, but in my experience, statically typed codebases are much easier to change than dynamic codebases. Because the tools understand the structure of the program, those tools can do much of the work for you. To take the simplest refactoring example, if you want to change the name of a field or property, VS will not just guarantee that every instance of “User.Id” gets changed to “User.UserId”, but even more importantly, will also guarantee that no instance of “Organization.Id” gets changed to “UserId”. When you've got hundreds of references throughout your codebase to some field named “Id”, that's a massive time savings. And even if you need to make a change that can't be made automatically (like splitting a class in two), the IDE will tell you the precise lines of code that just broke. There are ways of working around this sort of thing in Ruby, but it involves adding additional levels of indirection around almost everything, to the point where you end up losing the much-touted advantage of dynamic languages of being able to write code fast. In Ruby, the only net you get is the one you write yourself, so you have to spend a lot of time patching holes in that net.
   
4. Visual Studio. Visual Studio is the best IDE around, without question, and that's mostly because it takes full advantage of C#'s static typing. To take just one example, intellisense and code completion is a major help when dealing with large codebases. VS completely understands the structure of your code: it can tell you as you're typing what the possible methods are that you could call, what their parameters are, and use embedded metadata to provide plain-language help, without you ever taking your eyes off the cursor. That's a massive time savings, and Ruby's dynamic nature means that it's simply impossible to do that in the same way, no matter how clever or mature the development environment.

In brief, I get the impression that if you knew both languages equally well, you should choose Ruby if you think the biggest technology challenge is just getting off the ground. I think that someone who knew Ruby and who knew C# equally well could get further along in the first year if they were building the website in Ruby. I also think that after the first year, or as the team grows, you'd probably be able to move faster in C# - and you'd certainly have fewer scalability and performance issues.

The additional data point that I need to consider is that I don't know both equally well. Come September, I suspect I’d have more of a website if it's written in C# than in Ruby, just because I think in C#, I know the tools cold, and it'll take me a while to become that fluent in Ruby. (It's taken me years to become this fluent in C#, so I have my doubts about picking up Ruby as quickly as some folks have said.) There will probably be some period of time after those first three months where I’d have more of a website in Ruby, just because of the additional flexibility and more mature gem ecosystem. But I also think that after a year or so, I’d really start to miss the static typing, refactoring capabilities, and better performance of C#. C# is just inherently better suited to large, complex codebases with significant scalability requirements. (Ruby would simply not have worked for Zango, for instance. I can say that with complete confidence.)

So all of that said, this is a graph of my theory:

Anybody have additional thoughts, or wish to correct any of my assumptions or conclusions?

Various TypeScript Weirdnesses

I’ve been playing around quite a bit with TypeScript lately. I’m no fan of JavaScript – Douglas Crockford is crocked, IMO – so the idea that it might be possible to fix its enormous problems while retaining its real strengths has a whole lot of innate appeal to me. In addition, the fact that Anders Hejlsberg (the genius behind C#) is also behind TypeScript gives the project some immediately credibility.

I also saw an immediate use for it. I’m currently in the process of rewriting Alanta’s API, and during the first two iterations of the API, I struggled no end with getting JavaScript to act like a reasonable, modern language. It’s sort of possible, but given JavaScript’s extremely extensible nature, the potential for the tools to help you the way that they help you in C# or Java (or even C++) is pretty limited. You can force JavaScript into supporting things like inheritance and polymorphism, but it’s not pretty, and it’s easy to make mistakes.

So when it came time to start work on V3 of Alanta’s API, I decided to take the dive, and rewrite it all in TypeScript. I’m a couple thousand lines into it so far, and my initial conclusions have four parts:

(1) TypeScript and the tools around it are still pretty buggy.

Here’s an example. With VS2012 and version 0.8.1 of the TS compiler and tools, try typing this into a TS file:

class A {}
class A extends A {}

It’s nonsense code of course, but it’ll also hang VS2012+TS 0.8.1 hard.

(2) TypeScript still doesn’t have many of the things you’d expect from a modern language.

Generics are the big one here. You can get strongly typed arrays, which is kinda helpful:

class Animal { }
class Dog extends Animal { }
class Plant { }
var animals: Animal[] = [];

// These work
animals.push(new Animal());
animals.push(new Dog());

// This won’t compile
animals.push(new Plant());

But you can’t (yet) do something like this:

class ViewModelBase<TModel> {

    private model: TModel;
    private callbacks: { (model: TModel): void; }[] = [];

    constructor (model: TModel) {
        this.setModel(model);
    }

    setModel(model: TModel): void {
        this.model = model;
        this.raiseNewModel();
    }

    onNewModel(callback: (model: TModel) => void ) {
        this.callbacks.push(callback);
    }

    private raiseNewModel() {
        for (var i = 0; i < this.callbacks.length; i++) {
            this.callbacks[i](this.model);
        }
    }
}

Nor is there support for “async/await”, like the latest release of C#, nor any support for XML Doc or jsDoc comments, or extension methods, or protected methods, or even conditional compilation. And lots and lots of others. But I suspect that most of those will come in time; and of course, with a few caveats, JavaScript doesn’t have support for any of these either, right?

(3) TypeScript has some really weird, unexpected behaviors

This is probably my biggest issue with the language so far. Some of these behaviors are presumably “as-designed”, some might be actual bugs, and it’s not unreasonable to expect that many of them will change before the language is officially released. But they still represent some significant “gotchas” when you’re first getting used to the language as it stands right now.

One example is the weird behavior of the “this” keyword. If you’ve done any web coding at all, you know that “this” in JavaScript refers not to the class in which the method is defined, but to the object to which the method in question has been assigned. Given that JavaScript doesn’t have native support for classes, this sort of vaguely makes sense, but TypeScript is just different enough that you’re likely to get confused all over again.

For instance, take a look at this bit of code below.

class Foo {
    constructor () {
        document.onmousemove = this.showMessage;
    }
    message: string = "Hello";
    showMessage(e?: MouseEvent) {
        console.log(this.message);
    }
}

var foo = new Foo();
foo.showMessage();

Calling “foo.showMessage()” works as you’d expect. But when exactly the same method is called from the “document.onmousemove” handler, “this” gets assigned to the global “document” variable, and as a result “this.message” is undefined. That’s pretty close to how JavaScript acts, but not how “this” behaves in any other class-based language I know of. You wouldn’t normally expect a class method to exhibit entirely different behavior, depending on how it’s called. The workaround for it, by the way, is a tad odd, if handy: just assign the event handler like this:

document.onmousemove = e => this.showMessage(e);

Here’s another example. It turns out that TypeScript has a strange way of initializing methods and fields. Basically, by the time you get around to calling object constructors, you can depend on methods to have been overridden correctly, but you can’t depend on fields. For instance, take a look at this code:

class User {
    constructor () {
        console.log("Field from: " + this.field);
        console.log("Method from: " + this.method());
    }
    field: string = "User class";
    method(): string { return "User class"; }
}

class RegisteredUser extends User {
    field: string = "RegisteredUser class";
    method(): string { return "RegisteredUser class"; }
}

var registeredUser = new RegisteredUser();

In my opinion, it would make most sense to have this output:

Field from: RegisteredUser class
Method from: RegisteredUser class

Failing that, this would at least be consistent:

Field from: User class
Method from: User class

But instead, this is what we get:

Field from: User class
Method from: RegisteredUser class

And of course, that’s not at all intuitive. In looking at the emitted JS, it’s clear why this happens: methods are initialized (i.e., assigned to the class prototype) when the class is constructed, but fields aren’t initialized until the object constructors are called, and those get called in the order superclass->subclass.

var __extends = this.__extends || function (d, b) {
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();
};
var User = (function () {
    function User() {
        this.field = "User class";
        console.log("Field from: " + this.field);
        console.log("Method from: " + this.method());
    }
    User.prototype.method = function () {
        return "User class";
    };
    return User;
})();
var RegisteredUser = (function (_super) {
    __extends(RegisteredUser, _super);
    function RegisteredUser() {
        _super.call(this);
        this.field = "RegisteredUser class";
    }
    RegisteredUser.prototype.method = function () {
        return "RegisteredUser class";
    };
    return RegisteredUser;
})(User);
var registeredUser = new RegisteredUser();

So when you call the RegisteredUser() constructor, the correct methods have already been wired up correctly to its prototype, but the fields haven’t been: so the User() constructor calls the right methods, but doesn’t call the expected fields. That’s understandable when you look at the emitted JavaScript, but not at all intuitive. Basically it means that the same exact field reference in the same method can sometimes be referring to a field from the local class, and sometimes to a field from the subclass, depending on where you’re calling it from. That’s a pretty serious violation of the “law of least astonishment”.

Even more confusing, however, are some weirdnesses having to do with module loading. There are several different ways to handle dependencies between modules. One way is to just specify them at design-time in a ///<reference /> tag. So if you had a User.js file that looked like this:

class User {
    name: string;
    createdOn: Date;
}

You could then have a RegisteredUser.ts file that looked like this:

///<reference path="User.ts" />
class RegisteredUser extends User {
    registeredOn: Date;
}

But then you have to include both “User.js” and “RegisteredUser.js” in different <script> tags on your web page – which isn’t what you want to do if, say, you’ve got dozens of files and you’re trying to provide an API for lots of external users to use and you’re almost certainly going to be refactoring and changing the module names regularly.

The other way is to use named modules. The way you do this is a little odd if you haven’t worked with JavaScript loaders like tiki (which uses the CommonJS format) or curl and RequireJS (which use the somewhat more complicated and flexible AMD format). You’d modify your “User.ts” file by adding an “export”:

export class User {
    name: string;
    createdOn: Date;
}

And then you’d modify your RegisteredUser to import that module, which then acts as a sort of namespace prepending the exported “User” class:

import mUser = module("User");
export class RegisteredUser extends mUser.User {
    registeredOn: Date;
}

Assuming you’re using the AMD format, the compiled code for User.js looks like so:

define(["require", "exports"], function(require, exports) {
    var User = (function () {
        function User() { }
        return User;
    })();
    exports.User = User;    
})

And the compiled code for RegisteredUser.js:

var __extends = this.__extends || function (d, b) {
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();
};
define(["require", "exports", "User"], function(require, exports, __mUser__) {
    var mUser = __mUser__;

    var RegisteredUser = (function (_super) {
        __extends(RegisteredUser, _super);
        function RegisteredUser() {
            _super.apply(this, arguments);

        }
        return RegisteredUser;
    })(mUser.User);
    exports.RegisteredUser = RegisteredUser;    
})

All of those “define” calls look weird, but it basically means that the module loading gets offloaded to (say) RequireJS. But if you want to use any of these classes on a web page, there’s another step you have to go through, which is to require() them on the web page itself, like so:

<script type="text/javascript" src="../Scripts/require.js"></script>
<script type="text/javascript">
    require(['User', 'RegisteredUser'], function (mUser, mRegisteredUser) {
        var user = new mUser.User();
        var registeredUser = new mRegisteredUser.RegisteredUser();
    });
</script>

If you’re used to a nice, clean build and dependency system like C# gives you, all that’s a bit much to wrap your head around. And you have to jump through a few more hoops if you want to give users of your library a decent experience. But it’s not the weird part. The weird bit comes when you start trying to mix all this module loading stuff with interfaces. Specifically, this is  a problem I ran into when I was working with trying to get SignalR working with TypeScript. I had a “Service.ts” file that looked something like this:

///<reference path="../Scripts/jquery-1.8.d.ts" />
///<reference path="../Scripts/signalr-1.0.d.ts" />

interface SignalR {
    roomHub: Service.RoomHub;
}

module Service {
        export var roomHub = $.connection.roomHub;
        export interface RoomHub { }
}

And that worked fine. But then I needed to “modularize” it, so that I could access it from other files, so I added an “export” on the module bit, like so:

///<reference path="../Scripts/jquery-1.8.d.ts" />
///<reference path="../Scripts/signalr-1.0.d.ts" />

interface SignalR {
    roomHub: Service.RoomHub;
}

export module Service {
        export var roomHub = $.connection.roomHub;
        export interface RoomHub { }
}

And suddenly the compiler informed me that “roomHub” wasn’t a member of “$.connection.roomHub”. I’m honestly not sure if this is a compiler bug, or some expected but entirely unintuitive side-effect of modularization. And it took me quite a while to figure out the workaround: to move my interface definitions into a separate file (“ISignalR.ts”):

interface SignalR {
    roomHub: RoomHub;
}

interface RoomHub {
}

And then reference that file from the file that contains the exported Service module:

///<reference path="../Scripts/jquery-1.8.d.ts" />
///<reference path="../Scripts/signalr-1.0.d.ts" />
///<reference path="ISignalR.ts" />

export module Service {
    export var roomHub = $.connection.roomHub;
}

Apparently the rule is something like: if your file exports anything, you can’t have any interfaces in it that extend interfaces that don’t originate in the file with the exports. I’m not sure if that’s precisely it, or if it makes sense to have that requirement – but I can’t seem to make it work any other way. (And trust me, I spent hours trying.)

(4) TypeScript is still way, way better than JavaScript

So TypeScript is very new and fairly raw, with some significant rough edges. But there’s still no doubt in my mind that it’s a much, much, much better language than JavaScript. I haven’t experimented enough with CoffeeScript or Dart to be able to speak intelligently about how it stacks up to those alternatives. But at this point, I really can’t imagine going back to normal JavaScript for web development. Why would anyone? And when it finally catches up to languages like C# (or maybe even brings in some functional features from F#) – man, web development might actually start being fun.

Loading module-specific connection strings in Orchard

At Alanta, we’ve been using Orchard as the platform for our corporate website, with mixed results. I like Orchard’s deep integration with ASP.NET MVC, and with the almost insane flexibility that it provides you as a developer. (Let’s here it for IOC!) But it’s also quite complex, with a pretty steep learning curve, and it still has some real maturing to do in terms of community support, such as themes and third-party modules and what-not. On top of that, it’s designed more as a self-contained CMS, rather than as a general-purpose framework. It assumes, in other words, that pretty much the only database you’ll ever want to talk to is its own; and the only way you’ll ever want to talk to that database is through its own (fairly well-designed) database access layer.

But that approach doesn’t work so well if you’re using Orchard to provide the content, navigation and theming scaffolding around an application that fundamentally needs to talk to a separate database – which of course is what we’re trying to get it to do. In doing this, we’re probably trying to insert a fairly square peg into a reasonably round hole, but it’s where we’re at, so we’ve had to come up with some creative solutions.

One of the first problems we ran into is how to get our custom Orchard module, which of course needs to talk to a separate database, to retrieve the connection string for that database. You can of course put the connection string into the web.config of the module in question and then try to load them the normal way:

_connectionString = ConfigurationManager.ConnectionStrings["AlantaEntities"].ConnectionString;

But that doesn’t work, because ConfigurationManager only reads the global web.config, not the web.config sitting in your module’s directory.

So we initially settled on a compromise, namely, adding the connection string to the global web.config. And that worked, but I wasn’t quite happy. Since we were using a source-code subscription of Orchard for our rollouts, it complicated the build process: we needed to maintain a web.config that was different from the Orchard default, and somehow merge that into our source code rollout. It wasn’t a huge compromise, but it had, if not code smell, at least build smell.

Finally, when we started our switch to Azure, it became imperative to address the problem. I really wanted to be able to run the standard Orchard website install, without having to build it ourselves, with all the dependencies and complexities that introduced. (Among other things, well, we couldn’t get Orchard to run the normal way, as a “Hosted Service”. It kept giving us some weird message, completely unknown on the forums, about an Autofac DependencyResolutionException.) But if we wanted it to run as a website (one of Azure’s new features, still in beta), we didn’t have an easy way to control what goes into the global web.config.

So we did what we probably should have done in the first place: moved our connection strings back into the module’s web.config file. It’s a few extra lines of code to read the connection string, but not difficult once you know the trick:

// Read the connection string from the *local* web.config (not the root).
var fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = HttpContext.Current.Server.MapPath("~/Modules/Alanta.Web.Corp/web.config");
var configuration = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
_connectionString = configuration.ConnectionStrings.ConnectionStrings["AlantaEntities"].ConnectionString;

My favorite C# micro-optimizations #2: 1D Arrays

This is my second post on my favorite C# micr0-optimizations. Everything I said in the first post applies to this one as well, namely, don’t optimize until you know that you need to; and spend most of your optimization budget optimizing the algorithms, rather than figuring out which way to access an array is faster.

That said, this was a surprise to me: jagged arrays (e.g., arrays of arrays) are much faster than rectangular arrays: but indexed access into a 1D array is faster yet.

In other words, this is relatively slow:

   1:  for (int x = 0; x < size1; x++)

   2:  {

   3:      for (int y = 0; y < size2; y++)

   4:      {

   5:          result = twoDArray[x, y];

   6:      }

   7:  }

This is significantly faster:

   1:  for (int x = 0; x < size1; x++)

   2:  {

   3:      for (int y = 0; y < size2; y++)

   4:      {

   5:          result = jaggedArray[x][y];

   6:      }

   7:  }

But this is the fastest:

   1:  for (int x = 0; x < size1; x++)

   2:  {

   3:      for (int y = 0; y < size2; y++)

   4:      {

   5:          result = oneDArray[x * size2 + y];

   6:      }

   7:  }

Benchmark results on my machine (1000 iterations through a 1000x1000 array):

2DArrayTest action completed: iteration = 5, completionTime = 3111, averageCompletionTime = 3101.400
JaggedArrayTest action completed: iteration = 5, completionTime = 2283, averageCompletionTime = 2256.000
1DArrayTest action completed: iteration = 5, completionTime = 1698, averageCompletionTime = 1638.800

It’s also very much worth noting that the order in which the iteration happens is important. Sequential memory access is faster than purely random memory access, most likely because data is fetched from main memory to the CPU’s cache in chunks, so that subsequent sequential reads are from cache.

In other words, if instead of this at the center of each loop:

result = jaggedArray[x][y];
result = twoDArray[x, y];
result = oneDArray[x * size2 + y];

We switch the order of the indexes, so that memory is accessed out-of-order (this is called “diagonal access”):

result = jaggedArray[y][x];
result = twoDArray[y, x];
result = oneDArray[y * size1 + x];

Then the tests take more than twice as long:

JaggedArrayTest action completed: iteration = 5, completionTime = 7499, averageCompletionTime = 7676.400
2DArrayTest action completed: iteration = 5, completionTime = 6790, averageCompletionTime = 6818.600
1DArrayTest action completed: iteration = 5, completionTime = 5862, averageCompletionTime = 5883.200

It’s interesting that in a diagonal access pattern, rectangular arrays are indeed faster than jagged arrays: but one-dimensional arrays are still the fastest.

My favorite C# micro-optimization #1: Buffer.BlockCopy()

So a caveat first-off. Micro-optimizations are evil. You almost never need them. You can live the vast majority of your life as a programmer and never use them; and most of the time you use them, you’re going to use them incorrectly. If your program is running slow, you’ll almost never find some tiny little micro-optimization that will fix it.

But there are times when they’re handy, and with all the work I’ve been doing the last couple years on a custom Silverlight media stack, I’ve had a number of opportunities to learn about how to speed up code that gets called thousands of times each second. This series of articles is the result of that experience.

And my first suggestion is to use Buffer.BlockCopy() when you need to move data in and out of arrays. You don’t normally need to do this very heavily, but when you’re dealing with real-time multimedia, you’ll find yourself doing it all the time, so the faster you can do it, the better.

I mention this because a common way to move data from one array to another is through a for loop, like so:

   1:  for (int i = 0; i < sourceArray.Length; i++)

   2:  {

   3:      destinationArray[i] = sourceArray[i];

   4:  }

Unfortunately, that’s very nearly the slowest way to do it. (Array.Clone() is actually slower, but that’s another story.) A much better way to do it is to use Array.Copy(). Indeed, this is normally the preferred method, since you don’t have to worry about the size of the individual elements, which is an easy place to mess up. Moreover, Array.Copy() works for arrays of any type, instead of just intrinsic value types.

   1:  Array.Copy(sourceArray, 0, destinationArray, 0, sourceArray.Length);

But as it turns out, Buffer.BlockCopy() is slightly faster for many operations, since it doesn’t have to perform certain checks at the beginning of the copy:

   1:  Buffer.BlockCopy(sourceArray, 0, destinationArray, 0, sourceArray.Length * sizeof(short));

Benchmark results on my machine (10 million copies of a 64-element short[] array):

Buffer.BlockCopy action completed: iteration = 5, completionTime = 420, averageCompletionTime = 422.000
Array.Copy action completed: iteration = 5, completionTime = 478, averageCompletionTime = 482.600
forLoop action completed: iteration = 5, completionTime = 1092, averageCompletionTime = 1093.000

That said, the difference between Array.Copy() and Buffer.BlockCopy() tends to disappear the larger the amount of data to copy (while a for loop falls further and further behind). If you’re copying 64,000 elements instead of 64 elements, these are the results:

Buffer.BlockCopy action completed: iteration = 5, completionTime = 1251, averageCompletionTime = 1229.000
Array.Copy action completed: iteration = 5, completionTime = 1254, averageCompletionTime = 1218.200
forLoop action completed: iteration = 5, completionTime = 11063, averageCompletionTime = 11082.200

But there’s one significant caveat: if you only need to move a few elements, even the minimal overhead of Buffer.BlockCopy() can be too much. If you need to move less than 32 elements, you’ll probably find that a straightforward for loop (or perhaps an unrolled version of it) is the fastest. Of course, you’ll want to do your own testing to find out where the break-even point is. But here are my results with 1,000,000 copies of a 16-element array:

Buffer.BlockCopy action completed: iteration = 5, completionTime = 367, averageCompletionTime = 363.800
Array.Copy action completed: iteration = 5, completionTime = 418, averageCompletionTime = 420.000
forLoop action completed: iteration = 5, completionTime = 291, averageCompletionTime = 290.000

Fast (approximate) Sqrt method in C#

As part of the video codec that Alanta uses, we need to calculate the variation between blocks in one frame and the equivalent blocks in the next frame. I’ve been using an algorithm proposed by Thiadmer Riemersma that looks something like this:

public static double GetColorDistance(byte r1, byte g1, byte b1, byte r2, byte g2, byte b2)
{
    int rmean = (r1 + r2) / 2;
    int r = r1 - r2;
    int g = g1 - g2;
    int b = b1 - b2;
    int weightR = 2 + rmean / 256;
    const int weightG = 4;
    int weightB = 2 + (255 - rmean) / 256;
    return Math.Sqrt(weightR * r * r + weightG * g * g + weightB * b * b);
}

It works pretty well, but that last step depends on a square root calculation, which is relatively slow; and when this is something you need to run on every pixel in a frame, you want it to be as fast as possible. Consequently, I’ve been looking at ways to optimize it.

The important thing to note is that for my purposes, close is good enough: I don’t need IEEE precision. It turns out that there’s a pretty good approximation that’s available in languages like C or C++ which let you do unsafe casts back and forth between ints and floats:

float sqrt_approx(float z)
{
    union
    {
        int tmp;
        float f;
    } u;
    u.f = z;
    u.tmp -= 1 << 23; /* Subtract 2^m. */
    u.tmp >>= 1; /* Divide by 2. */
    u.tmp += 1 << 29; /* Add ((b + 1) / 2) * 2^m. */
    return u.f;
}

The problem with this approach is that C# doesn’t normally let you play this kind of magic.

The key word being “normally”, of course.

Turns out there’s one trick you can use to make C# treat the same memory address as either an int or a float, and that’s to create a struct with a [StructLayout(LayoutKind.Explicit)] attribute. (And surprisingly enough, the trick works in Silverlight as well.) The resulting class looks like this:

public class Approximate
{
    public static float Sqrt(float z)
    {
        if (z == 0) return 0;
        FloatIntUnion u;
        u.tmp = 0;
        u.f = z;
        u.tmp -= 1 << 23; /* Subtract 2^m. */
        u.tmp >>= 1; /* Divide by 2. */
        u.tmp += 1 << 29; /* Add ((b + 1) / 2) * 2^m. */
        return u.f;
    }

    [StructLayout(LayoutKind.Explicit)]
    private struct FloatIntUnion
    {
        [FieldOffset(0)]
        public float f;

        [FieldOffset(0)]
        public int tmp;
    }
}

The results are pretty good: it’s more than twice as fast, and the results tend to be within 2% of the “real” answer:

MathSqrtTest: averageCompletionTime = 2424.000
ApproxSqrtTest: averageCompletionTime = 1058.000
Average variation: 0.0253587081881525

If you want a bit more accuracy at the cost of an additional CPU cycle or two, you can use this one, based on the famous inverse square root method in Quake 3:

public static float Sqrt2(float z)
{
    if (z == 0) return 0;
    FloatIntUnion u;
    u.tmp = 0;
    float xhalf = 0.5f * z;
    u.f = z;
    u.tmp = 0x5f375a86 - (u.tmp >> 1);
    u.f = u.f * (1.5f - xhalf * u.f * u.f);
    return u.f * z;
}

It’s a tad slower than the first (though still nearly 2x as fast as Math.Sqrt()), but much more accurate:

MathSqrtTest: averageCompletionTime = 2428.400
ApproxSqrt2Test: averageCompletionTime = 1361.000
Average variation for method2: 0.000928551700594071

URL Rewriting Module Interferes with WCF REST Service Processing

I spent most of yesterday and a good chunk of this morning troubleshooting a problem with a WCF REST service I’ve been trying to create.  Specifically, I had a brain-dead simple WCF service that looked like this:

    [ServiceContract(Namespace = "AjaxRoomService")]
    public interface IAjaxRoomService
    {
        [OperationContract]
        [WebGet(ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped)]
        string SayHello();
    }

The implementation looked like this:

    public class AjaxRoomService : IAjaxRoomService
    {
        public string SayHello()
        {
            return "Hello";
        }
    }

And the actual .svc file looked like this:

<%@ ServiceHost Language="C#" Debug="true" Service="Alanta.Web.Services.AjaxRoomService" Factory="System.ServiceModel.Activation.WebServiceHostFactory" CodeBehind="AjaxRoomService.svc.cs" %>

Note that I was using the WebServiceHostFactory, so I didn’t need to have anything in my web.config file.  Simple, right? Everything should have worked, right?  But when I tried to call the service (i.e., by navigating to http://localhost:51150/Services/AjaxRoomService.svc/SayHello), I consistently received a 404 error.

I did my standard Google searches, but all the issues people described had to do with running the service in IIS, and I wasn’t even getting that far: I was just trying to get this running under Cassini, in Visual Studio. 

But after much troubleshooting and more than a little swearing, I finally put my finger on it.  We’re using a simple URL rewriting module that shouldn’t have been interfering with this, but it was.  The trouble was in this particular line of code in the URL rewriting module:

HttpContext.Current.RewritePath(rewrittenPath);

A debugger showed that it was rewriting the path from “/Services/AjaxRoomService.svc/SayHello” to “/Services/AjaxRoomService.svc/SayHello” – in other words, it wasn’t making any changes.  But as soon as I changed it to only rewrite the path if the path had actually changed, my problem went away:

// Only rewrite the path if the path has changed, as otherwise it interferes with .svc request processing.
if (string.Compare(HttpContext.Current.Request.Path, rewrittenPath, true) != 0)
{
    Debug.WriteLine(string.Format("Rewriting {0} to {1}", HttpContext.Current.Request.Path, rewrittenPath));
    HttpContext.Current.RewritePath(rewrittenPath);
}

Not exactly a dramatic discovery, but I figured it might benefit someone else at some point, so I’ll toss it out there for the Google indexer to discover, in the hopes that it helps someone else someday.

Genetic Engineering and our Dependence on Technology

I haven't done enough reading in the ethics of genetic engineering to have any real sense for the issues that are being discussed in that field. But I've been thinking this thought for a while, and I've never actually heard it addressed, so I thought I'd toss it out.

One of the things that people worry about with human genetic engineering is that we'll be mucking with our gene pool in artificial ways, a prospect most people find unsettling for reasons that aren't generally specified, and perhaps aren't specifiable.

I don't know what the right answer here is, but one thing that should be noted in any discussion of human genetic engineering is that we're already mucking about with our gene pool in ways that are obvious once they're pointed out. The 20^th century advances in medical technology have allowed lots of people to survive who would previously have been weeded out of the gene pool.

Lest I appear hard-hearted, let me hasten to point out that I'm one of these: I've had trouble with my ears all my life, I've had numerous surgeries to (partially) correct these problems, and I've been told by various doctors that were it not for these surgeries, it's quite likely that the mastoiditis which has given me such trouble would have eventually spread to my brain. In addition, I have a susceptibility to strep throat that, were it not for modern antibiotics, would probably have had me pushing up daisies some years ago. I'm very grateful that I'm not now six feet under, but from a genetic, evolutionary perspective, folks like me are precisely the problem. A hundred years ago, a set of genes like mine would have died out before they could get passed on, with the result that the next generation wouldn't have to put up with these problems. But these days, because of our dependence on technology, problematic genes are getting passed on routinely, ensuring that the next generation will be even more dependent on technology than we are today.

I should note that this particular tendency has been observed in other settings. According to Fred Lanting, wild dingoes are almost completely free of hip dysplasia: natural selection ensures that this particular trait doesn't get passed down. But a colony of wild dingoes bred in captivity for 40 or so years (without the pressure of natural selection) showed that a "substantial portion" of the captive dingoes suffered from hip dysplasia. I can't think of any reason why the same thing isn't happening to human beings.

I can't swear that this analysis is correct, though it makes sense to me. I don't know how quickly our gene pool is degrading, but it seems likely that it is in fact doing so, and that it's just a matter of time before the vast majority of human beings will be all but incapable of surviving without significant technical assistance. Entropy always tends to increase, Newton said, and without the pressure of natural selection, the entropy inherent in the human gene pool will increase more quickly than we expect.

Assuming for the moment that this is accurate, what are our options here? None of them sound particularly appealing, but for very different reasons.

1. We can continue down the current path, letting the human gene pool deteriorate, constantly supplementing its decline with increasingly sophisticated "external" technologies (such as surgery, antibiotics, artificial limbs and organs). In a dozen or so generations, the human race would be nearly cyborg in reality, if not appearance.
   
2. We can address the problems in our gene pool by letting survival of the fittest take its course. This isn't really even thinkable, of course: if we can help someone with medical problems, we're morally obligated to do so.
   
3. We can address the problems in our gene pool through genetic engineering. Presumably this wouldn't be through "eugenics", but through appropriately targeted gene therapies. The practical problems are many, of course: we don't have words to describe just how complex the human genome really is. We're at least decades and maybe even centuries away from being able to diagnose and fix the sort of "minor" genetic problems that I suffer from, let alone the sort of body sculpting you read about in science fiction novels. But there is at least one theoretical advantage: once we fix a particular problem, it will more-or-less stay fixed: the fixed genes will automatically get passed on to the next generation. If we ever get the technology figured out, we could presumably fix the decline of the human genome.

Not many folks are really passionate advocates of this last approach: human genetic engineering is a technology perched atop a rather slippery slope. It's not real likely that we'd be able to stop with "fixing the decline": as Ellul pointed out, technology that can be used almost certainly will be used. If we have the ability to give our children (never mind ourselves) super-human intelligence, super-human strength, or greatly extended lifespans, I think we certainly will.

But even if you don't buy the idea of a normative human nature (which I think I do), nobody really likes the idea of their genetic makeup being deliberately and specifically programmed by someone else. Written well before genetic engineering became a possibility, I think C. S. Lewis' Abolition of Man is nevertheless a fairly accurate prophecy of what will happen if we aren't very careful with these technologies. If we can meddle with our descendants' intelligence, will we also choose to meddle with their sense of morality? On what basis would we do so if we're convinced that morality is just a combination of social and evolutionary pressures? From this perspective, what would constitute a better or worse morality, and on what basis would we decide?

"If any one age really attains, by eugenics and scientific education, the power to make its descendants what it pleases, all men who live after it are the patients of that power. They are weaker, not stronger: for though we may have put wonderful machines in their hands we have preordained how they are to use them… The last men, far from being the heirs of power, will be of all men most subject to the dead hand of the great planners and conditioners and will themselves exercise least power upon the future…. Man's conquest of Nature, if the dreams of some scientific planners are realized, means the rule of a few hundreds of men over billions upon billions of men." (The Abolition of Man, pp. 68-69)

But as morally ambiguous as the third option is, I know of even fewer people who would be advocates of the first or second.

I'm not here trying to decide which of these approaches is the right one. I don't like any of them. But if I have any contribution to make to the argument, it would be to point out that the debate isn't about "genetic engineering" in the abstract. It's a choice between various unpalatable options: we have to pick one of these three. There is no neutral choice.

Ellul Critique #3: The Information Age Changes the Impact of Technique

This is a continuation of my series reflecting on Jacque Ellul's The Technological Society. I promised to write up what I felt to be some of the weaknesses of his method; this is the third.

Ellul was writing before the information age: he consistently thinks of the requirements of Technique in a manner analogous to technology and corporations as they existed in the 1950's. That's not exactly his fault, of course: mistakes which to us are obviously or even ludicrously wrongheaded may be quite understandable, though of course, they remain mistakes. His emphasis that Technique requires centralization (pp. 193ff) is one example of this. Nobody who lived through the PC revolution of the 1980's and the resulting death of the mainframe would ever assert with Ellul's certainty that "the idea of effecting decentralization while maintaining technical progress is purely utopian" (p. 194). The way you get computers to do what you want is dramatically different from how you get a drill press or a filling machine to do what you want. You still use Technique, of course, but you use it in very different ways, and it has dramatically different ramifications for those who use it. Many of the conclusions that Ellul draws, not to mention the arguments that he makes or the reasons that he adduces, are simply inapplicable to the economics of information or to the techniques of information management.

To take just one example, one of the great creations of the Information Age has been the job of computer programmer. As I put it in a previous posting:

"I sometimes marvel at how certain gifted engineers are able to work with computers, and the artistry they exhibit as they create beautiful and elegant solutions to the difficult problems I bring them. It makes me wonder if a silent, hidden capacity has existed throughout time inside at least some human beings, an aptitude which lay dormant through millennia of evolution and social change, until the day when Univac was unveiled, and the potential became actuality. To this small class of people, to live in an age prior to computers must have been something like living in a remote tribe which had lost all ability to speak; and turning on their first computer would have had all the glory and the wonder of Adam naming the animals."

If you aren't a computer programmer yourself, it's easy to miss the fact that programmers are first and foremost aesthetes. A great deal has been made about programming as an expression of the will to power, and there's certainly something to that claim. But from my own experience, programming and working with programmers for the better part of two decades, I think the primary motivation is something closer to beauty. Remember that, virtually by definition, a programmer who is writing code is trying to solve a problem that nobody else has ever solved before. If the problem has been solved before, the economics of computing mean that the cheapest, most efficient way to solve it is generally to use that person's code: writing code is hard. So if you're forced to write code to deal with a particular problem, it generally means that nobody has ever solved that problem before. For this reason, the act of programming is akin to meditation, an active response of Thought to the problems presented by an external world. When a programmer has completed (at least for the moment) a module or program, and has done it well, the resulting satisfaction goes beyond any simplistic sense of "a job well done"; it's closer to how an architect would feel contemplating one of his creations, or indeed, the way that an author feels when reading a particularly well-crafted sentence. It is true that Technique these days penetrates into even the heart of beauty and art, but it's equally true that art and beauty have penetrated into the very heart of Technique.

To be clear, I think the Information Age changes Technique both for better and for worse. For all the information Google puts at my finger-tips, it encourages me to think superficially about issues, to treat knowledge lightly, as a commodity, rather than with the respect that it's due. In addition, it introduces an entirely new problem, a vastly expanded "commons" whereby the "tragedy of the commons" can play out, with our attention as the commons, and advertising by fair means or foul as the Technique by which it is exploited.

Ellul Critique #2: Technique Doesn’t Work for Wicked Problems

This is a continuation of my series reflecting on Jacque Ellul's The Technological Society. I promised to write up what I felt to be some of the weaknesses of his method; this is the second.

"Wicked problems" are variously defined, but in effect, they're problems that you can understand completely only after you've solved them. You can get the idea by pondering what it would take to solve the Israeli-Palestinian conflict, or to create a genuine artificial intelligence. There are two key things to note about wicked problems: (1) they're everywhere, and (2) pretty much by definition, Technique doesn't work for them. This necessarily limits the power and scope of Technique, and carves out a realm where other phenomena can still function with some degree of autonomy. You can see how this works if you look at a classic wicked problem, how to write the best tax code. On p. 269, Ellul claims that "there is an optimum tax structure which can be completely determined," and that Technique will invariably force us to find and implement this structure. Yet 50 some years later, politicians in the US are still arguing about taxes – and any tax structure which might conceivably be viable in the US is dramatically different than what you would find in Europe. Indeed, due to the wildly differing philosophical presuppositions which underlie the debate, this is an area where there is very little agreement at all.

Similarly, Ellul describes (pp. 341ff) with great confidence the growing ability of psychology to accurately predict human behavior and, more disturbingly, allow technicians to control it. However, my experience with ad campaigns and, specifically, with the use of multivariate testing algorithms to select the best landing pages, leads me to believe that both Ellul's confidence and his worries are excessive. Determining the landing page that will give you the most conversions is a fairly simple and very well-defined problem, even if it has certain "wicked" elements to it. The most sophisticated approach involves assessing the attractiveness of different options within different page elements, using complex, multivariate statistics to overcome the astronomic number of combinations involved and predict the best combination of elements. At Zango, over the years, we tried this approach with at least three different companies, with precisely zero success. People simply didn't behave the way that the statistical models told us they'd behave; and even when they did, for a given page, it was nearly impossible to translate those learnings to the hundreds of other landing pages we needed to optimize. And this was for a very simple, very localized, very well-defined problem, with millions of data points available for analysis. Certainly advertisers, television executives, and movie producers have found a myriad of ways to manipulate us, and they're reasonably good at it. But it's still more art than science, more gut than technique. Who could have predicted the success of Nike's Just do it slogan? Or Apple's astonishingly simple "Hi I'm a Mac" ads? There's Technique there, sure, but there's a whole lot more creativity than Technique.

Here's another example. When an Internet company wants to maximize lifetime revenue from their audience, the standard technique is to split the audience up into "sample groups", and treat each of those sample groups differently (say, by showing them a different page when they visit your site). You then measure the "lifetime revenue per user" from each of those groups, and when you determine which of the sample groups has the highest lifetime revenue, you begin treating all your users the same way you treated those users. Google and Microsoft, those ancient adversaries, use this technique all the time. Back around 2000, when Google was just beginning its rise to power, both MSN and Google were trying to figure out how best to monetize their users. An insider from MS told me that the folks over at MSN decided to test showing ads on the MSN search page, and they tested it by dividing up the users into sample groups, and showing each sample group a different number of ads. Well, it turns out that the sample groups showed almost no difference in user lifetime, but the sample group which had the most ads had the best lifetime revenue. So MSN started showing a whole bunch of ads on their home page. And of course, why not? But the interesting thing is that Google ran the same tests, with the same sample groups, and they came up with the same results. But Google recognized that a sample group couldn't test everything: for instance, it couldn't test whether a user ended up referring friends to the site because it was so cool. So Google made the choice – against every advice that Technique could give them – not to show ads on their home page. In other words, unlike Microsoft, Google recognized that user retention was a "wicked problem", with counter-intuitive solutions. Of course, there are many reasons why Google has beaten Microsoft at search, but this recognition that not everything can be solved with Technique is a very big part of it.

Ellul reviews the various options which may stand in the way of Technique (morality, popular opinion, social structure and the state), and concludes that nothing in contemporary society is likely to stand in its way (pp. 301-318). But he ignores the entire class of problems that Technique simply can't address, and that calls his fundamental thesis into question. If Technique, by definition, has nothing to say to huge areas of human experience, it seems less of a threat than Ellul makes it out to be.

I suspect that it's only been in the last few decades – well after Ellul wrote – that we've come to recognize the nature and existence of wicked problems. The many futile attempts to create a general-purpose artificial intelligence have been highly enlightening in this regard. (See Hubert Dreyfus' What Computers Still Can't Do.) So it's perhaps understandable that Ellul could have repeated this claim:

"Jungk even claims that in the United States, on very advanced technical levels, unchallengeable decisions have already been made by 'electronic brains' in the service of the National Bureau of Standards; for example, by the EAC, surnamed the 'Washington Oracle'. The EAC is said to have been the machine which made the decision to recall General MacArthur after it had solved equations containing all the strategic and economic variables of his plan. This example, which must be given with all possible reservations, is confirmed by the fact that the American government has submitted to such computing devices a large number of economic problems that border on the political." (p. 259)

In the 1950's and 1960's, there was a fairly widespread assumption that the problems of artificial intelligence would be quickly solved, as evidenced by the tendency to call them 'electronic brains'. Still, this perspective seems absurdly naïve, and even though Ellul repeats it with "all possible reservations", the fact that he thought it worthy of repetition in any form shows just how badly he misunderstood the limitations of Technique. Certain problems are just not susceptible to technical solutions.