Riak is a very interesting Key-Value NOSql store. Built on the notion of combining many small, cheap parts for a durable whole, Riak loves and speaks the web. It is fault tolerant - to the point that a failed node is not an emergency. In this session, we will look at this extremely flexible database - what benefits it provides, what its drawbacks are and when you should consider using it. We will also look at how we can use it from our .NET applications. 

CQRS and Event Sourcing are two of the latest buzzwords in the community. In this session, we will look at what they are and what benefits they can bring to your applications. We will discuss different approaches that can be used to leverage these patterns. We will also discuss pros and cons so that you can make an informed decision as to whether these patterns are appropriate for your applications. Finally, we will look at a simple sample application – with all the plumbing needed in one 250 line .cs file that you can use for your projects with little or no modification. 

JavaScript is weird. Yet it is increasingly important. Not only limited to the browser, it can now be used for apps that run on servers, phones, tablets and even desktops. It has its own little world of weirdness that can catch you out when you least expect it. In this session, we will look at some of the idiosyncrasies that are all too easy to run into. We will see why they represent what can only be considered as strange behaviour. And we will look at what we can do to overcome them. You’ve seen the WAT, now here’s the why.

We all seem wary of waterfall – too much process with little actual code. Well, let’s think about what Agile is becoming? How much of Agile today is about process, process, process? Agile puts customer value at the top yet the Agile practices we follow seem to not. Bold statement? Think about it – if a customer requests a change, can we cater to it without saying “It’s not designed that way”? Are we afraid of adding things - or even experimenting - because of the numerous tests that we will have to maintain? Do we spend time building up automation to the point where weeks go by and the customer sees nothing? Do we have technical tasks the business has to pay for but doesn’t understand why they’re doing so? All of the steps in agile that we follow have costs associated with them. And in many cases, those costs have become part of the Agile process that in many ways go against a lot of the agile manifesto. In this session, we look at some of them. And kill some sacred cows in the process.

All too often large models are used to represent application data. And layers of abstraction used to prevent the emergence of what is known as a Big Ball of Mud. People use things like repositories, services, IoC containers and other strange mechanisms for even the most trivial applications – all in the name of avoiding that ball of mud. And this pursuit takes considerable effort. The teams have to deal with complicated versioning problems and often this leads to massive rewrites of entire products – thus negating the very reason of loose coupling. Can we not avoid this? And are balls of mud really such a bad idea? Can we not have architecture that lives on rather than dies every year or so?

Many of you who have dipped their toes in functional programming may have heard of an obscure term called Monads. While they are used frequently in functional languages, the idea is actually a mathematical concept. And the same idea can be used in mainstream languages as well (be it will a little less syntactic sugar). The main roadblock in understanding monads seems to be the requirement of knowing a functional language well enough to follow through the description. This need not be the case. In this session we will look at what monads are, and use them in commonly used languages like JavaScript / C#.