It looks like there is some confusion about the way Rhino Mocks 3.3 Expect.Call support for void method works.

Let us examine this support for an instance, shall we? Here is all the code for this feature:

public delegate void Action();

public static IMethodOptions<Action> Call(Action actionToExecute)
{
	if (actionToExecute == null)
		throw new ArgumentNullException("actionToExecute", "The action to execute cannot be null");
	actionToExecute();
	return LastCall.GetOptions<Action>();
}

As you can see, this is simply a method that accept a no args delegate, execute it, and then return the LastCall options. It is syntactic sugar over the usual "call void method and then call LastCall). The important concept here is to realize that we are using the C# * anonymous delegates to get things done.

Let us see how it works?

[Test]
public void InitCustomerRepository_ShouldChangeToCustomerDatabase()
{
	IDbConnection mockConnection = mocks.CreateMock<IDbConnection>();
	Expect.Call(delegate { mockConnection.ChangeDatabase("myCustomer"); });
	
	mocks.ReplayAll();

	RepositoryFactory repositoryFactory = new RepositoryFactory(mockConnection);
	repositoryFactory.InitCustomerRepository("myCustomer");
	
	mocks.VerifyAll();
}

This is how we handle void methods that have parameters, but as it turn out, we can do better for void methods with no parameters:

[Test]
public void StartUnitOfWork_ShouldOpenConnectionAndTransaction()
{
	IDbConnection mockConnection = mocks.CreateMock<IDbConnection>();
	Expect.Call(mockConnection.Open); // void method call
	Expect.Call(mockConnection.BeginTransaction()); // normal Expect call
	
	mocks.ReplayAll();

	RepositoryFactory repositoryFactory = new RepositoryFactory(mockConnection);
	repositoryFactory.StartUnitOfWork("myCustomer");
	
	mocks.VerifyAll();
}

Notice the second line, we are not calling the mockConnection.Open() method, we are using C#'s ability to infer delegates, which means that the code actually looks like:

Expect.Call(new Action(mockConnection.Open));

Which will of course be automatically executed by the Call(Action) method.

I hope that this will make it easier to understand how to use this new feature.

Happy Mocking,

   ~ayende

* Sorry VB guys, this is not a VB feature, but I am not going to rewrite VBC to support this :-) You will be able to take advantage of this in VB9, though, so rejoice.

And on the heels of the Blame Microsoft post, here is a perfect example. Silverlight doesn't support Right to Left languages. This means that if I want to display Hebrew or Arabic content, it is flat out.

This is usually the place where you sharpen a steak knife and go to meeting with a lot of red faced people and you need to wear ear muffs.

Until an angel appears...

Justin Angel went ahead and built RTL support to Silverlight. Check the links for details, but there a CodePlex project, a webcast and an online demo.

Rendering Comparison
Normal Silverlight RTL (Right-to-Left): Not Supported Align-to-right: Not Supported	Silverlight Hebrew & Arabic support RTL: Supported Align-to-right: Supported

And just to be clear, I don't agree with this sentiment, but it is a very real one.

Times have changed
Our applications are getting worse
They run so slow and won't behave
The code is ugly and perverse!
I tell you, that application is deprave!

Should we blame the PM?
Or blame the developers?
Or should we blame the process?
No! blame Microsoft
Everyone: Blame Microsoft

Blamability is an important concept, the facts doesn't really matter, but the ability to blame someone else, preferably something as ambiguous as Microsoft, is a good way to have an out.

Which bring a lot of interesting ideas to mind...

You can read about it here and here

After reading about Erlang, I got very excited about doing hot code swapping, and always on applications. I decided that this is something that would be cool to do on the CLR. So I did, it was very easy.

The screen cast is a short one, less than 25 minutes, but it covers all the concepts, and we have dynamically updated code in the end. :-)

As usual, the sound quality is suspicious, and I am probably speaking to fast.

• Total length: 00:24:12
• Download Size: 34.2 Mb
• Code starts at 2:05

Memorable code:

I think it is telling that I am using the Command pattern to print hello world.

You can get the code here

We are discussing the ideal IDE on the Alt.Net mailing list, I thought that it would be interesting to gather all the requirements in one place.

I made some minimal attempt to reduce duplication, and to put the interesting parts, but check the discussion, it is still going on. This is not a list of "what is wrong with VS", it is a list of things that we want to see in an IDE (or not see in an IDE :-) ). IDE is defined as the place where I write code / debug /test.

Good quotes:

• I want to be a train speeding full steam and have this IDE laying track just in front of me until such time as I tell it I want to go a different direction.
• I just want a lightening fast intelligent editor that will let me choose to add on the features I care about. I don't want to have to deal with lag time.
• Give me something like TextMate for .NET. Build it on managed code. Make the AST model/API sensible and self-evident. Provide a user-centricity driven plugin model - no abstracterbation for programmers with technology fetishes. Plain, simple, self-evident. Extensibility and usability for the merest of mere mortals.
• So, do you really need Snippet Compiler with ReSharper editing features and debugger?

And now to the real stuff that was mentioned:

• Coding:
• Syntax highlighting
• Intellisense (I may think I am a jedi but true zen is to talk to the machine and have it put forth the words before you)
• Code Browsing
• Refactoring
• Treat Warnings as Errors as not negotiable (always enabled).
• i want it to be geared towards the keyboard developer.
• Text manipulation:
• Regex manipulation of the text.
• Debugger, good one.
• Edit and continue
• Testing integration
• Setting up all the required stuff, what is compiled, embedded, etc.
• Preferably it should read my build script and work on top of that.
• i want the build system to be pluggable
• i want a light project structure. If anything is going to be stored in a file it needs to be in a readable form and would preferable have a lightweight API that ships with it.
• Source control integration - nice, but not really a must have, I use tortoise for that.
• Some opinions said that SCM should not be in the IDE.
• Extensible
• Should be able to add a new language easily.
• Should offer me the AST of the code when I build a plugin.
• Make it have a light version, where you can unplug stuff you find unnecessary. ??
• So as far as an IDE is concerned I want to do everything from inside it like deployments
• Smarts:
• Error highlighting (errors, warnings, test failures, bad practices, ...)
• A Code Smell detection system (users could extend it with CQL)
• i want it to give me visual cues to interesting code constructs
• All existing R# features
• IDE support for effect analysis (Chapter 11 of Working Effectively with Lagacy Code).
• automatically correct these issues: flase > false, reslut = result, retrun = return
• User interface:
• Full screen ability
• Background compilation as you type (I hate waiting for VS to compile my solutions all the time).
• Code searching:
• A very fast way to get from the current function you are in to any caller or to any function the function is calling (and class definitions, ...)
• Ability to instantly search for a specific artifact (kind of like google / windows live search). As I type it in, I see the filtered results. This is NOT the find feature.
• Misc:
• The ability to have 2 people working in separate window panes on the same file (one person typing on the local keyboard/mouse, the other in a remote desktop); both visible in the same environment.
• IDE installation < 100Mb
• Shell integration would be nice. and available from the keyboard (think launchy)
• For windows PowerShell integration would be nice too.
• How about an IDE that doesn’t lock up when the source control is unavailable ;)
• better multiple monitor support.
• Configuration screens that don’t give me a headache
• Responsive:
• I am willing to pay for a quad core computer with 16 GB RAM, and use that for only programming. But it _must_ be responsive. (I used VS.Net on such a system, it crawled!)
• FAST FAST FAST
• Designers:
• i don't want any of the overhead of a designer.
• Designers that don’t break or no designers at all
• Built in (no separate window) reflector
• I should be able to CTRL+B from the method to the code or to the disassembled code.
• Release cycle:
• I want an IDE which is released early and often. And I want an IDE built by a team which is responsive to community feedback. The rest is just details.
• Multiple Releases a year, constant improvement.

Udi has an interesting presentation that I recommend that you go through. He is going to present it at Tech Ed (Thu Nov 8 13:30 - 14:45 Room 117).

Most of the ideas are familiar to me because I have spoken to him about them before, but it represent new concepts to most people. I would preface his suggestion with the usual warning about designing for performance. Udi's points are about big systems, so consider if they are appropriate to your scenario first.

A pal of mine once told me that he designs systems for an order of magnitude increase in the requirements. So a system that works for a hundred users should also scale to a thousand users (additional hardware, maybe, but the architecture should hold), but going beyond that will require more than just throwing hardware at the issue.

This sounds like a good rule of the thumb.

My command history for the last hour:

Adam has an interesting discussion here about handling common actions in MonoRail. This has sparked some discussion in the MonoRail mailing list. I wanted to take the chance to discuss the idea in more detail here.

Basically, he is talking about doing this:

public class IndexAction : SmartDispatcherAction
{
   private ISearchableRepository repos;
   private string indexView;

   public IndexAction(
      ISearchableRepository repos,
      string indexView)
   {
      this.repos = repos;
      this.indexView = indexView;
   }

   public void Execute(string name)
   {
      ISearchable item = repos.FindByName(name);
      if(item == null)
      {
         PropertyBag["UnknownSearchTerm"] = name;
         RenderView("common/unknown_quick_search");
      }

      PropertyBag["Item"] = item;
      RenderView(indexView);
   }
}

And then registering it with the routing engine like this:

new Route("/products/<name>",
    new IndexAction(new ProductRepository(), "display_product"));
new Route("/categories/<name>",
    new IndexAction(new CategoryRepository(), "display_category"));

Now, accessing "/categories/cars" will give you all the items in the cars category.

On the face of it, it seems like a degenerated controller, no? Why do we need it? We can certainly map more than a single URL to a controller, so can't we solve that problem that way?

Let us stop for a moment and think about the MVC model. Where did it come from? From Smalltalk, when GUI was something brand new & sparkling. It is a design pattern for a connected system. In that case, the concept of a controller made a lot of sense.

But when we are talking about the web? The web is a disconnected world. What is the sense in having a controller there? An Action, or a Command, pattern seems much more logical here, no?

But then we have things that just doesn't fit this model. Consider the example of CRUD on orders. We can have a controller, which will handle all of the logic for this use case in a single location, or we can have four separate classes, each taking care of a single aspect of the use case.

Personally, I would rather have the controller to do the work in this scenario, because this way I have all the information in a single place, and I don't need to hunt multiply classes in order to find it.

But, there are a lot of cases where we do want to have just this single action to happen, or maybe we want to add some common operations to the controller, without having to get in to crazy inheritance schemes.

For this, MonoRail supports the idea of Dynamic Actions, which supports seamless attachment of actions to a controller.

Hammett describe them best:

DynamicActions offers a way to have an action that is not a method in the controller. This way you can “reuse an action” in several controllers, even among projects, without the need to create a complex controller class hierarchy.

The really interesting part in this is that we have both IDynamicAction and IDynamicActionProvider. This means that we get mixin-like capabilities.

Dynamic Actions didn't get all the love they probably deserve, we don't have the SmartDispatcherAction (yet), so if we want to use them, we will need to handle with the raw request data, rather than with the usual niceties that MonoRail provides.

Nevertheless, on a solid base it is easy enough to add.

Now all we need to solve is the ability to route the requests to the correct action, right? This is notepad code, so it is ugly and not something that I would really use, but it does the job:

public class ActionRoutingController : Controller
{
	public delegate IDynamicAction CreateDynamicAction();
	
	public static IDictionary<string, CreateDynamicAction> Routing 
		= new Dictionary<string, CreateDynamicAction>();
	
	protected override void InternalSend(string action, IDictionary actionArgs)
	{
		if(Routing.ContainsKey(action) == )
			throw new NoActionFoundException(action);
			
		Routing[action]().Execute(this);
	}
}

What this means is that you can now do this:

public void AddRoutedActions()
{
	AddRoutedAction("categories", "/categories/<name:string>", delegate {
		return  new IndexAction(new CategoryRepository(), "display_category");
	});
	
	AddRoutedAction("products", "/products/<name:string>", delegate {
		return new IndexAction(new ProductRepository(), "display_product");
	});
}

public void AddRoutedAction(string action, string url, CreateDynamicAction actionFactory)
{
	RoutingModuleEx.Engine.Add(
		PatternRule.Build(action, url, typeof(ActionRoutingController), action));
    
    ActionRoutingController.Routing.Add(action, actionFactory);
	
}

And get basically the same result.

Again, all of this is notepad code, just doodling away, but it is nice to see that all the building blocks are there.

Yes, this is invalid code, but still...

And then...