As you can see in the below image the new magic “OS Settings…” button is now available.

Clicking on the “OS Settings…” button takes you to the following screen to configure your operating system options and how it is updated:

Hopefully, more updates will start rolling out to the dev portal over the coming months.

Well, times have changed and our tools for Windows Azure have got a little shinier, making cloud deployments much easier.

This update was something that I had been itching to do for a while but have been busy plotting world  cloud domination with my current project.

Drum roll please…

However, Scott Densmore over at Microsoft’s P&P group has pipped me to the post (literally) with a two part blog series on how to do your daily deployments to Azure using the Windows Azure Service Management CmdLets and MSBuild (part1 & part2). Scott has even added in the ability to upload your certs for SSL during the deployment.

The addition of the Power Shell CmdLets makes this a much concise set of build tasks, even updating your config to point to the correct storage and account using a custom Task, I still prefer using the MSBuild Extension Pack however.

Additions

One thing that I will be adding to my own set of build scripts will be uploading the package and config to Azure storage before I run the deploy tasks so that I can keep them in dated blob containers so that I can roll back to prior releases at a moments notice.

Guidance

There’s some great Azure guidance coming from Scott and Eugenio in the Patterns and Practice team so keep a watch on their site for all manner of Azure related goodness.

RiskMetrics is on of the leading providers of financial risk analysis and I have had the pleasure to be working with them over the past couple of months to deliver their RiskBurst platform.

The RiskMetrics guys, Rob Fraser (Head of Cloud Computing) and Rich Bower (Dev Lead) and myself will be delivering a presentation on the platform, our lessons learned and how this integrates with the current data centre RiskMetrics have.

The session will be taking place on May 27th from the Microsoft London office and is sure to be one not to miss, as these guys are doing some great stuff with Windows Azure and really pushing the platform.

Here is an outline of our session:

High Performance Computing across the Data Centre and the Azure Cloud

RiskMetrics, the leading provider of financial risk analytics, is engaged in building RiskBurst, an elastic high performance computing capability that spans the data centre and the Azure cloud. The talk will describe the design and implementation of the solution, experiences and lessons learnt from working on Azure, and the operational issues associated with running a production capability using a public “cloud bursting” architecture.

Sign up for the event here: http://ukazurenet-powerofthree.eventbrite.com

Infrastructure Access Layer (IAL)

The Infrastructure Access Layer is simply a way to abstract away your underlying infrastructure from your business logic or processing. This means that I can easily change how my applications interact with the infrastructure just by changing a method within the IAL and the business logic would be none the wiser.

Lets take a simple example, I may be developing an applications that takes work items and processes them. I create a method in the IAL called GetWorkItem which will return to my business logic the work item to be processed. This method can then call out to Azure Queues to get a work item, or maybe in the future you will want to switch out where we are getting the work item from, maybe we want to use a web service to call another location, use blob storage to store large work items or listen for a work item to be passed onto a service bus. This can all be dealt with in a single place.

All the business logic knows and cares about is that it is going to call the GetWorkItem method and get a work item back, not where it came from or how it received it it.

Cloud Ready…

Even with more and more people are moving toward the cloud, there are still companies that aren’t quite ready to make the jump, but realise that in the near future may have to and want to know how to create applications that will be able to transition easily to the cloud when they are ready.

By programming against the Infrastructure Access Layer companies will be able to make this move a lot smoother, by just replacing the needed classes so that they interact with the cloud rather than the old infrastructure.

A great example of this would be using a messaging system such as MSMQ as part of your on premise application, and then being able to easily switch this out for Windows Azure Queues or the App Fabric Service Bus when moving into the cloud. Having to make minimal if any changes to your business logic.

Keeping the cloud contained

As I talked about in my last post the cloud can end up getting everywhere and you can soon end up breaking the principle of DRY (Don’t  Repeat Yourself).

With the IAL you can easily keep the cloud contained, letting a minimal number of project have access to the cloud, making SDK upgrades and maintenance easier.

Is that it?

It is indeed. As I said at the start, the IAL is a simple concept that allows you to abstract away your underlying infrastructure from your business logic and also help create cloud ready applications for when people are ready to make that push to the cloud.

Clouds can Spread …

The ash cloud started out in Iceland where it eventually moved and spread out to cover the UK and Europe, even some reports say that it got as far as Canada. Grounding planes and crippling transport for a number of weeks.

This got me thinking, not all clouds are nice white clouds, some are evil volcanic clouds that actually do more harm than good especially when not contained to where we want them to be.  (the ash cloud would have been fine if it had not strayed into European airspace).

The same is true in your applications, when developing for the cloud you can find that the cloud can end up spreading throughout your applications and if your not careful touching every section of code you write.

This can then be a real problem when the underlying SDK to interact with the cloud changes and you have to go through all of your application looking where to refractor and make changes.

Contain Your Cloud

To combat this I contain any code that will access the cloud within few specialised “cloud” projects within my application.

This means that throughout the application if I want to access the Azure message queue, I call a single method from one of my cloud project that will return me a message, meaning that no other part of you application needs to know how to deal with the cloud.

Added Benefits

Containing your cloud not only allows you to keep to the DRY principles and code re-use it, makes maintenance of your application easier and can reduce code smells. One of the biggest benefits is that it also allows you to easier test your applications without having to rely on the cloud or developer fabric, as you can create your cloud methods in a mock-able way.

On one of my previous projects we had heard management talking about getting the team to give open and honest feedback to each other, what everyone was doing well, where people needed improvement this was both in a technical and social context.

After hearing this our dev lead on the project Simon Middlemiss decided to implement this with the project team and created a the “Extreme Retrospective”.

What it is…

The Extreme Retrospective is a combination of the agile retrospectives at the end of a sprint, that discuss what worked well as part of the Sprint and what could be improved and the rapid meeting turnarounds of the daily scrums, along with the personal improvement aspects from personal coaching or mentoring.

How it works

Performing Extreme Retrospectives are pretty straight forward (after the fear of giving feedback are gone) here’s how we did it:

Get a room

Find a room where you wont be disturbed (this means phones / laptops off too)

Lead by example

Dev Lead starts as way of example – can move when everyone is comfortable with giving feedback.

Only speak when its your turn

Only one person speaks at once – you cannot try to defend yourself or give justification

Be Self Critical

Person that is receiving feedback should take note and either act upon it or not

Feedback Sandwiches?

Each person when giving feedback should give a “Feedback sandwich” where by you have  a piece of good feedback followed by feedback on where an individual needs to improve finishing up with a piece of good feedback again.

Everyone has a turn

One the speaker has given feedback to each person in the room, the privilege to speak is passed to the person on your right.

Repeat

This is repeated until everyone in the room has received feedback and given feedback to everyone in the room.

Why it works

The main benefit that I got from these sessions was that it really opens the team up, getting everyone comfortable giving and receiving feedback especially when the feedback isn’t what the person was wanting to hear.

This meant that once the first extreme retrospective session had been complete the barriers were dropped on we could instantly feedback to others in the group when they were either doing something good and especially when they were doing something bad (hiding under the umbrella of feedback). Once peoples issues / strengths had been identified it was easier to view and take on board the good qualities of other peoples actions both because you knew where you needed to improve yourself and who on the team was doing something really well that you could try.

It also allowed us to keep members of the team on track and focused, as everyone could see if a team member was showing a bad point such as being easily distracted and the rest of the team could help out by letting the person know they had fallen back into old habits.

One of my major issues that I had with giving feedback and was highlighted in our first extreme retrospective was giving feedback and disagreeing with more senior members of the team / organisation when I thought it was needed. The first retrospective we did forced me to do this giving feedback in where I thought my dev lead / test lead could improve what they were doing. Once I had done this for the first time I felt more confident giving feedback not only to senior members of our team but in general around the wider organisation.

Want to know more?

You can read Simons original post on the Extreme Retrospective on our MCS UK Solution Development blog.

This article shows the basics of how to get started, for the added cool-ness of BDD and Cucumber check out Bens slides from the talk.

What do I need?

IronRuby

IronRuby is Ruby for the .NET platform build on the DLR which allows you to use the Ruby language to interact with your existing .NET code.

RubyMine

RubyMine is a very cool IDE for developing Ruby applications that Ben used in his DDD demo, there are many other Ruby IDEs available including TextMate for the Mac and RadRails for Eclipse.

Now that we have all the none .NET pre-reqs downloaded and installed we can get to business.

Create Application Under Test

First things first, lets set up a skeleton application in Visual Studio that we will test. Here I just created a blank class library called IronRubyMine with the Person class within it. Build this code so that we have a dll in the bin/Debug directory.

namespace IronRubyMine
{
    public class Person
    {
    }
}

Setting up RubyMine for IronRuby

Within RubyMine I have then created a project in the same directory as my sln file for C# application, this will generate all your Ruby classes in the same location as your .NET app.

Once we have the Ruby solution we need to do a few tweaks to get it to work smoothly with .NET. Start off by adding the IronRuby SDK for use with the project (File – Settings – Ruby SDK – Add SDK…) and browse to the location of your IronRuby install and the ir.exe file.

Now RubyMine is using the IronRuby SDK we need to make another minor tweak to the Run/Debug configuration the files in the project. You will need to alter the Ruby Arguments to:

-e STDOUT.sync=true;STDERR.sync=true;load($0)

There are a number of discussions on the RubyMine forums how to best do this, but I have found that this alteration is the easiest and most straight forward way to get it all working.

Red – Create Failing Test

With our environments set up we create a simple test that fails before we write the code that we want and make the test pass.

require "test/unit"
require "IronRubyMine/bin/Debug/IronRubyMine.dll"

class PersonTest < Test::Unit::TestCase

  include IronRubyMine

  def test_create_person_called_dominic
    dominic = Person.new("Dominic")
    assert_not_nil(dominic)
  end
end

The second line pulls in the .NET dll that we created in our app allowing IronRuby to call any classes and methods that we create in our C# code. This is then used further down to create a Person object.

On running this test we will get a red light as we haven’t yet implemented the C# code to go alongside the test.

Green – Make Tests Pass

Now we can go back to Visual Studio and create a Person constructor that will take in a name, hopefully making our tests go green.

Once we have the code in place, build the application to ensure that the dll is updated and our IronRuby code is using the latest implementation.

Now jump back into RubyMine and re-run the tests.

Refactor…

You get the picture, with all our tests now passing we can do any refactoring needed and then go on to create more tests.

With this simple implementation in place we can build on this to implement more advanced techniques described in Bens presentation.

Eye On Earth is a stunning Silverlight application build on Windows Azure, developed by Microsoft MCS UK and the European Environmental Agency.

Check out the full article here.

Find out more about Eye on Earth here.

Vote for my session

Voting for sessions at DDD Scotland is open and this is a plea that you all go and vote for my session at the event (doesn’t even matter if your attending – just vote for me).

I will be doing a session on what I have learned about Azure and cloud computing over the past year I have been developing on the platform. This knowledge is expanding daily so I have a lot to share, including best practice, deployment and some nifty “cloud patterns”.

Cloud Coffee – A Year Developing on Windows Azure

Cloud Coffee is the latest in a wide range of coffee shops on the high-street. What makes Cloud Coffee different is that they use latest “cloud” principles, keeping costs low by using utility based staffing, maintaining a decoupled working environment and ensuring good scalability to meet customer demand. Cloud Coffee has very quickly risen to high street fame.

This analogy will help you understand how things work in the cloud, specifically Windows Azure. During this talk Dominic will elaborate and expand upon on the concept of ‘Cloud Coffee’, sharing some of the lessons he learned, best practices and patterns that have emerged whilst developing one of the first production applications for the Windows Azure Platform.

Why are you still on this page?! Go vote.