Refactor and Review

Review.And.Refactor

I’ve started to bring this “spike” to a close since I’ve set out to figure out the stuff I needed to using a few Azure services and got to a point of refactoring.   When I get to this point with a spike, I set out to do the following things listed in the task list you see here.  I’ll step through the why for each of them.

  1. Refactoring for Interfaces – I tend to build up a few concrete types which don’t need to be added to an IoC container for injection, I try not to abuse Unity even though it’s pretty awesome.  Until I find out that maybe a member needs to be injected to reduce a bit of coupling across the solution.  So, I’ll look for these opportunities across the solution and extract an interface and either add it to the container or do some poor man’s injection w/o the container – it just depends on the context of the type’s usage.  I agree, more interfaces are better, even marker interfaces serve a purpose but I try not to go crazy with anything, interfaces included.
  2. Logging – At this point, I know more than I did a few weeks ago and I’ve got a clearer idea of what I want to log.  This time I just need to build up the event source class for the app based on what I learned.  That’s it.  No more, no less.
  3. Magic Strings and Numbers – This one is special. I litter the application with strings and sometimes numbers and this is the best time to go back over the entire solution to pull them out and into something like constants, that’s what worked for this exercise.  I’m walking through all of the code to see if it makes sense, especially the bits that I’ve not seen in a few weeks.  I forget sometimes what I was thinking, and clarifying with a better member or method name is always better than adding comments.  And yes, I’ve got a small battery of tests to fire off after each changeset gets checked in.
  4. Plumbing for cross-cutting stuff – Now that the logging events are done, I need to plant them in the classes that are doing the work.

Not much here, just some habits I’ve been using over the years to keep solutions clean, readable, and hopefully maintainable.

HTH / oFc

British Lunch

Victoria.Sponge.YumMy girlfriend’s nanny is so awesome when it comes to working with kids.  She and her husband are from the UK and I thought it’d be a nice gesture to make her family a “British Lunch” this past Sunday.  Her Dad and Mum are visiting from the UK as well and I thought I’d get some pretty good feedback from them on how well it turned out.

I found Jamie Oliver’s “Jamie’s Great Britain” cookbook (http://amzn.to/qFmHSo) and used that for inspiration and guidance.  The measurement for each recipe are in American Standard which help with the metric conversions I thought I’d need to do.  So, that gives the book a few stars to begin with.

The menu.

Empire Chicken, Superb Pork Loin, King of Mash : Irish Champ, Victoria Sponge, and Welsh Cakes

Everyone ate a lot, and although the desserts were chilled to keep them somewhat fresh, everyone appeared to enjoy the food and commented nicely.  We finished up dessert with a nice tawny port, very delish!

I was really happy to do this for someone that gives so much on a daily basis, I’m looking forward to doing something like this again sometime soon too, maybe if it’s even to serve a Victoria Sponge moments after taking it out of the oven.

So much yum!

oFc

 

Azure SDK and SLAB

Rosetta StoneRight before I skated out of the office to start my four-day Memorial Day weekend I jotted down a few notes to blog about which outlined what worked for me using the P&P Semantic Logging Application Block (SLAB), as well as a few other sticky points while I was trying to stand up couple Windows Azure roles.

It’s really easy to get tangled up with broken builds when you introduce an updated library/dependency into your projects.  And going backwards a few minor versions just feels wrong when you want to “ship” with the something you want to stay current as long as possible.  While NuGet was handy at keeping everything up to date, it did get in the way at times when I need to swap around a few bits.  On a side note, the Package Manager CLI makes removing and adding things a whiz!  I’m still a huge NuGet fan.

I started out with a 4.0 framework solution, then moved it to the 4.5 framework so I keep it at, or start at, 4.5.  There was nothing wrong with 4.0 until I started adding the dependencies in.  For example, the 2.0 Windows Azure (WA) Storage, Runtime, and Configuration bits I installed from the WA site (http://bit.ly/v5MF7m) install v2.0.5.1, and those assemblies ran on top of 4.0 just fine.  This got me through the bulk of the coding to stand the application up.

Then in a previous post I mentioned I wanted to add in some logging pieces and wanted to give SLAB (http://bit.ly/Vh3Umz) a go.  The sample code didn’t work with what I had on my box for some reason, which gave me a clue I might have some depedency issues coming at me with my code.  The P&P code was easy enough to read through but the namespaces had a few changes at RTW time that I needed to work around, and was expected.

In addition to this, I had to work around issues between WindowsAzure.Storage and the MS.Data.Edm, MS.Data.OData, and System.Spatial assemblies.  I started out satisfying the dependencies with using v5.0.2.0 for them, but *really* wanted to make the latest, v5.4, work, but most of the blog posts I read through confirmed v5.0.2.0 was the way to go.  So the final fall back to get everything happy was to use v5.2 for the Edm, OData, and Spatial assemblies.    Then I learned of the (v5.0.2.0) Edm, OData, and Spatial dependencies.

Inside the SLAB reference application, the console application project took a dependency on an earlier version of Edm, OData, and Spatial and I didn’t want to go that far back – stuff should just work, right?  And it finally did. The logging pieces weren’t throwing anything, but they weren’t working.  The table used to persist the logging entries wasn’t getting built (if it didn’t exist) inside local table storgae, so nothing was being logged.

The answer was to use the Edm, OData, and Spatial v5.2.0.0 assemblies. Bingo!  Everything was firing, and all my tests were still passing so it was very green day once I got all of the zen sorted out in my assembly references.

Below is a list of assemblies with their dependencies sans the ones that come OOTB; hopefully this can help someone bumping into this as well.

HTH / oFc

WebRole (MVC4) Project

  • Microsoft.Practices.EnterpriseLibrary.Common v6.0
  • Microsoft.Practices.EnterpriseLibrary.Logging v6.0
  • Microsoft.Practices.Unity v3.0
  • Microsoft.Practices.Unity.Configuration v3.0
  • Microsoft.WindowsAzure.Storage v2.0.0.0
  • Microsoft.WindowsAzure.StorageClient v1.7.0.0
  • Unity.MVC4 v.1.1.0.0

WorkRole Project

  • Microsoft.Practices.Unity v3.0
  • Microsoft.Practices.Unity.Configuration v3.0
  • Microsoft.Data.Edm v5.2.0.0
  • Microsoft.Data.OData v5.2.0.0
  • System.Spacial v5.2.0.0
  • Microsoft.ServiceBus v1.7
  • Microsoft WindowsAzure.Configuration v1.8
  • Microsoft WindowsAzure.Runtime v1.8
  • Microsoft WindowsAzure.Storage v1.8
  • Microsoft WindowsAzure.StorageClient v1.7

Infrastructure Project

  • Microsoft.Practices.EnterpriseLibrary.SemanticLogging  v1.0
  • Microsoft.Practices.EnterpriseLibrary.SemanticLogging.WindowsAzure  v1.0
  • Microsoft.ServiceBus v1.7
  • Microsoft WindowsAzure.Configuration v1.7
  • Microsoft WindowsAzure.Runtime v1.7
  • Microsoft WindowsAzure.Storage v1.7
  • Microsoft.ServiceBus v1.7

Table Storage Hiccups

So, like most of us, I thought hooking up table storage would be easy.  Turns out, it’s not if like to keep up with the latest and greatest support libraries.

The first hiccup came when I tried to connect to my local storage service (UseDevelopmentStorage=true).  Well, now you need to specify the URI that points to the local storage emulator and like the blog post author states, “it just magically works”

Now that I had the table sitting there, the next hiccup came when I asked my table service context to build the table if it doesn’t exist.  This one was kind of bad, not something I expected.  First I used the Azure SDK library my exception told me I needed, in this case Microsoft.Data.OData (v5.2.0.0).    There’s a newer version of it as well, v.5.4.0.0, that didn’t work either even with an assembly binding redirect.  I installed v5.4 with NuGet and then had to uninstall it manually by clearing out the package.config entries and dropping the references.  Then using the Package Manager Console I installed v.5.0.2.0 instead w/o the binding redirect and it worked.

The last hiccup was getting the entities to insert into the table.  You can find more about CRUD here, and Table Storage CRUD operations here.  A side note on that embedded link, it discusses versions 1.7 and 2.0 – yesterday I was looking at 1.7, not 2.0 so check which form of the page you are looking at before you start coding.

My partition key was missing and the row key and the timestamp properties were null.  I read that the table client took care of this for me, so I used DateTime.UtcNow for a default property, and fixed up my extension method that gen’d my TableEntity for me.  That error came in the form of [ The remote server returned an error: (400) Bad Request ].

Here are the links I eventually found that bailed me out today.  All the code is working and I added a few more guard statements to do some additional state checks before the CRUD bits fire.  Hopefully, the blob storage stuff is ironed out implicitely as well with all of this dependency churn today.

HTH / oFc

Differences between Azure Storage Client Library 1.7 and 2.0

If you decide to use v5.0.2.0 read this.

What Azure allows inside a table entity during CRUD operations

How to use the Table Storage Service

Technical Evaporation…

This is the process of getting some data out of the local environment and up to the cloud – actually this is what evaporation is – the moisture has to come from somewhere whether its my backyard or the Gulf of Mexico and get up into the atmosphere and form the cloud to make the rain, right?

Like I mentioned, in the previous post I have been using mock data to get some of the view plumbing working so now I need to actually being taking things off my Azure Service Bus queue and putting them somewhere else.  I didn’t think about this b/c I just wanted to let the app’s development process lead me to the next feasible (and cheapest) choice for storage and persistence.  And the thought in the back of my mind is something that Ayenda Rahein said in a keynote a few years ago… “we should be optimizing for persisting data, not retrieving it.”  Yeah, pretty big statement, but it’s true.

So, the simplest thing I could do would be to persist everything into Azure table or blob storage until there’s some requirement for reporting then maybe a database can come into play.  I have to pay extra storage and compute costs on my Azure account to host a database and I don’t really need a full blown database instance right now.  I can just figure out what I need by stuffing things into something flatter and cheaper.  But, if I code this right, I should be able to move it into an instance if something triggers that need.

Moving on.

I settled on blob storage for my logging and table storage for my application data.  I built my code from this post which had some quick and dirty examples about accessing Azure’s table storage.  It turned out nice so hopefully it can be extended for other table storage persistence needs in the future.  Not as generic as I would have liked it, but it works for now.

Now, the app is throwing something somewhere b/c the local worker role is puking and coughing pretty hard right now.  So, back to my earlier post from yesterday, even though my tests are passing I need something to catch this junk so I look at it.  This will allow me to wire up the blob storage client – oh, there’s the PowerShell stuff to get to as well.  Should be a full(er) day today.

HTH / 0Fc

What Happens When It Stops Raining?

sunnyday

When we notice our cloud has stopped raining, it’s time to take a look under the hood to see what happened?  Or, is there a better place to look before we raise the hood?  A few questions to ask:

1) Was it something I did?

2) Was it something that happened inside one of the Azure instances?

3) Did the application run out of work?

4) Where can I look to see what was going on when it stopped?

Only you can answer the first question.  If all of your tests aren’t, or weren’t passing, and promoted something to a production instance you might be able to answer this fairly easily.

The second question assumes you’ve can get to your management portal and look at the analytics surfaced by Azure.  There might have been, or might be, a problem with one or more of your instances restarting.  I’ve never seen either of my instances stay down after a restart unless there was an unhandled exception getting tossed around.  Usually I find these problems in the local dev fabric before I promote.  Sometimes I don’t though, so on a few occasions even though my tests were passing I had missed some critical piece of configuration that my local configuration had, and the cloud config was missing.  I call this PIBKAC – problem is between keyboard and chair.  Usually the analytics are enough to tell you if there were problems.  And from there you can fix configuration if needed, or restart your instances or other Azure feature you’ve got tied to the application.

The third question is kind of a sunny day scenario where the solution is going what its supposed to in a very performant way.  However, sometimes ports can get ignored b/c of a configuration issue like I mentioned prior as one example.  If you’ve been storing your own health monitoring points you can probably tell if your application has stopped listening for new requests, or simply just can’t process anything.

The fourth question talks about having something that’s looking around the instance(s) and capturing some of your system health points: how many messages am I receiving and trying to process; how quickly am I processing the incoming messages; are there any logs that can tell me what was going on when it stopped raining.

I’ve been using Enterprise Library from the PnP team for >6 years and I still love the amount of heavy lifting it does for me.  The wire-ups are usually easy and straightforward and the support behind each libary drop is constant and focused.  Recently Enterprise Libary 6 dropped with a bit of overhauling to target 4.5 among other things, and here’s a blog post by Soma that discusses a few at a high-level.

I’ve used the Data and Logging Application Blocks, as well as Unity successfully.  I had recently started wiring my solution to use the Azure Diagnostics listener to capture some of the diagnostic events, particularly instance restarts from configuration changes.  Now, I think/hope I can use the logging application block to wire all of my logging events and push them to something simple like blob or table storage.

I’ve never like a UI that I have to open up and look through, it just makes my eyes tired and its annoying – I’d like to have something a little more easier to lookup fatal and critical logs first then go from there.  PowerShell (PS) looks cool and fitting for something like this, and I can probably do something quick and dirty from my desktop to pull down critical, fatal, or warning logs but I’m not a PS junkie.  But it would make for an interesting exercise to get some PS on me.  Oh, on a side not I picked up this book to (re)start my PS journey and so far it’s been worth the price I paid.  Some of the EntLib docs mentioned pushing data to Azure storage so I may just start there to see if this can work.

Here’s the doc and code downloads if you want to take a look around.

HTH /oFc

Black Beauty Rides Again…

work.and.play

Well, it’s not like she’s been off the road for a while but with all of the rain last week I just thought I’d be safer and not challenge the elements and wait.  And the wait was so worth it.  I mapped out a ride down yesterday morning with a burger stop in Lakeland – it was a great ride!  Here are the details: http://bit.ly/10dPXnJ  This should be a public page, sorry if it’s not but it may be b/c it’s part of the Harley Owners Group Ride Planner site.

About 1/2 way to Lakeland I had to stop to clean the love bugs off my helmet.  It was pretty bad, and nasty but ’tis the season here in Florida.  My bike was pretty covered in them as well but it just needs a quick bath and it’ll be good as new.  The ride was just over 100 miles and it was such a great day of riding.  Great for clearing out your mind and enjoying the beautiful state of FL.

/oFc