Metaprogramming Fun In JavaScript

Tuesday, September 3, 2013 by K. Scott Allen
3 comments

The idea is to take a JavaScript statement like the following:

c.find({ x: 1, y: 3, name: "foo" }, { id: 0 }).limit(1);

.. and turn the statement into a data structure that describes the methods being invoked and the arguments for each method call. There are multiple method names to capture (not just find and limit, but also findOne, orderBy, and more).

This sounds like a job for a mock object library, but let’s explore a few simple approaches that use < 20 lines of code.

One approach that doesn’t work is try to to build a function for each possible method call and forget how closures work. The following code has a bug.

var CommandCapture = function () {

    var commands = ["find", "findOne", "limit", "orderBy"];

    for (var i = 0; i < commands.length; i++) {
        this[commands[i]] = function() {
            return {
                name: commands[i], // here's the problem
                args: arguments
            };
        };
    }
};

By the time the innermost function executes, the value of i is outside the bounds of the commands array, so the name isn’t properly captured.

To avoid the closure problem we can embed the command name into a string and use the Function constructor.

var CommandCapture = function() {
    
    var commands = ["find", "findOne", "limit", "orderBy"];
    
    for (var i = 0; i < commands.length; i++) {
        this[commands[i]] = new Function("return { name: '" +
                                            commands[i] +
                                         "', args:arguments };");
    }
};

But ... building functions out of strings is tiresome and error prone, so instead we can use an IFFE and capture the value of i in a more proper manner.

var CommandCapture = function () {

    var commands = ["find", "findOne", "limit", "orderBy"];

    for (var i = 0; i < commands.length; i++) {
        this[commands[i]] = function(name) {

            return function() {
                return {
                    name: name,
                    args: arguments
                };
            };
            
        }(commands[i]);
    }
};

The above code will work for simple cases. Executing the following code:

var capture = new CommandCapture();
var result = capture.find({ x: 1, y: 3, name: "foo" }, { id: 0 });
console.log(result);

Yields this output:

{ 
    name: 'find',
    args: { '0': { x: 1, y: 3, name: 'foo' }, '1': { id: 0 } }
}

However, the above code doesn’t allow for method chaining (capture.find().limit()). The following code does, by keeping all the method calls and arguments in a field named $$captures.

var CommandCapture = function () {

    var self = this;
    self.$$captures = [];
    var commands = ["find", "findOne", "limit", "orderBy"];

    for (var i = 0; i < commands.length; i++) {
        this[commands[i]] = function (name) {

            return function () {
                self.$$captures.push({ name: name, args: arguments });
                return self;
            };

        }(commands[i]);
    }      
};

These are the types of problems that are fun to work on during a Saturday afternoon thunderstorm.

Dynamic Tabs with AngularJS and UI Bootstrap

Wednesday, August 14, 2013 by K. Scott Allen
4 comments

I’ve been working on a  data management tool where I want to give users “workspace” areas. Each workspace is encapsulated inside of a tab, and a user can add a new workspace by clicking an icon in the tab bar, as in the following picture.

image

This feature isn’t too difficult to put together using AngularJS plus UI Bootstrap. UI Bootstrap provides directives and templates to work with Bootstrap components like tabs, accordions, alerts, and dialogs.

The first bit of code here is the TabsParentController, which is responsible for managing multiple workspaces.

module.controller("TabsParentController", function ($scope) {

    var setAllInactive = function() {
        angular.forEach($scope.workspaces, function(workspace) {
            workspace.active = false;
        });
    };

    var addNewWorkspace = function() {
        var id = $scope.workspaces.length + 1;
        $scope.workspaces.push({
            id: id,
            name: "Workspace " + id,
            active: true
        });
    };

    $scope.workspaces =
    [
        { id: 1, name: "Workspace 1", active:true  },
        { id: 2, name: "Workspace 2", active:false }
    ];

    $scope.addWorkspace = function () {
        setAllInactive();
        addNewWorkspace();
    };       

});

Most of the tricky parts come in the HTML markup, which uses UI Bootstrap directives to create the tabs. You can see one tab created for each workspace, plus a static tab with the “+” sign icon.

<div ng-controller="TabsParentController">
    <tabset>
        <tab ng-repeat="workspace in workspaces"
             heading="{{workspace.name}}"
             active=workspace.active>
            <div ng-controller="TabsChildController"  
                 ng-init="workspace=workspace">
                <div>
                    {{workspace.id}} : {{ workspace.name}}
                </div>
                <input type="text" ng-model="workspace.name"/>
            </div>     
        </tab>
        <tab select="addWorkspace()">
            <tab-heading>
                <i class="icon-plus-sign"></i>
            </tab-heading>
        </tab>
    </tabset>
</div>

The hardest part was figuring out how to tell the TabsChildController which workspace object to use. Although prototypal inheritance is a nice way to share information between a parent and child controller, in this case the child controller inherits all the workspaces from its parent, and doesn’t know which specific workspace to use.

To get around this problem I used an ngInit directive to create a workspace attribute in the child controller’s scope. The value of the workspace is the workspace used from the outer repeater scope. This is confusing if you haven’t worked with Angular for awhile, I think, so if you think of a better solution I’m all ears!

Attribute Routes and Hierarchical Routing

Monday, August 12, 2013 by K. Scott Allen
6 comments

As announced earlier this year, attribute routing will be a part of the next ASP.NET release. You can read more about the feature on the asp.net wiki, but here is a quick example to get the idea:   

public class ServerController : ApiController
{         
    [GET("api/server/{server}")]
    public IEnumerable<string> GetDatabaseNames(string server)
    {
        // ...
    }

    [GET("api/server/{server}/{database}")]
    public IEnumerable<string> GetCollectionNames(string server, string database)
    {
        // ...        
    }     
}

Attribute routing has been around for some time (you can use it today), and is invaluable for certain types of applications. While today’s default routing approach in ASP.NET MVC and Web API is easy and conventional, the  approach lacks the flexibility to make the hard scenarios easy. Scenarios like modeling hierarchical resources as in the above code, where the application wants to respond to api/server/localhost/ and api/server/localhost/accoutingdb. Other scenarios include creating controller actions with custom parameter names, and actions that can respond to multiple URIs.

Overall, the addition of attribute routing to the framework is a win.

However . . .

One of the benefits of attribute routing listed on the asp.net wiki is:

[Talking about conventional routing] –> The information about what URI to use to call into a controller is kept in a completely different file from the controller itself. A developer has to look at both the controller and the global route table in configuration to understand how to call into the controller.

An attribute-based approach solves all these problems by allowing you to configure how an action gets called right on the action itself. For most cases, this should improve usability and make Web APIs simpler to build and maintain.

I disagree!

I personally like centralized route configuration. Having routes defined in one place makes it easier to order and optimize the routes, and also think about URIs before thinking about an implementation (which is arguably more important for an API than a regular web site).

As a comparison, consider Darrel Miller’s ApiRouter, which also allows for flexibility and hierarchy in the routing rules (below is an excerpt for routing rules to mimic GitHub’s model). 

Add("issues", ri=> ri.To<IssuesController>());
Add("events", ri => ri.To<EventsController>());
Add("networks", 
  rn => rn.Add("{userid}", 
    ru => ru.Add("{repoid}", 
      rr => rr.To<NetworksController>())));

Add("gists",rg => rg.To<GistsController>()
  .Add("public",
     rp => rp.To<GistsController>(new { gistfilter = "public" }))
  .Add("starred", 
     rs => rs.To<GistsController>(new { gistfilter = "starred" }))
  .Add("{gistid}", 
      rgi => rgi.To<GistController>("justid")
  .Add("comments", 
      rc => rc.To<GistCommentsController>())

In the end, I believe using an approach like ApiRouter will lead to a routing configuration that is easier to understand, optimize, maintain, and troubleshoot.

I believe it will also will lead to a better API design, because attribute routing makes it easy to destroy the uniform interface for a resource and avoid looking at the bigger picture of how the URIs work together. 

Thoughts?

Group and Display Data with Underscore and AngularJS

Thursday, August 8, 2013 by K. Scott Allen
6 comments

Let’s use the following data to simulate information you might receive from an HTTP API:

$scope.data =
[
    { department: "engineering", name: "Scott" },
    { department: "engineering", name: "Joy" },
    { department: "sales", name: "Sara" }
];

Using underscore.js, it is easy to group the objects by their department attribute.

$scope.groups = _.groupBy($scope.data, "department");

Now $scope.groups will look like the following:

{"engineering":
   [{"department":"engineering","name":"Scott"},
    {"department":"engineering","name":"Sally"}],
 "sales":
   [{"department":"sales","name":"Fred"}]
}

One way to get the data onto the screen is to use an ngRepeater, but the most popular expression form for the repeater (”variable in expression”) doesn’t exactly give us what we want.

<div data-ng-repeat="department in groups">
    <h4>{{ department }}</h4>        
    <ul>
        <li data-ng-repeat="employee in department">
            {{ employee.name }}
        </li>
    </ul>
</div>

That’s because department will hold each value of the groups collection.

image

What we really want is the lesser known expression supported by Angular: (key, value) in expression.

<div data-ng-repeat="(department, employees) in groups">
    <h2>{{department}}</h2>        
    <ul>
        <li data-ng-repeat="employee in employees">
            {{ employee.name }}
        </li>
    </ul>
</div>

Which gives us:

image

As always, there are 101 ways to achieve this end result, but I rather like the (key, value) expressions myself.

Deliberate Practice In Tests

Wednesday, August 7, 2013 by K. Scott Allen
0 comments

Something else we touched on in “Being a Better Developer” are the benefits of deliberate practice.

Over the years I’ve developed a habit I’d consider deliberate practice, and that’s the habit of writing unit tests when learning a new language, framework, or library. I’m not testing for quality, but trying to internalize what I’m learning about a new topic by writing code and experimenting.

Learning becomes a combination of reading documentation, reading source code (sometimes via a decompiler), and practicing code by writing code in tests.

For example, here are some of the tests I’ve written again the new Immutable Collections:

[Fact]
public void Modification_Returns_A_New_List()
{
    var list1 = ImmutableList.Create<int>(1);
    var list2 = list1.Add(2);

    Assert.False(Object.ReferenceEquals(list1, list2));
}

[Fact]
public void Create_Always_Returns_Same_Empty_List()
{
    var list1 = ImmutableList.Create<int>();
    var list2 = ImmutableList.Create<int>();

    Assert.True(Object.ReferenceEquals(list1, list2));
}

[Fact]
public void Clear_Returns_Same_Empty_List_As_Create()
{
    var list1 = ImmutableList.Create<int>(1,2,3);
    var list2 = ImmutableList.Create<int>();

    list1 = list1.Clear();

    Assert.True(Object.ReferenceEquals(list1, list2));
}

Writing simple tests like these give me confidence in using a new technology.

Being A Better Programmer

Tuesday, August 6, 2013 by K. Scott Allen
7 comments

Iris and I put together “Being a Better Programmer” with tips and strategies for everything from writing code to time management. We’ll list our favorite books and tell you a bit about how we got started in the industry, as well as talk about how we learn the business domain and where to go to find some good code to read.

Learning To Program - Being A Better Programmer

One of the techniques we talk about for being a better programmer is writing code – lots of code. Sometimes the code is a hobby project you work on for personal fun, sometimes the code is a kata or a koan, and sometimes the code is something you deliberately implement to see how something works in isolation. I have many little projects checked into source control that only exist to understand how something works.

For example, the behavior of a List<T>. If you want to figure out the default capacity of a List<T>, as well as the algorithm it uses to increase capacity, then you can use a decompiler or create a small experiment project to test a List<T> under different scenarios. While the decompiler is a useful exercise on its own, a small project with code is something that can give you hours of enjoyment as you run the program under different framework versions and try different parameters.

Here’s one I wrote recently that provides some interesting results.

static void Main(string[] args)
{            
    var list = new List<int>();            
    var newCapacity = list.Capacity;
    var oldCapacity = newCapacity ^ Int32.MaxValue;

    while (true)
    {
        if (oldCapacity != newCapacity)
        {
            Console.WriteLine(newCapacity);
            oldCapacity = newCapacity;              
        }
        list.Add(1);
        newCapacity = list.Capacity;
    }
}

For those who watch, I hope you enjoy the course!

Self Hosting WebAPI with Katana

Wednesday, July 24, 2013 by K. Scott Allen
0 comments

A few weeks ago we looked at a minimalistic Katana based project to serve a static response from a console application. For more fun we can throw in the WebAPI with only a little more work. The first step is adding a package that forms a bridge between the OWIN/Katana host and the WebAPI.

Install-Package Microsoft.AspNet.WebApi.OwinSelfHost -IncludePreRelease

The OwinSelfHost package depends on some of the core WebAPI packages, so one install command will bring in everything we need to get WebAPI up and running.

WebAPI does require some configuration to process requests, and we need to provide a routing rule describing how to map incoming requests to controllers. The configuration is always done using an instance of an HttpConfiguration object. In a traditional ASP.NET hosting scenario we access an existing WebAPI configuration object through GlobalConfiguration.Configuration, but in a self hosting scenario we need to create our own. Let’s create a custom class.

public class MyHttpConfiguration : HttpConfiguration
{
    public MyHttpConfiguration()
    {
        ConfigureRoutes();
        ConfigureJsonSerialization();
    }

    private void ConfigureRoutes()
    {
        Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );
    }

    private void ConfigureJsonSerialization()
    {
        var jsonSettings = Formatters.JsonFormatter.SerializerSettings;
        jsonSettings.Formatting = Formatting.Indented;
        jsonSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();
    }
}

Back in the Startup class, we no longer need to configure our own async handler to say “Hello, World!”. Instead we’ll add the WebAPI with the UseWebApi extension method provided by WebApi.OwinSelfHost, and an instance of our custom config class.

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        var config = new MyHttpConfiguration();
        app.UseWebApi(config); 
    }
}

The UseWebApi method installs a piece of Katana middleware (topic for a future post) that adapts HTTP request and response messages in the OWIN pipeline to and from the HttpRequestMessage and HttpResponseMessage objects that form the core of the WebAPI abstraction, as well as configuring the environment for the message processing. For example, setting Thread.CurrentPrincipal.

Now all need is a model and a controller.

public class Greeting
{
    public string Text { get; set; }
}

public class MessageController : ApiController
{
    public Greeting Get()
    {
        return new Greeting
        {
            Text = "Hello, World!"
        };
    }
}

Finally, we can run the application and verify that IE11 still uses Notepad to display JSON payloads.

json with ie11

by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!