Feeds:
Posts
Comments

New Toy

The family just took a vacation, spending an entire week in an indoor water park and resort. Specifically, we went to Kalahari in Sandusky, OH. We had a great time, though I don’t think I’ll go down any more “toilet bowl” slides.

Anyway, before leaving for this trip, my wife decided we needed a laptop. We own an aging Toshiba (don’t recall the model), but it’s painful to use. It’s that old. See, as much as I’m into this tech stuff, we’re kind of tight with our money. In this case, though, the wife really wanted to stay connected while we were gone on this extended vacation, so as long as we watched the budget, it was time to purchase a new laptop.

Well, we found a deal. Got a Toshiba Satellite U500 at a really great price. I’ve always liked the Toshiba line of laptops (our first one actually got dropped down a flight of stairs, while running, and suffered no damage), so it was pure luck that while bargain shopping with a single day to make a purchase, the one we found was a Toshiba. Even better, this one has a multi-touch screen. I must say, after using this one, I don’t think I’ll ever own a laptop without a multi-touch screen again. I’ve never plugged a mouse into this one, and I’m quite happy about that!

The U500 is a good size. Having bad eyesight, I didn’t think I’d like a screen this small, but honestly, it’s just about perfect. It’s got a rugged design, with a quality feel. It’s also packed with features. I’ve really been enjoying using this thing, even if I do still prefer the desktop experience (may have to look for a multi-touch screen for my desktop now).

I’ve even managed to get some Onyx vNext coding done on this thing, which is something I never could have done with the old laptop. 🙂

OK, this is too cool.

My current pet projects, Specificity and Onyx, both require desktop and Silverlight support (well, Specificity is getting this support soon). The typical way of accomplishing this is through project links. You create two projects, one for the desktop and one for Silverlight. You create physical source files in one of the projects, then in the other you create project links to the other file. A project link is like a symbolic link in file system vernacular, but done strictly within a project definition. If you need the code to be different between the platforms due to differences in the platform libraries, you either use conditional compilation via #if/#endif blocks, or you use a partial class with platform specific code in a file not shared with the other project.

All of that works fairly nicely, but it’s a bit of a maintenance PITA and can be rather error prone. Forget to create the link, and it’s possible everything will still compile, but you’ve got a “bug”.

Well, I just found out that there’s a tool that automates all of this within Visual Studio, provided to us by the patterns & practices team. It’s called the Project Linker: Synchronization Tool. Having just found it, I’ve not yet been able to use the tool “in anger”, but you can be sure I’ll be checking it out real soon.

By the way, if you’ve followed me here from my previous blog on Spaces, welcome to my new home. Hopefully I’ll no longer have to worry about blog spam here! However, being new to this blog, you’ll have to excuse me for a while as I settle in and get things working the way I like.

Update: Near as I can tell, this is where you grab the tool from: http://www.microsoft.com/downloads/details.aspx?FamilyID=387c7a59-b217-4318-ad1b-cbc2ea453f40&displaylang=en#filelist.

I’ve Moved

OK, after the rant in my last post, I’ve done it. I’m not going to be posting to this blog anymore. I’m moving over to WordPress at https://digitaltapestry.wordpress.com.

Spaces Rant

Windows Live Spaces are driving me nuts. I’m going to be looking for a new home for my blog very soon. I’m that fed up.

I get way too much spam in my comments. Do a Google (Bing) search and you’ll find that this has been a very long standing complaint, and there’s really no excuse for this. The spam I’m getting is very obviously spam, and is guaranteed to be caught by event he lamest of spam filters, but Spaces doesn’t employ any spam filters! Oh, but it gets worse. For much of the lifetime of Spaces there was no way to report spam. The tried to address this, but the result is a pain to the user, and there seems to be no results obtained from reporting the spam. There should be a big SPAM button on every comment when you’re in admin mode. Pressing that button should do numerous things:

  1. It should automatically notify the site administrators as to the wrongful behavior of the user, so an investigation can begin and the user can be banned.
  2. It should delete the comment.
  3. Optionally, it should block the user from ever posting to the blog again (outright banning from all blogs should be done only after investigation by administrators). In this case it should also delete all other comments on the blog left by this user.

Instead, we’re left with having to manually locate a form to fill out with information about the spammer that seems to be ignored, and then manually have to delete every spam comment. Manually deleting those comments is a royal pain. You can’t multi-select, it has to be done one message at a time, and each deletion requires confirmation. In less than a week I’ve received more than 60 spam messages, and deleting all of those is going to waste a lot of my valuable time. What’s worse, it’s all spam that I never should have gotten in the first place, if they’d simply run a spam filter!

Yeah, I’m going to be moving somewhere else. Just got to figure out where.

Sorry for the rant, but I’m in a mood right now!

This is just too funny not to share. I’m not going to give exact quotes or setup context, but just go straight for the funny bone.

Peter O’Hanlon: Who is this Major Hack you refer to? Is he in the same battalion as General Exception?

Michael Brown: I think Colonel 32 was also in that division.

Peter O’Hanlon: Along with Private Bytes?

Specificity Beta Released

I’ve released a Beta for Specificity, so it’s no longer just a source repository. Specificity still isn’t ready for full release. There’s additions to the release I plan to make, including project and item templates. However, I expect the APIs to be stable at this point. Creating a release, including an installer, was important to me. See, it’s going to help with one of the largest complaints I’ve received for Onyx: figuring out which source revision of Specificity to use. In the next day or two, I’ll update Onyx to use an installed version of Specificity, and those issues should be gone.

I’ve had to learn a lot of new tech to make this release. I’m using Wix to create the installer, and that’s not the most intuitive thing to work with. Then there’s the project and item templates that I’m working on. These require a custom wizard to control code generation, since Specificity is compatible with numerous different unit testing frameworks. If I find the time, I’ll try and blog about what I’ve discovered here, but if nothing else, hopefully the source will be useful for anyone else trying to figure this stuff out.

Disclaimer: This blog post is theoretical notes about an interesting subject, and does not contain a working solution. I will probably provide a solution in the future, but if you’re looking for one here, you’ll be disappointed.

Glenn Block had an interesting post about the “spirit” of the ViewModel design pattern. If you haven’t read it yet, do yourself a favor and go do so. I’m not going to talk about his subject matter here, really, but there was a very interesting reply in this posting from Ward Bell who’s also got a blog that’s well worth reading. In the reply, Ward talks about simplifying XAML/WPF coding by using convention based programming. In particular, this paragraph in his response stuck out to me:

Maybe we shouldn’t be marking up Person.Name at all. Maybe, if we had an easy way to walk the XAML tree, we could automate the wiring of the binding by letting convention tell us that "Person.Name" is accessible from the ViewModel.

See, the thing is, we do have a way to easily walk the XAML tree.

I’ve been playing around with a couple of different convention based solutions to WPF programming, some of which will see the light of day in Onyx in the near future, hopefully. What I’d like to do with this blog post is explore the idea, describing a concept that could be implemented to do exactly what Ward wants. I’m going to discuss implementation details, but I’m not going to provide code. This is all theoretical and is being presented for discussion purposes.

Ward gives a use case where he has a TextBox that’s been provided an x:Name value. He then says “A one-line wizbang in the code-behind constructs the binding for us … and not just for this TextBox but for every control bound to a property of Person.” First, I don’t like the idea of needing a “one-line whizbang in the code-behind.” I’d propose that instead we rely on an attached property/behavior to do this. Onyx already has the perfect attached property for this: View.ViewModel. The change handler for this attached property can walk the tree to provide our convention based bindings. In WPF we can actually use a trick that would enable us to not even have to walk the tree manually. View.ViewModel in the WPF version of Onyx is marked as an inherited property, so we’ll get change notifications for every child element which means WPF has done the work of walking the tree for us. In Silverlight you’ll have a bit more work to do, and it may be a bit tricky to handle some timing issues, but it’s all very doable.

I’d like to discuss using x:Name as the hook to use for our conventions. I don’t like this, for a few reasons. First, the fact that x:Name creates backing fields for you is something that I don’t care for, unless your intention really is to have a backing field. Second, x:Name is meant to be unique, while there will be several scenarios where we don’t want to be restricted in this manner. So, I’d propose using a special attached property for our hook. I’m struggling with a good name for this one, but for now let’s just call it View.Moniker.

So, now we have everything that’s necessary to do data binding by convention instead of configuration. But we can carry this idea much further. Let’s say we have a Button that we’ve given a View.Moniker of “Save”. If we have a SaveIsEnabled property on our ViewModel, that should be bound to the IsEnabled property of the Button. If we have an OnSaveClicked method on the ViewModel, that should be added as an event handler for the Click event of the Button. If we have a SaveCommand property on the ViewModel, that should be added as a command binding on the Button. You can imagine several other conventions to adhere to, so this should be an extensible concept. Instead of hard coding the conventions, include an ApplyConventions (needs a better name) event that can be hooked into to apply the conventions required by the individual application.

So, what are your thoughts on this?