Suave and DotLiquid

When ever I try out a new web framework one of the first things I look at doing is setting up a template engine for html. So when I started playing with Suave this is exactly what I did.

Suave is a simple web development F# library providing a lightweight web server and a set of combinators to manipulate route flow and task composition

Using the template engine DotLiqud:

DotLiquid is a templating system ported to the .net framework from Ruby’s Liquid Markup.

 

I thought I’d share some simple examples of how to use DotLiquid with the F# web framework Suave. This post isn’t going to go into detail about how it works, I’ll save that for a later post, I just wanted to show some quick examples.

Without further ado here is the first example (you will need to install Suave and Suave.DotLiquid packages, using either nuget or paket).

As you can see it’s quite minimal.

On line 7 we tell DotLiquid where our templates live.

Then on line 9 and 10 we define the data or model we wish to inject into our template.

Next we define a simple index function which renders a template with the name of “index.html” (which is in the templates directory we defined earlier) and passes model “people” to it.

Then the final step is to start the webserver with the default config provided by Suave and set the routing. Here we state that any request to the root of the site (in this case http://localhost:8083) will return the results of the index function.

Here is a copy of the index template:

Nothing too exciting but you can see how we use DotLiquid to render information that we passed into the template.

You’ll notice that the href for each person points to a details page, that doesn’t currently exist so let’s create it.

Now we need to modify our existing code a little to support the details path.

First we define a details function on line 13 which takes in the name of person we wish to view the details for. This like the index function renders a page and passes a model to it, in this case the model is a person from the list of people where the name matches the name passed into the function.

Now because we have two paths (routes) we use a built in Suave function called “choose” which allows us to define multiple paths. We used “pathScan” instead of “path” because we want to pull out information from the url and pass this to our function.

And there you have it a simple “dynamic” website with templating.

If you’d like to learn more about Suave check out the following resources:

Suave – Suave homepage which contains examples and docs.

Suave Music Store – great starting point in creating a music store site using Suave.

Tomas Petricek’s blog – articles on Suave and much more.

FsSnip Source Code – source code for Tomas Petricek’s FsSnip site.

Tamizhvendan S – articles on Suave (including a book) and F#

Repositories: Tell Don’t Ask

I believe tell don’t ask is one of the most overlooked components of Object Orientated programming. I will be honest, it takes more thought and time initially but more times than not it will result in a better and more habitable design.

Repositories by their very nature are prime violators of tell don’t ask. A common pattern is to ask a repository for a record and then perform some logic based on the record that was returned.

In this example we get a user from a repository based on username and/or email, if the user already exists we return an error, if not we register a new user.

This leads to records being leaked all over the place and logic being duplicated and spread through the application.

One alternative that I like to use is instead of returning records or DTO’s from my repository I will return a business object and then call a method on the business object that performs the logic.

This example encapsulates the knowledge of whether or not to create a user in the user business object returned from the repository. If the repository cannot find a user it will return a blank or null user business object which when Register is called on it, will perform the appropriate action, in this case return an error.

As you can see I am telling the business object to do something, it knows what state it is in and therefore knows how to perform the required logic. However I am still asking the repository for the business object, now this isn’t the worse thing in the world, it’s better than returning a record, but I wanted to see if I could remove asking the repository for something and instead tell the repository to do something. Another thing to be cautious about when using business objects in this manner is that they can quite quickly get rather large, every time you need the business object to do something different you have to create a new method on it.

This is where C#’s Functions and Actions come in handy. The first step was to allow the search criteria to be passed into the repository so I could have one generic repository. Then the repository needed to know what to do if it found a match and what to do if it didn’t. I ended up with the following code.

The problem was as you can probably tell using the repository in this manner doesn’t read very cleanly. Looking at the example above it’s not clear exactly what is going on. To solve this I created a static Query class which encapsulated the repository call and made the code more readable.

As always there are many other ways this could be achieved, this is just the solution I came up with at the time.

I hope you found this useful and next time you are writing a repository and returning a DTO or worse a record, stop and think, is there anyway you could encapsulate the logic into an object and return that from the repository instead or even better find a way to not return anything from the repository, as always have fun and don’t be afraid to try something different.

Banning the word “Agile” from the workplace

First off let me start by saying this is not an anti-agile post, I am a big fan of agile methodologies.

So why do I want to ban the word “Agile” from the workplace?

Well that’s pretty straight forward, I am constantly hearing agile being used as a reason for something.

Here are a couple of examples:

We pair program because we’re agile.

We do retrospectives because we’re agile.

Being agile is not a reason to do something, take the retrospective example. You don’t do retrospectives because you are agile, doing retrospectives is part of the reason you are agile yes, but it does not work the other way round. If your only justification for doing something is because you are agile, this shows a clear lack of understanding of why you are doing something and I highly suggest you question exactly why you are doing something.

Another of my favourites:

If we do [x] we’ll be more agile

More agile? What exactly does that mean? How do you measure how agile you are as a company? How many of the 12 agile principles do you satisfy? How many individuals and interactions do you favour over processes and tools?

No, they’re just meaningless measurements .

Instead explain why doing [x] is better for your company, regardless of how agile it makes you.

Doing retrospectives will allow us to address any issues and improve as a team.

If we release more often it will allow us a quicker feedback loop and our customers will get deliverables sooner.

So next time you hear someone or yourself use the word “agile” as a reason for doing something or as a measure of something, question it! Stop them in their tracks and ask them to explain exactly what they mean, without using the word agile, really get down into what they are trying to say.

I can’t promise you this will make you any friends, but I am confident it will make communication, understanding and intent clearer.

Feel free to let me know what you think, have you experienced this? Do you find it a problem? I’d love to hear your thoughts.

UPDATE: Pragmatic Dave has a similar article on his blog, if you enjoyed this article I recommend you give his a read at: Time to Kill Agile

Thanks to Stuart in comments for pointing this article out.