Installing and compiling Elixir and the Dynamo web framework on Windows

by Tom 9. June 2013 01:57


People following me on twitter noticed I got entangled in yet another new language for the Erlang/BEAM VM: 

Elixir could be easily described as "ruby for the BEAM/Erlang VM". In previous posts, I mentioned why people should learn Erlang, but in fact, I think most people might be better off when they skip Erlang and opt directly for Elixir. It has all the advantages of Erlang, but offers a Ruby-like syntax, macros, polymorphism and more.

As someone else made a perfect blog post on why you should learn Elixir, I will not elaborate further on it in this post. Read his post; the info is all there.

As usual, you can find more info about Elixir on Wikipedia , or on the Elixir site.

In this post, I will show you how to get started with Elixir and generate a template website using the Dynamo web framework.

Installing Elixir is simple, but because one of the Dynamo web framework dependencies requires the make tool, you need to do some extra work. If anybody finds a better/simpler way to do this, please let me know in the comments.


Erlang 101: an attempt to implement CQRS

by Tom 5. October 2012 04:03


As you might have noticed in one of my previous posts, I am currently focussing on Erlang, because I assume that this platform might be the most efficient way to handle umphteen connections over the web for now (but that is the subject for another post).

After running my first experiments and getting everything up and running on Windows, I finally decided to stop fighting usage of windows combined with Erlang so I installed myself a virtualbox with Lubuntu LXDE (please note that you have to set the available memory on the virtual appliance to 512MB, or the installation will crash).

Before I start implementing what might be my next startup, I tried implementing one of the things that I consider to be my personal kata (I made numerous attempts in .Net): a CQRS implementation of a simple stock system.

Disclaimer: I am a complete newb in Erlang, so I presume I am still miles away from a more elegant implementation.


HAxxors: Use SQL Server as a NOSql DB

by Tom 23. February 2012 07:05


I was in an environment where I only had SQL Server available, but I really wanted a key-value store, so what did I do:

Use SQL Server as a Key-Value store - Major Haxxors

In order to be a proper key-valuestore, one would need to add the ability to do searching etc, but as this was only a quick hack where I did not require the search, I did not implement it.

In case I would have implemented a search, I probably would have used something like Elastic Search.


CQRS for the lazy -ss

by Tom 15. January 2012 05:36


In one of my numerous attempts to create a neat approach to CQRS, this is yet another attempt to remove all the protocol that CQRS requires. I love bootstrapping new projects and experimenting with new approaches, and this is another step that improves efficiency. It is a natural evolution to one of my other CQRS playgrounds: Scritchy.

The conventional CQRS approach requires you to write command - and event classes, to wire up your commands and event handlers to the relevant AR's, saga's and viewmodel builders.
I removed some of the clutter in that process with Scritchy. Scritchy uses conventions to wire up the commands and events to the relevant components. This makes CQRS a lot less verbose while still offers the same advantages.

Scritchy v2 ?

While this is a good attempt, it still requires you to write the dreaded event - and command classes. Having pushed some best practices/usages/libs to some enterprise teams in the past, I noticed the following: any change that adds extra steps/work to the process makes acceptance harder by devs, as most people are usually trapped in a certain approach, and they do not see an advantage in having to write more code to do the same thing. If they do not need to write all the "protocol"/extra classes, you have removed yet another step that might slow down acceptance of the practice.


The new approach I am about to tell you about in this blog post completely hides the messages from the dev, i.e. the dev can just use a conventional method call, and messages are created underneath.



This is a possible approach to the problem, but I tend to think that the majority of the CQRS evangelists and practitioners value explicitness over pragmatism. I love the explicitness and clarity of their examples and implementations, but in the real world most people start to think: "Wow, that is a lot of code to simply add an item to the stock; are they nuts ?".

Having experienced the fallacy of the explicitness in a startup attempt, my brain got tickled to find fast and neat approaches to a pretty established conventional path. I think this one is pretty close.

The full source is available over at GitHub, and the demo app can be seen/tested over at appharbor.


So without further ado, here I will show you ALL THE CODE required to implement a complete CQRS app:


2010 - 2011: A retrospective

by Tom 27. December 2011 04:25

One of my main motivators, my youngest son Matisse #PrideAndJoy


I like the concept of retrospectives; it makes you self-reflect and think about the paths you followed and want to follow in the future. As it has been 2 years ago since my latest retrospective, I think doing a post on it right now might be a good idea.


Continuous thinking: CQRS explained to a 10-year old

by Tom 28. November 2011 03:20


The concept behind CQRS is neat: detach your domain implementation completely from your representation requirements. I even wrote a framework for it as a learning tool, so somebody without any prior experience should be able to boot a CQRS app in a few minutes.

The main idea behind this framework is providing developers new to CQRS an operating room where they can compose their own little CQRS Frankenstein app.

The whole framework is constructed in a way that it forces you to make your domain implementation completely persistence ignorant, respecting typical AR/transactional boundaries.

Scritchy is not "the framework to write CQRS apps"; Scritchy is a framework that tries to provide you a learning platform where you can start grasping the basic principles, advantages and disadvantages in using CQRS.

Once you understand the basic principles behind the CQRS setup, and why everything is setup the way it is, I would advise anybody to gradually replace parts of the framework and just opt for whatever approach you like, using proper message busses, pub/sub/... 

If you write your app following the conventions Scritchy dictates, the only thing you need to change to remove the Scritchy dependency is the base object your Aggregate Root inherits from; that is the only dependency that is ever necessary in you app implementation. This was by design,to make future migrations as easy as possible.

I wrote this framework to enable a dev new to CQRS to get his app up and running in a few minutes... But apparently that is not enough....


Quick tip: How to do TDD/BDD and debug unit tests with Visual Studio Express editions

by Tom 25. October 2011 07:47


This article will show you how you can do TDD/BDD with Visual Studio Express editions. While most people say it is not possible, it is actually pretty easy.


How do you do it ?


Scritchy: CQRS without plumbing - a preview

by Tom 21. October 2011 17:02


CQRS is one of my architectural pet peeves, as you might have noticed from the numerous amount of blog posts I made on this subject. However, I noticed the concept is complicated and hard to grasp for newcomers to CQRS. I have been spiking numerous attempts of a framework that makes CQRS both more manageable and understandable, failed hundreds of times, and even published a few of my acceptable attempts as gists over at github...

A few days ago I was messing around with SignalR trying to setup again another CQRS attempt, and failed miserably.... However, 2 nights after that approach I had an ephiphany which had been lingering around in my head ever since.

Today I decided to get back to business, so this afternoon I started spiking a proof of concept (POC).

I think you will be happy to see that I managed to get most of the annoyance out of CQRS with this simple concept.


Continuous thinking: Nerdbeers continued - We all win !!

by Tom 16. March 2011 14:40

Note: this post is the successor to the previous post on NerdBeers; if you have not read it yet, you might want to browse through that one first in order to have some context for this one.


The initial development on the Nerdbeers app was started about two weeks ago, and I never imagined it to be such a big thing really; I just wanted to build a small app to prove to myself that I could write an app without falling in the usual architecture trap.

But things evolved quite a lot, or, to quote a famous book:

"Opportunities multiply as they are seized"
Sun Tzu - "The Art of War"

I will try to give you a short overview of the key things that happened in the past two weeks.


The components matched perfectly

As I had been reading around on the web about Manos, Kayak, Massive, lean software practices, getting things done, ..., I was looking for an opportunity. The main focus point for me was avoiding protocol/boilerplate code, and thus having as much functionality as possible while writing the smallest possible amount LOC (Lines Of Code)  .

The minute I saw the Nancy web framework at github I knew that this would have to be it; it had such a nice and clean syntax, and it was similar to the thing I had been thinking about building myself. After one of the main coders provided the idea of reimplementing nerddinner, I just started implementing it.

Doing this, I did notice that I needed some kind of a data access layer as wel. Looking for the ultimate LOC/efficiency, I opted for the relatively new Simple.Data, which looked like it was the tersest possible approach possible to data access for me.

They matched perfectly !


The components were really young OSS projects

Since both of the components were still in an early development phase, they were bound to have at least some bugs, so choosing a relatively new player on the block might seem like a stupid mistake to make, but in my opinion this was one of the best decisions:

By choosing very "young" open source projects, 
the contibutors were all willing and able to help me out
with my newbie issues in a very direct way.

Think about it: if you use a mature open-source component, the OSS contributors get flooded with support requests, and are probably being asked the same questions over and over again. If you choose a young project, the authors will probably notice your questions, and they even might be able to help you out directly.

While I was hoping for some help, I never expected such a massive amount of response.


The component authors all contributed a huge amount to the NerdBeers project

What happened here was WAY beyond my expectations: next to getting almost instant help from all the component authors over twitter, they even started looking at my code, telling me what could be improved, and they even launched a few pull requests.

Most of the "bugs in their components" were actually bugs in my app due to my malpractices, but they were always there to help me out.

They also liked the fact that Nerdbeers was an implementation which showed of the results of their labour.

After a numerous amount of tweets with @GrumpyDev, @TheCodeJunkie @MarkRendle and others, I finally had an app boilerplate ready.

Next to this, someone from appharbor (@troethom) helped me to resolve a "bug" in my solution so that I could deploy the app to a demo website (for free), and the maintainer of AutoTest.Net (@AckenPacken) was there to help me after a tweet, even though I just made a stupid mistake (using the wrong MSpec runner).


The NerdBeers development team - a.k.a. "Wow, it really does happen!"

Here is a confession:

Without all those brittle minds, this would never have happened.

I have had projects skyrocketing in the past during my professional career. IMHO the usual way to get this happening is following these steps:


  1. Think about an idea
  2. Care about it, grow it, be passionate about it
  3. Set an initial target: both in scope and time
  4. Start implementing it
  5. Ship it at the time you planned it - really early, no matter how bad it looks, even if it does not have any true functionality yet
  6. Get other people passionate about it, and try to trigger their intrests
  7. Go to step 1, hoping to have at least triggered the interest of a few persons who might join you in the process later on
If you want this to happen, I can tell you one thing in advance: it will be hard, you have to be really persistent. You will have to take shortcuts, make some tough decisions, and be prepared to take the blame. It also requires some experience in team lead, group dynamics, NLP, management techniques, sales techniques, especially for step 6.

If you manage to pull this off, you will notice that the team's interaction augments the individual team members achievements to a new high.

For Nerdbeers, step 6 happened naturally; it did not take any effort at all. Agreed, there was some persistence required for the first steps, and sending out a version like this might have even damaged my "being professional about software architecture" (LOL), but at least I got something out there.

Here is what happened: the people started caring. No effort from my side was required at all. Those people influenced other people, and those might actually influence other people. All by themselves, no extra effort required. While this might not be a "traditional" software team, I would still call it a team. Agreed, we communicate over twitter, instant messages, github, without having any real contacts, or even some kind of direction, but everybody cares and takes his responsibility. Which is great, especially so soon in something so small !!

Conclusion & things to consider

After two weeks in the project, we have progressed a lot. We still have a long way to go, but I am confident that we will get there. For me the journey is more important than the destination, and I have had a very interesting journey already. It kind of makes me wonder on the path that lies ahead of me. 

The app in itself is still pretty useless, but the real value is in the way it has been constructed, both technically and on a social level.

This experience also makes me wonder about the future of software development teams. As far as I know, everyone on the N-team has day jobs. We do not share a common language or country. Yet, we still manage to be quite effective in handling problems quite efficient.

This makes me think about my future projects. As a small ISV, I currently have to turn down some projects, because they are to big for a single person. Working like this makes me wonder whether I might be able to take on a bigger project, working in the same way as we did on the NerdBeers team, with people whom I trust from previous experiences. We could sit together in an office, but we would not need to.

Maybe that's what work 2.0 will be about: a truely global work environment in the comfort of your own home.


Signing off,



Bookmark and Share

Continuous thinking: just ship it - the story of NerdBeers

by Tom 7. March 2011 18:24


This is the first in a series of posts :

  1. Continuous thinking: just ship it - the story of NerdBeers (this post)
  2. Continuous thinking: Nerdbeers continued - We all win !!
  3. Continuous thinking: Nerdbeers - Providing business value by issue tracking


Ok, I will admit it: I am a software architecture junkie. I love thinking about it, and try to use it in every app I can. I am an avid fan of CQRS (more info here), and I try to use it as much as possible.

Next to this, I am also a very big fan of BDD; to me it feels like there is nothing that even comes close to the process of describing a problem domain using the example stories.

I spend a huge amount of time on reading as much relevant articles as possible, joining discussions in newsgroups, on blogs. This has provided me quite a broad knowledge about software approaches one should use. (Think SOLID,BDD. ...)


Ok, stop bragging please, what is your point here ?

A while ago I got together with someone on a new idea (yes Geert, I am talking about you). We talked it through and started prototyping. So I set up a basic project, and built a CQRS architecture in order to get started, so we would have better scalable/testable/more maintainable code. In the mean time, the other person had already started prototyping, so I spend a few days converting his ADO code into a more appropriate model for CQRS, and convert everything.

I heard about the latest version of enitity framework, which had a code-first approach, and since I had been using fluent-nhibernate in the past for view storage, I decided to go for the new player on the block. Unfortunately, the EF apparently did not support Enum storage, so we had to adjust about 80% of the viewmodels.

After migrating everything, it seemed like the other person was implementing code in the wrong places. He has always been a DAL/ORM kind of person, so the whole CQRS thing was really confusing to him. (which is completely normal; cqrs requires a different mindset than CRUD, and I did not take in to account the rather steep learning process I had made in the past).

I can go on and on about this, but to cut a long story short, the project was temporarily postponed to an undefined later date...

I also quit another project like this because I lost intrest in the project while building up the whole required architecture setup and a few basic screens.

So a lot of effort resulted in ... absolutely nothing


Fast-Forward to a few months later

As time progressed, I read even more about architecture, learned some new frameworks on the way, and tried out a few things from which most did not even get to a usable phase. My software hobby projects were all seeded quickly, but abandoned even more quickly.

Until I read an article on the blog of Matt Mullenweg. The one phrase that kept lingering around in my mind was this one:

if you’re not embarrassed when you ship your first version you waited too long.

Wow! That is a strong statement !! So I decided that my next project would respect this statement; I was just waiting for the perfect opportunity to come along


And there it was...

I discovered NancyFx, a .Net web framework loosely inspired by the ruby/sinatra approach, as well as Simple.Data, which one can compare to the ruby ActiveRecord approach. If there is one web platform that is known for it's productivity, it has to be RubyOnRails. So I decided to give it a go, and merge the two in a new project.

As I was looking for an idea on an app to implement, @grumpydev told me he had been thinking about trying to implement something like, but maybe a bit more limited, and that I was free to try it.

So I came up with NerdBeers

After taking a few hurdles (cloning the NancyFx git repo,installing ruby, building, installing sqlce, building, installing F#, building, cloning the repo, building it, finding an SQLCE editor, finding a Migrator.Net that supported SQLCE 4.0 and building it), I started a basic web project, where I had an index screen showing all upcoming nerdbeers and the possibility to add a new one, and a details screen where one could edit a nerdbeer.

I ditched Migrator.Net, since it was making things to complicated at this phase of the project.

I published it at github, tweeted about it, and got some very enthousiastic reponses from the creators as well as from the community, even inluding some people whom I consider to be impossible to reach...

As I published my sourcecode to github, I was thinking about my idle appharbor test account that I requested a few weeks before... Continuous deployment is required if one wants to approach lean development.... So I started hacking/reading/making stupid mistakes. Luckily the people from appharbor were there to help me, and pointed out what was wrong.

So after a few attempts and sleepless nights, I had a pretty useless app online, but it looked kind of cool due to the tersness of the code.


NerdBeers... The story continues

Since I got so much positive responses to an app which was basically an empty shell, but showed a lot of potential, I was motivated enough to start hacking together something usable. After trying out a few things, checking out the Nancy sourcecode and bothering @GrumpyDev, @TheCodeJunkie and @MarkRendle with all my noob questions, I finally got around to publishing something usable - allbeit in a very limited way - .

It still looks ugly as hell, but I am a developer, not a designer. Strings are being pulled currently to help me out (=replace) the design.



For me, this approach was WAY OUT of my comfort zone, but apparently it does work... If I take out the time to build the libs and workaround the bugs, check the source, bothering people about it, I have published a usable app in about a day...

It still looks really ugly (both the design and the code), but it works in a very basic way. I also cut out every possible feature not needed (i.e. currently one does not even have a login), so I would be able to ship it fast. And I have to say it worked: the short cycles kept me productive/motivated, and the small featureset helped me to focus on what was really important.So I did ship something !!

As the libs for NancyFx and Simple.Data progress, we will get a very mature platform which will enable truly lean development.

You can see the demo application at

For me this has been a valuable lesson, and from now on, I will try to respect these principles more and more... I hope you found this an interesting read, and if you have had a similar experience, do not hesitate to let me know...


There is a followup post here.

Bookmark and Share

About Tom

     Tom Janssens op LinkedIn    Tom Janssens op twitter   Core bvba RSS

I build software and help organisations to get better at building software.

If you would like to know more or meet up, just give me a call at
+32 478 336 376.

More info about Tom and his company...

Tom's resume


<<  April 2014  >>

View posts in large calendar