Digital Wall – redux

I posted last week about the release of Digital Wall to the internet – the application that lets you graffiti on our office wall from your browser. Well I was so pleased with how it performed that I scrapped the entire codebase and started again from scratch. Mostly I did it because the original version was the first time I had played with Silverlight, WPF and WCF, so I realised there was a lot that I would do differently a second time around which would make adding cool features easier. So I did it, and I added some cool features.

The new version is up at http://wall.tequila-uk.com. A number of things are different:

 

• I can now write a welcome message on the server which will appear in your browser. I can write the welcome message in XAML. I do that using Mike Snow’s excellent tip for loading XAML into a control at runtime.
• As well as drawing on the wall, you can now add images to it. You have two options for doing this – upload an image from your hard-drive, or provide a link to an image on the internet. Then you get to drag the image around and scale it as you desire. When you’re happy with it just click the Send button or switch to the Brush mode to have the image sent to the server.
• The webcam is still pretty poor, so the Silverlight client will now download the server’s representation of the wall as objects and display it in your browser, overlayed on top of the stream. You can adjust the transparency of the overlay by clicking the button at the bottom of the toolbar. There are three settings: off, transparent and opaque. This way you can draw moustaches and fake wangs on people much more easily.
• You can identify yourself (this is optional) and see who else is using the wall at the bottom-right corner of the screen.

 

And of course the wall is publishing canvases out through a number of different channels:

 

• Twitter: http://twitter.com/DigitalWall
• TwitPic: http://twitpic.com/photos/DigitalWall
• RSS: http://feeds.feedburner.com/DigitalWallPhotoStream

 

Previous posts: Digital Wall Goes Public, Digital Wall (provides a video demonstrating what it basically does)

To talk to me about the wall you can message me on Twitter.

Enjoy!

Team Build 2008 and Visual Studio 2008 Web Deployment Projects

I wrote a post earlier this year about how difficult it was to get VS 2005 Web Deployment Projects and Team Build 2005 to play nicely together. Well in the 2008 versions it looks like they put some effort into removing a lot of the friction, so I want to explain how it works now and shout out that it’s much, much better than it used to be.

For the purposes of this example I created a simple website project, a web deployment project, and a basic build definition. There is a lot of information about how to create a team build definition in TFS 2008 so I’ll just gloss over that. The important points here are: a) the inputs (a website and a web deployment project) and b) the outputs.

The Build

1. The sample solution

2. Creating a build definition

3. Select the solution to build

4. Select the platform and configuration (Mixed Platforms and Release)

5. Finish

6. Create a build agent and enter the drop/staging location for the build

Next I ran a build, and here’s what came out:

The result of the build

 

Notice that within the _PublishedWebsites folder are two folders: ‘Website’ and ‘Website_deploy’. In this example they are identical; if I had set up custom web config replacements then in the ‘Website_deploy’ folder would be a customised web.config file.

If I hadn’t created a web deployment project, the Team Build would still create the ‘Website’ folder and deploy a compiled website. This is important because I believe that didn’t happen with Team Build 2005, it just dumped the compiled assemblies into the Release folder. (Please correct me if I’m wrong).

Deploying where you want

The next thing you (probably) want is to have the deployable website copied from the timestamped drop location to a static location for an IIS website. Here’s how to modify your build script to do this:

1. In the solution explorer, right-click on the build definition and select View Configuration Folder.

Select View Configuration Folder to see where the script is stored in source control

2. The files will not be downloaded to your machine yet – highlight them, right-click and select Get Latest Version. Now double-click the TFSBuild.proj file to open the build script.

 

Open the build script file

 

 

3. Now paste the following into the script, just before the closing </Project> tag:

   <PropertyGroup>

    <WebBinariesLocation>$(BinariesRoot)\Mixed Platforms\Release\_PublishedWebSites</WebBinariesLocation>

  </PropertyGroup>

  <Target Name=“AfterCompile“>

    <Message Text=“Copying from out $(WebBinariesLocation) to $(DropLocation)“/>

    <RemoveDir Directories=“$(DropLocation)“ Condition=“Exists(‘$(DropLocation)’)“/>

    <ItemGroup>

      <ProjectSourceFiles Include=“$(WebBinariesLocation)\**\*.*“/>

    </ItemGroup>

    <Copy

        SourceFiles=“@(ProjectSourceFiles)“

        DestinationFiles=“@(ProjectSourceFiles->’$(DropLocation)\%(RecursiveDir)%(Filename)%(Extension)’)“>

      <Output

          TaskParameter=“CopiedFiles“

          ItemName=“SuccessfullyCopiedFiles“/>

    </Copy>

  </Target>

What this will do is copy each of the deployment folders in the _PublishedWebsites folder directly into the drop location you specified in step 6 of creating the build definition (above). You don’t need to add anything specific to do with the project (other than the Mixed Platforms\Release path, but this won’t change between build projects). If you set up deployment projects for staging and production you will end up with 3 deployed websites (development, staging and production). Nice!

Obviously for the build to include the script changes you just made you need to check the file back in to source control.

Hope this clears things up.

Digital Wall Goes Public

You can now draw on the wall yourself! Go here to try it out: http://wall.tequila-uk.com/

I explained concept in my previous post, but in a nutshell you can graffiti on one of the walls in our office. Like, the actual wall. Eventually I want to set this up somewhere more interesting, like in our reception area, but there are some logistical issues with that so for now it’s just in the office.

Screen captures are being published via TwitPic, so you can keep up in various ways:

Twitter: http://twitter.com/DigitalWall

TwitPic: http://www.twitpic.com/photos/DigitalWall

RSS: http://feeds.feedburner.com/DigitalWallPhotoStream

There are a couple of obvious things that still kinda, well, suck.

1. You can hardly see what’s on the wall via the webcam feed. This is because we’re just using a £5 logitech quickcam, and because the wall itself is in our office under halogen lights.

2. When you add something to the wall it takes a good 30 seconds before you see it in the webcam feed. I had thought this was because the camera feed was too high-bandwidth, but I’ve done a load of tweaking and I’m convinced now it’s simply because of the latency between our office, StreamWebTown and the browser. Whatever you draw shows up on our wall immediately, trust me.

We’re looking at ways to improve it, but at the moment it seems making it really good will take cash. Unfortunately, because this is just pure folly, it probably won’t improve.

Anyway, enjoy.

Digital Wall

Drawing Something Together

I’ve been working on a cool little project over the last few weeks. The original idea was inspired by the amazing laser-pointer graffiti these guys did, but I wanted to provide more of a collaborative, distributed angle. I wanted to let anyone see a live feed of a real physical wall, and be able to draw on that wall in their browser and have their doodling reflected in the real world.

So I came up with this:

Digital Wall Architecture Diagram - not to scale

I’ll touch on each of the architecture points in turn.

Application Layer

At core the wall relies on a WPF application which is reponsible for actually drawing the current digital wall image on the physical wall using a projector. I used an InkCanvas control to display any drawing data that is ‘current’ (meaning it hasn’t been wiped off the wall yet). The drawing data for the control can be created remotely in Silverlight or directly at the machine using a Wii remote, using Brian Peek’s Managed Library for Nintendo’s Wiimote.

The drawing data is stored in a SQL database, which has a single table Drawings. Each row in that table is a single ’stroke’, in the sense of what you draw between pressing the left mouse button down and lifting it up again on the canvas. Any drawings stored in the table are swept up by the WPF application, added to the InkCanvas’ strokes collection, and then the whole canvas is captured to an image. That image is then applied to the application background and the InkCanvas’ strokes collection is cleared out. Using this technique I was able to get some performance improvements out of the application because keeping loads of Stroke objects in memory was way to intensive.

The application is also encoding a webcam stream of the physical wall, so that anyone connecting in their browser can see actual footage of the wall. I could have just downloaded the drawing data directly to Silverlight and rendered them in the browser using the same method as the WPF application, but I wanted to give remote users a real sense that they’re changing a physical environment. We’re using Windows Media Encoder to encode the stream and a service called Stream Web Town to make the stream available for broadcast. SWT provide a free streaming service which is limited in a couple of ways but dead useful to get a simple proof of concept up and running.

Finally the app is screen capturing the current wall every minute or so and saving out to a predefined network location, so we can see a complete history of what gets drawn. This is essential because currently the wall erases itself every 10 minutes, so it’s the only way people would be able to see what they’ve drawn.

The Browser

The Silverlight application is doing three things. First, the webcam feed is being streamed to the background of the canvas, so a user can see exactly what’s already on the wall. Second, another InkCanvas control allows the user to draw directly on the canvas. Third, when you’re ready the Silverlight app will send the drawing data to the database for the WPF app to pick up.

The communication layer was written in WCF and basically consists of a single method AddGeometry(), which requires some simple data like IP, colour and the actual data, which is just a list of points serialised to comma delimited values. The website that the Silverlight application available at is also hosting the WCF service. It also provides an RSS feed of all the screen grabs saved from the WPF app.

Cool so that’s a brief explanation of what I’ve built, I’ll try to get some more information up at some point, and more pictures and video too.