DevMavens Feed

Regional Differences

Steve Smith — Tue, 21 May 2013 19:16:28 GMT

Last week I ran a poll (that maxed out at 400 responses on twtpoll) asking how developers recommend using regions in C# (or not). You can see the results here:

About 15% of the respondents chose Other and/or chose to leave a comment. The comments are useful because they often highlight answer categories that I overlooked when I set up the poll. In this case, there were a lot of comments, I think because there are a lot of different opinions about regions in general, some of them rather heated.

Clearly the largest number of respondents simply never use Regions. A number of comments went on to say things like “Regions aren’t evil I just don’t know a situation where they’re useful.” The most popular use of regions from the ones I provided was for wrapping interface implementations, which isn’t too surprising since these regions are often automatically added when an interface is implemented automatically. Similarly, a large number of comments referenced “generated code” as a use case for regions, which I probably should have included in the original listing.

I added a couple of the options above, F and G, as items that I would consider obvious wrong answers on a standardized test. Surprisingly, both got a reasonable number of votes, with 13% of respondents recommending the use of regions with long functions. Now, some of these votes probably belong to commenters like this one: “Hiding long methods as I refactor it”. If you’re temporarily collapsing sections of a long function during your refactoring exercise, that seems quite reasonable to me. But if you’re putting regions into your function as a recommended, long-term approach, then I probably don’t want to work on that codebase with you. I would much rather functions be small enough that (without regions) they fit on one screen, and if they get too big for that, fix the problem by extracting out well-named and well-composed methods, as opposed to hiding the problem behind regions. And regions with regions. Wow.

My personal opinion is that regions had some great and common use cases in the early versions of .NET and C#. For instance, the first version of ASP.NET used regions appropriately to hide auto-generated wire-up code in the codebehind. A large number of comments continue to suggest that regions be used for generated code. Today, two things make this less of an issue. The first is partial classes. Generated code today is almost always in its own class, or could be, and as such rather than wrapping it with a region, I find it is better to simply use a partial class to keep the generated code in a separate file from the custom code. The second feature is more of an IDE feature. A lot of users find regions helpful as a code navigation tool, or as a way to limit what they are looking at on the screen. VS2010 provides great support for expanding and collapsing methods and other areas of code that you don’t wish to see, and tools like ReSharper make it trivial to navigate to a type or member anywhere in your solution (ctrl-T, then type a substring of the type, then enter and you’re there. For a member, the default keymap is the not-quite-as-easy-to-type ctrl-F12). A number of comments also suggested using regions for using statements. These don’t tend to bother me because I can quickly scroll down and not have to see them on my screen, and my using statements are usually quite small since ReSharper will clean up the ones I don’t need and will auto-add any that I do need, and my classes are small so they aren’t generally using more than a handful of other namespaces. And of course, VS2010 supports collapsing using statements as well, like so:

Why Consider Them Harmful, Smelly, or even “Evil”?

Evil is obviously a strong word, and of course since regions have no effect on compiled code, they can’t directly have any impact on the software you’re creating. However, I do think it is at least fair to say that regions often represent “code smells.” That is, areas of your code that may be worth investigating to see if there is rotten code that needs to be cleaned up. Why do some, including me, tend to feel this way? Because regions are often a symptom of underlying problems with the code itself. Regions do two things:

Provide a single-line comment
Wrap some number of lines of code and allow it to be hidden on demand

When might you need these features?

The intent of the code is unclear
The code is too long to quickly understand at a glance
Both of the above
You prefer an “outline view” of classes so you can drill into each category of member when you dig into a class

In the case of items 1 through 3, regions are covering up problems.

If the intent of a block of code is unclear, fix the code. Extract a method. Rename the variables. Refactor. Simplify. Don’t add a comment or a region (glorified comment) to try and cover up the problem. If you spill something in the kitchen, should you clean up the floor, or just throw a rug over it or put out an orange cone to warn people about the spill? Which option is going to keep the kitchen optimally usable? The same goes for your code. Keep it clean. Regions are rugs under which to sweep smelly code.

If the code is simply too long, fix it. Eliminate duplication. Refactor. Abstract details into larger-grained operations. If you’re spending 10 lines of plumbing code talking to a database or service, move that into its own method or class that is only responsible for that work. If you’re spending lots of lines of code copying values from one object to another, use a tool like Automapper to map the values with one line of code. Keep your code concise and at the appropriate level of abstraction for the method you’re in, and don’t mix plumbing code with application code if you can help it.

In the case of 4, regions are being used to do something that your IDE should be able to easily do for you. I won’t say regions are being mis-used in this context, but I do think that if a large number of people use them for this purpose, then Visual Studio or one of the add-in providers should provide this kind of view such that you don’t have to implement yourself in the source code with region statements. I definitely think it’s valid that some developers prefer this view of their classes, I just don’t think they should have to clutter up everybody’s codebase in order to do so. Let the IDE do that work. And of course, if the classes and methods are small, the need for a high-level view is significantly lessened. If you prefer to have all of your public properties in one section, public methods in another, private members in another, etc. then wouldn’t you prefer to have an IDE that would simply let you specify the organization you prefer, and automatically have it in every file you open?

Summary

Almost half of the developers polled would never recommend using regions. Yet nearly 15% of those polled would recommend using them to organize long methods. A great many use them to organize code into categories (public, private, methods, properties), though this could probably be better done automatically by a tool. When .NET was young, regions provided a useful way to hide generated code within classes or to provide expand/collapse capabilities within the IDE. Today, partial classes and improvements to the IDE and various plug-ins make these uses unnecessary for many developers. Clearly, there are still some opportunities for IDE/plug-in vendors to build in code organization support that will further erode the legitimate use cases for regions. If you’re not using them for such organizational purposes today, think about the underlying reason you’re using a region the next time you add one, and consider if you wouldn’t be better off correcting the underlying code deficiency rather than hiding it under the region rug.

Read more: Regional Differences | Subscribe

RavenDB, Victory

Oren Eini — Tue, 21 May 2013 13:00:00 GMT

Jeremy Miller’s post about Would I use RavenDB again has been making the round. It is a good post, and I was asked to comment on it by multiple people.

I wanted to comment very briefly on some of the issues that were brought up:

Memory consumption – this is probably mostly related to the long term session usage, which we expect to be much more short lived.

The 2nd level cache is mostly there to speed things up when you have relatively small documents. If you have very large documents, or routinely have requests that return many documents, that can be a memory hog. That said, the 2nd level cache is limited to 2,048 items by default, so that shouldn’t really be a big issue. And you can change that (or even turn it off) with ease.

Don’t abstract RavenDB too much – yeah, that is pretty much has been our recommendation for a while.

I don’t see this as a problem. You have just the same issue if you are using any OR/M against an RDBMS.

Bulk Insert – the issue has already been fixed. In fact, IIRC, it was fixed within a day or two of the issue being brought up.
Eventual Consistency – Yes, you need to decide how to handle that. As Jeremy said, there are several ways of handling that, from using natural keys with no query latency associated with them to calling WaitForNonStaleResultsAsOfNow();

Truthfully, the thing that really caught my eye wasn’t Jeremy’s post, but one of the comments:

Thanks you, we spend a lot of time on that!

Moving a Site to Windows Azure in 5 Easy Steps

Steve Smith — Tue, 21 May 2013 06:42:53 GMT

One of my sites is currently having issues where it’s currently hosted. They’re resolved by restarting the application, but that’s gotten tedious and I simply don’t have time to invest in troubleshooting this particular site. And, oh hey, those MSDN Windows Azure benefits keep looking shiny like I should play with them. So, I figure I’ll try moving the site to Azure and see if miraculously that fixes the problem.

Step One: Activate Azure Benefit

Sign into your account with your MSDN Subscription, and click the Activate Windows Azure link:

Fill out the form, which will require a credit card and a mobile device (that can receive text messages) to complete.

Step Two: Connect to Azure Portal

Follow one of the many links to https://manage.windowsazure.com (or just click on mine). There’s a ton of stuff you can configure and create from here. In my case, since I may want to host more than one small website, and I want to be able to use A records (I’m not a fan of www in front of domains for web sites, which is pretty much required for CNAME DNS approaches), I’m choosing to create a small VM (more on Azure DNS). You can do this from the NEW command in the bottom left, and if you use the gallery option you can select the OS you want – in my case I went with Windows Server 2008 R2 SP1.

Once you complete this wizard, it takes a few (really surprisingly few – I remember how long it took to deploy apps to the original version of Azure, and this is way faster) minutes to deploy and start the VM. In a short while, you should see:

So now what? Click on your VM to see what you can do with it:

The next thing I want to do is remote into the machine and start setting things up.

Step Three: Connect to Virtual Machine

My first thought was to just try to connect to the public foo.cloudapp.net name my VM was given, but of course that didn’t work. Looking at your VM, navigate to the ENDPOINTS tab to see the public port configured for RemoteDesktop access. You’ll need to specify that in your Remote Desktop Connection in order to connect (you do this by adding it to the end of your computer’s name following a : (colon)):

With that, you should be able to remote into the machine. In my case, since I want this VM to act as a web server, the first thing I need to do is Add Roles and select the Web Server (IIS) role. After that, the web platform installer is your friend. Once IIS is configured and I’ve gotten my web site’s files to the server, the next step is to configure the database.

Step Four: Configure Database

Your MSDN benefits include some database benefits in addition to the VM and web site benefits. Note that the database benefits are fairly limited, so if you have a lot of small databases you may use up this benefit quickly. With the Visual Studio Ultimate with MSDN benefit, you can use five 1GB web databases per month for free. To create a new database, go back to the Azure Management Portal, click on NEW, and choose SQL Database.

Choose a name, and a server (or a new one will be created if this is your first SQL Database). Then, if this is a new server, specify the username and password that will be used to connect to it. Once set up, which takes a few seconds, you should see the database:

So now, how do you connect to this database and move your existing data to it, is the next question…

Step Five: Connect to a SQL Database in Windows Azure

Click on the database name just like with the VM to see initial options:

Now that you see the server info at the bottom, naturally the next step is to try and hit it with SQL Management Studio, but you’ll get this:

Security bites us again! Click on the DASHBOARD link to change which IP addresses are allowed to connect to the server:

It will help you out by suggesting your current client IP:

Be sure to click the SAVE link at the bottom after you add it.

Voila! Now you can connect from Management Studio, which will let you run whatever queries you need in order to get your data into the database.

One last note – to actually connect to your web site on your VM, you’ll need to set up an endpoint for port 80 via the VM’s ENDPOINTS menu.

Once that’s in place, you should be able to hit your site in a browser:

AngularJS Abstractions: Filters

Scott Allen — Mon, 20 May 2013 13:12:00 GMT

Filters in AngularJS can form a pipeline to format and adapt model data inside a view. The built-in filters for AngularJS are date (format a date), filter (select a subset of an array), currency (format a number using a currency symbol for the current locale), and many more. I say filters can form a pipeline because you place them inside expressions in a view using a pipe symbol. The canonical example of a filter is the filter filter, which in the following markup filters a list of items according to what the user types in the search input (try it live here).

<input type="search" placeholder="Filter" ng-model="searchTerm"/>    

<ul ng-repeat="item in items | filter:searchTerm | limitTo:maxItems">
    <li>{{item}}</li>
</ul>

Notice the output of filter is also piped to a limitTo filter, which restricts the number of items in the list to maxItems (where maxItems would need to be defined in the model).

Custom Filters

Custom filters only require a filter function to be registered with Angular. The filter function returns a function that will perform the actual work. For example, a plurify filter to add the letter s to the output:

(function() {

    var plurify = function() {
        return function(value) {
            return value + "s";
        };
    };

    angular.module("patientApp.Filters")
           .filter("plurify", plurify);
}());

Now plurify is available to use in a view:

<ul ng-repeat="item in items | filter:searchTerm | limitTo:maxItems">
    <li>{{item | plurify }}</li>
</ul>

A filter can also take one or more optional parameters.

var plurify = function() {
    return function(value, strength) {          
       strength = strength || 1;
       return value + Array(strength + 1).join("s");
    };
};

Now we can add 5 s characters to the output:

<li>{{item | plurify:5 }}</li>

The beauty of filters is how you can package up small pieces of testable code to make the job of the model and view a bit easier, and the syntax to use a filter is easy and intuitive.

Fixing up the build process

Oren Eini — Mon, 20 May 2013 13:00:00 GMT

There is a big problem in the RavenDB build process. To be rather more exact, there is a… long problem in the RavenDB build process.

As you can imagine, when the build process run for that long, it doesn’t' get run too often. We already had several runs of “let us optimize the build”. But… the actual reason for the tests taking this long is a bit sneaky.

To save you from having to do the math, this means an average of 1.15 seconds per test.

In most tests, we actually have to create a RavenDB instance. That doesn’t take too long, but it does take some time. And we have a lot of tests that uses the network, because we need to test how RavenDB works on the wire.

From that perspective, it means that we don’t seem to have any real options. Even if we cut the average cost of running the tests by half, it would still be a 30 minutes build process.

Instead, we are going to create a layered approach. We are going to freeze all of our existing tests, move them to an Integration Tests project. We will create a small suite of tests that cover just core stuff with RavenDB, and use that. Over time, we will be adding tests to the new test project. When that becomes too slow, we will have another migration.

What about the integration tests? Well, those will be run solely by our build server, and we will setup things so we can automatically test when running from our own forks, not the main code line.

Using system.js in MongoDB (From C#)

Scott Allen — Fri, 17 May 2013 13:12:00 GMT

The official MongoDB docs recommend that you avoid storing scripts on the server, but there are scenarios where having reusable functions available on the server can be useful. Inside a MapReduce operation, for example.

We’ll start with some JavaScript code encapsulating statistical calculations, and place the code in a file named mathStats.js:

function() {

    var stdDev = function(numbers) {
        // ...  
    };

    var mode = function(numbers) {
        // ...
    };

    var mean = function(numbers) {
        // ...
    };

    return {
        stdDev: stdDev,
        mode: mode,
        mean: mean
    };

};

Note the script must be a function. To use the methods inside, the function must live in the system.js collection. The following C# code can do this:

var sysJs = db.GetCollection("system.js");
var code = File.ReadAllText("pathTo\\mathStats.js");
var codeDocument = new BsonDocument("value", new BsonJavaScript(code));
codeDocument.Add(new BsonElement("_id", "mathStats"));
sysJs.Insert(codeDocument);

It is important to insert the script as the value attribute of a document, and set the _id of the document to a friendly string name and not an ObjectID value. Failing to follow those two steps can lead to errors like “exception: name has to be a string” and “value has to be set” when you execute commands.

Once the script is loaded, you can use the function from any map, reduce, or finalize function by invoking the function with its friendly _id name. For example:

function(key, value){                      
    var stats = mathStats();
    value.stdDev = stats.stdDev(value.items);               
    return value;
}

RavenDB Webinar: Aggregation just jump a grade or two…

Oren Eini — Fri, 17 May 2013 13:00:00 GMT

In tomorrow’s Webinar, we will discuss handle dynamic aggregation using RavenDB. A new feature in 2.5, this is meant to give you more options for reporting queries, including complex aggregation, dynamic selection, etc.

You can register here: https://www2.gotomeeting.com/register/789291530

Move over TortoiseGit, welcome SourceTree

Jeffrey Palermo — Fri, 17 May 2013 07:46:45 GMT

Since around 2005, I, and teams I’ve led, have been using the Tortoise flavor of source control clients. TortoiseSVN, TortoiseHg, and TortoiseGit. Each came with the command-line client as well for specific use cases, but most of the time, we used the Windows explorer shell integration. To this day I’m using TortoiseGit with GitHub, BitBucket, and Team Foundation Service+Git. It works well with all of them. I’m not sure why it took so long for me to figure out that Atlassian has a Git and Hg client called SourceTree. Here is what it looks like, and it seem to work seamlessly with my existing repositories and working copies. In addition, it integrates diffs very well so that it’s obvious right off the bat what has changed in the file.

One feature that SourceTree does not provide is explorer shell integration so that I can right-click on the repository working copy and perform functions directly from there. It will remain to be seen how often I reach for TortoiseGit with the new slick interface that SourceTree has. I’m not sure, but I don’t think it will take long to see.

Videos: Beautiful Builds, and a Second Look at Unit Testing

Roy Osherove — Fri, 17 May 2013 03:16:59 GMT

While at the msswit conference in the Ukraine, I got to speak on two subjects with the following videos:

Beautiful Builds: Maintainable, Coherent Build Processes
A Second Look at Unit Testing: what I learned since the first edtion of Art Of Unit Testing

AngularJS Abstractions: Scope

Scott Allen — Thu, 16 May 2013 13:12:00 GMT

Continuing from the controllers post, the parameter to the controller function is named $scope.

var AboutController = function($scope) {

    // ...    

};

The name $scope is important since it allows the AngularJS dependency injector to know what type of object you are asking for, in this case an object that will contain the view model. Any plain old JavaScript you attach to $scope (properties, functions, objects, arrays) is eligible to use from the expressions inside the view.

In the last post our model was relatively “flat” in the sense that properties and functions were added directly to $scope:

$scope.rabbitCount = 2;

$scope.increase = function() {
    $scope.rabbitCount *= $scope.rabbitCount;
};

This allowed us to use rabbitCount and increase() in the markup that was inside the view scope (the div) of the AboutController:

<div data-ng-controller="AboutController">

    <div>Number of rabbits in the yard: {{rabbitCount}}</div>

    <button ng-click="increase()">More rabbits</button>
    
</div>

You can think of $scope as the execution context for the expressions in the view. Saying ng-click=”increase” results in a call to $scope.increase. The only thing tricky to understand about $scope is that having a controller inside a controller, or a controller inside an application (which you’ll always have), will result in nested $scopes, and a nested $scope will prototypally inherit from it’s parent scope by default. This is why $scope is injected by angularJS – the framework sets up the prototype chain before giving your controller the $scope object to use as a model.

Inheritance means a view has access to it’s own scope as well as any inherited scope. In the following example, the view inside the ChildController markup can use an expression like {{rabbitCount}}, and this expression will read the rabbitCount property of AboutController’s scope ($scope.rabbitCount will follow the prototype chain).

<div data-ng-controller="AboutController">    

    <div>Number of rabbits in the yard: {{rabbitCount}}</div>
    
    <div data-ng-controller="ChildController">
        Number of rabbits in the yard: {{rabbitCount}}
        Number of squirrels in the yard: {{squirrelCount}}
    </div>

</div>

The one place to be careful with the inherited scope is with 2 way data binding. The way JavaScript prototypes work is that writing to the rabbitCount property of the ChildController $scope will add a rabbitCount property to the ChildController $scope and effectively hide the parent property. $scope.rabbitCount no longer needs to follow the prototype chain to find a value. More details and pictures on this scenario in “The Nuances of Scope Prototypal Inheritance”.