Code Me To Heaven

Workflows or collaborative editing?

2011-12-14T08:56:00.001+01:00

Workflows are often requested in enterprise software. They cover areas such as publishing articles in a CMS, sales- and purchase order approval, online registration, shipment, subscription and cancellation. Among many other things. You probably go through several workflows in the course of a work day.

Why do we have workflows? For many different reasons:

Ensure that things are done in the right order. No shipment before payment. No shipment before all items are in stock. No unwrapping of presents before the tree has been lit.
Ensure the right people do their part of the job. For instance, making sure an article is reviewed by PR before being published. Or that each elf makes his part of the wooden truck.
Ensure the right people are informed. For instance a mail is sent to the Finance dept. when a payment is overdue. And Santa is notified when little Molly misbehaves.
Make sure that people don’t overwrite each others changes. For instance the check-in/out mechanism in most content management systems. And making sure that you and your wife don’t both buy a gift for aunt Christie.
Document that standards and procedures are followed to comply with rules and regulations.

Sometimes, workflows are put into place by default, by habit, or by convention. To publish even the simplest change to an article in a Microsoft SharePoint publishing site, for example, you need to perform the following manual actions:

Check out the article
Edit the article
Save the article
Check it in
Click Publish
Fill out the form
Click OK.

That’s ridiculous! And that’s just the standard workflow before a workflow-aholic business architect has added extra steps and flows. What we should be doing instead is simplifying the life of software users.

Let’s think a bit about two categories of workflows: First, those that model the business processes closely, and secondly, those that are applied because of habit, by default or because of fear of being accused of not being in control of our processes. The first category deserves our attention and Christmas Love. Workflows in the second category should be replaced by something more efficient.

Speaking of which, what if, instead of a workflow involving check in/out, your CMS worked like Google Docs, allowing any number of people to work simultaneously on the same document while seeing each others changes updated live on screen? What if you could have the same feature in your backend systems, allowing you to see the other users’ cursors as they type?

If someone makes a mistake (and some one will!), there’s a complete history available. Do you remember the disbanded Google Wave? There was a slider that allowed you to drag a slider left and right and magically watch the letters disappear and reappear in the order they were added by all users. One place you can see this in action is on collabedit.com. Try typing in some text then go to the history tab and drag the slider. Pure magic!

The technology that did the magic in Wave was acquired from Etherpad.com back in the day. Wave didn’t fail because of the real-time collaboration technology but for a lot of different reasons, one being lack of integration with email. After Wave was abandoned, Google open sourced the components that allow for real time collaboration. They are free for anyone to implement in a CMS, or in any web app.

I think it’s time to abandon the old check-in/out workflow. With components like signalR, a simple Wave-like HTML editor can be done in 30 lines of C# code and 60 lines of JavaScript. In other words, it’s ready to be put into production to replace your CMS publishing workflow today. Sumit Maitra posted a demo of these concepts.

One additional benefit is that the collaborative editing paradigm, when implemented right, caters for at much nicer User Experience. Having to ask your colleague to unlock a file or document (while she’s on vacation) is time consuming and frustrating. Fluently typing while she is working on the same document, article, product, campaign or whatever, is good User Experience to me.

To conclude, workflows that model business processes are the important ones. They need our love and attention. Workflows that exist because of an old technical limitation, or because it has become a habit, need to be reconsidered. Workflows that make you comply with laws can perhaps be re-thought and simplified. Which of your workflows fall into which category will have to be assessed case by case. But chances are, if any of your systems rely on the check-in/out mechanism, there’s an easy win right there.

Merry workflow-ho-ho!

PicoFX–a dogma for simple frameworks

2011-07-12T14:44:00.000+02:00

It’s really easy to be persuaded by a large framework that does everything. Who would want to tie your shoelaces together by choosing a framework, say an ORM, that does not have support for … say enums? (Sorry, EF I couldn’t resist picking on you.) Who can say no to log4net. After all, it’s comprehensive. It can log messages to files, rolling files, databases, event logs, toilet paper and the Times Square Billboard at rush hour?

NHibernate can do ANYTHING you’d want from an ORM. Now that the current EF CTP supports enums, it’s getting there too. But all the extra functionality comes at a price that you’ll have to pay eventually: Added complexity. Listening to “The Rise of the Micro-ORM with Sam Saffron and Rob Conery” on Hanselminutes, I was inspired by their thougths about going back to basics. Both their ORMs support only basic ORM stuff, but the complexity is way down –- and performance is so much better! Rob made me realize that SQL might just be the ideal DSL for writing queries. I had some of the same ideas when back in 2006, I wrote a simple closed-source ORM called Matterhorn. It was a response to the unnecessary complexity that NHibernate 0.3 introduced in my apps. Back then, when I tried to explain the pain points I had with NH, the reaction I was most often met with was “That’s odd. I haven’t had any problemt with it.”

So Micro-orms to me is great news. I like Dapper, Massive and PetaPoco. Orms are just the beginning. In fact, I think we should expand the notion to “Micro frameworks” to cover all kinds of frameworks from databases to service busses, from IoC containers to rest apis.

The term “Micro framework” might sound a little too much like the Microsoft .NET Micro Framework. So let’s instead go for something even smaller … what about PicoFX?

A dogma needs strict rules. So here are the rules that a framework or api must respect to be a PicoFX:

Max 1000 Lines of code (excluding Unit tests)
Only one code file that the user can include in any project
No dependencies except the .NET BCL
Must have open source license
Fully unit tested

I challence you to take a look the framework that you wrote. Rip it apart like Rob Eisenberg did with Caliburn. Take the crucial bits and leave the rest out. Boil it down to under 1000 lines. Is it possible? Then you’ve managed to distill the essense of the framework and leave the fat to the dogs. And chances are performance is improving too.

That should be simple enough, right? Kind of. Once the first version is out and the users start requesting additional features and you have all sorts of great ideas as well, trouble will start brewing. Can you add features and stay below 1000 lines? It’s tempting to add the killer feature thinking that 1156 lines won’t hurt. It’s only a bit more than 1000…

Every feature represents an additional tax, that your users will pay. What if you start taking out one feature every time you add one, respecting the 1000 lines limit? You won’t be 100% backwards compatible. That may hurt some. On the other hand, you’ll be keeping your promise of a simple framework that stays simple.

I’d better chip in and start taking my own medicine. I hereby submit PicoIoC, a 280 line fully functional IoC container. It’s heavily inspired by Autofac and supports registration by type, by lambda or by instance. Automatic lifetime handling means PicoIoC will deal with calling Dispose() if your class implmenets IDisposable. It support abstract factories and Lazy<T>. Yak yak yak. Check it out yourself. I promise you it will stay

I can’t wait to see the PicoFX versions of your framework.

QueryMyDesign allows you to query the structure of your own code.

2010-12-28T21:36:00.001+01:00

What if you could test your design like this:

from m in Methods.InAssemblyOf<MyClass> where m.CyclomaticComplexity() > 40 select m

or this?:

from t in Types.In(sut) where t.CountUsesOfNamespace("SkinnyDip.Tests") > 0 select t

Then, if placed inside a unit test method, you will be able to verify your design (and ensure against regression):

Assert.Empty(from t in Types.In(sut) where t.CountUsesOfNamespace("SkinnyDip.Tests") > 0 select t);

Why re-invent NDepend? Short answer, I’m not. NDepend can do anything QueryMyDesign can and much much more using its own query language. I just thought it would be interesting to have a small, simple api to express basic structural queries with a LINQ friendly syntax.

This way, you get type safety for free. Plus R# refactorings will work all the way to your queries.

Did I say type safety? Since namespaces are represented as strings by Cecil and since they're not really first class citizens of System.Reflection either, working with namespaces is not nearly as fool-proof as working with types. C# has the built in function typeof(A) but I miss namespaceof(A) and methodof(A.B). Methodof(A) can be faked by using Clarius Labs’ Typed Reflector and the Reflect<MyClass>.GetMethod(c => c.DoStuff()) syntax. I’ve modified the code to return Mono.Cecil.MethodDefinition instead of System.Reflection.MethodBase.

This allows you to write tests of single methods:

Assert.True(Reflect<D>.GetMethod(d => d.UsesE()).CyclomaticComplexity() < 10);

So, what can you learn about your code using QueryMyDesign?

* Number of instructions, number of variables, and cyclomatic complexity of methods, types, namespaces and assemblies.

* All references (methods to methods, types to types, namespaces to namespaces and assemblies to assemblies.)

* Discover cyclic references between types (and the reference graphs between them.)

* Calculate Uncle Bob's metrics such as Instability, Abstractness, Distance From Main Sequence, Amount of Pain, and Amount of Uselesness.

Convienient syntax

If you want to ask specific questions, like “what types does System.String use?”, “does type A depend on type B?” or “Which of my types has any cycles?”, there’s convienient extension methods provided:

var stringDependencies = Types.UsedBy<string>()

bool aUsesB = Reflect<A>.GetType().FindUsesOf<B>().Any();

var typesWithCycles = Types.InAssemblyOf<MyType>().Where(t => t.HasCyclicDependency());

Behind these easily accessible methods lie classes such as MethodDependencyFinder, TypeDependencyFinder and so on. For more advanced scenarios you’ll need those.

Pain and uselessness

If you want to get dirty with the metrics relating to The Main Sequence, things get a little bit less convienient. But only slightly. Metrics like Instability needs to know of both incoming and outgoing dependencies so we need some way of defining the system boundary. Otherwise we won’t be able to find incoming dependencies. We need a Dependency Structure Matrix:

var dsm = new TypeDependencyStructureMatrix(new[] {typeof(SomeClass).Assembly});

This constructor takes a collection of assemblies to search within. When that’s settled, we can ask questions like:

double i = dsm.GetInstability<SomeClass>();

double a = dsm.GetAbstractness<SomeClass>();

double d = dsm.GetDistanceFromMainSequence<SomeClass>();

double p = dsm.GetAmountOfPain<SomeClass>();

double u = dsm.GetAmountOfUselesness<SomeClass>();

Whether these metrics can tell you precisely what parts of your code hurt is a different discussion. At least they’re easily accessible using QueryMyDesign.

Get the source at GitHub. And remember, it’s alpha quality.

Using the repository pattern to achieve persistence ignorance in practice

2008-09-09T18:35:00.002+02:00

I recently experimented with migrating a project from Linq2Sql to Linq2NHibernate. It’s a small windows time tracker application that features offline capability.

The original app built a year ago used Linq2Sql’s class designer to create domain classes from existing database tables. Along with the domain classes it created a DataContext class:

public partial class DomainDataContext: System.Data.Linq.DataContext
{
 public System.Data.Linq.Table<customer> Customers
 {
  get { return this.GetTable<customer>(); }
 }
 public System.Data.Linq.Table<project> Projects
 {
  get   { return this.GetTable<project>(); }
 }
}

Tables of T are in fact Microsofts implementation of the repository pattern. I have two issues with Table<T> as a repository implementation. One, I like my repositories to take the shape of a collection more in line with what repositories were originally: A facade that let’s you access data through a collection metaphor. The method names should be Add, Remove and Clear as you would expect from a normal collection. In Linq2Sql MS renamed those to InsertOnSubmit, DeleteOnSubmit and so on.

Issue number two with Table<T> is that the methods Insert/DeleteOnSubmit are not defined in an interface but on Table<T> directly. That means I have to rely on a concrete class. Bad OOD karma! The thing is, these methods are really part of another pattern, Unit of Work. There is a muddy mismatch between the two and a need for a unified way to access data through repositories.

In order to be accessed in a manner closer to real collections, I could let each repository implement ICollection<T>:

public interface Repositories : IDisposable
{
 ICollection<customer> Customers { get; }
 ICollection<project> Projects { get; }
}

That’s all well and dandy as long as my repositories are simple in-memory collections or in-memory collections persisted using Xml. If I want to switch to repositories backed by an Linq2Sql or Linq2NHibernate, troubles arise. The result is that each time a repository is queried, the whole table is loaded into RAM and filtered there. Ooops. The trouble has to do with the way that Linq compiles queries.

Linq is able to choose between running queries in-memory or capturing the query expression in an expression tree then translating it into Sql for execution on the database server. The (not so secret) secret consists of two interfaces, IEnumerable<T> and IQueryable<T>.

If the collection you query against implements IQueryable<T>, then the expression is translated to Sql using Linq2Sql. If the collection implements IEnumerable<T>, the query is run in memory when the GetEnumerator() method is called.

When switching from in-memory collections to ORM backed repositories, I can no longer let my repositories implement ICollection<T> only, since Table<T> and Linq<T> implement IQueryable<T> instead. In other words I’m forced to change my interface to:

public interface Repositories : IDisposable
{
 IQueryable<customer> Customers { get; }
 IQueryable<project> Projects { get; }
}

Only now, I’m back to having repositories that are queryable but do not include any way to add or delete objects.

What I really like is a way to leave my Repositories interface alone while still being able to switch between database persistence, file based persistence, no persistence, pen-and-paper based persistence, coffee based persistence … anyway, you get the point.

What I need is a new interface:

public interface QueryableCollection<t> : IQueryable<t>, ICollection<t> { }

Allowing me to declare my repositories as:

public interface Repositories : IDisposable
{
 QueryableCollection<customer> Customers { get; }
 QueryableCollection<project> Projects { get; }
}

That way I can easily swap persistence mechanism, even have two different schemes running at the same time.

Here are is my repository implementation for NHibernate:

public class NHRepositories : Repositories, ConnectionProvider
{
 private readonly ISession _session;



 public QueryableCollection<customer> Customers
 {
  get { return new NHRepositoryAdapter<customer>(_session); }
 }

 public QueryableCollection<project> Projects
 {
  get { return new NHRepositoryAdapter<project>(_session); }
 }

}

NHRepositoryAdapter exposes NHibernate’s Query<T> as a QueryableCollection<T>:

internal class NHRepositoryAdapter<t> : QueryableCollection<t>
{
 private readonly ISession _session;

 public NHRepositoryAdapter(ISession session)
 {
  _session = session;
 }
 
 public IEnumerator<t> GetEnumerator()
 {
  return _session.Linq<t>().GetEnumerator();
 }
}

To satisfy the in memory collections I made an adapter to expose an IList<T> as a QueryableCollection<T> using Linq’s built-in AsQueryable() method:

public class QueryableList<t> : IList<t>, QueryableCollection<t>
{
 private readonly List<t> _list;
 private readonly IQueryable<t> _queryable;

 public QueryableList()
 {
  _list = new List<t>();
  _queryable = _list.AsQueryable();
 }

 public IEnumerator<t> GetEnumerator()
 {
  return _list.GetEnumerator();
 }

 public Expression Expression
 {
  get { return _queryable.Expression; }
 }

}

Couldn’t I just implement my repositories by inheriting List<T>, implementing IQueryable<T> and then delegating calls to IQueryable<T>’s members to Enumerable.AsQueryable()?. That would save the tedious wrapper code. Unfortunately that results in stack overflow errors when Linq calls the getters for the three properties Expression, Provider and ElementType defined in IQueryable<T>. I suppose the reason is that AsQueryable is in fact an extension method and thus doesn’t obey normal inheritance rules. Calling base.AsQueryable() gives the same result as this.AsQueryable() even though the getters have been overriden in the subclass.

Another concern to air is: Does the persistence mechanism really change often enough to justify this abstraction and added complexity? Not always. In this particular app, yes. One one the requirements is smooth operation online as well as offline. I can achieve that easily using my QueryableCollection interface. When running offline my repositories use xml as storage. When online and when synchronizing it uses NHibernate with a Sql Server database behind.

Another way of achieving offline functionality would be to only let the app talk to a SqlCe 3.5 database via Linq2Sql or Linq2NHibernate and then let ADO.NET Synchronization Services to sync it with the master Sql Server database. Then you wouldn’t need the abstraction I made, but complexity would only be relocated to configuring Synchronization services.

Anyway this solution allows me to maximum flexibility in persistence ignorance. The payback is a new interface and an adapter two adapter classes for each storage mechanism. It’s not feasible in all solutions but can be if you need the ability to manage offline/online synchronization manually or store data in several places using the same repository abstraction.

2 Responses to 'Using the repository pattern to achieve persistence ignorance in practice'

Morten Lyhr said,

ON SEPTEMBER 9TH, 2008 AT 11:40 PM

Great post Søren!

But its not persistence ignorence you have achieved, its ORM ignorence.

Actually I was wondering how to make a “POCO LINQ” repository that was not tied to any specific ORM. I guess you beat me to it
Rasmus Kromann-Larsen said,

ON OCTOBER 10TH, 2008 AT 11:50 PM

Nice post.

I’m about to play around with LINQ2NHibernate myself, in a LINQ-less solution that was recently kicked up to 3.5. I think your post might be the inspiration for my repositories.

- Rasmus.

Dear Santa, bring us Boo 1.0

2008-06-27T19:59:00.000+02:00

I wish the programming language Boo had a greater momentum and larger user group. I’d love to use it for writing production quality enterprise apps, but I don’t dare. To be frank, even though the authors do an excellent job of adding features and fixing bugs, there’s just substantially fewer hands available, compared to the forces behind C# 3.0 and VB.NET 9.0.

The ideas behind Boo are fresh and experimenting and they let us do great things with little effort. My hands ache every time I have to transform some collection into another using 10 lines of C# 2.0 when I could have done it using 2 lines of Boo. Getting lambda expressions and extension methods in C# 3 is a step forward, but Boo is already moving further ahead and giving us extension properties and a built-in abstract macro facility that enables us to write in-language DSLs.

Still, the risk of switching to Boo for real world apps is too big, and the tool support is too small at this time. Boo also needs to let me define my own generic types and methods before our relationship can move to the serious phase.

I wish there was some way I could support the authors of the Boo programming language. Money? Don’t have that much. Programming time? My family will leave me if I spend more pc-time.

Instead, here are a couple of words of appreciation: Boo brings the best from the functional style languages and the CLR. It provides ultimate power while still keeping tight focus on simplicity.

In a perfect world… (sigh)

Edit and Continue effectively disabled in Visual Studio 2008

2008-05-03T20:23:00.000+02:00

I find edit and continue to be a productivity booster and I use it every day. Or, I used to use it before I got a habit of using LINQ. I also find LINQ to be a productivity booster because I can express my intend at a higher level of abstraction than before LINQ. I rarely write foreach loops anymore since often it’s more brief and to the point to use one of LINQ’s extension methods and lambda expressions.

Whenever you have a method that contains one or more lambda expressions, edit and continue stops working. It’s not that it’s actually disabled in VS. You can go ahead and edit your method when debugging, it just won’t allow you to continue. So it’s effectivelyEdit and NO Continue ™.

It didn’t start as a problem for me, but becoming friends with LINQ and really getting it under my skin means a rough estimate of 75% of my methods contain LINQ code these days. Why don’t my two best friends, LINQ and Edit’n'continue, like each other? I prey the explanation is: It’s hard to do and Microsoft didn’t get it ready before they shipped VS 2008.

Service pack 1 maybe?

2 Responses to 'Edit and Continue effectively disabled in Visual Studio 2008'

Subscribe to comments with RSS or TrackBack to 'Edit and Continue effectively disabled in Visual Studio 2008'.

Morten Lyhr said,

ON JUNE 13TH, 2008 AT 7:48 PM

I really dont see the point in E&C?

Why do I have to use my time in the debugger?

Stay out of the debugger, with unit test and TDD.

As usual Jeremy D. Miller — The Shade Tree Developer, sums it up nicely.

Occasionally you’ll see a claim that TDD == 0 debugging. That’s obviously false, but effective usage of TDD drives debugging time down and that’s still good. From my experience, when the unit tests are granular the need for the debugger goes way down. When I do have to fire up the debugger I debug through the unit tests themselves. Cutting down the scope of any particular debugging session helps remarkably. The caveat is that you really must be doing granular unit tests. A lot of debugging usage is often a cue to rethink how you’re unit testing.

Taken from http://codebetter.com/blogs/jeremy.miller/archive/2006/03/31/142091.aspx
Soren said,

ON JUNE 20TH, 2008 AT 11:02 AM

I’m not a debugger lover I’d certainly love to use it less and I too think that doing TDD helps in that regard. But even unit tests and the code under test have to be debugged once in a while.

Given that a debugger is sometimes necessary, E&C just makes the ride much smoother. The whole experience is more organic, like I’m molding a sculpture with your hands.

Contrast that with the rigid feeling of writing, compiling, running tests. The pause from the time when you have a thought till the time when it’s effect becomes observable is very small with E&C.

The point you are making is against relying overly on debugging, not against E&C. A debugger capable of E&C is preferable over one that isn’t.

Design by C#ntract

2008-05-02T20:23:00.000+02:00

Designing by contract is a way of writing the specification into the class or method itself. It holds the promise of making specification and test code more visible to the users of the unit so as to minimize misunderstandings and catch error conditions early.

It’s just not something we C# developers are used to being able to do. Not in C# anyway. Changing to the Boo language where is can be done safely by the use of macros, or to spec# which (like Boo) is still in development, is something few peoplehave the guts to do in production.

So when I read The Wandering Glitch’s series about doing Design By Contract in C#using the new functional possibilities, I was thrilled. It goes a long way to let us specify pre and post conditions. Andrew Matthews even does post conditions that reference state from before method entry as in: age > old(age).

His code also has the benefit that when you pass in an expression that results in an exception you get a string representing the original expression thrown back at you as the exception’s message.

There was a couple of things that I thought could be improved a bit:

1. The error message that you get back from the Expression.ToString() is not nice to look at. A typical string representation of an Expression could be: () => (value(DbcTest.Person+<>c__DisplayClass0).age >= 0)
2. It seems like overkill to do serialization to capture the old state of simple types like int and strings.

The first one is easy. With the help of a simple regular expression, we can throw away the ugly part and leave behind the important stuff, so that the exception gives me this message:

Violation of precondition: age >= 0

There’s not a whole lot of code behind this:

[DebuggerStepThrough]
public static void Require(this T obj,
   Expression> booleanExpression)
{
  var compiledPredicate
                  = booleanExpression.Compile();
  if (!compiledPredicate())
     throw new ContractViolationException(
        “Violation of precondition: ”
        + booleanExpression.ToNiceString());
}

static readonly Regex noiseRemoverRegex1 =
  new Regex(@”value[^)]*).”, RegexOptions.Compiled);
static readonly Regex noiseRemoverRegex2 =
  new Regex(@”.*=>s((.*))”, RegexOptions.Compiled);
private static string ToNiceString(
  this Expression expression)
{
   var output = expression.ToString();
   output = noiseRemoverRegex1.Replace(output, “”);
   output = noiseRemoverRegex2.Replace(output, “$1″);
   return output;
}

Which can then be used thus:

this.Require(() => age >= 0);

So far, all we have, is another way of writing Debug.Assert statements with a little extra oomph.

Comparing a variable to the previous value

How do we store the old value of a variable for later comparison? Closures are capable of freezing the value of local variables. But what if the variable is a reference type and the value that you want to compare to its old value is a member of that object? If the object is immutable (like strings are), no problem. Then you know the value hasn’t changed, because it can’t change.

But if you’re trying to validate old_person => old_person.Age == person.Age you’ll be in trouble because the value of Age will compare against itself and give a false positive in the above case. To overcome that Matthews uses serialization to make a deep clone of Person and all its members and its members’ members and so on. But that has a huge cost. You don’t know how bit the serialized object graph is going to be, but I’ll bet you it will include lots more objects than you can compare in a line of code!

So I opted for a simpler approach that allows me only to compare old values of value types. Value types, unlike reference types, can be captured on block entry:

public class EnsureBlock : IDisposable
  where T : struct
{
  protected const string ViolationTemplate
     = “Violation of contract: {0}”;
  private readonly Func _predicate;
  private readonly T _oldT;
  private readonly string _predicateString;     

  public EnsureBlock(
     Expression> predicate,
   T oldValue)
  {
     _predicateString = predicate.ToNiceString();
     _predicate = predicate.Compile();
     _oldT = oldValue;
  }     

  [DebuggerStepThrough]
  public void Dispose()
  {
     if (!predicate(oldValue))
        throw new ContractViolationException(
   string.Format(ViolationTemplate,
   _predicateString));
  }
}

// Only syntactic sugar:
public static class EnsureBlockExtension
{
  public static EnsureBlock Ensure(
     this object obj,
   Expression> predicate,
   T oldValue)
   where T : struct
  {
     return new EnsureBlock(predicate, oldValue);
  }
}</T,></T,></T,>

The little "where T : struct" after the class declaration restricts the use of the captured variable to simple types and user defined structs. Objects cannot be passed in, so the following is allowed by the compiler:

int age = 12;
using (this.Ensure(old_age => age > old_age, age))
{
  age--;
}

The following, however, is not accepted by the compiler because p is a reference type:

var p = new Person();

using (this.Ensure(old_person => p.Age > old_person.Age, p))
{
  age–;
}

So what we really want to do is pass in the p.Age member as the old value:

var p = new Person();

using (this.Ensure(old_age => p.Age > old_age, p.Age))
{
 age--;
}

It’s definitely not perfect. We still need to compare object references against their old values sometimes. There are two ways to go about that:

1. Make an overload of Ensure that has a "where T : class" and that uses Matthews code to serialize the object graph.
2. Walk the Expression tree and manually capture all members that are references within the expression. Obviously that’s not a trivial thing to do.

Maybe I’ll give it a try some day. If you don’t beat me to it!

One Response to 'Design by C#ntract'

Subscribe to comments with RSS or TrackBack to 'Design by C#ntract'.

Søren on DBC « The Wandering Glitch said,

ON MAY 5TH, 2008 AT 1:27 PM

[…] than comment on the blog, he went away and did something about it. And it’s pretty good! Go take a look, and then pick up the baton from him. Your challenge is to extract the parmeter objects from the […]

Grammar noise cancellation

2008-04-21T20:22:00.000+02:00

Imagine a simple Irony grammar written in C# and capable of parsing the following string into a list of greetings:

mjallo dude howdy dudess hey "gal"

This could be written like so:

class GreetGrammar : Grammar
{
 public GreetGrammar()
 {
   var stringlit = new StringLiteral("stringlit");
   var id = new IdentifierTerminal("id");
   var homergreeting = new NonTerminal("homergreeting", "mjallo" + id);
   var cowboygreeting = new NonTerminal("cowboygreeting", "howdy" + id);
   var greeting = new NonTerminal("greeting",
                          homergreeting |
                          "hey" + stringlit |
                          cowboygreeting);
   var program = new NonTerminal("program",
                          greeting.Star());
   Root = program;
 }
}

There’s quite a few characters of noise in this, compared to a clean EBNF syntax. Let’s enumerate what’s distracting:

1. Every declaration has the name declared twice: As an identifier and again in a string.
2. "new NonTerminal" is repeated a lot and hinders readability.
3. "+" is used as a so called sequence operator, whereas BNF uses a space.
4. "var" is distracting.
5. The *, ? and + operators in EBNF are written as method calls: Star(), Q() and Plus() respectively.

If we switch to the Boo language, then with three little Boo macros, we can get rid of 1 and 2 to render this:

class BooGrammar(Grammar):
  def constructor():
     stringliteral stringlit
     identifier id
     rule cowboygreeting, "howdy" + id
     rule homergreeting, "mjallo" + id
     rule greeting, homergreeting | ("hey" + stringlit) | cowboygreeting
     rule program, greeting.Star()
     Root = program

That’s a little bit nicer, innit? Note that the var keyword is implicit in Boo, so that’s a free ride.

The only new noise added is the parenthesis around "hey" + stringLit. I believe it has something to do with a difference (between C# and Boo) in operator precedence and operator overloading. If you omit the parenthesis, the grammar compiles, but it won’t parse the input string properly.

So how about noise 3 and 5? Can we get rid of those as well?

The problem with the sequence operator (3) is that space is not an operator in either C# or Boo, so there’s nothing to overload.

Let’s look at the three operators, *, ? and +. Well in general purpose languages like C# and Boo, * and + are binary operators. In EBNF they are unary. Therefore it’s not possible to steal them. And ? is a ternary operator in C#, and it’s not an operator at all in Boo.

Still, this is a small step towards noise free executable grammars in .NET.

Looking for an open source text editor component with syntax highlighting

2008-04-17T20:21:00.000+02:00

I’m trying to give a little back to an open source project, namely Irony that I blogged about. My idea was this: We’re getting used to intellisense features in mainstream .NET languages such as syntax coloring, error highlighting, code completion, signature tool tips and more. When writing a DSL to be used and understood by business experts and developers, those things are not readily available.

The benefit of writing an add-in for Visual Studio that allows intellisense for DSLs parsed with Irony is big. Writing a managed language service for Visual Studio is no simple task. I want to avoid the complexity of the Visual Studio domain model and keep it simple using a stand alone text editor component. So I went searching…

There had to be lots of open source syntax highlighting text editors out there, I thought. And there is. I found a couple of well written candidates like SharpDevelop IDE TextEditor, the xacc IDE editor and SyntaxBox from the Puzzle Framework. Finally, there are quite a few commercial offerings, but introducing a dependency to a commercial product in an open source project is not the road to popularity.

Both SyntaxBox and SharpDevelop let you extend the built-in syntax schemes with your own. This is done by writing an XML based grammar. It’s possible to do and I have done it a couple of times. But having already written my grammar once using Irony, it just doesn’t feel right having to do it over again — this time using a different syntax.

Running an Irony-generated parser gives as output not only an AST, but also a list of tokens. If I could feed that list of tokens to the editor and bypass the built in lexing mechanism, I’d be laughing now. But it’s not that easy.

The problems with the three components that I tried using, fell into three categories:

The editor is entangled in references to other parts of the project, making it impossible to reuse it in other projects like Irony.
The built in lexer cannot by turned off, so lexing is being done twice, and two sets of formats for each token have to be merged — resulting in awfully bad performance.
The extension points are leaky abstractions that requires you to know of the inner workings of the text rendering.

Not unsolvable issues, but issues that result in poor maintainability and hacks en masse. Plus it takes a lot more (spare)time than I have.

Do you know of any open source text editor component that supports syntax highlighting AND lets me replace the tokenizer/lexer with something else?

2 Responses to 'Looking for an open source text editor component with syntax highlighting'

Subscribe to comments with RSS or TrackBack to 'Looking for an open source text editor component with syntax highlighting'.

Daniel Grunwald said,

ON APRIL 18TH, 2008 AT 11:38 AM

You can supply our own implementation of IHighlightingStrategy for SharpDevelop’s text editor and consume your own tokens in that. The interface isn’t as clean as it should be (at least in SharpDevelop 2.x), but it’s certainly possible. I would like to hear what problems you had exactly with SharpDevelop’s editor.
Soren said,

ON APRIL 19TH, 2008 AT 8:41 PM

Daniel,

the #dev editor is a great editor, and I really hope you will help me get this scenario working.

Having failed several attempts to make a custom IHighlightingStrategy work, Finally, I tried cutting to the bone by implementing the simplest possible scenario: Not tampering LineSegment.Words at all within MarkTokens(). I expected the text to be all black and otherwise work normally. But the editor starts behaving weird and it’s not possible to enter or edit text, because it gets cut off at a fixed column.

Try downloading http://skarpt.dk/blog/SDTextEditorTest.zip. It references ICSharpCode.TextEditor.dll version 3.0.0.2970.

Looking at the default implementaion I get a feeling that MarkTokens needs to be doing something else, something that is not obvious from the interface definition?

No reason to laugh at Irony

2008-04-16T20:21:00.000+02:00

Being a DSL geek I just want to give a shout out to Roman Ivantsovs Irony project. Irony is a LALR parser generator that lets you write your grammar in C#. If you’re looking to build your own little Domain Specific Language, Irony is a good alternative to ANTLR andGold Parser Builder.

A grammar written in C# with Irony looks as much like EBNF notation as possible given the constraints that writing them in C# imposes. For example, this definition of three non terminals in EBNF:

Expr  ::=  n | v | Expr BinOp Expr | UnOp Expr | '(' Expr ')'
BinOP ::=  '+' | '-' | '*' | '/' | '**'
UnOp  ::=  '-'

…translates into this C# code for an Irony grammar:

Expr.Rule = n | v | Expr + BinOp + Expr |
           UnOp + Expr | "(" + Expr + ")";
BinOp.Rule = Symbol("+") | "-" | "*" | "/" | "**";
UnOp.Rule = Symbol("-");

(Add to this a line for declaring each of the three non terminal variables - I left them out to prove a point

The syntax of the C# and the ANTLR versions are impressively similar, though there still is some noise left. It’s not as pretty as what Ghilad Bracha can do in Newspeak, but then again, C# wins by being a language that is actually used by developers.

Gold Parser Builder and ANTLR may be more mature than Irony, but what I like the most about the latter is the fact that the grammar is compiled along with the application that uses the grammar to parse DSL code. That means less switching between Visual Studio and ANTLR og Gold. Less fuss. Shorter path from language design to language test to language use.

The abstract syntax three (AST) that my Irony generated parser makes is nice and clean. It can even filter out punctuation characters, so that for instance parenthesis do not make up nodes themselves, only the expression within the parenthesis is a node in the tree.

That’s it for the extremely brief introduction to Irony. You can check out some more detailed samples by downloading. Irony is definitely a part of my toolbox so stay tuned for more on Irony.

One Response to 'No reason to laugh at Irony'

Subscribe to comments with RSS or TrackBack to 'No reason to laugh at Irony'.

Soren On Software » Looking for an open source text editor component with syntax highlighting said,

ON APRIL 17TH, 2008 AT 10:27 PM

[…] trying to give a little back to an open source project, namely Irony that I blogged about. My idea was this: We’re getting used to intellisense features in mainstream .NET languages […]

Bluefield projects

2008-04-16T20:20:00.000+02:00

The terms greenfield site and brownfield site have their origin in urban planning. Greenfield means using fresh farm land for building projects. Brownfield means reusing existing industrial sites for new purposes.

A greenfield software project is a fresh start project that lets you make design decisions without regards to an existing codebase. Productivity is high, as you are not bound by an existing code base. A brown field project is the opposite: Maintaining legacy code. Productivity is low. Working on a brown field project often feels like dragging through mud.

Here are two paradoxes:

Brownfield projects are more common than green field projects. All the while most developers treasure greenfield more than brownfield.
The computer science schools spend more time teaching greenfield-related techniques than brownfield. Meanwhile, a greenfield project may start green but before long it becomes brown. Even the code you wrote yourself will seem unintelligible in 6 months.

Most projects that I participate in have a color somwwhere between green and brown. Often there is a legacy app written in VB6 and it has to be rewritten in C#. The existing app is considered the blueprint and all of its functionality must be duplicated in the new app. Plus all the new features that the customer expects to be thrown in while we’re at it.

These kind of projects requires you to reuse some legacy code and allows you to make some greenfield decisions.

How to color the projects? Black field project? Too sinister. Blue field? Well the symbolism is not as clear as the terms green and brown. What’s your favorite color?

Design by Contract in more than 20 lines

2008-01-23T20:20:00.000+01:00

Some time ago, Ayende wrote a post, Boo: Design By Contract in 20 lines. It shows what can be done with very little effort using Boo’s meta programming constructs.

I shamelessly ripped his code in order to take it a bit further. I wanted keywords that resemble those of Microsoft incubation DBC enabled language called spec#: Requires, ensures and invariant. There are more features in spec#, but these are the basic three.

I also wanted requirements to be places inside the method, not only as attributes outside of it. So here’s the code for download.

Heres a class that makes use of these constructs:

import DesignByContract
import System

[invariant(women > 0)] #Invariant declared outside of class still has access to fields
class Promise:
 eternalLife = false
 women = 8
 beer = "A lot"
 forgiven = true

 def SmellBad():
  women = 0

 [requires(beer == "Unlimited")] #Requirement outside of method scope
 def GetDrunk():
  beer = "none"
  ensures women > 3:   #Ensures statement that works on a block
   women = 4

 [ensures(eternalLife)] # Ensures statement outside of method scope
 def DuplicateCode():
  requires beer == "A lot" #Requires statement inside
  if forgiven:
   eternalLife = true

And finally, here’s a specification, or test if you will:

import Specter.Framework

context "Invariant, requires and ensures":
 promise as duck

 setup:
  promise = Promise()

 specify { promise.SmellBad() }.Must.Throw()

 specify { promise.GetDrunk() }.Must.Throw()

 specify { promise.DuplicateCode() }.Must.Not.Throw()

The added requires, ensures and invariant statements in the Promise class act as a form of specification for the clients of the class. They communicate (and check runtime) what conditions are to be met if the output is to be valid. Now, the specification in the last code segment is written using Specter and it also acts as a specification for the class.

Note: If you haven’t tried Specter, which is a really nice DSL on top of NUnit, here’s what happens: Each context is made into a nUnit test class and each specify statement is translated into a test method, which can then be run using for instance the NUnit gui or with its own console runner. The syntax is way nicer than NUnit’s Assert.ThisAndThat(…) and the test methods are automatically named.

Both the internal specification in the form of requires, ensures and invariant statements and the external specification embodied in the specter context (unit test) tell us something about how the system is expected to behave under certain conditions.

When to use which then? Good question, glad you asked. I haven’t thought about that for very long, but perhaps you guys have an idea? I suppose the main difference is that the external specification is run on demand, like a test. The internal specification is run every time the method is run, in production as well. The internal specification has better be relatively cheap compared to the external one. So, any thoughts?

Don’t do modes, mkay? Modes are bad.

2007-09-29T20:19:00.000+02:00

I recently read Raskins “The Humane Interface“. It’s from 2000 and unfortunately Raskin died in 2005. What a pity, because some of his ideas are truly groundbreaking in the field of usability. While reading, I felt that this book is going to change the way we make not only GUIs but the way we make software as whole. Still, the material that he produced in his lifetime contains enough to keep me interested for … a lifetime.

If you haven’t read it, the basic idea is that we as software people have to know about the basic ergonomics of the mind, just as furniture people have to know about the ergonomics of the body. We can learn about the Ergonomics of the Mind from cognitive science. According to Raskin, the three most important things we learn from them is:

1. We can only focus on one thing at a time. If the message you are trying to convey your user is not at the “locus of her attention”, she just won’t see it. And it’s your fault as the programmer.

2. As we do certain actions repeatedly, they become automatic. Software should try to make it easier for people to learn to automate common tasks.

3. Modes confuse. Caps lock is a good example. Insert/overwrite modes on your keyboard is confusing. Modes in UIs are bad. Don’t do modes.

Ok, so here comes the actual reason for writing a post about this: Richard Raskins son, Aza, is continuing his fathers work, combining many ideas into a product called Enso. Enso is really quite different from other software. It contains a launcher and a spellchecker. So does many other products, but the implementation is way different from anything this far.

The launcher takes over the caps key (it’s only in the way, anyway) and turns it into a command key. While holding it down, you type stuff like “open word”. When you let go of the caps key, Word opens up.

The spellchecker is reached through the “spellcheck” command (using the caps lock key). It spell checks whatever is selected in whatever program is active. This far, only English is supported, though.

It takes a little getting used to, but I’m never gonna uninstall it. And I’m gonna read the book once every year ahead.

And I’m not gonna do modes.

Try it out: Humanized Enso.

Fresh AOP meat on the dish

2007-08-25T20:18:00.000+02:00

Old news to you, maybe, but news to me. And good news if you are just a little bit tired of the usual drawbacks of AOP using subclassing or proxies. In a previous post I discussed these problems with respect to the Policy Injection App Block in Enterprise Library 3.

Check out the PostSharp project. It uses MSIL post compilation. That means that after the c# compiler has finished compiling you code, PostSharp compiles it again to inject your interceptors. Very interesting in its own right.

One of the interesting spin-offs of PostSharp is called PostSharp4EntLib and is part of the EntlibContrib project. It makes it easier to have your Enterprise Library policies injected into your entities. Not runtime, but compile time. And you don’t even need to inherit from MarshalByRefObject and wrap all instantiations in ugly calls to abstract factories anymore. PostSharp takes care of this for you.

Only one hurdle so far: It will not recognize Danish characters in my identifiers. This minor setback can’t hurt me though. Even though it’s not reached production level stability, I’m going to try it out soon in an enterprise project.

Stay tuned for further details.

6 Responses to 'Fresh AOP meat on the dish'

Subscribe to comments with RSS or TrackBack to 'Fresh AOP meat on the dish'.

Thomas Jespersen said,

ON AUGUST 29TH, 2007 AT 5:36 PM

Interesting!

I wonder what the debugging experience is like!
azza gregg said,

ON SEPTEMBER 18TH, 2007 AT 9:54 AM

I’ve just started using it for the last week to implement logging throughout a multi-tiered asp.net 2.0 web application and I’ve found it easier to implement than the Microsoft Policy Injection Block.

As for Thomas’ comment, debugging is as normal however it looks like the post-compilation prevents you from being able to use the edit&continue VS2005 feature.

I’m almost finished, which unfortunately means I might have to roll-back because lost of posts out there mention it being not ready for production yet (doh!!!).

Looking forward to the next release, huge thanks to Gael Fraiteur!!
Soren said,

ON SEPTEMBER 18TH, 2007 AT 7:58 PM

In the meantime I’ve had some experience with debugging using VS2008. It’s better than all other AOP frameworks I’ve encountered, but still not 100%. Debug symbols are moved along with the code, so in 8 out of 10 exceptions will take the debugger to the right place in code.

But the last 2 tenths it will just give you a TargetInvocationException. Especially RuntimeInitialize() calls and static constructors are difficult.

Azza, bad news about edit and continue. I guess I’ve gotten used to not having that — it’s not working in VS2008

Could you post the urls for the posts that doubt PostSharp quality, please? I’m close to going production with it… Thanks!
azza gregg said,

ON SEPTEMBER 20TH, 2007 AT 8:51 AM

Hi Soren,

I’ve finished a first round of testing the Laos and Public namespaces and haven’t had any further issues which may mean this’ll go to test and production with the next release.

Sure you get those TargetInvocationExceptions, I was thinking about using the OnMethodBoundaryAspect to capture the OnException event and see if there’s more detail to be found…

My hesitation comes as a matter of caution when using something that still has the words ‘Beta’. I haven’t found anyone out there mentioning production implementation but did find the following link discouraging it;

http://doronsharp.spaces.live.com/blog/cns!E19CE2289AB7F8C1!137.entry

Enjoy VS2008…
Soren said,

ON SEPTEMBER 20TH, 2007 AT 3:47 PM

Azza, the blog post you refer to is from February when PostSharp was in alpha. It’s in beta3 now.

What’s more important than the official state (CTP, alpha, beta etc) is Gael’s willingness to provide support very quickly. And right now, he’s very dedicated to the project.

I’m planning to (very cautiously) take PostSharp into production months.

Regs, Søren
azza gregg said,

ON SEPTEMBER 24TH, 2007 AT 4:18 AM

Cheers Soren, I’m starting to feel a lot more confortable with this great peiece of software.

Regarding the TargetInvocationException, I’ve put a simple loop into the catch block that compares the InnerException to null and assigns to an exception variable. When the code breaks out of the loop we now have the actual Exception that was originally thrown.

Azza.

LINQ to POCO?

2007-08-25T19:54:00.000+02:00

I recently had the opportunity to try out LINQ for SQL beta 2 in a real world (though still small scale) enterprise solution. It’s been a while since I took an early CTP for a spin, so I was excited to finally have a go.

I used the Domain Model tool integrated into VS 2008 to have tables mapped into partial classes automatically. That worked like a charm. If any of my observations apply only to the Domain Modelling tool, and not to LINQ2SQL in general, I apoligize in advance. I’m not (yet) a LINQ expert…

I’m often concerned about the restrictions that different O/R mappers impose on your freedom to keep a clean, simple and efficient class design (otherwise known as POCO / Plain Old Clr Objects). My first impressions of LINQ in this regard, are these:

1. I love the embedded query language, and the code completion is good.

2. Association properties cannot be read only, thus preventing immutable properties. Immutable classes or immutable properties are fundamental to creating a clean, domain driven design.

3. You cannot add [Attributes] to the autogenerated properties, since partial properties are not supported in C#3. So you cannot use Enterprise Library’s attribute based validation framework, or some custom framework that uses attributes as the only interface. Xml serialisation can be tricky as well.

4. Autogenerated fields do not follow MS naming conventions which says fields should be camel cased. A property called Horse will have a corrensponding field named _Horse. Not critical but not very pretty either.

5. Associations require an additional property to hold the foreign key value. It can be private, but not omitted. One to many associations always have a parent property, only the child collection is optional. This forces the domain model to include something, which is not an intrinsical part of the domain: Foreign key values. They are there only to satisfy LINQ, so the domain object end up not being very Persistence Ignorant.

6. Even non lazy loadable associations are wrapped in an EntityRef. Not very POCO.

7. The same goes for collections, which are always of a specific type, EntityCollection. So no coding against interfaces or ReadOnlyCollection or custom collection types.

8. Objects that are constructed within a query are tracked automatically. It took me a while to realize why too many rows were being inserted in the database: I had created some of them to be temporary, but LINQ tracked them all and found them to be transient, therefore inserting them into the database.

9. In order for tracking to work, your classes must implement INotifyPropertyChange. Yet another restriction on my classes. They started out pretty POCO, but it all adds up to a very non-POCO feel.

Conclusion: That’s all for the first day with LINQ 2 SQL. Possibly, more issues will surface along the way, without doubt. These first issues are worth being aware of, as O/R mappers can make your life easier (particularly in small scale projects.) And a lot more difficult (typically in larger projects.)

Finally, a Microsoft-sponsored AOP framework

2007-05-20T19:54:00.000+02:00

It came out of the blue. Until the Patterns and Practices group in Microsoft release ThePolicy Injection application block as part of Enterprise Library 3.0, I would have never thought that Microsoft would ever release an AOP framework (or half an AOP frameword anyway). Especially since C# 3.0 and VB.NET 9.0 will introduce extension methods which go at least some of the way to let us inject Cross-cutting Concerns into classes that we don’t own or don’t want to clutter with code.

While mixins give os a way of letting foreign objects implement an interface in an ugly way, extension methods allow us to add new methods to existing classes in a nice looking way. The downside is that extension methods are more limited than mixins. Mixins can contain state, extension methods are just … methods.

AOP frameworks are there to provide two services to the developer: Mixins and interception. So far I’ve talked about mixins, but the Policy Injection application block (PIAB) doesn’t in fact provide mixins capability, only interception. And compared to other AOP frameworks it’s not that feature-rich at all. I still like it and here’s why.

What’s nice about PIAB is the way it’s integrated with the rest of Enterprise Library 3. It comes with ready made handlers that talk to the other blocks: Logging, Exception handling, Authorization, Performance counter, Caching and Validation. These cross cutting concerns cover 90% of what an average enterprise solution needs. And I can add new handlers and insert them into the handler pipeline. Handler code tends to be scattered in funny-named classes. This way it’s easy to organize sensibly.

I can get all that stuff if I’m ready to pay the price. And the price will always be the same (until the CLR starts supporting AOP or we get compile-time AOP like they have in the java world):

AOP is forcing us to 1) let our classes inherit from a certain baseclass, in this case MarshalByRefObject or to make all interceptable members virtual and 2) to never instantiate our objects using the new keyword. Instead an abstract factory is provided as part of the AOP framework. An PIAB is no exception to this rule. If you’re planning to plug PIAB into an existing project to get usage logging for example, you’d be forced to replace every instance of

Customer customer = new Customer();

with

Customer customer = PolicyInjection.Create();

The short term price is doing the search and replace. In the long run, your code gradually becomes more difficult to understand. If someone else from your team doesn’t know the convention to create objects this way, he’ll use “new” and suddenly everybody will be wondering why only some of the customers get intercepted by PIAB.

Mixins are a way to simulate multiple inheritance on an single inheritance runtime. But when PIAB requires us to inherit our business classes from a certain base class, we get no-inheritance instead of single inheritance. That can very well be a price you will be willing to pay, but you need to be aware of this before you decide to use PIAB.

If you’re not willing to pay this price and sell-out on the POCO principles there’s a nice in-between way: You get to choose the base class for your business classes, but then you will only get interception on the members that your class implements from a certain interface, that you specify. Often you’re not in a position to change the base class for foreign classes that you use, so this is a good alternative for those cases. You’ll still have to instantiate using the abstract factory though.

I’m not saying this to critisize PIAB or other AOP frameworks. They are made this way because it’s the only way. They all impose demands that go against POCO. The point is, you’ll want to know the limitations before starting using AOP in general and PIAB in particular. They are almost always mentioned as a footnote on page 64: “Oh by the way, to make any of this work, you’ll have to make all properties virtual and always instantiate objects using our factory.” What if the classes are provided without source code, then I can’t make their members virtual?

Maybe it’s time to reconsider POCO and become less religious about keeping classes clean. I’m looking forward to start using PIAB in the next real world project and to get some hands on experience. Anyway it’s great to know that AOP is moving from the dark-basement-experimental sphere to the enterprise-ready sphere.

For an in-depth discussion of the implementation choices in PIAB, see Ed Jezierski’s post.