Monthly Archives: October 2010

Why not publish NServiceBus messages from a web application?

Posted by David Boike on October 27, 2010 10 comments

It may be the single most asked question on the NServiceBus Yahoo Group, and it usually goes something like this:

The NServiceBus Documentation/FAQ says not to publish messages from a web application. But…why?

All the documentation says on the topic amounts to “Don’t. Bus.Send() a message instead.” This is true and good practice, but developers are smart people that aren’t commonly happy with an answer that doesn’t include a why.

In this article I’ll go into some depth on the three main reasons why you’re better off using Bus.Send() when in the web world than Bus.Publish().

Read more »

Deploying NServiceBus in a Windows Failover Cluster

Posted by David Boike on October 21, 2010 7 comments

NServiceBus is made from the ground up for scalability and reliability, but to take advantage of these features, you need to deploy it in a Windows Failover Cluster. Unfortunately, information on how to do this effectively is, as yet, incomplete and scattered. This article will describe the process for deploying NServiceBus in a failover cluster.

Read more »

Hey Apple, Your Push Notifications API Sucks

Posted by David Boike on October 19, 2010 3 comments

I’ve been an Apple fanboy for years. I grew up programming in BASIC on an Apple IIGS. I love my iPhone to death. However, I am not a member of the Church of Jobs that believes Steve can do no wrong. Now I’m a software developer and I appreciate a good, clean, easy to use API, and Apple falls short.

But fear not Apple! You may already have two push notification command formats on the books, but keep reading and I’ll suggest a third that won’t leave developers frustrated and angry with you.

Read more »

HgRemote: Extending Mercurial to Non-Developers

Posted by David Boike on October 11, 2010 3 comments

I hear lots of stories about how designers and developers can’t get along. Personally, I don’t get it. I love our web designers. They do something I can’t. I don’t do pretty. I can design a user interface and make it functional, but that’s not enough. Our designers can turn that around and make it gorgeous. We complement each other, and I try to take care of them whenever I can.

So when we made the leap from self-hosted Subversion to Kiln-hosted Mercurial, I wanted to better integrate our designers in the development process. I wanted them to have the same advantages of version control that I, as a developer, was accustomed to. And I really wanted to put an end to opening directories and finding “default.aspx”, “default – Copy.aspx”, “default – Copy (2).aspx”, etc.

The problem with Mercurial is that it doesn’t work too well for web designers that don’t have a locally hosted webserver on their workstation. When testing a bunch of CSS changes, an “edit, save, commit, push, refresh, check, repeat as necessary” workflow does not work. Designers need to be able to modify files on a shared design webserver where they can preview their changes immediately and then commit when done with a task.

Additionally, the designers only need access to the website directory, and attempting to do a 3-way merge makes them run for the hills. And why wouldn’t it – I don’t even enjoy that.

So like most developers, I figured there must be a way I can fix this problem with software.

Read more »