Skip to content

Instantly share code, notes, and snippets.

View AnthonySteele's full-sized avatar
💭
😪

Anthony Steele AnthonySteele

💭
😪
View GitHub Profile

The git Pull Request is a powerful tool. But just because you have it, does not mean that you have to use it all the time.

I am thinking of a team that owns on a codebase and works on it regularly. Pull requests give outsiders a powerful thing that they did not have before: controlled access to apply changes that they need, with review by the owners. However it is not a good process to apply across the board to those same owners as a matter of course.

I always think of it as like a gate in an ancient walled city: A stranger can come in, if they pass inspection at the gate. Without the gate, they would be reduced to standing outside and shouting over the wall "We need this feature! And you need to update some urls!" and hope that it happens soon. So the gate allows them to come in and get business done, while res

@AnthonySteele
AnthonySteele / Aboutasynchandlers.md
Last active January 17, 2016 22:38
About async handlers

##Setup

Many people have the misconception that async and sync code are mutually exclusive. This is not the case. It's easier than it seems!

If you have a method on an interface for async use, then the implementation can have zero or more awaits, and the case with zero awaits covers synchronous implementations. The code below will make this clear.

We have the following example contract that models a processor of messages:

 public class Request
using System.Web.Mvc;
namespace FeatureTest
{
public class FeatureRazorViewEngine : RazorViewEngine
{
private const string ViewsPathTemplate = "~/Features/%1/Views/{0}.cshtml";
private const string LayoutPathTemplate = "~/Features/Layout/{0}.cshtml";
public FeatureRazorViewEngine()