The Johnson Blog

Ramblings of a geek with a few hobbies…

Tag: Tech

  • Vista and Visual Studio 2005

    I knew I was taking a slight risk installing Vista on my laptop, where I do quite a bit of my coding.  I’m having a big problem with the Chef solution in Vista – it compiles and runs just fine but in the Visual Studio IDE I cannot open the WinForm Designer for anything but the simple forms.  Scenarios I have that cause the designer to blow up:

    • System.Windows.Forms.Form derived form that references controls that reside in another, referenced assembly
    • UserControl that derives from another custom UserControl that resides in the same assembly, and which can be designed.

    I wonder how long this is going to take to get fixed.  I don’t see this issue on their “known issues” list, maybe I should dig around and find out how to submit it.

  • LightScribe DVD Burner

    Ever heard of LightScribe? It’s a technology created by HP for “direct to disc” labeling, which means you can make labels on your CDs or DVDs. No cheesy paper labels, the laser is used to burn it in. Very cool idea.
    The laptop I purchased said it came with this capability. It wasn’t a selling point, but I thought it interesting and that I’d give it a shot some day. That day came last week when thought it’d be neat to make CDs of the offical Chef releases. Kinda dumb, I know. But a way to try out something new.

    I spent an hour or so trying to get the software on the laptop to recognize the drive and ended up on the HP website chatting with a support tech. They informed me that the drive in my laptop was not, in fact, LightScribe capable. I was a little mad because the box and label said it had it, otherwise I would have never known about the technology.

    That’s when Jay pointed me to a $30 drive that I ordered and was delivered tonight. I just got done burning my first label/disc (using the easy to use SureThing CD Labeler SE software) and I have to say that I’m very, very impressed and excited about this capability.

    Here’s my first disc (click to enlarge):

    First Lightscribe Disc

    You’ll notice the background is faded and the title logo isn’t very dark – that’s all because of the images I used.  The title is the red one located on http://www.ejichef.com and the background is a semi-transparent/faded image used on the Chef splash screen.  Pretty damn cool if you ask me.

  • Strong Naming

    As a continuation of my last post, I thought some of you .net developers may be interested in hearing about some of the issues I ran into when strong naming.

    Admittedly, this is my first real attempt at using strong naming as it’s intended and therefore I just wasn’t aware of a few things when I was writing the code for Chef. Two days ago I created myself a strong name key (sn -k keyfile.snk) to sign my assemblies with. Due to the obfuscation step I need to do between compile and packaging, I need to delay sign the assemblies.

    In an exercise in curiosity I decided to sign the assemblies with the public key half of my keypair and keep the private key “secret”. Which really means just not kept inline with the sourcecode, but rather living in a key container in the machine store on the build box. This process was mostly problem-free, I used the sn.exe utility to: create a keypair; import the keypair into a key container; extract a public key from the key container; tell .NET to allow me to run partially signed assemblies with that public key token (sn -Vr *,) for debugging purposes. It all went well until I went into visual studio and told it to use the public key for signing – it kept telling me that it was password protected and prompting me for the password. I never put a password on it.

    So to get around that, I did the first step (creating the keypair) from Visual Studio and gave it a password, then it all worked just fine.

    One feature in Chef is the ability to create bookmarks. In my ignorance, I was simply using the BinaryFormatter in .NET and serializing to disk an array of these things for loading later. Little did I realize that all of the version information for the objects is written out – and if the objects live in a strong named assembly and the assembly version changes, it cannot deserialize! There’s supposed to be a way you can get around this, by setting AssemblyFormat on the formatter to Simple but it continued to write the version information. I also tried the route of using a custom Binder during deserialization and that didn’t work either.

    As a result, last night I rewrote that code to serialize/deserialize the information myself with XmlWriter and XPathDocument rather than rely on .NET. Version issues gone. That’ll definitely be something I’m not likely to forget anytime soon. I need to rewrite one other small area this weekend for a similar problem, then I can move on. All that’s standing between me and Beta 2 is some thorough testing, a website update, and a file upload. Should all happen this weekend.

  • Automated Builds

    Several hours today were spent advancing my automated build process for Chef. I’ve had CruiseControl.NET building the software for months now but I’ve had a gaping hole in the processes that has been staring at me since I started it.
    What is this hole you ask? Version numbering.

    Why is versioning so hard in this day and age? Seriously. With .NET there are all these really nice and easy attributes that all you have to do is type in the version string you want your assembly/binaries to have. That works really well, until you want those numbers to be dynamic – then it requires modifying a sourcecode file with a new hard coded string. But what about 1.0.*? you ask, referring to the ability to have the compiler generate parts of it for you. Well, what real good is it to have version numbers that you don’t control? If they get generated by the compiler it just makes everything difficult – like translating between a version label from CruiseControl to the state of source control at the time of the build. Maybe I’m missing something here, but I don’t think I am.

    Another versioning issue is setup projects. The setup projects created in Visual Studio have a version number, product code, and upgrade code. Counter to intuition, the upgrade code is the same across versions for a given product and it’s the product code that changes between versions. Sooo, if you bump the version number you also need to create a new Product Code guid. Again, there’s no way (that I know of) to do this via command-line. Microsoft thinks you should open the setup project and bump the version number manually. They even go as far as prompting you to create the new Product Code guid when you do this. Microsoft, the creator of the great tool that is Visual Studio, make it very hard to do the Right Thing and have automated builds. Tisk, tisk.
    And finally, the version string has implications on product keys – both generation and verification. For instance, if Suzie buys Chef 1.2, I need to have a way to have that license key work for 1.2.5, 1.4, and 1.9; but not 2.1. And I need to be able to forget about the details rather than think about it every single time I create a release. (Chef Beta 2 is days away, by the way).

    My solution to these problems required a little planning, a little coding, and a lot of time waiting for test builds to be created. My process is as follows.

    • I go to the CruiseControl.NET Dashboard website and click Force to initiate the build.
    • The last successful build label is incremented (from 0.9.2.2 to 0.9.2.3, for instance).
    • The latest sourcecode is retrieved from the Perforce depot
    • The code I wrote tonight gets executed on the sourcecode tree, passing in the newly incremented build number
    • A new product code guid is generated
    • Every AssemblyInfo.cs file is edited and all AssemblyVersion attributes are changed to use the new version number
    • The specified .vdproj files (Visual Studio setup projects) are edited to modify the ProductVersion with a trimmed version of the current build version/label. The new ProductCode is also inserted
    • Visual Studio is called upon to perform the compile.
    • CruiseControl puts the generated installation packages out on the network
    • A sourcecontrol Label is created in the Perforce depot, denoting the state of the sourcecode at the time of the build.

    And that’s it. With a single click I have installation packages created with no further involvement. The files included in the package all have a version number that I can trace back to a CruiseControl label (to view build logs and in the future unit test results) and then back to a Perforce label with the same name to view the sourcecode files at were a part of the build. I’ll then also be able to compare those file versions with the recorded version numbers of bug fixes in FogBugz – something that will surely save time once Chef is in the wild.

    Microsoft, please please please make this better in the future.

  • Bug Tracking

    The development of Chef has been pretty interesting thus far. I had almost forgotten how much work is involved in getting an application shippable like this. My previous experience was with the release WakeUp! Alarm Clock, but that was as off-the-cuff as you can get: simple version control (umm, none at first then graduated to CVS); no bug tracking; no build process – builds were simply done on my development box; no unit test for regression testing (unit tests, what are those?!); and really no plan whatsoever. But I was in college and had no real experience in software, it was my first.
    In these regards, Chef is completely different. I mean completely. My development environment is quite extensive in comparison to the days of old: Perforce for source control; FogBugz for bug tracking, support, forums and a bunch of other things; an automated build system driven by CruiseControl that give me a build and install at the click of a button; full NUnit test cases for the entire Chef API; and multiple VMWare environments for testing. Future posts may include some information on some of these topics, but for now a little information about FogBugz.

    (more…)

  • Recipe Sharing and Beta 2

    Chef Beta 2 isn’t quite as far along as I’d like it to be thanks to the Holidays and work.  I’m targeting the middle of January for its release and that’s coming up fast.  A couple dozen bug fixes and features/enhancements since Beta 1 have been done though, with the major ones out of the way.

    One of these big features is Recipe Sharing, which I think will be a compelling reason to actually put recipes into the application.  It’ll be very handy to just click the mouse  a few times and be able to give recipes to fellow Chef users. And for sharing with non-Chef users, there’s always copy to clipboard.

    So those of you interested should keep an eye out in the next few weeks for the final Beta release, with 1.0 hopefully coming in another month+ after that.

  • DVD Changer

    A week ago, Jay brought up the topic of movies on demand in his house. He was starting to look hard at going the DVD-to-hard drive route, when he ran across this awesome Media Center setup from Sony. That’d be a fantastic solution if I were willing to pay that much for it. Unfortunately I’m not.

    Int he past I’ve made several attempts at having a computer in our living room hooked up to our tv. At one point we had been using MythTV for a year or more. It was a bit clunky but worked. But then we got an HD tv and started renting a dual tuner HD DVR from our cable company and disbanded the Myth box. Several months after that, my parents gave me their unused Tivo so I setup Galleon to allow us to play our MP3 collection with it. I think we’ve used it once. And now that my PC is in the next room with a decent set of speakers, I see us using it even less than once in the future. Shrug, I’ve tried.

    But now the thought of on-demand movies… We have a lot of DVDs but hardly ever watch them because we’re…ahem.. too lazy to get them off the shelf I suppose. Instead, we often find ourselves watching the same movies we own on TV – with the commercials and crappy picture. On-demand would be very helpful. However, I don’t like the idea of (these overlap, don’t complain) 1) building a computer to drive it, 2) paying for the computer to drive it, 3) have the annoyance of MythTV or the cost of Media Center. In short, I don’t want a computer in my living room running it all. I’ve tried it and I find it just too annoying.
    So today I think we solved it by purchasing Sony’s 400 Disc DVD Changer. It took a while to get configured with all of our movies, but it’s now up and running. All 200+ of our DVDs are now just moments away for a lot less money, time, and annoyance than a PC.

  • Perforce

    A while back I discussed needing to look into a new source control solution for Chef.  To recap, CVS had just gotten on my nerves for a few things: file deletion and moving; pretty crappy windows client support (gui); clunky (to me) branch management; and poor infrastructure on my network.  I just don’t feel comfortable using it on Chef going forward.

    Some of my requirements for the replacement system:  stable; reliable; simple backup/restores; good Windows GUI tools for management; inexpensive (read Free); intuitive; good documentation; preferrably a Windows server (to simplify my backups).   The two forerunners were a coworker’s recommended, SourceGear Vault, and Perforce.  Vault was built as a Visual Source Safe replacement and is free for a single user.  Perforce, I learned, is a very popular and robust scm server that is free for 2 users or 5 workstations.  After comparing the two for a while I settled on Perforce mostly because it met all of my requirements, and did so in a very elegant and polished fashion.  Documentation has been spot-on and things work as advertised.  I was able to import Chef, get it backed up and configure Visual Studio’s Source Control integration all in a span of a couple hours.  Pretty impressive. Thank you Perforce for the free license.

  • Radio Shark

    As many of you know, I have a Radio Shark setup at home for recording radio shows.  Overall, the software sucks for it.  Getting it working for the first time was nothing short of a miracle – it had lots of trouble recording to a network drive.  For weeks it would not record right, but after fiddling around with non-recording settings, it would magically start working.  It felt like there were terrible bugs all over the place, particularly in the app settings area.

    That aside, the scheduling was very weak and cumbersome.  So, I’ve been looking forward to a software update for a long time.  During the past few months they released a new Mac version, but zilch for the PC.  Yesterday I just happened to visit the website to look for updates and noticed they are now selling a Radio Shark 2 device that allows recording of internet radio.  And there’s new software for it.

    I looked at the support page for the regular Radio Shark, but they make no mention of any new software.  On a hunch, I decided to download the installer for the Radio Shark 2 and see if it would work on my older hardware.  As expected, it did!  And so far everything about it is 100% better, only time will tell if the scheduling actually works correctly.

    So for all you “version 1” Radio Shark owners – go get the new software on the Radio Shark 2 page, it’s definitely worth it.

  • Beta by Thanksgiving?

    A while back I tossed around the notion of having a beta of Chef available for testing by Thanksgiving.  So far I’m doing quite well with this goal.  Now that the setup situation has been resolved, I can work on a few other issues that have to be done before I add the few final features that will be in the 1.0 product.  It may not be too far-fetched to see the first beta available in the coming weeks, so if you’d like to give it a try I would be very appreciative.  Just shoot me an email or comment here.