Jeff Atwood's recent post Pair Programming vs. Code Reviews reminded me that I should post about my recent experience pair coding.

I spent the majority of the last three weeks pair programming with a co-worker rebuilding a UI framework that we've used before but lost the source code.  In my opinion, this was a perfect opportunity to try out pair coding.  We had two people remembering what types of things we did before, and what kinds of problems we encountered and wanted to avoid.

The thing that most suprised me about pair coding was how intense it was.  It was impossible to get distracted because the other person is there keeping you focused.  It was pretty exhausting compared to a normal day.  The best word I can think of is relentless.

Also, the quality of what we built is so much higher than I could have accomplished in the same amount of time.  I definitely think that the work we did was better than what we could have done working alone.  My partner saved me from writing so many bugs that I had no idea I was doing.  Granted, most of these would have been found by the compiler or the first time we tried to run, but I think it saved a lot of time.

Perhaps the best part of this period of pair programming is that I know everything that we did, not only my half of what was done if we had been working separately.  This was a key part of the situation because my co-worker had put his 2 weeks notice in.  I only hope I have a chance to work with him again.

Would I do it again?  You bet!  I now have no doubt that two developers can get just as much work done together that they could have done separately, and I think the quality is much better!

I finally got around to setting up my dasBlog blog on my new site.  I just got done importing my blogger posts to this blog using Nick Schweitzer's walkthrough.

There are a few kinks to work out, such as getting a configuration error whenever I try to view comments on old posts.  Also, the config error page is prompting for log in since it's in a directory that I don't allow access to.

I also want to find a better template and get around to personalizing it.  I think I'm going to try implmenting parts of the template in Silverlight.

UPDATE - I set up FeedBurner for my feed.  Until I set up my template with a better link, here's the link - http://feeds.feedburner.com/ProgramWithDotNet

So I'm here at the Silverlight DevCamp in Chicago with my colleague at Quick Solutions, Steve. We're just about to get started. It looks like the schedule for tomorrow is pretty full and will be going more in depth than the high level, overview types of presentations. I'm excited!

Labels: silverlight, SilverlightDevCamp

I haven't posted in over a week about my progress with my 30 day sprint to learn Silveright because it died. Right after the last post I ran into several roadblocks, the largest of which was the loss of enough free time to regularly spend the time needed. Also, after a couple of days of inactivity I lost my motivation.

This morning I realized that today is the 30 day mark. So did my expirement fail? In the sense that I didn't spend the hour per day that I pledge to myself, yes it did. But, in the sense that I learned a lot about Silverlight and got myself into more of a habit of setting aside time to learn, it was a success.

The next time I decide to do a sprint of this kind, I will check with my event planner (my wife) and make sure that the schedule will allow for the time I want to spend. Also, I think I'll go for a shorter time span. I think my next sprint will probably be either 2 weeks or 15 days, and I might try to lay out a goal for each day ahead of time.

Right now I'm involved in a project in my free time to build a Silverlight application that has a pretty aggressive timeline, but I'll try to post examples of things I've figured out or problems I ran into along the way. I also have several ideas of some fun apps to write that I'll blog about as well.

Labels: silverlight, sprint

Tonight was the first chance I've had to spend any time with Silverlight since the weekend. When it rains, it pours. When septic tanks back up, you have to rearrange your priorities a bit.

Tonight I started a new Silverlight 1.1 project in which I created a few textareas that I'm planning on reading and modifying through my Silverlight application. I was going through the Dom Access Quickstart and only made it to the third step in the first section before hitting a roadblock.

The quickstart says to create a variable of type HtmlDocument, but Visual Studio doesn't list it in Intellisense! My first thought was maybe that the System.Web name space needed to be referenced, but when I tried to add a reference to the project I didn't see it as an option. In fact, there are only a handful of assemblies available to reference by default.


My next thought was to hit the Silverlight.net Forums and look for a post where someone else had the same problem. Guess what? The forums don't have a search function. After reading through 3 pages I gave up and tried Google.

My search for 'silverlight htmldocument' led me to "Silverlight how-to: let the DOM interact with Silverlight". While the demo is very basic and regurgitates what's already available in the Quickstarts, it had one piece of information that made all the difference: it mentions that I need to add a reference to System.Windows.Browser in order to get to the HtmlDocument.

In retrospect, I could have probably found this a lot quicker if I'd just searched for HtmlDocument on MSDN. However, when I tried this, all I found was links to HtmlDocument in System.Windows.Forms. Buried in the search results I did find a link to Dave Relyea's post "Calling Javascript from C#" which is a much better resource.

This solved my problem and I'm ready to move on. Maybe tomorrow I'll be able to make some headway on some of the ideas I want to try.

Labels: silverlight, sprint

Component One has a controls suite called Sapphire for Silverlight 1.1 that has a lot more promise than the Telerik one.

And there's a textbox control! Too bad that hitting backspace in their textbox trigger's Firefox's back button. I found that bug in the first 10 seconds. Too bad.

Labels: silverlight

Telerik released it's RadControls for Microsoft Silverlight product on the same day Silverlight 1.0 was released. The cube control is cool, but the other ones don't really seem to be all that special. The button and layout controls in particular will probably be obsolete once Silverlight 1.1 is released. Still, it's nice to see what kinds of things will be available soon.

Labels: silverlight

I found that there are some generic controls included with the Microsoft Silverlight 1.1 SDK Alpha September Refresh. (We need an abbreviation for that; it's too long. How about MS1.1SDKASR?)

From the Welcome page in the MS1.1SDKASR, click on the Sample UI Controls for the readme, which includes this:

This package contains sample source code for some common
UI controls for the Silverlight managed code framework.

You may customize these controls and use them in your
Silverlight applications.

In this package, you will find a functional solution
with C# code files representing control behavior and XAML
markup files representing the visual aspects of the control.
Also included in the solution is test code that demonstrates
usage of the controls, how events can be hooked up and
handled, etc.

The following sample controls are included:
* Button
* Slider
* ScrollBar
* ScrollViewer
* ListBox

Wha? No Textbox control? Let's hope that they're working hard on one and it makes it into the 1.1 release.

I spent the day pretty much going through the sample controls and seeing how they work. I don't think they're suitable to be used in a production application, but they're good for learning.

Labels: silverlight, sprint

Day 12

On Day 11 I came to the realization that there wasn't any supported XAML in Silverlight that allowed text entry and that you had to tie your Silverlight app to an HTML textbox/textarea in order to do this.

I decided to try putting an HTML textarea over a Silverlight app and see how I could get them to work together. I wanted to have a javascript method called when the contents of the textarea changed, and have that javascript method call into the Silverlight app. After an hour or so of frustrating trial and error and reading through documentation online, I realized that you can't call Silverlight 1.0 from javascript.

Day 13

Up to now I've been working on a system with the Silverlight 1.0 SDK and Visual Studio 2008 March CTP. I have a very slow internet connection and my laptop leaves a lot to be desired, so this was holding me back from installing Visual Studio 2008 Beta 2. Last night I decided the time had come.

I had started the download of Visual Studio 2008 the night before, which took around 23 hours. At around 8pm I uninstalled the March CTP, then uninstalled all .NET 3.5 stuff hanging around. This all took almost an hour and a half. I then installed Beta 2, the Alpha Tools, and downloaded the Silverlight 1.1 Alpha SDK.

At this point it was almost 11pm and I was out of time to spend for the evening. So much for my Day 13 of the sprint. I realy hope to get further on the text entry experiments this weekend.

Labels: silverlight, sprint

I noticed this morning that the Silverlight Get Started page states that there's a Silverlight 1.1 Alpha September Refresh. I don't remember seeing anything in Scott Guthrie's post about a September specific version of the 1.1 Alpha Refresh. I downloaded the file and it has the same size and version as the 1.1 Alpha Refresh that I downloaded last month. The Get Started page also has a link to the Silverlight SDK 1.1 Alpha September Refresh. What's going on here?

I found this comment from Scott Guthrie in his above mentioned blog post.

The 1.1 refreshes from MIX to now have mainly just been updates to keep in sync with the Silverlight 1.0 code-base. Now that Silverlight 1.0 has shipped, the upcoming refreshes of 1.1 will be feature updates with more functionality. So you'll start to see more functionality appear soon.

Labels: silverlight