Adding pagination with DocPad

Saturday, July 26, 2014 | Posted in Blog DocPad

Last year when I started this blog I decided to keep the layout as simple as possible, hence all the posts were just added to the home page and to their own page. Over time as more posts were written the home page got larger and larger making it slower to load and more difficult to navigate. In order to improve this pagination of the home page was introduced.

Once again DocPad makes this very easy because all you have to do is add the DocPad-paged plugin and then update the documents you want to split. In the case of this blog only the index page needed to be split. The new index page now looks like this:

In order to make the paged plugin do its work the following 'properties' were added to the header:

  • isPaged - Indicates that the document should be broken up into multiple pages.
  • pageCollection - The collection from which the sub-documents that will fill up the current page are taken.
  • pageSize - The number of sub-documents per page

Finally two buttons were added to the bottom of the page to naviage to he newer and the older posts.

Blog archives by DocPad

Thursday, July 24, 2014 | Posted in Blog DocPad

A while ago I decided that it was time to add an archive page to the website so that there would be a place to get a quick overview of all the posts that I have written. Fortunately setting up an archive page with DocPad is relatively simple.

The first step to take was to add a new layout for the archive page.

The layout gets the list of all posts and iterates over them in chronological order. All the posts for one year are grouped together under a header titled after the year. In keeping with the layout of the rest of the site each post gets a title, the day and month and the tags that belong to that post. In order for this specific layout to work you will need to add the moment node.js package

The layout and the CSS for the archive page is heavily based on the layout created by John Ptacek.

nBuildKit release - V0.2.4

Monday, July 21, 2014 | Posted in nBuildKit

Version V0.2.4 of the nBuildKit build library has been released.

This release introduces NuGet packages that allow Visual Studio C# and WiX projects to share a common configuration including code analysis and strong naming capabilities and to generate one or more source files before building the project.

Both packages provide the ability to share a configuration between multiple projects in a Visual Studio solution. The shared configuration can contain items like Debug and Release settings, targeted .NET framework, code analysis settings and many other options.

Beyond that the C# NuGet package provides capabilities to:

  • Generate AssemblyInfo.XXXX.cs files for:
    • AssemblyInfo.VersionNumber.cs contains the version numbers for the project as determined by nBuildKit from the versioning strategies provided. Currently supported are either a version number provided through an MsBuild project file or through GitHubFlowVersion. By allowing nBuildKit to generate the AssemblyInfo.VersionNumber.cs file it is possible to automatically version the binaries the same way as all other artifacts, e.g. NuGet packages, installers, documentation etc. etc.. The version number is currently provided through the AssemblyVersionAttribute as Major.Minor.0.0; through the AssemblyFileVersionAttribute as Major.Minor.Patch.Build; and through the AssemblyInformationalVersionAttribute as the full semantic version.
    • AssemblyInfo.BuildInformation.cs contains information about the current build of the binaries. This includes the configuration, e.g. Release; the date and time that the binary was compiled and information describing the build number and the commit number that were used to generate the binaries.
    • AssemblyInfo.InternalsVisibleTo.cs contains the InternalsVisibleToAttribute values for any assemblies that should have access to the internals of the current assembly for purposes of unit testing.
    • AssemblyInfo.Company.cs contains the information describing the 'company' that created the binaries. The information includes the AssemblyCompanyAttribute and the AssemblyCopyrightAttribute.
  • Generate a CompanyInformation.cs source file that contains an internal static class providing constants for the company name and the company URL.
  • Generate a ProductInformation.cs source file that contains an internal static class providing constants for the name of the product.
  • Generate an app.manifest file with the current project version number.

And the WiX NuGet package provides capabilities to

  • Generate a VersionNumber.wxi WiX include file that contains the version numbers for the application and the installer.
  • Generate a CompanyInformation.wxi WiX include file that contains the name and URL of the company that produces the product.
  • Generate a ProductInformation.wxi WiX include file that contains the name and description of the product.

The generation of all of these files can be enabled through a setting in the settings.props file that is also used by the nBuildKit.MsBuild NuGet package

The documentation for this library can be found on the nBuildKit wiki

nBuildKit release - V0.1.5

Monday, June 16, 2014 | Posted in nBuildKit

Version V0.1.5 of the nBuildKit build library has been released.

This first release introduces the MsBuild NuGet package. This package contains build scripts that provide the ability to perform a complete build consisting of workspace preparation, compilation of binaries, execution of unit tests, analysis of source code and binaries and finally packing of the binaries as NuGet packages or ZIP archives. The nBuildKit.MsBuild NuGet package also provides scripts that can be used to tag a release in the version control system (VCS) and deploy the artifacts to a file server, NuGet feed or a GitHub release.

The documentation for this library can be found on the nBuildKit wiki

Nuclei release - V0.8.0

Wednesday, May 28, 2014 | Posted in Nuclei

Version V0.8.0 of the Nuclei library has been released.

This release introduces a few large features to Nuclei.Communication library and adds some minor updates to the base Nuclei library.

The main focus of this release was adding version tolerance (#3) to the different layers of the communication stack:

  • The discovery layer - Provides ways to discover remote endpoints either automatically (via WCF discovery) or manually.
  • The protocol layer - Provides the means to send messages to one or more remote endpoints and handling the responses to those messages if they are expected.
  • The interaction layer - Provides an abstraction over the protocol layer in the form of an proxy objects that provide user-defined methods which can be invoked on a remote endpoint.

In version 0.8.0 of the Nuclei.Communication library each of these layers now supports the ability to negotiate with a remote endpoint to determine which communication version will be used to exchange data between the endpoints. The communication version which will be used is the highest (i.e. most recent) version that both endpoints support. If the endpoint do not support the same versions then communication will not be enabled between the endpoints.

The second focus was to improve the robustness of all the network activity. The main changes here were:

  • #7 - Detection of messages that have not received their response within a given time-out.
  • #11, #17, #18 - Method(s) to detect if a remote endpoint is still available and discard endpoint information if it is not.
  • #19, #23 - Automatically rebuilding the communication channel if it faults during message sending and then resend the message that caused the faulting.

The final focus was on decoupling the interaction interfaces from their implementations. With these changes an endpoint does not need to provide concrete implementations of either the command (#6) and notification (#31) interfaces but can map the members on those interfaces to equivalent members on any given object.

Additionally it is now possible for some parameters on a command interface method (ie. the method on a command interface) and a command object method (i.e .the concrete instance method that is mapped to the given command) to contain parameters that have a special meaning. The available options are:

  • For command interface methods (#23)
    • Provision of a time-out indicating the maximum amount of time the endpoint should wait for a response to the command invocation request.
    • Provision of a retry count indicating the maximum number of times the endpoint should send the command invocation request should any errors occur during invocation.
  • For command instance methods (#28)
    • Provision of the ID of the endpoint requesting the invocation of the command method.
    • Provision of the ID of the message that was send to request the invocation of the command method.

Finally the Nuclei library versioning was switched to use semantic versioning.