At last

After so many days. It's there.

Ebay + Eclipse

Very nice article about Ebay and Eclipse :) they seems to be not very well fit together, but just read this

http://www.ibm.com/developerworks/library/os-eclipse-ebay1/index.html

Idea

Downloading idea. Eager to try it :)

Yet another driver for development - Domain

I was on the interview in a small company here in Dusseldorf recently. Interview went ok, allthough I didn't really liked the way the company is doing their development because they are definitely struggling with handover problems and heavy over-engineering.

However person on the interview mentioned that they want to start using Behaviour Driven Development (he also mentioned allot of other staff they *want* to do, but that's usual in SW development IMHO, just check the open position requirements on monster.com :) ).

So I heard buzzword BDD before but weren't really in the topic, so I decided to have a look.

So, I found following sentence:

"It brings together strands from TestDrivenDevelopment and DomainDrivenDesign into an integrated whole, making the relationship between these two powerful approaches to software development more evident."

What stands behind TDD buzzword was clear for me, however DDD weren't, so I found a nice book on InfoQ about it. What's interesting is that one of the authors of the book is a founder of InfoQ, and this PDF is basically a short summary of another book. Wherever, I started reading.

What was really interesting inside the book, authors are definitely aware about the common trends in SW industry, such as Waterfall-Agile transformation, so one citate from the book:

"continuous refactoring done by developers without solid design principles will produce code that  is hard to understand or change. And while the waterfall approach may lead to over-engineering, the fear of over-engineering may lead to another fear: the fear of doing a deep, thoroughly thought out design. "

Nice. Fear of though design, a kind of design-fobia. It reminds me a long discussion about evolutionary design which will never be really complete, since it's too much subjective feelings and experience stands behind. 

+1 to Safari

You might haven't noticed that, but new Safari 3.1 is out (!). Safari is my favorite web browser because 

• It has the best supports of most of the web standards (check Acid 2 test in your browser) so I can see the WEB the way it shall looks like. No Firefox can do that so far :). Microsoft IE team is trying to do that, but as soon as they did, nothing else works in IE :)
  
• It's damn fast, and version 3.1 is even faster!
• It renders fonts correct way. The way they should be rendered with subpixel rendering. Check Joel blog on that. (through all applicaitons on Mac do that, Firefox also, but not on Windows)
• It has a very nice features build in (check codinghorror and macrumors)
• It works very nicely on my Mac :) and on Windows :)

It's really a nice browser and unless there were a SafariBug (similar to FireBug) I would deinstall the Firefox the same minute. Migrate!

LDD - Language driven development

The ideas of MDA (Model Driven Architectures) seems to be very promicing to me. The ideas materialized after I explored EMF (Eclipse Modeling Framework) and we started using it in our development. Another topic that was interesting for me is DSL (domain specific languages), I had posted about it already before. Today I found a very nice approach that merges these two different ideas into one - XMF. 

It seems to be very interesting approach where AFAIK language itself is a matter to change depending on the domain we are working in, and we could represent language construct (AST or similar) as a modeling object. 

Having that in place we could automate transformation between different languages and have the full traceability between different artifacts. It's only my first impressions. Guys from Ceteva coined (?) a new term - Language Driven Development. I'm eagerly reading the paper from them.

Unit size in unit testing

It was quite a while since my last post here. Was a bit busy with the new article about Tapestry 5 and facebook application development :).

Recently Howard Lewis Ship, IMHO one of the most knowledgeable guys in software development, creator of Tapestry and Hivemind, posted a very interesting post in his blog concerning unit testing. 

In his post Howard discusses wherever unit testing on class level is efficient enough to worth the spent time, especially when DI (IOC) container is used and each class/service is relatively small. Very simplistic classes are not a good candidate for unit during unit/developer testing. 

He concludes that sometimes bigger units during unit/developer testing will lead to better results, and that's exactly what happened in our system.

We had a relatively big service (around 450 LOC) that was  loading objects from database inside our proprietary ORM (this is another topic why it's exists at all, but about it in the different post). This big service was quite complex one, we would require allot of setup efforts to test it. Actually the simplest way to test it was to hook it to the database (production Oracle or in-process HSQLDB). As you understand it's not a very good idea and make test maintenance very complex.

A bit of explanations required here. We are using EMF generated model code inside our system. It's a very nice approach to system modeling and brings us all benefits of MDA and Metaprogramming. Our Loader service is responsible for fetching data from the database by executing JDBC quries and filling up the model. Query construction and caching is delegated to other services. Query execution and mapping is complex and require some code. EMF model population is also not simple, especially when we would take into account lazy field/collection initialization and complex objects relations.

So, we decided to split this class (service) into two, instead on one Loader there will be Loader and InternalLoader. These two services are mutually dependent (which is no problem at all even with Constructor-based dependency injection). But most interesting decision for me here was how to split the single class into two. Normally according to GRASP we would like to have very small and concise interface between spitted services. It will not only be a better design but (as usual) will be easier to test.

We decided that InternalLoader will be responsible for purely database operations and Loader service will keep the EMF related functionality. After the split we could test Loader service injected into our model which directly highlighted a significant design problem in our code. 

Now it's evident that the problem that we found, couldn't be found by testing each class separately. EMF model and Loader interaction is very complex and involve our code as well as 3rd party EMF code. Only combination of simplified Loader service with our model produces well encapsulated module for testing. For such unit testing is efficient and do not require complex setup/maintenance - hence worth the efforts :)