So Long and Thanks for All the Sugar Water

If you are a bee keeper reading this then I'm sure you know where this post is headed. If not, let me briefly explain what happens when a bee colony decides it has outgrown its current facilities and wants to look elsewhere for other arrangements. 

When starting a hive, as my wife and I did this past summer, it is very important to check on the little critters at least once per week - which unfortunately my wife and I did *not* do this past summer. In our defense, we were very well intentioned but we just had way too much going on. Even though we had the benefit of attending 'bee school' provided by the local Bee Keepers Association (which I would highly recommend to anyone interested in getting started with their own apiary), I figured that even though they were a little neglected, they were being fed and seemed active so all was good. Wrong. I had only installed the lower hive with frames and had just recently finished assembling the next 10 frames to put in the second hive body but had not put it out yet. 

Well, one day in early June I came home from work and saw a frightening sight. Now, I knew there were a lot of bees in the hive - some 12 or 13,000 - but it wasn't until I saw most of them in a huge clump on the side of the hive that I really got the full effect. I was witnessing a swarm. Now, a swarm is not what the name has come to imply from horror movies. Rather, it just means that they had outgrown their current space and were ready to pack up and move. 

When bees swarm, they send out a small bunch of explorers to find a new location. When they find it, they signal back to the rest of the colony which is waiting patiently in a big ball and they relocate taking their queen with them. When this happens with bees in the woods or elsewhere, you might find them dangling from a tree limb. 

So now here I am faced with this swarm of bees. I had to work quickly, so I ran in the house to tell my wife and we jumped into the bee suits, opened up the hive and literally dumped the bees back into the hive. You would think that they would have just flown off at that point, but it seemed at the time that we had caught it just in time. 

Unfortunately there's not a happy ending to this story. Our hive did not survive the summer. While it seemed that through July and August the bees were reproducing and staying active, we never did find our queen. The only thing that we could think of is that either the queen had in fact flown off with a good portion of the colony, or somewhere along the way we (or the other bees) had killed her. We'll never know what really happened, but it turns out the bees were reproducing, but without a queen. We had a condition wherein the worker bees start laying eggs instead of the queen. Eventually the colony will die off when this occurs.

The upside to this whole thing (if one can be found) is that my wife and I learned the hard way some very useful stuff about bee keeping including how to check for a queen cell, the right way (and wrong way) to remove frames from the hive without squishing anybody along with the simple hands-on inspection of the hive. We plan on attending the bee school sessions again this winter and trying again in the spring with a new colony. At least now we've got all the equipment ready to go this time around. Here are some pictures of the hive taken prior to the mass exodus...

Mvc Framework Model Binders

In the preview 5 version of the asp.net mvc framework they introduced the ModelBinder. The team at my company actually started a very similar implementation for use with nHibernate. Unfortunately, it - like the project - never really took off. So along comes the mvc framework and the ModelBinder. Preview 5 supports built in support for basic binding, but allows you to build your own custom binding. 

As I mentioned in a previous post, I'll be a little different and post this example using vb.net code. Truth to be told, I prefer C#, but there seems to be a real lack of vb.net examples so far. 

To add custom binding/serialization support for your custom class it needs to implement IModelBinder. There's only one required method to implement which is GetValue() in which you take the form from the controllerContext.HttpContext.Request object and map the fields to your class. Here's a sample:

<modelbinder(GetType(fedloanrule))> _

Partial Public Class FedLoanRule

  Implements IModelBinder
  
    Public Function GetValue(ByVal controllerContext As System.Web.Mvc.ControllerContext, ByVal modelName As String, ByVal modelType As System.Type, ByVal modelState As System.Web.Mvc.ModelStateDictionary) As Object
  Implements System.Web.Mvc.IModelBinder.GetValue

        Dim request As HttpRequestBase = controllerContext.HttpContext.Request
        Dim rule As FedLoanRule = New FedLoanRule()

        rule.LoanType = request("LoanType")
        rule.LateDisbInterval = Integer.Parse(request("LateDisbInterval"))
        rule.MaxCombinedDepLoan = Integer.Parse(request("MaxCombinedDepLoan"))
        rule.MaxCombinedGradLoan = Integer.Parse(request("MaxCombinedGradLoan"))
        Return rule

    End Function
End Class

When an instance of a FedLoanRule is passed into my controller action, GetValue is called first. This would be useful if you had some special mapping that had to be done since it takes the mapping code out of your save/update code. In this simple case it would seem that it would have been easier just to call TryUpdateModel(). But this is good for an example. 

When the code gets into the controller action, the updated object instance is there and ready to use. Here's the catch. As of the Preview 5 version (I say that because the beta was just released),  this only seems to be useful for creating new records. If you want to do an update, even though your object is bound to the form prior to reaching your controller action, once in the controller action the Model does not see that anything has been changed. You have to retrieve the object from the model, make your change and then you can do the update. If you just call SubmitChanges()  on the object that is passed in from GetValue(), nothing is submitted. 

While it's cool functionality, it doesn't seem to make a whole lot of sense to have separate methods for inserting new records - a scenerio in which the model binder does work - and for updating existing records. 

Hey, this is still preview code and I've yet to try out the beta. Somebody else brought up this point on ScottGu's blog. And he mentioned that it might be addressed in the beta. 

ASP.Net MVC Framework

We've been using the new mvc framework at my company since the Preview 2 version. For those who are keeping score the beta was released about a week ago. I've been fortunate to have been able to work on projects that have spanned the evolution of this framework and had to upgrade a couple so I thought I'd share some of the highlights.

Let me state for the purpose of full disclosure that I've only been doing web development for about a year and a half though I've been an application developer for over 10 years now. But it's been a very full year and a half as I've been very fortunate to work for a company that embraces new technology. 

First of all, the mvc framework, certainly not a new idea having been around for some time, is a relief from having to deal with web forms. One of the biggest headaches of trying to incorporate javascript, for example, in a web forms app was having to use the ClientId property of html elements and pass that id back to the server rather than just using the id that I assign. This illustrates what seems to be the key feature that one would look to when considering switching development frameworks. With web forms the focus is on the server processing. Anytime you want to do client side processing you'll more than likely have to do some work around / hack to get it to work. It's not so much that the mvc framework gives you new functionality that web forms doesn't. It's the fact that you don't have to fight tooth and nail to get simple things to work. 

For example, take any web forms application and view the source of a page. You'll find all the nasty looking element ids that are auto generated along with html that, if you were the developer, would leave you scratching your head wondering where it came from. Now take that same page written using the mvc framework and you'll see ... wait for it ... yep, pretty much the same html that the developer wrote. You have control of every single tag that is written. 

Here's another gem. You have a datagrid control and you want to include a checkbox column. And to each checkbox you want to assign a custom attribute. Go ahead and try it. I'll wait. Hopefully when you get back here you won't have pulled out all your hair after you notice that each checkbox is enclosed in a span tag and your custom attribute is not assigned to the checkbox, BUT TO THE SPAN! Somebody with more experience please explain that to me. That same exercise using the mvc framework involves either using the Html.Checkbox helper function or just simply writing the input tag yourself and assigning whatever attribute you want. I'd call it What You Write Is What You Get. And while the world certainly doesn't need another acronym, if you try saying WYWIWYG a few times you'll soon be reverting to an Elmer Fud voice and rolling on the floor as I am right now. 

Excuse me.

Ok, I'm back.  If you want further information regarding the mvc framework, I'd check out Scott Guthrie's blog. One thing that does seem to be lacking, at least for now, is a good set of VB.Net examples. I say this because I'm currently working on an application for a client that requires VB.net and having heavily relied on example code to learn this new framework, I spent a lot of time trying to convert some of the features. Admittedly, though, much of the difficulty in conversion was dealing with LINQ and not specifically the mvc framework. I'll post some of the more interesting examples another time. 

Getting Started in Beekeeping

My wife and I took a shot at beekeeping this past summer and had some mixed results. We started by attending 'bee school'. The RI Beekeepers Association sponsored the session that we attended and I have to say it was very interesting. The class met once per week for about 10 weeks and by the end we had the knowledge (and contacts) necessary to get started. 

We hooked up with someone who regularly goes down south to get what are called installation packages. This is basically just a small box with about 10,000 bees in it and 1 queen. The queen is kept in a small wooden box with a couple of attendants in there with her. More on that later. We got our bees around the end of April. I have to admit I was a little freaked out driving home with 10,000 bees in the back of my truck. Fortunately, it was an uneventful ride home.

When we got them home, my wife and I put on the bee suits (which look strikingly similar to hazmat suits), opened up the empty hive and dumped the bees into it. There were still some left in the box, but we just left it opened in front of the hive. They found their way in eventually. Next, we took the queen box and gently placed it in the hive. What is supposed to happen is that the queen is protected inside the box. If she wasn't in there, the other bees would kill her. The purpose of the box is to allow the queen to gradually get introduced to the rest of the colony. The queen box has a little hole in the top which is plugged up with a piece of hard sugar. Over the course of about 3 days, the queen's attendants eat through the sugar so that by the time they are free, the queen should be acclimated to the rest of the colony. 

That's it. Pretty simple. I'll post some more regarding some of the more interesting things that we encountered in our little experiment.