In the era of JavaScript it's a good idea to support users that aren't getting JavaScript enhancements, specially if you work for UK's goverment. If you are using simple forms you don't have any problems, but as long as you start adding complexity to your page supporting this scenario can be a bit tricky. Obviously your first thought should be: "Can I provide a similar experience using a less complex view?" The answer to this question could be splitting your view in different steps, but you should talk with your team's UX expert, Business Analyst and Product Owner to see if this solution is acceptable. In this article, we'll see a couple of techniques to deal with this situation if you are only allowed to use a single view.


Imagine that you're developing a recipes website, where the user can add her own recipes. One step of this process is to add the ingredients needed to cook the recipe and you're asked to provide a search for the ingredients, the option of add to your recipe one of the search results, specify de grams of that ingredient used in the recipe and the option to remove one of the ingredients already added. You've developed the version that uses JavaScript with the last framework in the market, and now you need to develop the non JavaScript version of it. Let's start.

[caption id="attachment_286" align="alignnone" width="300"]Application Application[/caption]


Multiple buttons in a form

The first challenge you will face is to have multiple buttons in a form. As you know, you usually have a submit button in a form, but in this case we should have more than one. This is a problem well solved by ASP.Net MVC by using a derived type of ActionNameSelectorAttribute.

Here you can find a possible implementation of this attribute:

As you can see, basically what we are doing is checking the value of the button is the same than the name of the method in case the action was triggered by a button with the name specified in the SubmitButtonActionName property.

To use this attribute we need to make changes in both the controller and the view. Let's see both changes and I will explain them later:

As you can see, in the view we are setting the name and the value of an extra submit button. In the controller we should decorate an action with the MultipleActionButton attribute, setting the SubmitActionName property with the same value that we've specified in the name attribute of the button. The name of the action must be the same as the value of the value attribute of the button.

Passing parameters

In our application, we need to tell our backend what ingredient we want to add. Using the previous attribute is not enough, unless we want to end with a lot of actions doing the same thing (wich doesn't seem a very good idea). So we need to somehow pass a parameter to the controller, telling it with ingredient we want to add from the results search or we want to remove from the list of ingredients. Here we have to be more imaginative and combine an ActionNameSelectorAttribute with an ActionFilterAttribute. Let's start taking a look at the view:

What are we doing here is creating a value of the button like UseIngredient-0 for the first item in the list, UseIngredient-1 for the second one, etc. If we do that, we can no longer use the implementation of the ActionNameSelectorAttribute recently explained because we'd need an action called UseIngredient-0, an action called UseIngredient-1, etc. So, we need a new implementation of the attribute that extracts the real name of the action. Something like this:

Basically is the same code than the previous implementation, but we remove the parameter information before doing the comparison.

What problem do we have now? Well, right now our actions don't know anything about the parameter, we need to do something to pass the parameter to the action.

ActionFilters to the rescue

An ActionFilter is a mechanism to add custom behavior before or after an action is executed. In our case what we want is to inject the value of the parameter in the action. To do that we can write an ActionFilter like this one:

In this piece of code we are retrieving the original value of the button which triggered the action (line 11), extracting the value of the parameter (line 12), converting the value (a string) to the appropiate type (line 14) and injecting the value into the action (line 15).

Finally we just have to appy this filter in an action using the appropiate values:

Wrap up

In this article we've seen how to use different buttons in the same form and pass parameters to the controller without using any kind of JavaScript. Remember that if you want to use some code when JavaScript is not enable you can use the noscript tag. You can find the source code in this github repo.


Yesterday I attended XPDay 2015, an event organized by the people of the eXtreme Tuesday club. It was the first time I was there and it was great to share a day with such a bunch of talented people like Allan Kelly, Nat Pryce, Steve Freeman, Giovanni Asproni or Liz Keogh among others.

In this time where a lot of people talk about agile hangover and say that agile doesn't work it's good to return to the origins and talk about eXtreme Programming.

The event started on Monday where they started to configure the agenda (I couldn't be there). Hopefuly they reserved some time on Tuesday to propose more talks. The format of the event was an Open Space.

I started the day attending a talk about UX and agile. We started defining what is UX and the difference between UX, Design and Usability. Then, people exposed how they work with UX people, how are they integrated in their teams and how they decide the next feature to develop. Jasper (the host) ended drawing an interesting funnel describing the different artifacts using in UX.

[caption id="attachment_280" align="alignnone" width="300"]UX funnel UX funnel[/caption]

I continued with a session called "Strategies on identifying domain models on legacy databases", proposed by Sabrina. Sabrina explained the current situation in her company, where, after merging with another company, they've inherited a legacy codebase which must be maintained and evolved, and they struggle on identifying a domain model from a bunch of databases not very well designed. We ended up with a list of things they can do to soften this (probably painful) process, that contains items like: identify the seams, use test environments, define characterization tests, look at changes on the outputs when introducing an input (and invest in tooling to automate it), monitoring usage, make a complete rewrite.

I've explained briefly my last work at Skills Funding Agency, where we are replacing an old system with a new one, how we keep the data on both systems synchronised and how both systems were alive at the same time for some months.

This is the kind of sessions I love to see in an Open Space where the host, instead of trying to explain a topic, asks for help. I hope Sabrina took some useful ideas from the session.

My third session was about thinking out of the box talking about how the product manager and the delivery team can work together. We started defining what is and what isn't a product, and we talked about how can collaborate to make a successful product. I didn't get too much from this session, but probably it was because the session was just after lunch. :-)

After that I attended a session proposed by Monika Turska about unhealthy products and how can we get rid of them. It was an interesting session where we talked about what we think what an unhealthy product is, things to consider when deciding if we have to abandon that project, and how can we do that. It's an interesting topic because as a company developing a portfolio of products you can lose a lot of money extending the live of some of them.

And finally I attended a session proposed by Giovanni Asproni called "Where has design gone?". Giovanni explained that some years ago people talked so much about architecture and design (upfront design, yes) and now people are not talking too much about design, and a lot of applications and codebases suffers from a lack of it. Some people mentioned that we are too focused on deliver features and we are going too fast to be able to think on design. Some people mentioned that we are skipping the refactoring part of TDD and that we've forgotten the meaning of the last two Ds. And some people mentioned that some frameworks like Rails maked those kind of decisions for us and we only have to fill in the gaps. Finally a couple of talks were mentioned: Simple made easy, and Java the unix way.

I had a great time at the conference, I'll try to attend some of the eXtreme Tuesday meetups and I hope I can be part of XP Day 2016.

The #NoEstimates movement is an interesting thing. If you haven't heard about it, take a look at #NoEstimates hashtag on Twitter, read these articles from Ron Jeffries (article 1, article 2, article 3) or buy (and read) the excellent book written by Vasco Duarte.

Let me make a summary for you: we fail making estimations. A lot. Take a look at famous CHAOS report if you need more evidence. Agile methodologies improved the numbers a bit but not too much (I bet the numbers are going down again because everybody is "agile").

Failing making estimations is not bad per se. The problem is the use we give to estimates:

[caption id="attachment_274" align="alignnone" width="502"]Estimates as deadlines Estimates as deadlines[/caption]

And we usually do that when we know less about the project: before even starting it. Before starting a project maybe we have a good definition of the most important stories, but the others can be vaguely defined (which is good). So we should be able to estimate with some precision the first and most important stories of the backlog (which we already know we must implement), and we will produce very bad estimations for the vast majority of the backlog. Why are we estimating then?

There can be multiple answers to the previous question: we need to know if you will be able to do the job within the budget, we need a release date, etc. And all of them are fair. But the problem is that our answer is just a guess, it is not based on any empirical data. You can claim that you are an expert project manager with more than 15 years of experience, but you have to admit that this is the first time that you're developing this project for this client with this team.

Don't our clients deserve a better answer? Yes, of course. Why don't we use real data from the project to answer these questions? Why don't we talk with our client and ask to work on the project for three or four sprints and use that data to make a projection? Why don't we work on splitting stories in order to make them similar in size and avoid estimating and just count them (and increase our knowledge about them)?.

It sounds quite reasonable to me.

My main conclusions are the following ones:

  • Question all your practices. Estimations, retrospectives, testing, daily meetings... all of them. Are the practices giving value to you and your client?
  • Build trust with your client. If your client trusts you, probably you won't need estimations.
  • Work on slicing stories. Estimate them after doing it if you want, but you'll gain knowledge about them, and about your domain if you do it. You'll be able to deploy them sooner and shrink the feedback loop.
  • Use real data to make predictions. Real data beats guesses. Always.


In the first post of this series we've seen a possible implementation for the FizzBuzz kata. In particular, we've finished the article with this code for the fizzBuzz function:

We've applied a Tuple pattern to match the tuple created in the match part. We've also applied Wildcard matching to discard the values we are not interested in.

In this article we're going to see how we can solve this problem using another flavors of Pattern-Matching.

Active patterns

Using active patterns you can define case names (partitions of your data) so that you can use these names in Pattern-Matching expressions. A typical example could be this one:

So let's use active pattern to resolve FizzBuzz kata. The active pattern could be something like this:

As  you can see we have an active recognizer that defines four cases. Inside the recognizer we're using Pattern-Matching to select the appropriate case as we did in the original implementation of the kata. Now, we just have to use this recognizer in a Pattern-Matching function:

As you can see, we are using a Pattern-Matching function, a convenient shortcut for creating a Pattern-<atching lambda expression. We are just replacing the match...with portion of the match expression with function.

Now, if we would like to print the first 100 numbers we can do something like this:

In this case we are using a range expression to create a sequence with numbers from 1 to 100. Using the pipe forward operator we are passing this sequence to the map function of the Seq module that transforms a sequence applying a function (in this case fizzBuzz) to every element in a sequence. Finally, we iterate over the sequence to print the results.

Partial Active Patterns

Active patterns have to limitations:

  • Each input must map to a named case.
  • Are limited to seven named cases.

An alternative to active patterns are partial active patterns. A partial active pattern include only a single case name followed by an underscore. Let's rewrite the FizzBuzz kata using partial active patterns.

First, we have to write the active patterns we are going to use:

And after that, we are ready to use them in a Pattern-Matching expression:

Parameterized Active Patterns

It's possible to use a function that accepts more than the match value. Let's define a Parameterized partial active pattern (remember to include additional parameters before the match input argument.

And now, let's use this partial active pattern:

And that's all for today. All these samples are extracted from the excellent book The book of F#, so I can't recommend it enough if you want to learn F#.

As usual, I'm just learning F#. If you see something incorrect or you want to add an alternative solution, please leave a comment.

Last week I continued learning F# with my friends Samir and Pedro. The first week we learned some of the F# basics and this week we learned some of the functional characteristics of F#. To do that we started doing a custom interpretation of the Bank kata from Sandro Mancuso. You can find the code here:

As usual, let's start with a test an its implementation:

In this piece of code we can see some of the functional characteristics of F# we are going to see in this post. The first one is Discriminated Unions. Discriminated unions are types whose value are restricted to a known set of values called union cases. These cases are the only valid values. In our case we are defining Currency as a discriminated union. One of the most used discriminated unions is the Option type, present in the F# core library:

Option is a type with two possible values: Some and None. None is an empty union case (doesn't contain any associated data). Some has an associated instance of 'T. It's something similar to Maybe pattern in C#.

Using Option type is quite simple:

We will an example of how to retrieve the value of an Option, but it's as simple as:

The second functional characteristic of F# we can see in our little piece of code is a record type. In our case, we used a record type to define what is an account. A record represent a simple aggregates of named values. It's a kind of type between a tuple and a class. To define a record type enclose between braces a list of labels with type annotations. A simple record type can be something like this:

So, in our example we are defining an Account as a record type that has a label called Amount that is a tuple of int and Currency.

Let's take a look at the deposit function's code after another test and a refactor:

Here we can see how type inference and pattern matching (tuple pattern) helps us to have a more compact code. First of all, instead of defining the last parameter of the function as an Account, we can use definition of the record type. Doing this, we can use tuple pattern to extract the values of the tuple and use them inside the function. In our case, we don't care about the second value of the tuple, so we can use the wildcard pattern (_).

Let's take a look now at the final implementation of the withdraw function:

In this piece of code we can see another flavor of pattern matching. In contrast with the one used in the previous article, here we can't use directly the values calculated in the match part to define our cases. We have to use the values to compare with another value, in this case 0. To do that, we use the keyword when, specifying the condition after it. In the second part (when the first case is false) we get the calculated value and use it in the return.

And finally, let's take a look at the codification of a global operator we use to chain withdrawals:

As you can see, you define an operator just like another function but with the name of the operator enclosed in parenthesis. In our case, the operator |>> takes two parameters called result and f. You can annotate the type if you want but there's no need to. In the body of the function we use pattern matching to determine if the first parameter is a Success or a Failure. If it's a Success we called the function f with value as its first parameter and if it's a Failure we return the failure.

And that's all folks! We are just learning F# so, if you find something that is not correct in the article, please, leave a comment!