DI comes in several flavors, but two of the most common should be mentioned. Constructor injection, in which the class to be instantiated receives all its dependencies as constructor arguments from the DI container, provides a clear declaration of the dependencies of a type. I generally prefer it over setter injection, which makes less clear assertions about dependencies – if the DI container can provide an implementation to populate a property on a constructed object it will, but if it cannot satisfy the dependency, it’s not an error. With constructor injection, all dependencies must be satisfied, or you get an exception. It’s very clear.

There’s a problem with constructor injection, however. When using DI with classes that inherit from a base class that has constructor dependencies, the deriving class must also require those same dependencies. In many cases, these arguments are required solely so that they may be passed to the base class constructor:

public class Base
{
	private ISomeDependency _someDependency;

	public Base(ISomeDependency someDependency)
	{
		_someDependency = someDependency;
	}

	protected void DoSomething()
	{
		_someDependency.MagicHappens();
	}
}

public class Derived : Base
{
	public Derived(ISomeDependency someDependency): base(someDependency)
	{
	}
}

Note that Derived has no use for an ISomeDependency, it’s purely an implementation detail of the base class. Now at some point, after you have fifty or so classes that derive from Base, someone will decide that Base really needs another dependency. Then you’re faced with a hard choice: Go through all your source and update the constructors in all fifty subclasses to take the new dependency that they need in order to invoke Base’s constructor, or give up on DI for that new dependency:

	...
	IOtherDependency _otherDependency;

	public Base(ISomeDependency someDependency)
	{
		_someDependency = someDependency;
		_otherDependency = StaticContainer.Resolve();
	}
	...

Or perhaps equivalently, you start passing the container itself in as a constructor dependency. Either approach hamstrings the testability benefits of dependency injection.

A better approach is for base classes to take a single constructor argument that encapsulates all the dependencies for the base class:

public class BaseDependencies
{
	ISomeDependency SomeDependency {get;set;}
	IOtherDependency OtherDependency {get;set;}

	public BaseDependencies(ISomeDependency someDependency, IOtherDependency otherDependency)
	{
		SomeDependency = someDependency;
		OtherDependency = otherDependency;
	}
}

Now we make Base take only a BaseDependencies parameter in its constructor:

public Base(BaseDependencies dependencies)
	{
		_someDependency = dependencies.SomeDependency;
		_otherDependency = dependencies.OtherDependency;
	}	

We can add new properties to BaseDependencies at any time, and the DI container will provide implementations as we would wish, and our derived classes no longer need to be updated whenever the base class needs another dependency.

	public Derived(BaseDependencies dependencies):base(dependencies)
	{
	}	

Of course the pattern can be extended for deeper inheritance as well – instead of taking BaseDependencies, Derived can take a DerivedDependencies object that extends BaseDependencies. No need to hamstring your DI, no need to update those fifty derived classes.

For example, I had completely missed the importance of ADO.Net data services, which went under the radar as something that was useful only for people who wanted a RESTful interface for developering Silverlight apps. It’s far more than that. In particular, it’s Linq to your data over the web. If you already have an EF model, or a Linq to Sql model, or you care to implement something that looks like one (i.e., has IQueryable<T> properties), you can have a fully queryable web interface to that data, in just a few minutes’ time. As in, “Give me all the Foos with Bar greater than 5 and FooDate sometime in the last week,” and so on.

The speakers varied between adequate and excellent, with more excellent than not. The conference was held at the Mandalay Bay hotel in Las Vegas, and it was well organized. It was my first trip to Las Vegas, and on the whole I’d recommend against hosting a conference there in the future. Too expensive, too hard to get around without a taxi. Mine might be a minority opinion, though. More raucous souls seem to have enjoyed the nightlife there.

Real World Haskell is an excellent book. It covers all the basics, it covers common application development areas such as web, GUI, and database programming, and it covers real world needs like unit testing and performance profiling. It’s worth the price just for the coverage of monads and monad transformers.

A working copy of the book was online while it was being written, and many, many people (self included) contributed feedback along the way, which the authors graciously accepted and used to improve the book. So I had read parts of the book online already before I ever picked up the book in the book store. Still, I was surprised to see how much there was that I hadn’t read before, and also at how much more compelling it was in book form. Even if you’ve read the online version, you might still want to go buy the book.

The authors bring a great deal of knowledge and experience to the work, and I was very grateful for their observations and advice on Haskell software engineering and good style. The book is filled with little flashes of insight, and some very elegant code. If you want to be serious about Haskell, you want this book.

The book did what I hoped it would – gave me a basic understanding of R’s syntax and how to perform common operations. It’s also a slim volume at 217 pages, which is always appreciated. I found myself coming back to it for reference, rereading chapters that I had skimmed and getting more out of it the second time. So on the whole, it’s a good and useful introduction to R. It gave me the necessary footing to go out and explore more on my own. Do beware, however, that some of the examples have typos or other errors. Also, it leaves large swathes of R’s functionality completely unexplored (no discussion of R’s object orientation, for example). Nevertheless, you’ll be well prepared to go out and track down whatever further information you require after reading this book.

We find no sense in talking about something unless we specify how we measure it; a definition by the method of measuring a quantity is the one sure way of avoiding talking nonsense…
- Sir Hermann Bondi

This book was a great read and completely changed the way I think about measurement. It offers many techniques for taking the data you already have and analyzing them in ways that allow you make better decisions. It also teaches you how to evaluate what kinds of additional information would be most helpful to solving your problem, and even put a dollar value on how much it would be worthwhile to spend get that information in order to make a better decision.

Most importantly, it does an excellent job of challenging the basic assumption that some things just aren’t measurable. After reading this book, I feel like there’s always something I can do to help get the information I need, understand my problem better, and make a better decision. I heartily recommend this book.

The “obvious” way to do this, I thought, was to use Assembly.GetExecutingAssembly().Location to find where the assembly lived, use DirectoryInfo.GetFiles() to find the dll and exe files in that location’s directory, and then use Assembly.LoadFile() to load them. This all works just fine in the command line application, but in a web site, there’s shadow copying involved – the assembly returned to you from GetExecutingAssembly isn’t in your Bin folder, it’s in a semi-randomly named folder nesteded several levels deep from your Temporary ASP.Net Files folder. To add difficulty, that one assembly (along with its pdb file, perhaps) is all that’s in the folder. Each of the assemblies in your Bin folder gets copied to a unique folder of its own before it’s loaded into the application, so there’s no easy way to find them all and iterate over them. I didn’t check this, but it’s entirely possible that the assembly isn’t copied at all until it needs to be loaded, in which case even scrubbing through the funny folders looking for assemblies wouldn’t work.

So if Assembly.Location doesn’t work, what does? Something on the AppDomain, perhaps. AppDomain.CurrentDomain.BaseDirectory works for command line apps, but for web sites it gives you the root of the site, not the bin folder. For a web site, the Bin folder is in PrivateBinPath. PrivateBinPath is null for command line apps, though. So it turns out the way to find all your assemblies is by using PrivateBinPath if it’s not null, or else BaseDirectory.

Now that we have a way to find all the available assemblies, what about loading them? If your application is doing shadow copying, you can’t use Assembly.LoadFromFile, since you’re working with assemblies from the Bin folder, but your application is loading them from the shadow copy directories with the funny names, which means if you need a type called “Foo.Bar.Baz,MyAssembly” and you load it from an assembly in the Bin folder, it won’t be compatible with the types that are already loaded in your application, because they were all loaded from different assemblies in the shadow copy folders.

A better way to load them is to ask the AppDomain to Load() them. Get the name from the file, strip the extension, pass it to AppDomain.CurrentDomain.Load(). That way it will load types from the correct assemblies – either from the application directory, or from the shadow copy directories, whichever is correct for your application.

Therefore, I’m changing the focus of this blog. The new focus will be on clarity and simplicity – in thinking, in programming, in life. These qualities are notoriously difficult to achieve, especially in complex systems like software or our own lives. It’s certainly a struggle for me, but one I’m passionate about. I’d like to share the books, techniques, etc. that help me find simplicity and clarity, and invite others to do the same.

The new look of this blog is also a simplification. The first version of my blog worked with software I’d written myself. After some time I had to admit I didn’t have time to both write blog software and write for the blog. So I switched to some content management software, based on the notion that I wanted to build an interesting web site that would require lots of things beyond a blog. I installed a beta version because I thought I’d rather get the latest and greatest, and I’d want to tweak and extend the software, so a developer’s version would be fine. Turns out I didn’t have time for that either. Now, I’m using a supported version of a program specifically focused on blogging, and my focus will be solely on finding and writing good content. Simple.