OK, maybe not so new, but it is definitely gaining more ground (again). So why is it interesting, what is the point here?
I say: anybody can hack code these days , but , hacking code that generates code… now that is a skill !!!

I am not trying to despise or lower the value of a good programmer who has the discipline, knows best practices, follows guidelines. These programmers are very rare, even these days. I am writing about a new type of developer here.

These days, even teenager kids can write viruses (have to admit that they need a Microsoft for this, which makes it possible for them). But the real deal is actually writing the virus generator (for example: VBS Worm Generator), one that can generate your home-made-gonna-bring-down-the-internet-worm-peace-out type of stuff.

Of course there are more honourable and nobler purposes than writing a virus generator.

Essentially code generation starts with developing an exemplar - the code basis for the pattern implementation. The real skill here is to ensure that the code is generator or pattern friendly. Friendliness is a subjective measure, meaning how easy it is to develop the pattern implementation from the code.

Pattern implementation is about extracting the variability from the exemplar – the part of the code that is likely to change in the generated instances.

As it happens, these two tasks belong to different roles also likely to be different individuals. How are these two roles going to work together? What is the contract between them?

The contract, similar to an interface definition in OOP, in this case it is going to be a model. Actually I should say a meta-model that captures the elements of variability, and the relationships between them.

Once the pattern implementation is ready, an instance of the meta-model – a model – provides the input for the code generation.

This meta-model and the modelling activity gives us Model Driven Development.

The meta-model can describe a set of interrelated concepts, where these concepts can be captured using for example a Domain Specific Languags (DSL). DSL is a topic for another entry, in the meantime here is an article of mine about it: Explore model-driven development (MDD) and related approaches: Applying domain-specific modeling to Model-Driven Architecture.

When looking for an explanation for SOA, the typical findings would include: architectural style , architectural approach. Sometimes the explanation may not elevate further than a buzz-word stuffed marketing statement.How about…

Take mathematics, physics, or whatever science is closer to your heart as an engineer. Let’s look at how these disciplines described, modelled the world around us. Let’s take math (algebra) as an example…
…first we had integers to model numbers; then came zero and the negative numbers; later fractions and real numbers; complex numbers and so on.
Same evolution has happened to geometry as we learned to understand space and dimensions. Physics thought us about falling apples and a bit later about the quantum mechanics. Equally similar was geography where the world started flat and now it is an ever expanding universe of galaxies in a big boom.

So what is Service Oriented Architecture then?

It is a model for architectures, or it could be a meta-model if architectures had a proper notation for modelling.

Every single case when the model describing the world around us evolved there was something that had to be considered, there was a new aspect from which the world seemed flat again. As the models evolved they also had to ensure compatibility more-or-less with previous models; while pushing the boundary of understanding further and further.

It is quite similar with [IT] architectures. They describe, model a solution using our best knowledge and understanding of the domain.
Today we have arrived to Service Oriented Architectures, it is another step in evolution of describing and modeling IT solutions. It deals with some of the concerns more accurately, for example: business-IT alignment, loose couling, reuse, governance, and so on. It is also true that SOA may not be needed for an architecture, just like no need for complex numbers to count apples.

Is it the end of the evolution? Is SOA the perfect model? Far from it… These days, some of the concerns, decisions and their complex relationships are better understood than others. As the world moves together with our understanding of it, more complex requirements, concers and decisions emerge and they demand a new model, a new architceture.

Math still has problems that cannot be solved in the current models; physics is pushing the boundary to understand the smallest, astronomy is pushing to understand the largest thing there is.

Is this too academic?

Yes, at the moment it is, but it is a start. More details to come…

I have just recently built a server at home for some testing. I am quite pleased with the result and the experience is worth sharing.

The machine is an IBM xSeries 335 and the specs are: dual-Xeon 2.8GHz, 3GB RAM, 80GB disk (ATA). Memory and disk need a bit of beefing up. I have managed to pick up with box and a few extras for it from eBay for a fairly reasonable price for a system of this calibre.

The plan was to pull up a Linux server which is easy to manage, slap on a VMware server then run a few VMs remotely to test some SW for my pet projects.

I have picked Ubuntu as I am already reasonably familiar with the desktop edition, I like it and it has plenty of documentation for everything you may want to do on this OS.

The pleasant surprise came with the installation of Ubuntu Server Edition 7.10 and the rest of the SW. The OS went up in less than 10 minutes and booted up with all the HW pieces recognised, another 30 mins to install Gnome desktop over the Web, 10 minutes for VMware Server and a few more minutes fiddling with the config to make XDMCP work with GDM. That’s right; it took about an hour, not more.

Now if I could only do something about the noise from the army of fans inside…

Asimov’s 3 basic laws of robotics is broken (read his books for more details or watch the movie I, Robot). Who would have thought that? Well… an architect should have…

An architect should be able to deal with real life, illogical situations. Dealing with the human factor (organizational, business) is part of the every day job as a result of lacking project management, skill gaps, etc.

Another typical illogical situation – it could be during requirements gathering.

Consultant: Let me help you to chose a color for your new car. Do you prefer red or green?
Customer: Green.
Consultant: We also have blue do you prefer green or blue?
Customer: Blue.
Consultant: Excellent, so your preference is blue.
Customer: Actually, I like red the best.
Consultant:

And the moral of the story? Get your requirements right. Logical thinking may get you into trouble…

Interesting, educational and enlightning discussion with a developer (based on a real story, but no product names this time):
Specialist: I am trying to build this JSF page in this development environment (IDE), I do not know how to get this combo-box work?
Architect: Not sure about this environment, but try this… and this… or this…
Specialist: Right, I did not realize it works like this. I know this “other environment” and it works a bit different there.

What could be the moral here?

Often there is a need for a specifc style of menus on Web pages. These menus show up after a specific event (for example: click or hover over) and they stay visible as long as the cursor is over them.

Developing such menus is not trivial at least to say. I have managed to find two solutions to this.

One solution is based on CSS (Cascading Style Sheets) described in the excellent article: Pure CSS Menus.

The solution I have worked out for the menu is based on JavaScript, goes like this:

1. Retrieve the top HTML element for the menu or create the HTML elements for the menu. This can be a result of a mouse-click or a mouse-over event.
2. Register the mouseout event for every HTML element under the menu, the event should invoke a function checking if the menu should be closed.
3. Use the event.target (or event.srcElement on some browsers) and event.relatedTarget (or event.toElement on some browsers) properties from the event to check if the menu should be closed.
4. The condition for closing the menu is: the mouse has not entered (event.relatedTarget) the top menu item and it has not entered any other element that is a child of the top menu item.
   This second part may need a supporting function to determine whether an element is a child of another element, example (see isAChildOf function): Mouseenter and mouseleave events for Firefox (and other non-IE browsers)
5. (Optional) To get a funky effect, hook up the close action to a timer and only close it on expiry. In the meantime any mouseover event to any menu item should disable the timer.

Another example of the pointer sensitive menus can be found on the TDT 3D Web site. Unfortunately the code is scrambled, but it seems that it combines CSS and JavaScript to achieve a pointer sensitive, roll-down, delayed hiding menu effect.