Here is a video of me (in the blue) finishing the Cape May Time Trial. I ended up with a 19:59 which over the 7.5 mile course comes out to a 22.5 mph average.

For awhile now (62 days) I have been trying to lose weight. While I have only lost 12 pounds overall, I have certainly gotten stronger. This past Sunday I entered a 7.5 mile ITT (Individual Time Trial) and got clocked at 19 minutes and 59 seconds which equates to roughly a 22.5mph average. This is a lot better than what I could have done 62 days ago!

But it isn’t enough. My improvement in the races is going as I want, but on the scale it isn’t. So rather than get really drastic with my diet (I have cut out sugar, soda, and soon pizza) I am deciding to just go on two bike rides every day that it is possible. Today I went for a total of 36.2 miles over two outings but that number will increase drastically once it cools off a bit (it was 90F today).

The point of this is two fold: get a lot more miles on the bike without needing to spend constant hours on it and lose weight faster. Last year I was able to gain strength quickly after I bought my bike by doing large amounts of miles in a single day. This caused my muscles to break down enough so that they rebuilt much stronger. Furthermore more hours on the bike means more calories burned and more burnage means more weight loss.

Me at the Cape May ITT

The plan for the near-distant future is to have two weeks, one in middle May and one in middle June to spend an insane amount of hours in the saddle. For the week in May I plan to be doing large single ride days of 60 miles or more and mostly in the hills. This will set me up nicely for the week in June when I will be in the Adirondacks and am faced with nothing but incredibly large rolling hills.

One of the major design decisions for Vodka 2.0 has been how to handle the installation of all the software necessary to run a site. At first I favored a desktop application based install since it would allow me to write in normal .NET code without any problems or hurdles that the web presents. The problem with this idea is that a desktop based install isn’t feasible for most people, certainly not for those on shared hosting.

A client application based installation is what I call an Exploding Installation because it takes a package and pushes files out of it onto the file system. Thus it is exploding itself onto the computer. This works really well for most cases, especially basic software installs like games, office applications, et cetera.

Where such an explosion doesn’t work well is for web based installations, which is where Vodka 2.0 is headed (see screenshot below). This is due to the fact that in most cases the average user isn’t able to set up the server in a way to make it work, or doesn’t want to. Originally the installation procedure was going to be based on an explosion: the user would upload the files, put in the site information (see screenshot below) and then the installation would unpackage the files necessary to run the site based on the information. This would work very well, except it leaves the original install files at the root directory of the server. Instead of this approach, an Imploding Installation does the trick because it not only erases over the install files themselves (big security bonus), it doesn’t require any work to setup. The goal here is to have the user upload the files, run the install and get to work creating content.

So how is this done? To support an implosion of the software, or rather a rewrite of key points of it the software needs to be modular in such a way that programmatic writes can be done over content areas. In the case of the Vodka install the site’s navigation needs to be rewritten and because it is based on ASP.NET MVC has to handle the shutdown and/or removal of the installation controller and views. Right now this is done by removing a simple text file from the server, although in the future it can be done by changing a portion of the web.config file and/or removing an extra “Install” library from the bin directory.

The best part about the implosion is that it is 100% clean. After an installation is completed, there is no evidence left that it ever took place, and no possible way for a user to rerun the installation.

I sure hope so. The Zune is a great device for many reasons, most important to me being that it works every single time I want it to. I use the Zune software everyday and while it does crash sometimes, it isn’t morbidly slow and isn’t bloatware. The problem, however, is that the Zune really hasn’t received the hardware treatment it deserves. No touch screen, a touch pad that is glitchy (specific spot on the pad), and lack of full graphics development (no shaders) really hold it back. Hopefully this Zune “HD” will fix all that…

Shots via Engadget

Looks like we have a platformer contest starting up here… any other entrants? This is the start of a game by ElementCy which apparently go for more of a Conker feel than the fast paced style of Tears.

Check out Zedox’s new platformer, Tears, in this video. I have been wanting a good, fast platformer for many months now. Remember kiddies, Sonic is always better than Mario.

I run into these so much these days…

1. Order Dependent Coding – Often I find code that is entirely dependent on the order of the content tree. If you are trying to render a specific item in the tree you have to go based on some unique feature of that item, not its order. The best choice here is not to depend on the specific item at all but rather that it exists and is of a certain type. Try to abstract your code to depend on the item being passed in to your code.
2. Hard Coded Values – Hard coding has its time and place; it is especially great for quick and dirty tests. However you shouldn’t rely on a hard coded value for mission critical applications. All too often I find that developers write in a hard coded value that is possible the end-user will want to change. While this might provide you with a faux hour of work later on, it is just unethical and bad design. Rely on configuration files or databases instead to drive the settings of your code.
3. Error Checking and Response – It is important that as a developer you attempt to catch errors. It is understandable that you will not be able to develop a 100% bug free application, but simple errors are simple to catch and handle. This is even more important in the web sphere where a single error can bring down an entire page in an ugly manner. While an unhandled exception in a (.NET) WinForms application presents the user with a nice “continue or quit” box, an unhandled exception on a site can easily cause a messy error page to show with no options for the user. One of the most common problems with the web is checking for a null value!
4. Templating – Templates, Themes, et cetera all exist for a reason. They provide us with a way to treat all content of a certain type in a single manner. This greatly reduces the code we have to manage and reduces the dependency on us (by the end user) to create new content. This is a good thing, so use templates the way they were meant. Do not create a single template for a single instance of a content item.

Got my first full zipper jersey, but it is a little tight. I think my goal for this season is to fit in this jersey which means losing a lot of weight… like 30-40 lbs because I would lose the first half of that elsewhere most likely.