DarksideCookie

I know I am a Microsoft fanboy, and I am the first to admit it. But I still want to say that I can listen to other peoples arguments and try to look at the facts objectively. I tend to see benefits in a lot of Microsoft things, but that doesn’t mean that I believe that everything else sucks.

I have used a Windows Phone device since before they were even released, built a couple of apps for it and talked about it for different audiences. And it is not a big secret that I like it, especially since I got Mango on my phone.

Having that said, I still believe that there are 2 very good alternatives available. The iPhone is, whatever kind of fanboy you are, a great phone. No, I don’t like a lot of things when it comes to Apple, and I don’t like being stuck with iTunes, and I don’t like Apple’s censorship. But it still is a freaking awesome phone, and pretty much single handedly managed to change the smartphone market into what it is today, which is SO much better than it was with Windows Mobile.

More...

I have just returned from the Developer Mania II conference that I spoke at today. It was a great one-day Microsoft conference about Windows Phone 7 development, and I heard some good speakers.

My part in the conference was to share the stage with Johan Lindfors and talk about MVVM. As a part of that talk, I showed off some code I have created to simplify navigation in MVVM scenarios. I thought I would share that code, so here it is: DeveloperMania.MVVM.zip (628.26 kb). It is a little on the heavy side, but that is due to the inclusion of Unity…sorry!

A question I keep running into when I speak about XAML-based application developer is how the developer/designer workflow should work. I don’t know if the question is common in general, or if it is because people feel that I’m not only passionate about coding, but also about design.

I have spent quite a lot of time thinking about how this workflow should work when working with XAML. In other technologies, I believe that the flow is much harder to get going, and I believe it requires more steps. In the “XAML world”, it should be a lot easier. The separation between functionality and design is pretty clear. And this separation should enable quite a well working flow.

Before I get into how I see it, I want to add a disclaimer… I have not been able to try this out in the real world as much as I would have liked. Mainly because I, in most cases, play all the roles. Or at least manage everything from XAML to code, with visuals coming from a designer.

More...

I believe it is time for a really heavy blog post, and if you have ever read one of my other blog posts you are probably getting scared now. My posts are normally big, but this might actually be even bigger… Sorry! But it is an interesting topic with many things cover…

But before we can start looking at code, there are 2 things I want to do. First of all, I want to thank my colleague Robert Folkesson (warning, blog in Swedish) for getting me interested in this topic, and for showing me a great introduction.

And secondly, I want to give a quick run-through of what federated security and claims based authentication means…

Federated security means that an application relies on someone else to handle user authentication, for example Windows Live or Facebook. These identity providers are responsible for authenticating the user, and returning a token to the application, which the application can use to perform authorization.

More...

Configuring your application when running in Azure can be a little confusing to begin with, I agree. However, it isn’t really that complicated as long as you understand what config goes where and why.

In Azure, you have 3 places that affect your configuration. Actually it is in more places than that if you count machine.config files and stuff like that, but I’ll ignore that now… And to be honest, it is only 2 places, but you need to tweak 3 places to get it to work…

When you create a new Azure web application project, you get 2 projects in your solution, one “cloud project” and one Web Application Project for example, and both have some form of configuration going.

More...

Earlier this week, I got a link to a blog post that I for some reason just loved. I also managed, for some reason, to etch itself in the back of my mind. It is about the fact that due to human nature, and the that we have pretty much secured our survival and don’t need to fight to survive anymore, we are turning into a self-destructive and delusional species that try to turn unimportant things into important things just to give ourselves a reason to exist.

My short version of it however doe not do it any justice, so I suggested heading over and reading it in full here: http://phirate.posterous.com/weve-been-alone-too-long

It sort of sat there in the back of my mind, gnawing a little on me ever so often, until I found this: https://secure.mysociety.org/admin/lists/pipermail/developers-public/2011-October/007647.html

More...

Lately I have been working on an Azure project for a client (if you haven’t noticed from my Azure-centric blog posts as of late). A part of this, we have built a WCF service that exposes the functionality that we need. However, we are not actually building a client, only the service. So we don’t have a great way of testing the service. This is obviously where the “WCF Test Client” comes in.

For those of you who don’t know what this is, it is a small client that hooks up to any available service and creates a proxy for you. You can then use this proxy through the interface and call your service.

More...

Putting applications in the cloud is great, and offers a lot of benefits (as well as some complications). We get great scalability, elasticity, low cost of ownership etc. One problem however, is that the cloud is very public. I guess this isn’t a problem in most cases, but if what you are putting up there is supposed to be secret, or at least needs to limit who gets to use it, it becomes an issue.

I am currently working on a project like this. I am not going to talk about the project as such as it is under NDA, but the fact that it is is a service in the cloud that should only be used by certain clients is not uncommon.

The service has a front end that consists of WCF services, hosted in a web role, which is what we need to secure. The worker roles behind the web roles are by default secure as they do not communicate with the outside world at all.

More...

I have recently posted a few posts on how to use some of the new features of the Azure Service Bus. They seem to have been somewhat popular, which is fun. They are however very light weight introductions, and not that I am going to dig a whole lot deeper at the moment, but there are a few little things I want to mention.Mainly around brokered messages.

As you know from the previous posts, a brokered message, is a message that is sent to the bus from a client, and picked up by a service at some point. The message can contain a body, which could be more or less any class that you would like, as well as metadata about the message. The only thing to remember with those things, is the fact that the message size is limited to 256kb.

More...

I guess it is time for another Azure Service Bus post. The previous ones has been relatively popular, so I thought I would do one more post to cover one last feature in the bus. (I say one last now, but I am pretty sure I will be back…)

Topics and subscribers are the basic units behind the Service Bus implementation of the pub/sub pattern. And as expected from a “simple” pattern like this, it should be simple to implement, and it is. The basics would be, create a topic, add subscribers that subscribe to messages from the topic, and finally push some messages to the topic, which are then relayed to the subscribers. Simple as…

More...