Saturday, September 29, 2007

I don't think I have a slow machine but every time I open Outlook, I keep thinking that it might be time for an upgrade. It got me thinking that it (and many other applications) could benefit from a "load in the background" option. The idea is based on the desktop search apps that index your machine while it's idle. Outlook could start loading at startup (and I must stress, while the machine is idle) while I browse the internet, load up Visual Studio, etc., etc. Then when I actually click on the icon, the app might be a little snappier.

Without something like this, I'm giving serious consideration to making GMail my primary mail client.

Kyle the Impatient

Friday, September 28, 2007

Three days after my nervous breakdown and lo! i am saved! Both my mind and spirit (still working on my body). If you recall, Launchy, SlickRun, the WinKey, and even Alt+Tab were not working on my remote desktop connection because I had to launch remote desktop within the context of a Citrix application.

Launchy has been re-enabled simply by disabling it in my laptop. I suppose that means that since Alt+Space isn't handled there, the keystroke is passed into Remote Desktop. Frankly, I don't care. I can find things again!

WinKey is still insistent about not entering into my remote desktop. But SlickRun is back by nature of AutoHotKey. Which brings me to...

AutoHotKey's status has been bumped from "great utility" to "the most awesome computer application ever invented". Thanks to it, I have remapped SlickRun to RightCtrl+R. More importantly are the following two lines I've added to the AutoHotKey script:

RControl & RShift::AltTab
RControl & Enter::ShiftAltTab

This is taken directly from the AutoHotKey documentation. What it means is that I can Alt-Tab my way through applications by holding down RightCtrl and repeatedly pressing RightShift. Ditto for going the other direction by pressing RightCtrl and Enter. And since I rarely use the right Ctrl, Alt, and Shift keys, there is little chance it will interfere with, say, a ReSharper shortcut I use.

Hello keyboard, my old friend! I'm free to type on you again!

Kyle the Re-invigorated

Tuesday, September 25, 2007

7:00AM
Sure is great to be working from home. Just think of the time I'll save on the commute! Not to mention how much better it will be for my health not to eat out all the time.

7:15AM
This is awesome. Was a little cumbersome logging in. Bit of an inconvenient having to first connect to the VPN, then log in to Citrix, then connect to my machine at the office, then launch Remote Desktop. But it's totally gonna be worth it!

9:37AM
The rest of team is just rolling into the office and I've already slammed down two bugs. I'm changing my name to Wile E. Coyote, Soo-per Gee-nius. Sucks that I can't use my AutoHotkey shortcuts because of Citrix, though. Didn't realize I had set up so many of them. Oh well, guess I have to go old school for a bit. At least the ReSharper shortcuts still work.

10:45AM
My first remote Scrum. Fielded my share of jibes about the weather and working in my pajamas (I felt it best not to reveal that I sleep commando) but I didn't mention the two times I've had to reconnect already because of the ludicrous five-minute timeout and Citrix's inability to deal effectively with it. Gotta keep the mystique alive.

12:18PM
Hmmm...Can't launch Launchy on the remote machine either. Alt+Space keeps opening it up on my local machine. Ditto SlickRun. And even the Windows key (and Ctrl+Esc). Man, that's really gonna hurt. But no matter! Time for a nice healthy turkey sandwich on whole grain bread for lunch!

2:22PM
Are you kidding me? I can't even Alt+Tab between my apps when I use Remote Desktop in Citrix? Where's my *$%# mouse?

3:07PM
Who the *&^# looked at a rat and said, "Now, THERE's a way to navigate your way around a visual desktop". Seriously, someone has to tell me who invented the mouse so I can go to his house and "watch him sleep". I can't believe I used to use this little plastic phallic symbol. I need a snack. I know there are some chips around here somewhere...

4:14PM
Sweet Zombie Jayzus, WHERE THE &*%$ ARE ALL MY PROGRAMS? I haven't opened the Start Menu since the first week and now it looks like my desktop wallpaper whenever I expand the *$#^ thing. Plus I think I deleted a bunch of them because I had AutoHotkey shortcuts set up for them. Who knew I'd have to one day use this thing again?

5:39PM
Dear client...I'm so sorry...I...I can't go on...The mouse...it's so...bulky. I feel like Shrek when I try to click on a program in the taskbar. Google is three clicks and eight keystrokes away at any given moment. An eternity, I'm sure you'll agree. The keyboard has become this unknown...beast...of a device. I have so very many unused applications open on my laptop that I opened by mistake thinking they would open in my Remote Desktop. I'm scared to press Alt+F4 not knowing just exactly what will close. I'm scared I'm losing my mind. I'm scared I won't make it until the pizza delivery van shows up with the three eight-cheese pizzas I ordered. I'm scared...

Monday, September 24, 2007

I really do need to be more careful about what I say. But in my defense, there is no way that I could have known that an innocent little post on Silverlight would lead to accusations of bestiality.

But even without that nice little image of canine sodomy, I need to choose my words more wisely. And I get the impression from my previous post that I wasn't totally clear on my position. So I'll start by confirming that I am very excited about Silverlight. As I was with Javascript DOM manipulation, XML/XSL, XMLHTTP, and ASP.NET AJAX when each of them came out to make our lives "better". In case the tag cloud doesn't make it obvious, my interests lay in the web space. And Silverlight is almost as webby as you can get. And so, while my recent professional development has led me down some strange and wondrous paths, I will always make room in my calendar for a shiny new web technology like Silverlight.

My confusion was with the context around it. I.E. Why would you use it? (and I mean that as an honest question, not a sarcastic one). In what cases would you use Silverlight vs. a traditional web app vs. an ASP.NET AJAX one, for example. And in what cases would you combine two or three of those?

Such were the questions swirling through my head when I sat down to speak with John Bristowe, who graciously agreed to guide a friend and me through the tumult.

Side note: There is still a good sixty to seventy percent chance I would say this even if I didn't know John was going to read it but I've always appreciated his tendency to speak frankly about the technology he evangelizes, especially when talking to him directly. Not in an in-your-face, "I may work for Microsoft but I'm still a rebel" kind of way. He focuses on what it can and can't do in a very matter-of-fact way. He clearly knows his audience and their tendency to turn jaded when they detect marketing-speak so there's little sugar coating. But at the same time, he still paints things in a positive light. Anyway, that's enough Bristowe-love for now.

We discussed the many pros and cons of Silverlight of which I'll highlight only a couple here. None of the major cons struck me as being a big deal. Yes, it's early in the product's lifecycle and the tool support is still under development. But given that my favorite HTML editing tool is Notepad2, I'm okay working directly with XAML. At least I can use an XML editor if only to validate my work in some small way. In any case, I have no doubt the tool support will be there from someone when I eventually need it.

The pros were more interesting. The obvious one is the development environment. I.E. Building apps in a managed environment. This is one I kind of slammed in my last post. I shouldn't underestimate the impact of being able to write client code in C# and I welcome the opportunity but I'm also not going to shy away from a little Javascript if the situation warrants it. And for those of you who can't wait until the Silverlight 1.1 release, there are alternatives. Regardless, the fact that I can use base class libraries in a browser is a nice-to-have for me, not a make-or-break selling point. I'm just not feeling enough pain, I guess. Or rather, I'm of the opinion, "Find out what the user wants and build it. Somehow." If it involves technology that you're not familiar with or that is cumbersome, suck it up and learn. That's why you build software and users don't.

To me, the more important benefits are: the performance gains for really process-intensive client code (orders of magnitude in the hundreds!), dynamic assembly loading, and isolated storage. These seem to be more user-focused improvements over the current model. Performance gain is an obvious one but isolated storage opens up doors for customized user experiences. And dynamic loading means better perceived performance (which, as I've mentioned before, is more important than actual performance). Plus it means you can introduce more user controls in a seamless way. As my friend said afterward, it's almost as if you can extend HTML which has been notoriously resistant to extensibility for nigh on twenty years.

The fact that it integrates with my existing knowledge base (Javascript, ASP.NET AJAX) is also a big plus. It means Silverlight becomes a tool I can use when it makes sense. For example, I don't need to rewrite the entire application in Silverlight if I need some funky animation in one corner of the screen. I can drop in a control (or more likely, outsource it to a designer who knows how to make these things pretty) and carry on pretty much like I normally would. If the application calls for some fairly extensive processing and a lot of calls back and forth to the server, again, I now have another option.

Before John's initial presentation, I had a distorted view of what Silverlight would mean in my development world. Like it would revolutionize how I write my web applications. Afterward, I think I felt it was shifted back to normalcy but I felt there was something there I wasn't getting because its capabilities seemed to differ quite drastically from that distorted view. But then, we didn't really focus on the parts of Silverlight that make the marketers drool: namely, the media capabilities. The parts you will start seeing on the public websites for big corporate-type companies. My dissonance came because I think the hype applies more to these types of websites as opposed to the internal business apps I typically work with on a day-to-day basis.

I hope through all this philosophical rambling that it's clear that I did get the context I was looking for. The key to all of this, as it always is, is to remain focused on the end user. Given what I know of Silverlight's capabilities, what can I bring to the application that would make the user experience better? That was the underlying theme to the questions I had and I came away from our discussion much clearer on its place in my own personal world.

Kyle the Silverlit

Saturday, September 22, 2007

It's mind-boggling the amount of effort communication companies must put into their rate plans. I've resisted cell phones for that very reason alone. As soon as I see "if" or "provided that" or "after" or "before" my eyes glaze over and I get this unwavering urge to send the company some literature.

The main issue with the rate plans is that no matter which one I choose, I'll end up feeling stupid. Not only about whether I chose the right plan but also every time I would inevitably think, "I can't call X now because it'll be more expensive" or "I really should swap N for M in my top X list". And that's not even considering the idiocy I would feel for signing up for a contract. I've never signed a lease for three years. Not for an apartment and not for a car. So I'm sure as *%$@ not signing one for the right to get dirty looks when I forget to turn it off in a movie theatre.

This isn't just for cell phones. This little sidebar is being written from Lester B. Pearson airport in Toronto courtesy of www.boingo.com (the fact that that's not hyperlink is not an accident). In order for me to sign-up for their one day, $9.95 service, I needed to actually install something on my machine. Not even one of those idiotic ActiveX component that you have to keep open. This is a physical piece of software staring at me from the system tray. At the moment, it says I'm disconnected which I'm not. And yet, I couldn't get online without first installing it, then logging in.

And for completeness, they also lose points for their "lost password" mechanism. Namely, when I signed up, I had to provide not only a password but a four-digit PIN number in the event I forgot my password. My guess is that if you forgot your password, you would provide that PIN number and they'd send it to you via e-mail. Or maybe reset it. In any case, I would be embarrassed to even suggest you enter a four-digit PIN for *anything* in the 21st century. And you just know at least half the people signing up are using their bank PINs.

But it's hard to fault them completely for that kind of inanity. Like I said, I *did* sign up for it...

Kyle the Example

Friday, September 21, 2007

I'm faced with a bit of a quandary, which isn't so unusual except that this time, it doesn't involve a sister-cousin and a priest. I have carte blanche to work on an updated version of an application for my dad's company. And excited am I at the prospect of applying some of my recently obtained knowledge in a relatively unrestricted space.

The quandary I've been mulling over, though, is the UI. The original app is web-based and seven years old when choices were fairly limited when you built an app that needed to be accessible in multiple offices. It is fairly XML/XSL/XMLHTTP-y which is what I was into at the time but for the most part, it's your average everyday ASP app.

Fast forward to 2007 and your options include, but are not limited to: "Traditional" ASP.NET, ASP.NET AJAX, Smart Client/ClickOnce, Ruby on Rails, Silverlight, SharePoint, MonoRail, Spring.NET, ASP.NET AJAX Control toolkit, CAB (okay, I'm not really serious about that one), WPF, WCF/Web Services. And various combinations thereof.

And those combinations can be a little tricky. How does ASP.NET AJAX fit in with Silverlight? Can I reasonably use ASP.NET AJAX Controls within a MonoRail view? Is it even possible to get CAB to compile? It seems that making a decision to use one of these may have an impact on how to (or even whether to) use others.

So let it not be said that having free reign on a project is always a good thing. At present, I'm planning to fall back on my standard consulting strategy. Namely, start with technology that makes sense for the project and put all the shiny ones on my wish list aside. If I can justify at least investigating using any of them later, then I will.

Not that that makes the decision any easier. "SmartClient or web app?" is a pretty fundamental question with pros and cons on both sides. Hopefully, my one brother will insist that he has to be able to use it at home on his iMac in which case, I don't have to think about it. After that, I'll start with MonoRail (and add "of course" to that statement to make it sound like I roll with the big boys) and see where life takes me.

I've said it before: It's hard out here for a hillbilly.

Kyle the Chosen

Wednesday, September 19, 2007

After a year and a half as the sole developer on a content management project, where my programming was limited to writing utilities to assist with data loads and *shudder* writing OScript, it is freakin' fanTAStic being on a real development team again. And an agile(ish) one at that. It's great being able to discuss nice meaty problems like how to layer your application or how best to deal psychologically with the frustration that is the VSTS merge tool.

Now this being my first real agile experience (or at least the first one that's been officially called that), I'm not totally familiar with the conventions. But it seems to me that agile shops could benefit from a role that I'll call The Littlest Hobo, for lack of a better term. That is, someone who goes from project to project, lending a hand where pain points exist.

Many projects may have something like this in some regard. I imagine the scrum master plays this role for higher level impediments but I'm thinking at a more detailed level. Someone whose sole job is to pair with a developer for a morning on a task, then review code on a different project in the afternoon. The next day, he or she would examine the build process of a third project and see if it could be improved (and it always can). Another time, perhaps he or she could mentor someone on ReSharper shortcuts while they code.

Essentially, I'm thinking of someone working outside of a single project who can provide an outsider's perspective during the development process. And it doesn't necessarily need to be one person's full-time job. It could be a role that is passed around among senior developers every week. It doesn't even need to be a role that is fulfilled every week either. If you have a small group, maybe one person takes it for a week, and then it stays unfilled for a couple of weeks.

The impetus for this idea was an upcoming code review. Few people will deny the benefits of a code review in theory but in practice, I've been on both sides of the review and very often, there is no "ideal" time for a code review. Often, one or both of the reviewer and the reviewee are none too pleased to be ripped away from their work even if we recognize that it is something that needs to be done. It's difficult to coordinate a review time that isn't "crunch" time on one project, let alone two (presuming the reviewer is on a separate project).

That's where The Littlest Hobo could help out. This person's schedule could be almost set in stone save for the specific projects and people involved. E.g. Tuesday morning: Pair with someone. Tuesday afternoon: Review code on some project. Wednesday morning: Increase code coverage for some project. Thursday afternoon: Code review. Monday morning would be reserved for filling in the blanks where it says "some project" or "someone".

Personally, I think it would be a helluva fun role. Not full-time, mind you, but once every couple of months it would be a nice break from the ol' day-to-day, doncha know.

And for you nostalgic Canucks who are already singing it in their heads, here's the theme song.

Kyle the Nomadic

Wednesday, September 19, 2007

Today's post brought to you by honorary Hillbilly, Kevin Hemeon, who sent the following e-mail:

Dear Coding,

I realize you're a big mucky-muck who is too busy for the likes of the little people but my job, my life, indeed my very *soul* depends on being able to collapse an ASP.NET AJAX Toolkit CollapsiblePanel programmatically in a postback event, such as a button click. I've tried using myCollapsiblePanel.Collapsed = true but it doesn't work.

And I, being a blogger mindful of his readership, replied:

Kind and noble Kevin,

The solution to this problem is mere child's play and it certainly did *not* take me a good couple of hours wondering "WTF" while I stared in disbelief at what should be an obvious piece of code. You see, the CollapsiblePanel is "postback-aware" in that it will save its state during a postback and re-create it. This is very handy when you are submitting a form and you don't want to startle people who are easily offended by things such as UI elements that look different when a web page refreshes. That's the sort of behaviour that tends to lead to warnings on coffee cups, if you catch my meaning.

Unfortunately, this doesn't bode well if, in the postback, you want to alter its appearance manually. In this case, another line of code is necessary:

   myCollapsiblePanel.ClientState = "true";
   myCollapsiblePanel.Collapsed = true;

So you see, a simple solution for a simple problem (i.e. not a problem that appears simple but keeps you up all &*%$ night). Until next time, code strong and AJAX well.

Kyle the (De)Mentor

Tuesday, September 18, 2007

I'd like to think the developer who put this error message into Visual Studio had a good chuckle while he or she was doing so:

Kyle the Unattached

Wednesday, September 12, 2007

The hillbilly is feeling brief so I'll cut to the chase. The following test succeeds in NUnit but fails in MbUnit:

            decimal? nullableDecimal = 100m * 3.281m;
            Assert.AreEqual( 328.1m, nullableDecimal );

The error in MbUnit: Equal assertion failed: [[328.1]]!=[[328.100]]

The way to get this to pass in MbUnit (and still in NUnit) is:

            decimal? nullableDecimal = 100m * 3.281m;
            Assert.AreEqual( 328.1m, nullableDecimal.Value );

If you write out the value of nullableDecimal to the console you will indeed see that it is 328.100 so I suppose technically, MbUnit is correct in claiming that the values aren't equal, although it sure looks like it's comparing string representations rather than actual values.

So in this case, my opinion is that NUnit handles things better because it allows you to use the variable in a more natural way. I.E. It doesn't shove in your face the fact that the variable is nullable.

Caveat: Don't take this as an endorsement for NUnit. The hillbilly still prefers MbUnit because he likes to pretend it stands for "Mountain boy unit".

Kyle the Nullable

Monday, September 10, 2007

Have been following a small, but growing, discussion on various approaches to design. The initial post I saw was by Jeremy Miller on the various double D's (heh!) with a sort of rebuttal/clarification by Scott Bellware. Personally, I don't feel I'm experienced enough to add my thoughts on the various flavours of x-driven design but I would like to add one: UI-driven design. (And my apologies to whomever posted saying they like to start from the UI. That prompted this introspective but I forget where I read it first. Jeremy Miller or Tim Heuer maybe?)

At my current POB, we recently had a nice little design session where the team hunkered down and hashed out high-level pieces of the new feature. And while the ideas were flying around, I kept wondering how some of them would be presented in the UI. I asked more than once how the screen would look and I thought the same question even more but kept it to myself 'cause I think the team was getting a little annoyed at the question.

But I didn't ask in a "are you sure you've thought this through" kind of tone. There are many cases where I simply can't grasp the subtleties of a feature unless I see how it's going to work in the final product.

One feature we discussed: adding a user to a role for a particular project. There are any number of ways that could be designed, all valid, all maintainable, all happy and shiny. And if we were to build this in JP's Nothin' But .NET course, we'd pick one, build out the domain, add some database code, then add in a screen to tie it all together at the end. And it would be good, partially because it's a classroom setting and the example is somewhat canned but mostly because JP would have the solution in his head already.

But for me personally, I like to see the screen first. How is it going to be laid out? Does the screen show all users in all roles in all projects and let you maintain it on a global level? Or do you pick a project first and manage all the users within it? Or do you select a user and manage his or her project roles? Or both? These decisions could potentially have impacts on the design, not the least of which is defining what the aggregate root is.

It seems natural to me to start with the UI. Specifically, the view. The thing that holds all the controls but isn't wired up to anything. From there, I can drive out the domain pretty easily. I don't necessarily need to start at the presenter and work up to the database but at least I have something concrete in my head that I'm working toward. And it makes sense to me to work more from the mindset of, "how is the user eventually going to use this?"

There is a danger that you code too much to the UI. That you might pollute the domain with UI constructs. After all, what is a screen but a final visual representation of a user story anyway? So why bother with the screen? But when the user story is "An administrator should be able to add a super user to a project", that still leaves a lot of room for negotiation.

To tie things back to the example, we went back and forth on the responsibility of the screen. And it wasn't until we laid out exactly which components (i.e user controls) would be on it that it become more obvious what that responsibility was. And in this example, we didn't crowd around a computer banging out HTML. Our UI consisted of a bunch of boxes on a whiteboard. But when it was finished, let me tell you, this hillbilly had zero questions about how the design would look.

Kyle the User

Saturday, September 08, 2007

Oh all right already, I'll post on tabbed interfaces. I seriously thought this was a dead (or at least dormant) issue because the most meaningful conversation on it was over two years old. But shortly after my quick little swipe on it, it is again Jeff Atwood who is questioning the movement. I actually did have a fairly length post on this typed out a few weeks ago but deleted it during a "what was I thinking" clean-up of my computer.

Firstly, there are some pretty spurious arguments in the comments on his post. One of my favorites, which sums up a few others, is this one:

I seriously can't understand why you would want to have several browsers open at the same time even if you have 3 monitors. It's the whole point of tabbed interfaces. Just one browser for all the web-sites you have open. I normally have about 35 sites open and all is in one browser-window. I never have any trouble in finding one specific tab.

The crux of this argument seems to be: You should use tabs because they're there. I.E. Why open several browsers when you don't have to (even though I'm not going to tell you why you don't have to)?

Yes, the point of tabbed interfaces is so that you don't have to have several browsers open at the same time. But just because this solves that problem, doesn't mean it's a better interface than the original. My counter-argument is that it's easier *for me* to navigate 'twixt multiple browsers than it is tabs within a single browser.

The key there is that this is *for me* which was another reason I didn't originally plan to post on this. By and large, the context for browsing is task- and user-specific. If you are booting up your computer specifically to look through your RSS feeds and nothing else, I can see how tabbed browsing could be beneficial. I still don't totally agree with it even in that edge case but yes, it saves space (and I'd argue it isn't necessarily "valuable" space) and helps you keep everything in one logical place.

For me personally, though, I can only dream of a world where I'm doing only one thing at any given moment and that the one thing involves only browsing. As I type this, I have three browsers, two console windows, Outlook, two Visual Studio instances, and five Windows explorer windows open. The browser is the only application that can be tabbed (Visual Studio is within the context of a single solution but 'twixt solutions). And it is a *major* annoyance to have to switch 'twixt using Alt+Tab and Ctrl+Tab to get where I want to be.

Even more annoying: When I'm done with an app, I don't want to have to think about whether to type Alt+F4 or Ctrl+F4 to close it. My colleagues started to complain about me screaming "Mother Pusbucket!" too many times when I would close down the browser by mistake when what I really wanted to do was close the current tab.

Another reason for the sake of completeness because Jeff touches on it already: For the times when I do use the mouse, it's easier to select what I want by scanning the title bars along the task bar. I.E. I don't want to click on the task bar, then click on a tab. If I wanted to be overly statistical, that's a 100% increase in the number of clicks but frankly, clicking isn't exactly a time consuming application.

The only reason this mini holy war is going on is because of browsers. You could almost hear the groans from the northwestern US when reports started coming in about how much people loved tabbed browsing in Firefox. (I picture Ray Ozzie watching CNN going: "Ya gotta be kidding me. Aren't these the same people that complained that Word was an MDI?") Very few other applications are tabbed. Notepad++ and Console2 are the only two that come to mind (and thankfully, the latter isn't tabbed by default). So I don't understand why the big kerfuffle over browsers.

Ultimately, I simply don't understand the problem that tabs are meant to solve. Is it lack of taskbar space? If so, I'd probably use the taskbar grouping feature before I turned on tabbing. At least that applies uniformly to all applications, not just browsers. Plus you don't have the issue with accidentally closing an app or having to Alt+Tab, then Ctrl+Tab to what you want. But I don't particularly care how much space is taken up on the taskbar. I don't usually use the mouse to switch between apps anyway. Plus I use two monitors so space isn't an issue.

I like Jeff's idea of using search to find what you want. There are all manner of utilities to find programs/emails/documents/websites on your machine. Maybe we just need to extend this to include running (or recently run) applications. Kind of like the ReSharper Ctrl+E shortcut.

But the main reason I deleted the original post: Who am I to tell you whether or not to use tabs? Personally, I don't and these are my reasons. Whether or not they apply to you matters not to me nor, I'm sure, does it to you. If you like 'em, use 'em. Far be it for me to preach to you about user interaction practices.

But you should still turn them off.

Kyle the Single-Documented

Wednesday, September 05, 2007

Quick nugget o' information today 'cause I'm still on the clock.

MbUnit has a couple of command line parameters I've been using lately: filter-namespace and filter-type. Both can be useful when you have several hundred tests and don't want to run all of them when you're working on one area of the app.

The informational nugget: when you use either of these parameters, it will include tests marked with the Explicit attribute in your test run. Assuming, of course, those explicit tests are included in the filter.

Kyle the Filtered

Sunday, September 02, 2007

I recently attended John Bristowe's presentation on Silverlight. He was great as always and gave a good overview of the technology but I left the room not being as excited about Silverlight as I was when I went in.

Which isn't to say I'm not stoked about it. I'm a big AJAX fan and the idea of doing some of the more complicated or labour-intensive stuff in managed code is appealing. But there has been a tremendous amount of buzz on Silverlight. I've been following Tim Heuer's recent adventures in it with a tinge of jealousy because I'm still not playing with it a lot. And when Ray Ozzie touts the next big thing, people listen.

I had done my own "hello world" app early on and was suitably impressed. In the intervening months, the buzz just kept growing and growing to the point where I went into the presentation trying to see what else there was to it. I knew it was being positioned as a Flash-killer (or at least that's what the buzz was) but I had to see what I had missed in my XAML.

Turns it out, not much. Yes, it's a Flash-killer (whether John wants to say the words or not) but as far as I can tell, that's it. At the end, I was scratching my head about why everyone was so worked up about it. You're still working with textboxes and input buttons and wiring up the events the same way you would in HTML and Javascript, albeit in a *much* easier way. And probably prettier too once the designers get hold of this. You still have the same security limitations of Javascript. In particular, you still can't call webservices outside your domain. (This was one of the problems I thought Silverlight may have solved. They're working on it but for the moment at least, you still need to call back to your own domain.)

The essence of my puzzlement is that I don't understand why so many people think this is going to revolutionize the web. I mean that as a genuine question, not a cynical dig. Is it because of the presentation-aspect? That Silverlight can make apps that much more appealing visually? If so, how is it different than Flash? To be sure, the airline demo *is* impressive (and I sincerely hope someone is making an effort to do a real-world version of it).

I dunno, maybe I am underestimating the popularity of Flash. It doesn't seem like a very threatening technology to kill off. I'm probably not recognizing the value of the media-centred features of Silverlight as well. This is probably the big selling point for the executives at Microsoft, especially in an era where YouTube can be sold for $1.65b.

More likely, I'm probably underestimating the pain new web developers are feeling trying to get Javascript to do things people have come to expect from their web apps. Early in the presentation, John asked, "Who *likes* working with HTML, CSS, and Javascript?" It was a loaded question and I didn't want to get him off-track early in the presentation but to be honest, I do. Not at the expense of "real" development but I actually don't mind diving into Fiddler with XMLHTTPRequest objects, spewing alerts all over the screen. Not all day, every day but I like mucking with the DOM in a crappy dynamic language once in a while. It's my version of slumming it.

Silverlight is still in the top three on my technology wish list. I can think of quite a few applications that could benefit from it, not the least of which is the near-defunct music player I work on in fits of ambition. So I'll fiddle around with it in the coming months because it fits with my sensibilities. And if I'm lucky, it'll be as popular as everyone says it will and I'll be able to keep the young'un fed for the next couple of years.

Kyle the Aligned

Sunday, September 02, 2007

The ASP.NET Ajax Control Toolkit has a hate-on for namespaces, let me tell you. Their sample works slicker'n a greased hog when you use nice project names like "DisableButton" or "AlertBox". But use a name like "Suvius.DynamicFamilyTreeSorter" and you're in for a world of hurt.

Side note: Call me old-fashioned, but I like having the namespace in my project name. Saves me having to muck with assembly names in the project properties and makes things obvious when I'm staring at a twenty-project solution with four projects named DataAccessLayer. Plus it fosters creativity in naming if the project contains classes from different namespaces.

So what's a hillbilly to do if they like seeing they're comp'ny name embedded in the control project name? Let's assume you have just created an AJAX Control project with the name "Suvius.DynamicFamilyTreeSorter". Your project will contain three files:

• Suvius.DynamicFamilyTreeSorterBehavior.js
• Suvius.DynamicFamilyTreeSorterDesigner.cs
• Suvius.DynamicFamilyTreeSorterExtender.cs

The first task is to rename each of these files, removing "Suvius." from the beginning of each. After that, here are the steps for the contents of each file:

DynamicFamilyTreeSorterBehavior.js

• First non-commented line of code: Change the namespace to Suvius
• Last non-commented line of code: Change the first argument in the call to registerClass to Suvius.DynamicFamilyTreeSorter (i.e. removing the trailing ".Suvius")

DynamicFamilyTreeSorterDesigner.cs

• Remove "Suvius." from the name of the class
• Remove "Suvius." from the generic part of the ExtenderControlBaseDesigner<> declaration. This isn't totally necessary but helps keeps things clear

DynamicFamilyTreeSorterExtender.cs

• Remove "Suvius." from the name of the class
• Remove "Suvius." from the [Designer] attribute
• In the [assembly: WebResource] declaration, remove the *second* "Suvius.". I.E. It should read

  [assembly: WebResource("Suvius.DynamicFamilyTreeSorter.
  DynamicFamilyTreeSorterBehavior.js", "text/javascript")]

• In the [ClientScriptResource] attribute, remove the *second* "Suvius." from *both* arguments, similar to the previous step

For the longest time, I was getting a run-time error: Assemby 'yadda yadda' contains a Web resource with name 'Suvius.DynamicFamilyTreeSorter.DynamicFamilyTreeSorterBehavior', but does not contain an embedded resource with name 'Suvius.DynamicFamilyTreeSorter.DynamicFamilyTreeSorterBehaviour.js'. This after I had performed all the steps above. Except renaming the files in the first place.

So it would appear that WebResource locates files based on their location (replacing slashes with dots). Lesson learned. Or at least documented.

*EDIT*

One more step: In DynamicFamilyTreeSorterBehavior.js, replace all instances of Suvius.DynamicFamilyTreeSorterBehavior.Suvius with Suvius.DynamicFamilyTreeSorterBehavior.

Kyle the Assembled