A picture of me

Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool for .NET applications.

Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.

App.net recently caused a stir by promising to create a social network that users pay to use. This is an interesting idea because it means that the network will make money directly from users, rather than through advertisers, so there is more incentive to make the network nice to use.

That said, I'm not sure how new this is. I've been "paying" to use social networks for some time. Not directly to the network, but indirectly through the costs of being on the network:

  • The cost of maintaining my profile and keeping it up to date (photos, current job, location, interests)
  • The cost of responding to friend requests and other emails/notifications
  • The cost of ensuring my privacy settings are set correctly and I am sharing content with the right audiences
  • The risk of my account being compromised and having to respond to events like resetting my LinkedIn passwords

I put up with these costs because there's some value I expect to get out of the social network. Although I deleted my Facebook account a while ago, I re-created it recently just to connect to some relatives, because that's valuable to me. I get value from Google+ in the interesting links people share, and I get a lot of value from Twitter due to the discussions that take place.

LinkedIn, on the other hand, is a social network that I could never figure out. For years, I kept my profile up to date, accepted friend requests, and put up with recruiter emails. I even joined a bunch of discussion lists, only to find they were really just recruiter hang outs too. I would log in, and look through my stream, but the only interactions were "Joe is connected to Bob", or occasionally "Joe has a new job" (which, depending on who Joe was, I either already knew or didn't care).

So after years of "paying" to be a member of LinkedIn, I asked myself, what value am I getting from this network? I have 306 connections, but what does that mean?

Closing...

Real networking is about interacting with someone - discussing ideas, finding shared interests, learning about who they are and what they stand for. You can interact with many people in many places. Chat with them on Twitter or Jabbr. Join mailing lists that they frequent. Talk to them.

The kind of faux networking created by LinkedIn reminds me of when I was a six year old at school, and kids would ask each other "will you be my friend?". As adults, friendships come about implicitly because of interactions and communication, not from asking to be someone's friend and then accepting said friendship request.

After all, the primary piece of information on LinkedIn is your employment history. And who cares about employment history? Only employers and recruiters. Banks won't hire you unless you've worked in banking (because they only want people who will repeat the same mistakes over and over, not people who will make new mistakes), so they want to see that you worked at a bank in 2003. But the people you really want to network with - the programmer who could expose you to a cool concept in Erlang, or who could collaborate with you on your open source project - they aren't interested.

LinkedIn is a network built around "Joe now works for Acme". But I realized that where Joe works doesn't actually matter. I follow tons of interesting people on Twitter without knowing where they work, because it's their ideas that are interesting. I learn a lot from interacting with other people, not reading about what their job responsibilities were at some company I never heard of in 1998.

In fact, the more I think about it, the more I think LinkedIn is just a giant scam invented by recruiters to improve the chances of finding the right candidate. It's like every other job service/employment gateway except there's a social graph to improve results. 99% of people get no value from it, but don't want to leave for Fear of Missing Out. So like me, they log on once a month to accept 34 meaningless "connections" from people they either already know or have never heard of, and delete a handful of spam, just for the one in a million chance that this is the week that there'll be a job offer that involves a writing Ruby on a tropical island and a six figure signing bonus.

To cut the story short, I couldn't see how the benefits of being on LinkedIn outweighed the costs, so I deleted my account.

Bye bye LinkedIn

You might be one of the 5% that actually get value from LinkedIn. Maybe you do a lot of short term work, or you are looking for new opportunities (but between us, I think the people who you really want to work for are probably more interested in your blog and Twitter and GitHub than where you worked in 1998). I'm not, so I'm out.

The $50 fee to join app.net may be high, but it's not the only cost of joining a social network. The real question will be what kind of value will the $50 get me? What kinds of meaningful interactions will I get from the service?

(This started as a Google+ post, but since those words are wasted, I decided to blog it instead)

I do all of my work on a laptop, which I recently repaved for the new software Microsoft released last week. I thought it might be interesting to share the configuration.

Hardware

At the moment I survive on the single LCD monitor plus laptop screen, though when I return to Australia I'll add a second 22" monitor. I've used more expensive keyboards from Logitech in the past but the Microsoft Wired Keyboard has a very nice feel to it when typing.

Here is my WEI rating. The graphics performance is normally much higher, but I'm only using the built-in Windows 8 driver instead of drivers from the graphics vendor because, well, they seem very crashy.

Windows Experience Index

Software

Although I'm using Windows 8, I spend all of my time in the desktop, and haven't installed any Metro Windows 8 style applications from the application store yet.

So far I've managed to avoid installing SQL Server or any older versions of Visual Studio. I think if that time comes I'll set up a virtual machine using VirtualBox.

What does your 2012 hardware/software configuration look like?

Visual Studio 2012 shipped last week, so I'm working on a branch in Octopus Deploy to upgrade the ASP.NET frontend of Octopus to ASP.NET MVC 4.0. My main reason for upgrading was the inbuilt bundling and minification support, which is awesome.

Octopus provides a RESTful API (browse to /api on your Octopus server), which serves up documents in JSON like this:

[
  {
    "Id": "DeploymentEnvironments-1",
    "Name": "Production",
    "Description": "A production environment",
    "SortOrder": 0,
    "Links": {
      "Self": "/api/environments/DeploymentEnvironments-1",
      "Machines": "/api/environments/DeploymentEnvironments-1/machines"
    }
  }
]

Web API wasn't stable when I first built it, so I implemented it on top of ASP.NET MVC 3.0 using a custom ActionResult that used Json.NET. It doesn't support content negotiation, so everything is JSON-only. So when it came time to upgrade, I was also excited to try and convert my REST API to use ASP.NET Web API.

The ASP.NET team has been focussed on "one ASP.NET" for a while. Scott Hanselman sums it up with a nice image, which I'll shamelessly hotlink:

One ASP.NET to bring them all and in the darkness bind them

ASP.NET MVC and Web Forms have definitely done a lot of work to integrate, but ASP.NET Web API, I think, has a long way to go.

For instance, you'll be familiar with routing in ASP.NET:

routes.MapRoute(
  "Default", 
  "{controller}/{action}/{id}", 
  new { controller = "Dashboard", action = "Index", id = UrlParameter.Optional }
);

You can also do routing in ASP.NET Web Forms:

routes.MapPageRoute(
  "products-browse", 
  "products/{category}", 
  "~/Products.aspx"
);

Of course, as one would expect, both of these build on top of a shared routing system provided by the green ASP.NET box at the bottom of the diagram.

Naturally, you can also do routing in ASP.NET Web API:

routes.MapHttpRoute(
  "DefaultApi", 
  "api/{controller}/{id}", 
  new { id = RouteParameter.Optional }
);

You would expect this to be built on top of the same routing framework. Right? Right? Wrong!

ASP.NET MVC and Web Forms use classes like RouteCollection and the RouteBase abstract class. ASP.NET Web API on the other hand makes use of HttpRouteCollection and IHttpRoute. Of course, the reason they need a second copy becomes clear when you see the vast differences between the two.

For example, IHttpRoute has methods like:

public interface IHttpRoute
{
    IHttpRouteData GetRouteData(string virtualPathRoot, HttpRequestMessage request);  
    IHttpVirtualPathData GetVirtualPath(HttpRequestMessage request, IDictionary<string, object> values);
}

While ASP.NET's routing RouteBase class has completely different methods like:

public abstract class RouteBase 
{
    public abstract RouteData GetRouteData(HttpContextBase httpContext); 
    public abstract VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values);
}

My guess is that this duplication exists because ASP.NET Web API is designed to also operate outside of IIS. But if we're serious about "One ASP.NET", why not do it properly and make the whole stack run outside of IIS? (It can be done now actually, but it is very painful and breaks a lot).

The madness doesn't stop here. ASP.NET Web API ApiController classes don't inherit from the ASP.NET MVC Controller class. ASP.NET gives you a UrlHelper class to generate URI's from the route table, while ASP.NET Web API has its own completely separate (and less nice) UrlHelper class. ASP.NET provides some well known basic types like HttpRequest and HttpContext. Web API has its own alternatives. Filters are the same but different. Both stacks have their own dependency resolver. Both have their own model binders. Both have their own model state/validation. The list goes on and on.

Here's a more correct image:

One more ASP.NET

While both frameworks work, it's hard to say they "work together". I'm finding myself creating a bunch of wrapper classes and adapters so that I can do basic things like generate URL's when I'm in either context. It all feels very messy.

Right now, the only reason I can think of moving to ASP.NET Web API is content negotiation, but making ASP.NET Web API generate nice looking XML and JavaScript off the same model also seems to be a lot of work, so I'm not sure there's much to gain there.

(Part of me wonders whether content negotiation and a few REST idioms should just have been implemented in ASP.NET MVC, which would really obsolete the whole Web API project.)

If I could have one wish for ASP.NET 5.0, it would be to stop having "one ASP.NET", and instead to have one ASP.NET.

Prior to working full time on Octopus Deploy, I spent a year building a risk system using WPF, for traders at an investment bank. Before that I worked as a consultant and trainer, mostly with a focus on WPF. I've lived and breathed the technology for the last six years, and in this post I'm going to share some thoughts about the past and future of WPF and the XAML-ites.

Six years ago, I wrote an article about validation in WPF on Code Project. I also wrote a custom error provider that supported IDataErrorInfo, since, would you believe, WPF in version 3.0 didn't support IDataErrorInfo. Later, I worked on a bunch of open source projects around WPF like Bindable LINQ (the original Reactive Programming for WPF, back before Rx was invented) and Magellan (ASP.NET-style MVC for WPF). I was even in the MVVM-hyping, Code Project-link sharing club known as the WPF Disciples for a while.

As I look back at WPF, I see a technology that had some good fundamentals, but has been really let down by poor implementation and, more importantly, by a lack of investment. I'm glad those days are behind me.

Back in 2006, here's what the markup for a pretty basic Window looked like (taken from an app I worked on in 2006):

<Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
  xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
  xmlns:system="clr-namespace:System;assembly=mscorlib"
  Title="TrialBalance" 
  WindowState="Maximized"
  Width="1000"
  Height="700"
  Icon="{StaticResource Image_ApplicationIcon}"
  Background="{StaticResource Brush_DefaultWindowBackground}"
  x:Name="_this"
  >

I mean, look at all that ceremony! x:Class! XML namespace imports! Why couldn't any of that stuff be declared in one place, or inferred by convention?

Fortunately, it's now 2012, and things have come a long way. Here's what that code would look like if I did it today:

<Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
  xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
  xmlns:system="clr-namespace:System;assembly=mscorlib"
  Title="TrialBalance" 
  WindowState="Maximized"
  Width="1000"
  Height="700"
  Icon="{StaticResource Image_ApplicationIcon}"
  Background="{StaticResource Brush_DefaultWindowBackground}"
  x:Name="_this"
  >

Spot the difference? Of course not, it was a trick question, nothing has changed since 2006 that would have made that less verbose.

In contrast, here's what a web page looked like in ASP.NET in 2006 (also taken from a project in 2006):

 <%@ Page Language="C#" MasterPageFile="~/TrialBalance.Master" AutoEventWireup="true" EnableViewState="false" CodeBehind="Builds.aspx.cs" Inherits="PaulStovell.TrialBalance.MainWebsite.Builds" Title="Downloads - TrialBalance" %>
 <asp:Content ID="Content1" ContentPlaceHolderID="MainContentPlaceholder" runat="server">
  <asp:PlaceHolder runat="server" Visible="false" ID="_downloadAreaPlaceholder">
    <h1>Download</h1>

What would that markup look like today?

@model BuildsViewModel

@section Main {
  <h1>Download</h1>
}

I originally became a WPF developer because I didn't like ASP.NET Web Forms and models like View State. But now, when I look back at the journey ASP.NET has taken, it has made huge changes. From the Web Forms model to the MVC model, from ASPX syntax to Razor, there's been some real innovation in the ASP.NET camp in that time. There have been some real innovators in the ASP.NET camp in that time.

Here's a list of things ASP.NET has done in six years that WPF hasn't:

  1. Created a new, human-friendly markup language (Razor). Razor makes writing markup fun. XAML has never been fun. In fact before ReSharper introduced the 'Import namespace' support for XAML, it was downright torture.
  2. Embraced design patterns. You can't claim MVVM here for WPF - WPF supports data binding, but the core of WPF doesn't actually contain a single feature that helps with MVVM; it's all layered on top through Blend Behaviors and third party frameworks. ASP.NET has an entire stack built on top of MVC.
  3. Embraced the pit of success. You can actually build a maintainable application using ASP.NET MVC using the default project template. In contrast, without third party frameworks, the default WPF project template is the path to misery.
  4. Embraced extensibility. Nearly everything in ASP.NET MVC has an interface or abstract class that you can extend to change how the framework works. There's a beautiful pipeline that you can plug into. I'd swear the WPF team never even heard of an interface, and the only abstract classes have internal constructors.
  5. Embraced open source. ASP.NET MVC bundles jQuery and JSON.NET, and it's designed to work with a ton of open source tools. WPF, despite the litany of MVVM frameworks, and despite it being impossible to develop maintainable WPF applications without one, still hasn't embraced any of them.
  6. Become open source. ASP.NET MVC was open source since early on, but now the entire ASP.NET stack is open source, and accepts contributions. WPF isn't, and frankly, you wouldn't want to look at the WPF code anyway; it's hideous.

On top of all of this, you've got the innovation that's happening on the web stack itself. Don't like CSS? Try Less or SaaS. Don't like JavaScript? Try CoffeeScript or Dart. There's a rich ecosystem of innovation happening in the web space at the moment, innovation that has never been present in WPF since 2006.

Apples and oranges and all that

I'm not contrasting ASP.NET and WPF in an attempt to say ASP.NET is better, that would be ridiculous, since they clearly serve very different purpose. I'm simply trying to show how one has come so far in six years, while the other has barely changed at all. I think it's all down to a lack of investment.

What's disappointing is that WPF started out quite positively during its time. Concepts like dependency properties, styles, templates, and the focus on data binding felt quite revolutionary when Avalon was announced.

Sadly, these good ideas, when put into practice, didn't have great implementations. Dependency properties are terribly verbose, and could have done with some decent language support. Styles and templates were also verbose, and far more limited than CSS (when WPF shipped I imagined there would be a thousand websites offering high quality WPF themes, just like there are for HTML themes; but there aren't, because it is hard).

Data binding in WPF generally Just Works, except when it doesn't. Implementing INotifyPropertyChanged still takes way too much code. Data context is a great concept, except it totally breaks when dealing with items like ContextMenus. ICommand was built to serve two masters; the WPF team who favored routed commands, and the Blend team who favored the command pattern, and ended up being a bad implementation for both.

XAML

And then there's the failure that is XAML. XAML is so verbose it's hard to imagine that humans were ever supposed to write it. And that's because they weren't! In the land of lollipops and rainbows, designers were supposed to use Blend and developers were going to use the VS designer, and no one would even look at XAML. Yet, it's 2012, and even as Blend has improved most people are still hand-writing XAML. This will not change in VS 2012.

The biggest failing in XAML wasn't that the tooling was bad though; it's that the language was never modified to cope with bad tooling. And unlike HTML, XAML isn't semantic. It's not interpreted. It is compiled, a serialization format, so there's no real separation of the markup and the implementation.

Here's half a dozen things off the top of my head that could be done to improve the XAML experience:

  1. Allow XML namespace imports to be declared at a project level rather than redeclared in every single file
  2. Allow binding events directly to methods instead of via commands
  3. Make the binding syntax shorter and more easily memorable
  4. Allow C# expressions like basic boolean logic instead of requiring converters all the time
  5. Allow a boolean to be implicitly converted to the tri-state (dual-state in Silverlight) Visibility enum without a converter.
  6. Stop making me use XML prefixes for my own custom controls

The ASP.NET team were able to create an entirely new parser (Razor) for their platform; why can't even minor changes be made in WPF?

MVVM

I can't begin to tell you how tired I am of hearing about this pattern, especially from ex-WinForms developers who think it is the bees knees because they read Silverlight Unleashed and were amazed by MVVM Light.

The reality is that every WPF project I've been brought on to has involved some guy thinking he was smart enough to invent his own MVVM framework, only for it to be a half-baked knock-off of someone's Code Project article. All WPF projects end up with a ViewModelBase that is so choc full of inherited members for threading and progress bars and INotifyPropertyChanged. Showing a view in a dialog takes 20 times more code than it would if you just put the code in Button1_Click, and it's equally as well tested since most people using MVVM are doing it because they claim it is testable but no one is actually writing unit tests for their view models, except the architects inventing the MVVM frameworks in the first place.

There's plenty of hype about MVVM out there, but the lack of platform support for it mean that every WPF developer will need to build a few bad, hard-to-maintain WPF applications before they figure out how to do it properly. That's a real shame.

Conclusion

Ultimately, as I look back over six years of working with WPF, I feel that it was a bunch of good ideas, that weren't very well implemented. You could say the same for the first versions of ASP.NET too (anyone remember Web Parts in ASP.NET 2.0?).

Only there's a big difference: ASP.NET evolved. The web stack evolved. Not only did the code change; the philosophies of the team changed. WPF on the other hand hasn't had a major change since 2006.

What's really sad is that there really isn't an alternative. In the web world, ASP.NET competes with Ruby and PHP; if I don't like one I can switch. On the Windows desktop, I'm pretty much stuck with WPF. And if WPF isn't evolving, that's a real shame.

You might enjoy working with WPF. You might think XAML is a beautiful, terse, fun to write language. That's how I felt in 2006, and if the platform is still enjoyable for you, that's great. It's going to be around for a long time, since there's really no alternative yet. But for me, I'm glad my WPF days are behind me, and that my full time job now is now ASP.NET-focused.

This post took quite a while to write, but the result is pretty cool .From my Octoblog:

In this post, I created an ASP.NET MVC 4 site, and checked it in to my hosted TFS Preview instance. Then, I used OctoPack to create NuGet packages from Team Build, using MyGet to host the packages. Finally, I configured Octopus to deploy the application to a staging machine, and two production machines.

Automated deployment from TFS Preview via Octopus Deploy

Today I installed the Windows Server 2012 RC, planning to test Octopus Deploy with it.

First question: How do I open Notepad?

Where is the start menu?

(Click to zoom)

Unlike Windows 8, there's no start button near the bottom (the new looking icon is for Server Manager). How do I open applications with this? See if you can work it out.

From my Octoblog: How Octopus uses RavenDB

When I started building Octopus Deploy, I wanted to build something that worked well enough to release a beta and start getting feedback. I had plenty of experience with SQL Server and NHibernate/EF, so I decided to go with a SQL Server + EF Code First stack for my persistence layer.

In the recent 1.0 RC release, I switched Octopus to use RavenDB. In this post I'll explain the reason for the change, and show how it is being used.

A couple of weeks ago I blogged about the upcoming changes in Octopus. This week those features were released. Here's a preview:

The Octopus Deploy website has also had a refresh, and I'll be doing most of my Octopus-related blogging there from now on.

The last release of Octopus was February 16th. One of my goals when building the business was to make fortnightly releases the "heartbeat" of the business, a goal that seems to have fallen flat this release.

That's not to say that no work is happening on Octopus. Far from it, in fact. This next release of Octopus is going to be the biggest change since Octopus first shipped. The branch for this release has 121 Git commits and counting so far.

So what's going on? Why has it taken so long? In this post, I'll walk you through what's changing and some of the new features.

Goodbye SQL Server, hello RavenDB

Since the beginning, Octopus has used Microsoft SQL Server with Entity Framework 4.0. While it worked well enough, it did make the deployment complicated. If you visit the Octopus installation page, you'll find a huge blue box explaining what to do if you have SQL on another machine for example.

Using SQL Server also meant a lot of limitations around how easily I could evolve the database schema. While I could add new columns or tables easily enough with change scripts (thanks to DbUp), it meant I was always worried about adding too many concepts and ending up with too many joins or queries to render a page. This bit me especially when I was trying to implement permissions.

A release management tool like Octopus, it seems, is perfectly designed for a document store. And the embedded version of RavenDB means my installation process is far simpler too. While Octopus will use the embedded version by default, I'm also going to support the OEM Server license for RavenDB that Ayende has been considering, when it becomes available. This will mean you can choose to run RavenDB on a separate server to your Octopus server, without any extra costs.

Changing from a relational database to a document database has been a good lesson, and it is a lot more involved than changing from one relational database to another. Making such a big change had a few impacts:

  • Almost every MVC controller and back-end process that used the data model has had to be rewritten
  • The installation process needs to be updated

These two reasons are why there hasn't been a release since February. However, since I've had to touch almost every part of Octopus to make this change, I took the time to improve a bunch of things along the way...

A new look

Since it was first released, Octopus has had a purple and green colour scheme. This was fun, but there's not a lot that can be done with a purple scheme. For 2012, Octopus will be sporting a modern blue theme:

Cool blue Octopus

Twitter Bootstrap has been used for button styles, forms, and the grid layout, but the rest of the look is custom.

You'll also notice that the URL's are getting cleaner, especially where projects are concerned.

Release details

Release details

When you go to the 'releases' tab under a project, you'll now see a lot more details about the release. The release notes and description of your NuGet packages will appear, so you can more clearly see what this release contained. You can also see the list of deployments for the release.

Notice that release numbers now support semver 2.0, including tags like -alpha at the end, just like your NuGet packages.

Deployments

One of the biggest UI changes this release has been for deployments. Previously, deployments were shown on the release page, with another link to view the deployment log. Now, there's a dedicated page for deployments:

Deployment details

There are a couple of interesting improvements here:

  • A summary of the deployment steps is shown, so you can quickly see where the deployment is up to
  • You can now add comments when creating a deployment
  • It's easier to promote one deployment to another environment
  • The 'raw' link lets you download the deployment log into your favourite text editor

The deployment log uses expandable/collapsible sections so you can drill into the output and easily jump to errors. The whole page has been rewritten to use Knockout.js instead of meta-refreshing the page every few seconds, so you won't lose your place while the deployment is executing.

When you create a deployment, you'll get a few extra options:

Deployment details

One of the new features is the ability to skip a deployment step. This is useful, for example, when you are re-deploying to an environment and you know a step isn't necessary.

The second change is the ability to add comments to a deployment. This is useful when you want some kind of traceability for releases - for example, you might paste the contents of an approval email from your business sponsor.

Octopus previously used jQuery UI dialogs for a lot of interactions - editing machines, editing variables, and creating deployments. For this release you'll see a move away from jQuery UI dialogs, preferring full pages instead.

Users, Groups and Permissions

Permissions

One of the big features missing in previous versions of Octopus was security and controls. This meant a lot of customers were using Octopus for development and test releases, but weren't allowed to use it to control production releases.

A wiki page describes the security model, but basically:

  • You can choose between Windows and Forms authentication
  • For forms authentication, you can invite users to create an account (Windows accounts are automatically created)
  • You can create groups out of user accounts or other groups, as well as from Windows groups
  • You assign those groups permissions

For example, this system allows you to specify a rule like:

  • Only users in the ACME Web Portal Release Managers group can deploy ACME Web Portal projects to the Production environment.
  • All users in the ACME Web Portal Developers group can deploy ACME Web Portal projects to the Development environment.

Variables

Variables

This release I've also tried to improve the user experience for common tasks. In previous releases of Octopus, editing variables used to be quite cumbersome - each variable opened in a new dialog and had to be saved as you went. The new editor lets you edit the variables in bulk, and saves them when you are done, making it much easier to edit a large number of variables in one sitting.

Tentacle improvements

A few changes have also been made to Tentacle:

  • The directory structure used by Tentacle is much cleaner (card)
  • Using "force" has been improved (card)
  • Environment names are part of the path

So for example, if you deploy MyApp.Web version 1.0.0 to a Production machine, you'll get a path like:

C:\Octopus\Applications\Production\MyApp.Web\1.0.0

If you deploy it again with the "force" flag set, you'll get:

C:\Octopus\Applications\Production\MyApp.Web\1.0.0_1

This change makes it much easier to have a machine that serves dual roles (for example, a machine that doubles as both a dev and test machine).

Web site changes

I've also been working on a new version of the OctopusDeploy.com website. The site currently does a terrible job of explaining what Octopus does, and the documentation and support is scattered in a bunch of different places.

When the next release of Octopus is ready, I'll also release a new website that brings the documentation and a blog onto a single site, and does a much better job of explaining the product. I'm also going to record a couple of videos showing what Octopus does, and how to get started with it.

What's left?

The "in progress" column in the Trello board gives a rough idea of what's left to do before this release ships. Most of the work revolves around fixing up the installer to work with RavenDB, and making the final UI changes so that everything works with RavenDB properly, so I'm hoping this release won't be more than a couple of weeks away.

This release was originally just supposed to be about adding security. Instead, it has seen a database change, a UI refresh and a host of new features. Perhaps it's a good example of scope creep, but on the other hand, when making such a fundamental change in how a project works, maybe taking a couple of months to get it done isn't bad - time will tell. After this release I'll try to stick to the goal of small, incremental changes every couple of weeks. Promise! :)

Today on the Octopus support board a bug was reported that at first seemed like any normal support request:

The support request

As I read through the report, a few things stood out:

  1. It's from someone at Microsoft
  2. The title refers to an "Octopus Agent". We have a "Tentacle" but we don't refer to it as Octopus Agent.
  3. There's a COM+ error that I've never seen before
  4. The product version number starts with 15. I'm still working on version 1

This isn't the first time I've received a bug report like this:

It turns out that these bug reports refer to a Microsoft tool that seems to go by the name of "Octopus Deployment Tool". I don't know much about it, but it seems to be an internal Microsoft tool that might have something to do with BizTalk.

What really made me chuckle is that the post was from a Microsoft email address (although at least it was only a v- vendor account). I suppose when Microsoft users come to me to ask for support for their own internal tools, I must be doing something right.

What should my standard reply for these kinds of wrongly-directed bug reports be? Here's my attempt:

My reply