Posts

Unlocking the Power of Custom Software: Is It Worth the Investment?

Tue, 08 Aug 2023 17:49:16 Z

Introduction

In a world driven by technological advancements, companies are constantly looking for innovative solutions to gain a competitive edge. Many companies consider custom software, but concerns about cost can make decision-makers hesitate. Like a carefully tailored bespoke suit, custom software comes with a price tag. However, custom software is an investment that can provide a significant return on investment by saving money and generating significant revenue. Let's explore the value of custom software development and why it's a worthwhile investment for many companies.

The Expense of Custom Software Development

Custom software development involves the creation of tailored solutions to meet specific business needs. This level of customization requires time, expertise, and resources, resulting in a higher upfront cost compared to off-the-shelf software solutions. However, it's important to understand that the cost of custom software is relative to the long-term benefits it brings to an organization.

The Value of Custom Software as an Investment

Cost Savings

While the initial cost may seem daunting, custom software can actually save businesses a significant amount of money in the long run. By streamlining processes, automating repetitive tasks, and eliminating the need for multiple software licenses, companies can reduce operating costs and increase efficiency. Custom software is designed to fit seamlessly into existing workflows, eliminating the need for costly workarounds or manual intervention.

Increased Revenue Generation

Custom software has the potential to create new revenue streams and accelerate business growth. By tailoring software to meet unique business needs, companies can enhance their ability to deliver exceptional customer experiences, increase productivity, and seize new market opportunities. The ability to provide personalized services, adapt to changing customer demands, and differentiate from competitors can lead to increased customer satisfaction, loyalty, and ultimately, increased revenue.

Factors Influencing the Cost of Custom Software

Complexity

The complexity of the software solution is a critical factor in determining the total cost. Projects with complex functionality, integration with existing systems, or extensive scalability requirements may require more time and resources to develop, resulting in a higher investment.

Development Team Expertise

The skills and experience of the development team play an important role in estimating costs. Highly skilled professionals with expertise in specific technologies may have higher rates, but their skills can ensure a more efficient and effective development process, reducing overall project costs.

Development Team Location

Consider offshore outsourcing as an alternative to reduce custom software development costs. Check out this article to explore some pros and cons of offshore outsourcing.

Conclusion

While custom software development may involve a higher initial investment, it's important to view it as a strategic business decision. Like a bespoke suit that fits perfectly, custom software is tailored to meet the unique needs of your business. By reducing costs, increasing operational efficiency, and driving revenue growth, custom software becomes a valuable asset that can help your business thrive. Embrace the power of custom software and experience the transformation it can bring to your organization's productivity, competitiveness, and profitability.

Contact Volare Software today for more information about tailoring custom software to your business.

Advantages of hiring a business-driven custom software consultancy

Sun, 28 Apr 2024 19:49:26 Z

In the fast-paced world of tech, everyone talks about coding skills, and rightly so. But what if I told you that to make your custom software truly shine, you need more than just a whiz with code? Let's explore why having a software consultancy that understands your business can make all the difference.

Coding may top everyone's list, but the real magic happens when it is paired with a deep understanding of your business. A software consultancy with hands-on experience in your industry isn't just about making the code work; it's about tailoring it to fit your unique needs. This special understanding ensures that the software isn't just functional; it aligns perfectly with what makes your business tick.

Now, envision possessing a software solution that not only resolves your current challenges but also evolves hand in hand with your business growth. A software consultant with business experience doesn't stop at coding; they architect solutions for enduring efficiency. It's not just about saving money; it's about sparing you time and the headaches of constant fixes. By aligning your software with your business strategy, they create a robust foundation that adapts and grows with you, providing you with peace of mind and saving you from costly disruptions down the line.

Engaging with a software consultancy with business experience brings a refreshing perspective. External consultants offer innovative ideas and solutions that your in-house team might overlook. They act as guides, foreseeing potential roadblocks and steering your software development journey toward success. Their diverse experiences enhance problem-solving, making your team more adaptable and creative, leading to a software product that not only meets but exceeds your expectations.

An experienced business leader in your software development team forms a bridge between the technical details and your big-picture business goals. It's not just about writing code; it's about crafting a software solution that aligns precisely with your vision, goals, and the expectations of your customers and employees. An adept business-savvy developer ensures your team stays on track, preventing any deviation from your goals.

In this world where every line of code propels progress, business experience in custom software consultancy becomes the secret ingredient. Coding remains essential, but understanding your business emerges as the heartbeat of your project. Now, as a customer, you have the opportunity to choose a partner who doesn't just write code but engineers solutions that not only drive your business toward success but also leaves you feeling empowered, relieved, and confident in the transformative impact on your organization. With business-savvy custom software, you receive not only a technological solution but a catalyst for elevated customer praise, organizational efficiency, and an overall sense of peace on your business journey.

Should you go with an offshore team for your custom software development project?

Sun, 02 Apr 2023 18:25:24 Z

Are you trying to decide whether to work with an offshore team for your next software development project?

Offshore teams offer cost savings and the ability to work with a larger team, but there are potential risks to consider. Language barriers, cultural differences, and time zone differences can all hinder the project's success.

We'll explore the advantages and disadvantages of working with an offshore team and how to mitigate the potential risks.

Advantages: Cost Savings and a Larger Team

One of the most significant advantages of working with an offshore team is cost savings. Offshore teams are generally much cheaper than US-based or western Europe-based teams due to lower labor costs in other countries. This cost savings allow companies to invest more resources into other areas of their business, making it an attractive option for those looking to maximize their budget.

Another benefit of offshore teams is the ability to work with a larger team. Offshore teams can provide access to a more extensive pool of talent, allowing companies to take on more significant projects or multiple projects simultaneously. This can be particularly useful for businesses that need to scale their development efforts quickly.

Disadvantages: Languages, Cultures, and Time Zones

One of the primary disadvantages of working with an offshore team is the potential for language, culture, and time zone differences. These factors can make communication difficult, which can lead to delays in delivery and potentially hinder the project's success.This can lead to rework, additional costs, and ultimately delay the project's delivery.

How to Mitigate the Risks

While there are potential risks to working with an offshore team, there are ways to mitigate them.

First, companies should choose a reputable software development partner with a proven track record and good references. Working with an established team can reduce the risk of communication problems and delays.

Establish clear communication protocols and use technology to bridge the distance. Video conferencing, chat software, and project management tools can help keep everyone on the same page.

Finally, companies can ensure the quality of the work by providing clear project requirements, reviewing the code in progress during development, and providing feeback to the team to ensure the software built matches your needs.

Conclusion

At Volare Software, we understand the importance of choosing the right development team for your custom software project. That's why we offer US-based, western Europe-based, and offshore teams to fit your specific business and project needs.

We prioritize communication and transparency to ensure the success of your project, and you will see working software demonstated at the end of every iteration (usually every 1-3 weeks). We ask for your feedback on the in-progress software so we can make adjustments to build exactly the software you need.

So if you're struggling to decide about hiring an offshore team, let Volare Software help guide you to the best decision for your business. Contact us today to learn more.

Mocking calls with Jasmine

Tue, 14 Apr 2020 06:00:00 Z

This post and the examples have been updated to the latest release of Jasmine, which is currently 3.5.

Jasmine is a simple, BDD-style JavaScript testing framework, but to benefit from the full power out of the framework, you need to know how to mock calls the Jasmine way.

Jasmine uses spies to mock asynchronous and synchronous function calls. As with most mocking frameworks, you can set the externally observed behavior of the code you are mocking.

Using Jasmine spies to mock code

Jasmine spies are easy to set up. You set the object and function you want to spy on, and that code won't be executed.

In the code below, we have a MyApp module with a flag property and a setFlag() function exposed. We also have an instance of that module called myApp in the test. To spy on the myApp.setFlag() function, we use:

spyOn(myApp, "setFlag");

It's a little strange that in Jasmine, you have to put the function you want to spy on in quotes, but that's the API.

When you spy on a function like this, the original code is not executed.

// Code under test
var MyApp = function () {
    var testAsync = function () {
        // Do something that takes a long time...
    };
var callSomethingThatUsesAsync = function () {
    // Get a jQuery deferred
    var deferred = $.Deferred();

    // Make an async call and do something when it's completed based on success/failure
    this.testAsync()
    .done(function () {
        // Resolve the deferred
        deferred.resolve(&quot;The async call succeeded&quot;);
    })
    .fail(function () {
        // Reject the deferred
        deferred.reject(&quot;The async call failed&quot;);
    });

    return deferred.promise();
};

return {
    testAsync: testAsync,
    callSomethingThatUsesAsync: callSomethingThatUsesAsync
};

};
// Test helpers
var JasmineHelpers = function () {
var deferredSuccess = function (args) {
    var d = $.Deferred();
    d.resolve(args);
    return d.promise();
};

var deferredFailure = function (args) {
    var d = $.Deferred();
    d.reject(args);
    return d.promise();
};

return {
    deferredSuccess: deferredSuccess,
    deferredFailure: deferredFailure
};

};
// Specs
describe("Testing spies", function () {
var jasmineHelpers = new JasmineHelpers();
it(&quot;Should spy on async calls and use helpers to mock success/failure&quot;, function () {
    // Arrange
    var myApp = new MyApp();
    spyOn(myApp, &quot;testAsync&quot;).and.callFake(function () {
        return jasmineHelpers.deferredSuccess();
    });

    // Act
    myApp.callSomethingThatUsesAsync()
    .always(function (result) {
        // Assert
        expect(result).toEqual(&quot;The async call succeeded&quot;);
    });
});

});

Returning values from Jasmine spies

Most of the time when setting up mocks, you want to set return values so you can test a specific code path. Again, this is easy to do with Jasmine.

Here, I show setting the return value of a function so we can test specific branches in the code and skip over the real getFlag() function, which is hard-coded to return false.

// Code under test
var MyApp = function () {
    var getFlag = function () {
        return false;
    };
var useFlagForSomething = function () {
    if (this.getFlag() === true) {
        return &quot;It was true&quot;;
    } else {
        return &quot;It was false&quot;;
    }
};

return {
    getFlag: getFlag,
    useFlagForSomething: useFlagForSomething
};

};
// Specs
describe("Testing spies", function () {
it(&quot;Should replace the return value of function being spied on&quot;, function () {
    // Arrange
    var myApp = new MyApp();
    spyOn(myApp, &quot;getFlag&quot;).and.returnValue(true);

    // Act
    var result = myApp.useFlagForSomething();

    // Assert
    expect(result).toEqual(&quot;It was true&quot;);
});

});

The key piece is intercepting the getFlag() function with the spy and setting the value the substituted function returns:

spyOn(myApp, "getFlag").and.returnValue(true);

Sometimes, setting a returnValue isn't enough. If you need to replace the function you are mocking, you can use:

spyOn(myApp, "useFlagForSomething").and.callFake(function() {
    return "I'm replacing the real function with this";
});

Using Jasmine spies to verify code was called

You can also call the original code with a spy. This may sound pointless (why set up a mock and then call the real code?) unless you think about interaction testing, where it's important to know that a function was or was not called.

The syntax to call the original code but still spy on the function is:

spyOn(myApp, "getFlag").and.callThrough();

The code below shows how you can verify a spied on function was called. We have a new function called reallyImportantProcess(). We have to test to make sure it's being run under the right conditions, and we know it should run when getFlag() returns false, which is the default value. So we don't need to mock or change getFalse() to take this code branch, but we do need to spyOn reallyImportantProcess() to verify it gets called.

In this spy, we have lots of options. We could skip calling the real code, as we do below, or we could set up specific return values or substitute our own function for that function, or we could call the original code with callThrough(). When you set up Jasmine spies, you can use any spy configuration and still see if it was called later with and toHaveBeenCalled().

// Code under test
var MyApp = function () {
    var getFlag = function () {
        return false;
    };
var reallyImporatantProcess = function () {
    // Do something really important
};

var useFlagForSomething = function () {
    if (this.getFlag() === true) {
        return &quot;It was true&quot;;
    } else {
        this.reallyImporatantProcess();
        return &quot;It was false&quot;;
    }
};

return {
    getFlag: getFlag,
    reallyImporatantProcess: reallyImporatantProcess,
    useFlagForSomething: useFlagForSomething
};

};
// Specs
describe("Testing spies", function () {
it(&quot;Should verify a spy was called&quot;, function () {
    // Arrange
    var myApp = new MyApp();
    spyOn(myApp, &quot;reallyImporatantProcess&quot;);

    // Act
    var result = myApp.useFlagForSomething();

    // Assert
    expect(myApp.reallyImporatantProcess).toHaveBeenCalled();
    expect(result).toEqual(&quot;It was false&quot;);
});

});

You can also test that a spied on function was NOT called with:

expect(myApp.reallyImportantProcess).not.toHaveBeenCalled();

Or you can go further with your interaction testing to assert on the spied on function being called with specific arguments like:

expect(myApp.reallyImportantProcess).toHaveBeenCalledWith(123, "abc");

Testing async calls in Jasmine with jQuery's Deferred and helpers

Async calls are a big part of JavaScript. Most code dealing with async calls these day works through promises or callbacks.

Here, some test helper code can be used to mock promises being returned from an async call. I'm using jQuery's $.Deferred() object, but any promise framework should work the same.

You can mock an async success or failure, pass in anything you want the mocked async call to return, and test how your code handles it:

var JasmineHelpers = function () {
var deferredSuccess = function (args) {
    var d = $.Deferred();
    d.resolve(args);
    return d.promise();
};

var deferredFailure = function (args) {
    var d = $.Deferred();
    d.reject(args);
    return d.promise();
};

return {
    deferredSuccess: deferredSuccess,
    deferredFailure: deferredFailure
};

};

Here is some Jasmine spy code using these async helpers. Again, we use jQuery $.Deferred() object to set up a function that calls out to a pretend async call named testAsync(). It's invoked by callSomethingThatUsesAsync(), which is the function we're testing. We want to mock the testAsync() call (maybe it goes off to the database and takes a while), and we want to assert that when that testAsync() call succeeds, callSomethingThatUsesAsync() goes on to give us a text message saying it succeeded.

Since the function under test is using a promise, we need to wait until the promise has completed before we can start asserting, but we want to assert whether it fails or succeeds, so we'll put our assert code in the always() function. The done(), fail(), and always() functions are promise code - (actually, jQuery $.Deferred code if you want to be technical) they are not specific to Jasmine.

Testing async calls in Jasmine with Jasmine's done() callback

Testing synchronous specs is easy, but asynchronous testing requires some additional work.

For example, the code below fails because Jasmine evaluates the expect() piece before the testAsync() function has finished its work. The setTimeout() call forces a two second delay, but Jasmine has already moved on and failed the test before the setTimeout() completes:

// Code under test
var flag = false;
function testAsync(done) {
// Wait two seconds, then set the flag to true
setTimeout(function () , 2000);
}
// Specs
describe("Testing async calls", function () {
it(&quot;Should be true if the async call has completed&quot;, function () {
    expect(flag).toEqual(true);
});

});

With Jasmine async testing, we have to call the async code in the beforeEach() function that runs before each it() function block within a describe() function block.

We also have to let Jasmine know when the async function has completed by calling the special done() callback function Jasmine provides. Here, we are passing this special done() callback around so our code under test can invoke it.

// Code under test
var flag = false;
function testAsync(done) {
// Wait two seconds, then set the flag to true
setTimeout(function () {
flag = true;
    // Invoke the special done callback
    done();
}, 2000);

}
// Specs
describe("Testing async calls with beforeEach and passing the special done callback around", function () {
beforeEach(function (done) {
    // Make an async call, passing the special done callback        
    testAsync(done);
});

it(&quot;Should be true if the async call has completed&quot;, function () {
    expect(flag).toEqual(true);
});

});

This works, but changing the code under test to accept the done() callback argument and invoke it may not be realistic. Why would you change your code under test just to make the testing framework happy?

Instead, you can use promises and call the special Jasmine done() callback when your promise has resolved. Note that the Jasmine done() callback is NOT the same as the promise's done() callback. They just use the same function name.

Here, I'm using jQuery's $.Deferred() object for the promises, but this approach should work with any promises library.

// Code under test
var flag = false;
function testAsyncWithDeferred() {
// Get a jQuery deferred
var deferred = $.Deferred();
// Wait two seconds, then set the flag to true
setTimeout(function () {
    flag = true;

    // Resolve the deferred
    deferred.resolve();
}, 2000);

// Return the deferred promise
return deferred.promise();

}
// Specs
describe("Testing async calls with beforeEach and invoking the special done callback in the promise's done callback", function () {
beforeEach(function(done) {
    testAsyncWithDeferred()
    .done(function (result) {
        // Invoke the special done callback
        done();
    });
});
           
it(&quot;Should be true if the async call has completed&quot;, function () {
    expect(flag).toEqual(true);
});

});

You can even use the data returned from the promise in the test once it is resolved. Here we are passing the return value in the deferred.resolve() call:

// Code under test
function testAsyncWithDeferredReturnValue() {
    // Get a jQuery deferred
    var deferred = $.Deferred();
// Wait two seconds, then set the return true
setTimeout(function () {
    // Resolve the deferred
    deferred.resolve(true);
}, 2000);

// Return the deferred promise
return deferred.promise();

}
// Specs
describe("Testing async calls with beforeEach and invoking the special done callback in the promise's done callback and using the promise's return data", function () {
var flag = false;
beforeEach(function (done) {
    testAsyncWithDeferredReturnValue()
    .done(function (result) {
        flag = result;
        
        // Invoke the special done callback
        done();
    });
});

it(&quot;Should be true if the async call has completed&quot;, function () {
    expect(flag).toEqual(true);
});

});

But of course, real-world applications can't get away with simply testing with setTimeout and true/false flags, so here is a more real-world example.

It calls $.getJSON() to go fetch some public JSON data in the beforeEach() function, and then tests the returned JSON in the it() block to make sure it isn't an empty object or undefined.

// Code under test
function testAsyncRealWorld() {
    // Get a jQuery deferred
    var deferred = $.Deferred();
    
    // Real world data call
    var data = $.getJSON("https://data.colorado.gov/resource/4ykn-tg5h.json", function() {
    	deferred.resolve(true);
    });
    
    // Return the deferred promise
    return deferred.promise();
}
// Specs
describe("Testing async calls with real-world data", function () {
var data = null;
beforeEach(function (done) {
    testAsyncRealWorld()
    .done(function (result) {
        data = result;
        
        // Invoke the special done callback
        done();
    });
});

it(&quot;Should have result if the async call has completed&quot;, function () {
    expect(data).not.toBeNull();
});

});

Testing async calls in Jasmine with async/await

With version 2.8 and later of Jasmine and your compiler that supports async/await (e.g., Babel, TypeScript), you can change this to be more readable:

describe("Testing async functions", () => {
  
  it("Should work with async/await", async () => {
    // Arrange
    let flag = false;
// Act
flag = await returnTrueAsync();

// Assert
expect(flag).toBeTruthy();

});
});
function returnTrueAsync() {
return new Promise(resolve => {
setTimeout(() => {
resolve(true);
}, 1000);
});
}

Much cleaner!

Autocomplete dropdown with jQuery UI and MVC

Sat, 05 Feb 2011 01:40:23 Z

You know the autocomplete dropdown. It has become ubiquitous, and customers now expect them in their web apps. "Can't you just set autocomplete=true or something?" It's not quite that easy with ASP.NET MVC, but it's pretty simple.

We want to set up a text box on a web page that uses jQuery to call back to a controller action as the user types. The action method will return a JSON array of values that match what the user has typed so far. Each time they type and pause for a second, the screen should show the new matching records.

The view

First, we'll work on the view. Set a reference to jQuery and to jQuery UI. These are included with new MVC 3 projects (look in the Scripts folder), or you can find a CDN and reference them there. I've got this in my view's head section:

<head>
    <title>Autocomplete Test </title>
    <script src="<%: Url.Content("~/Scripts/jquery-1.4.4.min.js")%>" type="text/javascript"></script>
    <script src="<%: Url.Content("~/Scripts/jquery-ui.min.js")%>" type="text/javascript"></script>
</head>

Then you need a text box to tie all this too. The search results will be shown under this text box to give the appearance of a dropdown. This simple form should do:

<form action="/Search/ProcessTheForm" method="post">
    <input id="searchTerm" name="searchTerm" type="text" />
    <input type="submit" value="Go" />
</form>

Next, you'll need to use the autocomplete function in jQuery UI like this:

<script type="text/javascript">
    $(function () {
        $("#searchTerm").autocomplete({
            source: "/Search/AutocompleteSuggestions",
            minLength: 3,
            select: function (event, ui) {
                if (ui.item) {
                    $("#searchTerm").val(ui.item.value);
                    $("form").submit();
                }
            }
        });
    });
</script>

Here we've got a jQuery selector binding the autocomplete function to the searchTerm input box("#searchTerm"). We then set the URL for the source for the autocomplete suggestions, which in this case, will be our controller (Search) and action method (AutocompleteSuggestions). Then we set the number of characters the user has to type before we make the first call. It's set to three here to prevent pulling back meaningless matches from searching too soon.

Finally, we set up the autocomplete function's select event to set the selected value from the dropdown list as the value in the searchTerm input box and submit the form to the Search controller and the ProcessTheForm action method.

Here's the entire view for reference:

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<dynamic>" %>
<!DOCTYPE html>
<html>
<head>
<title>Autocomplete Test</title>
<script src="<%: Url.Content("_{/Scripts/jquery-1.4.4.min.js")%>" type="text/javascript"></script>
<script src="<%: Url.Content("}/Scripts/jquery-ui.min.js")%>" type="text/javascript"></script>
</head>
<body>
<form action="/Search/ProcessTheForm" method="post">
<input id="searchTerm" name="searchTerm" type="text" />
<input type="submit" value="Go" />
</form>
<script type="text/javascript">
$(function () {
$("#searchTerm").autocomplete({
source: "/Search/AutocompleteSuggestions",
minLength: 3,
select: function (event, ui) {
if (ui.item) {
$("#searchTerm").val(ui.item.value);
$("form").submit();
}
}
});
});
</script>
</body>
</html>

The controller

Now you need to write something that will return the records that match what the user has entered so far. This might be a database call with a LIKE searchTerm + "%" (watch out for SQL injection, though) or SOUNDEX or a web service call. Be sure you limit your returned search results to maybe the top 10 matches so you don't bog things down with too much data moving over the wire.

Next, set up a controller action to invoke this back-end call and JSON up the returned list. We've already names the controller (Search) and action (AutocompleteSuggestions) in our view. Something like this should work, where _searchRepository is my repository call that finds matching strings, which are then converted to JSON:

public JsonResult AutocompleteSuggestions(string term)
{
    var suggestions = _searchRepository.GetAutoCompleteSearchSuggestion(term);
    return Json(suggestions, JsonRequestBehavior.AllowGet);
}

Don't forget the JsonRequestBehavior.AllowGet parameter in the Json call. You won't get anything back from the action method if you leave it off.

Also, the name of the parameter passed into the action method is important. The jQuery UI autocomplete method will call your source URL with a query string like "?term=foo". If you set the parameter name to a string named "term", the MVC model binder will grab the value from the query string for you.

The jQuery UI Autocomplete function has several other options and events you can use in your app, and the demos are worth checking out too.

Building a Windows 8 Live Tile with JavaScript

Tue, 16 Oct 2012 00:39:54 Z

If you've seen Windows 8 yet, you know it's got a tile-based start menu. One of the cool things (or annoying things) you can do is post values on your app's tile. This is called a "live tile" in Windows 8 world. Your app users can turn them on or off with a right click on the tile.

Here's how I built one with JavaScript.

Figure out what you want to display on your live tiles

This is what my tile looks like before it's "live" as both a smaller (square) and a larger (wide) tile:

The live tile concept is that you pick a style template, build up some XML, then push that XML to the tile through the notification API. These guidelines show you the different tile templates you can pick. Find a square tile and a wide tile you like, and pay attention to the name of that template, since you'll use that soon.

In this case, I decided I like TileSquareText01:

<tile>
  <visual>
    <binding template="TileSquareText01">
      <text id="1">Text Field 1</text>
      <text id="2">Text Field 2</text>
      <text id="3">Text Field 3</text>
      <text id="4">Text Field 4</text>
    </binding>  
  </visual>
</tile>

and TileWideText01:

<tile>
  <visual>
    <binding template="TileWideText01">
      <text id="1">Text Header Field 1</text>
      <text id="2">Text Field 2</text>
      <text id="3">Text Field 3</text>
      <text id="4">Text Field 4</text>
      <text id="5">Text Field 5</text>
    </binding>  
  </visual>
</tile>

The plan is to show the users current altitude as a number on the top, larger font line, then show the units (feet or meters) under that in the smaller font.

There are several rules about what you can and can't show on your tiles, so check the guidelines carefully to be sure your idea will not get rejected by the Windows Store during the certification process.

Tests for the correct live tile XML

Since the live tile notification is all about sending the right XML, let's start with a test of the XML we want at the end. Here I'm using QUnit to check the XML.

test("tile", function () {
    var altitude = 6071,
        altitudeUnits = "feet",
        result,
        expected;
result = tile.buildSquareTileXml(altitude, altitudeUnits);
expected = '&lt;tile&gt;' +
    '&lt;visual&gt;' +
    '&lt;binding template=&quot;TileSquareText01&quot; branding=&quot;name&quot;&gt;' +
    '&lt;text id=&quot;1&quot;&gt;6071&lt;/text&gt;' +
    '&lt;text id=&quot;2&quot;&gt;feet&lt;/text&gt;' +
    '&lt;text id=&quot;3&quot;&gt;&lt;/text&gt;' +
    '&lt;text id=&quot;4&quot;&gt;&lt;/text&gt;' +
    '&lt;/binding&gt;' +
    '&lt;/visual&gt;' +
    '&lt;/tile&gt;';
equal(result.getXml().toString(), expected, &quot;should get correct xml for square tile&quot;);

result = tile.buildWideTileXml(altitude, altitudeUnits);
expected = '&lt;tile&gt;' +
    '&lt;visual&gt;' +
    '&lt;binding template=&quot;TileWideText01&quot; branding=&quot;name&quot;&gt;' +
    '&lt;text id=&quot;1&quot;&gt;6071&lt;/text&gt;' +
    '&lt;text id=&quot;2&quot;&gt;feet&lt;/text&gt;' +
    '&lt;text id=&quot;3&quot;&gt;&lt;/text&gt;' +
    '&lt;text id=&quot;4&quot;&gt;&lt;/text&gt;' +
    '&lt;text id=&quot;5&quot;&gt;&lt;/text&gt;' +
    '&lt;/binding&gt;' +
    '&lt;/visual&gt;' +
    '&lt;/tile&gt;';
equal(result.getXml().toString(), expected, &quot;should get correct xml for wide tile&quot;);

});

These tests fail since we haven't written the functions yet, but we'll do that next. Ignore the "branding" attribute for now. We'll come back to that.

Build up the live tile XML

Here's the code to get the correct XML and get those tests passing. See those calls the Windows.UI.Notifications.TileTemplateType? That's where you plug in the name of the square and wide template you picked from the catalog.

I'm building up an array of values for the different lines of text. Use any XML or string manipulation technique you like. I got this one from the Windows 8 SDK samples.

function buildSquareTileXml(altitude, altitudeUnits) {
    var squareTemplate = Windows.UI.Notifications.TileTemplateType.tileSquareText01,
            squareTileLines = [
                altitude,
                altitudeUnits
            ],
            squareTileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(squareTemplate),
            squareTileTextAttributes = squareTileXml.getElementsByTagName("text");
for (var i = 0; i &lt; squareTileLines.length; i++) {
    squareTileTextAttributes[i].appendChild(squareTileXml.createTextNode(squareTileLines[i]));
}

var squareTileBinding = squareTileXml.getElementsByTagName(&quot;binding&quot;);
if (squareTileBinding[0]) {
    squareTileBinding[0].setAttribute(&quot;branding&quot;, &quot;name&quot;);
}

return squareTileXml;

}
function buildWideTileXml(altitude, altitudeUnits) {
var wideTemplate = Windows.UI.Notifications.TileTemplateType.tileWideText01,
wideTileLines = [
altitude,
altitudeUnits
],
wideTileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(wideTemplate),
wideTileTextAttributes = wideTileXml.getElementsByTagName("text");
for (var i = 0; i &lt; wideTileLines.length; i++) {
    wideTileTextAttributes[i].appendChild(wideTileXml.createTextNode(wideTileLines[i]));
}

var binding = wideTileXml.getElementsByTagName(&quot;binding&quot;);
if (binding[0]) {
    binding[0].setAttribute(&quot;branding&quot;, &quot;name&quot;);
}

return wideTileXml;

}

Combine the square and wide XML

Since users of your tile can toggle the smaller (square) or larger (wide) version of your tile, you want to combine the square and wide XML and send down both. Here's how to do that. Again, this is just XML manipulation, use any technique you like.

function combineTileXml(wideTileXml, squareTileXml) {
    var node = wideTileXml.importNode(squareTileXml.getElementsByTagName("binding").item(0), true);
    wideTileXml.getElementsByTagName("visual").item(0).appendChild(node);
return wideTileXml;

}

Pass the combined live tile XML to the Windows 8 API

Now that you've got the final XML you want, create a Tile Notification object and pass it to the Tile Update Manager:

function sendTileUpdate(altitude, altitudeUnits) {
    var wideTileXml,
        squareTileXml,
        combinedTileXml,
        tileNotification;
if (altitude &amp;amp;&amp;amp; altitudeUnits) {
    wideTileXml = buildWideTileXml(altitude, altitudeUnits);
    squareTileXml = buildSquareTileXml(altitude, altitudeUnits);
    combinedTileXml = combineTileXml(wideTileXml, squareTileXml);

    tileNotification = new Windows.UI.Notifications.TileNotification(combinedTileXml);
    Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().update(tileNotification);
}

}

The last two lines are doing the real work here, by using the Windows 8 notifications API. The rest is calling the other helper functions.

Calling the notification code

So who notifies the notifier code that we've got some new stuff to show on the line tile? You do! Figure out when something interesting happens in your app, and send a notification to the live tile then. In this case, that looks like:

tile.sendTileUpdate(altitude, altitudeUnits);

Putting it all together

Here's the result for the square and wide tiles:

Here's the combined JavaScript. I put it all in a file named it tile.js and used the WinJS namespacing function. This is pretty much the same as the revealing module pattern, and it means I can call tile.<whatever> from the tests and other JavaScript files.

(function () {
    "use strict";
function sendTileUpdate(altitude, altitudeUnits) {
    var wideTileXml,
        squareTileXml,
        combinedTileXml,
        tileNotification;

    if (altitude &amp;amp;&amp;amp; altitudeUnits) {
        wideTileXml = buildWideTileXml(altitude, altitudeUnits);
        squareTileXml = buildSquareTileXml(altitude, altitudeUnits);
        combinedTileXml = combineTileXml(wideTileXml, squareTileXml);

        tileNotification = new Windows.UI.Notifications.TileNotification(combinedTileXml);
        Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().update(tileNotification);
    }
}

function buildSquareTileXml(altitude, altitudeUnits) {
    var squareTemplate = Windows.UI.Notifications.TileTemplateType.tileSquareText01,
            squareTileLines = [
                altitude,
                altitudeUnits
            ],
            squareTileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(squareTemplate),
            squareTileTextAttributes = squareTileXml.getElementsByTagName(&quot;text&quot;);

    for (var i = 0; i &lt; squareTileLines.length; i++) {
        squareTileTextAttributes[i].appendChild(squareTileXml.createTextNode(squareTileLines[i]));
    }

    var squareTileBinding = squareTileXml.getElementsByTagName(&quot;binding&quot;);
    if (squareTileBinding[0]) {
        squareTileBinding[0].setAttribute(&quot;branding&quot;, &quot;name&quot;);
    }

    return squareTileXml;
}

function buildWideTileXml(altitude, altitudeUnits) {
    var wideTemplate = Windows.UI.Notifications.TileTemplateType.tileWideText01,
            wideTileLines = [
                altitude,
                altitudeUnits
            ],
            wideTileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(wideTemplate),
            wideTileTextAttributes = wideTileXml.getElementsByTagName(&quot;text&quot;);

    for (var i = 0; i &lt; wideTileLines.length; i++) {
        wideTileTextAttributes[i].appendChild(wideTileXml.createTextNode(wideTileLines[i]));
    }

    var binding = wideTileXml.getElementsByTagName(&quot;binding&quot;);
    if (binding[0]) {
        binding[0].setAttribute(&quot;branding&quot;, &quot;name&quot;);
    }

    return wideTileXml;
}

function combineTileXml(wideTileXml, squareTileXml) {
    var node = wideTileXml.importNode(squareTileXml.getElementsByTagName(&quot;binding&quot;).item(0), true);
    wideTileXml.getElementsByTagName(&quot;visual&quot;).item(0).appendChild(node);

    return wideTileXml;
}

WinJS.Namespace.define(&quot;tile&quot;, {
    sendTileUpdate: sendTileUpdate,
    buildWideTileXml: buildWideTileXml,
    buildSquareTileXml: buildSquareTileXml
});

})();

Branding

In the bottom left corner of the tile, I am showing the name of the app, in this case "Altitude", on the live tile.

If you like, you can show your logo here instead. This comes from the 30x30 logo in your package.appxmanifest on the Application UI tab, under Tile > Small Logo.

Change these lines:

binding[0].setAttribute("branding", "name");

to:

binding[0].setAttribute("branding", "logo");

And you'll get this instead:

In fact, you can take out all the code around branding if you like the logo there, since that's the default behavior. If you want neither your app name nor your logo there, you can set the branding attribute to "none".

Hey, my Live Tile doesn't work!

I had this experience the first couple times I ran my code, too. The most common mistake I've seen is invalid XML, so be sure you add those test first to avoid that.

The other snag was using the Simulator in Visual Studio 2012 that simulates a tablet with touch and rotating. I don't know what the issue was, but my live tile didn't update when I ran it through the Simulator. Other live tiles could be turned on and off, but not the one for my app. When I ran on Local Machine instead, the live tile worked fine. So if you're not seeing your live tile work in the Simulator, switch to Local Machine and see if that fixes it for you.

Making your ASP.NET MVC app look decent on an iPhone or iPad

Mon, 24 Sep 2012 02:35:00 Z

I wanted to try out the new mobile features of ASP.NET MVC 4 to convert an existing site (this one!) to a half-decent looking iPhone/iPad app. It was really easy. Here are the steps and what I learned in the process.

Think about what your mobile user will want to do

This is the most important piece, and it's one you need to take seriously before you dive in. If you skip it, you'll just have a mess. You know that tablets and phones are smaller, so things that require lots of screen space won't work. But what is the main thing people open the site/app to do? Optimize for that and put it front and center. If there is more than one thing your site/app does, how will mobile user's navigate around? When converting an existing app to mobile, you'll probably want to cut out a lot of extraneous stuff. You could also phase in different chunks. It doesn't have to be all or nothing.

Choose your technical approach

Scott Hanselman has a nice blog post and chart showing effort compared to user experience across different approaches to making your app mobile.

He covers responsive design (CSS media queries and resizing), using a mobile framework (like jQuery Mobile), or going native (Objective-C). My only quibble with the Scott's chart is the green circle for native apps is too small. I think that's WAAAAY more effort.

For this post, I went with a mobile framework (jQuery Mobile). This is the most bang for your buck. You can learn it in less than an hour, and convert views and layouts in a half day to a day, depending on how complicated your views are.

Get jQuery Mobile

Add the jQuery Mobile NuGet package to your web project.

It will add the JavaScript, CSS, and sprite icon images in the /Scripts, /Content, and /Content/Images folders in your web project. I moved the JavaScript and CSS to /Content/Scripts/Downloaded and /Content/Styles/Downloaded folders. I prefer to do this so I can bundle scripts with wildcards like /Content/Scripts/Site/*.js. Here's my folder structure:

Bundling

I dropped the *.min.js and *.min.css files since I'm combining and minifying these with the BundleConfig like this:

using System.Web.Optimization;
namespace App_Start
{
public class BundleConfig
{
public static void RegisterBundles(BundleCollection bundles)
{
// Scripts
        bundles.Add(new ScriptBundle(&quot;~/Content/Scripts/modernizr&quot;).Include(
            &quot;~/Content/Scripts/Downloaded/modernizr-2.6.2.js&quot;)); 

        bundles.Add(new ScriptBundle(&quot;~/Content/Scripts/all&quot;).Include(
            &quot;~/Content/Scripts/Downloaded/jquery-1.8.1.js&quot;, 
            &quot;~/Content/Scripts/Downloaded/jquery.unobtrusive-ajax.js&quot;,
            &quot;~/Content/Scripts/Downloaded/jquery.validate.js&quot;,
            &quot;~/Content/Scripts/Downloaded/jquery.validate.unobtrusive.js&quot;,
            &quot;~/Content/Scripts/Site/*.js&quot;));

        bundles.Add(new ScriptBundle(&quot;~/Content/Scripts/mobileall&quot;).Include(
            &quot;~/Content/Scripts/Downloaded/jquery-1.8.1.js&quot;,
            &quot;~/Content/Scripts/Downloaded/jquery.mobile-1.1.1.js&quot;));

        // Styles

        bundles.Add(new StyleBundle(&quot;~/Content/Styles/all&quot;).Include(
            &quot;~/Content/Styles/Site/Site.css&quot;));

        bundles.Add(new StyleBundle(&quot;~/Content/Styles/mobileall&quot;).Include(
            &quot;~/Content/Styles/Downloaded/jquerymobile/*.css&quot;,
            &quot;~/Content/Styles/Site/Mobile.css&quot;));
    }
}

}

The bundles created here are for the JavaScript and CSS for the desktop site ("all") and the mobile site ("mobileall"). The "modernizr" bundle is separate because it only works in the <head> section, but the rest is loaded at the bottom of the <body> tag in the Layout view so it doesn't block page loading.

Make a _Layout.Mobile.cshtml

You'll want a mobile layout view. It's probably simplest to take your existing _Layout.cshtml, copy/paste, and rename it to _Layout.Mobile.cshtml.

The view engine routes "mobile" requests to the correct place. I have mobile in quotes here because it puts iPads in that category. Seems like it would be either _Layout.Tablet.cshtml or _Layout.Phone.cshtml instead of _Layout.Mobile.cshtml, since those are very different form factors, but that's what you get out of the box.

If you don't like that, you can add specific views for specific devices with display modes. I recommend looking through your web logs to see what your users are really browsing with so you spend your time making your app look its best for the most popular user agents. Start with a generic mobile layout and go from there if it starts to break down and you're getting enough traffic from that device to warrant the extra work.

You'll probably rip out pieces of your app/site in the mobile layout. Some stuff doesn't make sense on a phone, so this is where you can take it out if it's site wide. If it's something in a view you want to hide, see below.

For the JavaScript, you can probably get away with just jQuery and jQuery Mobile. You probably won't need Modernizr. You may have some site-specific JavaScript you need to include in their, too.

For style sheets, I recommend starting with just the jQuery Mobile CSS. You can add your own Mobile.css (you can rename this to anything you like) referenced in your mobile layout for tweaks and overrides you need to do. I'd leave the jQuery Mobile CSS as-is so you can upgrade later without problems.

You'll also want to set your viewport to max width for every device:

<meta name="viewport" content="width=device-width">

Here's my _Layout.Mobile.cshtml (the relevant parts anyway):

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width">
    <title>@ViewBag.Title</title>
    @Styles.Render("~/Content/Styles/mobileall")
</head>
<body>
    <div data-role="page" data-theme="c">
        <header data-role="header">
            <div>
                <a href="@Url.Action("Index", "Home")">
                    <img src="@Url.Content("~/Content/Images/Logos/Logo_100px_High.png")" alt="Volare Systems, Inc." width="160px" height="100px" />
                </a>
            </div>
        </header>
        <section id="content" data-role="content">
            @RenderBody()
        </section>
        <footer>
            <nav>
                <ul data-role="listview" data-content-theme="c" data-divider-theme="d" data-inset="true" >
                    <li data-role="list-divider">What We Do</li>
                    <li>@Html.ActionLink("Home", "Index", "Home")</li>
                    <li>@Html.ActionLink("Services", "Index", "Services")</li>
                    <li>@Html.ActionLink("Customer testimonials", "CustomerTestimonials", "Services")</li>
                    ...
                </ul>
            </nav>
            <div id="copyright">
                &amp;copy; 2009 - @DateTime.Now.Year.ToString() @Html.ActionLink("Volare Systems, Inc.", "Index", "Home")
            </div>
        </footer>
    </div>
    @Scripts.Render("~/Content/Scripts/mobileall")
</body>
</html>

Start using jQuery Mobile

Now it's time to start adding in the data-* attributes and classes jQuery Mobile wants to use. You'll find them here on the demo site. I used:

data-page="page" in the mobile layout as an outer wrapper
data-theme="c" (try out the different themes to see what suits you best by swapping out letters a-e)
data-role="content" around the @RenderBody markup
data-role="listview" and data-role="list-divider" for the navigation
data-role="collapsible-set" and data-role="collapsible" for collapsible text that shows/hides when you click it

Here are the results:

Click through the docs and see what you can find that adapts well to your situation. For forms, I found it was fine to remove my normal style sheet and let jQuery Mobile take over.

Make a Mobile.css

I use Site.css and Mobile.css as my desktop and tablet/phone CSS files. The _Layout.Mobile.cshtml references to the Mobile.css, and _Layout.cshtml references the Site.css.

You may not need a Mobile.css, but I found it useful to tweak margins, padding, etc. to get the look I wanted. You'll probably have to use the !important CSS tag to force your CSS to override the jQuery Mobile CSS, so watch out for that. Also, every time you do this, someone at A List Apart sighs heavily.

Test and tweak your views

There are lots of cheap and free iPhone/iPad simulators out there. Try to find a free one you like. I gave up and downloaded the Electric Plum one. So far, so good. It's more stable than the free ones I tried.

Once you browse to your site on localhost, you'll see things you didn't realize would be such a fail on the phone. This is your chance to remove it or fix it. There are several approaches I used, based on the situation:

Add jQuery Mobile data-* attributes to your view to render it the jQuery Mobile way. Sprinkling these should not collide with your HTML for desktop rendering.
Change the Mobile.css to draw the elements a little differently just for mobile. If it's really minor, you can hide it with a CSS display: none;, but keep in mind this will run on a phone. If you have the chance to send fewer bytes from the server to the device, that's almost always going to be the way to go.
Add server-side conditional checks for code or markup that is only for mobile (or just for desktop). In a MVC Razor view, this looks like:

@if (Request.Browser.IsMobile) {
    // do something just for mobile
}

If the conditional branching inside your view get to be too ugly, you can add a mobile-only view with the same naming pattern. So Index.cshtml has a mobile cohort in Index.Mobile.cshtml. You can break common code between the two views into partial views, and have the mobile and non-mobile views reference those partial views with the normal

@Html.Partial("_ThePartialView")

Getting HTTP/2 working with Azure CDN

Sat, 03 Feb 2018 16:49:00 Z

HTTP/2 serves web content faster through multiplexing, where several requests can be sent on the same TCP connection. However HTTP/2 is not available today on Azure App Services (web apps). A lot of people wish it was, but that's a limitation of Azure hosting right now. One of the Azure feedback admins had this to say on January 9, 2018:

Hi all. As everyone had noticed, we have upgraded App Service resources to Server 2016. As mentioned in our updates, this is indeed paving the way to HTTP/2 support across the board. As we are settling in with stability of the new OS version, we will begin work to open up HTTP/2. When I have a concrete timeline to share, I will do so. We should expect that in the next few months.

Thanks,
Oded

So it's coming, and hopefully soon, but it's not there yet. In the meantime, you can put static resources like images on an Azure CDN and get HTTP/2 performance benefits, in addition to normal CDN benefits for long-lived content, like cache headers that don't expire any time soon and a geographically distributed network to host it on.

This post is a walkthrough on how to do that with Azure Storage and Azure CDN services.

Azure Setup

First, go into your Azure account and create a new resource group. This makes it easier for testing so you can delete the whole thing when you're done playing around. I named mine testresourcegroup. There are so many pieces to an Azure infrastructure, you are better off if you prefix or suffix everything with one name, like your project name or acronym, and then put the name of the Azure thing you're creating somewhere in that name.

When that's created, go to that resource group. We'll add an App Service Plan (Azure-speak for the server/account type you want for your web app) and an App Service.

I click the + button to add, search for "App Service Plan", pick that, and fill that out. In the Pricing tier, I selected "Free" for this demo.

Now create a test web app by adding another resource to your resource group, searching for App Service, and selecting Web App. Be sure to select your newly created App Service Plan. I ended up having to go to testweb17 to get to a unique, publicly addressable name.

While that's being created, let's add Azure blob storage. Go back to your resource group, click the + button again to add, and search for "blob storage", then select "Storage account – blob, file, table, queue". Give it a unique name. In my case, I had to use teststorge19 to get a unique, publicly addressable name. I also changed the default Account kind to Blob storage since that's all I need. You can come back later and tweak the other settings here based on your app's needs.

Now we need to create the CDN in Azure. Go back to your resource group, click the + to add, and search for "CDN" and select it from the list. Give it a name. I used testcdn. Pick a pricing tier. I used Standard Verizon (Verizon allows custom domain HTTPS connections, Akamai doesn't).

Then select the option to create a CDN Endpoint. Like the App Service and App Service Plan relationship, the CDN is the service level and pricing, but the CDN Endpoint is the thing you really connect to. Pick a CDN endpoint name. I used testcdn19 to match up with my storage account name. Again, this must be unique and publicly addressable. Be sure to pick Origin type of Storage and pick the Original hostname for your storage account from the drop down. I used teststorage19.blog.core.windows.net since that is my test storage account created above.

When Azure is done huffing and puffing, your new resource group should look like this, but of course with your names. You'll have an App Service Plan with an App Service, a Storage Account, and a CDN Profile with a CDN Endpoint.

Web Setup

I've made a one page web app with an index.html and an image. You can download them from GitHub or use your own content or test page. It's nothing more than this HTML and a picture.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>HTTP/2 with Azure CDN</title>
</head>
<body>
    <p>Here is an image of an elk in Rocky Mountain National Park.</p>
    <img src="images/Fall - Estes Elk.jpg" />
</body>
</html>

To upload this web app to Azure, I first need to get a publish profile from Azure in my App Service.

Then I open my web app in Visual Studio, right click on the web site or web project and select Publish Web App.

Next, I tell Visual Studio to import the just downloaded publish profile.

Then when I publish my web app, it goes up to Azure and is publicly available.

After the publishing process completes, my browser opens the test web app at https://testweb17.azurewebsites.net/.

If I open Chrome Dev Tools and go to the Network tab, I can see the two requests (one for the page, one for the image) are using HTTP 1.1. Let's see if we can get that image to be served using HTTP/2.

Storage Setup

Go to your Azure resource group, find the storage account you set up, and add a blob container. This is not quite a folder, but kind of acts like one for our purposes. I'll add one for "web". Be sure to set your container to something other than Private. I set mine to Blob.

Now I can select my container and upload the image to it. There are lots of client tools to upload, download, and manage your Azure storage files, like CloudBerry Explorer for Microsoft Azure, which is free.

Once I have uploaded the image, I can click it and get its URL. Open that URL to test that you can see the image. If not, check that you didn't make your container private. Also, be sure you are using the correct case. Calls to storage blobs are case sensitive. If you file is Image.jpg and request image.jpg (lowercase "I"), you'll get a 404. In my case, the image URL ends up as https://teststorage19.blob.core.windows.net/web/Fall%20-%20Estes%20Elk.jpg.

If you open Chrome Dev Tools and refresh the image, you can see it's being served over HTTP/2 already without being on a CDN.

Let's update the HTML to use that new URL and check that it's still using HTTP/2 when uploaded to the Azure App Service.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>HTTP/2 with Azure CDN</title>
</head>
<body>
    <p>Here is an image of an elk in Rocky Mountain National Park.</p>
    <img src="https://teststorage19.blob.core.windows.net/web/Fall - Estes Elk.jpg" />
</body>
</html>

I made this change and re-published the web app, and sure enough, it's served over HTTP/2.

Let's go one step further and serve the image from a CDN, instead of directly from the storage account.

CDN Setup

In Azure, open your CDN Endpoint. You should see the URLs for your storage account and your CDN that maps to your storage account.

Since all our content is in a storage container called "web" and that becomes part of the URL, we can make that a default path for the CDN Endpoint under Origin.

Now we'll have URLs like this, using the CDN and skipping the /web/ folder in the URL:

https://testcdn19.azureedge.net/Fall - Estes Elk.jpg

instead of:

https://teststorage19.blob.core.windows.net/web/Fall - Estes Elk.jpg

This change can take up to 90 minutes to propagate, so if you get 404s, that may be what's happening.

Once you can browse to the image URL with your browser, replace that image source in the HTML markup and re-publish your web app to Azure.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>HTTP/2 with Azure CDN</title>
</head>
<body>
    <p>Here is an image of an elk in Rocky Mountain National Park.</p>
    <img src="https://testcdn19.azureedge.net/Fall - Estes Elk.jpg" />
</body>
</html>

When you browse to it now, you can open Chrome Dev Tools and confirm the image is coming from the CDN and is using HTTP/2.

Working with two sets of ESLint rules for legacy ES5 and modern JavaScript using Gulp

Tue, 05 Feb 2019 01:39:05 Z

I've written before about using file extensions to tell webpack and Babel which files are older-style ES5 syntax and which are newer-style JavaScript. What if you've got a project that has both, and you need to run ESLint on the older, *.js files as well as the new *.es6 files?

You can run both in one task with Gulp.

First, set up separate ESLint rules files. These are usually .eslintrc.json files, but since we need two sets of rules, create .eslintrc.es5.json (for the older syntax rules) and .eslintrc.es6.json (for the newer syntax rules).

Then create Gulp task ("validate-es5") to get a glob of the *.js files and apply the rules in the .eslintrc.es5.json rules config and a Gulp task ("validate-es6") to get a glob of the *.es6 files and apply the rules in the .eslintrc.es6.json rules:

const gulp = require("gulp");
const eslint = require("gulp-eslint");
const plumber = require("gulp-plumber");
const paths = {
    es6scripts: "Scripts/**/*.es6",
    es5scripts: "Scripts/**/*.js"
};
const es5eslintGlob = [paths.es5scripts];
const es6eslintGlob = [paths.es6scripts];
 
 
gulp.task("validate-es5", () =>
    eslintPipeline(gulp.src(es5eslintGlob), ".eslintrc.es5.json")
);
 
gulp.task("validate-es6", () =>
    eslintPipeline(gulp.src(es6eslintGlob), ".eslintrc.es6.json")
);
 
function eslintPipeline(stream, rules) {
    return stream
        .pipe(plumber({
            errorHandler: error => {
                console.log(error.message);
                console.log(error.toString());
            }
        }))
        .pipe(eslint(rules))
        .pipe(eslint.format())
        .pipe(eslint.failAfterError());
}

Next, create a Gulp task to run both tasks named "watch" to run a watch on those files and execute ESLint with the correct rule set for each file extension when a file changes:

const print = require("gulp-print").default;
const watch = require("gulp-watch");
 
gulp.task("watch", () => {    
    eslintPipeline(watch(es5eslintGlob)
        .pipe(print(filepath => `ESLint (ES5): ${filepath}`)), ".eslintrc.es5.json")
        .pipe(eslint.failOnError());
    eslintPipeline(watch(es6eslintGlob)
        .pipe(print(filepath => `ESLint (ES6): ${filepath}`)), ".eslintrc.es6.json")
        .pipe(eslint.failOnError());
});

Fix for weird errors in MVC4 when adding a new Area

Thu, 13 Dec 2012 01:39:38 Z

MVC has let you add Areas to your web project for a couple versions now. Areas help you group large chunks of code in your web app. You can group along a technical axes (like "Api") or a functional axes (like "Admin").

The first error

I created a new MVC4 project, added an area called "Test", and browsed to the home page (http://localhost:59669). Works! Then I browse to the new area (http://localhost:59669/Test) and get this:

What's going on with those underscores? The error message shows the problem is in my Web.config, but not the application root one, the one under /Areas/Test/Views/Web.config. I open it in Visual Studio, and sure enough, underscores.

<configSections>
  <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=__WebPagesVersion__.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
    <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=__WebPagesVersion__.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
    <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=__WebPagesVersion__.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
  </sectionGroup>
</configSections>

I compare that to the other Web.config under the root /Views/Web.config, and copy and paste those values in.

<configSections>
  <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
    <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
    <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
  </sectionGroup>
</configSections>

At this point, I'm assuming there is a bug in the "Add Area" template. So let's build and refresh the browser and it should work now, right?

The second error

Of course not.

Hmm. Lots of details in that stack trace, but not much to go on here. I checked my route registration code and checked my area registration code. Both looked fine:

using System.Web.Mvc;
using System.Web.Routing;
namespace MvcApplication2.App_Start
{
public class RouteConfig
{
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute(".axd/{*pathInfo}");
        routes.MapRoute(
            name: &quot;Default&quot;,
            url: &quot;{controller}/{action}/{id}&quot;,
            defaults: new {controller = &quot;Home&quot;, action = &quot;Index&quot;, id = UrlParameter.Optional},
            namespaces: new[] { &quot;MvcApplication2.Controllers&quot; }
            );
    }
}

}
using System.Web.Mvc;
namespace MvcApplication2.Areas.Test
{
public class TestAreaRegistration : AreaRegistration
{
public override string AreaName
{
get { return "Test"; }
}
    public override void RegisterArea(AreaRegistrationContext context)
    {
        context.MapRoute(
            name: &quot;Test_default&quot;,
            url: &quot;Test/{controller}/{action}/{id}&quot;,
            defaults: new {action = &quot;Index&quot;, id = UrlParameter.Optional},
            namespaces: new[] {&quot;MvcApplication2.Areas.Test.Controllers&quot;}
            );
    }
}

}

I also added the namespaces to the area (the last parameter above) to help the routing engine find the right controller. That looked fine, too.

The error message was about a bad assembly ("The given assembly name or codebase was invalid."). Maybe something didn't get built or loaded right ? I tried a Clean and Rebuild. No luck.

Maybe ASP.NET temp files were cached? Let's clear browser cache, close and re-open the browser, close and re-open Visual Studio, restart IIS Express, and see if that helps….and no, no luck.

The solution

I was running out of ideas, but since the first problem was the Web.config, maybe this was, too. I opened up the generated Web.config under /Areas/Test/Views/Web.config again and compared it to the one under the root /Views/Web.config.

Sure enough, more freaking underscores. I just copied ALL the values from the root view's Web.config into the areas one, built, refreshed, and finally got the areas showing up.

Maybe I have a wacky install. Maybe I got hold of some bad pre-release NuGet package. But it seems there is a template bug here when adding Areas to an MVC project. I have the Fall Update on Visual Studio 2012, so my About screen looks like this:

I'm writing this up in the hopes that I save someone else some time. If you have suggestions on where I got an underscore happy template, please let me know in the comments below.

Running SpecFlow and WatiN tests with TeamCity and AppHarbor

Fri, 03 Jun 2011 00:40:12 Z

If you're using SpecFlow and WatiN to automate your web testing, things work great on localhost, but tend to fall apart on the continuous integration server. It's a "chicken or the egg" paradox. If the new code hasn't been deployed yet, it can't be externally tested with WatiN, but it shouldn't be deployed until all the tests have passed. What are you supposed to do?

TeamCity

If your SpecFlow and WatiN tests are in their own assembly (something like MyProject.AcceptanceTests.dll), and you're using TeamCity, it's easy to run your unit tests and integration tests, then deploy the code to a web server, then run your acceptance tests in a separate build step. It's just a matter of breaking up the steps and designating which test assemblies will be run at which time.

This step in the screen shot below is running the unit tests and integration tests. A separate, later step will run the tests in the **\*AcceptanceTests.dll assembly after the code has been deployed to the web server.

AppHarbor

If you're using AppHarbor to run your tests on check in with git push appharbor master, (and you should - it's super easy), you don't want to run your web tests until the code is deployed, but AppHarbor doesn't deploy anything until all the tests pass.

What we want is for AppHarbor to ignore the web automation tests until the code is deployed. AppHarbor flips a *.config appSetting key named "Environment" to "Test" when it's testing and to "Release" when the code is deployed. So while your tests are running, your App.config in your test project should look something like this:

<appSettings>
  <add key="Environment" value="Test"/>
</appSettings>

We can take advantage of this appSetting test runner change to tell SpecFlow to ignore this set of tests, which allows AppHarbor to continue running other tests and deploying the code.

This is not be the most elegant way to do this, but I got this working today:

[Binding]
public class MyStepDefinition
{
    [BeforeFeature]
    public void BeforeFeature()
    {
        if (ConfigurationManager.AppSettings["Environment"] == "Test")
            Assert.Ignore();
    }
// Rest of step definition code...

}

The BeforeFeature attribute tells the SpecFlow test runner to execute that method before each feature. With a quick check on the Environment appSetting value, we can tell AppHarbor to ignore this test and continue processing. This will ignore all scenarios in all feature files. Since all my scenarios are web automation tests, that works for me.

But what if you have some scenarios that rely on web automation testing and others that don't? A more targeted approach would be to set a SpecFlow tag, like @web over the SpecFlow scenarios that require web automation testing to pass. Then in the [BeforeScenario("web")] handlers for that tag, you could set Assert.Ignore to skip those scenarios while executing all other scenarios.

[BeforeScenario("web")]
public void BeforeScenario()
{
    if (ConfigurationManager.AppSettings["Environment"] == "Test")
        Assert.Ignore();
}

Once your non-web automation tests have passed and the code is deployed, you can point your local test runner at the AppHarbor URL and test against the newly deployed web app.

Sharing data from within your Windows 8 app using JavaScript

Wed, 17 Oct 2012 00:39:51 Z

One of the nifty features of Windows 8 is the ability of the OS to share data between apps. For instance, if I open the Weather app, click Windows + H, I get the Share bar that let's me send the weather forecast to the Mail, Tweetro, or People apps.

Most sharing apps take relevant text, HTML, and links, and prepare a draft email, tweet, etc. for you to send. Here is the HTML the Mail app prepares to send from the Weather app:

This post is about how to do the same thing from within your app.

You can share text, HTML, images, files, etc. I'm going to share text with my current location information from an altitude app. This is what we're going for:

It's just plain text, but you can get fancier.

The first thing you'll do in your code is listen for Windows 8 telling you the user wants to share something. Wire up the sharing event listener in your "ready" code, and unhook it in your "unload" code like this:

var dataTransferManager;
var page = WinJS.UI.Pages.define("/default.html", {
ready: function(element, options) {
dataTransferManager = Windows.ApplicationModel.DataTransfer.DataTransferManager.getForCurrentView();
dataTransferManager.addEventListener("datarequested", onSharingRequested);
},
unload: function() {
dataTransferManager.removeEventListener("datarequested", onSharingRequested);
}
});

Now we've got a function called "onSharingRequested" that will run when the user starts sharing within our app, but we need to write the code in that event/function to build up the text to share.

function onSharingRequested(e) {
    var request = e.request;
    request.data.properties.title = "My current altitude and location";
    request.data.setText("My current altitude and location are Altitude: " + location.altitude + " " + location.altitudeUnits +
        ", Latitude: " + location.latitudeFormatted + ", Longitude: " + location.longitudeFormatted +
        ", Accuracy: " + location.accuracy + ", Near: " + location.near);
}

You set properties on the passed in request object, like the title and the text shown here. The title must be set or sharing won't work.

Sharing data between apps is something people will probably get used to eventually, but if you want to be sure the users of your app know they can share, make a button that does that same thing as Windows + H or a swipe from the right on a tablet.

On your button click event, call the showShareUI method of the DataTransferManager like this:

function onSharingButtonClick() {
    Windows.ApplicationModel.DataTransfer.DataTransferManager.showShareUI();
}

Validation frameworks in ASP.NET MVC

Thu, 17 Sep 2009 00:41:23 Z

There are plenty of validation frameworks out there. I've worked with NHibernate Validators, Microsoft's Enterprise Application Blocks, and now Data Annotations. They primarily work by adding attributes to the properties in the class you want to validate.

How are they different?

Not very. The biggest difference between them is their syntax. I guess the Validation Blocks from Microsoft's P&P group have a lot of configuration options, but I haven't needed that on a project. The most prominent differences are in the attributes themselves.

You can probably make a case for Data Annotations having a slight advantage since it's going to be in the .NET base-class libraries. Easier to deal with assemblies installed in the GAC instead of the ones you have to drag around for each deployment.

How do you integrate them with MVC?

Each of these frameworks can be integrated with ASP.NET MVC. But the best validation call is one you don't have to explicitly make. Huh?

It's OK to call MyClass.IsValid() in a controller action, but if you can avoid it, I think you're better off. Otherwise, what happens if you forget to call it?

Instead, use a model binder that invokes the validation framework for you. This is how I am using the Data Annotations model binder with the MVC framework:

ModelBinders.Binders.DefaultBinder = new Microsoft.Web.Mvc.DataAnnotations.DataAnnotationsModelBinder();

Now this guy will intercept calls to your controller actions and reject invalid incoming view models. Here is a simple tutorial for using Data Annotations that goes into more detail.

How do you lay this out in the solution?

I have an Application Services layer that my MVC layer calls into. My controllers have constructors with an interface to an application service injected into them. My IoC container decides which concrete version of this application service interface to use at runtime.

Next, my Application Service layer has a DTO folder that holds all the DTOs (property-only classes) my views need in my MVC app. These are not my domain entities. There might be a lot of overlap with those domain entities, but these DTOs are just there for communication between the UI layer and Application Services layer. These DTOs are where I put my validation attributes.

So now I've got views that are tightly bound to the DTOs, which are owned in the Application Services layer. This allows strong typing of the view so I can use the DTO's properties as my view's model. This is handy for the Html Helpers to get design-time IntelliSense and compile-time checking.

What else can you do?

I haven't spent a lot of time looking into it, but xVal looks pretty strong for client side AND server side validation using Data Annotations and a couple other validation frameworks. It also lets you validate your business rules in your domain and throw an exception. I need to check into this more, because that sounds like the validation holy grail for validation to me: getting UI validation and business rule validation into a common format.

The case for TDD

Fri, 17 Jul 2009 11:39:00 Z

TDD is hard. It sounds like it wouldn't be hard. It's just a little test. The code is the hard part, right? But it's really hard to do it well. I struggle with it plenty and I know my way around C# and OO pretty well.

There better be a payoff for this bass-ackwards way of coding. It takes a while to get there, but I can see the light at the end of the tunnel in my own development. Here's where I've seen my code improve as I've moved toward TDD:

Focusness

You focus on the behavior of your code instead of the implementation. You don't start by thinking of tables, classes, and properties (or in my case, try hard not to). You start off thinking of the business requirements and roles. User stories are popular because they push you into restating the requirements in context: "As a (some role)...I want to (do something)...so that (some business value)". The first two chunks of this can guide your test creation. You can write methods that cover these scenarios.

If you're doing it the RED-GREEN-REFACTOR way, you'll write a test and just enough for the code to compile, get the test to pass with the minimum amount of code possible. Finally, you can go back and clean up what you aren't proud of from your first effort, then run the test again. You get to keep repeating that until you are happy with the code and that the requirement/story is met and the user accepts it.

Then you STOP. That's the fourth step you don't see in the pretty RED-GREEN-REFACTOR icon. If you don't stop, you loose your focus on the functionality and you start trying to gold-plate the code. Which can lead to...

Dude, you know what would make this REALLY cool?

You're getting paid to write software to meet the requirements. If you going beyond that, be careful who you're doing the coding for. If it's the business, and you're glad to show them how much time you've spent on it, you might be justified in doing it. But if you're coding it for yourself, do it on your own time.

Unfortunately, people who are drawn to programming are often tinkerers and bit-twiddlers. I appreciate having a framework for my development that keeps me on task, because I am easily distracted by grand visions of what I might be able to code into the app. There is no code we couldn't tweak a little and add this new cool pattern or just-learned technique to. TDD forces you to go directly to the requirements, not the technology.

SOLID code

The more you move toward TDD, the more little classes you have with giant names. Same thing with methods. There are tons, they are very short (one screen or so max), and they have long names. This is progress?

Yes, I think it is because of the SOLID principals. SOLID is a horrible acronym of acronyms, but it can help you keep some object-oriented principals in mind. I'll go over it and how I've tried to learn it in more depth in a future post, but the guys at Los Techies covered SOLID in depth already. So the side effect of decoupled code is you have lots of little files that just do one little thing. It took me a while to get over this and the file bloat in the project, but I'm at peace with it now. The payoff is that I am using more SOLID principals than I was before, and that's a good thing.

Oh yeah, you get some tests, too

It's been said before, but TDD is kind of misnamed. Yes, you start with the test, but that's not the most important thing. The most important thing is the requirement focus and the way it drives you toward a more loosely coupled design. But it's pretty fun to see that screen light up with green checks or circles after you've made a change.

The real value of the tests themselves is that today's unit tests become tomorrow's regression tests. You won't remember why you wrote the code last week, but you don't have to. The tests can also serve as mini-documentation of the requirements if you write the test names in a consistent way. There are BDD frameworks that let you spit out some HTML to do exactly this.

Ruthless Refactoring

All this adds up to something of a safety net for refactoring. Think of the confidence you can have changing the code, even if it's another team members code. Or if (gasp!) they make changes to your code. It's nice to know your code still works.

If you write the tests first, you know you've got the "happy path" covered on your code. That's the one you started with. You can write a few more tests to cover the likely deviations from that happy path, but when you get to the weird stuff (what if you order $999,999,999,999 in widgets?), call it good and move on.

Showing and saving user settings in a Windows 8 app with JavaScript

Tue, 23 Oct 2012 00:39:49 Z

If your Windows 8 app has user-based settings, you need a place to show those values, let users change them, and save them for later use. Sometimes these are called preferences, but in Windows 8, they are called "settings".

You can see and set your settings in a Windows 8 app with Windows + I. You'll pull up a fly out dialog from the right like this:

Clicking on the "Options" choice opens up the settings for the app:

Before you dive in and do this with your app, get acquainted with the Windows 8 app settings guidelines. Here's what I did for mine.

Create the Options view

Here is my options.html file. Most of this is plain old HTML. Note the ID of the outer div is "options". This could be named anything, but keep that ID in mind since we'll need it later.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>Options</title>
&lt;!-- WinJS references --&gt;
&lt;link href=&quot;https://volaresoftware.com/blog/Microsoft.WinJS.1.0/css/ui-light.css&quot; rel=&quot;stylesheet&quot; /&gt;
&lt;script src=&quot;//Microsoft.WinJS.1.0/js/base.js&quot;&gt;&lt;/script&gt;
&lt;script src=&quot;//Microsoft.WinJS.1.0/js/ui.js&quot;&gt;&lt;/script&gt;

&lt;!-- App references --&gt;
&lt;link href=&quot;https://volaresoftware.com/blog/css/settings.css&quot; rel=&quot;stylesheet&quot; /&gt;
&lt;script src=&quot;/js/app/options.js&quot;&gt;&lt;/script&gt;

</head>
<body>
<div id="options" class="win-settingsflyout" data-win-control="WinJS.UI.SettingsFlyout" data-win-options="{ width:'narrow' }">
<div class="win-header">
<button id="backButton" class="win-backbutton" aria-label="Back" onclick="WinJS.UI.SettingsFlyout.show()"></button>
<div class="win-label">Options</div>
</div>
<div class="win-content">
<div class="win-settings-section">
<p>
<label>Use feet or meters</label>
<label>
<input id="feet" name="feetOrMeters" type="radio" value="Feet" checked />Feet
</label>
<label>
<input id="meters" name="feetOrMeters" type="radio" value="Meters" />Meters
</label>
</p>
<p>
<label for="refreshInterval">Refresh interval in minutes</label>
<input id="refreshInterval" name="refreshInterval" type="range" min="0" max="15" value="1" />
</p>
<p>
<label for="movementThreshold">Movement threshold in feet</label>
<input id="movementThreshold" name="movementThreshold" type="range" min="0" max="100" value="50" />
</p>
</div>
</div>
</div>
</body>
</html>

The CSS classes may not be familiar, but these are coming from the Windows 8 SDK CSS (ui-light.css).

The interesting parts are 1) there is no form tag or submit button (we'll see the JavaScript below that works with these values), 2) the data-win-control stuff in the top level div,

<div id="options" class="win-settingsflyout" data-win-control="WinJS.UI.SettingsFlyout" data-win-options="{ width:'narrow' }">

and 3) the onclick event for the back button that calls WinJS.UI.SettingsFlyout.show().

<button id="backButton" class="win-backbutton" aria-label="Back" onclick="WinJS.UI.SettingsFlyout.show()"></button>

The WinJS area we're working with here is the SettingsFlyout, and the show() and hide() methods display it and move it out of the way.

In modern web development, it's a venial sin to put JavaScript code in the onclick event of a button. We usually aim for unobtrusive JavaScript where all the events are wired up in JavaScript and the HTML just does the layout. I think that's a good practice, but for a back button like this, it makes the JavaScript more cluttered to have a tangential concern shoved in there. So take your pick on where you put your onclick event – the button itself or the JavaScript file.

Open the Options view

Now that we've got lovely labels and inputs to show in the Settings pane, we're ready to show it off. Add the following to your default.js file:

app.onsettings = function(e) {
    e.detail.applicationcommands = {
        "options": {title: "Options", href: "/pages/settings/options.html"},
    };
    WinJS.UI.SettingsFlyout.populateSettings(e);
};

This code will listen for the application's onsettings event (the "app" variable here = WinJS.Application) and open the options.html file in the href above. The title is what you want the user to see on the app's Settings pane. Clicking it will open your view where they can change values. The "options" part on the left side is the ID of the div it will look for in the options.html file.

At this point, you should be able to run your app and type Windows + I and see the app's settings pane, then click Options and see your app's options and the options.html input controls. Nothing will be reading or writing any data yet, so let's do that next.

Save and recall user settings for your app

There are three built-in storage areas for your Windows 8 app: local storage, roaming storage, and temporary storage. You can also use SkyDrive, Windows Azure Mobile Services, or your own homemade JSON API that reads and writes to your own database.

For app settings, I think roaming makes the most sense. Users will expect your app to remember their settings across different devices, and that's what roaming provides with no extra work on your part. The real difference between roaming and local you have to consider is, roaming storage is limited to 100k and can't hold binary data. If that won't work for your app, look into local storage, SkyDrive for files or photos, or Azure Mobile Services for structured data.

Here's the options.js file that pulls values from options.html and reads and writes values from the inputs:

(function() {
    "use strict";
var appData = Windows.Storage.ApplicationData.current.roamingSettings;

WinJS.UI.Pages.define(&quot;/pages/settings/options.html&quot;, {
    // This function is called whenever a user navigates to this page. It
    // populates the page elements with the app's data.
    ready: function (element, options) {
        var feetRadio = document.getElementById(&quot;feet&quot;),
            metersRadio = document.getElementById(&quot;meters&quot;),
            refreshIntervalRange = document.getElementById(&quot;refreshInterval&quot;),
            movementThresholdRange = document.getElementById(&quot;movementThreshold&quot;);

        // Set settings to existing values
        if (appData.values.size &gt; 0) {
            if (appData.values[&quot;feetOrMeters&quot;]) {
                setFeetOrMetersValue();
            }
            if (appData.values[&quot;refreshInterval&quot;]) {
                refreshIntervalRange.value = appData.values[&quot;refreshInterval&quot;];
            }
            if (appData.values[&quot;movementThresholdInFeet&quot;]) {
                movementThresholdRange.value = appData.values[&quot;movementThresholdInFeet&quot;];
            }
        }

        // Wire up on change events for settings controls
        feetRadio.onchange = function () {
            appData.values[&quot;feetOrMeters&quot;] = getFeetOrMetersValue();
        };
        metersRadio.onchange = function () {
            appData.values[&quot;feetOrMeters&quot;] = getFeetOrMetersValue();
        };
        refreshIntervalRange.onchange = function() {
            appData.values[&quot;refreshInterval&quot;] = refreshIntervalRange.value;
        };
        movementThresholdRange.onchange = function() {
            appData.values[&quot;movementThresholdInFeet&quot;] = movementThresholdRange.value;
        };
    },

    unload: function() {
        // Respond to navigations away from this page.
    },

    updateLayout: function(element, viewState, lastViewState) {
        // Respond to changes in viewState.
    }
});

function getFeetOrMetersValue() {
    var feetOrMetersRadio = document.getElementsByName(&quot;feetOrMeters&quot;);
    for (var i = 0; i &lt; feetOrMetersRadio.length; i++) {
        if (feetOrMetersRadio[i].checked) {
            return feetOrMetersRadio[i].value;
        }
    }
}

function setFeetOrMetersValue() {
    var feetOrMetersRadio = document.getElementsByName(&quot;feetOrMeters&quot;);
    for (var i = 0; i &lt; feetOrMetersRadio.length; i++) {
        if (feetOrMetersRadio[i].value === appData.values[&quot;feetOrMeters&quot;]) {
            feetOrMetersRadio[i].checked = true;
        }
    }
}

})();

I'm using the Windows.Storage.ApplicationData.current.roamingSettings (shortened to the appData variable) to read and write from roaming settings with the syntax:

appData.values["theKey"] = theValue;

It's a key value store, so if you've worked with cookies in the past, this will seem familiar.

The existing values (if there are any) are pushed into the input controls. Next, the onchange events on the options.html inputs are wired up to write the new values. You may also have other things you have to do in your app when the user changes a setting value, like redraw or hide something, etc.

Push your logic to the core

Thu, 30 Dec 2010 01:40:30 Z

Creeping logic

Developers struggle with where to put their business logic. We all know at an intellectual level that we should be keeping business rules and logic in some kind of a business layer, but I don't see it in practice that often. I do see a lot of business layers that turn around and call data layers. There's often nothing business-y about them.

Instead, the logic is sprinkled throughout the other layers, sometimes to take advantage of a technology, sometimes because of the strengths of the developer who wrote the code.

Validation controls in ASP.NET Web Forms are an example of business logic in the UI layer. Another is an ASP.NET Web Forms code behind event that calculate discounts for preferred customers on Page_Load.

ASP.NET MVC isn't immune from this either, although the validation logic story is better with Data Annotations letting validation rules flow up to the UI. Controller actions can be mistreated just like code-behind and often contain more business logic than they should.

And putting more logic in stored procs doesn't make your app dev teams more agile. It makes the data team the bottleneck for logic changes.

Journey to the Center of the App

A better approach is to lift that logic out of those layers and put it in your business/domain/core layer in C# POCOs. In many apps, this logic is what makes the app worthwhile. Sometimes, it's what gives the company a competitive advantage. It should be clear, expressive, and long lived code. It should not be coupled to any particular technology.

These can be tricky changes to make once an app is partly finished or already up and working in production. There can be a lot of refactoring. But the effort can pay off in making the code more clear to anyone working on it and letting you make complex changes much faster because the logic is centralized and expressive.

How do you do this?

One test I like to use for where the logic goes is, "What if the technology changed?" What if I wasn't able to use Web Forms or MVC, but had to use Silverlight or any other future technology? What if SQL Server went away? What if we switched from stored procs to NHibernate and then again to Entity Framework? If we've got business logic wrapped up in our tools, no matter what the tools are, we can be sure the logic will need to be rewritten when the technology changes.

It's great to take advantage of new tools, but your code needs to keep it's distance where possible. Wrap the tool with an interface or something so the tool is decoupled from your logic, and you can replace the technology if you need to. I've written about this interface wrapping technique before.

Another great technique is using TDD or other test-first approaches because your code will be written with an eye toward how it will be consumed. You'll end up with lots of small classes and methods with expressive names. This outside-in approach to coding really guides you toward creating a clean API for the app's first customer - your test code.

Generated unit tests are a net negative

Tue, 12 Oct 2010 00:40:38 Z

One of the most common misunderstandings for developers new to unit testing is the value of code coverage. We intuitively know that if coverage is low, we don't have enough tests, and if coverage is high, we probably do. Some IT shops even set minimum code coverage percentages, so if you check in code that drops the coverage metric below 80%, you fail the build.

One way to get higher code coverage is to generate the tests. Visual Studio has versions that can do this for you. Point the code at a class, click OK a few times, and all your code in the class under test can be covered. In fact, the generated test usually check for things you might not bother to, like what if there is a negative value passed in to a method, what if a zero passed in, what about a null, etc. How can this be bad? We're exercising the API of our class more fully, right?

What not to test

I think the focus needs to be on testing the right code in the right way. There is no point in testing the .NET framework. If you have a auto property that is an int, you don't need to test -1, 0, 1, and null. If int stops working, everyone using .NET has a bug. But int isn't going to fail, and even if it does, it's not your code anyway (unless you work at Microsoft on the .NET framework team).

So the first rule is be sure you're testing your code. That means testing your methods that do real stuff. If you have a method in your class that just wraps a call to another class, there really isn't anything worth testing. All you can test is that the class can be created and the method can be accessed and has those parameters and they are of that type. But you can do that better by testing the underlying class instead of the pass-through method.

Go faster when refactoring

In fact, testing these properties and pass-through methods and no arg constructors increases your code coverage numbers without adding anything meaningful to the test suite. The net negative comes into play when it's time to refactor, whether it's adding or removing properties, renaming, moving things to different classes, etc. Generated tests can really slow you down here as the new code stops building and the generated tests have to be removed and regenerated.

A better way is to write the tests you need first, then add the code to implement that business rule or feature. Whether you're using TDD, BDD or something else, you'll end up with tests that express the intent of the code rather than its implementation. Tests should emphasize the features of the application, not the coding artifacts. These are the kind of tests that add real value to your project.

MVC 2: Electric Boogaloo - What's new in MVC 2

Mon, 18 Jan 2010 01:41:07 Z

The MVC team loves their rec center, but an evil real estate developer wants to bulldoze it to build a hipster bar named Ruby's. The team has been coding their butts off with MVC 2, but will the new features be enough to save the rec center? Will the cynical real estate developer cackle and complain that it's still not enough?

Will the MVC team get areas right? Will the new templated HtmlHelpers strike the right balance of rapid development and fine control? Will validation concerns get muddled up with UI concerns? Will more web forms developers make the switch to MVC?

New Areas

Areas are an organizing tool for large web sites. If you've got lots of view and lots of controllers plus some shared content, areas can work as a top-level routing mechanism.

Example areas might be Admin for an administrative site, Store for a ecommerce site, etc. They can be either folders or separate web projects. Use the AreaRegistration class to set up your routes in your Global.asax (taken from MSDN article):

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
AreaRegistration.RegisterAllAreas();

routes.MapRoute(
    &quot;Default&quot;,                                              // Route name
    &quot;{controller}/{action}/{id}&quot;,                           // URL with parameters
    new { controller = &quot;Home&quot;, action = &quot;Index&quot;, id = &quot;&quot; }  // Parameter defaults
);

}

Then override AreaRegistration in the area's folder or in the root of the area web project (also taken from MSDN article):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
namespace Store
{
public class Routes : AreaRegistration
{
public override string AreaName
{
get { return "Store"; }
}
    public override void RegisterArea(AreaRegistrationContext context)
    {
        context.MapRoute(
            &quot;Store_Default&quot;,
            &quot;Store/{controller}/{action}/{id}&quot;,
            new { controller = &quot;Products&quot;, action = &quot;List&quot;, id = &quot;&quot; }
        );
    }
}

}

Sharp Architecture has had areas since its first release. I remember hearing rumors about areas coming in MVC for version 1.0, but I guess it wasn't ready. The biggest difference between the Microsoft version and the Sharp Architecture version is that the Microsoft version lets you register different web projects.

Theoretically, multiple teams can work on multiple web projects, then these web projects can be rolled into the same solution and AreaRegistration can make them appear as one big web site to a browser. I don't know how much of a need that is, but I guess if you have distributed teams that can't get to the same source code repository, it might be useful. I prefer multiple folders in one web project over multiple web projects to keep build times down and Visual Studio responsiveness up. I wouldn't break out each logical web site section to its own web project until the folder approach stopped working.

New HtmlHelpers

I'm not sure if Code Camp Server pushed the MVC team into this or just showed how it was possible to take HtmlHelpers to this extreme, but I'm glad to see the same concepts getting rolled into the base class libraries.

I think the new HtmlHelpers do give a nice range of control over your markup. You can use:

<%= Html.LabelFor(x => x.FirstName) %>
<%= Html.EditorFor(x => x.FirstName) %>
<%= Html.LabelFor(x => x.LastName) %>
<%= Html.EditorFor(x => x.LastName) %>

if you want to be fairly explicit for each form element. Or you can save a lot of keystrokes with:

<%= Html.EditorFor(x => x) %>

And if that's not enough, you can decorate your models with some UI hint attributes and roll your own rendering. I think this is something large web projects will take advantage of for consistent markup and control rendering. Seems like this has the advantages of homemade server controls without some of the hassles (INamingContainer, I'm looking at you).

New Validation

I did worry for a little bit about the UI stuff bleeding into the model with these new attributes. Seems like we've got a leaky abstraction there. But these days I think of the MVC model as the view model, not the domain model. The view model is married to the view it works with. It has no other purpose than to represent the data in that view. Well, now it also validates the data in that view, at least initially. Oh, and it now controls some of the view rendering. Damn. That's three responsibilities for my little view model.

But I don't have an alternative proposal to attribute-heavy view models either. I don't want partial classes. I haven't seen much benefit to the buddy class approach. And I do want to reuse some of my UI hints across view models (like a date picker for DateTime types). Plus, I want to take advantage of the new client and server side validation of my view model before it gets into the action method. MVC 2 has this built in.

I guess I'll grin and bear it and work on a new blog post about the Triple Responsibility Principal for View Models (as opposed to SRP). :D

Future

I've already talked about where MVC views are now and where they are going, and the view engine is definitely getting better. I still think views will continue to be the most in-flux part of the MVC framework. I know people that are very happy with Spark as a view engine, and Louis DeJardin, the guy who wrote Spark, is now working for Microsoft on the ASP.NET team. I don't have any inside scoop, but I wouldn't be surprised if the web forms view engine got a little."sparkier".

Views may also be the area with the most room for improvement, depending on who you talk to. When I visit with people about MVC and explain that runat="server" is gone and you can go ahead and close your Visual Studio toolbox, most get a glazed look. They don't want to hand code the HTML. They don't want to see a property sheet that doesn't know anything about their current mouse selection. They don't want to give up their current productivity.

I get that, but I think you can be faster without the designers and toolboxes and property sheets. It takes a while to get used to using the keyboard more than the mouse, but I think it's worth pushing yourself over that learning curve.

Time to switch from Web Forms to MVC?

I push MVC on projects where I have influence on that decision. In your world, it's your call. You may have environment constraints, in-flight projects, etc.

But it also doesn't have to be all or nothing. You don't have to wait for a greenfield project to fall in your lap. You can run MVC inside your current Web Forms project. It's just another set of HttpHandlers living under ASP.NET. Here is some guidance for getting your current project set up to do this.

I encourage you to give it a try and see what you think. It will take a while to get used to the paradigm. It's not hard - just different. But I think once you're used to it, you'll like the separation of concerns, the easier testing, and the more natural flow for web development.

By natural flow, I mean embracing the world of GET and POST. I mean when you need to expose JSON, an RSS feed, or something else (XML, PDF, file, etc.), Controller Actions are ready to go. Stop writing custom HttpHandlers or fighting WCF configuration for this stuff. It should be simpler, and it is with Controller Actions and the right ActionResult.

Make it a goal to get some real-world MVC experience in 2010. Think of the kids on the MVC team and their beloved rec center. Don't let their dream die. They've come too far. And remember the tag line from Breakin' 2 - "If you can't beat the systembreak it!".

Setting default values for Kendo UI and DataTables controls

Mon, 01 Apr 2013 05:57:00 Z

Most JavaScript controls take a JSON object for their settings. Here's how you initialize a Kendo UI grid:

$("#myGrid").kendoGrid({
    pageable: true,
    sortable: { mode: "multiple", allowUnsort: true },
    filterable: true,
    dataSource: {
        data: myData,
        pageSize: 10
    }
});

And here's how you initialize a DataTables grid:

$("#myGrid").dataTable({
    "bSort": true,
    "bAutoWidth": false,
    "bProcessing": true,
    "bJQueryUI": true,
    "bPaginate": true,
    "bServerSide": true,
    "bSortCellsTop": true,
    "sPaginationType": "full_numbers",
    "iDisplayLength": 25,
    "aLengthMenu": [[5, 10, 25, 100], [5, 10, 25, 100]],
    "aaSorting": [],
    "sAjaxSource": "/Api/MyData",
    "sAjaxDataProp": "Data"
});

Both controls take an object literal with all the settings to style how the control looks, works, etc.

But look at all those settings! We have to set all that sorting and paging and filtering every time if we want non-default behavior? And what if we change our mind later and want to use virtual paging instead of page numbers or another application-wide change?

If there was only a way to centralize the common settings and reuse them with each call…

Reuse common settings

Here's a snippet of JavaScript to store common settings for a Kendo UI grid:

var kendoGridDefaults = {
    filterable: {
        pageable: true,
        sortable: { mode: "multiple", allowUnsort: true },
        filterable: true
    },
    nonFilterable: {
        pageable: true,
        sortable: { mode: "multiple", allowUnsort: true },
        filterable: false
    },
    extend: function (defaults, settings) {
        return $.extend(true, {}, this[defaults], settings);
    }
};

And here are some common settings for a DataTables grid:

var dataTableDefaults = {
    serverSide: {
        "bSort": true,
        "bAutoWidth": false,
        "bProcessing": true,
        "bJQueryUI": true,
        "bPaginate": true,
        "bServerSide": true,
        "bSortCellsTop": true,
        "sPaginationType": "full_numbers",
        "iDisplayLength": 25,
        "aLengthMenu": [[5, 10, 25, 100], [5, 10, 25, 100]],
        "aaSorting": []
    },
    extend: function(defaults, settings) {
        return $.extend(true, {}, this[defaults], settings);
    }
};

In both cases, you build up an object literal with with the common settings you want to reuse, then create an "extend" function (or another name, if you like) using the jQuery $.extend function, which merges your default settings with any new settings you pass in.

More than one set of common settings

You will likely have more than one set of reusable settings (server-side grid and client side grid, filterable and non-filterable grids, etc.). Just define new objects in your settings object. Above, I've got "filterable", "nonFilterable", and "serverSide" as property sets.

Usage

To take advantage of the default settings, call your control code and pass in the common settings object, then call the extend function with your overrides and/or additional settings:

$("#myGrid").kendoGrid(kendoGridDefaults.extend("filterable", {
    dataSource: {
        data: myData,
        pageSize: 10
    }
}));
$("#myGrid").dataTable(dataTableDefaults.extend("serverSide", {
"sAjaxSource": "/api/myData",
"sAjaxDataProp": "Data"
}));

This technique isn't limited to grids, or to Kendo UI or DataTables. It can be used with any controls that set their properties with a JavaScript object literal.

Sessionless MVC 3

Fri, 21 Jan 2011 01:40:25 Z

If you've done much ASP.NET development, you know you shouldn't use session for high performance web sites that require web farms and load balancers. You can centralize session to be on one web server or move it to the database, but what if you want to avoid it altogether?

MVC 3 introduces a new controller attribute called SessionStateAttribute. You can decorate your controller with this attribute to disable session, make it read-only, or turn it on for full read-write access. Note that TempData, which uses session to store values between requests, is also disabled if session is disabled. That makes sense, but since it's called TempData[] instead of Session[], it's not obvious.

Here's how you can use this on a controller. Note this attribute is at the controller level, not the action level.

using System.Web.Mvc;
using System.Web.SessionState;
namespace MvcApplication1.Controllers
{
[SessionState(SessionStateBehavior.Disabled)]
public class HomeController : Controller
{
public ActionResult Index()
{
ViewBag.Message = "Welcome to ASP.NET MVC!";
        return View();
    }

    public ActionResult About()
    {
        return View();
    }
}

}

And here's how you can set it as a Global Filter ~~to turn it off for all controllers. The attribute is being set in the RegisterGloablFilters method in the Global.asax and is called in Application_Start.~~

UPDATE: This doesn't work as a global action filter. However, you can turn off session for your whole application with code in your web.config like this:

<system.web> ... <sessionState mode="Off" /> ... </system.web>

Handling Exceptions in ASP.NET MVC

Sun, 23 Aug 2009 09:24:27 Z

Here is a quick run down of the various approaches for handling exceptions. I use a combination of these that I'll show at the end.

Try-Catch everywhere

You've seen this code before, right?

public void DoSomething() { try { var x = 1; } catch (Exception ex) { ShowExceptionToUser(ex.Message); } }

The approach of putting try-catch block around every ounce of code seems like a good idea intuitively. Sure, you're showing the user an ugly error message, but it's better than crashing the server.

But what is the user supposed to do with the information you show them? How are they supposed to fix your null reference exception?

The other knock on this approach is there is so much ceremony code!

Generic error page

This approach goes the other way with a generic error page displayed to the user for any unhandled error. It's easy to implement in the Web.config file, and the user never sees a null reference exception or stack trace.

Here's what I'm using:

<customErrors mode="RemoteOnly" defaultRedirect="~/Error"> <error statusCode="403" redirect="~/Error" /> <error statusCode="404" redirect="~/Error" /> </customErrors>

There are two problems with the generic error page approach. First, the user has no information about what happened. Maybe it's something they could have resolved? Maybe they should try again later? Just saying "Pardon our mess" doesn't give them any details.

Second, it doesn't give you any details either. The next time you talk to the user, they will tell you they got an error in your app. "Oh, what happened?" you'll ask.

"Uh, it was on that screen with the customer info. I forgot what I was doing, but it just showed the error screen, so I rebooted and went home for the day." Not much to go on. Something about the customer screen? This will be a fun one to try to reproduce!

Just log it

The last approach is to log all errors. You collect as much detail as you need. The date and time the exception was thrown, which user/IP address, which server they were on, the stack trace, etc.

Error logging can be extensive and can be stored in rolling text files or database tables. I prefer using the database so I don't need to grant write permissions to the ASP.NET process running that web app.

Here's an Application_Error event from a couple projects back:

protected void Application_Error(object sender, EventArgs e) { var ctx = HttpContext.Current; var ex = ctx.Server.GetLastError(); if (ex != null) { _logService.LogExceptionToDatabase(ex); } }

I've done lots of applications like this, where the Application_Error event in Global.asax calls into a logger like log4net or Enterprise Library to store exception details. It works great. You get the details you need to fix the bug.

But what about the user? What are the users looking at when this exception is thrown?

#3 Combo Platter

Today, I'm using bits and pieces of all of these.

I show the user a generic error page for all unhandled exceptions. It may not have much info, but something weird just happened in the app and I wasn't expecting it. I need more information about what happened so I can decide what needs to be done.

That's why I'm also using ELMAH to log all unhandled exceptions. The exception details get stored in my database and I even get a fancy exception viewer since ELMAH works as an HttpHandler. My favorite ELMAH feature is you can usually see the yellow screen you would have seen if running locally on your box.

Finally, sometimes there are handled exceptions. This is where an exception occurred before in the code (database is down, file not found, etc.), it might occur again, and I've got some thoughts about what to do next time it happens.

In my view, the only place you need try-catch blocks is when you are worried that an exception might happen and you want to give the user some information, give the user instructions, or silently fix the problem yourself. If I can't do one of these, I just show the "Oops" page try to come up with a plan later.

For instance, if the database is down, I'd tell the user to try again later, but I couldn't save their record right now. If the user is trying to upload a file and it's not there, they can try to correct the file upload input box and resubmit.

How to wire this up in ASP.NET MVC

Set up ELMAH

First, download ELMAH binaries, add a reference to the ELMAH assembly in your web project, and follow the instructions to get your Web.config set up correctly.

Now test out ELMAH. You should be able to browse to elmah.axd and see the list of exceptions. Try throwing one in your code somewhere and see if ELMAH logs it.

You can make the elmah.axd page secure, log to a database, etc.

Set up the Generic Error Page

Once ELMAH is logging, wire up your Web.config to show the generic error page:

<customErrors mode="RemoteOnly" defaultRedirect="~/Error"> <error statusCode="403" redirect="~/Error" /> <error statusCode="404" redirect="~/Error" /> </customErrors>

I'm using an Error controller with a single Index action so I can send the user to the root and to the Error route to show the error page. Here's the controller:

public class ErrorController : Controller { public ActionResult Index() { return View("Error"); } }

It's calling a view also called "Error" that is in ~\Views\Shared\Error.aspx. Make your version of that page. Remember, this is the page for unhandled exceptions.

Next, you need to register this route. I've moved my route registration out of my Global.asax, but if you have a default ASP.NET MVC install, look for your routing registrations in Application\_Start:

routes.MapRoute("UnhandledExceptions", "Error", new { controller = "Error", action = "Index" });

This is just setting up some defaults in the route to simplify redirects to the generic error page. At this point, you should be able to browse to any controller with a thrown exception in the action and see your generic error page displayed.

Set up the ElmahHandleError attribute

There's one step left! You've now got two ways of dealing with unhandled exceptions. We need to consolidate these so the generic page is show AND the ELMAH logging is called.

You know how you have to add the HandleError attribute to your controller classes to get the generic error page to appear? This attribute doesn't call ELMAH. This is by design, since the HandleError attribute is, well, handling the error. ELMAH is for unhandled errors and doesn't log otherwise.

But you can have it both ways and use ELMAH as your handled exception logging tool as well. Follow these steps to create an ElmahHandleError attribute and replace the HandleError attribute on your controllers with this new attribute.

That's it! You should be all set with an exception handling strategy.

Combining JavaScript bundling, minification, cache busting, and easier debugging

Mon, 18 Mar 2013 01:12:00 Z

ASP.NET MVC has had server-side bundling and minification for a couple versions now. You can use this to reduce HTTP requests from the client browser to the web server. This optimization is a must when you get lots of small JavaScript files, which is what most large web applications have these days.

Here's the default BundleConfig.cs in an MVC4 default project:

using System.Web; using System.Web.Optimization; namespace BundlingSample { public class BundleConfig { // For more information on Bundling, visit http://go.microsoft.com/fwlink/?LinkId=254725 public static void RegisterBundles(BundleCollection bundles) { bundles.Add(new ScriptBundle("_{/bundles/jquery").Include( "}/Scripts/jquery-.js")); bundles.Add(new ScriptBundle("~/bundles/jqueryui").Include( "~/Scripts/jquery-ui-{version}.js")); bundles.Add(new ScriptBundle("~/bundles/jqueryval").Include( "~/Scripts/jquery.unobtrusive*", "~/Scripts/jquery.validate*")); // Use the development version of Modernizr to develop with and learn from. Then, when you're // ready for production, use the build tool at http://modernizr.com to pick only the tests you need. bundles.Add(new ScriptBundle("~/bundles/modernizr").Include( "~/Scripts/modernizr-*")); bundles.Add(new StyleBundle("~/Content/css").Include("~/Content/site.css")); bundles.Add(new StyleBundle("~/Content/themes/base/css").Include( "~/Content/themes/base/jquery.ui.core.css", "~/Content/themes/base/jquery.ui.resizable.css", "~/Content/themes/base/jquery.ui.selectable.css", "~/Content/themes/base/jquery.ui.accordion.css", "~/Content/themes/base/jquery.ui.autocomplete.css", "~/Content/themes/base/jquery.ui.button.css", "~/Content/themes/base/jquery.ui.dialog.css", "~/Content/themes/base/jquery.ui.slider.css", "~/Content/themes/base/jquery.ui.tabs.css", "~/Content/themes/base/jquery.ui.datepicker.css", "~/Content/themes/base/jquery.ui.progressbar.css", "~/Content/themes/base/jquery.ui.theme.css")); } }
}

This approach works well for 3rd party libraries (jQuery, jQuery validation, knockout, etc.), and it has a cache-busting hash in the URL that keeps you from caching an old version of the bundled and minified script in your browser.

Here you can see jquery and modernizr have a query string after the file name with the unique key:

So we've got bundling of scripts, minification, and cache-busting. What's not to love?

Where do I put my application scripts?

The default MVC project gives you a \Scripts folder. You could put your application scripts there. NuGet would like you to leave 3rd party scripts there, and it's the convention, but I prefer to move scripts I didn't write for the current app into a \Scripts\lib folder, and scripts for the app go in a \Scripts\app folder.

You'll have some moving around to do when you update a JavaScript via NuGet to get it in your preferred folder, but it's a little easier to find the stuff you'll really be working on for your app. You'll also need to update your BundleConfig.cs to point to the new \Scripts\lib folder.

So how to we bundle these app scripts? You could bundle them all in one file. Everything in that folder gets put in a "~/bundles/myApp" bundle. The problem is, you'll likely end up with lots of sequencing problems in the scripts and see "undefined" errors. This could work if you only have a small amount of JavaScript in your app, but it's not recommended.

You could also create a Razor section in the _Layout.cshtml and call it "scripts", then each view can list the scripts it needs to work in that Razor section. The default MVC4 _Layout.cshtml file already has this Razor section set up for you. This approach works, but now we're not bundling or minifying the JavaScript, and we don't have any cache busting going on with our app scripts.

So I have to debug minified files? Yuck.

The other drawback of using the built-in ASP.NET optimizations for bundling and minification is debugging minified files. You've probably dealt with this when your JavaScript throws an exception and you're in the middle of a jQuery file. JQuery almost certainly doesn't have a bug, but you sent it some values it wasn't expecting. Have fun sorting that out.

![[image_thumb_11.png](https://cdn.volaresoftware.com/images/posts/2013/3/image_thumb_11.png)

IE10 and Chrome have JavaScript pretty print tools that can make the minified script a little easier to read than one long line, but the variable names will all still be a, b, c, and whatever the minifier hadn't already used.

Using map files is a better way to go, and in Chrome, you turn this on in dev tools and click the gear at the bottom right, then check "Enable source maps".

Now each minified file can have a map file that points to the original, unminified source code. The built-in ASP.NET optimizations don't work with map files yet.

Web Essentials bundling to the rescue

If you are a Visual Studio web developer and you don't have Web Essentials, go get it now. You'll love it. It's a Visual Studio extension created my Mads Kristensen, who works for Microsoft for the Web Platform and Tools group.

One of the features is bundling and minification. You select the files you want to bundle, right click, then choose Web Essentials > Create JavaScript bundle file.

Name your bundle, and several files will be created. The first is the *.bundle file:

<?xml version="1.0" encoding="utf-8"?> <bundle minify="true" runOnBuild="true">  <file>/Scripts/app/script1.js</file> <file>/Scripts/app/script2.js</file> </bundle>

This file lists each script in the bundle and has flags for minify (default is "true") and runOnBuild (default is "true"). You may need to rearrange the order of the bundle files if there are functions defined in one file and called in another.

Any change you make to script1.js or script2.js, the *.bundle file, or building your app, will regenerate the files underneath the *.bundle file:

These three files are 1) the combined bundle without minification, 2) the bundle with minification, and 3) the map file for debugging the original script. The first is a giant concatenation of the two files and isn't that interesting.

The minified file looks like this:

function add(n,t){return n+t}function subtract(n,t){return n-t}function showMessage(n){alert(n)} //@ sourceMappingURL=myAppBundle.min.js.map

And the map file looks like this:

{ "version":3, "file":"myAppBundle.min.js", "lineCount":1, "mappings":"AAAAA,SAASA,GAAG,CAACC,CAAC,CAAEC,CAAJ,CAAO,CACf,OAAOD,CAAE,CAAEC,CADI,CAInBC,SAASA,QAAQ,CAACF,CAAC,CAAEC,CAAJ,CAAO,CACpB,OAAOD,CAAE,CAAEC,CADS,CCJxBE,SAASA,WAAW,CAACC,CAAD,CAAM,CACtBC,KAAK,CAACD,CAAD,CADiB", "sources":["/Scripts/app/script1.js","/Scripts/app/script2.js"], "names":["add","x","y","subtract","showMessage","msg","alert"] }

So the minified file gives the browser instructions on how to get to the map file, which gives the browser instructions on how to render in unminified, made-for-humans format.

Using the bundles

I create a bundle of app scripts for each view (usually I name it after the view, like register.bundle, login.bundle, etc.) and use the Razor "scripts" section in the _Layout.cshtml file to place those scripts at the bottom of the html, just before the closing tag. The script reference points to the minified file.

@section scripts { <script src="~/Scripts/app/myAppBundle.min.js"></script> }

In Chrome, the end result is this for the minified file:

And this for the mapped file:

This human-readable script can have breakpoints, etc. It looks like the original file, but the browser has not created new HTTP requests to pull down the originals. It's map file magic.

Setting up view-specific bundles seems lighter weight to me than always editing the BundleConfig.cs file, plus you get the mapping files. Now we just need to solve for the cache busting we lost with this approach.

Cache busting

Ever send your product owner to the CI web server to check out a new feature, only to have them tell you they got JavaScript errors on that page? Did you tell them to type CTRL-F5 to force a refresh of the page? If so, you have a caching problem where the browser is caching the file even though it has changed.

Mads has a blog post on cache busting that works well. It's based on getting the last changed date of the file and appending that date in ticks to the path of the request for the script or css. His solution involves having URL rewriting working on IIS.

In my case, I didn't want to mess with URL rewriting, so I went with the somewhat less optimal but simpler solution of using a query string instead. Here's my Razor helper:

using System.IO; using System.Web; using System.Web.Caching; using System.Web.Hosting; namespace BundlingSample.Extensions { public static class StaticFile { public static string Version(string rootRelativePath) { if (HttpRuntime.Cache[rootRelativePath] == null) { var absolutePath = HostingEnvironment.MapPath(rootRelativePath); var lastChangedDateTime = File.GetLastWriteTime(absolutePath); if (rootRelativePath.StartsWith("~")) { rootRelativePath = rootRelativePath.Substring(1); } var versionedUrl = rootRelativePath + "?v=" + lastChangedDateTime.Ticks; HttpRuntime.Cache.Insert(rootRelativePath, versionedUrl, new CacheDependency(absolutePath)); } return HttpRuntime.Cache[rootRelativePath] as string; } }
}

and how it's used in the Razor view:

@section scripts { <script src="@StaticFile.Version("~/Scripts/app/myAppBundle.min.js")"></script> }

and the resulting file name in the browser:

The query string pattern matches the built-in ASP.NET optimization pattern. I say this is sub-optimal because some page speed tools will fuss at you for using query strings. Google PageSpeed says, "Enabling public caching in the HTTP headers for static resources allows the browser to download resources from a nearby proxy server rather than from a remote origin server." I'm not too worried about that, but you'll want to use Mads' URL rewrite approach if you want a better PageSpeed score.

So there you have it. Bundling, minification, debugging, and cache busting when you need it!

Prefiltering a Kendo UI grid with an OData data source

Wed, 22 May 2013 23:28:00 Z

If you're using Kendo UI's grid, you know you can plug it into a Web API OData data source. The nice thing about using an OData end point is you don't have to parse all the possible filter values in your Web API code. You'd have to plan for column names, values, different operators, and'ing and or'ing of values, etc. Instead, with OData, just keep the data IQueryable, mark the method with a [Queryable] attribute, and you're all set.

But what if you want some client-side filtering to start off with? You could hack up the OData URL sent back to Web API, or you could set a filter on the grid's data source (extending the example here).

$(function () { var dataSource = new kendo.data.DataSource({ type: "odata", transport: { read: { url: "/api/Cats", dataType: "json" }, }, schema: { data: function (data) { return data["value"]; }, total: function (data) { return data["odata.count"]; }, model: { fields: { Id: { type: "number" }, Name: { type: "string" }, Color: { type: "string" } } } }, pageSize: 10, serverPaging: true, serverFiltering: true, serverSorting: true, filter: { field: "Color", operator: "eq", value: "black" } }); $("#grid").kendoGrid({ dataSource: dataSource, filterable: true, sortable: true, pageable: true, columns: [ { field: "Id" }, { field: "Name" }, { field: "Color" } ] });
});

See the "filter" setting on the data source? That will tell OData to search for /api/Cats/?<other OData stuff>&$filter=Color eq ‘black' on the URL (you will probably get a + symbol instead of a space from URL encoding). This URL stuff will become part of the query's where clause and filter your data. Since this is just a grid filter, your user can go in and edit it, clear it, etc.

But what if you have more complex filtering needs? What if you have multiple values or "or" logic instead of "and" logic?

filter: { logic: "or", filters: [ { field: "Name", operator: "contains", value: "fluffy" }, { field: "Color", operator: "eq", value: "black" } ] }

This will let you "or" your columns, so you are looking for Names containing "fluffy" or Colors equal to "black". The URL will look like /api/Cats/?<other OData stuff>&$filter=(substringof(‘fluffy',Name) or Color eq ‘black').

What if your filtering needs are more complex than this? What if you have both "and" and "or" logic you want to pass through to filter your OData?

filter: [ { logic: "or", filters: [ { field: "Name", operator: "contains", value: "fluffy" }, { field: "Color", operator: "eq", value: "black" } ] }, { logic: "and", filters: [ { field: "Active", operator: "eq", value: true } ] } ]

The grid's filter property is smart enough to handle more complex JavaScript objects thrown at it, as long as is matches the filter pattern. Take advantage of this to prefilter your grid data so those fancy OData queries don't send down values that aren't helpful for your end users.

Push to AppHarbor on every push to GitHub

Wed, 12 Oct 2011 00:40:07 Z

If you're using GitHub as your shared, online, git repository and you're using AppHarbor for continuous integration and deployment, you really have two git repositories – the GitHub one and the AppHarbor one.

AppHarbor instructions help you set up a remote to this git repository so you can push to it whenever you like, but that means you have two steps on most commits:

git push origin master

to push your code up to your GitHub repo, and:

git push appharbor master

to push your code up to the AppHarbor repo. Because AppHarbor doesn't support SSH yet (only HTTPS is supported now), you also have to enter your password. Not a giant hassle, but what if you could get rid of that last little bit of friction?

GitHub Service Hooks

GitHub Service Hooks run after a push to GitHub, and there is one to fire off your AppHarbor build/test/deploy. It's under your GitHub repo > Admin > Service Hooks.

Once you're there, the instructions are pretty simple.

Go to your application's main page on AppHarbor and find the "Create build URL". Example: https://appharbor.com/application/{application_slug}/build?authorization=

"token" is the value of the "authorization" parameter.

"application_slug" is your application's unique identifier.

If your GitHub repository is private you need to add the "apphb" GitHub user as a collaborator. This enables AppHarbor to download the source code.

Here's where you can find the values for steps 1-3 in AppHarbor:

Step #4 can be skipped if you have a public repo. If you're using private repos, add the "apphb" GitHub user to a GitHub team with "pull" grants.

All done!

Next time you do

git push origin master

your code will be pushed up to GitHub and AppHarbor will grab the latest code from GitHub (not from the AppHarbor repo anymore), build it, test it, and if the tests pass, deploy it. All in one step!

What's New in MVC 2?

Wed, 12 May 2010 04:00:00 Z

Thanks to all the folks who attended the South Colorado .NET User Group Visual Studio 2010 launch on May 6th. We went through a giant buffet of new things in Visual Studio, Entity Framework, SharePoint, Silverlight, and ASP.NET. Slides from my talk on the new features in MVC 2 can be downloaded here.

Big thanks also to Ben Hoelting for putting the event together. I liked the mini code camp format! It was a lot of info, but it was a great survey of most of the new features.

Faster Karma test runs that work in VSTS with Chrome headless browser

Mon, 12 Feb 2018 08:30:00 Z

Karma is a well known framework-agnostic test runner. It's the glue between your JavaScript tests and your test results.

Because Karma doesn't care what test framework, assertion library, or browser you use, configuration can be a bit of a headache. You have to specify everything.

Most examples I've seen use PhantomJS as a headless browser, and it works ok. But on my current project, we have 4,700+ JavaScript tests written with Jasmine. When I run those tests manually through Chrome using the Jasmine stock HTML test runner, the tests run in just over 15 seconds. When I run those same tests from the command line or the build server using Karma and PhantomJS, the tests run in about 1.5 minutes – much slower.

I was looking for something faster that would work well both locally and on the build server, and the new-ish Chrome headless browser sounded promising. After getting it set up and working, the Karma tests with Chrome headless as the browser now run in under 10 seconds. Yay!

Here's a step-by-step to getting it set up with the minimum configuration.

Installation

To install, first make sure you've got Node installed and then run:

npm install karma --save-dev

This installs karma for this project. Then:

npm install karma-cli -g

This installs the karma-cli globally for this computer. Next:

npm install karma-jasmine karma-chrome-launcher jasmine-core --save-dev

This installs common plugins we'll need for this project: karma-jasmine, karma-chrome-launcher and jasmine-core.

Next, we will install Puppeteer, an API for Chrome's headless browser. If you are not running your JavaScript tests on your build server, you can skip this step. I was able to get my local Chrome headless browser running without this, but I needed this installed for my build server, Visual Studio Team Services (VSTS).

npm install puppeteer --save-dev

Once puppeteer is installed for this project, it's time to configure things.

Configuration

You need to specify all the settings for Karma because it doesn't know anything about your project. It's like the opposite of zero-config - it's infinite-config.

Recognizing this, the Karma team came up with a bunch of simple questions to get most of what you need added to your config file. From the command line, run:

karma init karma.conf.js

Pick jasmine for the testing framework, no for RequireJS (unless you need that), Chrome for the browser (we'll adjust this later), and src/**/*.js and tests/**/*-tests.js for the source and test files (unless you prefer a different folder/filename pattern), and yes that we'll let the watcher keep an eye on file changes.

This is what mine looked like:

Next, open package.json in the project root and scripts section if you don't already have one at the top level.

"scripts": { "test": "karma start" },

This addition let's us run the tests from the command line with npm test or karma start. This is very helpful for build servers, like VSTS, which know about Node and npm, but not about Karma. Running npm test as an npm task on VSTS works nicely.

Write a sample test

We won't know if it's working until we write a test and see it fail and then see it pass. Let's do that now.

Add a new file under /tests named sample-tests.js. This file should get picked up by our glob pattern in karma.conf.js. Add this code to it:

describe("Testing Karma with Chrome headless", () => { it("Should work if configuration is correct", () => { expect(false).toBeTruthy(); });
});

You would never write this kind of test for a real project, but we just want to know if we've got everything working. This test should fail. Let's run it and see. From the command line, enter:

karma start

You should see a failing test like this.

You can use CTRL-C to break from the watch if you need to. Change the test so the assert is:

expect(true).toBeTruthy();

and save. As soon as you save the changes in the test file, the watcher should re-run the tests and you should see this.

If you don't have a passing test this point, go back and see if you missed a step or download from the GitHub repository and try running from that code.

Chrome Headless

When the tests run, Karma creates a web server, opens Chrome, and runs the tests using the Chrome browser. You can see it running. But we want the headless Chrome browser for speed and to keep that extra browser out of the way.

Use CTRL-C to cancel the watch Karma is running so we can kick it off again when we've made our changes. Open karma.conf.js and find the browsers section. Change it to:

browsers: ['ChromeHeadless'],

This is the token used to specify the headless (not visible) version of Chrome. There are a lot more browsers you can choose from.

Next, find the singleRun section and change it to:

singleRun: true,

and save. This is needed for your build server, or at least if your build server is VSTS.

Re-run with karma start. You should get similar results, with a passing test, but now it says the browser is HeadlessChrome. Also, the test stops and returns to the command prompt when completed instead of staying in watch mode.

![chrome_headless_thumb.png](https://cdn.volaresoftware.com/images/posts/2018/2/chrome_headless_thumb.png)

I don't really care for the watch running all the time on tests, as I prefer to run my tests manually, so I usually turn

autoWatch: false,

in karma.conf.js. I also don't like a lot of chatter in my test output, so I also set

logLevel: config.LOG_ERROR,

Now when I run the tests, I get just the last line from above. That's more like it!

All the code for this post can be found on GitHub.

SpecFlow isn't just a WatiN Wrapper

Wed, 05 Jan 2011 01:40:28 Z

I have been using SpecFlow with WatiN for about 9 months now. It's a great combination for driving the features you want in a web site and verifying they work as expected. SpecFlow takes care of the BDD framework and application features side, while WatiN drives the browser to verify behavior.

I've gotten used to the the pattern of writing a SpecFlow scenario, then writing the WatiN code in the step definition to open a browser and perform the task or look for the expected HTML. Once you get the hang of the tools and the process, it's a very sustainable workflow for the developer.

But today I ran into something that I couldn't test with WatiN. I wanted to check that an XML sitemap was coming up correctly on a web site. WatiN was able to open the XML document in the browser, but there was no Body tag because the XML is not an HTML document, so WatiN couldn't read the XML. All I needed to do was verify that an expected value was in the XML sitemap. If the value was found, the test would pass.

I spent about 15 minutes trying out different WatiN commands to find the text, but with no Body tag, there was nothing loaded into the WatiN object model, so nothing was working. I also tried looking through the WatiN Elements collection and a few other dead ends, but it was only showing me the previous web page or null.

Finally, the obvious answer occurred to me. I'm looking at an XML document and I want to verify that it has a value in it. I'm in a SpecFlow step definition and I've got the entire .NET framework at my disposal, not just WatiN. Five minutes later, I've got it coded to load and examine an XDocument for the value I needed so the test can pass.

This was a good lesson for me. Being on a development workflow roll is no excuse to not keep your head up for alternative strategies that would better solve your problem. SpecFlow isn't just a wrapper for WatiN calls. It can be used to verify any behavior it can invoke.

Fix for Cisco AnyConnect hanging on Hostscan is waiting for the next scan

Wed, 11 Mar 2020 13:34:00 Z

Welcome Coronavirus work-from-home folks trying to get their Cisco AnyConnect VPN working! I wrote this article about a year and a half ago but have recently refreshed it.

If solution below still works for you, please leave a comment below. Thanks, and happy social distancing! :)

TL;DR

If you use Fiddler to watch network traffic on your computer, it creates personal certificates that interfere with Cisco AnyConnect VPN.

Inside Fiddler, choose Tools > Fiddler Options > HTTPS.

Click the certificate maker. Click "Clear server certificates on Exit.".

You may have to reboot to clear memory, but you should be able to use your VPN normally after that.

Backstory

I use Cisco AnyConnect to connect to a client's VPN. Lately, it started hanging with the status message "Hostscan is waiting for the next scan".

The logs show a loop that lasts a little over 10 minutes where it scans and starts over until it finally gives up.

9:42:46 AM Hostscan state idle 9:42:48 AM Hostscan is waiting for the next scan 9:43:50 AM Hostscan is performing system scan 9:43:51 AM Hostscan is performing software scan 9:43:58 AM Hostscan state idle 9:44:00 AM Hostscan is waiting for the next scan 9:45:03 AM Hostscan is performing system scan 9:45:04 AM Hostscan is performing software scan 9:45:19 AM Hostscan state idle 9:45:22 AM Hostscan is waiting for the next scan 9:46:24 AM Hostscan is performing system scan 9:46:24 AM Hostscan is performing software scan

I read something about removing personal certificates helping with this, but I only have a few personal certificates, and they are my machine name, localhost, local development, and something NVIDIA put on there.

Solution

But then I read something else about personal certificates in IE11. Sure enough, under Tools (or the gear icon) > Internet Options > Content there is a button for Certificates.

After clicking that, I saw something very different from the machine certificates. They were there, plus some other certificates for local development, but there were HUNDREDS like *.somewebsite.com.

I sorted by the name, selected them, and removed them. Then I tried Cisco AnyConnect again, and it finally connected.

The wildcard certificates I saw in the IE11 Internet Options were created by Fiddler, which I use to watch network traffic and inspect web requests and responses. Fiddler acts as a proxy between your computer and your internet connection, and I guess it creates a personal wildcard certificate for every site you visit, or when Dropbox syncs, or your email does a send/receive, etc.

Since I must use Cisco AnyConnect for the VPN and I only use Fiddler sometimes, I removed the wildcard certificates and uninstalled Fiddler and I've been able to connect to the VPN reliably for a week now.

Stop wasting time with enums in C#

Sun, 12 Apr 2020 04:29:00 Z

Enums in C# can make you code easier to read:

private enum Status { Awesome = 1, Cool = 2 }; public void Sample() { var lego = new Lego(); lego.Everything = Status.Awesome; if (lego.PartOfTeam == true) { lego.Everything = Status.Cool; }
}

But enums don't cross in and out of C# easily.

Have you ever tried to save an enum to SQL? It becomes an int and you're right back to, "Wait, what does a Status of 2 mean again?".

It's easy convert the enum to a string before sending it to SQL, but then you have to convert it back to an enum in C# when you read it in, and that code is gross:

public string ConvertEnumToString(Status status) { return status.ToString(); }
public Status ConvertStringToEnum(string status) { return (Status) Enum.Parse(typeof (Status), status); }

What about sending the value down to the client in JSON? Again, by default you get an int that looses the point of having the enum in the first place.

That is, unless you want to add enum converters from Json.NET to your JsonSerializer to turn them into strings:

serializer.Converters.Add(new Newtonsoft.Json.Converters.StringEnumConverter());

That's not so bad. Plus, what's the alternative?

The simplest alternatives are primitive types that convert across all layers, like ints and strings. I prefer strings so I can immediately know what the value represents and code around that (e.g., the Status is "Cool" instead of 2).

"But this is using magic strings, and those are bad." Maybe. But 1) everyone likes magic, and 2) what's the risk?

That you mistype the string? There is type-safety risk, but it's a mild one and only applies to C#. Let's say you're in JavaScript and looking for that status of "Coll" instead of "Cool". That code will fail. How long until you figure that out? You'll have tests and/or run the code yourself and see it doesn't work, right?

Also, if you work with a dynamic language, you know you can type in any nonsense and your compiler won't help you. It's up to you to test it. I see magic strings the same way. Yes, you might make a mistake the compiler doesn't catch, but that's why we test our code.

What about the risk that the value changes in the future. Let's say management decides that statuses of "Awesome" are too strong. They want you to change all occurrences of "Awesome" to "Good" throughout the app. What's the damage here?

Well if you have C# enums, you change Status.Awesome to Status.Good everywhere, then you update you SQL data so old records are correct (only needed if you converted the enum values to strings before storing them), then you update your JavaScript so it doesn't look for or branch on the wrong string (again, only needed if you serialized your C# enums to strings).

If you didn't use enums at all, and just used strings in C#, you would have the same SQL and JavaScript updating to do, but maybe more C# strings to find/replace throughout the project. But I don't think you can reasonably say that's a lot more work. Maybe a few minutes more?

On top of that, what's the risk that enums change in the future like this. It's not zero, but it's really low. Enum values should be immutable and usually represent the type or state of something, so enum values don't change their meanings very often.

So why go to the trouble to store C# values in a special type that SQL and JavaScript can't work with? A magic string is just as easy to read as the enum, and it works up and down the stack.

Here's the original code, but with magic strings instead of enums. I don't think it loses any clarity:

public void Sample() { var lego = new Lego(); lego.Everything = "Awesome"; if (lego.PartOfTeam == true) { lego.Everything = "Cool"; }
}

Concerns with this approach

This post has generated a lot of comments! It's been a good discussion on the tradeoffs of using C# enums. Some people have agreed with me that it is simpler to use magic strings because they work across languages.

Some have worried about database space used storing strings vs. ints. Strings do take up more disk space, but I'd argue we're living in the age of not worrying about that, so take advantage of it. Others have pointed out databases can sort, index, and pull ints faster than strings. If storage costs or milliseconds matter in your situation, you'll need to factor that in.

Others have agreed with the point that enum conversions can be messy, but think I've gone too far with magic strings everywhere. The consensus with this crowd seems to be maybe skip enums, but at least use C# static classes. I like this, and that's what I'm doing these days:

public static class Status { public const string Awesome = "Awesome"; public const string Cool = "Cool"; } lego.Everything = Status.Awesome;

Still others want their C# enums just like they are and don't mind converting in JavaScript and SQL if needed.

It's up to you to decide what makes the most sense for your project.

Using CRM auto filtering in custom reports with complex SQL

Mon, 14 Feb 2011 01:40:20 Z

Report prefiltering in Microsoft CRM 4.0 is a very cool feature - when it works. The normal ways of setting up this auto filtering feature in your custom CRM reports are 1) special aliases, and 2) SQL strings.

Special aliases

The alias approach is the simplest one to use. If you have a report that needs prefiltering, change your SQL from this:

select firstname, lastname from FilteredContact

to this:

select firstname, lastname from FilteredContact AS CRMAF_FilteredContact

The trick is the alias. All you need to do is add an alias with CRMAF\_ in front of the view name, and CRM will rip out your SQL at report runtime and replace it with a custom SQL statement. I think the acronym must stand for CRM Auto Filter. By using a special alias CRM recognizes, the actual SQL run on your server will be similar to this, where contacts are prefiltered for city = 'Denver'.

select firstname, lastname from (select contact0.* from FilteredContact as contact0 where address1_city = 'Denver') AS CRMAF_FilteredContact

SQL strings

The other route you can go is mash together SQL strings and get a parameter from CRM that is the prefilter SQL statement. You've probably done this kind of this kind of thing before:

declare @sqlstring varchar(max) set @sqlstring = 'select firstname, lastname from (' + @CRM_FilteredContact + ') AS MyFilteredContacts ' exec (@sqlstring)

This really isn't bad when you have a small SQL statement, but you probably wouldn't need to create a custom CRM report if it was a simple SQL statement, right? The CRM users could create their own simple report inside CRM for that.

When the SQL statement gets complex, you have quote and string bugs. When the SQL gets lengthy, you can't have over a certain number of characters in the SQL string or you have to split it and you end up with:

exec (@sqlstring1 + @sqlstring2 + @sqlstring3)

You can get it to work, but it's pretty yucky.

The problem

I much prefer the alias approach. It's much easier to read, and the aliases are not too much trouble to add in and get prefiltering in CRM for free.

The problem is, the alias technique breaks down when the queries get more complex or you need multiple datasets in your report using the same prefiltering. Here are the cases I've found and the workarounds.

Dataset based on a union query

If you have a query with a union statement, like:

select firstname, lastname from FilteredContact AS CRMAF_FilteredContact where address1_city = 'Denver' union select firstname, lastname from FilteredContact AS CRMAF_FilteredContact where address1_city = 'Highlands Ranch'

CRM will do the alias filtering trick, but only for the first select. The second select in this query will not be filtered at all.

The fix I've come up with uses SQL temp tables. Maybe not the best approach, but I had a lot of reports that were not auto filtering as expected, and this has worked so far:

select * into #FilteredContact from FilteredContact AS CRMAF_FilteredContact select firstname, lastname from #FilteredContact where address1_city = 'Denver' union select firstname, lastname from #FilteredContact where address1_city = 'Highlands Ranch'
drop table #FilteredContact

This let's CRM do what it wants to, and swaps out your SQL where it finds the CRMAF\_FilteredContact alias the first time. It also let's you leave the rest of your SQL pretty much intact.

Dataset based on multiple queries selecting into a temp table

I had another query that was suffering the same problem, but this query was a little different. I needed the data displayed in columns, so I created a temp table and populated it with selects. There were multiple selects in the query filling up the columns in this temp table. Everything ran great without auto filtering.

But with auto filtering, the same thing happened. The first select statement got filtered. The ones after that were untouched. The fix I used was the same. I created a temp table, populated it with the auto filtered data, then selected off that temp table throughout.

To be a good TempDB citizen, I dropped the temp table at the end of the query. SQL Server does the temp table drop for you when the table is out of scope, but it helps to have the drop statement in there when testing the query in SQL Server Management Studio and running it multiple times in the same query window.

Reports with multiple datasets

This technique works if you have a complex query that needs auto filtering. But what if you have multiple datasets in your report, and they all need to be auto filtered?

In one report, the queries were very similar. I had two datasets that were identical expect one used report parameter A and one used report parameter B. This was to compare two funnels for two different time periods. Auto filtering worked fine on the first dataset and funnel, but didn't do anything on the second dataset or funnel.

The fix in this case was to create one dataset that didn't filter on either report parameter A or parameter B. Then in the report, have the funnel controls themselves do the filtering based on the report parameters. Most SQL Server Reporting Services data controls have a filter property. I've never really used them before now, since it almost never makes sense to pull all the data from the database and then filter inside the report. I'd rather filter on the database first. However, in this case, the control filters helped and I got the result I wanted because there was one dataset with one CRMAF\_ alias.

On another report, there were three charts built using three different datasets. The datasets were the same except for the group by clause. I was able to use the same approach and condense these to one dataset with no group by clause, then do the grouping in the chart controls. Again, it made me feel a little bad that the data wasn't already summed and grouped when it got to the chart control, but at least it was working.

REST-like behavior with MVC instead of WCF

Mon, 08 Mar 2010 01:40:57 Z

WCF is a very cool framework for adding an abstraction layer over your services. You can have .asmx, .svc, and now, REST URLs with no extension. These endpoints can even return JSON to the caller, which is useful if you're using jQuery or another JavaScript library.

The knock on WCF? The configuration story! It's getting better in WCF 4, which is scheduled for release in a month or so. It will have a bunch of defaults so you don't have to be as explicit in your config file. Finally, some convention over configuration in the WCF space! Now someone needs to create a fluent, code-based configuration tool for the exceptions to the default conventions…

Don't be afraid of JSON!

But if you need to return JSON to a caller today, you don't need scary WCF config files to do it. You can get the same URL and the same data payload with a lot less hassle using MVC controller actions.

The steps are:

Create a new action in a controller.

Grab your data or whatever you want to return.

Parse your data to JSON.

Throw it back out to the requestor.

The trick is to use JsonResult as the return type for your controller action and convert your output to a JSON string with the base controller's Json method:

public JsonResult GetAllDepartments() { var departments = _repository.GetAllDepartments(); return Json(departments); }

Now if I browse to this controller action (I'm using the HomeController in this example):

<u>http://localhost/Home/GetAllDepartments</u>

I get a pop-up to save the response stream, which I can open with Notepad:

[{"Name":"Human Resources"},{"Name":"Accounting"},{"Name":"IT"},{"Name":"Pencil Sharpening"}]

Yeah, JSON! And there was no gory config setup needed!

Using jQuery with JSON

Now we can use jQuery in the MVC view to take advantage of this returned JSON.

Here's a view that has a button and a div tag. jQuery is being used to tie the button click to a call to the controller and action we set up above. It then gets the JSON coming back, loops through it, and puts it in the div tag so it's visible to the user.

<script src="../../Scripts/jquery-1.3.2.min.js" type="text/javascript"></script> <script type="text/javascript"> $(function() { $("#btnShowDepartments").click(function() { $.getJSON("/Home/GetAllDepartments", null, function(data) { for (item in data) { var department = data[item]; $("#divDepartments").append(department.Name, ", "); } }); }); }); </script>
<p> <input id="btnShowDepartments" type="button" value="Show Departments" /> <div id="divDepartments"></div> </p>

This is probably not the best jQuery in the world. I'm still new to it. But the point is to show that you can put a URL in, parse the JSON, and use the data however your app needs it.

Is ASP.NET relevant to modern web development?

Mon, 29 Dec 2014 05:04:00 Z

ASP.NET has a new version coming out soon. ASP.NET vNext will have a new project file management system (long overdue) and a lot of integration points with modern front-end web development tooling, like Grunt and Bower.

I'm a web developer, and all of the back-end systems I work with are Microsoft based (ASP.NET MVC and Web API, SQL Server, Azure, etc.). I must be super excited about this new stuff coming soon, right?

Nah, not really.

Like most web developers, I spend a lot of time in HTML5 and CSS3 and tons of time in JavaScript. I spend most of my energy getting front-end libraries to work together, making web pages responsive, dealing with cross-browser and cross-device issues, and debugging with browser tools. Over the last several years, MVC, Web API, and even SQL Server have been less a part of my day-to-day coding, so changes and new versions matter less to me.

Just another back end?

If you are a front-end web developer, you need your AJAX request to hit a back-end endpoint and give you a response. That kind of framing of the back-end, that it can be encapsulated or black-boxed, also means its implementation could be changed and you wouldn't really care. Why should it matter if the back end is written with node.js, Ruby on Rails, Java, Azure Mobile Services, or ASP.NET? From the front-end web developer perspective, I just want a response. Obviously, it needs to be fast, scalable, robust, secure, and that kind of thing, but all major server-side frameworks have that figured out.

It seems to me that back-end tooling is becoming a commodity. Here's what I mean. Quick - which cloud provider is the best one? I don't know. Aren't they all about the same? Maybe they have different SLAs, or broader or narrower service offerings, but just to get a web app running with a database, they are all about the same. If one was $5/month cheaper, wouldn't you switch to them? Unless the support or extra services or the hassle of changing cloud providers were worth an extra $5/month to you, you'd switch.

I think of ASP.NET and SQL Server the same way. It's back-end tooling. It involves maybe 10-25% of my coding week. I'm not dissatisfied with the tools. I just don't use them that much. I guess they could get a little better, but that won't make me need to use them more or care more about how they are implemented.

I don't send view models down with my MVC views anymore. I just let MVC serve up a view-model-less view and let JavaScript and AJAX calls go get anything else the page needs. This means the initial page loads fast, but it doesn't fully work until the JavaScript has finished putting everything in its place.

Once you start spending a lot of time in JavaScript and pulling in data with AJAX, and you have to write it that way so the user can interact with the page, then why write it twice with 1) the Razor-template-populated-with-initial-view-model way, and 2) the HTML-template-populated-with-AJAX-data way? Writing the same functionality with two templating languages and two data sources isn't going to get your project done faster or reduce maintenance costs.

Plus, the user gets to see most of the page, just maybe without all the data yet or with empty drop downs while the data is still on its way to the page. I think that gives the user a sense that we're getting you the parts of the page as soon as we can, instead of building everything up on the server as one big ball of templated data while you look at a white, empty browser window.

So why not just dump the whole thing and code HTML, CSS, and JavaScript with any old text editor?

Where does the Microsoft ecosystem add value in modern web development?

IDE

In spite of its limitations for front-end development, Visual Studio is still a very good IDE. Different colors for keywords and navigation within and across files is very good. But most of the value I get from continuing to use Visual Studio is a result of the Web Essentials extension. It's nice to run JSHint with every save and to get pointers in the IDE about CSS rules, potential browser issues, and unclosed HTML tags. If I switched to Notepad, I'd be giving up some things that really do make my coding day a little brighter.

Working with the current Visual Studio project system has been more than just an annoyance; it's been a source of real pain. Looks like the new project/file system may help in vNext.

I can't say that Intellisense is very useful to me these days. It's never really worked right with JavaScript. Maybe that will get a little better, but I've gotten used to it pulling up every JavaScript symbol when I type ".".

Local Web Server

Simple and unobtrusive, IIS Express is a great place to test run your web app, and the integration with Visual Studio is limited but sufficient.

The alternative would be HTML files that you double click to open and debug in the browser. It would work, but you'd have to keep you file system and text editor open all the time, and you wouldn't have server-side debugging of your API layer.

Security

Security is probably the main thing that has kept me from dumping ASP.NET and using HTML files instead. I've never worked on a web app where security wasn't important. You need a way to know who's knocking on the server's door, and when that request is bouncing around on the back-end servers, you need to know what group/role that user is in so you can turn features on and off.

I still use MVC and Web API for their security, and I'm glad their namespaces are finally going to be merged in vNext. That means I won't have any more code that filters MVC requests one way and Web API requests another way.

API layer

Web API is totally relevant for modern web development. All web apps need a way of interacting with a back end, and Web API sets up as a simple, thin transport layer so you can do whatever back-end stuff you need to do on the server. Content negotiation is nice if you have a public API, but I've only written internal APIs that send/receive JSON.

Conclusion

I guess I am looking forward to some of the improvements in ASP.NET vNext.

If I was building a new web app today, would I use ASP.NET as the back end? Probably, but it would be the same way I've used it the last 4-5 years: minimal MVC page serving, an API service layer, and a security layer.

The most interesting, highest customer value web development stuff is happening on the front end, and I don't see that changing anytime soon.

Working with the latest JavaScript syntax on your project today

Tue, 03 Apr 2018 05:17:00 Z

Are you working in an existing code base with tons of ES5 JavaScript, and you're jealous of your friends working on greenfield projects using ES6/ES7/ES8+ or ES2015/ES2016/ES2017+ JavaScript? Here's how we moved our code base forward to start using newer features of JavaScript without losing our minds.

I've made a sample project using the ASP.NET MVC default project (and removing some of the noise). You can see all the code if you want to follow along or fork this on GitHub.

Install NPM packages

First, install node and npm, then install webpack and Babel from the command line in the web project root.

npm install --save-dev babel-core babel-loader babel-preset-env npm install --save-dev webpack webpack-cli

When you are done, you should have a devDependencies section in your package.json file, also in the web root, that looks something like this. You will almost certainly have different versions, and you will probably have more than just this in your devDependencies section, and that's fine.

"devDependencies": { "babel-core": "^6.26.0", "babel-loader": "^7.1.4", "babel-preset-env": "^1.6.1", "webpack": "^4.4.1", "webpack-cli": "^2.0.13" }

Set up Visual Studio

The plan is to leave old JavaScript files with the *.js extension and create new ES2015+ JavaScript files with the *.es6 extension. You can use *.es2015 or any other extension not already in use if you prefer. We just need some file marker so webpack knows which files need Babel transpilation and which don't.

In Visual Studio, you'll need to set up this new extension to use the JavaScript editor. You can do that in Tools > Options > Text Editor > File Extension. If you skip this step, Visual Studio will treat *.es6 like text files instead of JavaScript files.

Configure webpack and Babel

Let's set up the webpack.config.js file in the web root to work with the newer JavaScript syntax.

Below, the resolve section tells webpack we are using these two extensions for JavaScript files, and webpack should be looking for both *.js and *.es6 files when making bundles.

The rules section tells webpack that it needs to use Babel to load *.es6 extension files. There are a lot more Babel options you can add here. For example, want to use async/await in your *.es6 files? Add a Babel plugin for syntax-async-functions.

The isRelease flag is used to toggle between development and production settings for the build. This is using webpack 4's new mode setting, which should set up most things correctly. The devtool option uses either a quick and dirty source map or a more production-ready one.

const path = require("path");
module.exports = env => { const isRelease = env === "RELEASE"; return { mode: isRelease ? "production" : "development", devtool: isRelease ? "source-map" : "cheap-module-source-map", entry: { index: "index.es6", about: "about.js" }, output: { filename: "[name].js", path: path.resolve(__dirname, "dist"), publicPath: "/dist" }, resolve: { extensions: [".js", ".es6"], modules: ["Scripts", "node_modules"] }, module: { rules: [ { test: /.es6$/, exclude: /(node_modules)/, use: { loader: "babel-loader", options: { presets: ["env"] } } } ] } }; };

Single-Page vs. Multi-Page applications

In the entry section above, I've got two values for the two pages in this sample. index will be built using the index.es6 file as an entry point, and about will be built using about.js as the entry point. If your whole app is a SPA, you will have just one entry. If you have a multi-page application, you'll need an entry for each page. Webpack crawls the entry to bundle up all the dependencies.

We are outputting our files to a /dist folder. For simplicity, the file name will be the entry name plus ".js".

Scripts

We needs some scripts to test out the different JavaScript syntax styles.

Here is index.es6, using the new JavaScript import and templated string options.

import $ from "jquery";
$("#setInCode").text(This value was set in code using jQuery at ${new Date().toLocaleString()}.);

And here is about.js, using older AMD-style modules and ES5 style JavaScript.

define(["jquery"], function($) { $("#setInCode").text("This value was set in code using jQuery at " + new Date().toLocaleString() + "."); });

These scripts both find an element with jQuery and set some text to it and add the date/time. We want something simple to test if our pages are working with both old and new-style JavaScript.

Script references

Since I'm using a boilerplate ASP.NET MVC project template, the _Layout.cshtml file already has:

@RenderSection("scripts", required: false)

Each page, such as Index.cshtml and About.cshtml will then reference the built-by-webpack scripts in the /dist folder with. Index.cshtml will reference /dist/index.js, and About.cshtml will reference /dist/about.js like this.

@section scripts { <script src="/dist/index.js"></script> }

Build it

So we've got our npm packages installed, the webpack.config.js file is set up, our pages call our webpack-built scripts in the/dist folder . Let's run it and test it out.

Add a new section for scripts to your package.json file:

"scripts": { "build": "webpack --colors --watch", "build:release": "webpack --colors --env RELEASE" },

This allows us to run npm build and npm build:release as shortcuts for running webpack commands. You can name the commands anything you like.

The options show colors in the console, and for the build script, it sets up a watch on the files to re-run the build if anything changes. You'll want to use this for development. For the build:release script, we pass in —env RELEASE so the webpack.config.js script knows we want the build optimized for production.

You can also add another section to package.json to link up these build commands to the Visual Studio Task Runner Explorer.

"-vs-binding": { "ProjectOpened": [ "build" ] },

This will run your new build command when the project opens. Since it keeps a watch running, that should be all you need to development.

For production, you'll want to stop the build task and manually run the build:release task in the Task Runner Explorer (or run it from command line, or as a before/after build script for your ASP.NET project, or on your build server…).

Run it

Run the web app after the build command completes and you should be able to browse to the Index and About pages and see the jQuery execute in both pages the same way, even though the syntax for importing jQuery was very different for each page.

Debug it

Note we are referencing index.js in Index.cshtml and not the source code file name index.es6. That's because we're not referencing the source code. We're referencing the webpack built code in the /dist folder.

Don't worry. You can still set breakpoints and watches and debug with your favorite browser dev tools when referencing the built code through source maps. When opening a file, look for the one served by webpack://. It will be the original source code seen through the source map. The other file will be the bundled/minified one.

Now what?

If you are on a project that isn't using the newer JavaScript syntax and features, talk with your team. Chances are good they would like to be using the new stuff, too.

You don't need to wait until you get put on a new project. You can start coding with the latest JavaScript syntax today, but still keep backward compatibility for your project's ES5 script.

Deploying Reports Built with SSRS 2008 R2 to SSRS 2008 non-R2

Mon, 19 Mar 2012 00:40:02 Z

I've got SQL Server 2008 R2 Express installed on my primary development machine, and I create SSRS reports on this box. The problem is, I've got one customer with SQL Server 2008. And yes, Microsoft changed the RDL file format between SSRS 2008 and SSRS 2008 R2, so SSRS 2008 can't read SSRS 2008 R2 RDL files.

So how you you get around this without setting up VMs with both? It's not elegant, but here's what I do:

On your SSRS project properties with all your reports, change the Target Server Version to SQL Server 2008 (and not SQL Server 2008 R2).

Get your local dev box SSRS R2 server running if it's not already.

Deploy the report project to your local SSRS R2 server.

Go to your report management site (usually http://localhost:Reports) and download the report. This will save out the RDL for you.

Now when you deploy this report to the non-R2 SSRS server, it will be the correct, non-R2 format!

The crucial steps are setting that Target Server Version and deploying. That's where the Visual Studio report project converts the RDL file to the format you need it to be. After that, the downloading is just a way to get a copy of the report in the non-R2 format.

Now you can deploy the RDL to the customer's non-R2 SSRS server, without changing your dev box.

Moving a VM to another machine

Tue, 17 Nov 2009 01:41:16 Z

I've got a work laptop with a VMware virtual machine. But I wanted to move it to my slightly faster personal rig, with the nicer keyboard, mouse, dual monitors, etc.

So I shut down the VM on the work laptop and copied it over to the personal machine. Then I downloaded and installed the VMware Player to the new machine, copied the VM to it, and opened it up. I got a prompt asking if I "moved" or "copied" the VM. I chose "copied".

The VM spun for a little while, and then there was some gibberish message about VT being possible but disabled on the host. VT = Vermont? VT = Virginia Tech? VT = WTF? I did what professional developers are trained to do in these situations. I ignored it and clicked OK.

The VM said "Windows in Loading Files." but it kept rebooting over, and over, and over.

I got a tip from David Yack to check the BIOS settings. I have a Dell Latitude, so your mileage may vary here, but in my BIOS settings, I go to Post Behavior, then Virtualization, then set it to Enabled, then save settings and reboot.

That worked!

A quick look at NDepend

Tue, 04 Sep 2018 04:00:00 Z

NDepend is a Visual Studio extension designed to help you improve your code quality and reduce your technical debt. It sells for €399 per developer, which is about $462 U.S.

I gave it a try a very small project and a very large project. You open your project in Visual Studio, point NDepend at it, and wait a minute or so for the reports.

NDepend spits out a lot of reports and a lot of metrics, from dependency graphs to tree maps with hot spots showing too much cyclomatic complexity in red.

Here are the small project application metrics:

NDepend gives some basic counts and rule and quality checks, but the most interesting data is the technical debt. Here, both apps get an "A", but they have 3.69% and 4.81% tech debt. This didn't print out as nicely on my projects as the demo report from NDepend shown below.

Here you can see the estimated time to bring your tech debt up a letter grade, from a C to a B, is 14 days and 2 hours. The estimated annual interest on your tech debt is 47 days, and that's up 17 days and 4 hours from the last time the analysis was run.

When you drill into the errors and warnings NDepend shows you, you can also see the cost of fixing or leaving that tech debt. Here is one of the rules I broke in my project with a class that has too many methods (48!). In this case, it's a test class, so I'm not worried about it. Neither is NDepend, since it estimates this tech debt will cost me 4 minutes and 13 seconds a year.

If you want to tackle your tech debt but don't know where to start, NDepend can help you asses where your project is today, show your progress, and help you decide which tech debt is most costly and needs to be addressed soonest.

Adding and styling dynamic content in jQuery Mobile pages

Wed, 11 Jan 2012 01:39:56 Z

jQuery Mobile does great job styling your web app to look kind of like a native phone app.

It injects lots of classes like "ui-link", "ui-content", "ui-listview", "ui-shadow", etc. to make your page look pretty.

But if you're using jQuery to dynamically load content from another source on document ready, jQuery Mobile is already done with its styling changes. I searched and found lots of suggestions for refreshing the styles in the new section of the page, but .page(), .page("refresh"), and .trigger("enhance") didn't add the styles. You can see people struggling with this question.

I finally found the answer in this blog post:

$(function () { $("#dynamicSection").load("/api/dynamicContent", function () { $(this).trigger("create"); }); })

Using Kendo UI grid with Web API and OData

Tue, 19 Feb 2013 13:48:00 Z

The Kendo UI grid is a snazzy little thing:

The grid works natively with OData, but the examples from the Kendo team are of OData services driven by WCF back ends. I wanted to get the grid working with Web API and minimal coding to implement server-side sorting, filtering, and paging.

Until earlier this week, if you wanted to do that, you were on your own. There was a partial OData implementation in Web API via a NuGet package, but it didn't support $inlinecount, which is what the grid needs to know how many items there are total (e.g., the $inlinecount for the grid above is 830).

A more fully supported Web API OData implementation was rolled out this week and is available via NuGet. Here are the steps to get it working with a Kendo UI grid.

Server side

Open your existing Web API project and install the Web API OData NuGet update:

Decide what data you want to send to the browser and model it. I've got a Cat entity and a Dog entity:

namespace KendoGridWebApiOdata.Models { public class Cat { public int Id { get; set; } public string Name { get; set; } public string Color { get; set; } } }
namespace KendoGridWebApiOdata.Models { public class Dog { public int Id { get; set; } public string Name { get; set; } public string Color { get; set; } } }

Update your WebApiConfig.Register() method (in the App\_Start folder):

using System.Web.Http; using System.Web.Http.OData.Builder; using KendoGridWebApiOdata.Models; namespace KendoGridWebApiOdata.App_Start { public static class WebApiConfig { public static void Register(HttpConfiguration config) { var modelBuilder = new ODataConventionModelBuilder(); modelBuilder.EntitySet<Cat>("Cats"); modelBuilder.EntitySet<Dog>("Dogs"); var model = modelBuilder.GetEdmModel(); config.Routes.MapODataRoute( routeName: "OData", routePrefix: "api", model: model ); config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); // Uncomment the following line of code to enable query support for actions with an IQueryable or IQueryable<T> return type. // To avoid processing unexpected or malicious queries, use the validation settings on QueryableAttribute to validate incoming queries. // For more information, visit http://go.microsoft.com/fwlink/?LinkId=279712. config.EnableQuerySupport(); // To disable tracing in your application, please comment out or remove the following line of code // For more information, refer to: http://www.asp.net/web-api config.EnableSystemDiagnosticsTracing(); } }
}

You'll define the OData models you want to expose and set up special OData routes for them. You can add multiple EntitySets to the model builder as needed for your OData endpoints. Here, I'm adding Cat and Dog to the model builder.

The MapODataRoute uses the model builder values to create an OData route. Note this is not exactly a Web API route, but you can use the same /api/{controller} convention if you like (or /odata/{controller} if you prefer) by setting the routePrefix to whatever you like.

I tried toggling config.EnableQuerySupport on and off, and it worked in both cases, so I don't know if that matters any more after the Web API OData update.

For more details about what is going on here, check out Youssef Moussaoui's blog post.

Finally, you'll need a controller, but this isn't a Web API controller, it's an ODataContoller. That's kinda close, and it inherits from the Web API controller, but it's specifically designed for the OData calls you just set up in routing.

using System.Linq; using System.Web.Http; using System.Web.Http.OData; using FizzWare.NBuilder; using KendoGridWebApiOdata.Models; namespace KendoGridWebApiOdata.Controllers { public class CatsController : ODataController { [Queryable] public IQueryable<Cat> Get() { return BuildTestData(); } private IQueryable<Cat> BuildTestData() { return Builder<Cat> .CreateListOfSize(100) .Build() .AsQueryable(); } }
}

Here, I've got a CatsController inheriting from the ODataController. I also have a [Queryable] attribute over the Get() action method. This is another piece you supposedly need, and this was used in the older version of the Web API OData NuGet package, but I found my grid worked whether the attribute was on there or not. You will likely want to leave it as a place to lock down incoming requests, since this is where you can disallow certain query parameters, limit records returned, etc.

The BuildTestData() method is using NBuilder to crank out 100 Cat entities and pretend like it's queryable.

Test it out

That should do it for the server side. Let's test the route setup and see if we get data back. I like using the Chrome plugin Advanced REST Client, but since we're testing GET requests, you can also just type the URL in your browser.

For the URL /api/Cats, the JSON coming back looks like:

{ "odata.metadata": "http://localhost:56126/api/$metadata#Cats", "value": [ { "Id": 1, "Name": "Name1", "Color": "Color1" }, { "Id": 2, "Name": "Name2", "Color": "Color2" }, ...]}

To add some OData parameters to the URL, let's try /api/Cats?$inlinecount=allpages. Now the JSON has odata.count for the $inlinecount value:

{ "odata.metadata": "http://localhost:56126/api/$metadata#Cats", "odata.count": "100", "value": [ { "Id": 1, "Name": "Name1", "Color": "Color1" }, { "Id": 2, "Name": "Name2", "Color": "Color2" }, ...]}

See how the records are coming across in the value array? We'll need that and the odata.count to help the grid know how to parse this JSON.

Client side

The HTML for the grid is minimal:

<div id="grid"></div>

And the JavaScript isn't bad:

$(function () { var dataSource = new kendo.data.DataSource({ type: "odata", transport: { read: { url: "/api/Cats", dataType: "json" }, }, schema: { data: function (data) { return data["value"]; }, total: function (data) { return data["odata.count"]; }, model: { fields: { Id: { type: "number" }, Name: { type: "string" }, Color: { type: "string" } } } }, pageSize: 10, serverPaging: true, serverFiltering: true, serverSorting: true }); $("#grid").kendoGrid({ dataSource: dataSource, filterable: true, sortable: true, pageable: true, columns: [ { field: "Id" }, { field: "Name" }, { field: "Color" } ] });
});

In the dataSource variable, we're setting the type as odata. Seems like that would be enough, but you have to also set the read transport's dataType to "json" or your request will go to the server like /api/Cats?$callback=jQuery183021786115039139986_1361332885733&$inlinecount=allpages&$format=json&$top=10. This is a JSONP request. We want the $callback and $format parameters to go away, and setting the dataType to "json" does that and sets the request's Accept headers to "application/json".

There is also some extra stuff going on in the schema section. Normally, this is where you tell Kendo UI what your data types are so it can sort and filter correctly. Here, we've added data and total to pull the values out of the JSON response so the grid needs can render correctly. The data function is returning the value from the JSON we saw above, and the total function is returning the odata.count.

The rest of the dataSource properties are to force things to be done server side and to set the page size. The remainder of the JavaScript is firing up the grid with this dataSource and setting properties of the grid.

When you run this, you get a Kendo UI grid working with server-side OData. In this case, only 10 records are sent per request instead of the 100 Cat records we created on the server. The OData handling works with sorting, filtering, and paging on the grid.

If you get it running on your machine, check the XHRs to see the OData query string parameters getting added to the request and the response coming back with just the records requested.

Other nifty things

You can hit a URL to get the schemas of the entities you can query with /api/$metadata. You'll get back some XML like this:

<?xml version="1.0" encoding="utf-8" ?> <edmx:Edmx Version="1.0"> <edmx:DataServices m:DataServiceVersion="3.0" m:MaxDataServiceVersion="3.0"> <Schema Namespace="KendoGridWebApiOdata.Models"> <EntityType Name="Cat"> <Key> <PropertyRef Name="Id" /> </Key> <Property Name="Id" Type="Edm.Int32" Nullable="false" /> <Property Name="Name" Type="Edm.String" /> <Property Name="Color" Type="Edm.String" /> </EntityType> <EntityType Name="Dog"> <Key> <PropertyRef Name="Id" /> </Key> <Property Name="Id" Type="Edm.Int32" Nullable="false" /> <Property Name="Name" Type="Edm.String" /> <Property Name="Color" Type="Edm.String" /> </EntityType> </Schema> <Schema Namespace="Default"> <EntityContainer Name="Container" m:IsDefaultEntityContainer="true"> <EntitySet Name="Cats" EntityType="KendoGridWebApiOdata.Models.Cat" /> <EntitySet Name="Dogs" EntityType="KendoGridWebApiOdata.Models.Dog" /> </EntityContainer> </Schema> </edmx:DataServices> </edmx:Edmx>

If you are worried about exposing your data online, read up on OData Security Guidance.

Limitations

URLs are case sensitive. If you browse to /api/Cats, you get data. If you browse to /api/cats (lower case C), you get a 406 error.

Kendo UI grid allows sorting by more than one column, but the current Web API OData implementation doesn't seem to support it.

Download

You can download the code for this project from GitHub.

Convert callback JavaScript to async/await

Sun, 09 Dec 2018 11:40:03 Z

If you've done much JavaScript, you've run into the .done() and .then() callback functions, where your code is executed AFTER an asynchronous call completes.

Here, myFunction(myParams) calls makeXhrCall(myParams), an asynchronous XHR API call (the most common type of asynchronous call you will run into). The .then() function waits for the XHR call to complete. When it does, the XHR call returns data, which is used inside the .then() function to call another function, doSomething(data). The result of the doSomething(data) call gets returned out to whoever called the outer function when it's done.

myFunction(myParams) { return makeXhrCall(myParams) .then(data => doSomething(data) ); }

The key thing is, you are using .then() as a hook to do more work when the asynchronous call completes.

For a while now, you've been able to use async/await syntax as a way to treat asynchronous functions as synchronous, meaning no code AFTER the XHR call executes until the line with the await has completed executing.

If you are new to JavaScript, it can be confusing that making asynchronous calls leaves other lines of code UNDER that asynchronous call executing while the asynchronous call is still running. Changing to async/await makes your code clearer because each step is followed in top-down sequence.

async myFunction(myParams) { const data = await makeXhrCall(myParams); return doSomething(data); }

The async keyword tells JavaScript, "this code is going to use await at least once". Then you add await right before the asynchronous call. Now the data won't have a value until the XHR completes, and doSomething(data) won't run until the line with the await has finished putting a value in data.

Comparison of Typemock Isolator and Rhino Mocks

Fri, 16 Oct 2009 00:41:21 Z

I just started a new project using Typemock Isolator. It's a new tool for me, and since I've mostly used Rhino Mocks, my learning is from the perspective of "how do you do this with Rhino Mocks". These are the differences I see so far.

General

Typemock Isolator is a commercial product. Rhino Mocks is free and open source. Here's the Typemock pricing.

Typemock Isolator can mock just about anything, including not normally mockable things like private methods, static methods, and sealed classes. Rhino Mocks has traditional mocking from an interface, abstract class, etc. There has been some hand-wringingabout whether or not Typemock was too powerful and encouraged untestable software designs. But I think it's uncommon to create a brand-new stand-alone project, at least in enterprise development. So you're probably dealing with at least some code that wasn't written with testing in mind. You can wrap those static classes and create new default constructors and all kinds of OO jujutsu. Or you can just leave it alone and mock it as-is with Typemock.

With Typemock Isolator, everything starts with "Isolate" call. That's hard to beat for simplicity and discoverability. You can also use the AAA style syntax. Rhino Mocks also has AAA style testing in the newer versions. But there has been some confusion (at least in my mind) over the main entry points, like MockRepository.GenerateMock<ISomeClass>() and MockRepository.GenerateStub<ISomeClass>(). Once you understand it, you're all set, but it's kind of a stumbling block for people new to Rhino Mocks.

OK, let's move on to other syntax differences. I grouped these by AAA style (arrange, act, assert). Since the "act" step should be invoking your system under test, the frameworks should look the same there. They differ in the setup syntax (arrange) and the verify syntax (assert).

Arrange Syntax

Simple mocking

For simple mock objects, Typemock uses this syntax:

// Arrange var repository = Isolate.Fake.Instance<IContactRepository>(); var contact = new Contact(repository);
// Act contact.DoSomethingThatUsesARepository();

as compared to the Rhino Mocks syntax:

// Arrange var repository = MockRepository.GenerateStub<IContactRepository>(); var contact = new Contact(repository);
// Act contact.DoSomethingThatUsesARepository();

Not much here. Just different ways to do the same thing.

Argument handling

Method call arguments are ignored by default in Typemock, so you don't have quite as much setup to get to the system under test. You still need to put the correct type in the argument, but it can be null, string.Empty, 0, etc.

With Rhino Mocks, you have to be explicit when arguments don't matter:

theClass.Expect(x => x.theMethod(null)).IgnoreArguments();

or you can use the newer, more readable but maybe more typing Rhino Mocks syntax:

theClass.Expect(x => x.theMethod(Arg<theArgument>.Is.Anything));

In Typemock, you use this syntax:

Isolate.WhenCalled(() => theClass.theMethod(theArgument)).WithExactArguments();

only if the arguments are important to you.

So you can ignore arguments or use specific arguments with either framework. They differ on the default setting.

Unmockable mocking

In Typemock, you can also ignore calls on "live" methods (real instances, not fakes, stubs, or mocks) with:

Isolate.WhenCalled(() => theClass.theMethod(theArgument)).IgnoreCall();

The only way to not call into live code with Rhino Mocks that I'm aware of is to use a stub. This is the traditional testing approach that injects a stubbed dependency into the class under test.

So let's assume I need to test a Contact class method that does some stuff and then sends an email using EmailService, but I don't want an email to actually go out. Here's the Typemock arrange and act:

// Arrange var emailService = new EmailService(); var contact = new Contact(emailService); Isolate.WhenCalled(() => emailService.SendContactInfoToSales(contact)).IgnoreCall();
// Act contact.DoSomethingThatSendsAnEmail();

And the Rhino Mocks arrange and act:

// Arrange var emailService = MockRepository.GenerateStub<IEmailService>(); var contact = new Contact(emailService);
// Act contact.DoSomethingThatSendsAnEmail();

For the Rhino Mocks approach, my EmailService has to be mockable. Again, you can write code to do that, and in this sample I am using an interface to EmailService to do that. But with Typemock, you just tell the test to ignore that call. You don't need to write more code to make the EmailService test-friendly.

Suppose EmailService is in some company-owned assembly you have to use and it's a sealed class. Yes, you can wrap it with an interface, but why not just tell it to skip email sending with Typemock. That's pretty powerful. You can focus on the new code you want to test instead of refactoring existing code you don't really care about but are dependent on.

Simulating Exceptions

Another cool Typemock thing you can do is force existing code to throw an exception so you can test the robustness of your code. What if I want to make sure my new code works OK if the mail relay is down on that legacy, sealed EmailService:

Isolate.WhenCalled(() => emailService.SendContactInfoToSales(contact)).WillThrow(new SmtpException());

You can do the same thing in Rhino Mocks. Again, just different syntax:

emailService.Expect(x => x.SendContactInfoToSales(contact)).Throw(new SmtpException());

I think you would still need to have a mock on an IEmailService to do this with Rhino Mocks. The Typemock advantage is that it can work around that sealed class.

Assert Syntax

Simple verifications

The interaction testing assert syntax for Rhino Mocks is:

// Assert emailService.AssertWasCalled(x => x.SendContactInfoToSales(null), opt => opt.IgnoreArguments());

And for Typemock:

// Assert Isolate.Verify.WasCalledWithAnyArguments(() => emailService.SendContactInfoToSales(null));

This is just to test that the code got to that line/made that call internally. If you want to verify it got there and arrived with your expected arguments with Rhino Mocks:

// Assert emailService.AssertWasCalled(x => x.SendContactInfoToSales(expectedContact);

And with Typemock:

// Assert Isolate.Verify.WasCalled(() => emailService.SendContactInfoToSales(expectedContact));

So again, both frameworks can get you either assert type, just with different syntax.

Wrap up

The promise of Typemock Isolator is less time refactoring code that isn't on your roadmap and less setup to get to your system under test. I've focused here mostly on the arrange syntax for that reason.

Rhino Mocks can do most of the stuff Typemock can, except for the private, sealed, and static testing. Some would argue that you shouldn't test that code or if you need to make it testable, you should refactor it anyway.

Maybe. But it's also pretty appealing to keep your coding and tests focused on your project mandate, too.

Optimizing JavaScript and CSS files using RequireJS and R.js in an ASP.NET MVC app

Thu, 29 May 2014 00:39:26 Z

In my previous blog post, we discussed setting up RequireJS for a multi-page ASP.NET MVC app.

The code for the reference app is on GitHub, and when run, it shows us loading seven JavaScript files (409 KB) and four CSS files (31.1 KB):

We know we can reduce the number of HTTP requests, and reduce network traffic, if we can load fewer files and smaller files at run time.

There are several ways to do this bundling and minification: use MVC's built in tools, use Web Essentials, or use r.js, the tool that comes with RequireJS. The advantage of the later is you can let RequireJS, which is already tracking your dependency graph, decide which files should be bundled together for a specific page.

You can also use r.js to bundle ALL the scripts in your project together, and for a single-page app, that may make sense. But for a multi-page app, you want to have a common set of scripts you need on most pages, and an a la cart bundle for each page. We'll focus on the later here.

Prerequisites

You'll need to download r.js, which comes in the RequireJS nuget package, and you'll need a local version of Node running.

You'll also likely want to do this optimization only in Release mode, so be sure your project has a Debug and a Release build config.

What to bundle for JavaScript?

Here are the JavaScript files we have to work with:

We want page-level bundles, so we can load require.js, then main.js (including common libraries and kickoff.js), then main-currentDateTime.js and anything it needs that we haven't already loaded.

I usually name the main-*.js file as the name of the main MVC view or controller/action being pulled up on the screen. Theses main-*.js files are the entry point for firing up the JavaScript for just that page.

What to bundle for CSS?

We have three CSS files we can combine and a main.css file that references them:

The main.css file uses import statements for the three style sheets:

/* 3rd party stylesheets */ @import url("lib/bootstrap.css"); @import url("lib/bootstrap-theme.css");
/* Application stylesheets */ @import url("app/site.css");

This is usually a no-no for web development, because now there is a fourth style sheet, and a fourth HTTP request as the browser loads main.css, then turns around and loads the three style sheets it wants us to load. In this case, I think it's fine since this will be the way it works in Debug mode when you are working locally. When you go to Release mode, everything in main.css will be bundled and combined into one file.

Now change the link in the _Layout.cshtml file to point to main.css:

<link href="~/Styles/main.css" rel="stylesheet" />

TIP: Be sure your CSS files are listed in main.css in the order in which you want them to override, with your app styles at the bottom. The last ones listed will take precedence.

Setting up r.js, build-scripts.js, build-styles.js

I created an App_Build folder at the solution level. Call yours anything you like. The point is, this is stuff for building the project, not part of the code that is deployed when running the app.

I added the r.js file and two other JavaScript files with build config settings. One is for the JavaScript code and one is for the CSS.

The JavaScript config file, "build-scripts.js", looks like this:

({ appDir: "../Scripts", dir: "../Scripts-Build", baseUrl: "app", mainConfigFile: "../Scripts/main.js", paths: { main: "../main" }, keepBuildDir: false, modules: [{ name: "main", include: [ // These JS files will be on EVERY page in the main.js file // So they should be the files we will almost always need everywhere "domReady", "jquery", "jqueryValidate", "jqueryValidateUnobtrusive", "bootstrap", "moment" ] }, // These are page-specific bundles, usually named main-* { name: "main-currentDateTime", exclude: ["main"] } ], onBuildRead: function (moduleName, path, contents) { if (moduleName === "main") { return contents.replace("Scripts", "Scripts-Build"); } return contents; } })

Most of the paths are relative to the r.js file. The appDir is the main folder, so the appDir plus the baseUrl is the /Scripts/app folder. The dir setting is where you want the built scripts to go. The mainConfigFile is the path to main.js.

The first argument in the modules section is all the code you want rolled up into main.js. These are files used on almost every if not every page. The next argument in modules is each page file. Here, you need to manually add each page of your app where you want bundling. I've only got one page/bundle listed here. RequireJS will inspect that main-*.js file, and its dependencies, and their dependencies, and so on, but it will exclude files already bundled into main.

For example, the main-currentDateTime module uses "jquery". That file is already included in main.js in these build instructions, so it won't be bundled into main-currentDateTime.

The onBuildRead stuff is for swapping out paths in the built scripts. More on that down below.

The CSS config file, "build-styles.js", looks like this:

({ keepBuildDir: false, optimizeCss: "standard", cssIn: "../Styles/main.css", out: "../Styles-Build/main.css" })

The main configuration settings as the cssIn folder, where the code to bundle comes from, and the out folder, where it's going.

In both cases, we're outputting to new folders that are cleaned out on every Release build, /Scripts-Build and /Styles-Build.

Bundling and minifying on Release build

Open the web project Properties and select Build Events. In the Pre-build event command line, add:

if $(ConfigurationName) == Release node "$(ProjectDir)App_Build\r.js" -o "$(ProjectDir)App_Build\build-scripts.js" if $(ConfigurationName) == Release node "$(ProjectDir)App_Build\r.js" -o "$(ProjectDir)App_Build\build-styles.js"

Note the call to execute r.js with Node. You must have Node set up in your Paths on your machine for this to work. Now the build scripts will run every time the build is executed in Release mode.

Change your build configuration to Release mode and build the app. If it worked, the output window should show:

1>------ Build started: Project: RequireJSWithMVC, Configuration: Release Any CPU ------ 1> 1> Tracing dependencies for: main 1> 1> Tracing dependencies for: main-currentDateTime 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/app/currentDateTime.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/app/kickoff.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/app/main-currentDateTime.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/bootstrap.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/domReady.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/jquery-2.1.1.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/jquery.validate.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/jquery.validate.unobtrusive.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/moment.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/require.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/main.js 1> 1> main.js 1> ---------------- 1> app/kickoff.js 1> main.js 1> lib/domReady 1> lib/jquery-2.1.1.js 1> lib/jquery.validate.js 1> lib/jquery.validate.unobtrusive.js 1> lib/bootstrap.js 1> lib/moment.js 1> 1> app/main-currentDateTime.js 1> ---------------- 1> app/main-currentDateTime.js 1> 1> 1> C:/RequireJSWithMVC/Styles-Build/main.css 1> ---------------- 1> C:/RequireJSWithMVC/Styles/lib/bootstrap.css 1> C:/RequireJSWithMVC/Styles/lib/bootstrap-theme.css 1> C:/RequireJSWithMVC/Styles/app/site.css 1> C:/RequireJSWithMVC/Styles/main.css 1> 1> RequireJSWithMVC -> C:\RequireJSWithMVC\bin\RequireJSWithMVC.dll ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

r.js does a nice job of reporting back what it's done. Here, you can see it traces dependencies, minifies (uglifies) every JavaScript file, then it reports the files it bundled for main.js, main-currentDateTime.js, and main.css.

You should be able to show hidden files in Visual Studio and see the new folders and their files. Open them up and look at the minification changes

Dealing with paths with MVC Helpers

So great! We've got the files we want in /Scripts-Build and /Styles-Build. Unfortunately, our code is still pointing to /Scripts and /Styles. We can fix this with some MVC Helpers.

Looking at our _Layout.cshtml, we'll need to fix the path to the stylesheets and the path to require.js,:

<!DOCTYPE html> <html> <head> … <link href="~/Styles/main.css" rel="stylesheet" /> </head> <body> … <div class="container"> @RenderBody() </div> <script src="/Scripts/lib/require.js"></script> @RenderSection("scripts", required: false)
</body> </html>

Here's the C# for the stylesheet and scripts PathHelpers.cs:

using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class PathHelpers { public static string ScriptsPath(this HtmlHelper helper, string pathWithoutScripts) { #if (DEBUG) var scriptsPath = "_{/Scripts/"; #else var scriptsPath = "}/Scripts-Build/"; #endif return VirtualPathUtility.ToAbsolute(scriptsPath + pathWithoutScripts); } public static string StylesPath(this HtmlHelper helper, string pathWithoutStyles) {
#if (DEBUG) var stylesPath = "_{/Styles/"; #else var stylesPath = "}/Styles-Build/"; #endif return VirtualPathUtility.ToAbsolute(stylesPath + pathWithoutStyles); } } }

Now our _Layout.cshtml can be update to this:

@using RequireJSWithMVC.Extensions <!DOCTYPE html> <html> <head> ... <link rel="stylesheet" href="@Html.StylesPath("main.css")" /> </head> <body> ... <div class="container"> @RenderBody() </div> <script src="@Html.ScriptsPath("lib/require.js")"></script> @RenderSection("scripts", required: false)
</body> </html>

We still need to fix the paths within each page. They still point to the /Scripts folder and need to point to /Scripts-Build in Release mode. Let's do that by updating our RequireJsHelper.cs from the last post:

using System; using System.Text; using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class RequireJsHelpers { public static MvcHtmlString InitPageMainModule(this HtmlHelper helper, string pageModule) { var require = new StringBuilder(); #if (DEBUG) var scriptsPath = "_{/Scripts/"; #else var scriptsPath = "}/Scripts-Build/"; #endif var absolutePath = VirtualPathUtility.ToAbsolute(scriptsPath); require.AppendLine("<script>"); require.AppendFormat(" require([\"{0}main.js\"]," + Environment.NewLine, absolutePath); require.AppendLine(" function() {"); require.AppendFormat(" require([\"{0}\", \"domReady!\"]);" + Environment.NewLine, pageModule); require.AppendLine(" }"); require.AppendLine(" );"); require.AppendLine("</script>"); return new MvcHtmlString(require.ToString()); } }
}

Both of these helpers rely on the compiler flag for debug. If you don't like that, you could always branch off an Environment key in appSettings in your web.config or something.

Now when the page is loaded for this app, we have three scripts and one stylesheet, so we've gone from eleven HTTP requests to four. Furthermore, the files requested are much smaller after the minification, and we've gone from 440.1 KB to 223.3 KB total. You could get that down even more if you removed all the license info from the minified JavaScript in the build-scripts.js config with "preserveLicenseComments: false".

Finally, your users' browsers should cache most of these files after landing on any page on your site. The files require.js, main.js, and main.css will be the same for each page. Then the user's browser only needs to download the JavaScript for each newly browsed page.

Sessionless MVC without losing TempData

Thu, 30 Jun 2011 15:32:00 Z

I've blogged before about making your MVC controllers sessionless. The knock on sessionless controllers is that TempData is off the table because it uses Session as its data store.

If you see the TempData name and dismiss it, thinking it's another dictionary like Session[] and ViewData[] and you're waaaay past that since your mister type-safe, take another look. The neat thing about TempData is that it lasts for one more page load and then "poof" - it's gone. It self destructs as soon as it has been read.

Sure, it's a dictionary with magic string keys, but it's a great place to store message like "Your changes were saved" when you redirect to another page.

So how do we get the benefits of TempData as an ephemeral application message store, but go all-in on the web farm with sessionless controllers?

Cookies!

I can hear you groaning. Cookies are old school! They can't hold much information! They aren't secure!

Fine, don't put much in there, and don't put your secret fried chicken recipe in there. We're just going to use this as a little string to tell the user everything is OK or it's not OK.

TempData uses a provider model for the data store, and Session is the default data store. But you can get a cookie data store, CookieTempDataProvider, with Mvc3Futures NuGet package:

This should work as a TempData provider, but now it has to be wired into the application. Here's how you can do that:

public class BaseController : Controller { protected override ITempDataProvider CreateTempDataProvider() { return new CookieTempDataProvider(HttpContext); } }

Don't mock HttpContext

Thu, 19 Aug 2010 10:40:00 Z

HttpContext doesn't like to be mocked!!

It's so easy to take a direct dependency on HttpContext and not even realize it. If you're in the code behind in Web Forms or in a controller action in MVC, it's just right there, tempting you to use it to access session variables, application security, etc.

But don't.

Some little known facts about HttpContext:

HttpContext is the largest object ever created by humans.

If you printed out the code for everything in HttpContext, the pages could be stacked end to end to wrap around the Earth's equator 7 times.

Mocking HttpContext is like trying to calculate the last digit of pi. There is always a little more to it.

Chuck Norris gave up trying to mock HttpContext. He was deep in HttpContext.Response and quit, curled into a ball on the floor, and started whimpering.

Sealed what? Object reference what?

Let's say you've got some MVC security stuff you're trying to work with in a controller action. You've got code like:

public class OrderController : Controller { [Authorize] public ActionResult Process() { if (User.IsInRole("Admin")) { return View("SecretAdminStuff"); } return View("NotAuthorized"); }
}

See that User.IsInRole() code? That call is really to HttpContext.Current.User.IsInRole(). You just took the bait and are tied to HttpContext now.

So what? You have to use HttpContext to get that information, right? Sure, but you don't want to be tied directly to it or you've created untestable code.

Let's try a couple tests to verify the branching in this action method is returning the correct view based on the user's role. I'm using NUnit, Rhino Mocks, and the Should assembly below. Rhino Mocks has .Stub() and .Return() extension methods to set the expected return values for whether the user is or isn't in the Admin role.

[Test] public void Should_return_NotAuthorized_view_when_not_Admin_user() { // Arrange var mockContext = MockRepository.GenerateMock<HttpContext>(); mockContext.Stub(x => x.User.IsInRole("Admin")).Return(false); var orderController = new OrderController(); // Act var result = orderController.Process() as ViewResult; // Assert result.ViewName.ShouldEqual("NotAuthorized"); } [Test] public void Should_return_SecretAdminStuff_view_when_Admin_user() { // Arrange var mockContext = MockRepository.GenerateMock<HttpContext>(); mockContext.Stub(x => x.User.IsInRole("Admin")).Return(true); var orderController = new OrderController(); // Act var result = orderController.Process() as ViewResult; // Assert result.ViewName.ShouldEqual("SecretAdminStuff");
}

As soon as we run the tests we see "System.NotSupportedException: Can't create mocks of sealed classes". Oh yeah, HttpContext is sealed. That won't work.

Hmmm. Aren't there some new classes in System.Web.Abstractions for just this kind of thing? Let's change HttpContext

var mockContext = MockRepository.GenerateMock<HttpContext>();

to HttpContextBase

var mockContext = MockRepository.GenerateMock<HttpContextBase>();

and see if that helps.

The new problem is: "System.NullReferenceException: Object reference not set to an instance of an object." Mocking HttpContextBase isn't helping because the test isn't passing the mock context into the controller. Every call in the action method to User.IsInRole() will always call the real HttpContext, which isn't created because the test is not running in the ASP.NET process.

You can get around this with Typemock Isolator, which goes beyond mocking and can intercept the next call to HttpContext.Current.User.IsInRole() and swap out a result, but isn't there a simpler way to do this without buying another product or waiting for better abstract classes to work with?

A better way

We can't test something tied to HttpContext like this. We need another approach. The one I favor is wrapping the calls we care about, delegating out to the untestable code in the wrapper class, then passing an interface to the wrapper class into the constructor of the class using it.

Here's the wrapping class I've created to access a few HttpContext current user values and the interface for the wrapping class:

public class CurrentUser : ICurrentUser { public virtual string Name() { return HttpContext.Current.User.Identity.Name; } public bool IsLoggedIn() { return HttpContext.Current.User.Identity.IsAuthenticated; } public bool IsGuest() { return HttpContext.Current.User.IsInRole("Guest"); } public bool IsAdmin() { return HttpContext.Current.User.IsInRole("Admin"); } }
public interface ICurrentUser { string Name(); bool IsLoggedIn(); bool IsGuest(); bool IsAdmin(); }

Now I need to update the controller to inject this dependency into the constructor so it can be mocked, and use a private field set in the constructor for subsequent calls to _currentUser:

public class OrderController : Controller { private readonly ICurrentUser _currentUser; public OrderController(ICurrentUser currentUser) { _currentUser = currentUser; } [Authorize] public ActionResult Process() { if (_currentUser.IsAdmin()) { return View("SecretAdminStuff"); } return View("NotAuthorized"); }
}

Now we've got a testable action method. I mock the CurrentUser with MockRepository.GenerateMock<ICurrentUser>, set its return value with the Rhino Mocks .Stub() and .Return() extension methods, and check for the expected results:

[Test] public void Should_return_NotAuthorized_view_when_not_Admin_user() { // Arrange var mockCurrentUser = MockRepository.GenerateMock<ICurrentUser>(); mockCurrentUser.Stub(x => x.IsAdmin()).Return(false); var orderController = new OrderController(mockCurrentUser); // Act var result = orderController.Process() as ViewResult; // Assert result.ViewName.ShouldEqual("NotAuthorized"); } [Test] public void Should_return_SecretAdminStuff_view_when_Admin_user() { // Arrange var mockCurrentUser = MockRepository.GenerateMock<ICurrentUser>(); mockCurrentUser.Stub(x => x.IsAdmin()).Return(true); var orderController = new OrderController(mockCurrentUser); // Act var result = orderController.Process() as ViewResult; // Assert result.ViewName.ShouldEqual("SecretAdminStuff");
}

Hey, wait a sec

If you're thinking to yourself: I've just tested the code in the action method and not whether HttpContext really works, you're exactly right. The tests should cover the branching in the controller action and are unit tests. They are not integration tests that check to see if HttpContext is returning the right values.

I'm OK with that tradeoff. I know HttpContext works. It's been around forever and it's in a System.<something> namespace, so I shouldn't be testing it.

The real question is, do my login and roles and authorization settings work as expected in my application. That calls for integration testing, and the easiest way to do that is click through those screens and see if it's working. You can also automate this clicking around with Watin, or SpecFlow (which uses Watin internally to drive the browser).

Which IoC container should I use?

Sat, 10 Oct 2009 00:41:32 Z

This came up on the Alt.Net Yahoo Group/mailing list today. There are tons of tools out there for inversion of control. They have been compared here and other places online. Nobody wants their app tied to the Betamax of IoC tools, so people are anxious to pick the best one.

All containers keep a hash table of your interfaces mapped to your concrete classes. Most will let you request a specific instance with a string token. Most will let you control instance creation (singleton, etc.). The popular IoC containers have fluent configuration and use conventions to figure out that IEmailService maps to EmailService.

So which one should you pick? Go with the one you already know best and/or the one that is easiest for your dev team to configure. That's because with the Common Service Locator wrapping your IoC get instance calls, the provider becomes a moot point.

This is an old OO principal - encapsulate the stuff that can change. Jeremy Miller pointed out the need for a common IoC wrapper to do just this. Today's hot new open source IoC container could be tomorrow's dormant project. If you wrap the calls, you can rip out your IoC provider and most of your code stays the same since it's calling the wrapper.

Here's how I'm doing this using Castle Windsor in a Sharp Architecture project. First, I create a class to wire up my IoC configurations for my app.

public static class RegisterIoCContainer { public static void AddComponentsTo(IWindsorContainer container) { AddApplicationConcernsTo(container); AddCoreConcernsTo(container); } private static void AddApplicationConcernsTo(IWindsorContainer container) { container.Register(Component .For<IMappingEngine> .Instance(Mapper.Engine) .LifeStyle.Singleton); container.Register(AllTypes.Pick() .FromAssemblyNamed("MyApp.ApplicationServices") .WithService.FirstInterface() .Configure(c => c.LifeStyle.Transient)); } private static void AddCoreConcernsTo(IWindsorContainer container) { container.Register(AllTypes.Pick() .FromAssemblyNamed("MyApp.Infrastructure") .WithService.FirstNonGenericCoreInterface("MyApp.Core") .Configure(c => c.LifeStyle.Transient)); }
}

Note the use of convention-based mappings between assemblies and the different instance lifestyles. Mapper.Engine has a Singleton lifestyle. Not that there's anything wrong with that. :>

Next, I create a class to tell Common Service Locator to use Castle Windsor as the provider and to load up those IoC configurations:

public static class RegisterServiceLocator { public static void Register() { var container = new WindsorContainer(); ServiceLocator.SetLocatorProvider(() => new WindsorServiceLocator(container)); RegisterIoCContainer.AddComponentsTo(container); }
}

Then I call RegisterServiceLocator.Register() on Application_Start() in the Global.asax. From then on, I can call the Common Service Locator to get my instance from my interface:

var instance = ServiceLocator.Current.GetInstance<IEmailService>();

I don't often need to use this syntax, since I'm usually pushing external dependencies into a constructor and letting auto-wiring resolve the dependency chain for me. But I do use this syntax for testing that Common Service Locator is finding the instance I want.

Adding RequireJS to an ASP.NET MVC project

Wed, 28 May 2014 00:39:29 Z

Why RequireJS?

RequireJS is a popular JavaScript module loader. RequireJS solves the problem of needing to invoke some JavaScript code from another file, but not knowing if that file has been loaded yet.

It does this with either a define or a require declaration, which takes an array of strings and a callback function, then passes in the module names as arguments so you can reference them in your JavaScript code.

define(["jquery", "moment"], function ($, moment) { "use strict"; var init = function () { // Requires MomentJS to be loaded. // "moment" is the argument passed in by RequireJS for the MomentJS module, aliased as "moment" in the define/require statement. var now = new moment().format("M/D/YYYY h:mm:ss A"); // Requires jQuery to be loaded. // "$" is the argument passed in by RequireJS for the "jquery" module in the define/require statement. $("#currentDateTime").text(now); }; return { init: init }; }
);

Here "moment" is both the name of the module to load, and the argument passed in for that module name. It could have been "m" throughout, and it would still work. The same is also true for "jquery at the top in the define, which tells RequireJS what module to load, and "$" below that, which tells RequireJS to load that module into an argument named "$". We're using "moment" and "$" inside the function so the code looks conventional, but the "$" could have been "j" if you wanted it to be.

RequireJS guarantees that the external modules are loaded by the time your code runs. It also keeps track of which modules have already been loaded on the page, so it doesn't pull in the same module twice.

So which is it – require() or define()?

The require and define statement are the main ways you use RequireJS. The API signature is the same for both, but they work differently: "define" is for modules that will be loaded and run by code that uses a "require" statement to pull that module in. So think of "define" as your module definitions, and "require" as the way to execute them.

As you can see, the RequireJS usage is very simple and clean. The setup can be a headache, especially around paths, so I'll take you through how I've done it.

Configuring your paths in main.js

RequireJS needs to be configured. When we said "jquery" and "moment" above, we have to tell RequireJS where those files are so we can use those aliases. That's where main.js and required.config() come in:

require.config({ baseUrl: "/Scripts/app", paths: { jquery: "../lib/jquery-2.1.1", jqueryValidate: "../lib/jquery.validate", jqueryValidateUnobtrusive: "../lib/jquery.validate.unobtrusive", bootstrap: "../lib/bootstrap", moment: "../lib/moment" }, shim: { jqueryValidate: ["jquery"], jqueryValidateUnobtrusive: ["jquery", "jqueryValidate"] } });
require(["kickoff"], function(kickoff) { kickoff.init(); } );

RequireJS uses the baseUrl setting in main.js if you pass it a script name that is not an alias in the paths section. In other words, if you call "jquery" in your define/require, it knows from your paths setting where to go. If you call "myScript" in define/require, it looks for it in the baseUrl path, which is /Scripts/app in this case.

Notice there are no .js extensions to the end of the file names? This is something RequireJS does to help you. It's a JavaScript loader; it knows those are JavaScript files. In my view, this just adds to some of the confusion of configuring this thing.

Here's how I've got my paths configured under my Scripts folder in Visual Studio:

You can set up different folder structures or names based on your preferences, but it probably makes sense for main.js, which is the entry point of the app, to be at the root of /Scripts, or at least above your /app and /lib script folders. Also, you don't have to name your file main.js. that's just a RequireJS convention.

The shim section in the code above is to tell RequireJS about any dependencies your files have before they can be used. Here, we are saying if we call "jqueryValidate" to load that module, we have to load "jquery" first. The "jqueryValidateUnobtrusive" module has to load "jqueryValidate" and "jquery" first, before it can be used. You could probably shorten the shim for "jqueryValidateUnobtrusive" to just "jqueryValidate", since that module requires "jquery", and RequireJS tracks the whole dependency graph for you. It doesn't hurt to leave it in, either.

For many apps, it makes sense to call code to load the app or run code on every page from the main.js file, and we've done that here with a call to "kickoff.init()".

Calling the main.js file

The normal advice for adding RequireJS to an app is to put this line in the <head> section of _Layout.cshtml.

<script data-main="Scripts/main" src="/Scripts/lib/require.js"></script>

This is a kind of weird looking script tag. The src attribute is normal enough for pulling in RequireJS, but the data-main is new. That's RequireJS's special attribute for getting the path to main.js. Notice again there is no ".js" in the data-main. RequireJS knows it's a .js file and appends that automatically.

This script tag is usually all you need for a single page app, where all modules run inside one full page request.

Set up for multi-page apps

I don't see too many single-page apps in the wild. More often, they are multi-page apps where each page has a LOT going on. If you aren't building a single page app, you can still take advantage of RequireJS, but we need to change some things.

We need to change the code that loads RequireJS and main.js in _Layout.cshtml from:

<script data-main="Scripts/main" src="/Scripts/lib/require.js"></script>

to:

<script src="/Scripts/lib/require.js"></script> @RenderSection("scripts", required: false)

You can put this right before the closing </body> tag if you like, but RequireJS will inject <script> tags with the async attribute in the <head> section like this:

Now we've got a common layout, and a hook in each page (the Razor @RenderSection) where we can load THAT page's scripts. In each page, you'll then need something like:

@section scripts { <script> require(["Scripts/main"], function () { require(["currentDateTime"], function (currentDateTime) { currentDateTime.init(); } ); } ); </script> }

Each page will be different, depending on what you need to load and run, but you will always load and run main.js, then when that's done, you'll load the scripts just for that page in the inner require(). Note this inner require() is pulling in the code that was in the define() at the top of this post.

Now drop this code in on every page in your app, but first…

What about jQuery and DOM loading?

What if your JavaScript loads before the DOM is loaded? With jQuery, we normally call:

$(function () { ...the code to run on DOM ready... });

So how do we know the DOM is loaded before we start touching it in RequireJS world? We need to use the domReady plugin with:

require(["domReady!"], function() { ...the code to run on DOM ready... } );

Download the plugin and put it in the /Scripts/lib folder. Now we have a new file we want to alias, so we need to add that to our require.config paths in main.js

paths: { jquery: "../lib/jquery-2.1.1", jqueryValidate: "../lib/jquery.validate", jqueryValidateUnobtrusive: "../lib/jquery.validate.unobtrusive", bootstrap: "../lib/bootstrap", moment: "../lib/moment", domReady: "../lib/domReady", },

There we go. We have another piece of our run-on-every-page code snippet.

MVC Helpers

When you start repeating yourself in an MVC view, consider adding an HTML Helper. What we want generically is:

require(["Scripts/main"], function () { require(["...the module to load...", "domReady!"], ...run the module... ); } );

We also don't want to have to think about relative paths. We want the scripts to find main.js and the /Scripts/app and /Scripts/lib folder whether the page is located at the root (/) or /Deep/Within/The/Site.

Here's the C# to do that:

using System; using System.Text; using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class RequireJsHelpers { public static MvcHtmlString InitPageMainModule(this HtmlHelper helper, string pageModule) { var require = new StringBuilder(); var scriptsPath = "~/Scripts/"; var absolutePath = VirtualPathUtility.ToAbsolute(scriptsPath); require.AppendLine("<script>"); require.AppendFormat(" require([\"{0}main.js\"]," + Environment.NewLine, absolutePath); require.AppendLine(" function() {"); require.AppendFormat(" require([\"{0}\", \"domReady!\"]);" + Environment.NewLine, pageModule); require.AppendLine(" }"); require.AppendLine(" );"); require.AppendLine("</script>"); return new MvcHtmlString(require.ToString()); } }
}

What we're going for is having several things loaded on every page: 1) require.js, 2) main.js, 3) the DOM, and 4) the main JavaScript module for that page and anything that module needs. This "main module" concept works well to just run as it's loaded instead of forcing the caller to invoke it with an init() call, so let's change our "currentDateTime.js" module from above to do that and create "main-currentDateTime.js" instead:

require(["jquery", "moment"], function ($, moment) { "use strict"; // Requires MomentJS to be loaded. // "moment" is the argument passed in by RequireJS for the MomentJS module, aliased as "moment" in the require statement. var now = new moment().format("M/D/YYYY h:mm:ss A"); // Requires jQuery to be loaded. // "$" is the argument passed in by RequireJS for the "jquery" module in the require statement. $("#currentDateTime").text(now); }
);

We've also changed from define() to require() since this is a self-loading module, not one a caller has to invoke. We got rid of the init() function so this code runs when the module is loaded.

Download

That should do it for adding RequireJS to your MVC mutli-page app. All the code above is available for view/download on GitHub.

Why I'm using Moq instead of Rhino Mocks these days

Thu, 10 Mar 2011 01:40:15 Z

On my last greenfield project I got to pick the unit testing and mocking tools. I've been a regular Rhino Mocks user for a long time, but I've seen lots of code samples with Moq and liked the syntax, so I gave it a try.

I have to say, I did prefer Moq slightly to Rhino Mocks. The newer Arrange, Act, Assert (AAA) style syntax in Rhino Mocks is a huge improvement over the old Record/Replay mess. But Moq has the benefit of being born at the right time and has AAA style calls without the burden of supporting deprecated syntax. This means Moq has cleaner documentation, fewer options, and fewer ways to get confused by the API. I really couldn't find anything I needed to do in Moq that I couldn't do. I did get a little tripped up having to get the object out of the mock, with myMock.Object calls, but that wasn't a big deal.

Here's the NuGet Moq install package syntax to add Moq to your unit test project:

I'm using mocking frameworks less these days. Instead, I'll write a fake object myself or just try to avoid interaction testing altogether. But if I needed to pull one off the shelf today, I'd grab Moq first.

Lazy load off-screen images with lazysizes

Mon, 23 Apr 2018 00:39:09 Z

Many users will never scroll all the way down to see the awesome images below the fold on your web site. If you load all your images when the page loads, you are wasting bandwidth and slowing down the page start-up experience.

Instead, you can lazy-load images as they are about to come into view. The latest way to do this is using Intersectional Observer, but it isn't supported on Safari, iOS Safari, or IE11.

I opted to use lazysizes to deal with cross-browser differences, viewport size differences, scroll speeds, and the other headaches you could get rolling your own solution. To see it in action, go to their test page, open your browser tools Network tab, filter for Images, and scroll down. You'll see new images loaded as you get closer to them. It's slick.

The easiest way to use lazysizes is to reference the script in your page:

<script src="lazysizes.min.js"></script>

Then change <img> tags from src="myImage.jpg" to data-src="myImage.jpg" and add class="lazyload" like:

<img data-src="myImage.jpg" class="lazyload" />

You can get fancier with responsive image sets and lazy loading CSS background images, too.

Where should validation go?

Tue, 15 Sep 2009 00:41:26 Z

<groan>Not this argument again!</groan>

The short answer: I don't know.

The long answer: Yeah, I really don't know.

There is still no widely accepted answer on this one. Reasonable people disagree. One camp pushes it up closer to the UI, the other down lower so it shelters the domain from invalid states. Some like it sprinkled across layers; some like it centralized.

I think Steve Sanderson is correct that validation falls on a continuum from easy UI validation, like required fields, to complex business rules that need to be checked closer to or in the domain entities.

I also think Jimmy Bogard is correct that context matters when it comes to validation. This object is valid for what? Saving to the database? Emailing to sales? Displaying on the screen? The validation rules depend on the the behavior you are validating.

These days, I think of validation as either UI Validation (required fields, min/max length, etc.), Domain Validation (start date/time must be before end date/time, order must have at least one item, etc.), or Database Validation (is this value unique, is this ID value going to throw a foreign key violation). This is based on when you can validate in the call chain more than what it's valid for. I still like validation in context, but those business rules end up in my Domain Validation logic with method names like CanSendEmailToCustomer().

Sharp Architecture uses NHibernate Validators as attributes on the domain entities. The best thing about this is your validation is centralized. It's sitting right there in your domain, and you know where to go if there is a rule change.

The other good thing about this approach is your entity should always be valid when saved. The built-in Repository<TEntity> calls in Sharp Architecture enforce validation before inserts and updates, so you're covered there. If you want to call MyEntity.IsValid() in a method, you can do that as well.

The bad thing is those validation attributes can start looking like UI concerns when they have user-centric error messages in them ("Hey, user, that's not a valid format for a phone number"). And if there is a rule that doesn't lend itself to attributes (e.g., orders must have at least one order item), you are on your own.

I started with validation attributes on my domain entities, and when my attribute messages got too UI-looking, I moved to using Data Annotations on DTOs in my application service layer for UI validation. The DTOs are made to be client facing, so I'm not bothered by user-specific messages in them.

Then when Domain or Database Validation problems come up, a ValidationException is thrown up through the application service to the UI so the calling app can either display or handle it. I haven't played with it yet, but I think this is what xVal is doing, too.

The more I think about it, the more I see my web app as just another client calling into my application service layer which is encapsulating my domain. So my web app is the "user" and the message needs to be just enough for that user, not necessarily the end user. Maybe a validation exception token is sent out from the application service layer to the UI, and the UI translates that to a string from a very UI-centric resource file?

Bu I'm still not happy with this. I feel like I have the right kind of validation in the right places, but I would still like a more centralized approach for easier refactoring of business rules. I've used the Specification Pattern before, and it does a great job of centralizing the rules. But making yet another class for yet another required field and adding it to yet another Composite Specification? Seems like your walking away from a lot of the productivity attributes can give you.

Obviously, my thoughts on validation are still not fully formed. I'm still arguing with myself. My dream validation would be:

centralized for easy refactoring and rule changes

automatically called for routine things so I don't forget (like saving the order to the database)

allow ad hoc calls for non-routine things (like validating the order confirmation email can be sent to the customer)

handle simple validation like attributes so I can be productive

handle complex validation like specifications so I'm not limited

UI-agnostic so the centralized validation goo isn't holding end-user strings, except when I'm too lazy to set up the resource file, in which case strings can be passed up from this layer

I told you I didn't know! :)

Specifying Args with Rhino Mocks

Thu, 26 Nov 2009 01:41:11 Z

The problem

I ran into a snag testing some code today with Rhino Mocks. I was mocking calls to a repository and inspecting the repository method calls and arguments passed.

Everything started off pretty normal with the repository dependency injected into the class under test:

// Arrange var repository = MockRepository.GenerateMock<ICustomerRepository>(); var passenger = new Passenger(repository);
// Act passenger.CallTheMethodUnderTest(arg1, arg2);

In my Assert section, I needed to check that the correct repository methods were called with the correct arguments. The catch was, one of the arguments was a class created within the method under test. I thought I could create and assert the equivalent Customer in my test like this:

// Assert var expectedCustomer = new Customer { CustomerID = "1234", FirstName = "Joe", LastName = "Wilson" }; repository.AssertWasCalled(x => x.SomeRepositoryMethod( arg1, arg2, expectedCustomer));

The two Customer objects (in the test and in the method under test) had the same values, but of course, were not the same objects. They were two different Customer objects that happened to have the same values. So Rhino Mocks told me that my expected Assert wasn't met.

The answer

I knew Rhino Mocks could ignore arguments with

Args<T>.Is.Anything

But I knew what the values should be. In fact, for this test, the values being passed into the repository calls were just as important as the calls themselves.

So I tried comparing the values of the two Customer objects instead of the objects themselves:

repository.AssertWasCalled(x => x.SomeRepositoryMethod( arg1, arg2, Arg<Customer>.Matches(c => c.CustomerID.Equals("1234") && c.FirstName.Equals("Joe") && c.LastName.Equals("Wilson"))));

So close! But now Rhino Mocks told me if I used Arg for one parameter, I'd better use it for all of them. No biggie. I made the change and this worked:

repository.AssertWasCalled(x => x.SomeRepositoryMethod( Arg<int>.Is.Equal(arg1), Arg<int>.Is.Equal(arg2), Arg<Customer>.Matches(c => c.CustomerID.Equals("1234") && c.FirstName.Equals("Joe") && c.LastName.Equals("Wilson"))));

Postmortem

The Arg statement let's you specify a type and tell Rhino Mocks you don't know or don't care about the value:

Args<int>.Is.Anything

You can also tell Rhino Mocks you know the type and what the value should be:

Args<int>.Is.Equal(7)

If you have a non-primitive type or complex assert, you can also inspect values with the Matches statement:

Arg<Customer>.Matches(c => c.CustomerID.Equals("1234") && c.FirstName.Equals("Joe") && c.LastName.Equals("Wilson"))));

I realize the code in these tests is probably way too familiar with the code under test. I prefer testing state over this kind of interaction testing where possible. But this was a case where the code under test had a void return and didn't do much besides parse some values and call repository methods based on those values.

In times like this, I'm glad I have interaction testing to fall back on so I can verify my code is behaving the way it should.

Review of Sharp Architecture

Tue, 15 Sep 2009 00:41:29 Z

I've been using the open-source project Sharp Architecture for about 6 months now, and version 1.0 was recently released. It's a really great way to get rolling quickly on a project using ASP.NET MVC, Domain Driven Design (DDD), NHibernate, and Castle Windsor.

I won't go into the details about what Sharp Architecture does. I'll just cover what I like in the first version and what I hope makes it into future releases.

What I like

Decoupled Design

The Sharp Architecture framework uses inversion of control right out of the box with Castle Windsor and the Common Service Locator wrapping container calls. The MyProject.Core assembly holds your domain model and interfaces to your repositories. Implementations of those repositories are in MyProject.Data.

There is also a MyProject.ApplicationServices assembly for times when your controller logic starts to look heavier than it should or you prefer to push all your logic into an application layer so you can skim off the MVC UI for something else at some point (Silverlight? WCF?). I like this approach with very lightweight controllers and views for just this reason.

NHibernate Training Wheels

Billy McCafferty, the principal author on the project, is one of the gurus on NHibernate best practices. NHibernate is very powerful, but some tools, like Fluent NHibernate, which uses C# code to map your domain to your database instead of XML, are.well.kind of fluid.and still under construction.

I'm still new to NHibernate and very new to Fluent NHibernate, so I get tripped up often. It's nice to know that my solution is using best practices for tools where my footing is not as sure, like NHibernate session management.

Templates + Conventions

The Visual Studio solution and T4 templates inside Sharp Architecture are the things that makes it different from being just another reference implementation or architecture guidance. You can get a new, empty Sharp Architecture solution going in about 30 seconds with the Visual Studio solution template. The T4 templates help you add controllers and views built around conventions and the property names in your domain entity.

I used to be a big fan of code generation. It's nice to spit out a bunch of classes very quickly, but there really has to be a balance. If it gens too much code, is it all stuff you really need? If it only gens a little bit, did you need a code generator at all?

Sharp Architecture does a good job of giving you a jump start on stuff you will probably want or at least a place-holder for stuff you will want. It doesn't litter the solution with too much junk.

For instance, it doesn't generate a repository for your domain entity because you can use use the IRepository<MyDomainEntity> and Repository in the Sharp Architecture assemblies. It doesn't generate NHibernate mappings for your domain entity because the mapping conventions cover most cases. If you do need additional repository methods or have unconventional database mappings, it's easy to inherit from and override these. Sharp Architecture uses generics, base classes, and conventions to keep from needing a lot of code generation.

Documentation, Sample Code, Wiki, and Forum Support

This project is much better documented than most open-source projects. In addition to the "getting started" and 'using the framework" documents, there is a sample Northwind project that comes with the download files. Online, there is a wiki and a Google Group that is actively monitored if you need additional help.

I know real programmers only use Reflector for documentation. :> But don't underestimate the value of documentation for widespread adoption. You can have a great open source project that doesn't get very far if people don't know how to get up and running quickly and fully exploit the framework. That won't be a problem for Sharp Architecture.

Helpers

Sharp Architecture libraries are chock full of all kinds of convenience methods and helpers. Want to write a database integration test using SQLite? Just have your test class inherit from RepositoryTestsBase(). Want to hit the live database? Inherit from DatabaseRepositoryTestsBase(). Want to design by contract and check incoming parameters and return values easily? Look into the Check.Require() and Check.Ensure().

There are a ton of things like this that all of us have written before. Most developers I know walk around with a couple assemblies to make coding their next project easier. With Sharp Architecture, these are referenced in your solution right after File > New Project.

Folder Structure

Everyone has their own preferred solution and folder structure. The default project and folder organization in a new Sharp Architecture solution is pretty close to what I was already using and is simple for any developer to jump in and follow along.

This may not seem like a big deal because a good structure looks obvious in hindsight, but it's nice to not have to dig around for things. I've worked on solutions that have 20+ projects. Sharp Architecture goes the other way and you end up with about four projects in a normal MVC app.

What I would like to see in future releases

I don't have any strong objections to the design choices in Sharp Architecture. Most of the things here are more a matter of style/taste than anything.

Controllers back in MyProject.Web project

You can read Billy's view on putting the controllers in the web project. His main point is that controllers should be written and tested independent of the other assemblies so you don't succumb to temptation and do things like go straight to your repository from your controller instead of asking your IoC tool to give you the concrete repository instance.

That's fair. But my controllers don't do much besides call into my application services layer, render views, and redirect to other controller actions. I don't mind having a reference to the entire web project in my unit test project so I can test routes and the very little logic I have in my controllers.

In his article, Billy describes the pain of having done it the way I prefer. Maybe this is one of those lessons where you have to experience it yourself to internalize it. Like my dad telling me the stove was hot when I was a kid. :>

MyProject.Infrastructure instead of MyProject.Data

Maybe I've looked at Code Camp Server or listened to Jeffery Palermo talk too much, but I lump data handling into a larger category of infrastructure concerns. Sharp Architecture's solution template gives you MyProject.Data, which holds the NHibernate mappings and conventions and the repository classes.

But I have other utility/infrastructure things I need to put somewhere, like logging, emailing, etc. I prefer having MyProject.Infrastructure with Data as a folder underneath it so I can throw all my infrastructure implementation code into that assembly. The interfaces for these guys still go in MyProject.Core, just like the repository interfaces.

More emphasis on MyProject.ApplicationServices

I prefer to have as little logic as possible in my views and controllers. I push as much as I can to an application layer so the UI can be replaced or added to with minimal impact. In Sharp Architecture, you've got MyProject.ApplicationServices for exactly that. There is one Northwind example that uses this layer, but in the other samples, the controllers are doing the application flow work.

I think it's better to have an application service passed into the controller's constructor so the controller doesn't need to know much except routing, views, redirects, the app service method to call, etc. I don't mind having these UI logic concerns in the controller, but anything beyond that needs to be in an application layer.

I've borrowed a metaphor from the SQL Server installer that talk about "surface area". I think of the MyProject.ApplicationServices layer as a wrapper around all the app logic. The methods in this layer are the surface area of my application, and they encapsulates all the implementation code my domain is dealing with. Calls into this layer can kick off multi-step processes, handle workflow, and usually have long, explicit method names. But this is the only part of my domain's surface area that is exposed externally.

The MVC web project is one client calling into this application layer, but there may be others someday on even medium-sized projects. If your app becomes more popular and you've followed this approach, you can add other clients that call into your application service layer like a WCF service, a system tray tool, etc. These guys may have their own specialized methods or may use something the web application was using. Either way, you are very intentional on the surface area you expose.

I think Sharp Architecture gets this right. I would just like to give it a little nudge to make it a point of emphasis.

Conclusion

I've used a lot of different frameworks, but Sharp Architecture comes closest to the way I want to work already. The templates and documentation put it well beyond a reference implementation, and you can work with a simplified solution sitting on top of a lot of abstracted complexity to get you productive right away.

True is Truthy, but Truthy isn't the same as True

Fri, 24 Apr 2015 11:08:00 Z

Most JavaScript developers are familiar with the concepts of truthy and falsy. As a quick refresher, the falsy values are:

false null undefined 0 (the number zero) "" (an empty string)

Everything else is truthy. This is one of those things you just have to memorize, but it's simpler if you think of the falsy stuff as things that are false or have no value. Just watch out for zero and empty string.

I got burned by a bug today in a passing Jasmine test by not paying enough attention to the truthy values. The code I was testing was a little function to make sure scaleMin was smaller than scaleMax, but if they were both set to 0, that was OK. If scaleMin was greater than or equal to scaleMax, we'd return an error message.

Here are the function and tests I started with. All the tests pass. Done, right?!?!

// Code under test var MyApp = function () { var isValid = function (scaleMin, scaleMax) { if (scaleMax <= scaleMin) { return "Scale max must be greater than Scale min."; } return true; }; return { isValid: isValid }; }; // Specs describe("isValid", function () { var myApp = new MyApp(); it("Should be valid when scale min/max are both 0", function () { var scaleMin = 0, scaleMax = 0; expect(myApp.isValid(scaleMin, scaleMax)).toBeTruthy(); }); it("Should be valid when scale min is less than scaleMax", function () { var scaleMin = 0, scaleMax = 1; expect(myApp.isValid(scaleMin, scaleMax)).toBeTruthy(); }); it("Should be invalid when scale min is equal to scaleMax", function () { var scaleMin = 1, scaleMax = 1; expect(myApp.isValid(scaleMin, scaleMax)).toBe("Scale max must be greater than Scale min."); }); it("Should be invalid when scale min is greater than scaleMax", function () { var scaleMin = 1, scaleMax = 0; expect(myApp.isValid(scaleMin, scaleMax)).toBe("Scale max must be greater than Scale min."); });
});

Not so much.

Jasmine's toBeTruthy() checks for any truthy value, and a string with something in it is truthy. So in the test where I'm checking that it's OK if scaleMin and scaleMax are both 0, I'm getting the error string, which is truthy. Since the error string and the value true are both truthy, my check for toBeTruthy() will always pass. I'm getting false positives.

This is why you are supposed to write a failing test, then a passing test to prove your code was the thing that made the test pass. I skipped that here because this code was so simple. What could go wrong? Oops!

Here's the fixed function and test code, which uses Jasmine's toBe(true) instead of toBeTruthy() to tease apart error strings and the value true:

// Code under test var MyApp = function () { var isValid = function (scaleMin, scaleMax) { if (scaleMin === 0 && scaleMax === 0) { return true; } if (scaleMax <= scaleMin) { return "Scale max must be greater than Scale min."; } return true; }; return { isValid: isValid }; }; // Specs describe("isValid", function () { var myApp = new MyApp(); it("Should be valid when scale min/max are both 0", function () { var scaleMin = 0, scaleMax = 0; expect(myApp.isValid(scaleMin, scaleMax)).toBe(true); }); it("Should be valid when scale min is less than scaleMax", function () { var scaleMin = 0, scaleMax = 1; expect(myApp.isValid(scaleMin, scaleMax)).toBe(true); }); it("Should be invalid when scale min is equal to scaleMax", function () { var scaleMin = 1, scaleMax = 1; expect(myApp.isValid(scaleMin, scaleMax)).toBe("Scale max must be greater than Scale min."); }); it("Should be invalid when scale min is greater than scaleMax", function () { var scaleMin = 1, scaleMax = 0; expect(myApp.isValid(scaleMin, scaleMax)).toBe("Scale max must be greater than Scale min."); });
});

Unit testing untestable code

Tue, 06 Apr 2010 05:44:00 Z

Let's say you've got a static or sealed class, or a class with non-virtual members that your code needs to use. You need to unit test your code, but you can't get an instance of this class and/or you can't mock it.

There are two ways to go:

Buy a tool that let's you mock things like this, such as Typemock Isolator or the newly announced Telerik JustMock.

Code around it.

Buy it

I've already compared Typemock Isolator ($799) to RhinoMocks (free). Typemock Isolator works as advertised. The biggest issue is the price. It's hard enough to get management approval for introducing external tools. But when buy-in literally means BUY in, it's even harder.

Build it

Don't despair if you're stuck with "code around it" and using free mocking tools! If you can change the code that is static, sealed, private, non-virtual, etc. fix it that way. That's the best thing.

But if it's in a legacy assembly you have to use, and you can't just change the original code, use this simple technique.

Here's the untestable class we need to use. It's static, so we can't mock an instance of it with Rhino Mocks.

public static class StaticSendOrderClass { public static void SendOrderToAccountsPayable(Order order) { // Pretend code here... } }

Here's the new code you're working on that uses this static class to process an order:

public class OrderProcessor { public void ProcessTheOrder(Order order, bool useStaticClass) { if (useStaticClass == true) { StaticSendOrderClass.SendOrderToAccountsPayable(order); } else { // Notify accounts payable some other way } } }

First, we need to create an interface with just the functionality we need from the untestable class. Name the class and method(s) whatever makes sense for your app. You're not tied to the legacy code naming convention; this is your code now.

public interface INotifyAccountsPayable { void SendOrder(Order order); }

Next, create a new class to implement this interface and wrap the untestable code. In the method calls in the new class, turn around and delegate the call to the untestable class.

public class NotifyAccountsPayable : INotifyAccountsPayable { public void SendOrder(Order order) { StaticSendOrderClass.SendOrderToAccountsPayable(order); } }

Now inject the new interface into the constructor of your new class as an argument. You'll also want to create a private field and set its value to the instance argument in the constructor. Now you can swap out your old code that calls the untestable code, and instead use your new private field.

public class OrderProcessor { private readonly INotifyAccountsPayable _notifyAccountsPayable; public OrderProcessor(INotifyAccountsPayable notifyAccountsPayable) { _notifyAccountsPayable = notifyAccountsPayable; } public void ProcessTheOrder(Order order, bool useStaticClass) { if (useStaticClass == true) { _notifyAccountsPayable.SendOrder(order); } else { // Notify accounts payable some other way } }
}

Now you've got a unit testable OrderProcessor class! Mock the INotifyAccountsPayable interface with Rhino Mocks and inject that mocked dependency into your class under test. Then you can verify the call was made as expected.

[Test] public void Should_call_untestable_code_when_useStaticClass_is_set_to_true() { // Arrange var mockNotifyAccountsPayable = MockRepository.GenerateMock<INotifyAccountsPayable>(); var orderProcessor = new OrderProcessor(mockNotifyAccountsPayable); var stubOrder = MockRepository.GenerateStub<Order>(); var useStaticClass = true; // Act orderProcessor.ProcessTheOrder(stubOrder, useStaticClass); // Assert mockNotifyAccountsPayable.AssertWasCalled(x => x.SendOrder(stubOrder));
}

Please note this is not testing the internals of the untestable, static code. But you don't need to worry about unit testing the internals of that code. You don't own that code. Testing that is really an integration test, not a unit test. Using this approach, you isolate your new code from an external dependency and keep all your new code testable.

Upgrading FontAwesome from 4 to 5

Mon, 22 Jan 2018 06:33:00 Z

FontAwesome 4 has been around a long time, and it's…well, awesome! Remember their Kickstarter with those videos? Well FontAwesome 5 is out now, and as promised, it has some big improvements. But to get the benefits, you'll have to work through some breaking changes. Here's what I learned from my upgrade.

Let's start with a simple page with 3 icons using Font Awesome 4.

The big improvement in FontAwesome 5 is that the icons are drawn with SVG now. Yay for sharp scaling up or down! Now you reference a JavaScript file with the SVG specs embedded in it instead of a CSS file. I'll change the pen to remove the CSS reference and add the JavaScript reference from the CDN:

<script defer src="https://use.fontawesome.com/releases/v5.0.3/js/all.js"></script>

Then check the results:

You can see the icons, but they changed a little. The calendar is very dark, and the arrow is a little more narrow. That's because the way you reference the icons has changed in version 5. Instead of fa as a style preceding every icon style, you need to pick from fas for solid, far for regular, fal for light, or fab for brand. It looks like fas is the fallback, so you get solid if you leave your old fa references. For most icons, this change makes the icon heavier or lighter.

If you are biting your nails thinking of all the places you have icons that will now need to change, you can upgrade to 5 and use a shim.

<script defer src="https://use.fontawesome.com/releases/v5.0.3/js/v4-shims.js"></script>

That's better:

But if you've got the time and the inclination, skip the shim and change your icon classes to take advantage of the new, lighter styles. If I change all the icons in the same from fa to far we get this:

That's one of the other big changes. FontAwesome has lots more icons, but to get all of them, you'll need to buy the PRO version starting at $60 for 5 seats. I think that's a good deal, but the old icons are still free if you only need those.

Finally, some icons changed names, and you'll need to swap them out if you don't want to use the shim.

Cache busting with RequireJS and R.js in an ASP.NET MVC app

Sat, 31 May 2014 00:39:24 Z

Browser caching is great, except when it's not. What if you deploy a new version to production, but the fix you made to a JavaScript or CSS file isn't showing up? How can we force the browser to download files at least once with each build?

In previous posts, I showed how to use RequireJS in an MVC app, and how to optimize JavaScript and CSS using r.js in that project. Now we'll tackle cache busting to fix this problem.

The code for this project is available for view/download on GitHub.

Concept

We're going to put a small query string on every optimized JavaScript and CSS file with a unique code tied to that deployment. I'll use the build number of the main web assembly, since that's easy to get. The pattern will be like:

/Scripts-Build/app/main-fileName.js?v=1234

If you don't like using the build number for whatever reason, you can use anything you like, as long as it it changes when you build or deploy the files, but doesn't change all the time. So something like a build date makes sense, but not the current date/time, because that will always be different on each request.

Finally, be aware this is not a perfect solution. If someone is sitting behind a proxy server, they may not see the changes IF the proxy server doesn't honor the query strings and refetch the files. If that applies in your situation, you may need a path and some extra routing work to get past the proxy with something like:

/Scripts-Build/app/1234/main-fileName.js

I'll only be showing the build version style, and I've found that works in most situations.

Getting the build version

This is not the kind of code you write very often, but here's how I got the build number from the current assembly:

using System.Globalization; using System.Reflection; using System.Web; using System.Web.Caching; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class ApplicationVersionHelpers { private const string _assemblyRevisionNumberKey = "AssemblyRevisionNumber"; public static string AssemblyRevisionNumber(this HtmlHelper helper) { #if (DEBUG) return string.Empty; #else if (HttpRuntime.Cache[_assemblyRevisionNumberKey] == null) { var assembly = Assembly.GetExecutingAssembly(); var assemblyRevisionNumber = assembly.GetName().Version.Revision.ToString(CultureInfo.InvariantCulture); HttpRuntime.Cache.Insert(_assemblyRevisionNumberKey, assemblyRevisionNumber, new CacheDependency(assembly.Location)); } return HttpRuntime.Cache[_assemblyRevisionNumberKey] as string;
#endif } } }

We are just returning an empty string in Debug mode. In Release mode, we are caching the build revision number so we don't have to re-lookup that value every time we request it.

Now we need a way to access this version number from JavaScript. Let's put this version number in a global variable inside _Layout.cshtml in the <head> section so it's available on every page.

<script>var version = "@Html.AssemblyRevisionNumber()";</script>

We all know global variables are a sin, so paste it in and say your penance.

Using the build version

In the previous post, we had a PathHelpers.cs file that toggled between the /Scripts and the /Scripts-Build and between the /Styles and the /Styles-Build folders. We need to update that to use our version number based on Debug/Release build mode:

using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class PathHelpers { public static string ScriptsPath(this HtmlHelper helper, string pathWithoutScripts) { var fullPath = ""; #if (DEBUG) var scriptsPath = "_{/Scripts/"; fullPath = VirtualPathUtility.ToAbsolute(scriptsPath + pathWithoutScripts); #else var scriptsPath = "}/Scripts-Build/"; fullPath = VirtualPathUtility.ToAbsolute(scriptsPath + pathWithoutScripts + "?v=" + helper.AssemblyRevisionNumber()); #endif return fullPath; } public static string StylesPath(this HtmlHelper helper, string pathWithoutStyles) { var fullPath = "";
#if (DEBUG) var stylesPath = "_{/Styles/"; fullPath = VirtualPathUtility.ToAbsolute(stylesPath + pathWithoutStyles); #else var stylesPath = "}/Styles-Build/"; fullPath = VirtualPathUtility.ToAbsolute(stylesPath + pathWithoutStyles + "?v=" + helper.AssemblyRevisionNumber()); #endif return fullPath; } } }

This covers the _Layout.cshtml scripts, but we also need to update RequireJsHelpers.cs, our helper that is used for page-level scripts and pulls in main.js:

using System; using System.Text; using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class RequireJsHelpers { public static MvcHtmlString InitPageMainModule(this HtmlHelper helper, string pageModule) { var require = new StringBuilder(); #if (DEBUG) var scriptsPath = "_{/Scripts/"; #else var scriptsPath = "}/Scripts-Build/"; #endif var absolutePath = VirtualPathUtility.ToAbsolute(scriptsPath); require.AppendLine("<script>"); #if (DEBUG) require.AppendFormat(" require(["{0}main.js"]," + Environment.NewLine, absolutePath); #else require.AppendFormat(" require(["{0}main.js?v={1}"]," + Environment.NewLine, absolutePath, helper.AssemblyRevisionNumber()); #endif require.AppendLine(" function() {"); require.AppendFormat(" require(["{0}", "domReady!"]);" + Environment.NewLine, pageModule); require.AppendLine(" }"); require.AppendLine(" );"); require.AppendLine("</script>"); return new MvcHtmlString(require.ToString()); } }
}

Both of these now put ?v=1234 in the JavaScript or CSS path.

We still need to do some work so our /app and /lib scripts get the same treatment. We'll do that in main.js by adding this line:

urlArgs: version === "" ? "" : "v=" + version

Remember our awful global variable "version" in _Layout.cshtml? This is where it's being used. In my main.js file, I have this right under the baseUrl setting:

require.config({ baseUrl: "/Scripts/app", urlArgs: version === "" ? "" : "v=" + version paths: { jquery: "../lib/jquery-2.1.1", jqueryValidate: "../lib/jquery.validate", jqueryValidateUnobtrusive: "../lib/jquery.validate.unobtrusive", bootstrap: "../lib/bootstrap", moment: "../lib/moment", domReady: "../lib/domReady", }, shim: { jqueryValidate: ["jquery"], jqueryValidateUnobtrusive: ["jquery", "jqueryValidate"] } });
require(["kickoff"], function(kickoff) { kickoff.init(); } );

Now you should be able to run the web app in Release mode and get this, with ?v=1234:

Or run in Debug mode and get this, without the bundling, minification, and the extra query string stuff:

If you get this far and your build version in the query strings is 0, you need to update your AssemblyInfo.cs file:

[assembly: AssemblyVersion("1.0.*")]

The * is the auto increment of the build revision number.

Optimizing bundle size with Telerik ASP.NET Core controls, Bootstrap, and Webpack

Mon, 21 Dec 2020 07:45:51 Z

I am working on a mobile web application project using Telerik ASP.NET Core controls. These are the C# equivalent of the Kendo UI JavaScript controls. In fact, the Telerik ASP.NET Core controls are really Razor and tag helper wrappers that emit JavaScript to the browser to save you from the trouble of writing the JavaScript yourself.

Because this is a mobile web app that will be used in the field, we want fast page download speeds. Having worked with Kendo UI before, I knew I could import only the components I needed, rather than pull in code for sliders and other components not used in this app.

We are also using webpack and import only the JavaScript for the Telerik components used in each module.

Styles

In this project, we have a variables.scss file where we keep the common Sass variables, a site.scss files with the site-specific styles and overrides, and a common.scss file that brings these two project Sass files together with the vendor files - in this case, Bootstrap and Kendo UI styles.

Notice we are pulling in all Bootstrap styles, but we are not importing every Kendo UI styles or a combined file with all the Kendo UI styles for all the components. We are using only a handful of Kendo UI components in this app, so we don't want the extra weight of all those styles that will never be used in the app.

// All variables @import "variables"; // Bootstrap @import "node_modules/bootstrap/scss/bootstrap"; // Kendo UI @import "node_modules/@progress/kendo-theme-bootstrap/scss/autocomplete"; @import "node_modules/@progress/kendo-theme-bootstrap/scss/grid"; @import "node_modules/@progress/kendo-theme-bootstrap/scss/combobox"; @import "node_modules/@progress/kendo-theme-bootstrap/scss/datetime";
// Site @import "site";

Scripts

The webpack entry points for this web app are pages. It's a multi-page, not a single-page application. Here's what the home.js page script looks like. It imports the components it needs, which in turn import whatever they need. For this app, the home page is static and shows a splash, and that's about it.

import "common.scss"; import $ from "jquery"; import "components/top-menu"; import "components/header"; import "components/footer";

Here's the script for search.js a page that uses the Kendo UI autocomplete search and a gid to show search results. It also uses the Bootstrap alert module to show the user if there are no records found in the search.

Finally, I had to import @progress/kendo-ui/js/kendo.aspnetmvc in the page's JavaScript module. This is the secret sauce to get client-side behavior from server-side Telerik ASP.NET Core controls we used in Razor views (below).

import "common.scss"; import $ from "jquery"; import "components/top-menu"; import "components/header"; import "components/footer"; import "bootstrap/js/dist/alert"; import "@progress/kendo-ui/js/kendo.autocomplete"; import "@progress/kendo-ui/js/kendo.grid"; import "@progress/kendo-ui/js/kendo.aspnetmvc";

Razor

The Razor views were like normal ASP.NET Razor views or pages, but with client-side behavior coming from the page's import "@progress/kendo-ui/js/kendo.aspnetmvc";. This means you can sort or filter the results in a grid without a server call, but you don't have to write all the JavaScript client code to handle that.

We tried the Telerik ASP.NET Core control tag-helpers, and I kind of prefer the syntax, but we quickly found there were not enough examples on the Telerik site or out in the wild to figure out the API. Guessing got pretty old pretty fast, so we went to the more traditional HTML helper syntac in the Razor code.

<form id="searchForm" asp-controller="Search" asp-action="Index" method="post"> <div class="input-group"> @( Html.Kendo().AutoComplete() .Name("searchText") .DataTextField("HitString") .HtmlAttributes(new {@class="form-control"}) .DataSource(source => { source.Read(read => { read.Action("GetAutoCompleteAccounts", "Search").Data("() => { return { text: $('#searchText').val() }; }"); }).ServerFiltering(true); }) .Placeholder("Address, Owner Name, Legal Description, Account Number, or Parcel Number") .Value(Model) .Filter(FilterType.Contains) .MinLength(2) ) <div class="input-group-append"> <button type="submit" class="btn btn-primary text-light"> <span class="fas fa-search"></span> Search </button> </div> </div> </form>

Optimizing

When webpack starts build the entry points, in this case, home.js and search.js, it grabs only the styles in common.scss and only the modules in the pages and the components they use, so we get a smaller bundle than if we put style and script links in the <head> section of the _Layout.cshtml page.

Getting the SQL and Parameters out of Dapper for display in Glimpse

Mon, 02 Sep 2013 22:49:00 Z

Glimpse is a really nice tracing and diagnostic tool for what's happening on the server in an ASP.NET app.

It has a tab for showing the SQL and the query parameters being passed to SQL Server, but my tab looked like this when using Dapper dot net, a light-weight ORM that takes your SQL result and maps it to a C# object:

I knew Glimpse worked with ADO.NET, I had installed that plugin, and Dapper was using ADO.NET somewhere inside its framework, but my SQL tab was disabled. I thought maybe I needed to install a Glimpse Dapper plugin, but there was none on the official Glimpse plugins page.

I found this unofficial Glimpse Dapper plugin, but it still seemed like it was trying too hard. This should be easier.

I was getting my Dapper SQL connection through a factory like this:

public static class ConnectionFactory { public static IDbConnection CreateConnection(string connectionString) { var cnn = new SqlConnection(connectionString); cnn.Open(); return cnn; }
}

I finally found the Glimpse ADO integration help, and it said, "If you're not using an ADO connection that uses the DbProviderFactories class, Glimpse won't collect any data for the SQL tab (out of the box)."

Oh. Ok. So I changed my code to this:

public static class ConnectionFactory { public static IDbConnection CreateConnection(string connectionString) { var factory = DbProviderFactories.GetFactory("System.Data.SqlClient"); var cnn = factory.CreateConnection(); cnn.ConnectionString = connectionString; cnn.Open(); return cnn; }
}

and now the SQL and parameters are showing on the Glimpse SQL tab:

Yay!

Evolution of a View in ASP.NET MVC

Tue, 08 Dec 2009 05:00:00 Z

Many developers prefer working with ASP.NET MVC over Web Forms because they are more connected with the HTML, have better control over the rendered output, and can easily build their own HTML helpers to get consistent output.

But making the views can be a hassle when your building a CRUD app or something that has a lot of very similar views. Let's look at some ways around that you can use today and in the future.

Past

When MVC first came out, most people were coding their inputs in views like this. Just straight HTML with some helpers:

<% using (Html.BeginForm()) { %> <fieldset> <label for="Name">Name</label> <%= Html.TextBox("Name") %> <label for="Email">Email address</label> <%= Html.TextBox("Email") %> <label for="Phone">Phone</label> <%= Html.TextBox("Phone") %> <%= Html.SubmitButton() %> </fieldset> <% } %>

Simple, but a little too much reliance on strings. This made the code error prone, so developers made their own HTML Helpers to crank out consistent views with fewer strings by using lambda expressions:

<% using (Html.BeginForm()) { %> <fieldset> <label for="Name">Name</label> <%= Html.TextBoxFor(c => c.Name) %> <label for="Email">Email address</label> <%= Html.TextBoxFor(c => c.Email) %> <label for="Phone">Phone</label> <%= Html.TextBoxFor(c => c.Phone) %> <%= Html.SubmitButton() %> </fieldset> <% } %>

That's better. We get IntelliSense for the model's fields and we get the leave some of the strings behind.

Present

The next step was to get rid of some of those label statements and get those rolled into the output automatically. They did this in Code Camp Server and you can see the step-by-step progression in Eric Hexter's blog:

<% using (Html.BeginForm()) { %> <fieldset> <%= Html.Input(c => c.Name) %> <%= Html.Input(c => c.Email) %> <%= Html.Input(c => c.Phone) %> <%= Html.SubmitButton() %> </fieldset> <% } %>

Nice! Now we're on the road to consistent output in all forms in our MVC app and we won't spend as much time typing up view code. Eric even shows us he can name that view in one note:

<%= Html.InputForm() %>

Future

If you've been following the latest on ASP.NET MVC, you've seen the announcement for MVC 2 Preview 1 here, here, and here. Microsoft is going the same direction as these open-source extensions and making it easier to get a consistent view rendered:

<% using (Html.BeginForm()) { %> <fieldset> <%= Html.LabelFor(c => c.Name) %> <%= Html.EditorFor(c => c.Name) %> <%= Html.LabelFor(c => c.Email) %> <%= Html.EditorFor(c => c.Email) %> <%= Html.LabelFor(c => c.Phone) %> <%= Html.EditorFor(c => c.Phone) %> <%= Html.SubmitButton() %> </fieldset> <% } %>

MVC 2 also has an almost one-liner form that you define with templates, one of the new features:

<% using (Html.BeginForm()) { %> <fieldset> <%= Html.EditorFor(c => c) %> <%= Html.SubmitButton() %> </fieldset> <% } %>

So we've seen views getting simpler and smaller and even one-line forms. Can it get any smaller than a one-line form? What if there was no view? Can you have a view with zero lines of code?

Kind of. Phil Haack took the MVC 2 Preview 1 code out for a spin to try what he calls "default templated views". The idea is that your controller gets a model and displays a virtual view by using templates from your web project's "~\Views\Shared" folder. You can make as many templates as you need for different purposes.

This is ideal for CRUD apps or places in your app where the view is the same except for the model data it renders. You don't need a physical file for each view other than the template itself. The controller just renders a view that is one of the shared views/templates.

I like this approach because you can crank out code more quickly for the easy stuff, but if you have a view that needs something more complex, you still have the normal HTML inputs and helpers to fall back on. I hope Microsoft gets this idea fully flushed out and it ends up in the final MVC 2 release. It would make developers more productive on repetitive views and would have wider acceptance if it was in the MVC base-class libraries.

Combining batch edit and detail template edit on a Kendo UI grid

Sat, 13 Feb 2021 07:11:25 Z

A client recently asked for something I didn't know a Kendo UI grid could do. They wanted both batch edit and a detail/expand edit of the same record in the grid.

They liked the Excel-like editing experience of working in batch mode, where you make a bunch of edits and send all the changes at once. But they also wanted several UI features in the expanded/detail view that don't make sense in a grid row (e.g., charts, hyperlinks, buttons to calculate things, etc.). The idea was that users could use whatever fit their needs or preference, then save all grid changes as usual in a batch.

I got it mostly working with this code, which is using this HTML and JavaScript: https://jsfiddle.net/joewilson0/jwcLhtg2/

<div id="myGrid"></div>
<script type="text/x-kendo-template" id="myDetailTemplate"> <div class="form-group"> <label for="testNumber">Test Number</label> <input name="testNumber" class="form-control w-25" data-bind="value: testNumber" /> </div> <div class="form-group"> <label for="testString">Test String</label> <input name="testString" class="form-control w-25" data-bind="value: testString" /> </div> <div class="form-group"> <label for="testDate" class="d-block">Test Date</label> <input name="testDate" class="form-control" data-bind="value: testDate" data-role="datepicker" /> </div> </script>

$(document).ready(() => { const testData = [ { testNumber: 123, testString: "apple", testDate: new Date(2020, 10, 14) }, { testNumber: 456, testString: "pear", testDate: new Date(2020, 10, 15) }, { testNumber: 789, testString: "plum", testDate: new Date(2020, 10, 16) }, ]; $("#myGrid").kendoGrid({ dataSource: { data: testData, schema: { model: { fields: { testNumber: { type: "number" }, testString: { type: "string" }, testDate: { type: "date" } } } } }, columns: [ { field: "testNumber", title: "Test Number" }, { field: "testString", title: "Test String" }, { field: "testDate", title: "Test Date", format: "{0:d}" } ], editable: true, detailTemplate: kendo.template($("#myDetailTemplate").html()), detailInit: event => kendo.bind(event.detailRow, event.data) }); });

This line is the key to having the grid row and the expanded view share the same view model:

detailInit: event => kendo.bind(event.detailRow, event.data)

Now when you change a value in the grid row, it updates immediately in the expanded row. Great! But when you do the reverse, and update the expanded row value, the grid row updates, but the expanded row immediately collapses. Arg!

The fix to prevent closing the expanded row was to ignore the itemchange action in the dataBinding event:

function dataBinding(event) { // Prevent closing the expanded detail row when the itemchange action in the databinding event is fired so it doesn't close the expanded view if (event.action === "itemchange") { event.preventDefault(); } }

But this workaround fixes one thing and breaks another. Now the row doesn't collapse every time you change a value in the expanded view, but it also doesn't update the grid row values when you collapse because you just short-circuited that event.

To fix this new problem, I added a "Done" button to the template that collapses the expanded row and wired up a function to repaint the values in the grid row on collapse.

<button class="btn btn-secondary btn-collapse">Done</button>

If the user changes 3 things in the expanded view and keeps the expanded view open, the grid row still shows the original, unchanged values. Once the user clicks the "Done" button or collapses the expanded view with the icon on the left, the grid row is repainted with the values from the shared view model.

function repaintRow(row) { const grid = $(row).closest(".k-grid").data("kendoGrid"); const dataItem = grid.dataItem(row); const rowChildren = $(row).children("td[role='gridcell']"); for (let i = 0; i < grid.columns.length; i++) { const column = grid.columns[i]; const template = column.template; const cell = rowChildren.eq(i); if (column.field !== undefined) { if (template !== undefined) { // Handle templated columns const kendoTemplate = kendo.template(template); cell.html(kendoTemplate(dataItem)); } else { const fieldValue = dataItem[column.field]; const format = column.format; const values = column.values; if (fieldValue && values) { // Handle drop downs for (let j = 0; j < values.length; j++) { const value = values[j]; if (value.value === fieldValue.toString()) { cell.html(value.text); break; } } } else if (format !== undefined) { // Handle formatted columns (like dates and currency) cell.html(kendo.format(format, fieldValue)); } else { // Handle unformatted, untemplated, non-drop down values cell.html(fieldValue); } } } }
}

Now we have to wire up the Kendo UI grid and button events:

$("#myGrid").kendoGrid({ ...other grid settings... detailInit: detailInit, detailCollapse: detailCollapse, dataBinding: dataBinding, ...other grid settings... }); function detailInit(event) { const grid = $(event.masterRow).closest(".k-grid").data("kendoGrid"); const masterRow = event.masterRow; const detailRow = event.detailRow; // Bind the expanded view (detailRow) to the values in the master row kendo.bind(detailRow, event.data); // Handle the detail row "Done" button click detailRow.find(".btn-collapse").click(() => grid.collapseRow(masterRow));
}

Here's the final working version that keeps the Kendo UI grid row and the expanded view in sync: https://jsfiddle.net/joewilson0/e3p70jac/2/

Do we still need coding standards?

Thu, 08 Jul 2010 00:40:47 Z

The dark ages

I used to be really big on coding standards in the late 1990's. It was so easy to slip into spaghetti code in classic ASP and VB6, and at the time, the best antidote was rigid standards and uncompromising code reviews.

I was a hard ass about our coding standards. Then, as now, the rationale was that coding standards would make the code easier to read and maintain in the inevitable and long maintenance phase.

The development process we used at the time was to stand around the white board and talk about the development tasks, then the developers would go off and separately code it up. That was the other reason the coding standards mattered - we didn't want two code files to look totally different if written by different developers.

My teams used the naming conventions Microsoft came up with for Access/VBA/VB, including Hungarian notation prefixes, but a lot of the standards were about code comments, error handling code, whitespace and indenting, etc.

.NET comes on the scene

Fast forward maybe 5 or so years to the introduction of .NET and C#, and coding changed. ASP.NET HTML didn't require <% %> tags anymore. We could put the C# in code behind files and other project files. We didn't need On Error anymore, we had Try-Catch. XML comments seemed like a cool feature to show Intellisense drop downs for code you wrote in addition to framework Intellisense.

So we updated our coding standards to reflect the language and IDE changes, but they became more like guidelines instead of hard and fast rules. By convention, we would avoid the spaghetti code just by keeping the right code in the right place. Hungarian notation went away (slowly but surely). The coding standards document was mostly reference code snippets and justifications for the conventions we used. Code reviews became less common because it wasn't as big of an issue.

Today

A lot has changed since .NET first came out, and I code differently now. I'm trying to make my code a lot more terse these days. I'm a big fan of having clean, succinct, expressive code. The fewer non-essential things on the screen to wade through, the better. It's more readable and easier to refactor.

I could put Try-Catch blocks everywhere, but isn't it simpler to catch unhandled exceptions in one place.

I could add XML comments, but why? It's either code in my same web project or a project that is owned by my solution. I don't usually work on common library code where an assembly will be used across projects and Intellisense might be needed.

I don't put the variable type on the left side of the equal sign anymore and use "var" instead.

I've walked away from code regions and just order the items in the class file by convention. ReSharper likes to put new fields under the last field declaration in the class, so region wrapping all the fields in a class with "#region Fields" just wastes time when refactoring to pull it back up into the region.

Not only has the way I code changed, but the tools have changed. ReSharper code cleanup templates and StyleCop warnings can be used to keep your team writing code in a style that you've all agreed on. Just run the tool and have it clean up the code for you or flag code that doesn't meet the style guidelines.

Having tests around the code lets me refactor and use auto-code-cleanup tools freely. I understand the project a little more fully every day, so I can rename my class, method, and variable names to be more descriptive and accurate without worrying about breaking code.

I'm also doing more pair programming these days, and this is a good way to enforce and socialize team coding styles. It also means we don't have to refer to a coding standards document as often. Since we're more story-focused, we're thinking more about the feature and less about coding style. Taking ceremony code off the screen helps us keep that focus.

If I had to do it over

If I was going to write a coding standards document today, it would be more like a style guide to reflect my current less-is-more thinking, and I'd probably give my peers a ReSharper template to auto-clean their code as they go instead of a document to refer to. StyleCop for ReSharper looks promising as a gentle background reminder of team coding styles.

What about your team? Do you have a coding standards document people refer to? Do you use tools to enforce standards/styles? Does your code tell a story other developers can read?

Making spiffy buttons with CSS and MVC Razor helpers

Sun, 16 Sep 2012 06:07:00 Z

For most web apps, gray buttons with black text is fine. But if you take some time to jazz up your buttons a little, you are making your app a little nicer to use and giving your users small visual cues to let them know their options.

Going from this:

to this:

with hover colors of green and red, which, in the U.S. at least, usually mean "go" and "stop", can be just enough of a nudge to help your users and make them just a little happier. Here's how I built these.

Credit

The bulk of the concept and CSS work for this came from someone else, but I can't remember who anymore. It's been over a year since I started using this technique. It might be from an old version of HTML5 Boilerplate, Blueprint CSS, 960 Grid System, or something Rob Conery did on TekPub. I wish I could give more specific attribution, but it was probably one of these. My main contributions have been some CSS tweaks, the JavaScript, and the MVC Razor helpers.

HTML and images

This is what we're going for as the emitted HTML. We want these "buttons" to really be hyperlinks, not HTML buttons, so we don't have as much browser style sheet nonsense getting in the way.

This does add some complexity for submitting, which has to be done with JavaScript now, but the same script (see below) can be used throughout the app.

The positive CSS class gives the green hover effect, and the negative one gives the red effect.

<div class="buttons"> <a href="#" class="button positive"> <img width="16" height="16" src="/Content/Images/Icons/tick.png" alt=""> Save </a> <a href="https://volaresoftware.com/en/posts/archive" class="button negative"> <img width="16" height="16" src="/Content/Images/Icons/cross.png" alt=""> Cancel </a> </div>

The icons I used are from the Silk Icons collection. There are lots of great icon libraries out there, so use your favorite. Anything 16x16 should work, but you can go bigger or smaller and adjust the CSS and HtmlHelper tags.

JavaScript/jQuery

An anchor tag with a href to "#" won't get your values submitted back to the server, so we'll use some JavaScript and a touch of jQuery for that. You'll want to include this script on every page where you're using these buttons.

$(function () { global.initButtons(); });
var global = { initButtons: function () { $('a.button.positive').click(function (e) { e.preventDefault(); var parentForm = $(this).closest('form'); if (!parentForm.valid()) { global.flashMessage('Error validating these values', 'error'); } else { $(this).css(global.disableCss).unbind('click'); parentForm.submit(); } }); }, disableCss: { opacity: 0.5, display: 'inline-block' } };

CSS

The CSS for this is pretty simple. The div.buttons puts the buttons on one line and give a little vertical space around them. The .button and .button img styles do most of the work, with block styling, light and medium gray borders, a light gray background, some padding around the text and icon to fatten the button up a little, margins so there is space before the next adjacent button on the right, and a small shadow effect.

The :hover effects are where the color is flipped to darker gray, green, or red, with corresponding border colors.

/*--------------------------*/ /* Buttons /*--------------------------*/ div.buttons { display: inline-block; margin: 10px 0; } .button { display: block; float: left; border-top: 1px solid #CCC; border-left: 1px solid #CCC; border-bottom: 1px solid #AAA; border-right: 1px solid #AAA; background-color: #E3E3E3; font-family: Verdana, Helvetica, sans-serif; font-size: 100%; line-height: 110%; text-decoration: none !important; color: #333 !important; margin: 0 15px 0 0; padding: 5px 10px 5px 7px; cursor: pointer; box-shadow: 1px 1px 2px #969696; -moz-box-shadow: 1px 1px 2px #969696; /* Firefox */ -webkit-box-shadow: 1px 1px 2px #969696; /* Safari and Chrome */ } .button img { margin: 0 3px -3px 0 !important; padding: 0; border: none; width: 16px; height: 16px; float: none; } /--------------------------/ /* Button colors - Standard /--------------------------/ .button:hover { border: 1px solid #999; background-color: #D6D6D6; color: #333 !important; } /--------------------------/ /* Button colors - Positive /--------------------------/ .positive:hover { background-color: #E6EFC2; border: 1px solid #C6D880; color: #264409 !important; }
/--------------------------/ /* Button colors - Negative /--------------------------/ .negative:hover { background-color: #FBE3E4; border: 1px solid #FBC2C4; color: #8A1F11 !important; }

MVC Razor HtmlHelpers

So now we know the HTML and CSS we want. You could stop there and code your MVC views with that HTML. But if you want your Razor views to be able to user simple helpers like this, keep reading.

<div class="buttons"> @Html.LinkButtonForSave() @Html.LinkButtonForCancel() </div>

The helpers here have two public entry points, LinkButtonForSave and LinkButtonForCancel. The rest of the code is refactoring out some of the route parsing and tag building work. It's probably overkill for just these two methods, but it makes sense when you keep adding helpers for other buttons, like add, edit, delete, confirm, print, etc.

using System.Web; using System.Web.Mvc; namespace Extensions { public static class ButtonHelpers { public static MvcHtmlString LinkButtonForSave(this HtmlHelper helper) { var imageTag = ImageTag("tick.png"); var anchorHtml = FormSubmitAnchorTag(imageTag, "Save"); return MvcHtmlString.Create(anchorHtml); } public static MvcHtmlString LinkButtonForCancel(this HtmlHelper helper) { var areaName = AreaName(helper); var controllerName = ControllerName(helper); var imageTag = ImageTag("cross.png"); var anchorHtml = AnchorTagWithImageAndText(areaName, controllerName, "Index", null, "button negative", imageTag, "Cancel"); return MvcHtmlString.Create(anchorHtml); } private static TagBuilder ImageTag(string iconName) { var imageTag = new TagBuilder("img"); imageTag.MergeAttribute("src", VirtualPathUtility.ToAbsolute(string.Format("~/Content/Images/Icons/{0}", iconName))); imageTag.MergeAttribute("width", "16"); imageTag.MergeAttribute("height", "16"); imageTag.MergeAttribute("alt", ""); return imageTag; } private static string AreaName(HtmlHelper helper) { var routeData = helper.ViewContext.RouteData; return routeData.DataTokens["area"] == null ? string.Empty : routeData.DataTokens["area"].ToString(); } private static string ControllerName(HtmlHelper helper) { var routeData = helper.ViewContext.RouteData; return routeData.GetRequiredString("controller"); } private static string FormSubmitAnchorTag(TagBuilder imageTag, string anchorText) { var anchorTag = new TagBuilder("a"); anchorTag.MergeAttribute("href", "#"); anchorTag.AddCssClass("button positive"); anchorTag.InnerHtml = imageTag.ToString(TagRenderMode.SelfClosing) + anchorText; return anchorTag.ToString(); } private static string AnchorTagWithImageAndText(string areaName, string controllerName, string actionName, int? id, string cssClass, TagBuilder imageTag, string anchorText) { var anchorTag = new TagBuilder("a"); if (areaName != string.Empty) { anchorTag.MergeAttribute("href", id == null ? string.Format("/{0}/{1}/{2}", areaName, controllerName, actionName) : string.Format("/{0}/{1}/{2}/{3}", areaName, controllerName, actionName, id)); } else { anchorTag.MergeAttribute("href", id == null ? string.Format("/{0}/{1}", controllerName, actionName) : string.Format("/{0}/{1}/{2}", controllerName, actionName, id)); } anchorTag.AddCssClass(cssClass); anchorTag.InnerHtml = imageTag.ToString(TagRenderMode.SelfClosing) + anchorText; return anchorTag.ToString(); } }
}

Using the Should assembly for testing

Tue, 24 Aug 2010 00:40:45 Z

Should is a .NET assembly of extension methods for building easy to write and easy to read assert statements. The advantage of using this assembly is the syntax is more clear and more like human language. It's free, open source, and it doesn't matter if you're using NUnit or MSTest or any test runner (Test Driven .NET, ReSharper, etc.). The project is in Beta 1.1, but I've used it on a couple of projects now with no problems.

I've never really liked the MSTest way of doing an assert. The whole expected and actual arguments always seemed flipped around to me.

// Assert Assert.AreEqual("eggs", breakfast.Foods.First()); Assert.AreEqual("bacon", breakfast.Foods.Last());

Instead, just reference the Should assembly and add the

using Should;

statement to the top of your test code and you can change it to:

// Assert breakfast.Foods.First().ShouldEqual("eggs"); breakfast.Foods.Last().ShouldEqual("bacon");

I think one of the tricks to writing good tests is to have code that is dead simple to read when you come back to it much later. The Should assembly gives you that.

Here are some other calls from the CodePlex home page for the project:

public void Should_String_assertions() { var obj = new object(); obj.ShouldBeInRange(1,2); obj.ShouldBeNull(); obj.ShouldBeSameAs(new object()); obj.ShouldBeType(typeof (object)); obj.ShouldEqual(obj); obj.ShouldNotBeInRange(1,2); obj.ShouldNotBeNull(); obj.ShouldNotBeSameAs(new object()); obj.ShouldNotBeType(typeof(string)); obj.ShouldNotEqual("foo"); "This String".ShouldContain("this"); "This String".ShouldNotBeEmpty(); "This String".ShouldNotContain("foobar"); false.ShouldBeFalse(); true.ShouldBeTrue(); var list = new List<object>(); list.ShouldBeEmpty(); list.ShouldNotContain(new object()); var item = new object(); list.Add(item); list.ShouldNotBeEmpty(); list.ShouldContain(item);
}

You should check it out!

Tree shaking with Font Awesome and webpack

Mon, 29 Jan 2018 06:30:00 Z

Font Awesome 5 has a new tree shaking feature that works with webpack's tree shaking. This is really helpful so you don't have to download one giant JavaScript file with a bunch of SVG icon definitions in it like:

<script defer src="https://use.fontawesome.com/releases/v5.0.6/js/all.js"></script>

Which gets you file sizes like below, where all.js is 657 KB (278 KB gzipped) and index.js is 88 bytes.

Instead, you can limit the file size to only the icons you use in your project through ES2015+ module imports and get file sizes like this, where all.js is gone and index.js is now 33.3 KB gzipped. We just saved 600+ KB (or about 250 KB gzipped)!

The Font Awesome team wrote some nice documentation on how to do this, but I didn't need to reference the shakable modules to get the smaller file size benefits. Here's how I got it working with Font Awesome 5 and webpack 3.

What worked

This is the HTML for the index.html test page.

<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Tree shaking with FontAwesome and webpack</title> <link href="https://volaresoftware.com/blog/node_modules/bootstrap/dist/css/bootstrap.min.css" rel="stylesheet" /> </head> <body> <div class="text-center" style="font-size: 24px; margin-top: 30px;"> <div class="row"> <div class="col-xs-2"> <div> <I class="far fa-calendar-alt"></I> </div> Calendar </div> <div class="col-xs-2"> <div> <I class="far fa-envelope"></I> </div> Email </div> <div class="col-xs-2"> <div> <I class="fas fa-arrow-up"></I> </div> Arrow Up </div> </div> </div> <script src="/dist/lib.js"></script> <script src="/dist/index.js"></script> </body> </html>

And this is index.js.

import fontawesome from "@fortawesome/fontawesome"; import farCalendar from "@fortawesome/fontawesome-free-regular/faCalendarAlt"; import farEnvelope from "@fortawesome/fontawesome-free-regular/faEnvelope"; import fasArrowUp from "@fortawesome/fontawesome-free-solid/faArrowUp";
fontawesome.library.add(farCalendar, farEnvelope, fasArrowUp);

In the markup, I'm pulling in lib.js, which webpack will figure out from the commons chunk (see below about what that is), and index.js, whose code is nothing but some icon imports.

In Font Awesome 5, you can now import a single icon, multiple icons, a full set of icons (the solid, regular, light, or brand sets), or every icon they make (free or pro). If you want the tree shaking and small file size benefit, you have to import the Font Awesome library and add your newly imported icons to the library before they can be used, like I've done above.

Here is the webpack.config.js file.

const webpack = require("webpack"); const path = require("path"); const CleanWebpackPlugin = require("clean-webpack-plugin"); const UglifyJsPlugin = require("uglifyjs-webpack-plugin");
module.exports = () => { return { entry: { index: "index.js" }, output: { filename: "[name].js", path: path.resolve(__dirname, "dist"), publicPath: "/dist" }, devtool: "source-map", plugins: [ new CleanWebpackPlugin(["dist"]), new webpack.optimize.CommonsChunkPlugin({ name: "lib" }), new UglifyJsPlugin({ sourceMap: true, uglifyOptions: }) ], resolve: { extensions: [ ".js" ], modules: [ path.resolve(__dirname, "scripts"), "node_modules" ] }, module: { rules: [ { test: /.js$/, exclude: /node_modules/, use: { loader: "babel-loader", options: { presets: ["env"], babelrc: false, cacheDirectory: true, plugins: [ "transform-runtime"] } } } ] } }; };

If you're used to seeing webpack.config files, there isn't anything too novel going on. If you aren't, here's the gist: There is one application entry point, index.js. Files will be output to the /dist folder. Source maps are turned on. We clean the /dist folder before a build. We have a commons chunk called lib.js, which means webpack figures out code shared across modules that can be extracted into a common file. We are minifying with UglifyJS and setting its source map flags to true also. We have the UglifyJS dead code (tree shaking) flag set to true, but I get the same results with or without that setting turned on. The resolve section tells webpack where to look for files, and the module rule we have set is to use Babel to load *.js files unless the file comes from the node_modules folder (so use Babel's loader for our projects' scripts).

I'm pretty happy with this, and for a project with a handful or even several handfuls of icons, it probably makes sense to import just the ones your project uses. One option is to make a selectedIcons.js file, set up all your imports and Font Awesome library additions there, and import selectedIcons.js in your single entry or for pages with icons if you have a multiple entries project.

What didn't work

The Font Awesome documentation describes some special modules you can set up through webpack.config aliases, and when you import from those files, you get tree shaking.

I changed the webpack.config.js resolve section to this.

resolve: { extensions: [ ".js" ], modules: [ path.resolve(__dirname, "scripts"), "node_modules" ], alias: { "@fortawesome/fontawesome-free-solid$": "@fortawesome/fontawesome-free-solid/shakable.es.js", "@fortawesome/fontawesome-free-regular$": "@fortawesome/fontawesome-free-regular/shakable.es.js" } },

Then I changed index.js to import with a different syntax.

import fontawesome from "@fortawesome/fontawesome"; import { faCalendarAlt, faEnvelope } from "@fortawesome/fontawesome-free-regular"; import faArrowUp from "@fortawesome/fontawesome-free-solid";
fontawesome.library.add(faCalendarAlt, faEnvelope, faArrowUp);

Then I re-built the code. The page still works, but the index.js file got waaaay bigger.

I don't know if I missed something in my webpack.config.js, or I've imported with the wrong syntax, or I've referenced the special shakable files incorrectly, but I couldn't get it working. If you see my mistake, please comment below and I'll update the post.

Either way, it works to import and add individual icons, and you get smaller files. All the code for this post can be found on GitHub.

Stop making hay

Sat, 25 Dec 2010 01:40:33 Z

Straw men

When test-driven development (TDD) or other test-first methods are first introduced, many people object with different variations of the same argument "if you can't test everything, it's flawed". People seem to get mentally stuck when they can't automate all test cases. Sometimes, the point gets really stretched, like, "What if the user enters a negative salary lower than int.MinValue? We don't have a test for that, do we?" or "What if the database or web server goes down? How do we do TDD for that?"

Darren Cauthon made this observation on Twitter a few months ago:

All these arguments are straw men, where an exaggeration or misrepresentation of the point is used to discount the entire thing.

Getting started

TDD won't make all your problems go away or all your dreams come true. It's something that takes a lot of practice to get better at it. I consider myself pretty mediocre at it. You will be slower at coding when you start out, but you will get faster, and I believe it is worth the investment in terms of the cleaner design it yields. The tests are nice, too. :>

The trick for me to getting started with TDD was to start small. This has also been the only way I've been able to do TDD successfully - in very small steps. Create one test for the happy path for the feature you are trying to implement. This usually has to be broken down into sub steps. Write the least amount of code you can write to get the test to pass. Once the test is passing, refactor the code to clean it up and add some polish. Then run your test again to make sure it still passes.

Unhappy paths

Occasionally test the unhappy paths, based on how likely they are and how important they are to the business. If your product owner isn't worried about int.MinValue, you shouldn't be. Move on to the next feature you're building.

You probably won't automate all your test cases, but that's OK. Your code will be decoupled, easier to refactor, and easier to read. Plus you will have automated tests for whatever percentage of tests cases you came up with.

There are far too many benefits to dismiss test-first approaches based on what it can't do well. So let's stop with the straw man arguments against test-first and start reaping the benefits.

Why bother writing unit tests?

Thu, 08 Oct 2009 00:41:38 Z

More developers are coming around to the idea of writing unit tests for their code. But not everyone is sold. Let's take a look at the arguments for just writing code and either manually testing or handing the app over to QA:

It takes too long to write unit tests.

This is really simple code. I could see maybe testing something complex, but this is just a CRUD app.

Write my tests before my code? Are you kidding me? I've always done it the other way and it's worked out just fine.

Let's take these one by one and see if they are still valid.

Time Argument

It doesn't take long to run the test. I think there is consensus there. But writing units tests and writing code is more lines of code than just writing the code. More lines = more time, right?

Sure, as long as manual testing is less than the automated testing over time. Not just the first time, but for the lifetime of that code.

If I'm using your old assembly from 2004 or web service from last month, I want some assurances it still works the way it was supposed to. If you knew the secret way to manually test it, but have forgotten it, I don't fully trust your code. I have to spend time going over that code and testing it out myself.

Code with a lifespan longer than your memory and availability to manually regression test it benefits from having a suite of unit tests that can be run in milliseconds.

Simplicity Argument

"If the code is really simple, there is no point in writing unit tests."

This is a good point. Unit testing can help work through complex code, but what if the code is really easy?

I agree that there isn't a need to bother testing setting and getting properties and methods that just call other methods. And please don't spend time testing code that is part of the .NET framework or an assembly you bought. That's a waste of time.

But if you're using test-driven development, you start with the functionality, not the implementation. So you write tests that cover the important/core stuff in your requirements. You don't bother testing properties and call wrappers, which are just technical artifacts of the important stuff you are coding. If it's the important stuff, shouldn't it be covered with unit tests?

TDD = My World Upside Down

"Writing test before writing code is crazy talk." I also have had a great career without doing this, so what's the point?

I agree it is crazy. I also agree it's a 180 on the conventional wisdom. And I completely agree that it's harder than just writing the code.

But here's where I depart from the TDD crowd. If you're new to unit testing, I just want you to write unit tests to cover the critical code for now. It might lead you to TDD at some point, it might not. But it's not an all or nothing thing. Let's just try to work in as many tests as we can and leave it there for now. How many tests do you need? What code coverage levels are you shooting for? That's up to you. If you feel good showing the code to your peers and are happy to be held accountable for the quality of your code, you're probably done.

I'll make the case for TDD another time. Just baby steps for now.

HtmlEncode and UrlEncode aren't the same thing

Sat, 29 Jan 2011 07:43:00 Z

The other day I was trying to pass an encoded version of id=123 to a customer's search API. I tried

var result = HttpUtility.HtmlEncode("id=123");

but it returned id=123. I stared at the screen, scratched my head, and jumped on Google.

A quick search reminded me that HtmlEncode is for escaping HTML, but it leaves everything else alone. So

var result = HttpUtility.HtmlEncode("<br/>");

returns <br/>. All the less thans and greater thans get escaped, but the rest is pretty much the same.

UrlEncode is for cases where you want to escape a URL, so

var result = HttpUtility.UrlEncode("id=123");

returns id%3d123, which is what I wanted in the first place. By comparison, if you UrlEncode the <br/> tag, like

var result = HttpUtility.UrlEncode("<br/>");

you'll get back %3cbr%2f%3e. It's encoding the less than, the slash, and the greater than, but it's encoding them with URL-type escapes instead of HTML-style ones.

I guess it's been a while since I paid attention to encoding. Not all encoding methods are equal in the ASP.NET framework, so be careful which one you use.

Resizing a Kendo UI drop down to fit its data without wrapping

Sat, 02 Feb 2013 13:19:00 Z

Telerik's Kendo UI Web makes a spiffy looking drop down with JavaScript and CSS.

The demos on the Telerik site show drop downs with default widths and not much text.

That breaks down when the text in the drop down gets longer because it wraps. I don't like this look.

So I wrote a JavaScript function that resizes the drop down to fit the width of the data so you avoid the wrapping and get:

Here's the JavaScript:

var resizeDropDown = function (e) { var $dropDown = $(e.sender.element), dataWidth = $dropDown.data("kendoDropDownList").list.width(), listWidth = dataWidth + 20, containerWidth = listWidth + 6; // Set widths to the new values $dropDown.data("kendoDropDownList").list.width(listWidth); $dropDown.closest(".k-widget").width(containerWidth);
}

You have to call this on the drop down's dataBound event. That way, if you're pulling remote data through something like Web API, you won't resize until you've gotten the data back and fired the dataBound event.

Here's a JSFiddle to play around with it. The fiddle shows two drop downs – one with the default sizing and wrapping, and the other with the resizeDropDown function called on the dataBound event.

<div> <label for="defaultSize">Default drop down</label> <select id="defaultSize"> <option id="1">Apress Pro ASP.NET MVC 4 Framework</option> <option id="2">Head First Object Oriented Analysus and Design</option> <option id="3">Working Effectively with Legacy Code</option> </select> </div> <div> <label for="resized">Resized drop down</label> <select id="resized"> <option id="1">Apress Pro ASP.NET MVC 4 Framework</option> <option id="2">Head First Object Oriented Analysus and Design</option> <option id="3">Working Effectively with Legacy Code</option> </select> </div>

var resizeDropDown = function (e) { var $dropDown = $(e.sender.element), dataWidth = $dropDown.data("kendoDropDownList").list.width(), listWidth = dataWidth + 20, containerWidth = listWidth + 6; // Set widths to the new values $dropDown.data("kendoDropDownList").list.width(listWidth); $dropDown.closest(".k-widget").width(containerWidth); } // Default implementation with Kendo CSS sizing $("#defaultSize").kendoDropDownList();
// Resized on data bound to the width of the data in the drop down $("#resized").kendoDropDownList();

Trim unused CSS selectors with PurifyCSS and webpack

Mon, 16 Apr 2018 21:49:00 Z

Most web sites use a CSS library like Bootstrap. It's great for getting started quickly and works well as an all-purpose style sheet.

But what about all the selectors in Bootstrap you aren't using in your app? What if you also add a Bootstrap theme and your own web app style overrides on top of that? All the used and unused styles go down to your users' browsers with every response.

If you can trim that down to only the styles your web app actually uses, you'll send down a much smaller style sheet, your site will run faster, and you'll save on bandwidth costs.

Here's how I did just that with PurifyCSS and webpack.

Install webpack and PurifyCSS

Once you've got Node and NPM up and running, install webpack 4.

npm install webpack webpack-cli --save-dev

Then install PurifyCSS and the MiniCssExtractPlugin, if you don't already have it set up.

npm install purify-css purifycss-webpack glob-all mini-css-extract-plugin --save-dev

Set up PurifyCSS in webpack.config.js

In your webpack.config.js file, add a reference to the MiniCssExtractPlugin, the PurifyCSS plugin, and a way to glob files.

const glob = require("glob-all"); const MiniCssExtractPlugin = require("mini-css-extract-plugin"); const PurifyCSSPlugin = require("purifycss-webpack");

Then set up your paths in PurifyCSS. These are the locations of the files that will contain your styles. PurifyCSS will statically scan these files for styles and reference them in the style sheet. Styles found in the markup or scripts are left in the final style sheet. Styles not found are removed. The algorithm for finding used styles is pretty sophisticated.

plugins: [ new MiniCssExtractPlugin({ filename: "[name].css" }), new PurifyCSSPlugin({ paths: glob.sync([ path.join(__dirname, "Views/**/*.cshtml"), path.join(__dirname, "Scripts/**/*.html"), path.join(__dirname, "Scripts/**/*.js") ]) }) ],

Here, I'm referencing my ASP.NET MVC Razor pages in Views/**/*.cshtml, my component templates in Scripts/**/*.html, and my project *.js files. Also note this plugin entry goes after the MiniCssExtractPlugin.

Add any whitelist exceptions

Even with it's fancy algorithm, PurifyCSS can still miss styles it should leave alone. To prevent PurifyCSS from removing them from the final CSS, use the whitelist option.

Here, I've got a project style sheet with two styles – one that should be removed because it is not referenced, and one that should be left in even though it isn't referenced.

.some-unused-class { color: red; }
.some-dynamic-class { color: red; }

To do this, I've added "*some-dynamic-class*" to the whitelist array so PurifyCSS won't remove it.

plugins: [ new MiniCssExtractPlugin({ filename: "[name].css" }), new PurifyCSSPlugin({ paths: glob.sync([ path.join(__dirname, "Views/**/*.cshtml"), path.join(__dirname, "Scripts/**/*.html"), path.join(__dirname, "Scripts/**/*.js") ]), purifyOptions: { whitelist: ["*some-dynamic-class*"] } }) ],

Results

In the sample project, I'm using Bootstrap and a very small app style sheet. Here are the result before PurifyCSS.

And here are the result after PurifyCSS.

The sample site is a one-page site with a carousel component that references Bootstrap CSS, and as you would expect, the KB trimmed from removing unused CSS selectors is significant.

Here is what happened with that class .some-dynamic-class I put in the PurifyCSS whitelist. The .some-unused-class selector is removed as we'd expect, and the .some-dynamic-class is still in the final CSS file at the bottom.

All this code is on GitHub if you want to see the package.json or full webpack.config.js or mess around with this yourself.

Tree shaking with Bootstrap 4 and webpack

Sat, 24 Feb 2018 19:48:00 Z

The simplest way to use Bootstrap 4 is to add the whole thing from the CDNs.

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css"> <title>Bootstrap Size Test</title> </head> <body> <div class="container"> <div class="row"> <div class="col-sm"> page </div> <div class="col-sm"> content </div> <div class="col-sm"> goes </div> <div class="col-sm"> here </div> </div> </div> <script src="//code.jquery.com/jquery-3.2.1.slim.min.js"></script> <script src="//cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.9/umd/popper.min.js"></script> <script src="//maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js"></script> </body> </html>

The problem is, you might not need everything Bootstrap has to offer. Adding the JavaScript like this adds 134.5 KB (ignoring gzipping for comparison below) to your page.

If you are using ES2015+ and the npm distribution, and you don't need the whole Bootstrap package, you can import just the code you need. Here's how.

Set up Bootstrap, Babel, and webpack

First, install Bootstrap, along with jQuery and Popper, which Bootstrap relies on. Then install webpack, along with tools to use ES2015+ syntax and minify JavaScript for distribution.

npm install bootstrap jquery popper.js npm install --save-dev webpack babel-core babel-loader babel-preset-env clean-webpack-plugin exports-loader path uglifyjs-webpack-plugin

Next, update your webpack.config.js to resolve the /node_modules folder. You're setting this up so your import statements know where to look when you reference Bootstrap modules.

You'll also need to use exports-loader with the webpack ProvidePlugin to export the expected values from the Bootstrap modules and their dependencies. This helps with globals some of the Bootstrap modules depend on, like $ for jQuery.

Finally, I've added an alias for jQuery to point to jquery.slim.min.js since that's enough jQuery functionality for Bootstrap to work. If you are already using the full jQuery in your project, skip this alias.

const webpack = require("webpack"); const path = require("path"); const CleanWebpackPlugin = require("clean-webpack-plugin"); const UglifyJsPlugin = require("uglifyjs-webpack-plugin");
module.exports = () => { return { entry: { index: "index.js" }, output: { filename: "[name].js", path: path.resolve(__dirname, "dist"), publicPath: "/dist" }, devtool: "source-map", plugins: [ new CleanWebpackPlugin(["dist"]), new webpack.ProvidePlugin({ $: "jquery", Popper: ["popper.js", "default"], Alert: "exports-loader?Alert!bootstrap/js/dist/alert", Button: "exports-loader?Button!bootstrap/js/dist/button", Carousel: "exports-loader?Carousel!bootstrap/js/dist/carousel", Collapse: "exports-loader?Collapse!bootstrap/js/dist/collapse", Dropdown: "exports-loader?Dropdown!bootstrap/js/dist/dropdown", Modal: "exports-loader?Modal!bootstrap/js/dist/modal", Popover: "exports-loader?Popover!bootstrap/js/dist/popover", Scrollspy: "exports-loader?Scrollspy!bootstrap/js/dist/scrollspy", Tab: "exports-loader?Tab!bootstrap/js/dist/tab", Tooltip: "exports-loader?Tooltip!bootstrap/js/dist/tooltip", Util: "exports-loader?Util!bootstrap/js/dist/util" }), new webpack.optimize.CommonsChunkPlugin({ name: "common" }), new UglifyJsPlugin({ sourceMap: true, uglifyOptions: }) ], resolve: { extensions: [ ".js" ], modules: [ path.resolve(__dirname, "scripts"), "node_modules" ], alias: { jquery: "jquery/dist/jquery.slim.min.js" } }, module: { rules: [ { test: /.js$/, exclude: /node_modules/, use: { loader: "babel-loader", options: { presets: ["env"] } } } ] } }; };

Import just the needed modules

Now you can import the Bootstrap style sheet from /node_modules, assuming you want the same styling on every page.

<link rel="stylesheet" href="https://volaresoftware.com/blog/node_modules/bootstrap/dist/css/bootstrap.min.css" />

You can also import Bootstrap styles from inside your webpack modules, but for most web apps, you'll want the same styling on all pages, and putting a link to the style sheet in the <head> is an easy way to do that.

Now you can write code that imports only the needed Bootstrap modules like this.

import "bootstrap/js/dist/carousel";

Let's say have a page that uses the Bootstrap carousel. Here's the HTML, including a reference to a webpack-built index.js from my /dist folder that only includes the carousel reference above.

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> <link rel="stylesheet" href="https://volaresoftware.com/blog/node_modules/bootstrap/dist/css/bootstrap.min.css" /> <title>Bootstrap Size Test</title> </head> <body> <div class="container"> <div id="carouselExampleIndicators" class="carousel slide" data-ride="carousel"> <ol class="carousel-indicators"> <li data-target="#carouselExampleIndicators" data-slide-to="0" class="active"></li> <li data-target="#carouselExampleIndicators" data-slide-to="1"></li> <li data-target="#carouselExampleIndicators" data-slide-to="2"></li> </ol> <div class="carousel-inner"> <div class="carousel-item active"> <img class="d-block w-100" data-src="holder.js/800x400?auto=yes&amp;bg=777&amp;fg=555&amp;text=First slide" alt="First slide [800x400]" src="data:image/svg+xml;charset=UTF-8,%3Csvg%20width%3D%22800%22%20height%3D%22400%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%20800%20400%22%20preserveAspectRatio%3D%22none%22%3E%3Cdefs%3E%3Cstyle%20type%3D%22text%2Fcss%22%3E%23holder_161c9dd15ef%20text%20%7B%20fill%3A%23555%3Bfont-weight%3Anormal%3Bfont-family%3AHelvetica%2C%20monospace%3Bfont-size%3A40pt%20%7D%20%3C%2Fstyle%3E%3C%2Fdefs%3E%3Cg%20id%3D%22holder_161c9dd15ef%22%3E%3Crect%20width%3D%22800%22%20height%3D%22400%22%20fill%3D%22%23777%22%3E%3C%2Frect%3E%3Cg%3E%3Ctext%20x%3D%22285.921875%22%20y%3D%22217.7%22%3EFirst%20slide%3C%2Ftext%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fsvg%3E" data-holder-rendered="true"> </div> <div class="carousel-item"> <img class="d-block w-100" data-src="holder.js/800x400?auto=yes&amp;bg=666&amp;fg=444&amp;text=Second slide" alt="Second slide [800x400]" src="data:image/svg+xml;charset=UTF-8,%3Csvg%20width%3D%22800%22%20height%3D%22400%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%20800%20400%22%20preserveAspectRatio%3D%22none%22%3E%3Cdefs%3E%3Cstyle%20type%3D%22text%2Fcss%22%3E%23holder_161c9dd15f3%20text%20%7B%20fill%3A%23444%3Bfont-weight%3Anormal%3Bfont-family%3AHelvetica%2C%20monospace%3Bfont-size%3A40pt%20%7D%20%3C%2Fstyle%3E%3C%2Fdefs%3E%3Cg%20id%3D%22holder_161c9dd15f3%22%3E%3Crect%20width%3D%22800%22%20height%3D%22400%22%20fill%3D%22%23666%22%3E%3C%2Frect%3E%3Cg%3E%3Ctext%20x%3D%22247.3203125%22%20y%3D%22217.7%22%3ESecond%20slide%3C%2Ftext%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fsvg%3E" data-holder-rendered="true"> </div> <div class="carousel-item"> <img class="d-block w-100" data-src="holder.js/800x400?auto=yes&amp;bg=555&amp;fg=333&amp;text=Third slide" alt="Third slide [800x400]" src="data:image/svg+xml;charset=UTF-8,%3Csvg%20width%3D%22800%22%20height%3D%22400%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%20800%20400%22%20preserveAspectRatio%3D%22none%22%3E%3Cdefs%3E%3Cstyle%20type%3D%22text%2Fcss%22%3E%23holder_161c9dd15f8%20text%20%7B%20fill%3A%23333%3Bfont-weight%3Anormal%3Bfont-family%3AHelvetica%2C%20monospace%3Bfont-size%3A40pt%20%7D%20%3C%2Fstyle%3E%3C%2Fdefs%3E%3Cg%20id%3D%22holder_161c9dd15f8%22%3E%3Crect%20width%3D%22800%22%20height%3D%22400%22%20fill%3D%22%23555%22%3E%3C%2Frect%3E%3Cg%3E%3Ctext%20x%3D%22277%22%20y%3D%22217.7%22%3EThird%20slide%3C%2Ftext%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fsvg%3E" data-holder-rendered="true"> </div> </div> <a class="carousel-control-prev" href="#carouselExampleIndicators" role="button" data-slide="prev"> <span class="carousel-control-prev-icon" aria-hidden="true"></span> <span class="sr-only">Previous</span> </a> <a class="carousel-control-next" href="#carouselExampleIndicators" role="button" data-slide="next"> <span class="carousel-control-next-icon" aria-hidden="true"></span> <span class="sr-only">Next</span> </a> </div> </div> <script src="/dist/common.js"></script> <script src="/dist/index.js"></script> </body> </html>

The page now uses the same full Bootstrap CSS, which accounts for most of the Bootstrap weight at 141 KB. But the size of the JavaScript is just over 76 KB, saving us about 58 KB from the original approach.

It is much simpler to pull in the full Bootstrap library, but if you need to squeeze out a little more performance or shrink your page weight a little more, pulling in only the Bootstrap libraries you need can help.

The sample code for this post is available on GitHub.

Setting Default Values for Multiple Value Parameters in Reporting Services

Sat, 02 Oct 2010 00:40:40 Z

Today I was working on a Reporting Services report that needed to have all the values checked for a multi-value parameter when the report opened up. It was a little tricky to figure out, but it turned out to be very simple in the end.

Multiple Value Parameters

I've got some multiple value parameters on a report. These are easy to create in SQL Server Reporting Services. Just check the box for your parameter and the user gets a check box drop down letting them pick more than one value from the drop down.

Available Values

You can set the available values for the drop down to a dataset in your report or a shared dataset in the Reporting Services project. Next, pick the value and name fields (which can be the same column in the dataset if that's what works in your situation).

Default Values

This is the part where we want to check each of those multiple values on report startup. The hard part is, I don't know the values at design time, so I can't hard code them. I want to simulate a "select all" of the check boxes. My mind started wandering to VBA code I could put in the report as a startup function.

But on a whim, I tried selecting all the values from the same query, and I was pleased to see it work!

And I get the results I want on the report when it opens:

Fixing screen saver wait time of 999 minutes on a Dell laptop

Thu, 10 Mar 2011 01:40:18 Z

I have a Dell Precision M4500 with Windows 7 and ran into a problem with the screen saver not coming on. Rebooting didn't fix it and calling Dell technical support didn't help ("You could reformat, I guess.").

My screen saver dialog looked like this with 999 minutes in the wait time:

If I clicked Preview, the screen would go blank like it was supposed to, so it wasn't a video card thing. When I set the wait time to 10 minutes and clicked OK, then opened the dialog box again, my value of 10 minutes was saved, but the screen saver never turned on.

Finally, I found this dialog in the Dell System and Manager under Display Settings:

See the "Disable alarms and timers for Presentations" check box? I had that checked, so I unchecked it and the screen saver started working normally again. I wasn't in Presentation mode, but this Dell app didn't seem to know that.

I hope this is helpful to someone stuck on the same issue.

SpecFlow and WatiN Worst Practices: What *NOT* to do

Sun, 06 Jan 2013 05:05:00 Z

The best way to learn something is to jump right in. Best practices don't really emerge until you've found out what works and what doesn't. This is my list of things that didn't work on my four SpecFlow and WatiN projects in the last two years. Of course, I'll also talk about what did work.

Acknowledgements

First off, almost everything I know about SpecFlow/Cucumber/Gherkin I learned from Paul Rayner and pairing with with him on two projects. I'm grateful for the experience and the knowledge gained.

I've also tried to glean as much as I can from Marcus Hammarberg, Darren Cauthon, Richard Lawrence, and Brandon Satrom in their twitter feeds and articles.

What level of your app should you test?

One big issue that comes up around SpecFlow is what level of your application should you be testing – internal or external. The answer has a big impact on how you write your feature files, what side benefits you get from the feature files, and the speed of your tests.

Developer-facing

You can use SpecFlow as a BDD-style tool and do unit or light integration testing with it. I call these developer-facing feature files, because they are expressed in language internal to the application ("Then I post the form values to the AccountController"). The nice thing about this is the readability of the test from the dev side and the speed of execution, since you are explicitly testing code internals.

Business-facing

But I think this misses an opportunity to have richer language in the feature files. If the SpecFlow features are worded the way the product owner sees the app working, you are fostering a ubiquitous language between the business and the developers. You have a clearer vision of your app's external behavior expressed through concrete examples.

You end up with "Then I click the save button" or even better, "Then I save" instead of "Then I post the form values to the AccountController". The bad thing about this style of spec wording is you end up testing through UI test automation tools like WatiN. This testing style is slow and can be buggy and fragile if you aren't careful (see below for tips).

In my experience, one of the main problems in software development is getting the dev team to understand what the business wants built and why. SpecFlow is a great tool for getting both sides together to define that behavior through examples.

Furthermore, UI testing becomes much more important as web applications take on more and more JavaScript and other client-side code. Since the external behavior of the app is how the business and users will evaluate the app, I think it makes sense to test at this level.

How not to set up your test project

Acceptance tests that drive the browser are not unit tests. They are closer to integration tests, but they are even slower, since your local web server and the browser have to spin up each time and fill out forms, click buttons, etc.

Because of this, don't add SpecFlow to your current unit test project or even your current integration test project, if you separate those. Let it live in its own project with a name like MyProject.AcceptanceTests. For quick test running and CI, it's much easier to omit an entire assembly of tests, so keep these guys separate.

I find that I often want to run the faster unit tests and run the acceptance tests only around the parts of the application we are working on. I run the full suite maybe 2-5 times a week, especially before a hand-off to a stakeholder or a big demo.

How not to install SpecFlow and WatiN

Don't bother with DLL downloads or manually setting up file references. Install the SpecFlow NuGet package and the Visual Studio Extension. Let NuGet handle the assembly references and setting up the app.config for you. The VS Extension adds some nice feature file editing and right-click features to run a single test.

You'll need to decide on MSTest versus NUnit. The first comes with .NET, the later is free open source and you can add it with NuGet. If you're in a shop that heavily favors one over the other, use that. All you're using these for in the SpecFlow world is the generated code and the attributes marking your test fixtures and methods.

If you're using NUnit (the default), you'll need to be sure ApartmentState is set to "STA" in the app.config for your test project like this. If you use the NuGet download, it should take care of that.

Finally, you'll need WatiN, which can also be installed with a NuGet package. I've sometimes had to set some of the WatiN assemblies to Copy Local = true in the acceptance test project to get everything working. Kind of a hassle, but once it's set up right, you're done forever with it.

How not to set up a WebBrowser class and app.config

WatiN can run UI tests with Internet Explorer or FireFox (not Chrome, Safari, Opera, or anything else). The FireFox API didn't have parity with the IE one last time I checked, so I've gotten used to using the WatiN IE class.

However, don't reference this class directly, or all your code is IE dependent. What if the next version of WatiN supports an iPad emulator you want to use? Do you really trust your find-replace skills that much?

Instead, wrap the references with a static class, and reference that in your step definitions. Here's the one I'm using these days that gets an instance of IE in a static constructor:

namespace Helpers { public static class WebBrowser { private static IE _browser; static WebBrowser() { _browser = new IE(); _browser.ShowWindow(NativeMethods.WindowShowStyle.Maximize); } public static IE Current { get { return _browser; } set { _browser = value; } } public static string BaseUrl { get { return ConfigurationManager.AppSettings["BaseUrl"]; } } }
}

This is maximizing the IE window after it opens and adding a reference to a BaseUrl property, which is set in the app.config.

<appSettings> <clear/> <add key="BaseUrl" value="http://localhost:1234/"/>  </appSettings>

I use the BaseUrl to switch out the location of the test target in the step definitions (not shown above). So if I want to test locally, the BaseUrl is "http://localhost:1234/". If I want to hit the AppHarbor version, the BaseUrl "http://myapp.apphb.com/". Just change the app.config and run the tests.

How not to set up your SpecFlow Before and After attributes

SpecFlow has attributes that can be put over your step definitions for your setup and teardown code. Here are the hooks you have:

BeforeTestRun / AfterTestRun

BeforeFeature / AfterFeature

BeforeScenario / AfterScenario

I've struggled with where these go before, but the last couple projects I created a BeforeAndAfter.cs class (clever, huh?), set the SpecFlow [Binding] attribute to the top of the class, then added all my before/after code.

This is a great place to put database clean ups, security code if your app has a login, any custom SpecFlow tags you've created, etc. Here's the code I used on my last project:

using System.Configuration; using TechTalk.SpecFlow; using WatiN.Core; namespace Helpers { [Binding] public class BeforeAndAfter { [BeforeTestRun] public static void BeforeTestRun() { // Ignore all features and scenarios when running on AppHarbor if (ConfigurationManager.AppSettings["Environment"] == "Test") { Assert.Ignore(); return; } // Always login first Security.ILoginAsAdministrator(); } [AfterTestRun] public static void AfterTestRun() { // Logout to be ready for next session Security.ILogout(); // Close the browser and dispose WebBrowser.Current.Close(); WebBrowser.Current.Dispose(); // Reset the data to be ready for the next session TestData.CleanUp(); } }
}

I put all my helper methods like the WebBrowser.cs and BeforeAndAfter.cs in a /Helpers folder in the acceptance test project.

How not to organize your feature files

Feature files have one or more features in them. You could put each separate feature in it's on .feature file, but that's overkill.

I used to create a new feature file for each view in the app. That probably makes sense in some cases, but this approach often misses the value of those pages. For instance, if there are 2-3 pages for an e-commerce checkout process, it's probably not that helpful to have a feature file for BillingAndShippingAddress.feature, CreditCard.feature, and Confirmation.feature. It might be helpful to developers, but it's likely non-developers on the team see the checkout process more holistically, so why not start with a Checkout.feature file? If this gets too big, split out pieces into their own logical .feature files later.

I put all my feature files in a /Features folder in the acceptance test project. It's mostly cosmetic, but it does help a little.

How not to organize your step definition files

Step definitions are the implementation of the steps in the feature files. Since I was organizing feature files by web app page, I started out doing the same with step definitions. When you try this approach, you quickly see the problem, since step definitions can and should be reused across features.

If there is a step definition "Then I go to /MyPage", the step definition might be clicking a menu, a link in the page, or just opening a URL. As you can imagine, this can be helpful in lots of different feature files, so it makes more sense to group these in a Navigation.cs file or something like that. Maybe you have a separate Menu.cs with those step definitions, or maybe you lump them in with Navigation.

How you group these is up to you. SpecFlow sees all *.cs files with a [Binding] on them as places where your step definitions could live, and it uses regex matching to find the right method. SpecFlow doesn't care if you put your methods in one class or 100 classes, but you will. So put some thought into how you group these, because it's easier to see opportunities to refactor out similar code you find within the same .cs file versus across .cs files.

This makes the file names much more generic, but I've had the most success with this style. On recent projects, my step definition files have included Forms.cs, Menu.cs, Messages.cs, Navigation.cs, Search.cs, Security.cs, and SEO.cs.

I put all my step definition code in a /Steps folder. In the end, it looks like this:

How not to code step definitions

Step definition code in each method should be brief – like a couple lines. If you've got large blocks of code, you've probably got too much going on.

Maybe you have a giant form with tons of fields and a SpecFlow table feeding you the values. You can probably get away with something like this:

public void IFillOutTheForm(Table table) { foreach (var row in table.Rows) { var field = row["Field"]; var value = row["Value"]; switch (field) { case "Something Different": // Put exceptions here for drop downs, date pickers, radio buttons, etc. WebBrowser.Current.SelectList(Find.ByName("SomethingDifferentId")).Select(value); break; default: WebBrowser.Current.TextField(Find.ByName(field)).Value = value; break; } } }

Here, the "Something Different" case is where you would put non-textbox filling out code. But if your forms are like most business apps, there are lots of text boxes, a handful of drop downs, and a smattering of radio, checkbox, date pickers, sliders, etc. that require some different WatiN code.

Of course, if the exceptions outnumber the convention, make a separate method and see if you can factor out some common code to use somewhere else. Remember, the key to being productive with SpecFlow is reusing the step definitions, so once you start seeing duplication, look for ways to refactor to a common convention in your feature files and step definitions. It takes a while to get a critical mass of these built up, but once you do, you really start picking up speed.

Concatenating and decoding strings from a one-to-many table in SQL

Tue, 13 Oct 2015 10:23:43 Z

Let's say you have two tables in SQL Server: Person and PersonNotes. PersonNotes is a one-to-many table of notes about that Person. Here's the SQL for the tables:

create table Person (PersonId int not null) insert Person (PersonId) values (1)
create table PersonNotes (PersonId int not null, Note varchar(max)) insert PersonNotes (PersonId, Note) values (1, 'note <1>') insert PersonNotes (PersonId, Note) values (1, '& note #2') insert PersonNotes (PersonId, Note) values (1, '& finally, note <3>')

And let's say you need to grab all those PersonNotes rows and concatenate them into one string per Person row. You have a couple options: 1) create a custom function, 2) write a cursor, or 3) use T-SQL's FOR XML trick. I'll focus on the last one n this post.

Using FOR XML is kind of lame, since it's really meant for something else, but it works pretty well to pull all the strings across rows into one value:

select Person.PersonId, (select PersonNotes.Note + ' ' from PersonNotes where PersonNotes.PersonId = Person.PersonId for xml path('')) AS Notes from Person where Person.PersonId = 1

Here's the SQL Fiddle for this table setup and query. Running this will get you these results:

note &lt;1&gt; &amp; note #2 &amp; finally, note &lt;3&gt;

The problem is, putting it in XML means you get lots of "<", ">", and "&" where the strings have been encoded. That's what you want for XML, but it's not usually what you want for a string.

But if we use a little XPATH to pull the first node from that resulting XML, we do get the decoded values again:

select Person.PersonId, (select PersonNotes.Note + ' ' from PersonNotes where PersonNotes.PersonId = Person.PersonId for xml path(''), root, type).value('/', 'varchar(max)') AS Notes from Person where Person.PersonId = 1

Here's the SQL Fiddle for the tables setup and query with the extra XPATH casting back to varchar(max). Running this will get you these results:

note <1> & note #2 & finally, note <3>

And we're happy!

Using Visual Studio 2012 Test Explorer with NUnit and SpecFlow

Wed, 19 Sep 2012 00:39:59 Z

This one came up today and surprised me. I usually use the ReSharper test runner, but I wanted to try out the new, improved Visual Studio Test Explorer in VS2012. I have NUnit-based unit and integration tests and SpecFlow/WatiN UI automation tests that use NUnit behind the scenes.

Visual Studio Extensions and Updates

You'll need to install the NUnit Test Adapter so the Visual Studio Test Explorer knows what to do. You don't need to go back and change attributes, references, etc. to use MSTest. It can work with NUnit natively once you add this extension under Tools > Extensions and Updates.

Apartment State

Using SpecFlow with NUnit means you have to set your app.config ApartmentState to STA. This is well documented, but it's one of those things you have to do to get everything working.

<NUnit> <TestRunner> <add key="ApartmentState" value="STA"/> </TestRunner> </NUnit>

Making this app.config change is all the ReSharper test runner needs, but the Visual Studio Test Explorer needs a little more help. You have to set the NUnit attribute

[assembly: RequiresSTA]

in your AssemblyInfo.cs for your test project where your SpecFlow tests live.

Done!

Now you should be able to run ALL your solution's tests with the Visual Studio Test Explorer, including the SpecFlow ones!

Visual Studio Test Explorer still needs a lot of work around grouping tests, and Peter Provost says as much in his blog post, but it has come a long way.

Integrating Kendo UI drop downs with Knockout JS

Sun, 17 Feb 2013 22:07:00 Z

Kendo UI drop downs look great. Here is a Kendo UI drop down with default styling in closed and open view:

It is built with this HTML:

<input id="kendoDropDown" type="text" />

and this JavaScript:

// Init the drop down $("#kendoDropDown").kendoDropDownList({ dataValueField: "id", dataTextField: "name", dataSource: [ { id: "1", name: "apple" }, { id: "2", name: "orange" }, { id: "3", name: "banana" } ] });

The snag

Unfortunately, this handsome drop down doesn't integrate smoothly with Knockout JS when it comes to data binding.

We should be able to update our HTML to use a Knockout binding:

<p> <label for="kendoDropDown">Kendo UI Drop Down</label> <input id="kendoDropDown" type="text" data-bind="value: fruitId" /> </p>

Then add a view model and apply the Knockout binding:

// Define and init the Knockout view model var ViewModel = function () { var self = this; self.fruitId = ko.observable(); }, vm = new ViewModel(); // Set the initial fruit value vm.fruitId("2"); // orange
// Wire up KO binding ko.applyBindings(vm);

We should see a drop down loaded with the view model's initial value of "2" (orange), but the first value in the list ("1" apple) is selected instead. What's going on?

More investigation

I thought maybe I had a Knockout bug in my code, so I played around with a plain (non-Kendo) select list and a plain text box by adding the following HTML:

<p> <label for="select">Plain old select</label> <select id="select" data-bind="value: fruitId"> <option value="1">apple</option> <option value="2">orange</option> <option value="3">banana</option> </select> </p> <p> <label for="textBox">Plain old text box</label> <input id="textBox" type="text" data-bind="value: fruitId" /> </p>

But these controls were set to the correct initial value ("2" orange).

It gets weirder when you change the view model's value programmatically. Here, I've added some HTML buttons to do that:

<p> <button id="changeTo3" class="k-button">change fruitId to "3" (banana) programmatically</button> </p> <p> <button id="changeTo2" class="k-button">change fruitId to "2" (orange) programmatically</button> </p>

and some JavaScript to change the view model's values:

// Wire up the buttons $("#changeTo3").click(function () { vm.fruitId("3"); // banana }); $("#changeTo2").click(function () { vm.fruitId("2"); // orange });

Clicking the buttons should change the view model's value, which should change the controls' values. It works for the plain HTML controls, but not for the Kendo UI drop down.

Here's the JSFiddle to see all this in action.

<p>The fruitId should be "2" (orange) initially, then "3" (banana) after the button click. The text box and the drop down are bound to the same value in the Knockout view model (fruitId).</p> <p>As the drop down is changed manually, the Knockout view model is updated, and the drop down and text box show the new value. But as the button is clicked and the view model is updated in code, the text box shows the correct value, but the drop down does not.</p> <p>How can the drop down be set in code with Knockout?</p> <p> <label for="kendoDropDown">Kendo UI Drop Down</label> <input id="kendoDropDown" type="text" data-bind="value: fruitId" /> </p> <p> <label for="select">Plain old select</label> <select id="select" data-bind="value: fruitId"> <option value="1">apple</option> <option value="2">orange</option> <option value="3">banana</option> </select> </p> <p> <label for="textBox">Plain old text box</label> <input id="textBox" type="text" data-bind="value: fruitId" /> </p> <p> <button id="changeTo3" class="k-button">change fruitId to "3" (banana) programmatically</button> </p> <p> <button id="changeTo2" class="k-button">change fruitId to "2" (orange) programmatically</button> </p>

// Init the drop down $("#kendoDropDown").kendoDropDownList({ dataValueField: "id", dataTextField: "name", dataSource: [ { id: "1", name: "apple" }, { id: "2", name: "orange" }, { id: "3", name: "banana" } ] }); // Define and init the Knockout view model var ViewModel = function () , vm = new ViewModel(); // Set the initial fruit value vm.fruitId("2"); // orange // Wire up KO bindidng ko.applyBindings(vm);
// Wire up the buttons $("#changeTo3").click(function () { vm.fruitId("3"); // banana }); $("#changeTo2").click(function () { vm.fruitId("2"); // orange });

The work around

A Kendo UI team blog post describes a work around for this issue, but it didn't work for me.

The trick here is that the Kendo UI drop down is really a hidden input and a bunch of spans. Knockout changes the value of the hidden input when the view model changes, but you have to hook into that jQuery DOM change event and call the code to select a new value in the Kendo drop down. Kind of lame, but it's supposed to work.

$("#kendoDropDown").bind("change", function() { $(this).data("kendoDropDownList").select(this.selectedIndex); });

You can even unhide the hidden text box inside the Kendo UI drop down list and watch its value change as the view model changes, but the drop down just sits there. Arg!

The real work around

I was pulling my hair out by now, and asked for help on Stack Overflow. Unfortunately, the answer I got was use another library that does the integration in a different way, the Knockout-Kendo.js library. That's probably a good answer, but I was hoping to avoid adding another library just to use Knockout and Kendo UI together.

Instead, I found I could get everything working as expected with a Knockout subscription. It's like a view model data change listener. My thinking was that I could use the same concept as the Kendo UI team blog post (listen for a change and then manually set the drop down). Not ideal, but oh well.

Here's what I changed in the view model:

self.fruitId.subscribe(function (newValue) { $("#kendoDropDown").data("kendoDropDownList").value(newValue); });

And the final, working JSFiddle.

// Init the drop down $("#kendoDropDown").kendoDropDownList({ dataValueField: "id", dataTextField: "name", dataSource: [ { id: "1", name: "apple" }, { id: "2", name: "orange" }, { id: "3", name: "banana" } ] }); // Kendo UI team work recommended around //$("#kendoDropDown").bind("change", function() { // $(this).data("kendoDropDownList").select(this.selectedIndex); //}); // Define and init the Knockout view model var ViewModel = function () { var self = this; self.fruitId = ko.observable(); // Real work around self.fruitId.subscribe(function (newValue) { $("#kendoDropDown").data("kendoDropDownList").value(newValue); }); }; vm = new ViewModel(); // Set the initial fruit value vm.fruitId("2"); // orange // Wire up KO binding ko.applyBindings(vm);
// Wire up the buttons $("#changeTo3").click(function () { vm.fruitId("3"); // banana }); $("#changeTo2").click(function () { vm.fruitId("2"); // orange });

Increasing Testability

Sun, 07 Mar 2010 06:30:20 Z

Testa-what?

I don't know if "testability" is a word, but if Bud Light can make up "drinkability", maybe it should be. I'm talking about how pliant your code is to testing. If you're doing TDD or BDD, the code you write is testable by definition.

But if you're going the other way, and coding first or testing legacy code (any code not already under test), you've probably run into code that was hard to test and felt like giving up. Some of the most common hurdles for testability are not coding to abstractions and not decoupling dependencies. Here's how to get around that.

The problem

Here's a garden variety Order class with a ProcessOrder method:

public class Order { public string FirstName { get; set; } public string LastName { get; set; } public string Email { get; set; } public decimal Total { get; set; } public bool ProcessOrder() { var result = false; // Validate order if (!string.IsNullOrEmpty(this.Email) &amp;&amp; this.Total > 0) { // Send order confirmation email var emailService = new EmailService(); var emailSendResult = emailService.SendOrderConfirmationEmail(this); if (emailSendResult == true) { // Do more order processing... result = true; } } return result;
} }

And here's the test:

[Test] public void Should_return_true_when_using_good_order_values() { // Arrange var order = new Order(); order.FirstName = "Joe"; order.LastName = "Wilson"; order.Email = "real_email_address@volaresystems.com"; order.Total = 123.00m; // Act // Watch out! Don't run this or it will send real emails! var result = order.ProcessOrder();
// Assert Assert.That(result, Is.True); }

We need to call the SendOrderConfirmationEmail method in the EmailService class. But if our test calls ProcessOrder, there is no way to avoid calling the live emailing method as it's coded now.

How can we test the logic in the ProcessOrder method without sending out a real email?

Code to Abstractions

First, we need to code to an abstraction of EmailService, not to the concrete class itself. So let's create an interface around EmailService:

public interface IEmailService { bool SendOrderConfirmationEmail(Order order); }

Then change the EmailService class to implement this new interface. Visual Studio 2008 and ReSharper make this easy.

This will let us change our test later to use a fake version of IEmailService instead of the real one.

Decouple and Invert your Dependencies

The next problem is we're creating an instance of the EmailService class in the ProcessOrder method. Anytime you use "new" in your code, you're probably introducing a dependency and reducing testability.

The fix is to let the caller create the instance and tell the class or method being called which instance to use. I am using a private field with constructor injection to set the field instance. Note we're also now coding to the interface IEmailService instead of the instance EmailService.

Here's the full Order method using the private field to call the SendOrderConfirmationEmail method on IEmailService inside the ProcessOrder method.

public class Order { private readonly IEmailService _emailService; public string FirstName { get; set; } public string LastName { get; set; } public string Email { get; set; } public decimal Total { get; set; } public Order(IEmailService emailService) public bool ProcessOrder() { var result = false; // Validate order if (!string.IsNullOrEmpty(this.Email) &amp;&amp; this.Total > 0) { // Send order confirmation email //var emailService = new EmailService(); // Created outside this class now var emailSendResult = _emailService.SendOrderConfirmationEmail(this); if (emailSendResult == true) { // Do more order processing... result = true; } } return result;
} }

Dependencies can be very hard to spot, but it's critical to tease them out of your code to increase testability. They can even come from things as innocuous as DateTime. If you're code relies on DateTime.Now, how will you write unit tests for your logic without changing your system clock when you run the test? It's simpler to have the caller pass in the DateTime value and have the method do the calculations based on whatever value it is given.

Make a Fake

Now that we've got testable code, we can make a fake EmailService and update our test.

First, create the FakeEmailService class implementing the IEmailService we created earlier. We need the SendOrderConfirmationEmail method to return true to simulate an email being successfully sent.

public class FakeEmailService : IEmailService { public bool SendOrderConfirmationEmail(Order order) { return true; } }

You could also use a mocking framework like Moq or Rhino Mocks for this, but a homemade fake is easy, too.

Now we're ready to update our test to use the fake and inject it into the Order constructor:

[Test] public void Should_return_true_when_using_good_order_values() { // Arrange var emailService = new FakeEmailService(); order = new Order(emailService); order.FirstName = "Joe"; order.LastName = "Wilson"; order.Email = "real_email_address@volaresoftware.com"; order.Total = 123.00m; // Act var result = order.ProcessOrder(); // Assert Assert.That(result, Is.True);
}

Last step

We've refactored the Order class so the caller sends the IEmailService instance to it. That makes sense for the test, but what about the real code?

I typically use an IOC container like Structure Map or Castle Windsor to hold and resolve an in-memory dictionary of interfaces and class instances. You wire it up at application startup and when you call something that needs IEmailService, it creates an instance of EmailService for you.

If you're working with legacy code and can't use and IOC container, you also can add a no arg constructor like this:

public Order() : this(new EmailService()) { }
public Order(IEmailService emailService)

Your legacy code keeps calling the no arg constructor like it used to, and any new code and your test code use the constructor with IEmailService dependency passed in.

Wrap up

If you code isn't testable, you won't test it. If you're working with legacy code or writing tests after coding, you can use these techniques to pull out external dependencies so they can be faked for testing.

You can have it all: testable code, unit tests around that code, and no broken legacy code. Mmmm.Testability. Drink it in!

Ten mistakes to avoid when choosing a custom software development company

Sun, 02 Apr 2023 18:24:49 Z

Custom software development can be a game-changer for businesses, providing tailor-made solutions that meet specific needs. Choosing the right software development company is crucial, but it can be a daunting task. Many companies offer these services, and it's easy to make mistakes that can cost time, money, and even the success of the project.

Here are ten mistakes to avoid when choosing a custom software development company.

Mistake #1: Choosing a software company that can't deliver what you need

The first mistake is selecting a software company that cannot deliver what you need. Custom software development requires a deep understanding of the client's business needs and goals. Choose a software development partner that takes the time to listen, understands your requirements, and has a history of successfully delivering for clients.

Mistake #2: Choosing a software company that can't support you going forward

Custom software often needs updates to maintain optimal functionality. Choose a software development company that can offer ongoing support, maintenance, and updates to ensure your software stays in tip-top shape. A company that disappears after the project's completion can leave you with a system that quickly becomes outdated or breaks down.

Mistake #3: Choosing an untrustworthy software company

Your software development company will have access to sensitive data and information. Choose a software company with a proven track record and a reputation for trustworthiness. Look for references, testimonials, and reviews to ensure you choose a reliable partner.

Mistake #4: Choosing a software company with unreasonable pricing and time ranges

Ensure that the pricing and time ranges for your project are reasonable and within your budget. If the software company's prices or timelines seem too good to be true, they probably are. Be wary of software companies that offer fixed prices and unrealistic timelines, as these often result in cost overruns, delays, and tons of stress.

Mistake #5: Not checking the software company's technology stack

Ensure that the software company's technology stack aligns with your organization's preferred stack. Ask about the technologies they use and how they plan to integrate them into your project.

Mistake #6: Not considering the software company's communication skills

Effective communication is crucial in custom software development. You need your software development partner to be on the same page throughout the development process. Choose a software company that is responsive and easy to communicate with. Ensure they have a clear communication plan and a project manager who will keep you updated on progress, challenges, and milestones.

Mistake #7: Not considering the software company's culture and values

It's important to choose a company whose culture and values align with your own. This can help ensure a successful and positive working relationship.

Mistake #8: Not clarifying ownership and IP rights

Ensure that ownership and intellectual property rights are clearly defined in your contracts. This agreement should include who owns the software and its components, who has the right to modify and distribute it, and what happens in case of disputes or termination of the contract.

Mistake #9: Not considering the software company's development methodology

Different software development methodologies exist, such as Agile and Waterfall. Ensure that the software company's methodology aligns with your project's needs, timeline, and budget. The development methodology should also include regular reviews or demos, invite your feedback, and should change to meet your changing priorities.

Mistake #10: Not signing a clear contract

A detailed contract is essential to ensure that both parties understand the scope, timeline, cost, and expectations of the project. The contract should also include provisions for changes, delays, and dispute resolution.

Choosing the right custom software development company is crucial for the success of your project. Avoid these 10 mistakes and you'll be well on your way to finding the right partner for your business.

Contact Volare Software today for more information about custom software development.

The importance of listening to users during the design process

Sun, 02 Apr 2023 18:46:50 Z

As a custom software development company, creating a web or mobile app that meets the needs of your target audience is essential. One of the best ways to ensure that your app is a success is by listening to user feedback during the design process.

Here's why:

Users can have insights you might not think of.

As product owners or developers, it's easy to get caught up in our own ideas and lose sight of what users really want. By listening to real user feedback from real users, you can gain valuable insights that you might not have thought of on your own. This can help you create an app that is more intuitive, user-friendly, and effective.

Users can focus your thinking on the essential parts of the app they care about.

When developing a web or mobile app, it's easy to get bogged down with features and functionality that users may not even care about. By listening to user feedback, you can get a better sense of what users are looking for in your app and focus your development efforts on those key areas. This can help you create an app that is more streamlined and efficient.

Not all user feedback is helpful, but it is important to use it as guidance.

Of course, not all user feedback is going to be useful or actionable. However, it's still important to listen to all feedback and use it as guidance. Even negative feedback can provide valuable insight into what users don't like about your app, which can help you make improvements and refine your design.

At Volare Software, we understand the importance of listening to users during the custom software design process. Our team of experienced app developers has a proven track record of creating custom apps that meet the specific needs of our clients. Whether you're looking to develop a web or mobile app from scratch or need assistance with enterprise app development, we've got you covered.

So if you're ready to create an app that truly resonates with your target audience, contact us today to learn more about our web and mobile app development services. With our help, you can create an app that users will love and use time and time again.

What is custom software?

Tue, 18 Apr 2023 14:20:03 Z

Sure, we sell custom software, but we’ll often be the first to recommend off-the-shelf software if it’s a better fit for your budget, scope, or timeline. Off-the-shelf software is convenient and cost-effective, but sometimes it doesn't quite meet your business's unique needs. In those cases, custom software development may be the better choice.

You might be wondering: what exactly IS custom software? And how does it differ from the social media apps on your phone or the word processor you use at work?

Simply put, custom software is a tailored solution designed specifically for your business's needs. Unlike off-the-shelf software, which is designed to be used by a wide range of individuals and organizations, custom software is built with your specific business processes, requirements, and goals in mind.

Custom software development is similar to building a custom house in many ways. Just as a custom house is designed to meet the specific needs and requirements of its owner, custom software is developed to meet the unique needs and requirements of a business. In both cases, the end result is a solution that is tailored to the owner's exact specifications and reflects their individual style and preferences. Just as a custom house requires a team of architects, builders, and designers to bring the owner's vision to life, custom software development requires a team of developers, designers, and project managers to create a solution that meets the client's specific needs. And just as a custom house can make its owner’s life both more efficient and more beautiful, custom software can add tremendous value to a business, helping to improve productivity, streamline processes, and drive growth.

Think about it this way: the social media apps you use on your phone are designed to be used by a massive audience, with features and functionality that cater to a broad range of users. Your word processor software may have more specialized features, but it's still designed to be used by a wide range of industries and professions.

On the other hand, the inventory management system or fleet management software your company uses is likely more specialized and tailored to your business's specific needs. It may have features and functionality that you can't find in off-the-shelf software, and it's designed to help your business operate more efficiently and effectively.

Custom software can take many forms, from desktop applications to mobile apps to web-based systems. But no matter the form it takes, the goal of custom software development is to create a solution that fits your business like a glove.

So why choose custom software over off-the-shelf solutions? The answer is simple: because it's designed with your business's unique needs in mind, custom software can provide a level of functionality, efficiency, and productivity that off-the-shelf solutions simply can't match. Plus, because it's built specifically for your business, custom software can be more easily integrated with your existing systems and processes, reducing the time and effort required to train your staff on new software.

At Volare Software, we specialize in custom software development, helping businesses of all sizes and industries find solutions that meet their unique needs. If you're tired of using off-the-shelf software that just doesn't quite fit, contact us today to learn more about how custom software can help take your business to the next level.

What does custom software development cost?

Mon, 06 Aug 2018 06:00:00 Z

Do you need custom software?

Are you considering custom software development?

While there are already plenty of software options available for common business tasks, such as accounting or HR, there are situations where commodity software won't do. For example, if you have a unique business problem or product, or the software on the market today doesn't match your business needs, custom software development may be the solution.

But what does custom software development cost?

Small projects, like MVPs, can be as little as $25,000/€23,000 for one, full-time developer for 1-2 months.

Medium projects are $50,000/€45,000 - $250,000/€225,000 and take 3-6 months for one or two full-time developer(s).

Very large projects for enterprise customers and government entities are more complex and take more people and more time. They can be 6 months to several years to complete, so they can cost well over $250,000/€225,000 - $1,100,000/€1,00,000 for three to five full-time developers for 6-12 months.

How we estimate custom software costs

Unlike building a basement or a house, custom software pricing is not straightforward.

At Volare Software, a custom software development company, we don't provide fixed bid contracts. Instead, we estimate the monthly running cost for a development team, and the duration and total cost are given as ranges based on the minimum and maximum estimates for the modules in the system.

We are transparent with potential customers that the total cost and durations are estimates constructed by adding up lots of smaller guesses, so the margin of error is very high. However, we can commit to the cost of the development team for each month, and we can resize the team and monthly budget up or down as needed.

What takes one developer six months does not take two developers three months. There is communication and code integration overhead to account for.

Having more developers usually means you get the software delivered more quickly, but there is a point of diminishing returns. We've found that three to five developers can be as productive as ten.

Avoid fixed bid pricing

Fixed bid contracts require all project details to be known and documented up front. However, we've never been on a project where those initial plans didn't change, and they usually change significantly.

Fixed bid contracts put the consulting company in the position of arguing with their client that the new thing or the change or the different interpretation they have was not in the original specifications and was not included in the price they were given. This model of constant contract negotiating with your customer is not a positive experience for either party, and it adds to the overhead of the project.

Instead, we prefer to say "yes" to customer ideas and changes, telling the customer the impact of the change. Ultimately, the customer decides if it's worth the extra time and cost.

Deliver the most important software early

At Volare Software, we use an agile software development process where the most important features of the system are built first. These are usually the highest value modules in the system.

By building the key modules early, we bring the value and the risk forward in the software project, ensuring the software meets your goals and can be a successful product.

Contact us today to learn more about our custom software development services.

Five Essential Steps to Ensure Your Web App is Secure

Tue, 18 Apr 2023 14:27:52 Z

It seems like every time we read the news, we see another headline about a data breach. With cyber attacks on the rise, it’s important to ensure your web app is secure. So, how can you be sure your web app is secure? In this blog post, we’ll share five essential steps to ensure your web app is secure.

Encrypt all traffic

Encrypting all traffic between your website and its users is essential for securing your web app. This means using HTTPS instead of HTTP. HTTPS encrypts data in transit, so even if someone intercepts the traffic, they won’t be able to read it. To implement HTTPS, you need to obtain an SSL/TLS certificate from a trusted certificate authority and install it on your server. Many hosting providers offer free SSL/TLS certificates, so there’s no excuse not to use HTTPS.

Encrypt sensitive data in the database and don't store it if that's an option

Encrypting sensitive data in your database is another important step to securing your web app. This includes user passwords, credit card numbers, and any other personally identifiable information. Encryption makes it much harder for hackers to access this information if they manage to breach your defenses. However, if possible, it’s best not to store sensitive data at all. If you don't need to store sensitive data, don't store it. It’s that simple.

Run security scans

Security scans are a great way to find vulnerabilities in your web app. There are many tools available that can help you scan your website for common security issues. Some of these tools are free, while others require a paid subscription. It’s worth investing in a good security scanner to ensure you’re not leaving any vulnerabilities exposed.

Run static code evaluations

Static code evaluations are another way to identify potential security issues in your web app. These evaluations analyze your code for common vulnerabilities such as SQL injection, cross-site scripting, and buffer overflows. By identifying these issues early, you can fix them before they become a problem.

Check security headers

Security headers are a powerful tool for securing your web app. They tell browsers and other applications how to behave when interacting with your website. For example, the Content-Security-Policy header can be used to prevent cross-site scripting attacks by telling the browser to only load resources from trusted sources. Checking that your web app has the appropriate security headers is an important step in securing your web app.

In conclusion, securing your web app is essential to protecting your business from cyber attacks. By encrypting all traffic, encrypting sensitive data in your database, running security scans and static code evaluations, and checking security headers, you can help ensure that your web app is secure. Remember, security should be a top priority for any website owner or developer.

At Volare Software, we specialize in custom software development, helping businesses of all sizes and industries find solutions that meet their unique needs. If you’re looking for custom software and security is a top concern, contact us today to learn more about how Volare Software can help take your business to the next level.

Buy, Build, or Both?

Sat, 12 Aug 2023 11:50:33 Z

You need to open up a new market, cut costs, or automate a process. New software can help solve this problem, but which software meets your needs?

There are three main categories of software: 1) packaged software, 2) software as a service (SaaS), and 3) custom software. This article covers the pros and cons of each type of software and can help you make the right purchase decision for your business.

When is packaged software or SaaS the right choice?

If you want a word processor, email client, or accounting package, it's been done. The products are numerous, mature, and range from free to very reasonably-priced.

More and more business software is falling into this commodity space, such as enterprise content management solutions, document management programs, and customer relationship management (CRM) software. These tools have a single purpose and usually very good at what they do.

Cost wise, buying software is usually cheaper than building custom software. As we'll see later on, there are some caveats to this, but this conventional wisdom is often correct.

This is where most software evaluations end. It meets your requirements and it's cheaper. Make the purchase and move on, right? Well hold on a sec.

There are some risks to packaged software and SaaS that are often overlooked:

They often include modules you don't want and may not be an exact fit for your business. Adding the modules you do want is extra. So is implementing the software and customizing it to fit your business.

They work in functional silos and are usually from multiple vendors. You've got to be sure it will integrate with your other systems.

They may not let you get the data out the way you want it.

Your users may not be as excited about your choice as you are.

Let's take a closer look at these problems and when they may ultimately push your decision to the custom software side.

Get just what you want, no more, no less

Buying software "off the rack" is the way to go if the package meets all your business requirements. But most of the time, you're buying functionality you don't need and missing functionality you do need. You shouldn't have to change your business to match the software you've just purchased.

The common answer is to have consultants implement a solution and customize it to your business. If the packaged software is a good fit with your requirements, this can be a good choice, too. You just want the consultants to come in and round out the corners, though. They shouldn't need to rewrite anything; just configure it for your organization and maybe integrate your new software with some of your existing systems.

But at some point (and it should be pretty soon after the install), the consultants should finish and go home. If they need to stick around for lots of customizations or integrations, you may have lost the justification for buying instead of building it. And don't forget that all those customizations can't just be thrown out when the vendor rolls out the next version of the product you've bought. Too many companies make this mistake and fall into a cycle of perpetually customizing packaged software.

With custom software, the program meets all the requirements of the business and doesn't include any modules you don't want. It usually costs more initially, but because you buy only what you need, nothing more, you won't need to perpetually customize.

Get deep integration with your existing systems

With packaged software, integration with your other systems ranges from simple to a painful implementation project. For example, if you purchase CRM software and want to load all your existing customers into it, the tool should provide this. Most consultants can do this work quickly. Painful integrations are when you can't get the data out, or you can get it out, but you have to use the vendor's very strange API to pull just one record at a time.

If the new system is one piece of a larger process, or if it will be the system of record for your enterprise data, you will have many integration points for data coming into and out of the new system.

With custom software applications, those integration points are built in because they are part of the original requirements. The software integrates deeply with your current enterprise systems. If done right, the new integration APIs are written in standard ways that are discoverable by any new applications that may come online in the future.

How stable is that vendor? What is your exit plan?

The main value proposition of packaged software is the functionality you get for the price you pay. But that value can go out the window if the vendor goes out of business or is purchased and no longer supports your software. And what happens if you get their software deeply embedded in your business and the vendor goes up on price next time you're negotiating their contract. Vendor lock-in is a real business risk.

In a struggling economy, it's not unusual to see smaller software vendors bought out by larger ones. It's also common to see start-up SaaS companies offering low introductory prices to get customers on board, then gouging them once the cost of leaving that vendor gets high enough. When purchasing software, consider the long term costs and how you would get your data out.

And don't just make a plan. You need to test that your plan really works and you can get the data out when you need it and in a format that is useful to you. This is like a building evacuation plan. Usually no one reads the plan until the emergency happens, and then it's too late. You have to actually test pulling your data out in a non-emergency situation to see if the plan will really work.

With custom software, your business owns all the code and all the data from the start. Most systems are turned over to IT departments after the construction phase, so there is no risk of your data being held hostage.

Although unlikely, it's certainly possible to have your custom software development vendor go out of business or be purchased by a competitor during the development phase. However, if the system is written using your IT department's standards and your application development vendor is releasing working versions of code every few weeks, you minimize vendor lock-in or vendor going-out-of-business risk.

Where is the data stored?

With packaged software, the data is often stored in a proprietary database. Even if it's in a more common database format, many vendors will not support direct queries or reports against the data store.

If you're using SaaS and the data is in the cloud, you can't be sure where it is. That works great for some organizations that really want the redundancy and availability, but for sensitive data or for businesses that are heavily regulated, data security will be a deciding factor in your purchase.

Custom software puts the data where the organization wants it because access to and location of the data are part of the requirements. It's as secure, redundant, and available to queries and reports as the requirements dictate.

Get user buy in

The typical IT buying process is to identify the requirements and find the packaged software that best fits. This evaluation is often handed over to a technical person to be sure the software is a fit for the organization from an IT perspective.

The problem comes when a package is selected and the users are told that starting next Monday, they will be in training, and starting the Monday after that, they will be using the new system. If the users haven't helped choose the software, they may reject it or sabotage the implementation.

With custom software and custom integration projects, users are involved in the requirements early on, and the new system should be tailored to their specifications. They are the most critical stake holders and can set the tone for a successful adoption throughout your organization.

Conclusion

Software purchase decisions can be as complex as the problems they attempt to solve. Decision makers need to consider short and long term costs and risks of buying packaged or SaaS software as is, buying it and customizing it to integrate into the business, or going with custom application software the whole way. The easy answer is not always the best answer when all the risks are considered.

Contact Volare Software today for more information about building custom software for your business.

How we do agile software development

Sat, 12 Aug 2023 11:43:25 Z

We follow an agile software development process that has been revisited, updated, and tweaked over the 13 years we've been in business. We are happy with the process we have now, but we're always trying to improve it. If you see inefficiencies or blind spots, please let us know in the comments below.

Planning and Project Management

Stories and Bug Fixes

The business, usually through a single product manager, is primarily responsible for writing up new stories. The content should be enough for the author to remember what he/she was talking about when asked for details in the future. Once the placeholder story comes up in the work cycle, the delivery team gets with the relevant stake holders and asks them questions about the feature, ideally working through and writing up some concrete examples and coming up with a design if needed. These conversations and examples highlight the reason for the feature. and serve as a powerful motivator for the delivery team.

There is no need to write stories in the language, "As a ____, I want to ____, so I can ____.". The blanks should have been filled in from the conversations and may or may not be useful to write into the story. That's up to the team if they want to document that for posterity or new people joining the team, but it's faster to tell people the reason this story matters to the business and transfer the knowledge that way.

There is no need to agree on a definition of a story being "ready" for the team to work on. If it's at the top of the backlog and needs design work or more details, it's your job to chase that down before coding starts. We don't start coding until we have acceptance criteria that is clear enough for the developer. The developer usually writes up the steps for testing for the tester and product owner and business.

Everyone on the team can write a story. Developers and testers find technical debt, bugs, and UI inconsistencies all the time. The team can prioritize this work, but it is important that it is visible to both the delivery team and the business.

There is no need to separate feature work from bug work. A bug is when the software does something the business doesn't want it to. A feature is when the software doesn't yet do something the business wants it to. There is no need for a blanket policy of "fix all bugs first". The business knows if there are low priority bugs that can wait while a high impact feature is being worked on.

We don't trace user stories to epics and don't usually break them down into tasks. If stories have a common theme, they can be tagged with a label or colored the same color if needed.

Estimating

We don't estimate story sizes. We can tell the business how many stories we average per release or per time period. Using this knowledge and seeing how far back the story is in the backlog and the number of stories in progress, the business can roughly calculate when that bug fix or feature will be in production.

Priorities

Stories are ranked in the backlog in priority order, with the highest priority stories at the top. If the story or bug fix is important, it can be moved up so it is more likely to be in the next release or the one after that.

The business can change the delivery team priorities at any time, and the attitude of the delivery team should be that we're glad to do it because we are there to work with the business to make the software as effective as possible.

Occasionally, there are very high priority bug fixes that need to be made. We can add a swim lane to our online Kanban board for these, and they get expedited treatment to get the fix into production as quickly as possible.

Workflow

Stories are worked from left to right in the online Kanban board. The leftmost column is the Backlog. The rightmost column is stories pushed to production. The columns in between vary based on the project, but usually include Development, Testing, and Ready for Acceptance Testing, which is a queue where stories sit until the next release to the user acceptance testing environment, and User-Acceptance Testing.

More than one person can be assigned a story. Anyone on the team can move a story, ideally with a comment about why they made the move. We don't both with hard WIP (work in progress) limits, because we socialize that you can truly only work on one thing at a time, and it's OK to have two stories sitting in the Development column if you are waiting for answers on one of them and it may take a few days to get a response.

When testers review developers' work and find issues, they write up enough details for the developer to reproduce the issue, ideally with screen shots or a walkthrough, and the story is moved back to the Development column for fixing. That now becomes that developer's top priority and the fix is usually not time consuming, and then the story move back to Testing with comments from the developer about the fix.

The same process happens with user acceptance testing. If the produce owner or business find a bug or think of a change they want made, the story gets updated and moved back to the Development column. Sometimes the change requested is big enough to warrant a new story which also needs to be prioritized.

Reporting Status

There is no need for daily standups or status reports. We have an online Kanban board that shows all stories in progress, their status, and who is working on them. The delivery team and the business have access to this task board. Everything the delivery team is working on is transparent.

Communication and Meetings

If there are no daily standups or status reports, how do we communicate? Since we work remotely, we do it all online. If you've got an internet connection, you're all set. We mostly use instant messaging tools and escalate to phone or video call or screen sharing as needed. Email and phone calls work, too, but those are secondary and usually used when someone we need to talk with doesn't use the same IM tool as the delivery team.

Stock images make meetings look fun, but synchronous meetings (e.g., 5 of us need to be on a call at 10am today) are expensive and their purpose is often better accomplished in other ways. Instant messaging allows us to have asynchronous meetings, so you can keep working and hop into the discussion when you have time. This avoids context switching and prevents developers and testers from looking at the clock, seeing they have a meeting in 15 minutes, and deciding not to start something new. Software design, development. and testing require uninterrupted thinking for big chunks of time, and async meetings are critical to not disturbing someone's flow.

Blocks and Team Dynamics

If people on the delivery team are blocked (e.g., "I can't access the database.", "How does the business want these buttons to look?", "I'm stuck on some SignalR syntax.", etc.), it's up to those team members to report that right away. Because there is no daily standup, there is no waiting until the next day to mention it. Anyone who can helps the blocked team member or gets them with someone who can help them.

A key assumption here is that the blocked team member will speak up and not quietly flounder for hours or days. We make sure asking for help doesn't come at the price of being teased or humiliated for not knowing something.

Everyone on the team must help other team members. In fact, how this is approached is crucial. If you ask a developer if they need help with something, 9 times out of 10 they will reflexively say no. They want to figure it out on their own, they think they've almost got it, etc. If you instead ask, "How can I help?" or "Why don't we look at this together - it's tricky." or "Can you show me how you did that? I want to learn it too." you'll have more success.

Be humble. Be considerate. Be sincere. Be helpful. Be cheerful.

Development Practices

Testing

We write LOTS of client and server-side unit tests. These tests help ensure the happy path tests cases are covered and that the corner cases have at least been thought through. They also drive a decoupled design where we can mock things as needed that are not directly under test, like database queries that need to return specific data to hit a code path.

These tests become more valuable over time. You can change something in one part of the code base and feel confident you didn't break something you wrote 6 months ago after seeing all the tests pass.

Running the unit tests to check the software is not enough to know we're done, so we also use a combination of integration, end-to-end, and manual testing.

We write some, but not as many integration and end-to-end tests where we're testing database, API calls, or the entire front and back end. These tests are slower to run and harder to maintain with all the setup needed, so we use these kinds of tests only in the most crucial pieces of the app (e.g., the shopping cart better work).

Developers are responsible for manually testing their own code. They wrote it, so they should know where the pitfalls could be. They are also responsible for writing detailed test scripts for team members who will be testing after them. These are usually added to the story. A developer can only move a story once they have done their own manual testing and writing detailed acceptance criteria.

We also have a tester that does manual testing to double-check that the developer didn't forget anything. This manual testing is helpful for limit testing (e.g., try values like –1, 0, or 1), validation testing (e.g., if the field says it's required, it really is), cross-browser testing (e.g., if the developers are using Chrome to code/test, does it also work with Safari on iPads?), and logic testing.

We don't measure test coverage. We have in the past, but we have never known what to do with the data. 100% test coverage isn't a goal. 50% or 75% coverage doesn't tell me we need more tests, or we have enough. It's trivia and adds overhead, so we don't bother any more.

Code Patterns and Refactoring

We develop code patterns for the project by asking all developers for input. Over time, we change our mind about some of those patterns or make updates to tools. If we can, we pull the pattern out as a shared piece of code so it can be changed in one place. If that's not practical, we bring code forward to the new patterns as we work on it.

We refactor code as needed, usually following our own version of the Boy Scout rule (always leave the campground cleaner than you found it). If you open a piece of code to make a small change, leave the rest of the code alone. If you need to make major changes, bring that code up to the latest coding patterns and tools the team is using today.

Because we have extensive test suites, major code changes are not a scary thing for the team.

Pair Programming and Code Reviews

Pair programming is used, but typically on new or complex code or with new team members. Most developers prefer to work through the problem alone, but sometimes that's a little overwhelming and pairing for an hour or so is hugely helpful.

We do code reviews of each other's work, but it's not every for every commit. If a developer is feeling a little unsure about their work or coding patterns or working on something that will be shared by the whole team, a code review makes sense.

Pair programming and code reviews are fantastic ways to socialize coding patterns and check in with developers to make sure they understand and are using the team agreed to development patterns.

Just-in-time Architecture and UI Design

We don't have a big architecture plan before we start the project. We have a rough idea of how it will go, but we try to code in such a way that we have options and can change the architecture just-in-time as needed during development.

For some stories, the UI design is a key to solving the problem. In those cases, we use mockup tools to quickly draft a UI and get feedback from the business and product owner. We cycle through that feedback until we're happy with the design, and then the mockups become attachments in the story so the developer has a template of what the finished product should look like.

UI design mockups can be very powerful when done live with the customer, and the tools are simple enough that ideas can become concrete designs very quickly.

Branching

We don't usually create branches for feature or bug fixes. Everyone works on master. We have branches for releases, like a user-acceptance testing branch and a production branch, so we can hop onto a branch and make a fix and merge it back to the lower branches as needed. We create labels/tags for each release candidate.

Continuous Deployment and Feedback

Every code commit pushes a new release to a development web server. This tests our code integrations and builds, but more importantly, it gives the team's tester, product owner, and any other stake holders a live look at the latest working code.

The delivery team is constantly asking for feedback from the product owner and the business about how the software is working or not working so we can adjust. With custom software, they key to getting what you want is giving the delivery team lots of feedback on the in-progress software. Continuously deployment is the place to take the latest code for a test drive.

Release Management

Time-boxed vs. Feature-driven

Releases can be either time-boxed, where we release everything that's done every 2 weeks, or they can be feature-driven, where we release when a feature is complete. We sometimes compromise and release every 2 weeks unless there is something important that is almostdone, and then we'll wait another couple of days before releasing with that feature. We don't do this every release, and the product owner, business, and delivery team should reach consensus on whether to hold up a release.

Time-boxed releases are nice and steady and give the business an expectation of when they can have working code in production. We use feature toggles to turn off parts of the app that are not ready for production so we can still deploy code with partial features.

We don't build up sprints with points for time-boxed releases because I have seen negative side effects of that approach. Team members finish early and don't want to start a new story because it's for next week's sprint, or team members are working like crazy to finish before the sprint cutoff so their feature makes it into this release. Both go against the idea of having a steady, sustainable pace of work. If we're doing a release and code isn't ready and won't be ready tomorrow, that's OK.

Definition of Done

We agree on a story being done when the acceptance criteria has been met, the code is checked in, there are passing automated tests for the code, detailed steps for testing the story have been written, the manual testing found no remaining issues, and the business accepted the story as done. At any point, a story moved to the right that doesn't meet one of these can be sent back to the left for rework.

Acceptance Testing the Release Candidate and Deploying to Production

We set up a development integration environment, a staging or user-acceptance testing environment, and production. Once a release candidate has been deployed, the product owner and business test those features. Ideally, this is not the first time they have seen these features or bug fixes, and they are confirming they still work as expected in this release candidate and environment.

After the business and product owner give the go ahead that the release candidate looks OK, it's deployed to production.

Process Review and Improvement

Retrospectives

We don't have sprint retrospectives. Any time is a good time for improvement. We have a culture where suggestions are always carefully considered and incorporated where possible, even if they are a little experimental.

Calculations

After a release, we can recalculate our cycle time (how long it takes a story from work starting to installed in production). This, combined with counting the number of stories per release can give the business a simple tool for predicting when a story they have their eye on will land in production.

For example, if we complete an average of 10 stories per release, and the story in question is number 3 in the backlog and there are 6 stories on the board in progress right now, there is a small chance that story will make it into the current release (it would be the 9th story, and we average 10), but there is very good chance that story will be in the next release after the current one.

Ten disasters to avoid in your next custom software development contract

Sun, 02 Apr 2023 20:39:06 Z

Custom software development is not just about coding. It's about effective communication, mutual understanding, and well-drafted contracts.

Contracts define terms, conditions, and expectations that may arise during the project. But when the contract itself fails to protect your interests, it can lead to disastrous results for your business.

Here we'll discuss ten potential disasters to avoid when writing a contract for custom software development services.

Introduction

Custom software development is a complex process that involves multiple stakeholders, including clients, vendors, project managers, and developers. A well-drafted contract can help all parties achieve their goals and mitigate potential risks.

As the client, you need to ensure that the vendor delivers what they promised and meets your expectations. Vendors need to ensure that they are paid in a timely manner.

Here are ten disastrous consequences that can stem from a poorly-written contract:

Disaster #1: No termination clause

Can you fire the vendor if they fail they deliver substandard work? Without a clear termination clause, you may not have the legal authority to terminate the contract, which can result in delays and financial losses. be sure you have a termination clause that lets you end the contract immediately if you are not happy with the software company's performance.

Disaster #2: Ambiguous scope of work and unclear process software development process

What if the software development company interprets the scope of work differently from what you intended? Do they have a process that can help surface that difference so you can address it? If not, this can lead to disputes and project delays. A clearly-defined scope of work can avoid misunderstandings, but for all but the simplest projects, the scope of work is not enough. You must define the process the development company will use to build the software so you have opportunities to see the work in progress, give feedback, and have the software company change course if needed.

Disaster #3: Vague payment terms

What if you are late on payments, or the vendor demands payment for unfinished work? Clear payment terms help both clients and vendors avoid disputes and financial losses.

Disaster #4: No intellectual property rights

What if the vendor holds the code ransom and refuses to give you access to it? What if they use the code for other client projects without your permission? A well-written contract will define intellectual property rights so everything is clear. Most software development contracts in the United States and western Europe are work-for-hire type contracts where the company paying for the work owns all the intellectual property.

Disaster #5: No liability clause

What if the vendor delivers faulty code that causes harm to your business or customers? Without a liability clause, the vendor may not be legally responsible for the damages. The software company will want to limit that liability, but often the limits are based on what an insurance company would pay out. Be sure any liability limits are sufficient to cover your business loss risk.

Disaster #6: No confidentiality agreement

What if the vendor leaks your confidential information to competitors or third parties? A confidentiality agreement can protect your trade secrets and sensitive information. Look for confidentiality agreements that extend beyond the completion of the project and the termination of the contract, usually a year or more.

Disaster #7: No dispute resolution mechanism

What if a dispute arises between you and the vendor during the project? Dispute resolution mechanisms help the parties resolve the dispute without going to court. You may want to use binding arbitration or some other, less expensive options to sort out disputes.

Disaster #8: No non-compete clause

What if the software company hires your developers? What happens if one of your managers casually mentions that one of the software developers should join your company as an employee? A non-compete clause can define what happens in either of these scenarios and can reduce the risk of this happening for everyone.

Disaster #9: No conflict of interest clause

What if the software company starts working a similar project for your competitors? A conflict of interest clause can assure you that the software company isn't currently working on the same problem with another client or with a close competitor in your industry.

Disaster #10: No support agreement

Finally, your software is in production, but you just found a bug. Do you have a support agreement that defines the role of the software development company for something like this? Will production support be needed, or will your company's IT department take that role? Be sure to think through the maintenance phase of your software and how you want to handle that.

Conclusion

A well-drafted software development contract can help both parties achieve their goals and mitigate potential risks. By avoiding the disasters mentioned above, you can ensure that your project is completed smoothly.

At Volare Software, we have been successfully completing custom software projects since 2009, and we understand the importance of a well-drafted contract. Contact us today to learn more about our custom software development services.

Volare Software Ranked One of the Top 50 Software Development Companies in the United States

Thu, 05 Dec 2019 01:43:56 Z

In November 2019, TechReviewer published its list of the top 50 software development companies in the United States and ranked Volare Software #39. TechReviewer analyzed over 500 software companies in the U.S. to come up with their list of the top 50+.

Joe Wilson of Volare Software said, "It's nice to have some recognition for our work. We are committed to developing high quality software applications that delight our customers."

About Volare Software

Volare Software is a custom software development company with its U.S. location in Denver, Colorado and its E.U. location in Hilversum, Netherlands. They build high quality web and mobile apps that run fast and look great on every device. Since 2009, Volare Software has been building solutions for clients like the U.S. Air Force, AT&T, Kaiser Permanente, and Jeffco Public Schools, to name a few. The company specializes in enterprise application development using agile software development processes that speed up delivery, increase quality, promote transparency and accountability, reduce risk, and ensure high customer satisfaction.

About TechReviewer

TechReviewer is a trusted analytical hub that carries out studies and compiles lists of top development, design, and marketing companies. Specializing in B2B tech companies, TechReviewer's mission is to help businesses make informed decisions to select vendors who provide high quality services.

Volare Software Sponsors Colorado Give Camp

Wed, 24 Oct 2012 04:00:00 Z

Custom software company supports coding for charity.

Volare Software is pleased to sponsor Colorado Give Camp in Colorado Springs this weekend, October 26-28, 2012. This is the third time Volare has sponsored the Give Camp.

GiveCamp is a weekend-long event where technology professionals from designers, developers and database administrators to marketers and web strategists donate their time to provide solutions for non-profit organizations. Since its inception in 2007, the GiveCamp program has provided benefits to over 150 charities, with a value of developer and designer time exceeding $1,000,000 in services.

"GiveCamp is a free, non-profit event that could not be possible without sponsors," says Gabriel Villa, Colorado Give Camp Co-Organizer. "When we called for sponsors, Volare Software stepped up to the cause. Not only have they provided food for a group of volunteers developing for non-profits, but also volunteered their President to develop for the weekend as well. Volare is a real leader in development and a leader in their community."

About Volare Software

Volare Software is a custom software development company with its U.S. location in Denver, Colorado and its E.U. location in Hilversum, Netherlands. They build high quality web and mobile apps that run fast and look great on every device. Since 2009, Volare Software has been building solutions for clients like the U.S. Air Force, AT&T, Kaiser Permanente, and Jeffco Public Schools, to name a few. The company specializes in enterprise application development using agile software development processes that speed up delivery, increase quality, promote transparency and accountability, reduce risk, and ensure high customer satisfaction.

Volare Software celebrates 10-year anniversary

Tue, 02 Jul 2019 01:45:00 Z

Volare Software, a custom software development company based in Denver, Colorado, celebrated its 10-year anniversary in June.

Owner and founder Joe Wilson said, "We're grateful to the clients and employees we've worked with over these first 10 years. We've built large, complex solutions for Fortune 50 companies and built minimum viable products for startups. I'm proud of high-quality software we've delivered. We consistently get glowing reviews and high ratings from both our customers and employees, so we must be doing something right. Here's to the next 10 years."

About Volare Software

Volare Software is a custom software development company with its U.S. location in Denver, Colorado and its E.U. location in Hilversum, Netherlands. They build high quality web and mobile apps that run fast and look great on every device. Since 2009, Volare Software has been building solutions for clients like the U.S. Air Force, AT&T, Kaiser Permanente, and Jeffco Public Schools, to name a few. The company specializes in enterprise application development using agile software development processes that speed up delivery, increase quality, promote transparency and accountability, reduce risk, and ensure high customer satisfaction.

Volare Software among best mobile app development companies in 2019

Mon, 30 Sep 2019 00:43:53 Z

Volare Software was named one of the best mobile app development companies in 2019 by Business of Apps in their just-released guide. The roundup features app development companies from all over the world.

Volare Software specializes in custom web and mobile app development, using progressive web apps (PWAs) for mobile app development. PWAs are a special type of web application that can be installed on a mobile phone like an app and can interact with that device, like by sending push notifications to the user.

Joe Wilson, owner of Volare Software, said, "It's nice to be recognized for the work we've been doing for the last 10 years building high quality custom web apps for our clients."

About Volare Software

Volare Software is a custom software development company with its U.S. location in Denver, Colorado and its E.U. location in Hilversum, Netherlands. They build high quality web and mobile apps that run fast and look great on every device. Since 2009, Volare Software has been building solutions for clients like the U.S. Air Force, AT&T, Kaiser Permanente, and Jeffco Public Schools, to name a few. The company specializes in enterprise application development using agile software development processes that speed up delivery, increase quality, promote transparency and accountability, reduce risk, and ensure high customer satisfaction.

About Business of Apps

Business of Apps provides world class news, analysis, data & marketplaces for app businesses. Founded in 2014, we have become the essential resource for people building, marketing and monetizing apps. Our site reaches a global audience of over 200k app industry professionals a month. We host comprehensive B2B directories and marketplaces covering app ad platforms, app development, app marketing, influencers and other specialist areas.

Volare Software working with U.S Air Force

Mon, 16 Mar 2020 07:56:20 Z

Volare Software, a custom software development company specializing in web and mobile applications, has been awarded a U.S. Air Force Small Business Innovation Research (SBIR) contract through AFWERX and the Air Force Research Lab (AFRL).

The project will advance the development of the Human Resources Smart Weapon, a mobile and tablet-optimized custom web app for onboarding airmen with one click. Common fields will be pre-filled for airmen, fields will be validated as they are entered, multiple PDFs will be created from one form submission, and workflows will route submitted PDF forms for approvals and signatures.

About Volare Software

Volare Software is a custom software development company with its U.S. location in Denver, Colorado and its E.U. location in Hilversum, Netherlands. They build high quality web and mobile apps that run fast and look great on every device. Since 2009, Volare Software has been building solutions for clients like the U.S. Air Force, AT&T, Kaiser Permanente, and Jeffco Public Schools, to name a few. The company specializes in enterprise application development using agile software development processes that speed up delivery, increase quality, promote transparency and accountability, reduce risk, and ensure high customer satisfaction.

About AFWERX

Established in 2017 by the Secretary of the Air Force, AFWERX is a catalyst for agile Air Force engagement across industry, academia, and non-traditional contributors to create transformative opportunities. The core mission of AFWERX is to improve Air Force capabilities by connecting innovators, simplifying technology transfer and accelerating results. AFWERX has partnered with the AFRL, a scientific research organization operated by the U.S. Air Force Materiel Command, to streamline the SBIR process to speed up the experience, broaden the pool of potential applicants, and decrease bureaucratic overhead.

Volare Software Named Best Custom Software Developer in Denver by Digital.com

Fri, 22 Jan 2021 05:22:55 Z

Digital.com, a leading independent review website for small business online tools, products, and services, has named Volare Software to its list of the best custom software development firms in Denver. The top companies were selected based on core service offerings and customer feedback.

Volare Software and other service providers were expected to work with businesses across various industries, including e-commerce, legal, or media. Each firm was also required to offer multiple service lines, such as UX/UI design and web and mobile app development. The guide features both large and small companies to meet the diverse needs of businesses that seek faster project turnaround or budget-friendly services.

Researchers at Digital.com conducted a 40-hour assessment of over 63 companies across the city. To access the complete list of the top 15 custom software developers in Denver, please visit https://digital.com/custom-software-development-companies/denver/.

About Volare Software

Volare Software is a custom software development company with its U.S. location in Denver, Colorado and its E.U. location in Hilversum, Netherlands. They build high quality web and mobile apps that run fast and look great on every device. Since 2009, Volare Software has been building solutions for clients like the U.S. Air Force, AT&T, Kaiser Permanente, and Jeffco Public Schools, to name a few. The company specializes in enterprise application development using agile software development processes that speed up delivery, increase quality, promote transparency and accountability, reduce risk, and ensure high customer satisfaction.

About Digital.com

Digital.com reviews and compares the best products, services, and software for running or growing a small business website or online shop. The platform collects twitter comments and uses sentiment analysis to score companies and their products. Digital.com was founded in 2015 and formerly known as Review Squirrel. To learn more, visit https://digital.com/.

How do you choose a workflow management tool?

Sun, 02 Apr 2023 18:37:07 Z

Attention business owners and managers!

Are you tired of managing multiple spreadsheets, emails, and applications to keep your workflows running smoothly? It's time to streamline your business processes with a workflow management tool.

But with so many options available, how do you choose the right one for your organization? Here are some factors to consider when making your decision.

Vendor Reputation and Longevity

First and foremost, consider the software company's reputation and longevity in the market. You want to choose a vendor that has a proven track record of providing reliable software solutions. Look for customer reviews, testimonials, and case studies to assess their level of customer satisfaction. Additionally, check the vendor's history in the industry to ensure they have the staying power to support your business in the long run.

Technology and Scalability

Next, evaluate the technology and scalability of the workflow management tool. You want a tool that can handle your current workflow demands but can also grow with your business. Consider factors such as the platform's architecture, security features, and performance capabilities. A tool that utilizes REST API development and microservices will offer the flexibility and scalability required to support your evolving business needs.

How the Platform Handles Errors and Hang-Ups

Even the most robust workflow management tools can encounter errors and hang-ups. When selecting a tool, it's crucial to evaluate how the platform handles these issues. Does the vendor offer reliable customer support? What are their response times? Do they have a documented process for resolving issues? These are all questions to consider when assessing the tool's reliability.

Business Process Automation and System Integration

In addition to workflow management, many organizations also require business process automation and system integration capabilities. Look for a tool that supports these functionalities to streamline your business operations. Workflow development and management can be made more efficient when they are integrated with other key systems such as CRM, ERP, and HRM.

Selecting the right workflow management tool can significantly improve your team's productivity and streamline your business operations. By considering vendor reputation and longevity, technology and scalability, and how the platform handles errors and hang-ups, you can make an informed decision. With the right tool in hand, you'll be well on your way to achieving your workflow management goals.

At Volare Software, we specialize in API development, business process automation, system integration, workflow development, and workflow management. Contact us today to learn more about how we can help you streamline your business processes to help you achieve your goals.

Reusing Kendo UI settings to make your app's UI patterns consistent

Sun, 14 Feb 2021 07:44:17 Z

Kendo UI components have LOTS of settings and options. For most web apps, you'll pick a set of options and stick with common UI patterns throughout the app.

Will your app's grids use paging or infinite scrolling of grid data? If paging, how many records should you show on each page? Which UI style should your app's date pickers use? What format should your app's numeric text boxes use by default - whole number or decimal?

One technique for sharing common settings across all Kendo UI components within your app is to set up your defaults and wrap with the jQuery extend function.

Here is a date picker:

import $ from "jquery"; import "@progress/kendo-ui/js/kendo.datepicker"; export function extend(settings) { const commonSettings = { componentType: "modern" }; return $.extend(true, {}, commonSettings, settings);
}

Here is a drop down list where the server returns a text and a value field to populate the drop down:

import $ from "jquery"; import "@progress/kendo-ui/js/kendo.dropdownlist"; export function extend(settings) { const commonSettings = { dataSource: { sort: [{ field: "text" }] // Sort by the field called "text" every time }, dataTextField: "text", // Assume the text field is always called "text" dataValueField: "value", // Assume the value field is always called "value" optionLabel: "- Please Select -", autoBind: false, // Don't bind the drop down on initialization valuePrimitive: true // Use primitives for values, like 123, not objects, like { value: 123, text: "Active" } }; return $.extend(true, {}, commonSettings, settings);
}

Here is a numeric text box for positive whole numbers:

import $ from "jquery"; import "@progress/kendo-ui/js/kendo.numerictextbox"; export function extend(settings) { const commonSettings = { min: 0, step: 1, decimals: 0, round: true, format: "{0:0}" }; return $.extend(true, {}, commonSettings, settings);
}

Use these default app settings by importing the module, referencing the extend method exported by that module, then using, adding to, or overriding the UI defaults needed for that date picker, drop down list, or numeric text box:

import * as datePicker from 'common/datePicker'; import * as dropDownList from 'common/dropDownList'; import * as numericTextBox from 'common/numericTextBox';
$("#myDatePicker").kendoDatePicker(datePicker.extend()); // No change to default values $("#myDropDown").kendoDropDownList(dropDownList.extend({ dataSource: "/api/myDropDown" // Add to, rather than change, default values })); $("#myNumericTextBox").kendoNumericTextBox(numericTextBox.extend({ min: -100 // Override default values }));

This is a good way to have a consistent UI without always copy-pasting key-value pairs across files.

It also allows you to quickly change how your app looks and works across pages and components with a change to the common Kendo UI defaults.

Posts

Unlocking the Power of Custom Software: Is It Worth the Investment?

Introduction

The Expense of Custom Software Development

The Value of Custom Software as an Investment

Cost Savings

Increased Revenue Generation

Factors Influencing the Cost of Custom Software

Complexity

Development Team Expertise

Development Team Location

Conclusion

Advantages of hiring a business-driven custom software consultancy

Should you go with an offshore team for your custom software development project?

Advantages: Cost Savings and a Larger Team

Disadvantages: Languages, Cultures, and Time Zones

How to Mitigate the Risks

Conclusion

Mocking calls with Jasmine

Using Jasmine spies to mock code

Returning values from Jasmine spies

Using Jasmine spies to verify code was called

Testing async calls in Jasmine with jQuery's Deferred and helpers

Testing async calls in Jasmine with Jasmine's done() callback

Testing async calls in Jasmine with async/await

Autocomplete dropdown with jQuery UI and MVC

The view

The controller

Building a Windows 8 Live Tile with JavaScript

Figure out what you want to display on your live tiles

Tests for the correct live tile XML

Build up the live tile XML

Combine the square and wide XML

Pass the combined live tile XML to the Windows 8 API

Calling the notification code

Putting it all together

Branding

Hey, my Live Tile doesn't work!

Making your ASP.NET MVC app look decent on an iPhone or iPad

Think about what your mobile user will want to do

Choose your technical approach

Get jQuery Mobile

Bundling

Make a _Layout.Mobile.cshtml

Start using jQuery Mobile

Make a Mobile.css

Test and tweak your views

Getting HTTP/2 working with Azure CDN

Azure Setup

Web Setup

Storage Setup

CDN Setup

Working with two sets of ESLint rules for legacy ES5 and modern JavaScript using Gulp

Fix for weird errors in MVC4 when adding a new Area

The first error

The second error

The solution

Running SpecFlow and WatiN tests with TeamCity and AppHarbor

TeamCity

AppHarbor

Sharing data from within your Windows 8 app using JavaScript

What do you want to share?

Listen for the sharing event

Build up the Sharing payload

Adding a button to start Sharing

Validation frameworks in ASP.NET MVC

How are they different?

How do you integrate them with MVC?

How do you lay this out in the solution?

What else can you do?

The case for TDD

Focusness

Dude, you know what would make this REALLY cool?

SOLID code

Oh yeah, you get some tests, too

Ruthless Refactoring

Showing and saving user settings in a Windows 8 app with JavaScript

Create the Options view

Open the Options view

Save and recall user settings for your app