Introduction

As you might now I started working quite recently for the startup Paycento. One of the things I am currently doing is setting up a system that allows us to do continuous integration and deployment everywhere and anywhere...

@ToJans Why write & maintain it if someone already solved the problem? (assuming something solves it). Spend time on competitive adv :)

— Simon Guindon (@simongui) May 18, 2012

As I got into an interesting discussion with Simon Guindon on twitter about the choice between a custom tool and an existing one like CruiseControl.Net for example, he suggested me to write a blog post about it. So here it is...

You are suffering from the NIH (Not-Invented-Here) - syndrome!!

So what! I get paid to write code, so I should not care what I write... or not ?

As a startup we have to make sure that everything we do provides business value, so why would one go to all this trouble to write his own CI/deployment system, if there are existing things available ?

More...

Finally !!

It has been a while since I blogged about my project #startup10, and there has been a reason for that... In the past months I have been talking quite a lot with a former colleague of mine, who co-founded a start-up, but on a whole different scale/level as my 2 utterly simple experiments.

After having to keep my mouth shut for over a month - which was, as for those of you who know me, quite hard -, I am finally allowed to tell the world I am joining the start-up www.paycento.com .

Paycento ? WHUT ? What's that ?

More...

Introduction

TL;DR: I managed to minimize the CQRS overhead even further.

Over the years, I have been trying to minimize CQRS in several iterations, even releasing a framework and a lib in doing so. Yet, I have still not been satisfied by the approach I reached. This time I once again am pretty satisfied with the way things turned out, and they actually seem to require even way less overhead...

How it works

The concept is quite simple: I use a generic message class to implement messaging. Next to this I use the virtual keyword:

• A class can contain virtual properties; these properties define the unique key of the instance. (f.e. an "Account" class has a "protected virtual string AccountId {get;set;}").
• When invoking a message on a class type, an instance is loaded where the unique key is loaded based on the match between the message parameters and the classes' virtual properties. A message only gets invoked if it contains all the virtual properties from the class.
• In order to alter state, one should use a virtual method.
• One can only send messages targetting non-virtual methods to a class instance.
• Non-virtual methods should never alter state, but instead call a virtual method that alters the state...
• When rebuilding state based on past events, only the messages targetting the virtual methods are invoked to rebuild the state; no messages are emitted.

Note: this is a post from a blog post series about starting up 10 businesses in a year.

Introduction

I love appharbour, in fact, I have 8 apps running over there at this moment. A little while ago, appharbour announced that they now have to start making some money, so that they were going to charge for custom hostnames...
I got a little dissapointed, since custom hostnames are an artificial limit, they do not add a lot of overhead to the system AFAIK, so why the hell would they charge for something like that??? I even was thinking about migrating my app to NodeJS, CoffeeScript and Zappa and switching to Heroku so I could have a free hostname, I even set up a poc to check the feasibility....

So I would have to pay 10€/month/site , and I do not have any profit yet...

And I want to build 10 different sites this year, so I would have to pay 100€/month just for custom hostnames, that is 1.2K€/year; for that price I can get a lot of hosting... So I posted them this message, and they replied that I could find other hosting for this price, but the service would be different...

I could use options like web forwarding or cloaking, but this looks highly unprofessional... Maybe there are other alternatives ???

I decided to let this issue rest for a few weeks and progressed with my first two startups (blommekes.be and dampen.be), updating them about umphteen times/day using a simple "git push apphb"... I could push fearlessly as I could just as easily revert to the previous version by the click of a mouse button... That is exactly one of the reasons I love it; they offer such a fine infrastructure... I even setup a simple staging environment by adding another apphb instance and a git remote...

Then I started thinking even more...

More...

Note: this is the first post in the series "Project #Startup10" : a blog post series about starting up 10 businesses in a single year. Here is a list of all the relevant articles:

• Introduction (this post)
• You pay peanuts, you get the monkeys
• Where we found our inspiration
• #1: Blommekes.be 
• E-Payment and logistics
• #2: Dampen.be -
• [This project has been put on hold]...

Introduction

I love reading about startups, lean product development, software practices etc... After spending over a decade studying a plaethora of subjects, I decided to finally put my money where my mouth is: this year I am going to put the theory in practice, and start up 10 new (or not so new, but different) business ideas, hence the tag #Startup10.

In the first post of this series I will give you a primer on my background, and also a few pointers to the things that inspire and motivate me; I hope they might inspire you too...

The **drumroll** "Big Idea" about a decade ago

The first thing I decided to build when I decided to quit my day job about a decade ago, was a single software product that would allow me to apply it to all kind of different problem domains, it required me to setup the database, and do little or no extra custom development. Little did I know that the software part was the least important of all...

Even though I did manage to sell a few user licenses at 1.5K, the product never really hit the market bigtime; here is why: I did not have a clue who my target audience was, so I had no idea how to market the product.

While the product in itself was not that bad, it was obvious that it was not going to allow me to make a living out of it, so I opted for the path most ICT-people opt:  freelance consultancy...

So one could say that this was actually my first startup attempt....

Enter 10 years later.... Project #Startup10

More...

Introduction

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.

More...

I am presenting for Visug on the 6th of march; it is a session about CQRS; here is the abstract:

CQRS 101 - All Your BASE Belong To Us

CQRS is a relatively new approach to software development in complex, distributed and/or asynchronous problem domains.

In the first part of this session, you will get a brief but pragmatic overview on the what, why and when using some examples. You will see how CQRS leverages BASE in CAP-theorem, and how this translates to the cloud. We will also touch some of the major advantages and disadvantages of this pattern, including applicability to TDD/BDD and NoSQL-like environments.

In the second part we will get our hands dirty by implementing some sample domain behavior, using one of the many possible CQRS approaches. You will see how CQRS really separates business logic from infrastructure, and that infrastructure in itself is practically interchangeable. Next to this you will also see how the combination with eventsourcing allows you to completely remodel historic data without a lot of effort.

Before the Q&A starts we will end with a small overview of the session, together with some practical tips on how you might use this approach today.

Unfortunately the session is sold out, but hey, if it is a success, I am confident more of them will follow...

Update

The presentation is over; 45 people; a great crowd and lots of interaction....

While I covered quite a lot of ground, I think the biggest remark was to show more concrete examples; you can find the slides here

I published the (cleaned up and bugfixed) example sourcecode on github.

Feedback/tips/Remarks ? Please let me know your opinions in the comments, so I can improve it!

Introduction

Over at a private LinkedIn newsgroup for ENTP personality types, somebody posted a link to "The Seven Habits of Spectacularly unsuccessful Executives". This is a great article, but not a lot of help IMO, instead of telling what not to do, one might be reversing the reasoning, and try to figure out what to do.

I posted this blurb in a comment on the newsgroup, and I figured I might as well post it on the blog as well...

Here we go:

The Seven Habits of Possibly Spectacularly Successful Executives

More...

Introduction

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.

Disclaimer

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.

Example

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

More...

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

Introduction

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.

More...