Rework Reminder (Kill your BDUF, Code Smells, Anitpatterns, Etc ASAP!)

Rework is ok.  Refactoring is ok.  BDUF (Big Design Up Front) is bad.  Minimal amount to get to market is good.  Getting to market is good.  Don’t get into analysis paralysis.

Best book that cleanly cuts to the chase I’ve read in a long while:  Rework

…and a few friendly reminder videos.

I really can’t emphasize how much better an individual or a company is at getting things done, getting things to market, and generally improving what they do in life when taking a lot of the advice in this book to heart.  Read it.  Know it, and kill the things that are dragging you and your company down.

Thanks.  This has been a friendly public service announcement by yours truly.  Adron B. Hall here at Composite Code Blog.  😀   Cheers!

Windows Azure SDK Unit Testing Dilemma — F5DD Plz K Thx Bye

I’m a huge advocate for high quality code. I will admit I don’t always get to write, or am always able to write high quality code. But day in and out I make my best effort at figuring out the best way to write solid, high quality, easy to maintain, easy to read code.

Over the last year or so I’ve been working with Windows Azure (Amazon Web Services and other Cloud/Utility Platforms & Infrastructure also). One of the largest gaps that I’ve experienced when working with Windows Azure is the gross disregard for unit testing and especially unit testing in a Test Driven Development style way. The design of the SDK doesn’t make unit testing a high priority, and instead focuses mostly on what one might call F5 & Run Development.

I’ll be the first to stand up and point out why F5 Driven Development (for more on this, check out Jeff Schumacher‘s Blog Entry) is the slowest & distracting ways to build high quality code. I’d also be one to admit that F5 Development encourages poor design and development. A developer has to juggle far too many things to waste time hitting F5 every few seconds to assure that the build is running and code changes, additions, or deletions have been made correctly. If a developer disregards running the application when forced to do F5 Development the tendancy is to produce a lot of code, most likely not refactored or tested, during each run of the application. The list of reasons to not develop this way can get long pretty quick. A developer needs to be able to write a test, implement the code, and run the test without a framework launching the development fabric, or worse being forced to not write a test and running code that launches a whole development fabric framework.

Now don’t get me wrong, the development fabric is freaking AWESOME!! It is one of the things that really sets Windows Azure apart from other platforms and infrastructure models that one can develop to. But the level of work and effort makes effectively, cleanly, and intelligently unit testing code against Windows Azure with the development fabric almost impossible.

But with that context, I’m on a search to find some effective ways, with the current SDK limitations and frustrations, to write unit tests and encourage test driven design (TDD) or behaviour driven design (BDD) against Windows Azure, preferably using the SDK.

So far I’ve found the following methods of doing TDD against Windows Azure.

  • Don’t use the SDK. The easiest way to go TDD or BDD against Windows Azure and not being tightly bound to the SDK & Development Fabric is to ignore the SDK altogether and use regular service calls against the Windows Azure service end points. The problem with this however, is that it basically requires one rewrite all the things that the SDK wraps (albeit with better design principles). This is very time consuming but truly gives one absolute control over what they’re writing and also releases one from the issues/nuances that the Windows Azure SDK (1.3 comes to mind) has had.
  • Abstract, abstract, and abstract with a lock of stubbing, mocking, more stubbing, and some more abstractions underneath all of that to make sure the development fabric doesn’t kick off every time the tests are run.  I don’t want to abstract something just to fake, stub, or mock it.  The level of indirection needed gets a bit absurd because of the design issues with the SDK.  The big problem with this design process to move forward with TDD and BDD is that it requires the SDK to basically be rewritten as a whole virtual stubbed, faked, and mocked layer. Reminds me of many of the reasons the Entity Framework is so difficult to work with for testing (has the EF been cleaned up, opened up, and those nasty sealed classes removed yet??)

Now I’ll admit, sometimes I miss the obvious things and maybe there is a magic “build tests real easy right here” button for Windows Azure, but I haven’t found it.  I’d love to hear what else people are doing to enable good design principles around Windows Azure’s SDK. Any thoughts, ideas, or things I ought to try would be absolutely great – I’d love to read them. Please do comment!

Improving the Time Suck of Social Media

Social media, albeit being a great boon in many regards, has also become a massive time suck for almost everyone involved!  Sure, news is up to date, down the the minute, almost real-time with every single little bit of craziness there to read about right now!  The t0-read, to-do, to-make, to-code lists all keep getting longer and longer and longer…

…and then…

Crickets.

That’s right, you might as well be listening to crickets.  Social media is killing many productive people’s productiveness.  I’ve decided I’m going to take a break, of some sort, just not sure what kind.  Maybe I’ll schedule myself some “social media time” or something.  Similar to “TV Time” for kids.  If only parents were better about that, maybe social media wouldn’t be the ADD person’s massive time blow that it is.  Well, as I write this I’ve determined the following.

Twitter

I’m going to time box the activity and use specific tools that enable me to effectively use the social media services.  Twitter, that needs to be done on a PC with Seesmic or something that allows me to truly and quickly interact.  None of this half-assed mobile super phone poking about on the Blackberry, or twiddling about with Twitter on the iPad.  Those other tools just don’t allow the speed and ease of viewing links and other such things that using a full on PC with power allows.  I want to get in, see what’s up, filter the crap I don’t want to read out of the way, tweet, and get the hell out of there.  I want bus time, walking time, and other activities back for other uses.  I want to just read a book, or just take a walk again.  No twittering while riding or walking anymore.  Done.  Gone.  Zilch.

My time box at this time is going to be limited to 15 minutes a day.  In the morning and in the evening sometime.  In that time I have the following things I need to straighten out;

  • Get synced up on who I am and am not following, and review my list of recent followers to see who I should be following.
  • Find a better way to track tweets.  Lists are useful, but there needs to be something more.  Maybe Paper.li or something of that sort.

Both of these tasks need knocked out with the time boxing I’ve allocated.

Facebook

This I’ve already relegated to minimal use.  I might use it about 15 minutes to 2 hrs a week.  I’m actually amazed at this fact.  Simply, I have a Facebook Profile because one kind of needs to have one being in the technology industry.  Also it provides a great avenue for keeping in touch with people that I might otherwise not be in touch with.  It’s good to know people I grew up with are doing well, providing a little morale boost here and there.  🙂  Plus, one never knows when a blast from the past might turn out to be a great friend, asset, or network contact here in the present!

Time boxing for Facebook is going to be limited to 5-10 minutes per day.

Blogging Here @ CompositeCode.com or elsewhere…

This is something that I find truly useful.  Not the time suck like these other web apps.  So really I’m not going to time box myself or set some arbitrary limit.  I am going to continue striving to have at minimum a blog entry per week.  One that is partially useful, even if it is just to review what I’ve done for the week, conferences or meetups I’ve attended, or something of that sort.  Hopefully I’ll be able to maintain some actual useful code how-to, cloud computing write ups, and other legit, honest to goodness, readable entries as well.  🙂

So no time box for blogging, this is something I truly love to do.  Write, write, and more writing.

With that I’m off to find some time tracking software to help myself stay in the time boxes I’ve set.  Cheers, and happy holidays!

Windows Azure SDK 1.3 Broken Deployments

I’ve been using the 1.3 SDK now for about a week.  I have one single machine that can deploy an ASP.NET MVC Application to Windows Azure.  The other 32 bit machine and 64 bit machine do not, fail pretty much every time I do a build on them.  This is how it looks so far.

Machine 1 is: 32 bit, 4 GB RAM with Win 7, .NET 4.0 with VS 2008 + 2010 individual installs of software over a period of about 10 months.  In other words, it isn’t the cleanest installation anymore.

Machine 2 is: 32 bit, 4 GB RAM with Win 7, .NET 4.0 with VS 2010.  Relatively clean enterprise level installation of Windows.

Machine 3 is: 64 bit, 8 GB RAM with Win 7, .NET 4.0 with VS 2010.  The installation is literally 4 days old now.

Machine 3 fails to provide a build that is deployable every single time.  It creates what I call a “Ghost Deploy”.  See the video below:

Machine 2 actually completes a deployment after setting the assemblies in the ASP.NET MVC Web Application to local and removing the diagnostic configuration settings.  This is the only machine I’ve had successfully deploy a Windows Azure 1.3 SDK ASP.NET MVC Web Application in the last week.

Machine 1 actually just spools the deployment into the Web Role, but then it spins, busy without starting.  Once after about 45 minutes it did finally stop.

In the video I did not have a certificate added to the web role, but have since added one and tried to launch the web app (on Machine 2), still nothing.  It at least does not turn into a Ghost Deployment.  On machine 3 the deployment with the certificate still just dies.

I’ve tried to set all assemblies to local, I get no changes.  I’ve assured no configuration changes have diagnostics in them.

Machines 1 and 2 both deployed Windows Azure ASP.NET MVC Application without any issue before SDK 1.3.  Machine 3 I’ve just built, so certain issues may be inherent in the machine load itself, but with the other issues still rearing their heads, I doubt that Machine 3 is at fault but instead am leaning toward SDK 1.3.

Anyone else out there having any issues?  Seen the continual spooling?  Compared to SDK 1.2 (which I didn’t even have a single issue with) this is really disconcerting.  I encourage cloud technology use to major enterprises, and this type of mistake is worrisome.  Fortunately for me (or maybe I should say fortunately for Microsoft) I’m not pushing any efforts with the 1.3 SDK right now.  It has a few new features I’d really like to try out, but at the current time I can rarely get a decent deployment, let alone something that tests out the new features.  Plz fix k thx bye.  🙂

Windows Azure v1.3 SDK Issues

I’ve been having oodles of deployment issues with Windows Azure lately ever since upgrading to the 1.3 SDK.  It seems on one machine (which is 32-bit) when I do a build and deploy it appears to word.  On my 64-bit machine with a COMPLETELY clean load of Win 7 and VS 2010 + the Windows Azure SDK 1.3 it never deploys.  Just keeps trying and eventually gives up after about 30-45 minutes.  Very painful.

So far I’ve had some twitter conversations and Eugenio Pace has helped a lot in trying to figure out what the problem is.  At CloudCamp however I start an empty ASP.NET MVC 2 app and deployed it, as things go it worked flawlessly.  I guess Eugenio scared it into operating properly!  🙂

Also Rinat Abdullin has run into some issues with the 1.3 drop also.  Rinat’s entry is titled “Don’t Upgrade to Windows Azure SDK 1.3 Yet“, so you might get the vibe you may not want to upgrade yet.

I also got this tweet from Eugenio on a troubleshooting page on the MSDN site.  It may help if you’re slugging through some issues.

Eugenio Pace @adronbh Latest list of deployment issues on Win #Azurehttp://bit.ly/hTpEeN