If there is one language feature of .NET that I've become increasingly apprehensive of it is events. On the surface they seem incredibly useful, letting you observe behavior without the observed object having to know anything about the observer. But the way they are implemented has a number of problems that makes me avoid them whenever possible.
The biggest pitfall with events is that they are a common source of "memory leaks". Yes, a managed language can leak memory — it happens anytime you create an object that is still referenced by an active object and cannot be garbage collected. The nasty bit that usually goes unmentioned is that an event subscription represents an object holding a reference to the observed instance. Not only does this go unmentioned, but Microsoft spent years showing off code samples and doing drag and drop demos of subscribing to events without stressing that you need to also unsubscribe from them again.
Every "memory leak" I've ever dealt with in .NET traced back to some subscription that wasn't released. And tracking this down in a large project is nasty work –taking and comparing memory shapshots to see what objects are sticking around, who subscribes to them and whether they should really still be subscribed. All because the observer affects the ability of the observed to go out of scope, which seems like a violation of the Observer pattern.
A pattern I've implemented from scratch several times (the side-effect of implementing core features in proprietary code) is the Weak Event pattern, i.e. an event that uses a weak reference as the subscription, so that the observed class isn't pinned in memory by a subscriber.
.NET 4 Microsoft has even formalized this with the WeakEventManager to implement the Weak Event Pattern, although I prefer just overriding the add and remove on an event and using weak references under the hood. While this changes the expected behavior of events and is unexpected in public facing APIs, I consider it the way events should have been implemented in the first place, and use it as default in my non-public facing code.
A better way of implementing the Observer pattern is IObservable from the Reactive Framework (Rx). Getting a stream of events pushed at you is a lot more natural for observation and allows for following a number of different behaviors in one observer. It also provides a mechanism for terminating the subscription from the observed end, as well a way deal with exceptions occuring in event generation. For new APIs this is definitely my prefered method of pushing state changes at listeners.
A pattern I encounter frequently are one time events that simply signal a change in state, such as a connection being estatblished or closed. What I really want for these is a callback. I've added methods in the vein of AddConnectedCallback(Action callback), but always feel like their unintuitive constructs born out of my dislike of events, so generally I just end up creating events for these after all.
I could just use a lambda to subscribe to an event an capture the current scope much like the .WhenDone handler of Result, the lambda is anonymous making it impossible to unsubscribe:
xmpp.OnLogin += (sender,args) => {
xmpp.Send("Hello");
// but how do I unsubscribe now?
};
The mere fact that lambdas are being shown as convenient ways to subscribe to events without any mention about the reference leaks this introduces just further illustrates how broken both events and their guidance are. Using this closure, simplifies attaching behavior at invocation time and makes sure that unsubscribe is handled cleanly.
Doing a lot of asynchronous programming work with MindTouch DReAM's Result continuation handle (think TPL's Task, but available since .NET 2.0), I decided that being able to subscribe to an event with a result would be ideal. Inspired by Rx's Observable.FromEvent, I created EventClosure, which can be used like this:
EventClosure.Subscribe(h => xmpp.OnLogin += h, h => xmpp.OnLogin -= h)
.WhenDone(r => xmpp.Send("Hello"));
Unfortunately, like Observable.FromEvent, you have to set up the subscribe and unsubscribe using an Action provided handler, since there isn't a way to pass xmpp.OnLogin as an argument and do it programatically. But at least now the subscribe and unsubscribe are handled in one place and I can concentrate on the logic I want executed at event invocation.
I could have implemented this same pattern using Task, but until async/await ships, Result still has the advantage, aside from continuation via .WhenDone or Blocking via .Block or .Wait, Result also gives me the ability to use a coroutine:
public IEnumerator<IYield> ConnectAndWelcome(Result<Xmpp> result) {
var xmpp = CreateClient();
var loginContinuation = EventClosure.Subscribe(h => xmpp.OnLogin += h, h => xmpp.OnLogin -= h);
xmpp.Connect();
yield return loginContinuation;
xmpp.Send("hello");
result.Return(xmpp);
}
This creates the client, starts the connection and suspends itself until connected, so it can then send a welcome message and return the connected client to its invokee. All this happens asynchronously! The implementation of EventClosure looks like this (and could easily be adapted to use Task instead of Result):
public static class EventClosure {
public static Result Subscribe(
Action<EventHandler> subscribe,
Action<EventHandler> unsubscribe
) {
return Subscribe(subscribe, unsubscribe, new Result());
}
public static Result Subscribe(
Action<EventHandler> subscribe,
Action<EventHandler> unsubscribe,
Result result
) {
var closure = new Closure(unsubscribe, result);
subscribe(closure.Handler);
return result;
}
public static Result<TEventArgs> Subscribe<TEventArgs>(
Action<EventHandler<TEventArgs>> subscribe,
Action<EventHandler<TEventArgs>> unsubscribe
) where TEventArgs : EventArgs {
return Subscribe(subscribe, unsubscribe, new Result<TEventArgs>());
}
public static Result<TEventArgs> Subscribe<TEventArgs>(
Action<EventHandler<TEventArgs>> subscribe,
Action<EventHandler<TEventArgs>> unsubscribe,
Result<TEventArgs> result
) where TEventArgs : EventArgs {
var closure = new Closure<TEventArgs>(unsubscribe, result);
subscribe(closure.Handler);
return result;
}
private class Closure {
private readonly Action<EventHandler> _unsubscribe;
private readonly Result _result;
public Closure(Action<EventHandler> unsubscribe, Result result) {
_unsubscribe = unsubscribe;
_result = result;
}
public void Handler(object sender, EventArgs eventArgs) {
_unsubscribe(Handler);
_result.Return();
}
}
private class Closure<TEventArgs> where TEventArgs : EventArgs {
private readonly Action<EventHandler<TEventArgs>> _unsubscribe;
private readonly Result<TEventArgs> _result;
public Closure(Action<EventHandler<TEventArgs>> unsubscribe, Result<TEventArgs> result) {
_unsubscribe = unsubscribe;
_result = result;
}
public void Handler(object sender, TEventArgs eventArgs) {
_unsubscribe(Handler);
_result.Return(eventArgs);
}
}
}
While this pattern is limited to single fire events, since Result can only be triggered once, it is a common enough pattern of event usage and one of the cleanest ways to receive that notification asynchronously.
One dirty little secret about Visual Studio 2008 and even Visual Studio 2010 is that while MSBuild governs the solution build process, the .sln file is not an MSBuild file. The .*proj files are, but solution isn't. So trying to customize the build on the solution level seemed really annoying.
As I dug around trying to find the Solution level equivalent of the Build Events dialog from Visual Studio, Sayed Ibrahim pointed out that in Visual Studio 2010 there is now a hook to let you inject some before and after tasks, but unfortunately the problem I was trying to solve was the build process for MindTouch DReAM, which is still in Visual Studio 2008.
Digging around further, I found out that you could get the MSBuild file that the solution was turned into. By setting the environment variable MSBuildEmitSolution=1 and running MSBuild will write out the generated .proj file.
While this enables you to edit it and add new tasks, it means that your build script will drift out of sync with the solution as it is modified. I initially went down this path, since the build i wanted was very specialized to the distribution build. That let me eliminate 90% of the .proj file and I felt confident that the smaller the .proj, the simpler it would be to keep it in sync with the solution.
But wait, all the solution .proj did was call MSBuild on each of its projects. So if one MSBuild script can call another, why do i even need to use a generated version of the solution? Turns out you don't. You can write a very simple MSbuild script, that in turn calls the .sln, letting MSBuild perform the conversion magic, and you still get your pre and post conditions.
<Project DefaultTargets="Build" ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<CallTarget Targets="PreBuild"/>
<CallTarget Targets="Dream"/>
<CallTarget Targets="PostBuild"/>
</Target>
<Target Name="PreBuild">
<Message Text="Pre Build" />
...
</Target>
<Target Name="PostBuild">
<Message Text="Post Build" />
...
</Target>
<Target Name="Dream" Outputs="@(DreamBuildOutput)">
<Message Text="Building DReAM" />
<MSBuild Targets="Rebuild"
Projects="src\MindTouchDream.sln"
Properties="Configuration=Signed Release; Platform=Any CPU; BuildingSolutionFile=true;">
<Output TaskParameter="TargetOutputs" ItemName="DreamBuildOutput" />
</MSBuild>
<Message Text="Done building DReAM" />
</Target>
</Project>
Now that I've implemented this, I am surprised that when I looked for a solution, this didn't come up in google and I hope that this post helps the next person that runs into this issue. The only drawback (which it shares with the first approach) is that this script is only for manual execution. Building from within Visual Studio can't take advantage of it.
I've been trying to figure out a workflow in git for resetting my clone of an upstream branch to the current upstream state, but without discarding my history. The reason for not dropping the history is that a) it's antithetical to me to ever discard anything from revision control, and b) i push my local changes to a public repo, which means others might have cloned it and are following my changes, so a git reset or git rebase is a bad thing.
Sure, merge usually does just fine, but in the case of me working on something that is not accepted upstream or was made irrelevant by an upstream change the merge would not get rid of my dead end changes.
One option is to leave my clones of upstream branches alone and always create working branches that i discard once the task is completed and each new working branch is a new branch off the upstream master.
After digging around a while, I found almost what i wanted:
git merge --strategy=ours <branch>
which brings in history from <branch> but adds one more commit recording the changes required to keep the current branch at its pre-merge state. Except i want to do the opposite
git merge --strategy=theirs <upstream/branch> // does not exist!
which would bring in the history from <upstream/branch> and record a commit with the changes required to make the current branch a replica of <upststream/branch>. While there is something that looks like it would do that, i.e.
git merge --strategy=recursive -X theirs <upstream/branch>
but that will not discard local changes that do not conflict with upstream changes.
Assuming i must just be overlooking a command or switch, I asked on stackoverflow and with the help of users kelloti and jefromi (update: VonC updated his answer to more precisely reflect this workflow) was able to put together a workflow that fakes --strategy=theirs:
get a temp copy of the upstream branch
git co -b temp <upstream/branch>
merge our version of the branch into the upstream with ours strategy
git merge --strategy=ours <branch>
commit if necessary (i.e. auto-commit or fast forward didn't happen)
git commit ...
checkout our version of the branch
git co <branch>
merge temp (which will be a fast forward)
git merge temp
push the changes to our origin repo
git push
get rid of the temp branch
git branch -D temp
It's a bit convoluted but does leave us with our history and a re-freshed local copy of the upstream master.
I'm setting up the worflow for MindTouch DReAM right now. Up until now, we'd been collobrating via SVN without development branches. I had kept my own private git repo, because I am rather particular about committing frequently and wanting those commits backed up remotely.
As long as my repo had nothing to do with the public version, this was all fine, but since now I'd want the ability to collorate on WIP with other team members and outside contributors, I want to make sure that my public branches are reliable for others to branch off and pull from, i.e. no more rebase and reset on things I've pushed to the remote backup, since it's now on github and public.
So that leaves me with how i should proceed. 99% of the time my copy will go into the upstream master, so i want to work my master and push into upstream most of the time. But every once in a while what i have in wip will get invalidated by what goes into upstream and i will abandon some part of my wip. At that point I want to bring my master back in sync with upstream, but not destroy any commit points on my publicly pushed master. I.e. i want a merge with upstream that ends up with the changeset that make my copy identical to upstream. And that's what git merge --strategy=theirs should do.
For notify.me I hand-rolled a simple actor system to handle all Xmpp traffic. Every user in the system has its own actor that maintains their xmpp state, tracking online status, resources, resource capability, notification queues and command capabilities. When a message comes in either via our internal notification queues or from the user, a simple dispatcher sends the message on to the actor which handles the message and responds via a message that the dispatcher either hands off to the Xmpp bot for formatting and delivery to the client or sends it to our internal queues for propagation to other parts of the notify.me system.
This has worked flawlessly for over 2 years now, but its ad-hoc nature means it's a fairly high touch system in terms of extensibility. This has led me down building a more general actor system. Originally Xmpp was our backbone transport among actors in the notify.me system, but at this point, I would like to use Xmpp only as an edge transport, and otherwise use in-process mailboxes and serialize via protobuf for remote actors. I still love the Xmpp model for distributing work, since nodes can just come up anywhere, sign into a chatroom and report for work. You get broadcast, online monitoring, point-to-point messaging, etc. all for free. But it means all messages go across the xmpp backbone, which has a bit of overhead and with thousands of actors, i'd rather stay in process when possible. No point going out to the xmpp server and back just to talk to the actor next to you. I will likely still use Xmpp for Actor Host nodes to discover each other, but the actual inter-node communication will be direct Http-RPC (no, it's not RESTful, if it's just messaging).
One design approach I'm currently playing with is using actors that expose their contract via an interface. Keeping the share-nothing philosophy of traditional actors, you still won't have a reference to an actor, but since you know its type, you know exactly what capabilities it has. That means rather than having a single receive point on the actor and making it responsible for routing the message internally based on message type (a capability that lends itself better to composition), messages can arrive directly at their endpoints by signature. Another benefit is that testing the actor behavior is separate from its routing rules.
public interface IXmppAgent {
void Notify(string subject, string body);
OnlineStatus QueryStatus();
}
Given this contract we could just proxy the calls. So our mailbox could have a proxy factory like this:
public interface IMailbox {
TRecipient For<TRecipient>(string id);
}
allowing us to send messages like this:
var proxy = _mailbox.For<IXmppAgent>("foo@bar.com");
proxy.Notify("hey", "how'd you like that?");
var status = proxy.QueryStatus();
While this is simple and decoupled, it is implictly synchronous. Sure .Notify could be considered a fire-and-forget message, .QueryStatus definitely blocks. And if we wanted to communicate an error condition like not finding the recipient, we'd have to do it as an exception, moving errors into the synchronous pipeline as well. In order to retain the flexibility of a pure message architecture, we need a result handle that let's us handle results and/or errors via continuation.
My first pass at an API for this resulted in this calling convention:
public interface IMailbox {
void Send<TRecipient>(string id, Expression<Action<TRecipient>> message);
Result SendAndReceive<TRecipient>(string id, Expression<Action<TRecipient>> message);
Result<TResponse> SendAndReceive<TRecipient, TResponse>(
string id,
Expression<Func<TRecipient, TResponse>> message
);
}
transforming the messaging code to this:
_mailbox.Send<IXmppAgent>("foo@bar.com",a => a.Notify("hey", "how'd you like that?"));
var result = _mailbox.SendAndReceive<IXmppAgent, OnlineStatus>(
"foo@bar.com",
a => a.QueryStatus()
);
I'm using MindTouch Dream's Result<T> class here, instead of Task<T>, primarily because it's battle tested and I have not properly tested Task under mono yet, which is where this code has to run. In this API, .Send is meant for fire-and-forget style messaging while .SendAndReceive provides a result handle — and if Void were an actual Type, we could have dispensed with the overload. The result handle has the benefit of letting us choose how we want to deal with the asynchronous response. We could simply block:
var status = _mailbox.SendAndReceive<IXmppAgent, OnlineStatus>(
"foo@bar.com",
a => a.QueryStatus())
.Wait();
Console.WriteLine("foo@bar.com status:", status);
or we could attach a continuation to handle it out of band of the current execution flow:
_mailbox.SendAndReceive<IXmppAgent, OnlineStatus>(
"foo@bar.com",
a => a.QueryStatus()
)
.WhenDone(r => {
var status = r.Value;
Console.WriteLine("foo@bar.com status:", status);
});
or we could simply suspend our current execution flow, by invoking it from a coroutine:
var status = OnlineStatus.Offline;
yield return _mailbox.SendAndReceive<IXmppAgent, OnlineStatus>(
"foo@bar.com",
a => a.QueryStatus()
)
.Set(x => status = x);
Console.WriteLine("foo@bar.com status:", status);
Regardless of completion strategy, we have decoupled the handling of the result and error conditions from the message recipient's behavior, which is the true goal of the message passing decoupling of the actor system.
Looking at the signatures there are two things we can still improve:
We can address both of these, by providing a factory method for a typed mailbox:
public interface IMailbox {
IMailbox<TRecipient> To<TRecipient>(string id);
}
public interface IMailbox<TRecipient> {
void Send(Expression<Action<TRecipient>> message);
Result SendAndReceive<TResponse>(Expression<Action<TRecipient>> message);
Result<TResponse> SendAndReceive<TResponse>(
Expression<Func<TRecipient, TResponse>> message
);
}
which let's us change our messaging to:
var actorMailbox = _mailbox.To<IXmppAgent>("foo@bar.com");
actorMailbox.Send(a => a.Notify("hey", "how'd you like that?"));
var result2 = actorMailbox.SendAndReceive(a => a.QueryStatus());
// or inline
_mailbox.To<IXmppAgent>("foo@bar.com")
.Send(a => a.Notify("hey", "how'd you like that?"));
var result3 = _mailbox.To<IXmppAgent>("foo@bar.com")
.SendAndReceive(a => a.QueryStatus());
I've included the inline version because it is still more compact than the explicit version, since it can infer the result type.
The reason the mailbox uses Expression instead of raw Action and Func is that at any point an actor we're sending a message to could be remote. The moment we cross process boundaries, we need to serialize the message. That means we need to be able to programatically inspect the inspection, and build a serializable AST as well as serialize the captured data members used in the expression.
Since we're talking serializing, inspecting the expression also allows us to verify that all members are immutable. For value types, this is easy enough, but DTOs would need be prevented from changing so that local vs. remote invocation won't end up with different result just because the sender changed it's copy. We could handle this via serialization at message send time, although this looks like a perfect place to see how well the Freezable pattern works.
I'm taking a break from Promise for a post or two to jot down some stuff that I've been thinking about while discussing future enhancements to MindTouch Dream with @bjorg. In Dream all service to service communication is done via HTTP (although the traffic may never hit the wire). This is very powerful and flexible, but also has performance drawbacks, which have led to many data sharing discussions.
Whether you are using data as a message payload or even just putting data in a cache, you want sender and receiver to be unable to see each others interaction with that data, which would happen if the data was a shared, mutable instance. If you were to allow shared modification on purpose or on accident can have very problematic consequences:
There are a number of different approaches for dealing with this, each a trade-off in performance and/or usability. I'll use caching as the use case, since it's a bit more universal than message passing, but the same patterns applies.
A naive implementation of a cache might just be a dictionary. Sure, you've wrapped the dictionary access with a mutex, so that you don't get corruption accessing the data. But multiple threads would still have access to the same instance. If you aren't aware of this sharing, expect to spend lots of time trying to debug this behavior. If you are unlucky it's not causing crashes but causes strange data corruption that you won't even know about until your data is in shambles. If you are lucky the program crashes because of an access violation of some sort.
Easy, we'll just clone the data going into the cache. Hrm, but now two threads getting the value are still messing with each other. Ok, fine, we'll clone it coming out of the cache. Ah, but if the orignal thread is still manipulating its copy data while others are getting the data, the cache keeps changing. That kind of invalidates the purpose of caching data.
So, with cloning we have to copy the data going in and coming back out. That's quite a bit of copying and in the case that the data goes into the cache and expires before someone uses it, it's a wasted copy to boot.
If you've paid any attention to concurrency discussions you've heard the refrain from the functional camp that data should be immutable. Every modfication of the data should be a new copy with the orginal unchanged. This is certainly ideal for sharing data without sharing state. It's also a degenerative version of the cloning approach above, in that we are constantly cloning, whether we need to or not.
Unless your language supports immutable objects at a fundamental level, you are likely to be building this by hand. There's certainly ways of mitigating its cost, using lazy cloning, journaling, etc. i.e. figuring out when to copy what in order to stay immutable. But likely you are going to be building a lot of plumbing.
But if the facilities exist and if the performance characteristics are acceptable, Immutability is the safest solution.
So far I've ignored the distributed case, i.e. sending a message across process boundaries or sharing a cache between processes. Both Cloning and Immutability rely on manipulating process memory. The moment the data needs to cross process boundaries, you need to convert it into a format that can be re-assembled into the same graph, i.e. you need to serialize and deserialize the data.
Serialization is another form of Immutability, since you've captured the data state and can re-assemble it into the original state with no ties to the original instance. So Serialization/Deserialization is a form of Cloning and can be used as an engine for immutability as well. And it goes across the wire? Sign me up, it's all i need!
Just like Immutability, if the performance characteristics are acceptable, it's a great solution. And of course, all serializers are not equal. .NET's default serializer, i believe, exists as a schoolbook example of how not to do it. It's by far the slowest, biggest and least flexible ones. On other end of scale, google's protobuf is the fastest and most compact I've worked with, but there are some flexibility concessions to be made. BSON is a decent compromise when more flexibility is needed. A simple, fast and small enough serializer for .NET that i like is @karlseguin's Metsys.Little. Regardless of serializer, even the best serializer is still a lot slower than copying in-process memory, never mind not even having to copy that memory.
It would be nice to avoid the implicit copies and only copy or serialize/deserialize when we need to. What we need is for a way for the originator to be able to declare that no more changes will be made to the data and for the receivers of the data to declare whether they intend to modify the retrieved data, providing the folowing usage scenarios:
In Ruby, freeze is a core language concept (although I profess my ignorance of not knowing how to get a mutable instance back again or whether this works on object graphs as well.) To let the originator and receiver declare their intended use of data in .NET, we could require data payloads to implement an interface, such as this:
public interface IFreezable<T> {
bool IsFrozen { get; }
void Freeze(); // freeze instance (no-op on frozen instance)
T FreezeDry(); // return a frozen clone or if frozen, the current instance
T Thaw(); // return an unfrozen clone (regardless whether instance is frozen)
}
On submitting the data, the container (cache or message pipeline) will always call FreezeDry() and store the returned instance. If the originator does not intend to modify the instance submitted further, it can Freeze() it first, turning the FreezeDry() that the container does into a no-op.
On receipt of the data, the instance is always frozen, which is fine for any reference use. But should the receiver need to change it for local state tracking, or submitting the changed version, it can always call Thaw() to get a mutable instance.
While IFreezable certainly offers some benefits, it'd be a pain to add to every data payload we want to send. This kind of plumbing is a perfect scenario for AOP, since its a concern of the data consumer not of the data. In my next post, I'll talk about some approaches to avoid the plumbing. In the meantime, the WIP code for that post can be found on github.
Posted a new episode of the Concurrent Podcast over on the MindTouch developer blog. This time Steve and I delve into Coroutines, a programming pattern we use extensively in MindTouch 2009 and one that i’m also trying out as an alternative to my actor based Xmpp code in Notify.me.
Since there isn’t a native coroutine framework in C#, we’re using the one provided by MindTouch Dream. It’s built on top of the .NET iterator pattern (i.e. IEnumerable and yield) and makes the assumption that all Coroutines are asynchronous methods using Dream’s Result<T> object for coordinating the producer and consumer of a return values. Steve’s previously blogged about Result. Since those posts there’s also been a lot of performance improvements and capability improvements to Result committed to trunk, primarily providing robust cancellation with resource cleanup callbacks. For background on coroutines, you can also check out previous posts I’vee written.
The cool thing about asynchronous coroutines compared to an actor model is that call/response based actions can be written as a single linear block of code, rather than separate message handlers whose contiguous flow can only be determined by examining the message dispatcher. With a message dispatcher that can correlate message responses with suspended coroutines, sending and waiting for a message in a coroutine can be made to look like a method call without blocking the thread, which, especially with message passing concurrency, is vital, since a response isnn’t in any way guaranteed to happen.
I’m due to write another post on how to use Dream’s coroutine framework, but in the meantime i highly recommend checking out Dream from mindtouch’s svn. Lot’s of cool concurrency stuff in there. trunkis under heavy development, as we work towards Dream profile 2.0, but 1.7.0 is stable and production proven.
As usual, I’ve been blogging over on the MindTouch Developer blog, and since the topics i post about over there have a pretty strong overlap with what I’d post here, I figured i might as well start cross-posting about it here.
Aside from various technical posts, Steve Bjork and I have started recording a Podcast about concurrent programming. It’s currently 2 episodes strong, with a third one coming soon. Information on past and future posts can always be found here.
Today’s post on the MindTouch dev blog is about the producer/consumer pattern and how i moved from using dedicated workers with a blocking queue to using Dream’s new ElasticThreaPool to dispatch work.
Ok, so i’m not proud of it, but i’ve been a hold-out on mocking frameworks for a while. With the auto-gen of interfaces that resharper gives me, i’d just gotten pretty fast at rolling my own mocks. Once or twice a year, i’d dip my toe into a mocking framework, find its syntax frustrating and rather than get a good used to it, I’d soon find myself replacing NotImplementedException in a stub for yet another custom Mock object.
My reasoning was that if i can roll my mocks just as fast as wiring up a mock, then why bother with the dependency. And I thought I wasn’t really causing myself too much extra work.
In the meantime, I even wrote a simple Arrange/Act/Assert mocking harness for Dream, so i could better test REST services. So, it’s not like i didn’t believe in the benefits of mocking harnesses.
Well, for the last couple of weeks, I’ve been using Moq and it’s pretty much killed off all my desire to roll my own. I’m generally a huge fan of lambdas and have gotten used thinking in expressions. Although even with that, I wasn’t able to get comfortable with the latest Rhino.Mocks. Probably just me. But from the very first attempt, Moq worked like i think and I was up and running.
var mock = new Mock();
mock.Setup(x=> x.Bar).Returns("bar").AtMostOnce();
var foo = mock.Object;
Assert.AreEqual("bar",foo.Bar);
I’m a convert!
Once again, there’s been extended silence over here. I have several article drafts that keep getting the short end of my time in favor of coding. In the meantime, I have blogged a couple of article’s over on the MindTouch Dev blog.
In general, I’ve just been spending a lot of time working on RESTful services, both for MindTouch and designing the new Notify.me REST API.
Just finished an article over on the MindTouch blog about tweaking Dream’s default access patterns. I really like how Dream uses cookies, something you don’t often see in REST services. Generally it’s all about X-My-Cool-Auth-Header business, which is yet another manual burden for developers. Not sure if this originated because people did raw http requests and either didn’t know that most http request mechanisms have cookie support (even curl has a cookie jar), or whether it was a dislike of cookies.
The article also briefly touches on Prologues and Epilogues, a topic I need go into with more detail some time in the future. Basically every Feature call can have n pre and post actions that can do anything from checking authentication to mutating the request (think accepting data in json or Xml and having a prologue and epilogue do transformations on the way in and out so that the feature itself doesn’t have to worry about the data format but can assume that it always gets Xml. The system kind of reminds me of apache handler chaining from mod_perl.