DevMavens Feed

RavenDB workshop in NDC, Oslo 4-5th June

Oren Eini — Sun, 05 Feb 2012 15:00:00 GMT

The RavenDB workshop is coming to Oslo, Norway in June!

Join us to an intensive RavenDB hands-on workshop just before the great NDC conference starts.

During the first day of this workshop we will get to know RavenDB and its core concepts, get comfortable with its API, learn how to build and customize indexes, and how to correctly model data for use in a document database.

After getting familiar with all the basics in the first day, during the second day we will build on that knowledge to properly grok Map⁄Reduce, Multi–maps and other advanced usages of indexes, learn how to extend RavenDB and the various options of scaling out.

More details on the workshop and the conference can be found here.

Limit your abstractions: Application Events–the wrong way

Oren Eini — Fri, 03 Feb 2012 12:45:00 GMT

In my previous post, I have taken a few interfaces from a DDD sample application and called the application procedural and hard to maintain. In this post, I want to show you exactly why.

We will start with examining this interface, and how it is used:

public class CargoInspectionServiceImpl : ICargoInspectionService 
{
  // code redacted for simplicity

 public override void InspectCargo(TrackingId trackingId)
 {
    Validate.NotNull(trackingId, "Tracking ID is required");

    Cargo cargo = cargoRepository.Find(trackingId);
    if (cargo == null)
    {
      logger.Warn("Can't inspect non-existing cargo " + trackingId);
      return;
    }

    HandlingHistory handlingHistory = handlingEventRepository.LookupHandlingHistoryOfCargo(trackingId);

    cargo.DeriveDeliveryProgress(handlingHistory);

    if (cargo.Delivery.Misdirected)
    {
      applicationEvents.CargoWasMisdirected(cargo);
    }

    if (cargo.Delivery.UnloadedAtDestination)
    {
      applicationEvents.CargoHasArrived(cargo);
    }

    cargoRepository.Store(cargo);
 }
}

Can you see what I find painful in this code?

Listen to Your Community, But Don't Let Them Tell You What to Do

Jeff Atwood — Fri, 03 Feb 2012 07:18:54 GMT

You know how interviewers love asking about your greatest weakness, or the biggest mistake you've ever made? These questions may sound formulaic, maybe even borderline cliche, but be careful when you answer: they are more important than they seem.

A Handy Script For Compiling CoffeeScript On The Fly

Rob Conery — Fri, 03 Feb 2012 07:04:18 GMT

Rails 3.1 and beyond has the asset pipeline. Node has connect-assets, and there are plenty of "Just In Time" CoffeeScript compilers out there for other platforms as well. I like using a File Watcher - and here's my code.

Microsoft Doesn’t Read Their Own Terms of Service Apparently

Rob Conery — Fri, 03 Feb 2012 00:57:04 GMT

Every time Microsoft Marketing tries to make something "viral" it comes off as what my old baseball coach used to call a "Monkey F***ing a Football". It's just the same with their latest "Gmail Man" BS.

Limit your abstractions: Analyzing a DDD application

Oren Eini — Thu, 02 Feb 2012 12:43:00 GMT

Abstractions have a cost. You should limit them. That seems like an obvious statement, but in a recent discussion I had, I realized that I didn’t articulate things in quite the proper way before.

Let me see if I can explain better now. One of the problems in typical applications is that we don’t really think before we introduce abstractions. For the purpose of this discussion, an abstraction in an interface. Let us take a look at a sample DDD application.

Nitpicker corner: No, I am not saying avoid using interfaces.

I took all the interesting interfaces out of the application, you can see them here:

Take a look at those interfaces. They bother me. They bother me because each of them represent an abstraction that is specific for a particular problem. In other words, it represent an non-abstracted abstraction, if that make any sense.

As I said, this is taken a DDD sample application. It isn’t a big one (and no, I didn’t review the actual code to see if it is a good one), but the interfaces that it has reveal a common problem, namely, interface explosion, or over abstraction. I removed any infrastructure / persistence stuff that was in the app, so you are looking just at the business interfaces, mind.

The problem is that the way this application is structured, it is highly procedural and had to maintain.

Huh?! I can hear you say, procedural? This is a DDD app, just look at the names, we have services and facades and events and… those are all good things. This design is pretty much text book. How can you say that this design is hard to maintain?

I’ll answer this question (and propose answers) in this series of posts. In the meantime, feel free to look at the code (it is Java, in its origin, and I simply modified it to C# for easier working) and make your own conclusions.

Laptop Rebuild - Essential Apps

Steve Smith — Thu, 02 Feb 2012 07:27:50 GMT

When we last saw our hero, he had fallen victim to an evil plot to disable his computer’s ability to boot up. After great efforts at recovery, eventually he was forced to concede defeat to Vista and reinstall everything from scratch. Let’s return now to see what’s in store in the next chapter of our story, already in progress…

So, day 2 after my issue with Vista and I’m now at least able to use my laptop again for real work. However, it still is missing dozens of little things that I find useful, so I thought I’d catalog those here in the spirit of Scott and Jesse’s posts on useful tools and utilities. In my case, this is a running list of things I’m installing, in order, along with some commentary. Feel free to comment on anything you think I’ve left out.

Day 1 Basics

Windows Vista Ultimate SP1 – Followed by about 40 immediate updates.
Visual Studio Team Suite 2008 SP1
Microsoft Office 2007 Ultimate SP1 – Followed by a bunch of updates, and switching from Windows Update to Microsoft Update so that Office automatically gets updated.
FireFox 3
- FireBug
- YSlow

Basic Utilities

Terminals – For all remote connection needs.
Visio Professional 2007 – Often handy, and it’s on the same MSDN disc as Office 2007.
Del.icio.us Bookmarks FireFox Addin – Makes Del.icio.us easy to use.

The following tools just stay in my C:\Util folder and get restored from my backup.

DebugView
Fiddler
ProcessMonitor
Reflector
SpaceMonger
LINQPad – xcopyable LINQ and SQL and Code Snippet Editor/Manager. Awesome!

Social Software (IM and Twitter)

Pidgin – supports multiple IM clients and has some cool features like detecting when someone is writing an IM to you before they finish typing it.
TweetDeck – Current favorite Twitter app. Follow me at @ardalis.

More Apps

Foldershare – Awesome for sharing files between computers.
Adobe Reader (or Foxit Reader) – for PDFs. Foxit installs and opens documents MUCH faster but occasionally has compatibility issues with Adobe.
ClearContext – Makes filing things a breeze in Outlook.
Flickr Uploadr – Makes uploading photos a breeze w/Flickr.
Virtual CloneDrive – Trying this instead of Daemon Tools for ISO mounting. So far I like it.
SQL Server 2008 – Had 2005 before, but figure now’s as good a time as any to upgrade. We’ll see if I still need SQLPrompt with it.

I still have a lot more to go but this is where I am with reinstalling by day 3. I still need an FTP client (FileZilla) and a bunch of other apps. Debating whether to install Plaxo again. Outlook is actually quite fast now that I just had it start with a fresh PST file, and I’m hoping to keep it that way since previously it was the slowest thing on my machine. We’ll see.

Stories Too Big - Vertical Slices

Steve Smith — Thu, 02 Feb 2012 07:27:03 GMT

I have a client who lists as one of the key challenges with implementing agile practices with their teams as managing to define user stories that are valuable but not too big. This is actually a very common challenge, and one that we run into frequently ourselves at Lake Quincy Media and with other clients of NimblePros.

Naturally there are many books available on the subjects of extreme programming, agile software development, user stories, etc. and these are certainly worth reading. Additionally, an agile boot camp like HeadSpring’s can be an excellent way to fully immerse yourself in how things should be done, without the daily distractions of regular work. My first word of advice is that you read what the experts suggest, and consider attending a class from a well-respected trainer if you can do so.

That said, here is some simple, practical advice I’ve collected (from others) on the subject of writing useful stories. First, there’s an acronym that you can use as a test to measure how effective a particular user story is. This is taken from Bill Wake’s eXtreme Programming Explored book. He suggests that you INVEST in good user stories.

Good User Stories should be:

Independent
Negotiable
Valuable
Estimatable (or Estimable)
Small (more on small user stories)
Testable

I would further suggest that these attributes are most important only when the time comes to plan for the story in an iteration. That is, once it comes time to estimate the story and prioritize it as part of an iteration, it needs to exhibit the INVEST qualities. Prior to that point, it’s perfectly acceptable as a placeholder even if it’s big and vague – it can be broken down further when it’s closer to actually being done. This exemplifies the lean principle of putting off decisions until the last responsible moment. If you’re not going to get to the story next week, there’s no sense wasting time trying to estimate it or otherwise make it perfect. Things will change before you start work on it, which will make at least some of your work waste.

Large, vague user stories are known as Epics. It’s fine (even efficient) to have Epic stories in the backlog – it stops being fine once you begin an iteration. That’s when the rubber meets the road and the actual stories need to be extracted from the larger epic.

How Do You Break Up an Epic into Stories?

There are a lot of different ways one could attack this problem – and certainly more than one “right” way. If we take the “epic / story” metaphor too far, we could say that every story arc has an introduction, a climax, and a prologue and that in between there are many chapters and character development, etc. However, this viewpoint naturally imposes a serial constraint on the stories we develop, and would tend to lead to Story 1 which is required for Story 2 which is required for Story 3. This violates the first attribute in our INVEST acronym, which is that the stories should be Independent.

Bad Example

A real world example of this serial approach that delivers nothing until everything is in place would be to create stories based on logical tiers in the software. For instance, if you have a data-driven application consisting of UI, business tier, data access layer, and database (quite common), and for the sake of argument you have a hard dependency on each layer from the one above it (bad design, but quite common), then you might opt to write stories like this:

Story 1: Create the new DB Table
Story 2: Create the stored procedures
Story 3: Create the DAL to access the sprocs
Story 4: Create the business layer code that references the DAL
Story 5: Write the UI screen

You can think of each of these stories as addressing a horizontal layer in the application architecture. The problem with this is that it’s very difficult to start Stories 2-4 without the previous story being done. About the only parallelization you can easily achieve here would be the UI, and with strong coupling it would also be very difficult to test things along the way.

An Alternate Approach – Vertical Slices

An alternate approach is to break down the epic into stories that very small yet still valuable bits of vertical functionality. For instance, let’s say the initial story is for a user registration page that collects a lot of different data. There’s name data. There’s room for multiple addresses. There’s email and phone info. There’s some validation logic. Using the horizontal approach, someone might have generated the Registration Page user interface, and from there a data model, tables, sprocs, etc. If at any point someone got stuck, nothing would be ready to deliver and so none of the stories would be providing value until all of them were produced. Using vertical slices, this might break down like so:

Story 1: User can register and provide username and password.
Story 2: User can provide name data.
Story 3: User can provide an address.
Story 4: User can manage multiple addresses.
Story 5: User can add additional contact fields (phone, email, etc).

All of the stories most likely still depend on the first one in this case, and you’ll rarely be able to completely eliminate all dependencies between stories in an epic. But now it would be possible to develop all 5 stories independently. They might even be written using some kind of control (web, WPF, AJAX, doesn’t matter what UI technology) such that they would be simple to stitch together on a single UI page or kept separated to form some kind Registration Wizard multi-step process. And if the iteration ends and only Stories 1 and 2 are done? You ship it (or at least demo it to the customer) and get feedback earlier than you otherwise would have, which helps ensure that what you’re driving toward really is the correct solution.

Summary

As I mentioned, there are many ways to split epics into individual stories. The details of your application and other variables will influence what technique is best for the given situation. However, if you remember the key attributes of good user stories and focus on being able to deliver something, however small, of value to the customer as quickly as possible, you’ll very likely end up with stories that are about the right size.

XBox 360 - Home Media Center

Steve Smith — Thu, 02 Feb 2012 07:26:17 GMT

Recently I picked up an HP MediaSmart EX470 Windows Home Server to help consolidate my files at home and to provide a simple backup solution. It’s been great and it’s an extremely economical way to get backups. You can hook it up with Amazon S3 using JungleDisk and get simple offsite backup of the files (but not the backups) easily and cheaply as well, and JungleDisk is just one of many plugins available. I recommend the 500GB version for the price, as you can pick up a 1.5TB hard drive to plug into one of the extra bays for under $150.

One of the many plugins for the WHS is a media streaming one that makes it very easy to use the WHS from your XBox 360. With this, it becomes trivial to use the XBox to browse pictures, watch slideshows, watch video clips, and play music. Sometimes the lag is pretty bad when the XBox is trying to load a list of items, but this is likely just due to my wireless network and the significant distance between my XBox and my router and WHS.

Suggestion 1: Support Streaming Video

As much as I love this, there is certainly room for improvement around the XBox’s media capabilities. First of all, as I mentioned in my previous post, you can download HD content for the XBox from the video marketplace, but the files are (as you would expect) quite large, and unfortunately you can’t start watching the movie until it’s been downloaded (or at least, I wasn’t able to start playing it after it had downloaded 20% over the course of half an hour the other day – I went to bed before it reached 100%). It would be great if the XBox video marketplace supported streaming downloads, as one of my commenters on another post reports the AppleTV does.

Suggestion 2: Consolidate XBox 360, WMP, Zune into Unified Media Story

I’d also like to improve the music playing experience. Currently, there is no way to save a playlist using the XBox interface unless the songs are stored on the XBox. It does support playlists on the media server it’s connecting to, but not Zune playlists. So if you’re a Zune user, you have to duplicate your playlists using Windows Media Player so that the XBox can use them, and you have to do all of this from your computer, not your XBox because the XBox can’t store playlists that include songs that aren’t on the XBox. It’s very uncoordinated in its current state, and not the kind of seamless application sharing that Microsoft is well-known for in other areas, such as Office. I’d really like to see some consolidation between Zune, Windows Media Player, and the XBox so that it’s much easier for these technologies to work together. Microsoft needs one ring to rule them all (and not the RROD).

Suggestion 3: Allow Upgrades to the XBox at Market Value

I can get a 1.5 TB hard drive for under $150. I can get a 2GB flash memory drive for $1.85!

Market Hard Drive Cost: $0.10 per GB
Market Flash Drive Cost: $0.92 per GB

Now, how much is for an XBox Hard Drive? Retail for the 120GB unit is $150, NewEgg has it right now for $135. How about a 2GB memory unit? Oh, wait, they don’t have those. 1GB? Nope. But you can get a state-of-the-art 512MB unit for just $40. My *phone* has more memory on its MicroSD card (300% more), and the MicroSD card is about 1/20th the size of the XBox memory card.

XBox Hard Drive Cost: $1.13 per GB (more than 10x market price)
XBox Flash Drive Cost: $80 per GB (more than 80x market price)

Apparently you can upgrade your hard drive yourself without being limited to a mere 120GB overpriced unit, as this PCWorld article shows. I’m not aware of a similar way to create a cheaper memory unit. Oh, and it’s also annoying that the XBox supports up to 4 players but only 2 memory units. What if all 4 people have XBox Live Accounts they want to use, with the profiles on their memory units?

Either Microsoft should put out supported upgrades for the hard drives and memory units that are at least in the same ballpark as market values (even 2x as expensive would be fine w/me, honestly, but 10x and 80x is a bit extreme), or, better yet, they should allow the use of standard electronics like USB flash drives and USB hard drives. I understand part of the reluctance to do this is to make hacking and cheating more difficult, so I would settle for the first option (and I’m sure Microsoft’s sales of these peripherals would be quite good, too).

Learning To Code with the Azure SDK - Show Me The Code

Steve Smith — Thu, 02 Feb 2012 07:25:15 GMT

I’ve been working with Azure off and on since last summer, and like any new API or platform, there are hurdles involved with the learning curve. This is especially true for pre-release software that is rapidly changing and of course has neither official documentation nor much in the way of info on blogs or developer community sites like ASPAlliance.com. One of the ways I like to learn about projects these days is through testing. Ideally, the project will already have a suite of unit tests that I can run to confirm that it actually works at least as well as its creators expect it to, and then I can look at individual tests to discover how the creators of the API expect others to use it. Like many other developers, I usually don’t bother to read the official documentation (I’ve come to expect it will be lacking), preferring instead a “Show Me The Code (SMTC)” approach.

Show Me The Code

The big benefit of SMTC is that you don’t have to worry about whether or not the documentation was properly updated between the previous CTP release and the preview alpha CTP pre-release daily build you’re using now. You run the code, and if it does what it’s supposed to do, then you know you have a system that is more-or-less working and you can go from there. Most SDKs include samples to help you get started, with full source code, as obviously this is one of the best ways developers can quickly get up to speed with a new set of tools.

Azure’s SDK as of the January CTP ships with about 9 folders worth of samples, including a couple of HelloWorld projects, a PersonalWebSite, a CloudDrive demo that lets you map a drive to cloud storage, and more. If you want to take advantage of Azure Storage on your local machine, then you’ll most likely run the sample storage client API sample so you can get up to speed with it. It’s comprised of a console application that basically runs through a bunch of API exercises that demonstrate how to perform operations against Azure’s Blog, Queue, and Table storage options. If you run it, you end up with something like this:

Coupled with the actual source code, this is a great example of how to use Azure Storage. However, it’s not the best output and unless you watch it as it runs, you don’t really know what all this program actually did. Or if some pieces maybe failed. Or how to run just the part on deleting table entries. This is a good example of SMTC, but it falls short of being as expressive and approachable as it could be.

Unit Tests

I’m probably preaching the choir here when it comes to unit tests, but there are still about a bazillion developers out there who simply don’t get them. They don’t write them, they don’t run them, and they certainly don’t see the value in them. This is just one instance where I think unit tests are valuable, and that is as documentation. As a developer trying to learn an API or going through an SDK, I would much rather have an exhaustive suite of unit (and integration) tests than a .chm file or PDF with standard documentation (though of course having both would be ideal). With the unit tests, I have documentation I can execute. And I can do it for the whole system or just a tiny piece that interests me at the moment. I don’t have to try and set up a huge solution that came as a sample with the SDK – I can run just one test. Or I can look at just one test and, if it was written well, I can come quickly grasp how the System Under Test (SUT) is meant to be used.

Going back to the Azure SDK example with the StorageClientAPISample project, the Program.cs file in that project is 972 lines long. Here’s a small example of some of the code, showing how to create a Blob of text:

// write some text blobs
NameValueCollection nv1 = new NameValueCollection();
nv1["m1"] = "v1";
nv1["m2"] = "v2";

StringBlob hello1 = new StringBlob("hello.txt", "Hello World");
hello1.Blob.Metadata = nv1;
Console.WriteLine("Creating blob hello.txt");
PutTextBlob(container, hello1);

BlobProperties prop = container.GetBlobProperties("hello.txt");
Console.WriteLine("hello.txt content length = " + prop.ContentLength);

I’m sure the unit testers among you will agree that this would be a good candidate for a unit test (or in this case, since it really is talking to the storage service, an integration test). It’s possible that some future version of the Azure SDK (it’s not even Beta yet, I realize) will include a suite of unit tests, but Microsoft faces some challenges here with deployment. MSTest still is not xcopy deployable, and to date they’ve shown a fair amount of reluctance to use alternative open source tools like NUnit (though the ASP.NET MVC team has been more open in this regard than most other teams). Since I’m not on the Azure team but I do think such tests would be a valuable addition, I’ve suggested this to the team but I’ve also gone ahead and started an Azure Contrib project on CodePlex that will include such tests among its samples, as well as other Azure add-ons that don’t ship with the official SDK. Naturally I’ll be looking for additional project members as well as ideas for things to include in the project, though for now I don’t even have these tests set up so I don’t want to get too far ahead of myself.

Summary

Show Me The Code (SMTC) is a great way to learn. Tests are a great way to break up a lot of code into bite-sized pieces that are both easy to learn and easy to evaluate whether or not they’re working correctly. Microsoft should consider shipping tests instead of monolithic console applications with the SDK samples, for Azure as well as other frameworks they are developing, and they should consider making MSTest distributable or accepting the fact that tools like NUnit can serve this space well. Azure Contrib will soon provide some additional components of interest to Azure developers which are not part of the official SDK.