Are new `.js` ui frameworks and - libs a fad?

Good question! TL-DR: Most are, except: jQuery React vue.js Frameworks - not for me! In web UI, frameworks like BackBone, Ember and Angular might be all nice and stuff, but when you start using them to compose larger applications, things tend to break down quite easily with less experienced developers. Developing large client-side applications requires the same modelling skillset as developing large server-side applications; the complexity is usually not located in the infrastructure, but in properly mapping boundaries and responsibilities within your solution space.

Foldable for non-Haskellers: Haskell's controversial FTP proposal

In the Haskell world, there is currently a big fuss about the “Foldable/Traversable in Prelude”-proposal. Edit: For the record: it was a proposal, and has been implemented in the current version of Haskell (GHC) As a non-Haskeller, you probably wonder what all the fuss is about. First things first: some context In most languages, you have functions to iterate over a sequence / array / iterable / list, for example in C# (assuming we have an array called values) int[] values = new int[] {1, 2, 3}; foreach(var v in values) { Console.WriteLine(v); } In Haskell, we usually refer to an sequence with a list, and the example code would look like this: values = [1,2,3] mapM_ print values Let’s say we need a function that concatenates several sequences of the type a.

Hangman in Haskell

As I noticed a question for a more idiomatic Haskell version of the game Hangman on, I decided to give it a go; this is the result: Note This article has been posted on Reddit’s Haskell channel, and gradual improvements were made on this article based on tips in the threads, so feel free to check these. Tips Most idiomatic Haskell code I see has a very high signal to noise ratio.

Selling DDD

A little while ago, we gave a series of short talks called “DDD Basics” for the Belgian Domain-driven design community. The focus was on strategic design. < shameless self promotion > I got some awesome feedback on my part: @ToJans @DDDBE I really loved your talk last night ?? — Tom Marien (@Tom_Marien) 12 februari 2014 @ToJans @DDDBE no remarks, it was perfect, inspiring and motivational — Tom Marien (@Tom_Marien) 12 februari 2014 </ shameless self promotion > My session was about selling DDD, and while the slides can’t show you how much interaction there was, they do contain the gist of the ideas, so I decided to post them to my blog anyway; enjoy them!

Why bad software architecture is easy to monetize

This morning I received yet another “interesting” job offer, which looked like this: Wanted: "senior .Net architect" Description "build one framework to build all future projects, using sharepoint" #ThanksButNoThanks — Tom Janssens (@ToJans) 17 februari 2014 Building a single framework to rule all your customers is just plain wrong. I did it in the past and now I know better. Why do a lot of consultancy/web shops do it then? Let me tell you a story … About someone building a house… The project You would like to build a house.

The very first #DDDBE event: the modellathon

This is my personal review of the @DDDBE inaugural meeting: a modellathon. Some background info So, last night we had the very first event of the Belgian DDD community: a modellathon facilitated by Mathias Verraes and Stijn Vannieuwenhuyse, and kindly hosted by the hosting company Combell. For the people who do not know the concept of a modellathon - in fact, I think we might even have invented the term maybe, but I am not quite sure -, it was something we spiked like a while a go, while coming back from the London DDD Exchange: As we were sitting together on the train with some of the #CQRSBeers guys, we considered starting a Belgian DDD community, and having real workshops.

My #CQRS cookbook

Here is my personal take on how I interpret all things CQRS… Commercial impact: why use CQRS ? CQRS enforces you to apply strict boundaries to your app in a consistent way. These boundaries convert your single application into 3 separate parts, only coupled by commands, events and queries. By using CQRS you convert your single app into 3 apps who can be built in parallel. So basically, when you do have enough resources, the approach can decrease your time to implement something by a factor of 2.5 (estimate, 3 times - 0.5 for the common interfaces - commands, events and queries).