Using Blog Engine .NET

So I decided to use Blog Engine .NET for the foundation of this blog, I suspect I'll move to something homegrown when I start putting together a product oriented site, but for now it certainly scatches the itch.

So what did I think of it?

It's an excellent blogging solution out of the box, the only things I did that I disagreed with were mostly matters of opinion in such things as urls and I could have changed this since it's open source.

It's only when I wanted to create my own theme that I started to run into problems. For a number of the pages the html generation was all over the place, a crazy mixture of strings in the code behind, generation of html dom (new HtmlTable() etc) and in the aspx file itself. Overall this slowed me down in altering the look and feel, and for some pages I gave up entirely. The ajax on the contact us and comments pages seem very fragile as well.

In conclusion, for out of the box functionality it's great, for altering the look and feel it'll require quite a bit of untangling and time investment to get it right.

At some point I'll invest time into MVC and Silverlight as a learning exercise and see what I can do myself (all programmers think they can do everything better), but for me it's balancing "Not Invented Here" against having a real world example to learn a new set of technologies.

Encountering the Solution before the Problem

I read a post a few weeks ago about feeling the pain of some software development practises including such things as untestable code and tight coupling. I'd really like to post a link to it however Google Reader search isn't at all helping in helping me re find it. But first some history.

I feel like I'm in that position now, during my previous employment I encountered during my R&D a lot of what's now labelled as ALT.NET practises such as Dependency Injection containers, NHibernate, TDD andDDD . These practises really resonated with me and since I was leading the development of a new product I was a in good position to get to grips with some of them (I still have trouble with test first development) with mixed results (another post).

Coming back to NZ and slotting into my old position I started with a lot of enthusiasm for bringing my team "into the light" and sharing what I thought was a better way to build applications. Our company is marketing services based so the web sites we build can vary from the small brochure sites up to fully integrated e-commerce applications (very very bespoke). In hallway discussions with other programmers I talked about some of what I had learnt and encountered mixed reactions.

The overall impressions I received were that since our team had not encountered some of the pain that these patterns solve then their perceived value was lessened. I also feel some of the pain our team has felt could be caused by these but attributed elsewhere (the functional spec is always a tempting scapegoat).

Our client's domains do not have huge dramatic shifts (I can only think of one counter example) so the pain of tight coupling isn't as strong. Without having to develop different implementations of services for unit testing or having the domain implement core service interfaces lessens the pain of not having dependency injection.

While I still believed that these practises could helpful for us to use I needed to think differently about they should be approached and the seminal question. What to do when you encounter the solution before experiencing the pain of the problem?

In practise we do this all the time, we build our solutions on top of other solutions, we use frameworks, libraries and patterns, all proven solution for time old problems, we certainly don't reinvent the wheel every time.

I'm finding now there needs to be a bit of mix, the pain needs to be there, but only in small doses. Create the problem yourself, show a bit of pain, and then "solve it".

A good example is right now I'm building some simple content management capabilities into our core framework. Part of which is some routing based off the newMVC Routing engine (another post). Due to the pages (and the page repository) being part of the domain my core services are programmed against interfaces (IPage and IPageRepository). Obviously these need use so we have a simple "RepositoryLocator" as this pattern of usage grows and starts to become unwieldy I'll introduce a container such as Windsor or Unity to reduce the pain.

In short, I think some developers really need to encounter a problem before the value of the solution is perceived, but if we can do this in a controlled fashion then everyone wins.

Entity Framework

So there's been a lot of commenting back and forth at the moment concerning the new Microsoft Entity Framework and especially the "vote of no confidence" by members of the Alt.Net and DDD communities. This I can understand, the current EF certainly doesn't meet any of their requirements for a toolset or framework.

The EF team looks to have taken some of this criticism on board and the Entity Framework Design blog gives some good indications we could end up with an excellent toolset.

The bastard step child in all of this is LINQ to SQL, certainly all the attention is on EF and as Ian Cooper says "I would like to see a commitment from the Data Platform team to stop its focus on talking LINQ to SQL down as a RAD tool and tallking up its advantages for use in the OO approaches to software development." I'd like to see this as well. For small to medium projects this could an excellent foundation, I'd love to see it opened up by the Data team, the provider model for it is mostly there, hidden away under internals and sealed classes.

On a personal note, I'm still hunting for a product idea, my brain seems to overly critical at the idea phase. I'm currently working on common libraries for my work and I'll share some of the ideas that come out it soon. I'd like to polish of the LINQ to SQL repositories and building it into a business framework.

Back in business

Wow, that took a lot longer than expected. Vodafone took every single day of their "up to three weeks for your broadband to be connected". In the last few weeks I've taken up my new job and am settling in fairly well. Part of the new job entails evaluating new technologies (more so than I usual do) for use within the company. After reading over the Entity Framework I have mixed feelings.Visual designers are always pretty much as many have people have pointed out they scale terribly, the strongly typed querying via LINQ, but hopefully that can come to libraries such as NHibernate soon. The lack of implicit lazy load is also really annoying.

In my opinion the EF designer should only map the relationship between the conceptual and the data models. Not generate the conceptual model, this tightly couples them and designer generated code is always a pain in the ass to extend (partial classes only alleviate some of this pain). The post DP Advisory Council gives me a lot of hope in this regard.

Over the week or so I'll outline the project I'd like start to build in my spare time and hopefully share some of it with you in the same vein as MVC Storefront by Rob Connery. Probably not via screencasts, but a product built from the ground up.

More on var

 I've started playing with Resharper 4.0 and one of the first things I noticed was that it recommends using var for local variables, there's a great post at "Varification -- Using Implicitly Typed Locals" about their perspective on it. It's interesting reading and given me a lot to think about. The second note that it "induces" better named variables is interesting, it instantly remind me of the debate about TypeMock, and how that other mocking frameworks "induce" better designs