15 August 2013

Though it isn't strictly code-related, writing cases concerns every person involved in the development process. From designers to developers to testers, writing good cases is vital to the efficiency of the project workflow.

This video on making cases in FogBugz, the bug tracking system that we use, breaks cases into three basic types of information: title, metadata, and notes.

A good case doesn't just convey the right information; it presents the information in a way that is easily readable and lacks ambiguity. A well written and laid out case saves time for every subsequent reader.

Expand This List

03 June 2013

In our last video, we looked at using the async and await keywords in a console application. This week's video uses async and await in a WPF application.

First we create a simple event handler using async and await. Then we simulate what happens behind-the-scenes with await by implementing the same behavior using continuation tasks. Just like await, we capture the SynchronizationContext and use the Post method to run the continuation on the UI thread.

Next we use DBpedia's SPARQL endpoint to asynchronously execute a query against its structured data from Wikipedia. We then see what happens when an exception is thrown in an awaited task.

14 May 2013

By default, ASP.NET uses shadow copying, which "enables assemblies that are used in an application domain to be updated without unloading the application domain." Basically, it copies your assemblies to a temporary folder and runs your web app from there to avoid locking the assemblies, which would prevent you from updating those assemblies.

This works great for managed DLLs, but not very well for native DLLs. ASP.NET doesn't copy the native DLLs, so the web app fails with an error that doesn't even make it obvious that a native DLL is missing or which one it is.

The simplest solution I've found is to turn off shadow copying, which causes the DLLs to be loaded directly from the bin directory. This is the strategy now being used in production by Biblia.com. Just add a <hostingEnvironment> element to your web.config:

This also works for local development, but you may find that you need to restart the app pool in order to rebuild the app. Biblia has a pre-build step that runs appcmd stop apppool and a post-build step that runs appcmd start apppool with the corresponding /apppool.name argument.

Alternatively you could consider removing <hostingEnvironment> from your local web.config and putting your bin folder in the PATH system environment variable, but that will be problematic if you have multiple web apps that depend on different builds of the native DLLs.

10 May 2013

As multi-core processors are quickly becoming ubiquitous, it becomes increasingly important to use parallel and asynchronous programming techniques to create responsive, high-performance applications. The latest .NET releases have responded to this need by introducing the Task Parallel Library (TPL) in .NET 4, and the async/await keywords in C# 5.

We have created a set of fast-paced, code-driven videos on asynchronous programming in C# using TPL and async/await, with a focus on the Task-based Asynchronous Pattern (TAP). If you want a concise introduction to Tasks and async/await, these videos are for you! The videos are under 5 minutes each, and are intended to give a quick overview of each subject. The accompanying blog posts have links for further study.

19 November 2012

As mentioned in my last post (Sharing Code Across Projects),
developers work on the head of the master branch “by convention”. This
is fine for day-to-day work, but we’d like something a little more rigorous
for our continuous integration builds.

For this, we use “build repositories”. A build repository contains a
submodule for each repository required to build the project. (In the App1
example, the App1 build repo would have App1, Framework and Utility
submodules.) The CI server simply gets the most recent commit on the master
branch of the build repo, recursively updates all the submodules, then builds
the code.

The problem now: how is the build repository updated? We solve this using a
tool we developed named Leeroy. (So
named because we use Jenkins as a CI server, and
Leeroy starts the Jenkins builds. We weren’t the first ones to think of
this.)

Leeroy uses the GitHub API on our
GitHub Enterprise instance to watch for
changes to the submodules in a build repo. When it detects one, it creates
a new commit (again, through the GitHub API) that updates that submodule in
the build repo. After committing, it requests the “force build” URL on the
Jenkins server to start a build. Jenkins’ standard git plugin updates the
code to the current commit in each submodule and builds it.

The benefit is that we now have a permanent record of the code included in
each build (by finding the commit in the build repo for that build, then
following the submodules). For significant public releases, we also tag the
build repo and each of the submodules (for convenience).

Posts in the “Building Code at Logos” series:

17 November 2012

We often have common code that we'd like to share across different projects.
(For example, our Utility library is useful in both the desktop software
and in an ASP.NET website.)

One way of sharing code is to place it in its own repository, and add it as
a submodule to all repos
that need it. But submodules are a bit of a pain to work with on a daily
basis (for example, git checkout doesn't automatically update submodules
when switching branches; you have to remember to do this every time, or
create an alias).

Submodules also make it difficult to “compose” libraries. For example, App1
and App2 might both use Utility, but they might also both use Framework,
a desktop application framework that's not general-purpose enough to live in
Utility, but is in its own repo. If Framework itself uses Utility as a
submodule, then the App1 and App2 repos might contain both /ext/Utility
and /ext/Framework/ext/Utility. This is a maintenance nightmare.

Our choice at Logos is to clone all necessary repositories as siblings of
each other. In the App1 example above, we might have C:\Code\App1,
C:\Code\Framework and C:\Code\Utility as independent repos. Dependencies
are expressed as relative paths that reference files outside the current
repo, e.g., ..\..\..\Utility\src\Utility.csproj. We've written a shell script
that clones all necessary repos (for a new developer) or updates all
subfolders of C:\Code (to get the latest code).

By convention, developers are working on the master branch on each repo
(or possibly a feature branch in one or more repos for a complex feature).
It’s theoretically possible for someone to push a breaking change to
Utility and forget to push the corresponding change to App1 (a problem
that submodules do prevent), but this happens very infrequently.

Posts in the “Building Code at Logos” series:

16 November 2012

Some of our repositories reference third-party code. In many cases,
this can be managed using NuGet, but sometimes
we need to make private modifications and build from source.

We accomplish this by creating a repository for the third-party code. In some cases, this repository is added as a submodule under ext in the repositories that need it; in other cases, the binaries created from the code are committed to another repository's lib folder. The decision depends on how complicated it is to build the code versus how useful it is for developers to have the source (and not just precompiled binaries).

In the third-party repository, the upstream branch contains the unmodified upstream code, while the master branch contains the Logos-specific modifications.

When cloning the repository locally, the origin remote refers to our repository containing the third-party code. If the original third-party code is available via git, then we add an upstream remote that references the original maintainer's code.

# switch to the "upstream" branch, which contains the latest external codegit checkout upstream** delete all files in the working copy, except the '.git' directory# get the latest version of the third-party codesvn export --force http://source.example.org/repos/example/tags/1.1 .# add all files in the working copy, then commit themgit add -Agit commit -m "Update to Example 1.1."# switch to our local "master" branch, which contains Logos changesgit checkout master# merge in the latest upstream codegit merge upstream** fix any conflicts, and commit if necessary# push the latest merged code to our repogit push origin master