Monday, June 30, 2014

LearnerJS: Back to Basics Presentation

Thanks to everyone who came out for the inaugural meeting of LearnerJS!

Topic

Back to Basics: The importance of testable modular JavaScript components.

Summary

What do jQuery Plugins, Angular Directives, Knockout Components, and Ext JS classes all have in common? Modular Components! In this session we will discuss the importance of modular and reusable JavaScript components, define goals for abstraction and test-ability, and get into some demos showing how to achieve those goals.

Downloads

Enjoy,
Tom

Saturday, June 21, 2014

Waiting for Events with Tasks in .NET

Would you like to just await the next time that an event fires? It takes a little setup, but you can!

Migrating your code from using an Event-based Asynchronous Pattern to an Task-based Asynchronous Pattern can be very tricky. You can use the TaskCompletionSource to manage your Task, and then you just need to create the wire up around registering and unregistering your event handler. Unfortunately this process is not nearly as generic as I would like.

Event-based Asynchronous Pattern Tests

Here is a way of waiting for an event to fire by simply sleeping while we wait.

This is a terrible solution because we can not know how long we will have to wait for the event. This means we have to wait for one long time period, or we have to periodically poll to see if the event has fired.

public delegate void SingleParamTestDelegate(int key, string value);
 

Saturday, June 14, 2014

NUnit TestCase, the Data Driven Unit Test

A while back I wrote a blog post about data driven unit testing with xUnit. Back then a reader had to correct me because I did not think that NUnit had support for such things.

NUnit 2.5 added a slew of great features for authoring your own data driven unit tests. Perhaps best of all is the amazing support that ReSharper offers for the NUnit test cases.

You really should be using these amazing features when authoring your unit tests!

Data Driven NUnit Samples

// Here is a simple example that is the equivalent of an
// inline data attribute from xUnit.
 
[TestCase(1, 2, 3)]
[TestCase(2, 3, 5)]
public void SimpleSumCase(int a, int b, int expected)
{
    var actual = a + b;
    Assert.AreEqual(expected, actual);
}
 

Sunday, June 8, 2014

How to stream a FileResult from one web server to another with ASP.NET MVC

MVC has a lot of great built in tooling, including the ability to stream very large file results straight from disk without having to load the whole file stream into memory.

What about the scenario where you want to stream a large file from one web server to another?

For example, I have an ASP.NET MVC application that needs to expose a download for a file hosted on another server, but I can not just redirect my users directly to the other URL. For that, we need to create a custom ActionResult type!

WebRequestFileResult

Here is a simple of example of what your controller might look like:

public class FileController : Controller
{
    public ActionResult LocalFile()
    {
        return new FilePathResult(@"c:\files\otherfile.zip", "application/zip");
    }
 
    public ActionResult RemoteFile()
    {
        return new WebRequestFileResult("http://otherserver/otherfile.zip");
    }
}

Tuesday, May 27, 2014

Three Things All Applications SHOULD WANT to Have

This is the third in a three part series:

  1. Three Things that all Applications MUST Have
  2. Three Things that all Applications SHOULD Have
  3. Three Things that all Applications SHOULD WANT to Have

Somehow these three things are quite controversial. I have had many debates with people who are not using these practices and services, and they are not convinced of their usefulness. However everyone I have met that has used these tools is always a staunch defender of their value! I beg you to give these a chance, try them out and they will prove their merit to you!

Do you agree or disagree with these practices? Let me know in the comments!

1. Error Reporting

How do you know what is wrong with your application? Without proof you are just guessing!

Reporting errors to a central location helps you solve problems the moment they begin, not after they have negatively impacted your entire user base. Here is a fun Microsoft statistic: 80% of customer issues can be solved by fixing 20% of the top-reported bugs. So start reporting your exceptions today!

2. User Impersonation

The easiest way to recreate a bug reported from a specific user is to actually be that user. By adding user impersonation to your application you can save your QA team hours of time. While I completely understand the security concerns of this feature, I must still emphasize the value that it returns in the forms of testing and debugging.

You may want to take this code out in production, but make sure you have in QA and Dev!

3. Continuous Deployment

There is a difference between continuous delivery and continuous deployment, and I am talking about continuous deployment. Just imagine: instant bug fixes, constant streams of new features, and best of all no more deployment schedules! This is not a cheap goal to achieve and it requires continuous maintenance of your tests and deployments, but so does all software development!

To be honest I have never worked in an environment where we made it all the way to continuous deployment, but I would really like to someday! The few people I have met who have been able to accomplish this task had nothing but great things to say about it. Like always I would suggest starting small with a new practice like this, pick an internal application or minor project and begin your foray into continuous deployment from there.

Miss a post in this series? Start over with part 1: Three Things that all Applications MUST Have

Enjoy,
Tom

Monday, May 26, 2014

Three Things that all Applications SHOULD Have

This is the second in a three part series:

  1. Three Things that all Applications MUST Have
  2. Three Things that all Applications SHOULD Have
  3. Three Things that all Applications SHOULD WANT to Have

These three things are all generally agreed upon as being best practice, and few people will argue against their value. Unfortunately not all teams take the time to set them up. Again, I can not emphasize how much time these services will save you time in the long run, the earlier you set them up the more value they will return to you!

1. Dynamic Configuration

What the hell is "dynamic" configuration? It's configuration that is simply not not static or hard coded. Do not use constant strings or compiler symbols to configure your application! Start by using configuration files and build transforms. If your system is very distributed, consider using remote or discovered configuration.

2. Continuous Integration

How do you know that the code in your source control is in a functional state? If not, who broke the build? Continuous integration is the practice of consistently pulling and building the projects in source control in an automated fashion. Typically these builds will also execute any tests associated with the project and provide reports for each build. This is crucial rapid development, and is a necessary first step on the road to continuous deployment.

3. Automated Deployment

Before we can get to continuous deployment we have to start with automated deployment. This is simply the act of having a service that deploys your applications to an environment without the need for any significant human interaction; i.e. you can deploy with the click of a button! Automated deployment is extremely useful because it drastically speeds up deployments, prevents human error, and restricts access to different environments (such as production). Please, do not under estimate the value that a deployment system can provide!

Continue reading part 3: Three Things that all Applications SHOULD WANT to Have

Enjoy,
Tom

Sunday, May 25, 2014

Three Things that all Applications MUST Have

This is the first in a three part series:

  1. Three Things that all Applications MUST Have
  2. Three Things that all Applications SHOULD Have
  3. Three Things that all Applications SHOULD WANT to Have

I feel very strongly that when you start a new project you should spend your first day or two just setting up a few basic utilities. For every hour you spend at the beginning of a project setting up these tools you will save yourself days down the line.

1. Logging

What is your application doing? How can you debug it? Will that work in all environments? The go to answer for these questions should always be logging!

I am constantly amazed at how many applications do not have a logger. To be fair, most of the time when I do not see a logger it is because the application is small or started out as a one off project. However to me that is all the more reason to just take the time and setup a logger right from a project's inception, then you know it will always be there. Thick client, thin client, or back end service, it should have a logger!

2. Dependency Injection

Dependency Injection is a pattern that drives a lot of best practices: it allows you to loosely couple your modules, forces you to consider the number dependencies any given module requires, and perhaps most importantly it makes your code very testable. The inversion of control that dependency injection provides also enables you to refactor and test in ways that are almost unachievable without it.

It can take a little while to fully understand dependency injection, especially the intricacies of lifetime management, but once you understand the fundamentals you can apply that knowledge to any language and any framework.

3. A Test Project

There is no reason not to have a test project as part of your solution. Regardless of how you feel about Test Driven Development (TDD) as a best practice we should all be able to agree that unit testing does provide value and is a good thing.

I encourage you to start simple: just create a test project with ONE unit test inside of it. Even if you do not have time to write tests right now, just having the project already setup will enable you to write them later. Additionally, just thinking about writing unit tests encourages you to author more testable code; so if absolutely nothing else then just use your test project as a best practices placebo!

Continue reading part 2: Three Things that all Applications SHOULD Have

Enjoy,
Tom

Real Time Web Analytics