Under the hood www.miljoparkering.se is, admittedly, quite overdesigned.

The web site, in its current form, is very simple: People sign up. They then choose the streets they want reminders for. It’s also possible for them to change their e-mail address. Every night there’s a recurring job that goes through all the user profiles, matches them with street cleaning tasks for the day, and then send out reminders to the users that has these streets selected. The site could have been made easily in a short time with a simple relational database, simple data access layer and some CRUD code.

For the last year or so, however, the Command Query Responsibility Segregation (CQRS) principle and Event Sourcing has been surging up the trend curve. It’s hard get around if you’re interested in system design. Many people talk about it, it’s discussed on community meetings. We actually considered CQRS when we had to make initial technology choices for Mikz.com, the daytime project I’m currently working on. But CQRS+EventSourcing is quite different than the classic de-facto enterprise system design, the n-layered design.

In a n-layered design, you’ll typically see at least three layers, UI, domain logic and database access. Depending on your flavor, you might have more layers, and the data access layer might / might not be implemented with and ORM framework such as nHibernate. After changes changes are made to the domain model, the current state of the model is persisted into the database. When you need to get information from the system, the same layers are used to query for the current state.

In CQRS, you don’t use the same model for both updating and for querying. There’s a model that facilitates safe and structured changes to the domain objects (through the use of “void” commands). And there’s a model for querying the system. The first model may be relatively slow to work with, but that’s ok because we need to validate the information and ensure that the changes are made correctly, and we maybe even have notify other systems that a change has occurred. The read model, however, generally needs to be fast since most often, for each update you make to a system, there are many reads.

Creating a system based on CQRS can be done without Event Sourcing. But Event Sourcing has some advantages, that doesn’t come naturally from a system, that just contains the current state, such as getting answers to new questions from a system that is already running. This makes the Event Sourcing concept very interesting. Also, data from a system based on Event Sourcing is quite different: current state is not persisted in the data store. Instead, all the events that occurred in the system lifetime are saved, from which current state of any domain object can be extracted!

With many years of experience with development of n-layered systems, Björn and I agreed that it was about time to get our hands dirty with CQRS and Event Sourcing. We wanted to gain real life experience, and thereby get a bit of distance to theoretical discussions, some of which where a bit too glorifying, and instead be able to make choices on behalf of our enterprise customers based on real experience. This is the reason behind the overdesign of www.miljoparkering.se – it’s by design.

As of writing this, with version 1.0 of the system, we are aware that this is only the start of our experience with CQRS+EventSourcing. Our professional experience tells us that we need to experience at least (1) an upgrade iteration, as well as at some point (2) facing a previous design choice, that has to be refactored/rectified/expanded. I will blog when we reach those experiences.

When we set out to create www.miljöparkering.se, we wanted it to be a win situation from the very start. That is, even if the site wouldn’t ever gain significant user adoption, our goal was to at least make it a personal win.

One of the things that both Björn and I had wanted to break into was cloud computing. We wanted to gain experience in hosting a web service in the cloud. We also wanted to control and maintain the entire stack of the web service, from web server to database server, to background services.

The inspiration for using Amazon’s cloud services (or, Amazon Web Services (AWS), to be exact) came from talking to Lars Krantz and Thomas Mårtensson, the guys behind www.malmofestivalen.se. During our communication while I was creating the Android application, I got a lot of input on how they did things on the site and got to know their thoughts on how to maintain and scale the site. And as you might have noticed the last two years, that site has run perfectly with high availabilty. 

So, in preparation to developing www.miljoparkering.se I sent Lars some questions, which yielded an answer which I, at first, found rather cryptic. But basically it was just very much in line with one of the toughest parts of getting involved with Amazon’s AWS: you have to understand a huge pile of acronyms, services and entities and how they all relate to each other!

I all honesty I think Amazon AWS has a steep learning curve. Documentation is present, but is huge and overwhelming. Trying to predict costs is almost an intimidating task (although it’s gotten a lot better since the first time I looked through their pricing information some years ago). The detailed sign-up process includes identity validation through phone (very well implemented, though, technically speaking). Once you’re validated, you can log on to your personal web console, a AWS universe full of detailed information. Also, using the AWS SDK for .Net has its quirks, such as initially failing when used with log4net (caused by an unexpected side effect). 

However, for those considering to try out Amazon AWS, I do have some encouragement: True, Amazon AWS is very advanced and can be quite overwhelming. But you can ignore most of it and just focus on the part of AWS, that you initially need. For us it was EC2 (Elastic Computing) servers. After getting a server up and running, we started to look at other services, such as Elastic IP (public IP for the server, hard to get around ;-), firewall setup, and the SES, Simple Email Service, for sending out our notifications.

Although the site itself could fit easily into a normal web hotel, the Amazon server gave us the flexibility and control we needed. And over time, the cryptic mail from Lars turned out to be very useful information, once I had gotten acronyms in place (thanks Lars ;o)

When Björn and I put up our landing page for www.miljoparkering.se we had Google Analytics (GA) in place from the very start.

Our landing page contained two points of user interaction, the sign-up and the contact form, so creating goals based on these actions was obvious to us.

Soon, however, we started getting curious about how much of the information on our landing page the users were seeing and at what point they would start loosing interest and leave. But as our landing page didn’t have sub-pages, we didn’t really have any any obvious data to tell us what the users were doing other than visit the first page. From a GA perspective we were a bit in the blind …

We started thinking about what we could do about this. What we’d really like was a solution based on GA goals which would mean that we could use funnel visualization, a great way to display the users progress and their exit points. However, GA goals and funnels are based on page views and cannot be based on events, so we needed to somehow hack it a bit.

Our solution ended up like this:

Since Lydia came into my life she’s opened my eyes for “second hand dogs”. I now have a story about that, that I want to share with you. This is not a technical blog post, this is a post about something as simple caring for animals.

Before I continue this personal story, I want to share a picture with you. It’s a picture I took of the other browned eyed girl living in our house, who’s constantly fighting with Lydia for my attention. Her name is Xena.

Xena is a “second hand dog” from a Guardia Civil office. That’s death row for stray pets. Guardia Civil usually picks up stray pets and if no one adopts the animal within a couple of days, it’s put to sleep. Not because they don’t like animals, no, because there are so many of them.

I dare to say that in Scandinavia the “second hand dogs” phenomenon is not so well known, as people in most cases treat their pets with respect and love.

In Spain, the owners of overbooked shelters for abandoned and / or injured dogs tell a different story. People abandon dogs and cats in abundance. Some people have “summer pets”, that they leave behind in the city they spent their summer holiday. Others because the temper of the dog might not suit the owner, or maybe because keeping the dog is more of a job than expected. We experienced a lot of those dogs last night in Carboneras. Luckily, most people were friendly to the small stray creatures, that were now begging at the tables outside restaurants.

Today, however, it was a quite different. And today we’ve been talking to a lot of those dog shelter owners.

Our story starts en route to a new city, where we had to stop for refreshments and gasoline. When paying, Lydia asked about the dog laying outside. The staff told us that someone had abandoned the dog at the gas station. The dog now lived outside the gas station and there it was waiting for its owner to come back and pick it up. One of the shelter owners actually knew the dog, and confirmed the gas station staff’s story that someone already had tried to pick it up for adoption. But when someone tried to get near it ran away and returned again to the same place when the people had left.

When we were leaving the gas station, I somehow felt that this story had to be told or captured. I decided stop the car and get out to get a picture of the sleeping dog.

I never got a picture of the dog sleeping. It got up before and maybe that’s ok. Not only was the dog thin. Although sleeping in shadow, it was coping with 30C+ degrees. But the worst thing was the flies. We did notice the many flies when putting on gas. The dog was sleeping with its mouth open, and its teeth and tongue was covered black with flies. That sight made me sick to my stomach.

But the dog wasn’t sleeping anymore. Now he was up looking at me. I managed to get a couple of shots, but I honestly had a very hard time focusing about light and focus settings.

Poor guy. He didn’t stay still. He was fighting the flies all the time. Must drive him nuts when he’s awake. How will his sleep be with a mouth alive with flies?

At that point we didn’t know what to do, and we drove away with a strong feeling of injustice. But when we arrived to our hotel we decided that we couldn’t just let such a sight go by unnoticed.

So we’ve been calling around to the dog shelters, and here’s probably the worst part of the story: It happens all the time. Some people even abandon them close to tourist areas, as they know that people from the U.K., Germany and Scandinavia are keen on taking them. 

What will happen to our friend at the gas station is yet to be seen. I guess he’s still waiting. Meanwhile we’re still searching for at place for him, and for someone to pick him up. Doesn’t look too positive, though…

So please, if you consider getting a dog, don’t get a brand new one. Consider one from Spain*. They’re not rabies-monsters from hell, they’re lost and without a home. And they’re super nice. Xena is a a living proof of that, charming everyone that meets her.

And of course, here’s a picture of our loyal friend at the gas station.

* There’s pan-European adoption services, that will help you get the dog across borders.

It’s now been a little more than two months since I took my Malmöfestivalen for Android 2010 project and turned it into a Open Source project for 2011 development. Since then, the project has grown from a closed source one man show to an Open Source project now backed by 15+ people, who are giving some of their free time to add features, fix bugs or refactor code. Quite an unexpected and mindblowing development!

Given my trade as a Software Development Consultant, the projects I’ve been working on have traditionally been (very) closed source. So I didn’t have much experience in preparing, publishing and running an Open Source project. I did have the conviction of doing it, but I needed some input how to it in practice. This lack of experience, by the way, is also why I take a little extra time and write about this. Open Source is not new, I use many Open Source frameworks in my job, but actually going from closed source to open source is quite an experience.

If some of you are considering to take existing projects to Open Source (or starting one), but need insight about the practical details and also the more philosophical aspects of Open Source, I can recommend these books:

 
This book is a practical guide on how to run Open Source projects. It will tell you about how to handle basically every situation you may encounter, from announcing your project to handling code and lead team members. 

 
A collection of essays about Open Source from different authors.

 
A collection of essays / stories. The book is more than 10 years old, but still very inspirational.

The Malmöfestivalen for Andoid and iPhone continues its development throughout the summer until the festival starts in mid-August. Many questions are still open: Will people like the new features in the Android app? How will the new iPhone app look and feel? Will we gather enough Windows Phone 7 developers so that having an app ready in two months is believeable?

I’ll keep you posted – enjoy the reading! :)

It’s with great pleasure and excitement that I can announce the Malmö festival Android 2011 app an Open Source project!

Last years edition was fuelled by my curiosity about the Android platform and functioned as a way to scratch my personal itch on how to navigate the festival better. A lot has happened since last year. I’ve gotten a lot of feedback and ideas from users, other developers and friends, and I’ve also gotten encouragement by the people behind the festival. Furthermore, I’ve also had the pleasure to work directly with talented people that create Android applications for a living (I usually work in the enterprise development domain). Combined with the huge adoption of Android phones during the last year, this convinced me to try to take the application to a whole new level of awesomeness this year.

I have given this a lot of thought during the last couple of months and I think that moving the project into the Open Source space (under the GNU GPL license) will benefit everyone in the best possible way. I considered taking a shot at it myself (alone again), but the idea of collaborating with other creative people from the Malmö area (and maybe even beyond) is a lot more compelling. Not only will make the work more fun, but the result will potentially contain many more awesome features, than I would have time to create alone. And more awesome features means more happy users! :)

The strategy right now is to get more users to the Facebook page, which will serve as the interface between users and project members where ideas can be exchanged. I’ve also created a non-technical project front page where the users can get the application and / or get involved in the project.

And, of course, there’s the project space itself, where project members can find code, discussions and issue tracker. The project space is in English, by the way, following the festivals multicultural spirit. And, most important, some people have already signed up to help! Whoop whoop!

So, there you go… it’s now Open Source. Let’s get hacking! :)

After having spent more than 11 years in the Microsoft camp of application development building primarily enterprise applications, I chose to spend my summer 2010 learning the Google Android Operating System and Framework, the Java Framework, and, of course, get inspired about new ways to make applications, at the Mittuniversitetet university in Sweden.

As part of my course I had to do a project, and I chose to develop an application for Android phones that I had wanted to have in my hand last year: An application for the Malmö cultural and music festival. I remembered my experience from the previous year, where I was able to study their concerts on their site all I wanted, but once I were amongst the many visitors and the many scenes, I was hard to find my way and remember where to go and where the scenes are. To me, the festival needed a more "local" guide, of course taking use of the latest technology available to most people now (here GPS and mobile data network).

So I made it my mission to create such an application! In case you missed it during the festival, you can see the result below in this application walkthrough:

The following screen was the start screen of the application. From there the user could go to "Just now and upcoming events", "Festival map", "Scenes and Places", "Your favorites", and search.

This screen showed the contents of the "Just now and upcoming events" window. It showed current and the two next events, sorted by scene.

The next screen showed the festival scenes on a map. The pins were clickable, and gave the user access to information by the given scene, including all the concerts on that scene.

This next screen showed a different way to access scenes, as a simple list. Again, clicking on the scene would take the user to detailed information about the scene, including all the events.

The screen below showed a detailed view of a concert. The user could share the event on every media possible in the mobile phone, such as Twitter, Facebook, Mail, SMS and more. Even better, the user could also press the heart in the upper right corner, which would then light up and add the concert to her/his favorites list.

The screen below showed the users favorite event list. The user would get a reminder about the concerts in the favorite list 30 minutes before the concerts begin. Super nice, when you were browsing the stands on the festival or got carried away in conversation! :)

The features above were the most significant in the application. I had some really good feedback from the people who downloaded and used it. 4,5 stars out of 5 possible! Futhermore, the great people at malmofestivalen.se caught on to the application and after a short coffee meeting, we decided to create an import feature, which would make it possible to transfer the favorites from the web site into the Android application. By doing so, the users would get the best of both worlds: a rich web interface to create favorites and a local application to remind the user and show where the concert took place. The application had about 1000 active users, which might not be much compared to the amount of visitors, but it still was quite a surprise to even have that much popularity.

If you are considering to get an application created for your company or organization, I would be more than happy to add my detailed experience and help that application come to life in the best possible way. Bringing the application above to the end users gave me insight on many details that you might be able to use, from application life cycle management, support and communication with end users, and also how to get data for visitor analytics.

Feel free to drop me a line here!

I have been playing with jQuery lately and I have gotten really fond of how much more one-to-one front end development has become. Earlier one had to do all kinds of tweaks to get things right, and the annoyance of that sort trial-and-error development have kept me away from doing anything really serious client side development. Sure, I've done many web applications but none with what the trendy Web 2.0 kids want today :o)

After poking around with jQuery I decided that I had to try and develop a plug-in. You know, not only using jQuery but also developing something that can be reused.

First a little history: Back in 2003 or something like that, my old time study friend and client side developer Kim, who I had a company with back in 1998-1999, handed over some client side code that my business partner at that time, Anders, and I could play with and use as we wanted. It was a nice little javascript snippent and some images which made up some client side functionality, that would show a little bubble with help text over for example an input box.

Anders and I made extensions of all the ASP.NET web controls, including the client side script and images. So, in essence, instead of using asp:textbox we used kwd:textbox, and could then write BubbleText = "whatever", and the user would get that shown. Pretty nice, and very welcomed by the end users of our applications.

So as I was playing around with jQuery I came to remember this client-side functionality and thought that it was a pity that it wasn't available on the more and more popular ASP.NET MVC platform. (Well, basically on any platform, but using it with ASP.NET MVC was my first concern). So I sat down and started investigating was needed to make a jquery plug-in.

The end result I have named BubbleHints. A bubblehint simply looks like this:

It's a standard jQuery plug-in with no ties to ASP.NET MVC and can be used on any web platform. Tested with Google Chrome, Firefox and Internet Explorer.

Check out the examples.

Download examples, plug-in and images in a zipped package.

Feedback is welcome!

Not so long time ago I released an application on my mobile broadband blog called Mobile Broadband Logging Monitor. It’s purpose is to help non-techincal users diagnose and discover if they’re affected by the heavy logging problems, that some of the big mobile broadband connections softwares suffer from.

The following story is about the creation of this piece of relatively simple software, and I’d like to share some of the thought I’ve had while making it.

First, a small question. What’s the difference between the applications shown in the pictures below?

Ok, I was cheating for theatrical effect. The pictures are the same. Read more, and you’ll know why I asked.

The story of the software begins with the issues about mobile broadband connection clients logging way too much information. I had made plenty of blog postings on what the issues were and how to solve them, but I wanted to make a diagnostic tool for everyone to use so that they could see if they were affected or not.

So, having thought for a while creating this software for a while and while feeling inspired, I sat down and started coding. I had no formal specification for the software, as I usually have on my job, but of course, I had some goals. The software had to be able to diagnose several different types of mobile broadband software, in various versions, and display their file activity to the user. It furthermore had to display some simple statistical information, the activity pr. minute and forecasted activity pr. hour and work day.

I didn’t take long before have the famous “working protype”. Yes, I could start the app, and it would be able to diagnose HUAWEI Mobile Partner and two versions of Birdstep Techonolgy’s EasyConnect. Golden!

Now, from a feature perspective I was done. The first version of the application had these features:

* Start button – starts the monitoring of the mobile software.
* Stop button – stops the monitoring.
* If the software in question has a fix described in the blog, show a link to that blog post.
* If it is the first time the user start the aplication, show a thank-you-for-downloading web page.
* If user clicks links to blog or feedback page, show the pages accordingly.

I put the software online and people started downloading.

But from other perspectives than the (admittingly vague) requirements, I wasn’t done at all. I had created an application below the norm in many ways if this had this been in a professional context (in my opinion). The application had one window and all the logic of the application was contained in the code behind of that window. This meant lack of testibility (well, there was no testibility at all!). Also, I had ideas for adding more features and even exposing the core application logic (finding and monitoring the software) as an API for others to use.

I decided to take on refactoring the application big time, without adding any new features to the application. The goals for the application were:

* Make most of the application logic covered by non-integration unit tests.
* Following the above, to have the part of the application which interacts with the “runtime” and/or external systems made as “thin” as possible, making it very easy to code these interactions and also ensure that they behave correctly in unit tests.
* Compose the application with components, that have clear purposes and one concern pr. component only.
* To open up for injectibility and IOC, hopefully to make use of Castle Windsor or the like in the future.
* Open up for making the application Open Source and thus expose the inner workings of the application (people might be hesitant to download arbitrary software from blogs, I know I would)

The goals for me personally was:

* To make it “right”. No bullshit.
* To make use of the many inputs I’ve had over the years, once and for all, making the software a sort of mini experiment of how it could be done in a professional situation.
* To be able to add new features in a structured way instead of the trial-and-error way that the software invited to in its current implementation.
* Not necessarily use the last tools or frameworks, but at least use sensible implemenation patterns what would make structured change easy.

Oh yes, big goals in small scale! :o)

The following are the stages of refactoring I went through with the application. If you don’t want the bloody details, I suggest you skip the description of these stages, and go directly to the “You had a question, Mr. Ostengaard?” section.

Stage 0
This was the working prototype that I started out with. I uploaded the software to Microsoft’s Codeplex. You can browse the code here.

Stage 1
In this stage I seperated a lot of the applications logic into components (ie. objects) with well defined purposes. The application only had one really structured part so far, which was about what mobile software the application supported. I could add new types of software pretty easy, even in the first edition. The rest of the application, however, was all code behind spaghetti voodoo. I started to identify the concerns of the code. You know, identifying these things in retrospect is not an easy task. I took a lot of time, and you start to see how entangled things really are when you code like this: Functionality for seaching for the software, starting / ending monitoring, UI state management, reading from configuration, handling events from directory watcher, collecting simple statistics and cross-thread UI updates. There’s was a little of everything, not much, but enough to make the identification of concerns pretty fun ;o)

I ended up creating some components and introduced interfaces for each of these, and every component got their dependencies injected (I chose the constructor strategy). You can browse the code of this stage here.

Stage 2
At this stage, efter going through the refactoring of business logic, I turned my focus on the UI. I had most of the business logic of the application seperated from the UI logic now. Not all, but almost. There was still some things, such as reading from the configuration, opening web pages and such in the UI code behind. But I was really really thirsty for more. I wanted to have the UI logic testible through unit tests in a non-integrated way too. I wanted full control over everything that the application did, at least as far as possible.

Now, when I had my own company I was involved in developing a Windows Forms application. At that time, I used a simple MVC framework to create views and sub-views and their corresponding controllers. The implementation had its forces and its drawbacks. But since then, I hadn’t done anything so structured in Windows Forms, and therefore I had some inherit mistrust for the strategy of that tiem. No need to not learn from the past, right? ;o) So, after having poked around for a while and tested some strategies, and honestly being a bit confused about which strategy to use, I ended up with the MVP pattern. Many thanks to input from Steve Bohlen on that, you have a beer waiting in Copenhagen.

But here’s an interesting thing: When you have the ambition to cover as much logic as possible in non-integrated unit tests, transforming traditional UI logic into testible code is quite an eye opener. You have to ask yourself what a dependency really is? In the case of UI logic, it’s can be the many things that you usually just take for granted in a quick-and-dirty Windows Forms application: Reading configuration files, displaying MessageBox (and child windows) and in this case also opening web pages. These simple things now became obstacles for my unit testing goals and something had to be done about them. I therefore made components to handle these things, disregarding the sense of overkill at the time. This would, hoverever, when creating unit tests, turn out to be a very good idea: Everything was injectible, everything was mockable.

You can browse the code of this stage here.

On a side note, the same is true for UI logic in .Net web applications. Traditional code behind is not very testible, so if you want to have that control over your software, similar strategies has to be taken into use.

Stage 3
At this point there were still some things in the business logic that were not covered by unit tests, especially the parts handling statistics. And to make that testable I had to control the applications sense of time. Just as writing “new SomeComponent();” is avoided in the name of injectibility and testibility, so is writing “DateTime.Now;”. If you use DateTime.Now in your code you have code that is less testable because your code is dependant on a very fluent component, namely the system time of the computer. How would you for example test a time-based statistics component when you cannot control time? It is possible in some ways, but if you want solid results and the test to run in short time, you’ll have a challange. Would you choose to have your unit tests run in real-time? That’s way too counter productive – these non-integration unit test has to be blazingly fast and give quick feedback to the developer - and because of this, time has to be encapsulated as well and made injectible. The IDateTimeContainer was introduced which contains the method GetNow() returning nothing more but DateTime.Now.

In this stage a new project was included in the solution. Until now the business logic had been contained in the same project as the UI, but with 100% seperation. Now I moved the logic into its own project (API), to ensure this seperation fully and also to make the core logic available without any relation to the UI.

You can browse the code of this stage here.

Final product
After going through all these stages I still had an application with no new features. But it was much better structured and had the qualities that I wanted: thoroughly tested through unit tests, and open for structured and controlled change. 

New versions
After this rearrangement of code I have relesed a new edition of the software. Change was adding a new child window to the mani window. The child window and its related presenter, and even the changes in the presenter for the main window, was added with ease. It was really a joy doing that in a controlled invironment.

You had a question, Mr. Ostengaard?
Now, the headline of this blog post asked “What’s the lesson of this story?" I ask because I actually want your input on what part of this whole story you think is the actual success story. I can think of some viewpoints, maybe you can think of others.

* One viewpoint could be that creating a “working prototype”, like I basically did here, is fair enough, as long as you have enough dicipline to throw the original code away or a least invest a proper amount of time restructuring it before adding new features. 

* Another viewpoint could be that things has to be thoroughly analyzed and components identified (whatever that means) before going into development. That would mean getting many of the benefits from unit tests and structured change from the early beginning. But it also means that the customer has to pay more up front and wait longer before gettign return on investment. (I’m not going to go into numbers here.)

* A third viewpoint could be not to focus so much on unit testing and other forms of control and feedback at all, and just fulfill the requirements and have testers assert that the requirements have been fulfilled. When the application get past these tests, the release is considered a success.

I ask the question above and put forward these three examples of viewpoints, because I am surrounded with people who carries (roughly) one of these three viewpoints and discussions often about this often occur. Some will say that the early release is the way for success (early business value), others will say the pre-study and analysis must be done, and others simply don’t have a clue about structured and quality-oriented application production (or simply don’t have it as a business goal).

The first viewpoint is good for early business value, I agree, but the problem with this strategy is that the application is born with a quite large techincal debt. But I have never heard about a customer (or software consultant house for that matter), who would pay for 4-10 times as much time as it took to create the original version to (re-)make it into a structured application and this without gaining basically any new features for that money. Have you? And if that doesn’t happen, all you have done is lured yourself and taken the first step in following the third viewpoint, where technical debt is not considered bad. But to me, the third strategy can never be the way to go. It will end up in a system, that carries so many problems, that change in the end will be seen as evil. Change will be avoided. It’s on a death march...

I hope that you can see, that I am, in most cases, a proponent of the second viewpoint. I can live with the first viewpoint, if actions are taken to rearrange the software. Unfortunately I do believe that many people start out by going with the first strategy, then skipping/postponing the restructuring, only to later find themselves trapped far into to third strategy with almost no possibility of returning.

And if you still wonder about the pictures, the difference between the two applications lies in the quality of the implementation and openness to change in the future. One sucks, one doesn’t.

Tell me something from your part of the world… :-)

If you have tried to use the Google Feedburner service and the Yahoo Pipes together you have probably experienced the “Error 999”, which means that Google Feedburner does not consume the feed provided by Yahoo Pipes. In other words, your RSS feed stalls although there’s new content from the pipe to expose.

I ran into this error myself and hoped for a resolution between the two parts. However, it seems that people have been experiencing this since the beginning of 2009, and I’ve just been spared until the beginning of November. And apparently the progress has stalled totally between the two camps, so nothing is really happening to solve this issue for their users. So I’ve tried some things, and the solution/fix/hack is actually quite simple. It does, however, have prerequisites: You’ll need to have a little programming done and a place to put the program.

The normal Google Feedburner/Yahoo Pipes setup looks like this:

Request flow: Google Feedburner –> [Get RSS] –> Yahoo Pipes
Response flow: Yahoo Pipes -> [Returns Pipes mashup RSS content] -> Google Feedburner

To fix the problem, you need something like this:

Request flow: Google Feedburner –> [Get RSS] –> Intermediary service –> [Get RSS] –> Yahoo Pipes 
Response flow: Yahoo Pipes -> [Returns Pipes mashup RSS content] -> Intermediary service -> [Returns Pipes mashup RSS content] -> Google Feedburner 

The setup above means the Google Feedburner will be able to consume the Yahoo Pipes feed indirectly instead of directly. My personal intermediary service is placed here on christer.dk. Now, the only thing that the service has to do is to consume the Yahoo Pipes feed and forward its content. Here is what you do (in inline asp.net c# 3.5 code).

   1:  <%@ Page Language="C#" %>

   2:  <script runat="server">

   3:      protected void Page_Load(object sender, EventArgs e)

   4:      {

   5:   

   6:          System.Xml.XmlReader reader = System.Xml.XmlReader.Create("[YAHOO PIPE RSS URL HERE]");

   7:          System.ServiceModel.Syndication.Rss20FeedFormatter formatter = new System.ServiceModel.Syndication.Rss20FeedFormatter();

   8:          formatter.ReadFrom(reader);

   9:          reader.Close();

  10:   

  11:          using (System.Xml.XmlWriter writer = System.Xml.XmlWriter.Create(Response.OutputStream))

  12:          {

  13:              System.ServiceModel.Syndication.Rss20FeedFormatter outputformatter = new System.ServiceModel.Syndication.Rss20FeedFormatter(formatter.Feed);

  14:              outputformatter.WriteTo(writer);

  15:              writer.Flush();

  16:          }

  17:          Response.End();

  18:      }

  19:  </script>

Place this code in an asp.net aspx-page or create a similar logic on a different platform and expose it on a server. Then reconfigure your Feedburner feed to retrieve the RSS content from your new service.

That’s it. I hope it helps you like it helped me. :-)

[Update]: Seems that my layout isn’t very code friendly! ;-) Here's the asp.net code to download: RSS.zip (453,00 bytes)

[Update two] I've clarified the request / response flow description above.