Joseph Bulger IV

I’m trying out a new product Microsoft is releasing on the web called Hohm.  It’s a web site dedicated to tracking your energy expenditure and cost, so that you can reduce your energy consumption and also save you some cash along the way.

How does it accomplish this?  It profiles you and your house.  It asks you some basic (and some not so basic) information about your house and your energy habits.  The cool thing is you can choose to fill in as much, or as little, as you want.  No pressure.  However, the more information you can give it the more accurate the reports will be.

Other cool things include the ability to track your energy bills through an automated feed.  This has to be set up with your utility company(ies), but if they offer it, then it’s a quick way for Hohm to get a lot of information about your energy consumption.  I live in Homestead, FL, and as of today they haven’t set up any of the providers here.  I’m hoping they will in the future so I can submit them my data feed and get some real data to project.

I’m really using it as a way to try and save money primarily.  If it works out I’ll be writing a success story on it at a later date.

I’ve discovered a product that I really enjoy using and thought I would share it.  It’s called Balsamiq Mockups and it’s a tool that you can use online or on your computer for drawing up quick ideas on software systems.  They use a sketchy kind of font to give you that “drawing out a spec” feel.  What really makes the product so appealing is how fast you can build up a simple mock to show to your team.  I’m literally able to sit down at my computer and within 5 minutes have a meaningful mockup of some kind of feature I want to convey.  Really powerful stuff.

Here’s an example of the kind of thing you can build with it.

Balsamiq Demo

I’ve been unexpectedly suprised by the longevity of my BlackBerry Curve.  I’m coming up on my 2 year mark, and it’s still operating the same as it was when I bought it.  I think that’s the first phone I’ve had that I can say that of.  That’s also not for lack of use, either.  I’ve really beat the heck out of this phone.  The only issue I’ve come across is the ball will get sticky every now and then and it won’t respond to movement.  There’s a simple remedy, though.  All you have to do is move around the ball with a damp cloth.  After you’ve done that for a bit, let it dry and you should be able to use the ball again.  I’ve had to do this about 4 times, because my son, Isaac, get’s a hold of the thing and get’s some funk on it.

All in all, very pleased with my BlackBerry.

I’ve been having a lot of problems with my coding lately. I primarily program in C#, but I originally came from a C++ world. When I first learned Java, and was introduced to the idea of Single Inheritance, the sales pitch made a lot of sense to me. How can any class really derive from multiple classes? I drank the kool-aid, and I’ve been living in a Single Inheritance world ever since.

Now, the caveat to all of this was that you had this thing called an interface that actually allowed you to define declarations of behavior that could later be implemented. This could be done any number of times. This also made a lot of sense, and they would do some simplistic model that illustrates the concept. I imagine for purposes of this article we should probably illustrate something as well just to drive home the point. Let’s say you have a Coin. A Coin is a kind of Currency. So the simple inheritance chain would dictate that Coin inherits from Currency, and everything is fine. Of course, in order for this to matter at all, there needs to be some benefit to having Coin inherit from Currency. So let’s say that Currency has some behavior called CalculateBuyingPower that actually figures out what kind of buying power that particular Currency has. Ok, so now we have an inheritance chain, and we have a direct benefit, figuring out the buying power of the Coin.

If that’s as far as you take it, then everything’s all fine and dandy, and Single Inheritance is great. The problem is, that in the Real World, what we call Objects can legitimately “be” multiple things. This is equally true in the Software World. So, going back to the Coin, not only is the Coin a Currency, but the Coin is also a MetalConstruct. A MetalConstruct is just my way of saying something that is made of metal. Why do I care? Simple. At some point during the life of a Coin, it is entirely possible that the buying power of the Coin will reach a point that it would actually be better to melt down the Coin because the value of the Metal in the coin is much higher (look at what a penny is made of nowadays and you’ll see what I mean). Now, a lot of you are going to say, “That’s fine, just define a MetalConstruct interface and you should be good to go.” In a lot of cases that might be true, but in this example we fine a very big problem. The point of the MetalConstruct is to normalize the behavior of melting down the Coin. No matter what kind of MetalConstruct you have, the melting process for it is always going to be the same. Sure there are variations in melting temperature and what not, but the overall process is the same. The point being, that an interface can only declare that behavior MeltDown should exist, but not define the implementation of it. This is the problem with Single Inheritance. I now need a way for the Coin to be both a Currency and MetalConstruct, which provides the Coin with behaviors CalculateBuyingPower and MeltDown. Coin shouldn’t have to define how to do either of those behaviors, because that’s not it’s responsibility.

During software development, when you’re working on defining your domain, this can come up quite often, actually. With the advent of extension methods in .NET, you’re able to ease the pain a bit in C#, but the fundamental problem is really still there. What I would like to see would be one of two things. It would be nice if you could inherit from multiple abstract classes, which would allow you to define Contracts at the abstract class level. Another idea would be to bring forward the construct of a contract as a first-class citizen, it would be similar to an abstract class and an interface in the sense that you could not create one directly, but would allow for definition of behavior while still being able to have a class implement numerous contracts. It would be a totally new way of defining an object, apart from class, struct, or interface entirely perhaps.

So now I’m looking back at C++ and I’m thinking it would be really nice if I had Multiple Inheritance so I can just get past this ridiculous wall I’m having to climb. Possibly with .NET 4.0, Microsoft is bringing forth the idea of Code Contracts , which might help when you’re trying to get around Single Inheritance issues when dealing with Design by Contract, but for real domain model issues, I think the problem still remains.

Food for thought.

My church’s band has done this AMAZING thing by producing an album that people can buy and ALL proceeds go to helping people in Cambodia. 

Specifically, this is an excerpt from their site:

By purchasing this album, you will be added to this partnership and will in turn help provide clean water, build a village, build a health clinic, and create education opportunities for the people of Cambodia, Southeast Asia, and other locales.

Now, any one who reads this that knows me knows I wouldn’t be writing this unless it was completely legit and worth your time and effort.

So if you’re like me and you have a hard time trusting in organizations to do some good, but would like to know where a good place to do some charity would be, this is it.

http://thesaturnproject.com/

If anyone has any questions feel free to contact me directly.  I will be glad to spend the time talking to you and directing you to the right people.

Take care!