Try Not To Boil The Ocean

Do you use TDD to help shape your application’s design?  I do, although I’m not as strict as I used to be.  I used to test eeeverything, now, not so much.  I was a fly on the wall during some Agile coaching sessions from “The Dude” at my shop; he kept making a statement during one particular coaching session – “Let’s not try to boil the ocean, ok?”

I know he’s not the first one to say this, it’s a pretty common saying.  The context was around stories, epics, and setting up a story map and making discrete stories that can simply organize work items for the team to work on – small bites, Legos – pick your analogy.  It just allowed for the story map to flow better and to give the team context around what’s next, and what “it” is what’s being accomplished.

I try to do the same thing with TDD – as I’ve mentioned in other blogs, testing the framework isn’t as valuable as testing your own code, right?  I mean, if there’s a bug in a(the) framework you’re using you’re going to find it sooner or later if you are pressing any particular namespace pretty hard.

One thing I also learned from Uncle Bob was that TDD can help you understand a framework – probably not as much as Code Kata, but so TDD helps me understand the namespace(s) I’m working in and keeps the context and responsibilities of the classes tighter and more cohesive.

Moving on…

I started out trying to boil the ocean for the Windows Azure Media Services (WAMS) because I didn’t get how everything was wrapped together and how things were processed.  There’s things you can’t mock, but some things you can.  There are many interface types you can implement to make your own mocking types for quicker tests, and understanding these interfaces once they’re implemented inside your own concrete types helps tell the story of what they’re doing.  Here are a few that I worked with extensively while I was baking my infrastructure classes: IAsset, IJob, and ITask – I got a lot of mileage (and headaches) unraveling and re-wrapping this stuff for my little brain.

Reducing the temperature from 212F (100C) to a light simmer…

I started with the business layer tests, the thought being I’d spin up some fast(er) running tests in that space first, then move into the infrastructure layer(s).  The effect was my business layer tests had too much code in them.  I was building up some of the infrastructure types while I was building the business layer types and tests – not good.  So I stopped and just focused on the infrastructure bits.  Here’s how the infrastructure assemblies looks right now:

infrastructure

infrastructure tests

There’s four separate services I’ve created for interacting with WAMS.  Each service is something you can do with the WAMS portal, and I wanted to break it up like that, the only thing missing is a publishing service that actually tosses the media over the wall and a URL is assigned to the content you’ve uploaded and encoded.

I’m not using an IoC container yet to spin up concrete types for me, so to keep the tests simple for now I’m just building the concrete types by hand.

 

This was all I need to do to keep the infrastructure types from polluting my business unit tests.  Most of these infrastructure tests are bouncing up against WAMS for now, but my business layer test will be using a few mocked out types using the interfaces I mentioned above.  Once the publishing service and the business layer tests are built out I’ll blog those, but now I’ve got to put some thought into how this application is going to use the business layer, so it’s time for a little (more) story mapping.

HTH

oFc

Starting With Another Clean Slate

Starting out with a sample from here, I wanted to build out some reusable libraries I could use with other projects if needed, but focus the focus of the libraries on a new application which can take advantage of Azure’s Media Services.  I also learned a few things from my last application I built, and I want to incorporate those bits into the solution as well.

Spinning Up Some Media Magic

I was looking over some old app designs I shelved last year, they needed some support from something like Windows Azure Media Services, but they weren’t baked last year;  maybe the preview was out when I last looked, not sure.  Recently, I’ve been toying with the idea of getting one of these applications stood up using WAMS now that they’re ready.

I used this chain of posts to get a small harness built and get an understanding of what this stuff does and how it works together to create assets, then encode and stream in various formats, or convert the formats.  The sample code is a bit of a fire house, but the post(s) explain what’s going on with each chunk coming out of the fire-hose.

What I wanted to share is related to a post where I was fighting with a few assembly references and how they were mixed up and giving me a rash.  I asked NuGet for the WAMS bits and here’s what installed:

WAMS.Dependencies

I remember using some of the 1.7 assemblies, but not the 5.1 assemblies;  not a huge thing, but if the other project I was working on last week got mingled with this one, there might be some challenges.

The WAMS stuff looks fun, and its something new for me, I’ve not done much of this stuff except for using OS apps to convert media files from one format to another; so the curve may be steep starting out but yesterday I flattened it a bit and have a working harness that’s using my WA dev account.

HTH / oFc

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

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

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

Squeezing The Rain Out Of A Cloud

mostly.cloudy.rain.xlarge.mod

This week’s weather has been overcast and cloudy, and this morning the forecast looks like the image above (according to an online weather source).  So I thought I’d share a few things I worked through yesterday and this morning to get some rain out my cloud.

Here’s what the solution is using, so far:

MVC 4 Internet project – and all the scaffolding bits it gives us. Nuget packages only include Unity.Mvc4 & Microsoft.ServiceBus right now.  I’ve got some ideas for logging that’ll use some of the PnP Enterprise Library goodness to wire-up some business and system logging for this solution, as well as tap into Wasabi for scaling & throttling ideas I have for the solution – more on the last two later on though.

The solution is pretty simple, and that’s how I’d like to keep it for now.  But I needed to start pulling some mock data into grids to start with, and historically being a server-side coder I started out trying to unload my collections with some of the HTML helpers Razor exposes to us.  But it really just didn’t feel right and I found myself trying to hack something together to get some data into the view.  The night before I was having a conversation with John Papa around UI/UX content enablers.  He makes all of this stuff look so easy, so I thought, sure I can do this too so I set out to jam in a JQuery plug-in to spin through my data.

I settled on jqGrid with only a few minutes of looking around the jQuery home page.  So not being the client-side junkie most folks are these days I started Binging for code samples.  After a few hours (seriously, I’m not that smart and somethings take longer than it should) I found a post on Haack’s site that talked about what conventions need to match and which ones don’t.  Oh, and after a minutes I fixed the signature on my controller action and the code started lighting up.  Now it’s only formatting I need for a few views which I won’t burn too many cycles on.

Using Phil Haack’s example, I had jqGrid running in a few minutes.  But I will say this – I did learn alot about the Html Helpers ASP offers, they are powerful and very handy.

The side of effect of this choice was larger than I thought though and required a bit of refactoring.  The view receiving this data was strongly-typed with  IEnumerable and now that the data was coming from a jqGrid call to an action that returned a JSON payload, I didn’t need that.  The repository method that was serving the data to the controller looked funny now.  I needed to scope the method to just return the requestor’s data, not all of the data.  I may still split this interface up because of ISP, but I’ll keep my eyes open for code smells just in case.

So, there’s a bit of refactoring going on today before I hookup the Azure persistence piece which is next.  I haven’t quite figured that out yet, but soon.  The easy part about this is I can still target my Azure Service Bus queues, and tap into the local storage emulator on my local box until I figure out data and or document shapes for the storage thingee.

Here’s a gist with the view and controller source.

HTH /oFc

Living Inside a Cloud Should Be Easy, Right?

crescent-wrench

It’s been a few months since I dropped the Azure SDK on my desktop and the tooling and changed considerably to say the least.  The portal changed a bit as well, but once you get used to it, it just works for you, and unlike before you can see everything that’s going on “up there” at a glance.

However, back in the IDE, particularly inside the code there are more pieces that are supposed to bolt up to your Azure code.  And if you’re using an MVC 4 web role you can push in a NuGet package called Unity.Mvc4 with comes with the this handy little bootstrapper you can use to load your Unity container using the UnityConfig class that runs next to the bundler and routing configs in the App_Start folder.

This was one thing that I didn’t realize was new to the MVC 4 scaffolding.   These config classes help keep things we’ve piled into the Global.asax for a long time.  And the UnityConfig class follows suit nicely.

The idea with the bootstrapper is to help keep the type mappings contained, but loading when the app domain spins up each time.  All of the other pieces appear to act the same, i.e. life-time management, aliasing, and child containers.

The last thing I’ll mention about things fitting together is when I started this solution months ago, I was using a previous version and the upgrade wizard didn’t fire-up so I didn’t get a bump on my web role “and that’s when the fight started”.

If you’re trying to preserve your old solution and you’re trying to get it to act like an MVC 4 template, don’t.  If you don’t get the version bump from the IDE, stop.  Create (or add) a proper MVC 4 project from the project template dialog and go from there.  Copy your code to the new one, fix up the usings and references and keep going.

While I was doing this refactoring and sorting out my existing unit tests the code started to thin out and I realized that the MVC 4 bits could do what I was making the older MVC project do.  It just took a bit of frustration and brute force to recognize this and keep coding.

I had the unique pleasure of deleting a lot of code, and still have everything work, well.  Just had to sync with the tooling and the way things are supposed to fit together now.  Same tools, just a different approach sometimes when the bits are out in front of the IDE.  Not a bad thing, just different, and better.

*** Update ***

So I didn’t need the UnityConfig class anyway.  The NuGet step actually plugged the bootstrapper into the root of the website and exposed a static RegisterTypes(IUnityContainer container) method that handles the mappings.  I usually don’t wrap my type registrations in code, but rather in the configuration file so I can easily add types on the fly.  The bootstrapper exposes a static method that handles returning the container.  Here’s a code snippet with one registration added.

Bootstrapper

 

 

 

.

 

HTH /oFC

Clouds Need to Make Rain, right?

Clouds Need to Make Rain, right?So I’ve been working on this cloud stuff off and on for a few months now.  And while the cloud vendors try to make it easy to work with cloud stuff, things aren’t always intuitive unless you clear your mind and don’t try to do what you remember, but actually how you’re being told they need to work.

Then after taking your code around the block a few times, you take something someone else coded or created and make it your own.  Most of the time it works this way, but there are times when it doesn’t and you just have to apply brute force and push that rock back up the hill.  And once you do the first time, everything starts to click (and work).

I guess the idea here is working with cloud technology is fun, and challenging but you have to keep your eyes on what you set out to build initially and not get bogged down in why something doesn’t work.

If if  doesn’t work, start from scorched earth, as in, throw away *all of your code you just wrote* (hard to do sometimes) and start all over.  I did yesterday and tossed about 1,000 lines of source code – and worked around a problem in about 15 minutes I’d been dealing with for a while.

Of course there were other (positive) external forces that helped me get beyond the block I was experiencing, but scorched earth was the right, first, step to take.

And as it worked out, my piece of the cloud started raining on the scorched earth and once all of the smoldering finished, I had something really nice to work with and continue working with.

HTH – oFc