you've been HAACKED

Interface Inheritance Esoterica

Haacked — Tue, 10 Nov 2009 18:43:13 GMT

I learned something new yesterday about interface inheritance in .NET as compared to implementation inheritance. To illustrate this difference, here’s a simple demonstration.

I’ll start with two concrete classes, one which inherits from the other. Each class defines a property. In this case, we’re dealing with implementation inheritance.

public class Person {
    public string Name { get; set; }
}

public class SuperHero : Person {
    public string Alias { get; set; }
}

We can now use two different techniques to print out the properties of the SuperHero type: type descriptors and reflection. Here’s a little console app that does this. Note the code I’m showing below doesn’t include a few Console.WriteLine calls that I have in the actual app.

static void Main(string[] args) {
  // type descriptor
  var properties = TypeDescriptor.GetProperties(typeof(SuperHero));
  foreach (PropertyDescriptor property in properties) {
    Console.WriteLine(property.Name);
  }

  // reflection
  var reflectedProperties = typeof(SuperHero).GetProperties();
  foreach (var property in reflectedProperties) {
    Console.WriteLine(property.Name);
  }
}

Let’s look at the output of this code.

No surprises there.

The SuperHero type has two properties, Alias defined on SuperHero and the Name property inherited from its base type.

But now, let’s change these classes into interfaces so that we’re now dealing with interface inheritance. Notice that ISupeHero now derives from IPerson.

public interface IPerson {
  string Name { get; set; }
}

public interface ISuperHero : IPerson {
  string Alias { get; set; }
}

I’ve also made the corresponding changes to the console app.

var properties = TypeDescriptor.GetProperties(typeof(ISuperHero));
foreach (PropertyDescriptor property in properties) {
  Console.WriteLine(property.Name);
}

// reflection
var reflectedProperties = typeof(ISuperHero).GetProperties();
foreach (var property in reflectedProperties) {
  Console.WriteLine(property.Name);
}

Before looking at the next screenshot, take a moment to answer the question, what is the output of the program now?

Well it should be obvious that the output is different otherwise I wouldn’t be writing this blog post in the first place, right?

When I first tried this out, I found the behavior surprising. However, it’s probably not surprising to anyone who has an encyclopedic knowledge of the ECMA-335 Common Language Infrastructure specification (PDF) such as Levi, one of the ASP.NET MVC developers who pointed me to section 8.9.11 of the spec when I asked about this behavior:

8.9.11 Interface type derivation Interface types can require the implementation of one or more other interfaces. Any type that implements support for an interface type shall also implement support for any required interfaces specified by that interface. This is different from object type inheritance in two ways:

Object types form a single inheritance tree; interface types do not.

Object type inheritance specifies how implementations are inherited; required interfaces do not, since interfaces do not define implementation. Required interfaces specify additional contracts that an implementing object type shall support.

To highlight the last difference, consider an interface, IFoo, that has a single method. An interface, IBar, which derives from it, is requiring that any object type that supports IBar also support IFoo. It does not say anything about which methods IBar itself will have.

The last paragraph provides a great example of why the code I wrote behaves as it does. The fact that ISuperHero inherits from IPerson doesn’t mean the ISuperHero interface type inherits the properties of IPerson because interfaces do not define implementation.

Rather, what it means is that any class that implements ISuperHero must also implement the IPerson interface. Thus if I wrote an implementation of ISuperHero such as:

public class Groo : ISuperHero {
  public string Name {get; set;}
  public string Alias {get; set;}
}

The Groo type must implement both ISuperHero and IPerson and iterating over its properties would show both properties.

Implications for ASP.NET MVC Model Binding

You probably could have guessed this part was coming. Let’s say you’re trying to use model binding to bind the Name property of an ISuperHero. Since our model binder uses type descriptors under the hood, we won’t be able to bind that property for the reasons stated above.

I learned of this detail investigating a bug reported in StackOverflow. It turns out this behavior is by design. In the context of sending a view model to the view, that view model should be a simple carrier of data. Thus it makes sense to use concrete types on your view model, in contrast to your domain models which will more likely be interface based.

Tags: aspnetmvc, interfaces, cli, model binding

Neat VS10 Feature: Pinning A Debugger Watch

Haacked — Sat, 07 Nov 2009 00:42:53 GMT

I was stepping through some code in a debugger today and noticed a neat little feature of Visual Studio 2010 that I hadn’t noticed before.

When debugging, you can easily examine the value of a variably by highlighting it with your mouse. Nothing new there. But then I noticed a little pin next to it, which I’ve never seen before.

So what do you see when you see a pin? You click on it!

As you might expect, that pins the quick watch in place. So now I hit the play button, continue running my app in the debugger, and the next time I hit that breakpoint:

I can clearly see the value changed since the last time. I think this may come in useful when walking through code as a way of seeing the value of important variables right next to where they are declared. I thought that was pretty neat.

Tags: vs2010, visual studio

A RouteHandler for IHttpHandlers

Haacked — Thu, 05 Nov 2009 00:18:30 GMT

I saw a bug on Connect today in which someone offers the suggestion that the PageRouteHandler (new in ASP.NET 4) should handle IHttpHandler as well as Page.

I don’t really agree with the suggestion because while a Page is an IHttpHandler, an IHttpHandler is not a Page. What I this person really wants is a new handler specifically for http handlers. Let’s give it the tongue twisting name: IHttpHandlerRouteHandler.

Unfortunately, it’s too late to add this for ASP.NET 4, but it turns out such a thing is trivially easy to write. In fact, here it is.

public class HttpHandlerRouteHandler<THandler> 
    : IRouteHandler where THandler : IHttpHandler, new() {
  public IHttpHandler GetHttpHandler(RequestContext requestContext) {
    return new THandler();
  }
}

Of course, by itself it’s not all that useful. We need extension methods to make it really easy to register routes for http handlers. I wrote a set of those, but will only post two examples here on my blog. To get the full set download the sample project at the very end of this post.

public static class HttpHandlerExtensions {
  public static void MapHttpHandler<THandler>(this RouteCollection routes, 
    string url) where THandler : IHttpHandler, new() {
    routes.MapHttpHandler<THandler>(null, url, null, null);
  }
  //...
  public static void MapHttpHandler<THandler>(this RouteCollection routes, 
      string name, string url, object defaults, object constraints) 
      where THandler : IHttpHandler, new() { 
    var route = new Route(url, new HttpHandlerRouteHandler<THandler>());
    route.Defaults = new RouteValueDictionary(defaults);
    route.Constraints = new RouteValueDictionary(constraints);
    routes.Add(name, route);
  }
}

This now allows me to register a route which is handled by an IHttpHandler very easily. In this case, I’m registering a route that will use my SimpleHttpHandler to handle any two segment URL.

public static void RegisterRoutes(RouteCollection routes) {
    routes.MapHttpHandler<SampleHttpHandler>("{foo}/{bar}");
}

And here’s the code for SampleHttpHandler for completeness. All it does is print out the route values.

public class SampleHttpHandler : IHttpHandler {
  public bool IsReusable {
    get { return false; }
  }

  public void ProcessRequest(HttpContext context) {
    var routeValues = context.Request.RequestContext.RouteData.Values;
    string message = "I saw foo='{0}' and bar='{1}'";
    message = string.Format(message, routeValues["foo"], routeValues["bar"]);

    context.Response.Write(message);
  }
}

When I make a request for /testing/yo I’ll see the message

I saw foo='testing' and bar='yo'

in my browser. Very cool.

Limitation

One limitation here is that my http handler has to have a parameterless constructor. That’s not really that bad of a limitation since to register an HTTP Handler in the old way you had to make sure that the handler had an empty constructor.

However, this code that I wrote for this blog post is based on code that I added to Subtext. In that code, I am passing an IKernel (I’m using Ninject) to my HttpRouteHandler. That way, my route handler will use Ninject to instantiate the http handler and thus my http handlers aren’t required to have a parameterless constructor.

Try it out!

I’ve uploaded a sample project to my blog that requires Visual Studio 2010 Beta 2 and ASP.NET 4 Beta 2 to run. However, all the code will work against ASP.NET 3.5 SP 1 except for the SimpleHttpHandler. The RequestContext property of HttpContext is new in ASP.NET 4.

Tags: asp.net 4, routing, IHttpHandler, PageRouteHandler

Html Encoding Nuggets With ASP.NET MVC 2

Haacked — Wed, 04 Nov 2009 05:56:49 GMT

In a recent blog post, I introduced ASP.NET 4’s new HTML Encoding code block syntax as well as the corresponding IHtmlString interface and HtmlString class. I also mentioned that ASP.NET MVC 2 would support this new syntax when running on ASP.NET 4.

In fact, you can try it out now by downloading and installing Visual Studio 2010 Beta 2.

I’ve also mentioned in the past that we are not conditionally compiling ASP.NET MVC 2 for each platform. Instead, we’re building System.Web.Mvc.dll against ASP.NET 3.5 SP1 and simply including that one in VS08 and VS10. Thus when you’re running ASP.NET MVC 2 on ASP.NET 4, it’s the same byte for byte assembly as the same one you would run on ASP.NET 3.5 SP1.

This fact ought to raise a question in your mind. If ASP.NET MVC 2 is built against ASP.NET 3.5 SP1, how the heck does it take advantage of the new HTML encoding blocks which require that you implement an interface introduced in ASP.NET 4?

The answer involves a tiny bit of voodoo black magic we’re doing in ASP.NET MVC 2.

We introduced a new type MvcHtmlString which is created via a factory method, MvcHtmlString.Create. When this method determines that it is being called from an ASP.NET 4 application, it uses Reflection.Emit to dynamically generate a derived type which implements IHtmlString.

If you look at the source code for ASP.NET MVC 2 Preview 2, you’ll see the following method call when we are instantiating an MvcHtmlString:

Type dynamicType = DynamicTypeGenerator.
  GenerateType("DynamicMvcHtmlString", 
    typeof(MvcHtmlString), new Type[] {

Note that we’re using a new internal class, DynamicTypeGenerator, to generate a brand new type named DynamicMvcHtmlString. This type derives from MvcHtmlString and implements IHtmlString. We’ll return this instance instead of a standard MvcHtmlString when running on ASP.NET 4.

When running on ASP.NET 3.5 SP1, we simply new up an MvcHtmlString and return that, completely bypassing the Reflection.Emit logic. Note that we only generate this type once per AppDomain so you only pay the Reflection Emit cost once.

The code in DynamicTypeGenerater is standard Reflection.Emit stuff which at runtime creates an assembly at runtime, adds this new type to it, and returns a lambda used to instantiate the new type. If you’ve never seen Reflection.Emit code, it’s worth a look.

In general, we really frown on this sort of “tricky” code as it’s often hard to maintain and a potential bug magnet. For example, since System.Web.Mvc.dll is security transparent, we needed to make sure that the assembly we generate is marked with the SecurityTransparentAttribute. This is something that would be easy to overlook until you start testing in medium trust scenarios.

However, in this case, the type we’re generating is very small and very simple. Not only that, we only need to keep this code for one version of ASP.NET MVC. ASP.NET MVC 3 will be compiled against ASP.NET 4 only (no support for ASP.NET 3.5 planned) and we’ll be able to remove this “clever” code and have much more straightforward code. I’m looking forward to that. :)

In any case, the point of this post was to fulfill a promise I made in an earlier post where I said I’d give some more details on how ASP.NET MVC 2 works with the new Html encoding block feature.

This is all behind-the-scenes detail that’s not necessary to understand to use ASP.NET MVC, but might be interesting to some of you. Especially those who ever find themselves in a situation where you need to support forward compatibility.

Tags: aspnetmvc, reflection emit

ASP.NET 4 Web Server Here Shell Extension

Haacked — Wed, 28 Oct 2009 04:52:17 GMT

Have you ever needed to quickly spawn a web server against a local folder to preview a web application? If not, what would you say you do here?

This is actually quite common for me since I receive a lot of zip files containing web applications which reproduce a bug. After I unzip the repro, I need a way to quickly point a web server at the folder and run the web site.

A while back I wrote about a useful registry hack to do just this. It adds a right click menu to start a web server (Cassini) pointing to any folder. This was based on a shell extension by Robert McLaws.

Well that was soooo 2008. It’s almost 2010 and Visual Studio 2010 Beta 2 is out which means it’s time to update this shell extension to run an ASP.NET 4 web server.

Obviously this is not rocket science as I merely copied my old settings and updated the paths. But if you’re too lazy to look up the new file paths, you can just copy these settings (changes are in bold).

32 bit (x86)

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\VS2010 WebServer]
@="ASP.NET 4 Web Server Here"
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\VS2010 WebServer\command]
@="C:\\Program Files\\Common Files\\microsoft shared\\DevServer
\\10.0\\Webdev.WebServer40.exe /port:8081 /path:\"%1\""

64 bit (x64)

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\VS2010 WebServer]
@="ASP.NET 4 Web Server Here"
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\VS2010 WebServer\command]
@="C:\\Program Files (x86)\\Common Files\\microsoft shared\\DevServer
\\10.0\\Webdev.WebServer40.exe /port:8081 /path:\"%1\""

I chose a different port and name for this shell extension so that it lives side-by-side with my other one.

Of course, I wouldn’t even bother trying to copy these settings from this blog post since I conveniently zipped up .reg files you can run.

Tags: asp.net, asp.net 4, cassini, webdev.webserver

VS10 Beta 2 From an ASP.NET MVC Perspective

Haacked — Wed, 21 Oct 2009 04:30:10 GMT

You probably don’t need me to tell you that Visual Studio 2010 Beta 2 has been released as it’s been blogged to death all over the place. Definitely check out the many blog posts out there if you want more details on what’s included.

This post will focus more on what Visual Studio 2010 means to ASP.NET MVC and vice versa.

Important: If you installed ASP.NET MVC for Visual Studio 2010 Beta 1, make sure to uninstall it (and VS10 Beta 1) before installing Beta 2.

In the box baby!

Well one of the first things you’ll notice is that ASP.NET MVC 2 Preview 2 is included in VS10 Beta 2. When you select the File | New menu option, you’ll be greeted with an ASP.NET MVC 2 project template option under the Web node.

Note that when you create your ASP.NET MVC 2 project with Visual Studio 2010, you can choose whether you wish to target ASP.NET 3.5 or ASP.NET 4.

If you choose to target ASP.NET 4, you’ll be able to take advantage of the new HTML encoding code blocks with ASP.NET MVC which I wrote about earlier.

As an aside, you might find it interesting that the System.Web.Mvc.dll assembly we shipped in VS10 is the exact same binary we shipped out-of-band for VS2008 and .NET 3.5. How then does that assembly implement an interface that is new in ASP.NET 4? That’s a subject for another blog post.

What about ASP.NET MVC 1.0?

Unfortunately, we have no plans to support ASP.NET MVC 1.0 tooling in Visual Studio 2010. When we were going through planning, we realized it would’ve taken a lot of work to update our 1.0 project templates. We felt that time would be better spent focused on ASP.NET MVC 2.

However, that doesn’t mean you can’t develop an ASP.NET MVC 1.0 application with Visual Studio 2010! All it means is you’ll have to do so without the nice ASP.NET MVC specific tooling such as the add controller and add view dialogs. After all, at it’s core, an ASP.NET MVC project is a Web Application Project.

Eilon Lipton, the lead dev for ASP.NET MVC, wrote a blog post a while back describing how to open an ASP.NET MVC project without having ASP.NET MVC installed. All it requires is for you to edit the .csproj file and remove the following GUID from the <ProjectTypeGuids> element.

{603c0e0b-db56-11dc-be95-000d561079b0};

Once you do that, you’ll be able to open, code, and debug your project from VS10.

Upgrading ASP.NET MVC 1.0 to ASP.NET MVC 2

Another option is to upgrade your ASP.NET MVC 1.0 application to ASP.NET MVC 2 and then open the upgraded project with Visual Studio 2010 Beta 2.

Eilon has your back again as he’s written a handy little tool for upgrading existing ASP.NET MVC 1.0 applications to version 2.

After using this tool, your project will still be a Visual Studio 2008 project. But you can then open it with VS10 and it knows how to open and upgrade the project to be a VS10 project.

What about automatic upgrades?

We are investigating implementing a more automatic process for upgrading ASP.NET MVC 1.0 applications to ASP.NET MVC 2 when you try to open the existing project in Visual Studio 2010. We plan to have something in place by the RTM of VS10.

Ideally, when you try to open an ASP.NET MVC 1.0 project, instead of showing an error dialog, VS10 will provide a wizard to upgrade the project which will be somewhat based on the sample Eilon provided. So be sure to supply feedback on his wizard soon!

Tags: aspnetmvc, asp.net, visual studio 2010, visual studio

Announcing Let Me Bing That For You

Haacked — Sat, 17 Oct 2009 03:51:07 GMT

Despite what your well intentioned elementary school teachers would have liked you to believe, there is such a thing as a stupid question, and you probably get them all the time via email or IM.

You also know that in half the time it takes to type the question, the person pestering you could have typed the query in their favorite search engine and received an answer immediately.

Let me Google that for you addressed this little annoyance by providing a passive aggressive means to tell annoying question askers to bugger off while at the same time teaching them the power of using a search engine to help themselves.

When I first heard about the Microsoft’s new search engine, Bing, I jumped at purchasing the domain name http://letmebingthatforyou.com/ (though I was remiss in not also registering lmbtfy.com as well. If you own that domain, may I buy it off of you?)

Unfortunately, being way too busy caused me to leave the domain name unused gathering dust until I put out a call on Twitter for help. Not long after Maarten Balliauw and Juliën Hanssens answered the call and put together the bulk of this ASP.NET MVC application using jQuery and jQuery UI.

I really like what they did in that the background image for http://letmebingthatforyou.com/ changes daily to match the one on bing.com. I finally found some time to review the code, do a bit of clean-up, fix some minor issues, and test it so I am now ready to deploy it.

Keep in mind that even though I’m employed by Microsoft, this site is a pet project I’m doing on the side in collaboration with Maarten and Juliën and is in not associated with Microsoft nor Bing in any official capacity. We’re just some folks doing this for fun.

Now go try it out and release your inner snarkiness.

Tags: bing, fun

ASP.NET MVC 1.0 Scripts Available on Microsoft CDN

Haacked — Fri, 16 Oct 2009 03:56:02 GMT

A little while ago, Scott Guthrie announced the launch of the Microsoft Ajax CDN. In his post he talked about how ASP.NET 4 will have support for the CDN as well as the list of scripts that are included.

The good news today is due to the hard work of Stephen Walther and the ASP.NET Ajax team, they’ve added a couple of new scripts to the CDN which are near and dear to my heart, the ASP.NET MVC 1.0 scripts. The following code snippet shows how you can start using them today.

<script src="http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js"
 type="text/javascript"></script>
<script src="http://ajax.microsoft.com/ajax/mvc/1.0/MicrosoftMvcAjax.js"
 type="text/javascript"></script>

Debug versions are also available on the CDN.

<script src="http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.debug.js"
 type="text/javascript"></script>
<script src="http://ajax.microsoft.com/ajax/mvc/1.0/MicrosoftMvcAjax.debug.js"
 type="text/javascript"></script>

As ScottGu wrote,

The Microsoft AJAX CDN makes it really easy to add the jQuery and ASP.NET AJAX script libraries to your web sites, and have them be automatically served from one of our thousands of geo-located edge-cache servers around the world.

We currently don’t have the ASP.NET MVC 2 scripts available on the CDN, but that’s something we can consider as we get closer and closer to RTM.

Tags: aspnetmvc, ajax, cdn

Software Externalities

Haacked — Tue, 13 Oct 2009 18:19:14 GMT

If you’re a manufacturing plant, one way to maximize profit is to keep costs as low as possible. One way to do that is to cut corners. Go ahead and dump that toxic waste into the river and pollute the heck out of the air with your smoke stacks. These options are much cheaper than installing smoke scrubbers or trucking waste to proper disposal sites.

Of course, economists have long known that this does not paint the entire picture. Taking these shortcuts incur other costs, it’s just that these costs are not borne by the manufacturing plant. The term externalities describes such spillover costs.

In economics an externality or spillover of an economic transaction is an impact on a party that is not directly involved in the transaction. In such a case, prices do not reflect the full costs or benefits in production or consumption of a product or service.

Thus the full cost of manufacturing includes the hospital bills of those who get sick by drinking the tainted water, the cost of the crops damaged by the acid rain, etc.

Software is the same way. I got to thinking about this after reading Ted’s latest post that Agile is treating the symptoms not the disease where the complexity that Agile introduces is disparaged and Access is held up as one example of a great “simple” way to develop applications.

I agree that Access is great when you’re building a little database to track Billy’s baseball cards. However, the real world doesn’t stay that simple. As the second law of thermodynamics states (paraphrasing here), entropy tends to increase over time, which is something that Ted doesn’t address in his discussion.

I’m all for simplicity in our tools and methodologies as I think we still have a lot of room for improvement in reducing accidental complexity. Unfortunately, the business processes for which we build software are not simple at all and full of inherent complexity. Oh sure, they may start off as a simple Access database, but they never stay that simple. Every business I’ve ever interacted had very complex sets of business processes, some seemingly cargo cultish in origin, which led to major complexity in business processes.

Ted mentions friends of his who’ve made a healthy living using simple tools to build simple line-of-business apps for customers. And I’m sure they did a fine job of it. But I also made a healthy living in the past coming in to clean up the externalities left by such applications.

I remember one rescue operation for a company drowning in the complexity of a “simple” Access application they used to run their business. It was simple until they started adding new business processes they needed to track. It was simple until they started emailing copies around and were unsure which was the “master copy”. Not to mention all the data integrity issues and difficulty in changing the monolithic procedural application code.

I also remember helping a teachers union who started off with a simple attendance tracker style app (to use an example Ted mentions) and just scaled it up to an atrociously complex Access database with stranded data and manual processes where they printed excel spreadsheets to paper, then manually entered it into another application. I have to wonder, why is that little school district in western Pennsylvania engaging in custom software development in the first place? I don’t engage in developing custom school curricula. An even simpler option is to buy some off the shelf software or simply use a Wiki, but I digress.

These were apps that would make The Daily WTF look like paragons of good software development in comparison.

The core problem here is that while it’s fine to push for simpler tools to reduce accidental complexity, at one point or another we are going to have to deal with inherent complexity caused by entropy. Business processes are inherently complex, usually more than they need to be, and this is not a problem that will be solved by any software. Most are not only inherently complex, but chock-full of accidental complexity as well. Your line of business app won’t solve that. It takes systemic change in the organization to make that happen.

Not only that, but business processes get more complex over time as entropy sets in. The applications I mentioned dealt with this entropy and reached a point where the current solution could not scale to meet that new level of complexity (a different sort of scaling up), so they started to drown in it, the original authors of the applications long gone off to create new apps with new externalities.

Fortunately, the externalities of these applications didn’t cause cancer, but rather kept guys like me employed. Of course, it was a negative externality for the company who kept pumping cash to fix these applications.

Ted paraphrases Billy suggesting that Agile requires even more complex tools, story cards, continuous integration servers, etc. This is an unfair characterization and misses the point of Agile. Agile is less about managing the complexity of an application itself and more about managing the complexity of building an application.

A higher principle of agile is YAGNI (You ain’t gonna need it) until you need it. For example, the 1 to 2 guys in a garage probably don’t need a continuous integration server, stand up meetings, etc and any real agilist worth his or her salt would recognize that and not try to force unnecessary procedures on a team that didn’t need it.

However, as the two garage dwellers start to grow the business and need to coordinate with more developers, such tools come in handy. As you grow a team beyond two people, the lines of communication start to grow exponentially, thus creating inherent complexity. Looking at the cost of developing and maintaining an application over time is where you start to get a full picture of the true cost of building an application.

As Robert Glass pointed out in Facts and Fallacies of Software Engineering, research shows that maintenance typically consumes from 40 to 80 percent of software costs, typically making it the dominant life cycle phase of a software project. Thus these so called “simple” solutions need to factor that in, or the customers will continually be left with the clean-up duty while the polluters have long since moved on.

Tags: software development, agile, entropy, externalities

Introducing Mia Yokoyama Haack

Haacked — Wed, 07 Oct 2009 13:57:50 GMT

This morning at 3:17 AM, Mia Yokoyama Haack was born weighing in at 7lb 8.5 oz. Now my world domination crew is complete!

Mia is a fast little one as labor started around 11 PM and she was delivered only four hours later!

This time around, we did a water birth at a birthing center which involves the momma sitting in a big tub for the last part of labor and delivery, which made for a much more comfortable experience than last time. I think she’d definitely recommend it.

We were back home by 6:30 AM which just amazes me. Momma and Baby are doing well. I’m still getting over my cold, but I think the adrenaline of the whole experience helped a lot. :)