IFTTT Bookmarks

For a couple of years I have stored my bookmarks in GMail. I used the gmail + trick to send these bookmarks to myself and via a simple filter a labelled them accordingly. Storing the bookmarks in GMail makes it very flexible, they can be tagged,  grouped and searched.


But now that I have a site, I thought it would be nice if these ‘bookmark’ emails are published here as well. Instead of manually adding the books to the site I have configured an IFTTT rule to do this.


Now I only have to find a way to get all my old email bookmarks to WordPress.

PowerShell backup

I’m running a virtual server with a number of web applications on it. For a couple of years I did the backup and the daily maintenance via a custom made C# application. But I thought that it would be better if I used Microsoft PowerShell because it is actually made for this kind of work. So after reading some tutorials and digging around on stackoverflow I came up with the following script. It is not doing all the stuff I would like, but it’s a start.


I have been working on a ASP.NET MVC application for a dart statistics enthousiast. This application stores information about all the played games and scores of TV darts tournaments from the last 30 years. One of the starting points of this project was to make this data accessible by other websites. Building the web application with MVC, the ASP.NET Web API seems like a logical candidate.

The implementation of a Web API is straightforward and a lot of functionality is provided by the framework.

Beside the exposed methods there were also a number of prerequisites. The API should support multiple versions, it should be documented and there should be some form of authentication. Some of the details while implementing these requirements are described in the next section.


One thing I learned as a developer is that API’s always change. So it you have 3rd parties that are using the API, versioning is a must. So after some considerations I decided to go with the twitter setup which uses a version number in the URI. (stats.idarts.nl/api/v1/). By using routes and area’s the project layout is shown below.


For each action I defined a route that leads to the specific version.

using DartStat.Web.Filters;
using DartStat.Web.Areas.Apiv1.Models;

namespace DartStat.Web.Areas.Apiv1.Controllers
    public class CompetitionV1Controller : BaseApiController
        /// <summary>
        /// Get list of all the available competitions.
        /// </summary>
        /// <returns></returns>
        public IEnumerable<CompetitionViewModel> Index()
            var competitions = CurrentUser.Subscriptions;
            var items = new List<CompetitionViewModel>();


This API is used by a number of companies so sort of API documentation is a must. After some searching on the internet I found the Microsoft ASP.NET Web API 2.2 Help Page nuget package that makes it a lot easier to document API. The nice thing about this packages is, besides of course that the documentation is generated from code, that it’s source code (controllers/views) are integrated in the project. This makes is possible to change the code and the view templates.

I used this last feature to add support for derived classes in the API. Via the DataContract attribute it is possible to make use of derived classes in the API but the Help generator doesn’t generate any help for these models. By extending the documentation generation this can be fixed.

Derived classes are defined as follows:

namespace DartStat.Web.Areas.Apiv2.Models
    /// <summary>
    /// Base set of properties for a match. The data of the match is 
    /// either extended with players information or pair information.
    /// </summary>
    public class MatchViewModel
        public long KeyA { get; set; }

By added an extra property in the ModelDescriptions the information of the derived classes can be stored.

namespace DartStat.Web.Areas.HelpPage.ModelDescriptions
    /// <summary>
    /// Describes a type model.
    /// </summary>
    public abstract class ModelDescription
        public string Documentation { get; set; }

        public Type ModelType { get; set; }

        public string Name { get; set; }

        public IEnumerable<ModelDescription> ParentOf { get; set; }

This ParentOf property can be filled in the HelpController:

        public ActionResult ResourceModel(string modelName)
            if (!String.IsNullOrEmpty(modelName))
                ModelDescriptionGenerator modelDescriptionGenerator = Configuration.GetModelDescriptionGenerator();
                ModelDescription modelDescription;
                # if class has a model KnowType attribute then generate a description model for the found model.
                # and fill the ParentOf property. 
                # Implement here.
                if (modelDescriptionGenerator.GeneratedModels.TryGetValue(modelName, out modelDescription))
                    return View(modelDescription);

The last change is in the view code:

 @if (Model.ParentOf != null)
        foreach(var item in Model.ParentOf)
            <h2>Class extensions @item.Name.Substring(Model.Name.LastIndexOf(".") + 1)</h2>
            <section class="content-wrapper main-content clear-fix">
                @Html.DisplayFor(m => item)

Another problem I had was the naming of the controllers. In the first setup, the different areas had the same controllers. This setup isn’t supported by the help page generator. For now I added the version number in the controller name. Another option would be to add the FullName in the help generation storage classes, this solution is shown on this page.


The API is not open to everybody so there should be a way from the user to sign in. I wanted to start with a simple setup that is easily tested I started with basic http authentication. This means that in each request the credentials are provided in the header.