Joel Hainley

Well amazingly enough the hot water side of the plumbing replacement project went off without a hitch. I replaced all of the lines, hooked up the water heater and opened it up and there wasn’t a leak in the entire system. This means one of two things : 1. I got lucky. 2. I finally have a handle on soldering water pipes. I’m going to go with the latter until there is convincing evidence to the contrary.

This completes the first phase of this project. The second phase is to redo the plumbing up in the wall behind the shower, and then to put in a new bathroom sink, toilet, floor and to refinish the bathtub itself. I will probably also spend some time and retile the shower. Thankfully tomorrow I have a mountain bike ride scheduled with the fellas so the shower is going to have to wait another day or two before it gets some love.

On Friday night I had enough.  I have been dealing with a mostly useless shower for the better part of 4 years, coupled with bad water pressure everywhere in the house I decided it was time to do something about it. Time to replace all of the water pipes in the house. About 4 years ago I had replaced all of the kitchen lines with copper piping but the majority of the house was still running on galvanized lines. Galvanized pipes seem to do only one thing, get clogged and fail. So I decided it was time to bite the bullet and switch everything over to copper.

So Friday afternoon with very little ceremony and absolutely no fanfare I shutoff the main water in the house. I pulled out the sawzall, a couple of pipe wrenches, and a large dose of optimisim and started to demo the cold water pipes in the house.  Before I went to bed I had the cold water side removed from within the house.

Saturday morning I just had to deal with going back up the main water supply line until I found a logical place to tie into things. So I get up in the morning, make a pot of coffee ( stole water from the neighbors hosebib ) and got to digging. By 1pm I had a list of the major stuff that I needed so it was off to Home Depot to spend some money on parts.

The rest of Saturday was spent running cold water pipes back into the house, changing the flow of a couple of lines to make it easier to do repairs in the future. I went to bed mostly discouraged that I hadn’t made faster progress but at least things were moving along. Sunday I got up and continued working on the cold water side. I was almost done when I realized that I needed a pipe cutter that would fit close to a wall. Another trip to Home Depot and I had the cold side done. I turned on the water slowly and except for 1 small leak, it held. ( I eventually had another small leak appear after a few hours, but that was easily fixed ).

I learned one thing that has been very useful, if you put water into a system and then you have to solder it, the best thing to do is to get all of the water out of the pipes before you start soldering again. If you have water in those pipes it will never get warm enough to melt the solder. I was able to siphon the water out of one side, and the other time I had to use some pressurized air, but I was able to get it all out and get things buttoned up very neatly.

On Sunday afternoon, I started on the hot water side, I made fair progress but an overlooked part and general weariness ensured that I wasn’t able to get things done on Sunday. Having cold running water is better than having no water, and it shouldn’t take too long to get the rest of the hot water system done.

The water pressure on the cold water side is amazing, I don’t recall the water EVER running that well in the house. With this done, I guess you could say that the cold water system was optimized? Hopefully reusing the same pattern on the hot water side will have the same results.

Shad, a fellow developer and good friend, and I were hiking a great new loop I found in Mt. Diablo State Park the other day and after solving the rest of the world’s problems we eventually came around to talking about things that were driving us nuts in our current projects. We both had recently found ourselves with code that was initially a quick and dirty library with a “Button 1″ interface. ( You know the type, programmer’s make them. They have a single command button on them and you click them and then they do stuff..and never notify you when they are done, and don’t resize and a host of other things that a normal UI should have ). These “Button 1″ quick and dirty apps have a nasty habit of turning themselves into indispensible tools for production/operations stuff.

The big problem we were both having was that while the apps were decent enough for their initial use we were being asked to extend them and both of us wanted to do some refactoring of the application before we released them into the wild. The best approach for this sort of thing is to develop unit tests so that, once refactored, we could be sure that we hadn’t broken anything important.

The biggest problem with dropping unit testing into an application after the fact is that sometimes you run into problems where you have to refactor just to get the unit tests access to all of the routines that you want to test. This isn’t an ideal situation, as you quickly end up wondering if you are breaking things just trying to get some unit tests built that are supposed to ensure you aren’t breaking anything. So you start wondering if instead of refactoring if you simply make functions that wrap your private functions and expose the behaviour might be the answer, pretty soon you have stuff everywhere and you wonder which is your testing code and which is your unit testing code to make all of this possible. Madness.

As we dropped off of the fire trail back into a heavily wooded area with a nice creek, it came up in conversation that perhaps partial classes were the way to go. If you haven’t used c# partial classes, you will. You can write class code in multiple files and yet at compile time it is assembled into a single logical unit. Several days later I had some free time and was able to verify that this would indeed work, I could drop all of my unit testing code into a single file that would provide all of the unit testing logic and wouldn’t muddy up the existing class. Furthermore, with a couple conditional complilation statements I could get rid of all of the unit testing code from the final release of the new library.

This is obviously not the approach you want to take if you can avoid it. It is arguable that you do not want your classes invaded in such a way for the purposes of unit testing. This is something you can work around if you use unit testing from the beginning, but what if you inherit a project and it doesn’t have any unit test capabilities built into it? What if the way that the classes are structured make unit testing pieces of the application difficult? Do you just plow forward and hope for the best? I hope not, and hopefully this stop gap measure to get unit tests built into the classes so that you can test existing functionality is the way to go. With these “nunit partials” in place you should be able to then start refactoring the rest of the application to be a little bit better structured for unit tests without having to risk dropping anything.

I met with a company recently about doing some work for them. During the meeting one of the UI developers let me know that they were using xhtml in strict mode.  Now I have to admit it has been a while since I looked at xhtml and I’ve never actually done anything with the strict variant before. So I got a little curious and decided to spend some time and see what it was all about.

I pulled up the xhtml specification the next day and read through it. The name “xhtml strict” kinda hints at what you would expect to find and it does a pretty good job of living up to its name. It’s a very precise way of working with xhtml, it doesn’t allow you to “get away” with sloppiness, it requires that all attributes must be quoted, all tags must be well formed, and closed properly, attributes must be lowercase, you can’t have “name” attributes they are all id attributes and a bunch of other things like that. My initial impression was that this doesn’t seem that arduous, it’s simply a way of enforcing a convention upon a document. .

In order to see how it stands up in the “real world” I decided that I would update hamtesting.com to be xhtml 1.1 strict compliant just to see what sorts of things a developer could run into while working in this environment. Below are some of my thoughts about the process.

My initial efforts at getting all of the templates into shape went pretty quickly in about 45 minutes I was able to get all of the main site templates updated to be compliant. Things like updating the br’s and hr’s and adding /’s to input items on forms were all of the things that I expected. Also expected was that all attribute values need to be lowercased. So if you have an onclick defined for something in your page it can’t be onClick or ONCLICK or anything else, it needs to be onclick.

The first thing that kinda gave me pause for a bit was that it is really picky about which elements can be just below the root element in a document. This ends up not being an issue and actually leads to a lot more consistence in the document structure. It was a little bit of a pain at first but it quickly got into shape. The specification does spent a certain amount of time talking about which elements can contain other elements and such things, so it’s probably good to have that floating around in your head. Or use a validator plugin ( see below )

The second thing that was a little difficult was that I had used the name attribute in a lot of places for some of my javascript interactions. So first I made everything xhtml compliant by switching things from name attributes to id attributes, with this done the site didn’t work terribly well. So I updated one javascript routine in my main library and then whammo everything was working well again.

With this all done I spent a bit of time and knocked the css document into shape and got it validated as well. So now when you go to www.hamtesting.com you will see badges from w3c for the site being both xhtml compliant and css compliant. Kinda fun.

Probably the biggest lesson learned was that while the w3c’s online validator services are fine for a page or two they can be a pain after a while, especially if you are trying to validate pages that are in an authenticated area of your site. Do yourself a favor and go get a html/sgml/xhtml validator plugin for firefox so that you can just pull up the errors as you run across them.

In the end, this wasn’t as difficult as I thought it was going to be. My impressions are that xhtml is kinda nice, and using the strict variant definitely enforces a certain amount of discipline into your efforts. It’s a good exercise if you have some spare cycles and want to dig in a little.

I ran into this over the weekend and since it took a bit of time to find I thought it might be useful for others. I was setting up an ATG development environment and had installed a version of MySQL that was known not to work with ATG..(oops..I’ll cover this in another posting). I uninstalled MySQL using the following steps :

1. cd /usr/local
2. sudo rm mysql
3. sudo rm -rf mysql-<some version number here>

With this done I downloaded a different version of MySQL and tried to install it, however I received the following error.

“You cannot install MySQL blah-version-blah for Mac OS X on this volume. A newer version of this software already exists on this volume”

After digging around about this for a while I was finally able to come up with the problem. You need to go into the /Library/Receipts directory and delete the Mysql related items in there was well. An example :

• cd /Library/Receipts/
• rm -rf Mysql<blah blah blah>

With this done. I was able to continue installing the new version and get back to stuff. Hopefully this helps someone else.