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

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

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

“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?

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

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:

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

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?

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?

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?

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.