You can see some pictures of it in this post

The old kitchen cabinets, including the old sink, was moved into the laundry room at some point, in addition to the laundry sink already there. Behind the cabinet, a few inches away from the wall, is the main waste water pipe for the house.

Beside the stairs there is a central vacuum unit (marked CV). The fuse panel (ELEC) is on the wall behind that, and between the two (not shown) is a vent that comes down and goes under the stairs. At the bottom of the stairs, there is another vent that comes down and was boxed in by wood paneling (That is shown).

The water heater is offset from the furnace because the furnace filter access is on that side, and if the water heater is right beside the furnace the filter doesn’t come out (apparently it was installed that way initially, and then later the hot water tank was moved). In the middle of the basement is a support post.

I should also point out that there are two ducts running down the middle of the basement (about 6.5′ high) from post, to about 1′ from the bottom of the stairs. Because of the post and low ceiling, I didn’t really think the middle area would be useful to be part of the rec room, so that is why in all designs it is part of the laundry room.

So far I have taken down the all the paneling, the wall and all the cabinets that were in the center of the basement, and moved the duct that comes down at the bottom of the stairs.

My objectives for the basement are to have a laundry room, and a rec room area that I can put my desk in and use as an office, and also put a couch and TV in to use as a place to watch movies/TV. So my first design:

In this (and all designs), I am adding 2″ of rigid foam insulation around the whole basement, and then a 2×4 insulated frame on top of that. This means redoing most of the laundry room plumbing to bring it out from the wall, so moving things around is not a big deal. It also means moving the fuse panel for the same reason, which I don’t mind since I wanted to upgrade it to a breaker panel anyways, and add several new circuits for the basement.

I got thinking about it, and started wondering if I could add a bathroom. The house only has a single bathroom (3 bedrooms) so a second half bath could be quite appealing. I came up with a couple of designs, but I don’t know which I like better yet:

The first design moves the central vac from beside the stairs to beside the electrical panel. This shouldn’t be a big deal, and I was going to cut into the central vac lines anyways to add another outlet downstairs.

The second design involves moving the electrical panel about 8′ into the laundry room. I still need to check if this passes building code, and also what exactly I am allowed to do with the mains wiring (eg, do I need to get Hydro to come in and run new mains wires from the meter?). It would of course get boxed in.

Both designs also show an on-demand tankless hot water heater (which can be mounted on the wall, out of the way of the furnace filter door). This lets me move the wall about 2′ closer to the furnace, but I haven’t decided if it makes sense to switch to the on-demand heater yet, due to the high cost (I’m guessing ~$1200-$1500 installed). I probably wouldn’t see the energy savings but I may recoup the costs when I sell the house anyways - maybe tankless systems will be in high demand in 5 years. They’re certainly going in almost every house I’ve seen that was built in the last year or so.

In both designs, the toilet is also relatively close to the main waste line, which means minimal cutting into the concrete to run the waste line. There is also a vent line next to the waste line, which hopefully I can use for the bathroom as well (still need to check code on that).

So I’d love to hear feedback on which design is better (or if anyone has any other ideas).

Using one of the old cabinets that happened to be close to the right size, I built a rudimentary 19″ rack. It’s not too bad for a DIY rack, especially considering a small swing-out metal rack costs around $250.

I basically took an old cabinet, cut the middle shelf out and turned the whole thing on its side. I added another piece of wood from another cabinet on the other end as a mounting location for the rack-mount gear, and I pre-drilled several pilot holes at 1U spacing (to prevent the wood from cracking when putting in screws). I used part of the old middle shelf to build a new shelf to hold my modem, router, VoIP adapter, etc.

I terminated all the cables from the jacks throughout the house onto the back of a 1U 24-port patch panel.

On the main floor I have 12 jacks so far - 2 network + 1 cable in each of 3 bedrooms; 2 network + 1 cable in two separate locations in the living room; 2 network on a wall shared by kitchen/dining room. I probably would have put another jack (and a cable hookup) in the kitchen, except that I plan on doing some major renovations there in the next couple of years, so I’ll just wait, since I don’t need them now anyways.

There are a couple of benefits to using a patch panel for this job. Any “network” jack in the house can be made into either an Ethernet jack, or an analog phone line. Since I use a VoIP PBX at home, I can actually put analog extensions anywhere I’d like, and keep the VoIP adapter in the rack (like the Linksys PAP2 you see on the right). Additionally, I can use PoE injectors (or a PoE switch) and selectively send PoE to ports that need it (eg, have a VoIP phone plugged in).

I can also run different networks to different spots in the house. Most people probably wouldn’t use this, but my main MythTV server (currently in my living room) is also my PBX server, and it has a public IP (VoIP traffic on its own IP avoids QoS issues). I have a hub on my cable modem that splits the connection to the router, and sends another “raw internet” line up to the PBX server (red cable going into the patch panel).

The other end of every connection is pretty simple. I ordered all the keystone jacks, wall plates and patch cables from monoprice.com. The jacks are 1/5 the price Home Depot sells them for, and the patch cables are sold for cheaper than I can buy the parts to make them myself.


Public Sub New() ' Create new object using default storage
Public Sub New(ByVal storage as Storage) ' Create new object using specified storage
Public Sub New(ByVal conditions as String, ByVal parameters() as Object) ' Load an object by the specified query, using default storage
Public Sub New(ByVal storage as Storage, ByVal conditions as String, ByVal parameters() as Object) ' Load an object by the specified query
Public Sub New(ByVal id as Object) ' Load an object by the specified primary key, using default storage


And so on. I like to provide many different ways in the base classes, to 1) make writing the objects that inherit from this as easy as possible, and 2) make writing client code as easy and flexible as possible.

Unfortunately, since you cannot inherit constructors (except for the default New() constructor, if that is specified in the parent..), you cannot do this. You have to define stub constructors in each inherited object which call the parent constructor, which ends up being a whole bunch of copying and pasting, and even more work if you ever change/add a constructor.

Eric Gunnerson posted a blog entry about inheriting constructors, and there is a good discussion on it in the comments. I completely agree with Darren Oakey who suggests that constructors should be inherited if and only if no constructors are defined.

This fits in with the default behaviour of inheriting the empty constructor, and generally is compatible with existing code. The only time it would break existing code is if you have an object with no constructors that inherits from another with a non-default constructor, and you specifically want your inherited object to have the default constructor.


Public Class A
Public Sub New(ByVal value as Integer)
End Class

Public Class B
Inherits A
End Class


In the implementation right now, B only has the default (no parameters) constructor. If this change is made, B will have New(ByVal value as Integer), so existing code that assumes it has no parameters will fail. The fix for this is to explicitly define a constructor for B as:


Public Class B
Inherits A

Public Sub New()
End Sub
End Class


One of the arguments against inheriting constructors seem to be that implicit operations are bad and confusing - however, in my view, having the default constructor implicitly added in the above case is exactly the same thing. Additionally, as is pointed out in the comment thread in Eric’s post, this is also how methods behave. Why should constructors be different?

Another option is to add a class attribute that would allow constructors to be inherited, eg:


<InheritConstructors(true)> _
Class B
Inherits A
End Class


It would really make the language more powerful, and allow writing simpler and nicer code. In a simple example:


Dim cust as Customer = Customer.Load("id = {0}", 123)


becomes:


Dim cust as New Customer("id = {0}", 123)


Since the upstairs is finished, I wanted to disrupt it the least amount possible, so I purchased a 54″ flexible installer’s drill bit. It’s 9/16″ which is big enough for all the cables I’m running. The basic process is to cut out the hole in the wall where the wall plate will go, stick the bit in and drill a hole from inside the wall to the floor below, and then pull the wires back up through.

The bit came with a special tool that goes inside the wall and directs the bit straight down. I had to use this a couple of times when a joist was directly below part of the wall. It also came with a special sleeve that clips onto a hole in the drill bit, grabs the wire, and lets the drill bit act like a fish to pull the wires back up through - very convenient.

I used a low-voltage plastic retrofit box to finish it off. This is easier than a metal retrofit box simply because I’m using keystone jacks and quite a few wires. The retrofit boxes are typically not that big, so trying to terminate several wires, including RG6 coaxial (which is not really that flexible), is easier.

I’m still waiting for all the plates and keystone jacks to arrive, so I haven’t terminated too many of these yet (just a couple to get phones and my media server going). I’ll follow up with a post about the termination later.

The basement is not really finished. In the main area, there is wood paneling, acoustic tile ceiling, and painted cement floor. The laundry area is just bare concrete walls, and has all the old cabinets from the original kitchen.

So the first thing I did was rip the ceiling, panels and most of the old cabinets down.

There is a crawlspace under half of the house, and the only paneling I left was for the door to the crawlspace, as I believe the door will fall apart without it. I will eventually figure out something better.

There was some kind of flower wallpaper paneling around the stairs (think wood paneling, but flower wallpaper instead of the faux-wood). This was glued to the drywall, so removing it left chunks of glue, and missing sections of drywall. There’s probably a way to remove it that wouldn’t have done this, but too late now. I just have to decide if it’s easier to sand and plaster, or just put up new drywall..

I also started taking down the wall between the main area and the laundry room, but ran into a bit of an issue with a cold-air return vent. It goes up beside the main beam, runs through the joists over top of the main air duct, and then down into the main cold air return duct. I think I’m just going to try capping it off, and then adding a new cold-air return on the other side of the basement.

It uses ClickOnce for the installation (because it was really easy to do from VisualStudio), and is pointed at the svn repository for updates - so although I’ve never tried it, the theory is that it will have automatic updates built-in. You can download the install files from the project page linked above.

Of course, UI is hard, far harder than coding for developers. It’s tempting to skip the tough part and do what comes naturally — start banging away in a code window with no real thought given to how the user will interact with the features you’re building.

Remember, to the end user, the interface is the application. Doesn’t it make sense to think about that before firing up the compiler?

I found this particularly interesting and timely in light of the topic being the brunt of a recent April fool’s day joke on The Daily WTF. When I read that post, I actually found it surprising that programmers would think it satirical to consider designing the user interface first. Of course, the rest of the post gets a bit more crazy but I won’t touch that part.

Jeff talks more about the benefits of paper prototyping:

Paper prototypes are usually pitched in terms of doing low-fi usability studies, and rightly so. But I find a paper prototype tremendously helpful even if I’m the only one that ever sees it. I need to create an image in my mind of what I’m building, as it will be seen by the world, before I start pouring the concrete to make it real.

Figuring out the GUI definitely helps you get into the guts of what you need to accomplish in the end, and so it is definitely a helpful task. I think there is another tremendous benefit that to this however: developing a nice user interface.

Okay, so this seems like a less than earth-shattering revelation. Many programmers totally miss the mark on this though. Consider the traditional approach: write a command-line app or hardcode everything in, get the code working, and then write a GUI on top of it to expose to the end user. By doing this, you automatically box yourself into writing a GUI based on your underlying API or database layout.

I think there is a big benefit to taking a step back, totally forgetting about all the underlying API stuff you did, and think up a design for the best possible UI that you can for the problem you’re trying to solve. Pretend you’ll be the one using it every day for the rest of your life.

What you come up with may be totally incompatible with your API; that is okay. In fact, it may even point out fundamental flaws with the way you’ve done things (hence the benefit of the initial paper prototype..). It may work exactly with your code. It may require a translation layer of sorts, to convert what the underlying code is doing to how things are represented in the UI. It may also require compromises in the UI to be able to write a translation layer. All of these are good outcomes though because the end result is you generally have a much nicer UI than you would get if you just stick a pretty face on the raw API.

To use a simple example, consider the Google MyMaps interface. Underneath, the database is storing locations using their latitude and longitude, and assigning a name to them. The ultimate simple interface to this would be:

Of course, what Google actually did makes much more sense - even though it involves a whole lot of code that translates mouse clicks on the screen into map pixel offsets, and then those into latitude/longitude:

In a lot of situations, the success of your software can come down to how nice and/or easy to use the GUI is, regardless of how powerful it is underneath (I’m sure you can think up many examples of this .. perhaps in say, the operating system world). Whether or not you actually design the UI first is inconsequential - ultimately you need to design the UI for the end users, not for the API.

Via BoingBoing

Each user can create a number of stations, and for each of them, you can add artists to it, control how much variety it plays, and rate songs as they play.

An interesting feature is you can search for and play songs on demand - but what happens is it shows songs that are currently playing on other user’s stations, and then tunes you into that station. The song starts at the beginning, but if you continue listening, the next song that plays is determined by the station. In this sense, “stations” are more like dynamic playlists - it’s an interesting concept.
My stations are at: http://www.jango.com/users/3393756. Enjoy!