Archive for January, 2008

Testing Windows Live Writer

January 31, 2008

I don’t like writing in the spare white textbox in WordPress. Hopefully Windows Live Writer will be easier.

SQL queries can be as efficient as stored procedures

January 29, 2008

For posterity, here’s the link. You have to write your queries carefully to minimize recompilation.

Realistic historical return of the Dow Jones

January 29, 2008

Though stock markets around the world have crashed, many will argue that the historical return of the DJIA is pretty good and we shouldn’t worry about one bad year. But they compute the average annual return for a far longer period than most investors will actually invest in the market. That is, computing the average over 50 years is silly since most investors are only invested for 10 or 20 years. The chart below shows the average annual return if you had bought and held the DJIA for 10 or 20 years. So if you bought it 20 years ago and sold this month, your annual return would be 9.5%. The chart demonstrates that those who sold in the 70s and 80s would have seen less than a 5% annual return. Factor in the ridiculous inflation rate and they actually lost money. So the very long-term historical return is meaningless. Instead, we are hoping to be in a lucky 10 or 20 year period of phenomenal growth like the 90s. 

DJIA Historical Return

Use AppDomain recycling for reliable systems

January 28, 2008

ASP.NET does it, so why not you? There are two reasons restarting an AppDomain is useful for a reliable .NET server program. First, the only way to change the assemblies loaded into your AppDomain is to restart it. This allows you to upgrade a program quickly without taking it completely down. Though you should probably have the inputs buffered somehow to deal with your program being offline for a split second. Second, when your program inevitably breaks, it is useful to simply restart the program rather than fail. If you design your program so major subsystems are in their own AppDomain, then you can have a master program that monitors their health and restart those that fail. Erlang does this for their processes.

The way to do this is to use .NET Remoting. The entry point into your subsystems will likely be a class factory that inherits from MarshalByRefObject. Then you write a master program that creates a new AppDomain (AppDomain.CreateDomain) and accesses the factory class (AppDomain.CreateInstanceFromandUnwrap). When the AppDomain needs to be restarted, unload it (AppDomain.Unload) and reload it. Remote method calls across the AppDomain barrier are very fast. The hard part is designing a program to use this technique effectively.

DSLs and extension methods

January 11, 2008

I ran across this presentation on building library APIs that feel like a domain specific language. An example from his slides:

calendar.add("dentist").from(fourPM).to(fivePM).at("123 main street") ;

The method calls look like an English sentence. In fact, this looks at lot like LINQ’s API style. With extension methods, one can add these methods to any existing class to make a more readable API. Read on for some code to implement 4.Hours().FromNow() and 2.Hours().Ago() using extension methods. Someone could add an entire vocabulary for simple transformations on time.

static class TimeHelpers    {
     public static TimeSpan Hours(this int i) {return TimeSpan.FromHours(i);}
     public static DateTime FromNow(this TimeSpan t) {return DateTime.Now.Add(t);}
     public static DateTime Ago(this TimeSpan t) {return DateTime.Now.Subtract(t);}
}

Security lessons from Qmail

January 10, 2008

Qmail is a secure alternative to Sendmail. This paper summarizes some lessons learned from 10 years of development.

  • Eliminate bugs: duh!
  • Eliminate code: less code probably means fewer bugs.
  • Eliminate trusted code: Run most of your code in a tight, secure runtime environment (i.e. .NET with limited CAS). Concentrate bug fixing effort on that tiny little bit of code that still needs to be trusted.
  • Don’t just chase attackers: Most security work is patching holes found by attackers. These are merely symptoms of insecure code. In addition, devs must focus on the root cause of these security holes.
  • Minimizing privileges doesn’t solve the problem: Work on fixing bugs, not just minimizing damage when bugs are exploited.
  • Don’t obsess about performance: A small slowdown is better than insecure software