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...

We zitten in de problemen in ons landje; hoe zou U als ondernemer het probleem aanpakken ? #BeterBelgie

Het geld is op, de mensen komen op straat, er is schrik voor de economische malaise en verdere implicaties er van, ...

Als ondernemer zit U dagelijks in gelijkaardige situaties: uw acties hebben niet alleen impact op producten en bedrijven, maar ook op mensen in een directe of indirecte manier. Bijgevolg heeft het merendeel van U een soort van zesde zintuig ontwikkeld om dergelijke problemen op te lossen.

Daarom wil ik aan U als ondernemers vragen: welke suggestie heeft u voor de overheid ? Hoe kunnen we de problemen in dit land op een pragmatische en efficiënte manier gaan oplossen? Ik vraag dus geen gepalaver vanuit de ivoren toren, maar concrete en uitvoerbare oplossingen die het verschil maken.

More...

Introduction

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....

More...

Introduction

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.

More...

Introduction

What MBTI personality type are are you ? If you do not know, I would suggest you find it out (I did it here, it only takes a few minutes).

I did it, and it was an epiphany. Apparently, I am an ENTP. For years, I felt like I did not know anybody who had a personality similar to mine. Now I do, and I found some great online discussion groups all populated with aligned personalities.

In one of those threads, we had a great discussion on how your personality influences your professional life.

Enough off-topic blahblahblah™, time to get to the subject. In the mentioned discussion thread, I gave away my "secret sauce of great leadership - IMO ;) -", just like that, for free... As I received some great comments, I was thinking: "Maybe posting this to my blog might be helpfull for some readers as well". So I did.

Unlike most of the stuff the Oracles out there are spreading, it is not some kind of a magic formula, on the contrary: it is hard work. It is also small and coincise; there is no need to overcomplicate things.. This is my personal approach. I use it all the time, and it works for me. 

So without further ado, here we go; this is my personal ...

"Secret sauce of great leadership - IMO ;) -"

More...

Note: this post is part of a series; you can find the first post here.

Introduction

Well, another 14 days passed by for the NerdBeers project, and a lot has happened:

• @Grumpydev added a proper design
• I did some major refactoring in the FailingSqlite branch, which will allow us in the future to have full integration testing available for doing proper BDD (or top-down TDD, if you prefer to call it like that). Unfortunately this branch is still pending for integration due to some problems.
• I got some followers/forks over at github (Yay!!)
• Some more people offered to help me out
• Both @MarkRendle and @NotMyself progressed a lot with both Simple.Data and Simple.Data.SQLite
• Spring started; I enjoyed the sunshine outside with the kids and the Mrs.
• Social obligations
  • My brother in law's house renovation deadline is approaching
  • My brother's birthday party
  • Lots of catching up with some friends
  • ...

So Nerdbeers has not really changed a lot ? Are you lamenting ???

No, in fact I am not, I spent quite a lot of time on trying to get the "FailingSqlite branch" going, but unfortunately I have not been able to finish it, so I can not integrate all my changes into the master branch.

After receiving a kind offer from someone to help me out on the project, he asked me what still needed to be implemented. This got me thinking:

In this project, I reject tools/methodology as long as possible. Since I noticed the project was starting to slip - I've spent a lot of time on it, but the Net result for the end user is still zero -, I wondered how I could prevent this from happening again.

After all, that is what Agile/Lean is all about: be as efficient as possible in what you do, and the minute you are getting less efficient, look back at what happened, and find a way to make sure it does not happen again.

I used this approach all the time in the Nerdbeers project: I started without any tests or IOC, I postponed them until the manual testing process was slowing me down/not error-prone enough. This might mean I have a suboptimal design, but since there is no real business value in this, I can safely neglect this. When the suboptimal design starts getting in the way of doing efficient development, I can always refactor.

Anyway, back to the slipping part.

How can I prevent this lamenting stuff ?

The reason for lamenting is quite straightforward: I need a proper way to determine my - and the contributor's priorities. So I started creating issues on github, and after a few attempts of tagging, I finally found a method that works for me. It is heavily inspired by the Kanban stuff I use all the time during dev.

This is what the open issues list currently looks like:

Whoa, that's a lot of tags!! Why is that ?

Well, because I need them; let's look at them one by one, in the order they are assigned:

• Type: determine whether an issue is providing direct business value (bug or feature) or not (Tech)
• Time: a very rough estimate how much time it might take to implement; the purpose is helping you prioritize issues
• Care: this tag points to the person who is taking care of this issue (you could consider this a bit like an assignment)
• Stat: (short for status) Using stat you can follow the progress of the task

I tried searching for the minimal amount of tags which would allow to determine the correct priorities.

Using these tags I found out that the huge branch I'm currently working on, does not really provide a lot of added business value, so I decided to lower the priority and make it a bottom one. This is actually something that happens a lot with projects: things get implemented because they are "cool", but they actually do not provide a lot of direct business value. These tags should help me to prioritize.

Another cool thing is that the closed issues list now actually provides some value:

Fixing the features

As I was thinking about all the possible features, I noticed that I was adding a lot of them, without actually thinking them through. Since I wanted to avoid adding features which do not provide business value, I decided to implement a BDD technique into my feature definition.

Lets take a look at this in detail:

As a site owner
I would like the Nerd
To be able to view a map of all upcoming nerdbeers
So that he can choose whether he would organise one himself, or just join another one

This uses my favorte BDD format for BDD stories: you inform the reader who wants the feature, for whom it is designated, what it is and what the business value is.

This approach actually made me remove some of the issues I had entered, and made me alter some others. Someone who looks at a feature should now be able to figure out a lot based on these four simple sentences.

Conclusion

While the app in itself has not really evolved a lot, the way we approached it now has; this is what Agile/Lean is all about to me: provide business value in small incremental steps, reducing waste/being efficient as much as you can. I am rather curious to know what the next step will be in this project !!!

Introduction

In this small article I am going to ventilate my recent thoughts on the evolutions and the future of software (both platform and development methodology). This is my first attempt for such an article, so please do not take it too serious. Maybe within 5 to 10 years time, one will be able to read this article and have a big laugh, but then again, I am hoping to get at least a few predictions right.

Application architecture

I think the next big thing leveraging software and it's development will be HTML5. The basic architecture would be like this:

• the client will be a task-based GUI running on the HTML5 platform; HTML5 will be supported on most peripherals.
• the GUI will be able to generate explicit commands (poco class instances) and query view data L/WS* (=local and/or from one or more webservices)
• these commands will be handled L/WS*
• when the command is executed, the changes will be propagated explicitly through events (=poco class instances), or change the view data directly
• these events will be processed L/WS* and will update the respective view data L/WS*
• viewdata can be generated and persisted locally and/or on the server, and syncing is a mather of syncing commands and events
• commands, events and view data will probably be published through some kind of ATOM/ODATA-like interface (or persisted locally)
• due to more and more microdata formats and standards, webservices will become interchangeable (think address lists for example)
• All devices will get a webservice interface (think phones/peripherals in general), usually with a full REST implementation

Consequences

This would imply that a well written app (in HTML5) would be able to:

• query/consolidate microdata or other standardized formats locally and from multiple sources
• disconnected apps could easily be synchronized
• app components should be reusable, apps should be composed of multiple HTML5 components
• it could work in both offline and online mode
• it should support multiple media/input methods
• apps should work on a plethora of platforms without to much effort

The environment/tools

In order to make this possible I expect the following

• the development language of choice will probably need to be the same for both the webservice and the client-side. This does not need to be javascript; it can be an other language translated to javascript for the HTML5 side (think Coffeescript for example)
• commands, events and the handlers should be first-class members of the language of choice, or at least offer a framework that makes it easy to use this.
• there will be a registry which would contain the mappings to resources (either local or on one of more webservices) - this registry might be a webservice in itself, for example a webservice of registry for all your personal multimedia resources
• sharing data between different platforms would become universal (think movies/music for example)
• caching/syncing data should be as simple as calling a single function
• replication/failover is a piece of cake to setup
• CQRS/BDD will be hot
• monitoring the infrastructure is easy
• everything will become continuous: continuous integration through a buildserver, continuous testing (think autotest.Net for example), continuous deployment, continuous monitoring
• authentication will also be done through webservices or through current http/SSL/OID/... implementations
• some kind of universal search which goes through all resources in the registry should be possible

Finally

I think in the end we will get an application that sends commands to a bus, which is either handling things locally and/or on one or more webservices. The app will also be able to either query the local data or some webservice for view data.

The registry of webservices will make it possible to plugin your own stuff without much hassle, and caching/backup/failover/monitoring should all become a non-issue.

A few possible problems come to mind here, which might be excuses why my predictions could be false:

• migrating/integrating legacy systems
• software/Services ownership and -protection
• CQRS/BDD acceptance might be hard for some devs
• implementations differences of HTML5
• REST webservices might be replaced by something faster/with less overhead (protobuf comes to my mind for example)

In the end, what it all comes down to, is finding a balance between simplicity, flexibility, complexity availability and concurrency.

Introductie

Gezien de huidige situatie in ons Belgenlandje vroeg ik me af wat nu het verdere verloop zal zijn van onze politieke impasse...

Omdat ik meer verstand heb van poker dan van politiek (ook al hab ik niet veel verstand van poker :-) ), heb ik het even als een pokertoernooi proberen bekijken; dit is het resultaat :

Verloop van het toernooi

We zijn een pokertoernooi aan het spelen... CD&V, OpenVLD, N-VA,MR-FDF en PS zitten nog aan de tafel... Dit was de historiek:

• NVA was shortstack
• OpenVld speelde met zijn chiplead veel te aggressief, waardoor die de average stack CD&V een keer verdubbeld heeft.
• CD&V was toen chipleader, maar heeft  veel te loose gecalled , en bijgevolg een paar keer NVA verdubbeld ipv ze uit te schakelen.
• MR-FDF heeft nog niet veel handen gespeeld; deze speelt enkel als hij de nuts heeft ... Deze gaat wel direct all-in, dus is het moeilijk te verifieren of hij al een keer gebluft heeft
• De PS heeft goed gespeeld, maar een paar keer lucky hits gehad (bv. AA tegen 76s met een flushdraw voor PS, en er valt een flush op de river, nadat alle raises gecalled zijn)... Ze nemen soms onnodig veel risicos, maar hebben tot nu altijd geluk gehad.

Wat is de huidige situatie ?

• NVA is bigstack(25BB), gevolgd door PS (21 BB)
• De andere partijen hebben >  10BB
• PS raises preflop 3BB - Di Rupo als formateur
• NVA calls 3BB - De Wever laat niet in zijn kaarten kijken
• PS checks the flop (Rainbow lowcards) - Di Rupo doet een laatste poging
• NVA bets the pot (6BB) - NVA weigert
• PS reraises (12 BB) - L'Onckelinx dreigt met de scheiding van België

Optie 1: NVA callt  ( zoekt naar een compromis )

Als NVA callt, en ze verliezen deze hand dan zullen ze waarschijnlijk ook het toernooi te verliezen en de chipleader een enorme voorsprong geven... 
Als ze dit callen, en ze winnen, dan hebben ze verhoudingsgewijs wel redelijk wat chips bij, maar zoals de meeste toernooispelers wel weten, zijn de chips die je hebt altijd meer waard dan de chips die je kan verliezen, dus nooit callen !!

Dit is dus geen goeie optie

Optie 2: NVA Reraises all-in  (weigert)

Aan de andere kant, als NVA zelf een tightere range heeft (moeilijk te bepalen, gezien het kleine aantal gespeelde handen), dan zou die misschien best reraisen, want zo schakelt hij zijn meest geduchte tegenstander uit...

(in het verleden heeft PS al laten zien dat ze all-in durven gaan met 77 in een 1-vs-1... ) Natuurlijk blijft het een risico om all-in te gaan, zeker gezien hij momenteel nog altijd op tweede positie staat, ook na het folden...

Ze weten beiden dat bij de kleinste kans de spelers met een lagere stack (10BB) bij het minste all-in zullen gaan, en dat ze zo de leiding zullen kunnen verliezen...

De kans dat de PS zal folden bij een all-in van de NVA wordt zeeer klein geacht.

Optie 3: NVA foldt ? (gaat akkoord)

Als de NVA foldt, komt de PS wel aan de leiding, maar dan is het verschil niet onoverkomelijk; de NVA maakt dan nog steeds kans om het toernooi uiteindelijk wel te winnen... Het zal dus nu even moeten inbinden, maar maakt uiteindelijk nog wel kans om te winnen....

Wat is dus bijgevolg mijn voorspelling ?

NVA zal nu folden (=akkoord gaan), om later zijn kans te grijpen....

Akkoord of niet ? Laat het me maar weten !!

Introduction

For one of my customers I needed to have some kind of versioning for a whole bunch of entities on my database. Since I use my very own MvcExtensions framework, I wanted to include a functionality which would automatically filter all entities based on this interface :

In short, I only want to get the entities of the current version through my repository. This interface would then automaticly imply that all data could be filtered by setting a version filter.

I took me quite some time, but spending a weekend at the Dutch coast cleared my mind a bit, and after the weekend I managed to get it working...

More...

Introduction

Today I was reading an article on Codeproject, and I was really astounded by the way some people rate articles and give comments...

It was an article about someone who had implemented a simple service locator which contained the following code sample :

Which seems quite obvious to me. Since I noticed a comment titled 'my vote of 2', I was curious why this article would be voted such a low score (2 out of 5). I checked the comment and I was astounded:

Please note: the keyword "var" is supposed to be used with anonymous types. You should not use it for anything else. Otherweise please start
programming java script

More...