MadeByMonsieur

Thoughts about technology, business and how to make it done

Example – Pushing events to an web app

This blog post is a quick walk-through of this demo.

The demo is very simple. When a web page is opened an anonymous XMPP connection is created. You can open another window and send events between the two anonymous connections.

The demo might look simple, but if you look deeper you will notice that when it comes to eventing and messaging, the possibilities to extend this example are amazing. Thanks to XMPP.

But let’s not praise XMPP more. Let’s get back to explain the demo instead.

The web page [1] is mostly done by using a very easy to use JavaScript library called Strophe. It is used to create long polling XMPP over BOSH requests to the XMPP server. The requests are proxied through an HTTP server [2]. The XMPP server will take care of session handling, routing and delivery [3].

The webclient communicates with the XMPP server through BOSH.

So what is needed?

Following technologies are used:

  • XMPP
  • HTTP
  • BOSH
  • JavaScript
  • (plus some HTML and CSS)

To get the demo working, I needed to install an XMPP server and an HTTP server.

I installed an XMPP server called Prosody (0.7) and an HTTP/reverse proxy -server called Nginx.

This demo is based 100% on standards so any other XMPP server that supports BOSH and any other HTTP server that supports reverse proxying can be used.

As mentioned earlier, an excellent JavaScript library called Strophe was uesd to create the functionality on the web browser.

The demo is running on Debian Lenny 5.0.7 but the technology used is of course not limited to it.

Step number one, let’s install Nginx

The following command was run as root. It installs Nginx server using the Apt utility:

$ apt-get install nginx

That was pretty easy. The next step was to configure it.

Since the demo is running in example1.madebymonsieur.com, I created an configuration file /etc/nginx/sites-enabled/example1.madebymonsieur.com. As you can see by opening the file, the configuration is very simple. Important is to notice the reverse proxy configuration for /http-bind/ location in the end of the file. That rule is done to route the BOSH traffic to the XMPP server.

To make the configuration effective, I restarted the Nginx server.

$ /etc/init.d/nginx restart

Next we’ll install the XMPP server

A good introduction and clear help how to install Prosody can be found here . However this is what I did (as root again) for the demo:

$ cd /usr/src/
$ wget "http://prosody.im/downloads/debian/prosody_0.7.0-1_i386.deb"
$ dpkg -i prosody_0.7.0-1_i386.deb
$ # I had some dependency problems so I just ran
$ sudo apt-get install -f

And XMPP server was up.

Now let’s configure it. (The final configuration file can be seen here.) Open /etc/prosody/prosody.cfg.lua file.

First we enabled “BOSH”. We archived this by uncommenting the line 56 (remove the ‘–’).

Next we configure the port we want BOSH connections to be listened on. Port 5280 is the standard one. We add “bosh_ports = { 5280 }” to the config before “VirtualHost” -parts. See example on line 103 of the example configuration file.

As a last step for the Prosody configuration file, we add virtual host configuration (example starts on line 109 in the configuration file).

VirtualHost "anon.example"
    anonymous_login = true
    disallow_s2s = false

We configured the host name to be “anon.example” and enabled anonymous connection for it. We don’t want to allow server-to-server connection for this domain so s2s is disallowed.

As I created a new hostname, I added it to the /etc/hosts file so it would be correctly resolved. To archive this I added a following line to my /etc/hosts file:

127.0.0.1 anon.example

Now we restart prosody and on we go:

$ /etc/init.d/prosody restart

One last step to do

I copied the index.html, strophe.min.js, example.js files to web root. For this example the root was /var/wwww/examples/example1 . Listing of the directory looks like this:

$ ls -laF /var/www/examples/example1/
-rw-r--r-- 1 www-data www-data   3967 2010-08-14 01:04 example.js
-rw-r--r-- 1 www-data www-data   2576 2010-08-14 00:22 index.html
-rw-r--r-- 1 www-data www-data  40107 2010-08-14 00:18 strophe.min.js

Ready!

That’s it. If you are interested how the JavaScript code works, open the example.js -file. It should be pretty simple (just 5 functions). Most of the “code” is just comments and “jquery -stuff” for nicer display.

Remember that this was just a very simple example how straight forward it is to push events to an web browser. Since we use XMPP here, it would be quite trivial to send messages to the demo for example from gTalk or launch any kind of events from other systems and visa verse.

In case of any questions, problems or ideas, don’t hesitate to contact me. I would be delighted to help out more or just discuss about the possibilities of this kind of technology.

Cheers,
tuomas@madebymonsieur.com

To Go Fast, Do We Need to Do It Always Well?

Have you ever been significantly slowed down by “Bad Code”?

I have. And probably at least once a month. I know bad code will slow projects down, I have seen it slow projects down – So why do I still sometimes write it!?

Because we were on a tight deadline and we had to go as fast as possible, the managers were pushing us and the specifications changed at the last minute and I will fix it later …

A project might be finished on time and on budget. It looks good on paper and in reports so the job was well done, right?

What if the project includes some ugly hacks just to finish it on time? The dirty hacks will most likely significantly slow down the next version or another project. So in the end, was the project well done or not?

Should we take more time to finish the project with good quality code? It would be more stable, easier to maintain and quicker to evolve. Or should we just hack it up to make it “work” as soon as possible? The customer does not always understand or care about the consequences.

As the saying goes, ‘if something is worth doing, it’s worth doing well’. I think that is a professional attitude, a principle, something I would not want to compromise.

But at the same time I often have a feeling that perfectionism is the enemy of progress.

I’m trying to find my way by following a mantra of “do no harm”.

If a company is not very organised and pushes any kind of proof of concept to production, the quality of code must be high. As a result, the project will be probably slower to do. I will try to reach high code coverage, will use a simple and easily understandable framework and develop good documentation. I will try not to do harm to my colleagues, future projects and the company by giving them a “big ball of mud”.

However if a company follows software development best practice, uses a framework and has an understandable architecture, I don’t think it matters if some messy stuff is sometimes done just to get the job done. The messy stuff will be cleaned up later through iterations and code reviews. No real harm done.

To go fast, the basics must be done well. Later on, it will be so much faster to build on top of it. And even rush sometimes.

Good core architecture, libraries, practices and frameworks are very valuable for a company. Something to be proud of – “priceless”, even.


tuomas@madebymonsieur.com

Not maybe a Pirate but a Forty-niner

“During the The California Gold Rush (1848–1855) the gold-seekers were called ‘Forty-niners’ (as a reference to 1849)”

During the Halloween, I read a good blog posts by Michael Arrington about the essence of being an entrepreneur. It’s a interesting post that brings up many thoughts. I recommend it to be read by anyone having their own business or thinking of having one.

In his post “Are you A Pirate“, Mr. Arrington finds similarity between entrepreneurs and pirates since both gets utility out of the risk itself.

It’s an interesting comparison and made me think of my past. I came to a conclusion that I would not describe myself as a pirate. At least not any more.

When I was younger, I was always highly interested in the decades of the history when one was able to explore the world and to be his own master with endless possibilities. I was even a bit jealous for not being able to live in time when there were places in the world where no man had gone before. I would have wanted to be the one travelling through Asia with Marco Polo or sailed with Christopher Columbus to discover America.

And not to forget my favourite, the California Gold Rush. One was able to make his own luck, almost without laws, without limitations.

Why had I not been born 160 years earlier?

But then, the Internet came. My possibility to discover a world of endless possibilities was there. I had found my “Gold Rush”.

I was able to start to explore something completely new. I was able to start to build things that no one had ever done before. I had amazing possibilities when it came to customers and not-been-done-before -ideas.

When I was younger, I think I was a bit of a pirate as Mr. Arrington describes it. I just wanted to do things selflessly for the sake of it, for the risk of it, to be able to go to new places, to travel. All the rewards as we see them in a normal working life were just a bonus. I just wanted to be in the action, on the field.

If I would describe myself now, I would not describe me as a pirate but maybe more as a Forty-niner with a family to feed. I have a goal. I know there is gold out there. I might not hit a jackpot but I’m still able to make a living out of it for my family. I have the same change as everybody else and god damn it’s just fun to try. Not a single day is the same and I can do it just the way I want.

I am the same guy as I was 6 years ago, I’m just not digging pointlessly any more. It does not mean I’m not enthusiastic. Contrary. Sometimes it’s fun to rush but more and more often I stop and think before acting. It has helped me to find more gold than ever before.

I consider myself lucky to be able to live these exciting times.


tuomas@madebymonsieur.com

PS. Read http://en.wikipedia.org/wiki/California_Gold_Rush . Add 160 years to the dates and change a bit the concept towards the web industry. Not that different, is it?

Pledging for unit tests

I still regularly have to defend and sometimes even “fight” for unit tests. Sadly most of the developers and managers do not get the value of the unit tests but sees them as a burden instead.

Some of the common complains I hear about the unit tests are the following.

There more you write tests the more …

  • it takes time
  • you have to maintain them
  • those test have to be re-factored when you have to re-factor the code
  • it’s impossible to test everything anyway
  • it’s a burden
  • it’s hard
  • (and because I’m lazy, unmotivated and I don’t want to do it!)

Yeah, OK, they have a point. Yes, it will take some more time to do the tests. Yes, the tests are going to take some more work to maintain. Yes, producing code that is “unit testable” is sometimes “harder”.

But C’mon! For me that sounds like “It’s too hard and complicated to test and prove that our code works, so we just pretend that it works“.

At this point in the history of software development, why do we still need to defend unit tests? Or am I wrong? Are there some other, more efficient and better solutions available?

Of course not all mock-ups, proof of concepts and personal projects need a high code coverage or unit tests at all. If you feel there is no need for them or TDD is just not your cup of tea, fine. It’s not a crime not to do them.

But if you are working with code that is going to be released to production or used by other people, please developers, let’s keep doing more and more unit tests. It will make our work so much more efficient, motivating and a bit more professional.

And if not for you, do it for the next dev. When you have managed to set a high code coverage with good unit tests to a codebase, it will be so much easier for anyone to take over when you move to a more interesting project. Or faster for your colleague to do a patch when you are on vacations.

Not to forget, that sometimes unit tests are a great and efficient way to understand quickly how a library or a class is suppose to be used.

Please, do unit tests. Everybody will win. You, your collegues, the project, the company and the whole developer community.


tuomas@madebymonsieur.com

Be professional, do unit tests

Let us see the hands of developers who are practising Test Driven Development or at least does unit tests before the code is delivered?

We have been asking the above question in different conferences, companies and community meetings. In average 40% 25% of developers rise their hands.

That is awful.

Only 25% does unit tests? It means that 75% of the developers don’t know if their code works or not!

We, developers, should be ashamed of ourself.

If we are not doing unit tests at this point in the history of software development then something is wrong.

People have been talking about the practise already far too long and the conclusions are always the same:

  • it helps you so much
  • it makes you go so much faster
  • it helps you to deliver much better code

If you are not doing unit tests you need to seriously stop and consider why.

Are you not doing TDD because your management does not support it? Are you not doing unit tests because “it brings too much overhead to the project”? Are you not doing unit tests because “it makes the development slower”?

It is unprofessional to not know that your code works. It is unprofessional to release code that you are not sure if it will work or not. Know that it works.

And how do you know that it works? We got tests.

So lets do sane unit tests at least in one point of the project.


tuomas@madebymonsieur.com

Update:

The Valuable Benefits of Domain EDA

Implementing Domain Event Driven Architecture (Domain EDA) will bring multiple advantages.

It will allow us to create high performance, highly scalable, “real-time” systems. This is due the Domain EDA is highly decoupled and event driven.

One might argue that that was a lot of meaningless buzzwords in one paragraph, but it’s not camouflage chit-chat saying nothing. It’s true. The “technological” benefits really kicks ass.

However, we think that the greatest value and the biggest possibilities of the Domain Event Driven Architecture are at the end of the chain: when everything is in place, people at work will love it.

Why?

1. Can highly speed up implementing new features

Faster time-to-market. Implementing Domain EDA will highly reduce time to implement new features and functionalities.

There will be no need for point to point integration. The producers of events do not need to know who are the consumers of the events. The core team creating the producers do not need to hassle with the teams creating the consumers and visa verse.

The above can be boosted by using a transport layer like XMPP which can also provide authenticated, secure and routable messaging.

2. Enables you to do efficient Complex Event Processing

For example, let’s say that we have a need to know in real time when a user spends 500 euros on our e-shop.

To fulfil the need, the only thing we need to do is to build a Complex Event Processing (CEP) application which will receive events published by a billing platform [1.]. No need to change nothing in the billing platform, DataWareHouse imports or exports and so on.

As our new application will receive events, it will process them. In this case it will sum up users’ spending. When a user reaches 500 euros, our CEP application will launch a new “user_spent_500″ -event immediately [2.].

Now, for example, marketing department can use this new event to grand an offer coupon without delay for the user while he is still on the webpage buying Christmas gifts [3.].

Another good example is about a user who is trying to buy an expensive product but has problems paying it. A system launches an “possible_help_needer” -event and a user receives help from customer care when he is still on the web page.

That is a great customer service don’t you think?

3. Will help you to implement Business Process Management

The Business Process Management is more quick and more easy to set up since the processes can be started by domain’s events.

In the above example, immediately when a user has spent 500 Euros, a business process can evaluate if the user is worth of a coupon or not.

There is no need to wait for reports from DataWareHouse. Thanks to Domain EDA, even complex business processes can be executed in matter of seconds. (Yes I agree, the example above is not that complex but you get the point.)

And the best part in this is that “Business Teams” can manage efficiently their business processes as they want and when they want without IT involvement. That’s the whole point of BPM, right?

4. Key to real time Business Activity Monitoring

How are we doing today? What’s going on in our systems? Is the latest marketing campaign we launched this morning showing any sign of success?

Similar questions are asked in companies multiple times a day.

In many companies the above questions are answered with reports from the datawarehouse. The reports are calculated daily, twice a day, every three hours …

With Domain Event Driven Architecture we can have these reports in real time. There is no need for batch type of time based processing. Easy to implement, real time Business Activity Monitoring is available for the marketing team.

Less waiting. The information is available immediately as it happens.

System administrators have their tools for having a real-time view to their responsibilities. The marketing people should have the same kind of possibilities, right?

So what do You think?

Above we described the main values we have gained from implementing Domain Event Driven Architecture. We hope this blog post has brought you at least some interesting ideas.

We are more than happy to talk more about the Domain EDA so we would be delighted to hear your feedback, thoughts or questions. Let us have them!


tuomas@madebymonsieur.com

Domain EDA is the key to real time Business Activity Monitoring

How are we doing today? What’s going on in our systems? Is the latest marketing campaign we launched this morning showing any sign of success?

Similar questions are asked in companies multiple times a day.

In many companies the above questions are answered with reports from the datawarehouse. The reports are calculated daily, twice a day, every three hours …

With Domain Event Driven Architecture we can have these reports in real time. There is no need for batch type of time based processing. Easy to implement, real time Business Activity Monitoring is available for the marketing team.

Less waiting. The information is available immediately as it happens.

System administrators have their tools for having a real-time view to their responsibilities. The marketing people should have the same kind of possibilities, right?

Domain EDA will help you to implement Business Process Management like it should

The Business Process Management is more quick and more easy to set up since the processes can be started by domain’s events.

In the above example, immediately when a user has spent 500 Euros, a business process can evaluate if the user is worth of a coupon or not.

There is no need to wait for reports from DataWareHouse. Thanks to Domain EDA, even complex business processes can be executed in matter of seconds. (Yes I agree, the example above is not that complex but you get the point.)

And the best part in this is that “Business Teams” can manage efficiently their business processes as they want and when they want without IT involvement. That’s the whole point of BPM, right?

Domain EDA enables you to do efficient Complex Event Processing

For example, let’s say that we have a need to know in real time when a user spends 500 euros on our e-shop.

To fulfil the need, the only thing we need to do is to build a Complex Event Processing (CEP) application which will receive events published by a billing platform [1.]. No need to change nothing in the billing platform, DataWareHouse imports or exports and so on.

As our new application will receive events, it will process them. In this case it will sum up users’ spending. When a user reaches 500 euros, our CEP application will launch a new “user_spent_500″ -event immediately [2.].

Now, for example, marketing department can use this new event to grand an offer coupon without delay for the user while he is still on the webpage buying Christmas gifts [3.].

Another good example is about a user who is trying to buy an expensive product but has problems paying it. A system launches an “possible_help_needer” -event and a user receives help from customer care when he is still on the web page.

That is a great customer service don’t you think?

Domain EDA can highly speed up implementing new features

Faster time-to-market. Implementing Domain EDA will highly reduce time to implement new features and functionalities.

There will be no need for point to point integration. The producers of events do not need to know who are the consumers of the events. The core team creating the producers do not need to hassle with the teams creating the consumers and visa verse.

The above can be boosted by using a transport layer like XMPP which can also provide authenticated, secure and routable messaging.

The Big Benefits of Domain Event Driven Architecture

Implementing Domain Event Driven Architecture (Domain EDA) will bring multiple advantages.

It will allow us to create high performance, highly scalable, “real-time” systems. This is due the Domain EDA is highly decoupled and event driven.

One might argue that that was a lot of meaningless buzzwords in one paragraph, but it’s not camouflage chit-chat saying nothing. It’s true. The “technological” benefits really kicks ass.

However, we think that the greatest value and the biggest possibilities of the Domain Event Driven Architecture are at the end of the chain: when everything is in place, people at work will love it.

Why? Because …

(Each of the above links are separate blog posts of ours.)

So what do You think?

Above we described the main values we have gained from implementing Domain Event Driven Architecture. We hope this blog post has brought you at least some interesting ideas.

We are more than happy to talk more about the Domain EDA so we would be delighted to hear your feedback, thoughts or questions. Let us have them!


tuomas@madebymonsieur.com

Developers should know How, What and Why

Are you working in one of those big companies which have slow processes and endless meetings? Are you told to work on a task to create an API but you don’t really know how it is going to be used? Are you just following the specifications to make it technically correct?

The knowledge of “How to do things” is the most valuable piece of information developers brings to teams. Sadly, some people think that it is the only thing a developer needs to know to pick him for a project.

We don’t think so.

Even the fastest Ruby on Rails dude, the most skilled Spring developer or PHP hacker will never bring the best value if he does not know what he is actually working on.

How many of you have created an API but have not been told correctly how it would be really used? How many have gasped “They use it like that? I developed all the 17 rest services as described in the spec and now they use only 4 of them. Damn.”

We think that before a developer can do a good work, not only he needs to know “How to do it”, but he also needs to know What he is actually working on.

However knowing What and How is not enough.

We believe that a developers needs to know and understand also the “Why“. When he knows that, he will be able to produce the most valuable and working product.

Why does the project exists? Why does the product exists? Damn, why does the company exists? Everyone should be asking these questions. By knowing and understanding the “Why”, we will be able to produce the optimum solution.

Knowing the “Why” will make us fully understand the goal of projects, products and the company. It motivates us because we see the big picture.

Understanding the “Why” will make decision making so much better.

We always start from What and Why. Then we know How to do it the best.

That works for us. What is your road to success?

The basic idea of Domain Event Driven Architecture

For us, the basic idea of the Domain Event Driven Architecture is that every significant event of the domain is available in real time as a push notification.

Let’s break it down to bullets.

1. Events are informal

Events are not commands. They are informal. The events are not type of “Create a user” but “I created a user”.

For example some events of a stock system could be “Product X was removed from the stock” and “There are only Y amount of product X left in the stock”.

2. Events are published in “real-time”

Events are published by the producer as they happen in the system. They are published in “fire-and-forget” -style. The producer does not care who is going to consume the events. When the producer publishes an event the consumers receives it as a push notification.

3. Consumers subscribe to events

Consumers subscribe to events they are interested of and consume them as suitable for their function.

For example a service is created to follow users’ payments. The business need is that when a user spends more than 2000 euros, she is automatically given a VIP status and an offer coupon.

To create this kind of service, a new system (as a consumer) only needs to subscribe to “User X paid Z amount of money” -events produced by the billing system. Now a user can be given an offer coupon and a VIP status immediately when the user is still, for example, on the web site. There is no need to wait a report from data-warehouse or from some other batch process. That’s a good customer service, no?

What do you think? Makes any sense?

Ostatus demo – road to SWAT 0

The autumn in arriving to Paris is and so is the deadline for the Social Web Acid Test – Level 0. We set up a simple demo hoping to give ideas and an example how the test could be passed using the OStatus protocol stack.

In the test we have the following parties:

  1. example.dude@lobstermonster.org, a homebuilt minime-hack
  2. testkoski@identi.ca, a status.net installation
  3. tuomas@madebymonsieur.com, a homebuilt minime-hack
  4. evan@evan.status.net, a status.net installation

In the beginning of the test the above parties have no other relationships than testkoski@identi.ca is subscribed using PubSubHubbub to example.dude’s notice feed.

Following steps are done in the demo in the following order:

  1. example.dude uploads a photo he took of Evan and Tuomas to his microblogging service
  2. testkoski@identi.ca gets a notification of the new photo since he is following example.dude’s notifications (PubsubHubbub)
  3. example.dude tags evan@evan.status.net and tuomas@madebymonsieur.com to the photo
  4. Evan and Tuomas will get notifications on their services that they were tagged to the photo (salmon)
  5. testkoski@identi.ca comments on the photo (salmon)
  6. example.dude’s microblogging service receives the salmon and since Evan and Tuomas were tagged to the photo they are sent a notification about the new comment as  well (salmon)
  7. Evan and Tuomas can see the notification and the comment in their microblogging services

So there we go! Nice federated microblogging service without boundaries! Birds have been let out of their cage to tweet free.

Next we’ll concentrate on the XMPP implementation and the compatibility with One Social Web project and Cliqset. And then this will be of course implemented to buddycloud -project as well.

Why Domain Event Driven Architecture

“It’s really become clear to me in the last couple of years that we need a new building block and that is the Domain Events”
– Eric Evans, QCon 2009

During the last years I have been lucky to be part of teams creating different Service Oriented Architectures (SOAs) in different sizes and environments. Some of the projects were very successful, some were a bit less. The power of SOA is widely known and there is a lot of information about it in “the Internet” so I won’t be going too deep in that. Instead, I will write about the problems I found in SOA and how Domain Event Driven Architecture (Domain EDA) came to help.

I think a word of caution is in place here before reading forward: I’m still very, very junior in SOA and specially in Domain EDA so I’m not even claiming of being a professional in this. I’m still learning new every day (sadly most of the time from my own mistakes) and love to discover and experience more. So specially when you don’t agree, I would love to hear some feedback and counter arguments.

Ok, back in business.

While working on the SOA projects I started to feel that the SOA is missing something. Maybe because my inexperience but still the SOA implementations most of the time ended up looking nice only on paper. The CEO/CTO guys were happy but if you looked deeper into the services, the systems included all kind of ugly hacks and shortcuts that were usually done due a lack of time. So something was wrong when it was not possible to implement “beautifully” new systems and services in the speed the marketing was expecting.

But thanks to (a very big special thanks to) Stefan Norberg’s and Eric Evans’ presentations I found Domain Event Driven Architecture (Domain EDA). As monsieur Norberg puts it, Domain DEA really completes SOA and gives it the boost it needs.

I will try to explain using a use-case why I think SOA can get slow and messy and how this problem could be solved using a Domain Even Driven Architecture.

Our use-case is about a value added service company called VASC (completely fictional) which already has a very nicely built SOA architecture:

Company's SOA

As we can see in the above diagram, the company has everything build in nice SOA with autonomous services like reporting, billing, CMS, etc. Everything runs nicely and individual services can be replaced pretty painlessly without having to effect the company’s main business. The business people of VASC are happily planning their next big campaign and product launch. The IT department is happy because they can do their geegy stuff  with individual services without halting the whole production and evolution and messing with the business people.

But one day the CEO hits her fist to the table and wants to implement an “affiliation system”. The VASC is doing a lot of TV, radio and Internet advertising and want to know which campaigns are successful and which just eats the money. This is what they want to use the “affiliation system” for.

So the Architect of the company gets to work. The Architect needs to change the front-end to catch some data. He needs to track the user through the systems to finally get the information to the reports the Big Boss needs. The CEO also wants that they are able to know four hours after the ad campaign has started if the campaign is showing sign of being successful or not. This of course brings even more grey hair for the Architect since the way their DataWareHouse works – a batch is run once or twice a day to get the data to the warehouse and then build the statistics.

The Architect gasps when he realizes that to implement the new service he needs to implement changes to all of the following services despite the beautiful SOA they had so hard worked for:

Company's SOA

Even the VASC’s architecture is “proud to have” SOA, they would end up changing almost all the services to be able to implement a one new feature. Implementing it and launching it is most unlikely to be the fastest and funniest process. Not even talking about all the endless meetings that needs to be done to spread the information what and why. The Architect takes a whiskey and wonders with a serious face – “man gotta do what man gotta do”.

When the Architect proposes his plans to his colleagues he starts to wonder why don’t they have all that information they need already available in “real time”? From where users came to the VASC’s web pages? What did the users buy , when, how, etc. That all is business information the business people are the most interest of. Why it’s not available in real time but only available in the reports coming from the famous DataWareHouse they spend a fortune to? If he would have the mentioned information available in real time, the “affiliation system” would have been a joy to create. And fast.

And then, in the middle of the sentence the Architect realizes: the information he needs are the events the services do which are important for the Business People.

Hallelujah! Mazel Tov! Heureka (plus all the other words) the Architect yells! Every service must yell out loud the events of the actions they do!

The Architecture decides to change his systems to just publish the events they do and makes the new affiliation system to subscribe to these event. Every service can be updated independently and the development of the new affiliation system can start immediately.

That night the Architect had a whiskey with a smile in his face thinking of all the possibilities the implementation of Domain Event Driven Architecture had brought to him.

So, let’s end our story and see what kind of events VASC’s architecture could send:

Company's SOA

Now based on the events above, the new affiliation system can be build as a separate service that just needs to subscribe to the relevant events above. The nature of the events is “fire-and-forget” so publishing the event will not really effect the way the existing services works at all. They “just fire-and-forget” the business relevant events that occurred and continues the job.

So that’s it. What do you think?


This was my first blog post about Domain Event Driven Architecture and there are many to come. The next post will be about how I have implemented Domain Event Driven Architecture using XMPP and how the “fire-and-forget” events can be easily published.

If you want to learn more about Domain EDA, I recommend to watch a presentation called Event Driven-Domain Architecture by Stefan Norberg. It’s very good presentation and gives you more information and examples why Domain EDA is just so great. Stefan and his college also presents a different solution how to implement Domain EDA than I’m going to present in the coming weeks.


tuomas@madebymonsieur.com

No, I won’t do it. It would not be professional.

“Oh yes, the specification was wrong, but we need to do this right now. We cannot launch without. Everyone has it. It such a small change. It must be easy and fast to do.”

-le project manager

You sit in the meeting with the project manager and marketing people. You hear the above demands with the famous “need, must, easy, fast” -assumptions. What can you answer? You are pushed to the corner.

After such a meeting, how many of you have done dirty hacks to the code and been ashamed of it? How many has done some big, quick shortcuts that you know will become a major roadblock in the future?

I have.

Luckily during the years, I have learned to say more or less no.

“Dudes, I would not recommend to do this hack like this right now. It would not be very professional. If we do this hack like this, quickly, right now, someone else will need to fix it one day. I will not do it to the next guy.

How ever I’m not the boss here so if we will do it anyway, I believe we should at least take couple of hours to document it correctly and create an automated functional test to also remind the existence of it. If it’s such an important feature, couldn’t we then take a full day or two to do the hack correctly?”

Usually that helps. If not, it’s time to take it to the next level. “OK, so you want me to do unprofessional work?”.

Developers. Every time we use a variable name that does not make sense we do harm to our colleagues. Every time we create an error message that does not make any sense or is not documented correctly we do harm to the support team. Every time we do an undocumented hack or shortcut we end up creating harm to everyone working with the software.

If I remember right, there is something like this in the Hippocratic Oath:

I will prescribe regimens for the good of my patients according to my ability and my judgement and never do harm to anyone.

Comparing a professional developer’s job to professional doctor’s one? Many argue that it’s not the same thing. Well, the doctors uses the tools nowadays the developers have developed for them.

How do you defend yourself to not to be “forced” to do unprofessional work?

Learn fast, learn often

How often you still hear these famous words at the office: “Fail fast, fail often”? I think the most of us who are familiar with the saying and understand the methodology behind it fully agrees with it. But be careful when using the phrase. Those who have not heard it before or have not understood it correctly thinks you are close to insane: “who in the hell would like to fail often?”.

In the worst case, people who hear and understands the words wrong are the ones who are responsible of the project. The project in witch you are ready to fail fast and often with. Those guys and gals don’t want to hear about failing. “Fail fast, fail often” sounds plain stupid to their ears and makes you look unprofessional and unqualified in their eyes.

Such a simple thing as changing the negative sentence to a positive one will have a big difference. Instead of saying “Guys, this is something new. So ‘fail fast, fail often’!”, say something like: “look, we have never done this before so what if we push it to the beta testers so we can learn fast if this is the best way to do it or maybe we could improve it even a way more?”.

“Fail fast, fail often” means the same thing as “learn fast, learn often”. I think it is time to start hearing more the positive version of it.