Regrettably, WordPress just wasn’t cutting it, and so I made the difficult decision to move ship to Blogger. My new home on the web is www.toastedcode.com. Yeah I know – if I had set up a domain a long time ago I wouldn’t have had to make this service announcement.

I’m still working on Code Toaster and will create an updated site at a later date with links to download files, documentation, and so forth. For now, check www.toastedcode.com for the latest information.

I hope you’ll follow me to my new home, but if not, it’s been swell!

Hold on now! That wasn’t one of my classes – I’d never seen it before, although I did in fact have a class called CodeFragment. I right-clicked and selected Go To Definition from the popup menu.

The class looked familiar somehow. On closer inspection, it appeared to be a copy of my CodeFragment class, except that in this _Accessor version, all the fields I had declared private were declared public. Hmmm.

I cracked open the MSDN documentation and ran a search for the ShadowingAttribute. MSDN displayed the helpful hint: Do not use this class.

Really. That’s what it said. Do not use this class. Lighten up Microsoft, I wasn’t going to use it, I just wanted to know what it’s for! Sheesh. And that’s pretty much all the documentation it looked like I was going to get on the infamous ShadowingAttribute.

But moving right along – the _Accessor class inherits from a class called BaseShadow. Maybe that would provide some clues.

And I was right – MSDN reports that BaseShadow
is used by the publicize method to help you test private types.

Well now, that makes a whole lot more sense, and is actually pretty snazzy too. Although, to be honest, I’m not sure what publicize method they’re referring to. I mean, I see what they’re getting at, but that seems like odd language. Did they mean there’s a class somewhere that has a method named publicize, which uses the BaseShadow class in some way, or does this refer, in a general sense, to the process of publicizing a test? Or something.

Anyway, VS.Net’s unit test framework apparently uses some fancywork (using reflection) to ensure complete code coverage (instead of generating tests for only public fields, properties, and methods). You’re not going to get much help from Google doing a search for ShadowingAttribute, but take it from me that you can (and should) safely use the generated _Accessor class to unit test both public and private accessors in your class. And this is another great reason why you should let VS.Net stub out your unit tests for you instead of building them from scratch yourself – hand coding the “shadow wrapper” would take a while.

And that’s working very well. In fact, I think it’s working better than I expected, perhaps because, this time around, I’m using much better development practices. Like Test Driven Development. In retrospect, it was extremely foolish of me to ever approach a large coding project like this without reams of automated tests – I’ll talk about that later in this post. But first, a little about how the parser(s) work…

Each step increases in complexity by many-folds. I’ve completed the Template Parser, which was enjoyably challenging but not ridiculously difficult. It’s currently parsing a 1,000+ line template in about 80 milliseconds, which should be fast enough, I think. I’ve done some performance tuning, but may revisit it later to try to speed things up even more. As you’re editing a template, any changes (like variable declarations, new types, etc) need to be available immediately within IntelliSense, which means the backend parser and IntelliSense engine must be lightning fast.

And reliable, which is why I’ve spent a good deal of time fleshing out a suite of unit tests. VS.Net 2008′s new unit testing functionality is just a beautiful thing. It’s actually beyond beautiful. If a test fails, I can easily run just that test (VS.Net is smart enough to figure out what test to run by looking at where my cursor is in the test class), step into the code, and inspect and fix the problem using the stupendous Edit & Continue feature. Yeah, you could do almost the same thing with NUnit, but the process is so much more streamlined now, and just plain easy.

I think I’m on the right track. Getting rid of ProGrammar means there’s no cross-appdomain performance penalties, no COM headaches (like registering and unregistering COM dlls, and all the headaches that could entail, during installation), and most of all, I can tailor the parser architecture to meet the rather specific needs of Code Toaster.

So your next question is probably: what about that C# parser? How long is that bad boy going to take to write from scratch?

And the answer is: not long at all. But that’s a story for another post.

A few security researchers have recently turned their attention from hacking RFID chips to pacemakers and implantable defibrillators.

Apparently a hacker could cause some serious cardiac damage, wirelessly, from less than 5 feet away. For now, the threat appears to be “largely theoretical”, whatever that means. At the least, the idea of someone being able to stop a heart, via remote control, would make for a great novel or movie plotline.

But for those 250,000 folks sporting a pacemaker under their skin, it might be time to start thinking about making suspicious visitors and money hungry, unscrupulous, relatives check their laptops and other wireless devices at the door. 

Is it just me, or is this starting to resemble the razor blade shootout between Gillette, Schick, et al?

From TweakTown’s review:

“It’s clear that NVIDIA has really got its dual GPU SLI technology sorted out, but when you start mixing it up with three or four GPUs the performance increase while present, is very small, especially in relation to what it costs you to go down that route.”

Psychologically, though, I can’t help feeling that, if I had the funds, of course three video cards must be better than two! And most definitely one!

Ain’t that just silly?

I’m trying to get back into the rhythm of working on Code Toaster a few hours each night; updates should be forthcoming. Bear with me while I get things rolling again.

In which case it can become a little difficult to stay focused. For a little help in that area, try out this Yahoo widget: Ten Plus Two (you’ll of course need the Yahoo widget engine installed).

Ten Plus Two is basically a timer than counts down for 10 minutes (or more, or less, if 10 minutes isn’t your cup of tea) of work, and then counts down for 2 minutes of rest before repeating the process. Work for 10 minutes, breathe for 2 minutes. Your two minutes can be a trip to the bathroom, a quick blog post, or just staring off into space while your eyes rest. Each change is accompanied by a nice little audio cue as well as color indicators – the background turns red when you’re supposed to be working, and green when you can take a break.

Granted, this could possibly get aggravating after a while, but it works wonders for keeping me on track while slogging through monotonous work items when I would much rather be browsing TechMeme or reading the latest from Coding Horror.

What it purports to do is to allow you to design a web app as a .Net client application, slice it up into different tiers, and spit out cross-browser JavaScript for the client tier, web services for the server tier, and all the boilerplate code to tie everything together.

At first glance I got all giddy and thought that this could convert any .Net client application to a web-based app, but a closer look seems to show that to not be the case. You have to use the Volta libraries and mix and match traditional HTML with your .Net code.

Might be worth a look. 

Ultramon – link

If you have a multi-monitor setup, you must run out and purchase this tool right now.

This tool has changed my life!

OK, maybe not really changed my life, but it has drastically improved my satisfaction level when working across multiple monitors. The price is reasonable at only $39.

Just buy it. Or at least download the trial. You’ll thank me later.

Enso - link

Humanized.com puts out some interesting products; I’ve only tried Enso, and it is truly a beautiful thing. It’s a little hard to explain without actually giving it a whirl, but, in a nutshell, you can teach it to do things when you type short commands, like “open my documents”, or “open intranet”, or “define heuristic”.

If you’re a developer such as myself, your first thought when you take a look at Enso will probably be something like, “I could have done that. This isn’t that hard.” But after using it for a bit, I’ve come to think that it’s too simple and elegant to have been easy to put together. I can open a file, URL, folder, or run a program anywhere on my computer, without searching for it, just by typing a simple intuitive command.

And the price is super reasonable at only $19.99.

Just buy it. Or at least download the trial. You’ll thank me later.

I’m doing some work on the next minor version of Code Toaster, which (hopefully) will include an automatic update feature. After reading (again, for the ka-jillionth time) this tutorial on creating an update msi with WiX, methinks it should be fairly straightforward. The process will go something like this:

1. When Code Toaster launches, it will download an XML file containing version information.
2. If there is a new version (as noted in the XML file) Code Toaster will download the msi installer for that update.
3. Code Toaster will launch the msi and exit.

One problem I’ll have to resolve is how to install an update while Code Toaster is running. The most oft-used and recommended solution for doing auto-updates is to launch your application via a proxy that does the update work, and then launches the application later if no updates are available (or after the update process is complete). But I don’t like that for a couple of reasons. 

1. If there are two executables, CodeToasterProxy.exe and CodeToaster.exe (or whatever), that might confuse a user as to which one to run (users would run CodeToasterProxy to get the update capabilities, not CodeToaster.exe).
2. Since CodeToaster.exe can be run as a command-line application (to compile/run templates in batch mode, for example), it should be intuitive which exe to run in that scenario. In this case, the user would run CodeToaster.exe, not CodeToasterProxy.exe.

I bet you’re looking at this post cross-eyed after that wonderful explanation, huh? Maybe I should have boiled it down into one reason: confusion. And we sure don’t want Code Toaster to be confusing.

There is another option : to have Code Toaster check for and download updates, and then launch a separate application to run the msi update. That would keep things intuitive – you would always launch CodeToaster.exe rather from the command-line or from the Windows GUI, and CodeToaster.exe would remain in control of the update process. The only problem, and a minor one at that, would be the installer app would need to wait until the Code Toaster process had successfully exited before beginning the install. So step-by-step, it would work like this…

1. CodeToaster.exe launches and downloads an XML file containing information about available updates.
2. If an update is available, CodeToaster.exe asks the user if they want to go ahead and download and install the update.
3. If the user wants to install the update, CodeToaster.exe initiates the download.
4. Once the download is complete, CodeToaster.exe launches the installer application, and then exits.
5. At this point the installer must wait until CodeToaster.exe has finished exiting, and then launch the update .msi file that was downloaded earlier by CodeToaster.exe.
6. Once the msiexec process has exited, the installer app can re-launch (the now updated and bodacious than ever) CodeToaster.exe, and way the user goes!

Whudya think? I think I like it. That’s the route I will probably take – there are a lot of steps but I think it’s more elegant than having a proxy app between the user and your application. Howsomever, there may be someone out there who knows better – if so let me know.

On another note, I’ve noticed that Windows Installer packages are quite difficult to update. You can’t just run an msi containing a minor (version) update, because you’ll get an error message that says ”Another version of this product is already installed.”

Well, duh! I want to update the version that is already installed!!

So you have to run your msi using the following command:

msiexec /i MsiFileName.msi REINSTALL=ALL REINSTALLMODE=vomus

Don’t ask what “vomus” stands for. I couldn’t find an adequate definition/explanation on Google within my 5-second attention span. But this is another reason to use an automatic update design instead of asking the user to run an update msi manually. Ask a user to do that to update your software and they’ll hate your guts and call you names.

This, too, is documented in the WiX tutorial, lesson 4, if you’re interested in some late night fireside reading while your hunting dog naps beside your overstuffed armchair.

So, looks like I have some work to do.

Onward.