Rich Internet Applications presentation

Today I gave a presentation for TCS Knowledge Sharing session here in Dusseldorf. It was about Rich Internet Applications, how they are working, which technologies are used and so on.

Since it was my private time that I've spend on it you can also have a look on that, so I've published it here.

It's 3.5 megabyte PDF file, original presentation was made with wonderful tool from Apple, Keynote.

Tapestry 5 Java User Group

Yesterday, my self and my friend Igor Drobiazko presented the Tapestry 5 on the local Java User Group in Düsseldorf. It went very well, there was around 80 people to watch our presentation, and the audience was very responsive and allot of interesting questions were asked. We really enjoyed the presentation and the conversations after it!

We even meet some people from the Tapestry community there, so for example Nils Günther have traveled from Hamburg to Düsseldorf (which is quite a trip for Germany) to participate.
So here is the photo of Igor, me and Nils:


Was nice to meet him offline :)

The presentation is already online, you can get it from here.

Soon I will add some photos from the event (they are now processed from RAW format).

YUI

I was playing with YUI recently. YUI is not only three consequential buttons on the keyboard, it's a Yahoo UI library, fully JavaScript driven. It's similar to Dojo where you can have all the kind of UI elements such as tabbed panes, dialogs, layouts, tables and trees.

It's really nice an could be a very good base for "second generation AJAX" applications. Applications where data is delivered from the server via Async XML HTTP Request (and most probably JSON) and rendered by Javascript. The main difference from "classical AJAX" is that we are not sending HTML from server just to do a partial request, but client application has a notion of "model" and "view" rendered by Javascript.

The main difference of YUI to other frameworks are mainly huge user base, excellent documentation, huge number of examples and high quality you can expect from company like Yahoo.

It's online now! Our Tapestry 5 Article on InfoQ!

Hi!

Today it happened! At last! Our (my self and Igor Drobiazko) article "Tapestry for Nonbelievers" is published on InfoQ!

Check it here: http://www.infoq.com/articles/tapestry5-intro

The article was written quite a while ago. We've got allot of help and support from Howard. We really appreciate his help and without him this article would be much less that it is now.

Then we tried to publish it first on TSS . It was reviewed and accepted and then... nothing. For more than 6 weeks, just nothing, and our emails were ignored :( so, too bad we thought, therefore... 

We sent article to InfoQ there it was also reviewed and accepted, and .... after some time, it's eventually online. 

In the end it was very good experience in writing articles (it wasn't my first article though). We really enjoyed working on it. And off course we hope that with our small contribution more people will see how Web application can be constructed nowadays.

P.S. We are now preparing a talk for our local Java User Group. You can guess what the topic will be :)

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 :)

+1 to Mac

Macbook cool. Thanks to Pat, I've got it at last. It's really rocks, and MacOs (Leopard here) is very, very nice and easy to use. I've managed to do what took me on Windows more than 1 week in 1 minute (connect my mobile Nokia 6680 via Bluetooth and go online with it). It's really cool and fancy and very, very well done.

P.S. I'm writing this post from my Mac sitting in my car in the middle of nowhere.

Skype rocks

Just tried to call via Skype to Apple Store in US, and guess what? They ask me to "Press 1 if you want to blahblah press 2 if you want to blah blah..." and... indeed if you press "2" in Skype window it will send the tone signal to the phone line! For that's kind of feature I love skype.
Skype rocks!

Today I've upgraded the most important and visible part of my PC - display :)

New 226BW is now staying on my desk. It's 22 inch wide screen therefore I have a lot of screen now, I can organize my windows without overlapping :) also Firefox full screen makes no sense anymore.

I'm actually thinking now to plug it together with the old 19'' one.

DSL in Automated acceptance testing

I found a very interesting post on the Google Testing Blog
concerning experiences in Automated Acceptance Testing, we also call it end2end testing. It's was very interesting reading, because we share more or less the same experience. We had a very long discussions with my colleague from the "testing department" about how much the automated acceptance tests worth.
He was writing his Master Thesis on this topic. He was using Mercury Winrunner tool for automation of the Java Swing GUIs (Netbeans based). He had very interesting experiences and the thesis was very well done and interesting to read (I can't find it right now, may be I'll post a link to it later). In the end he comes to the heuristics, that for his project it takes 4 times longer to automate and maintain automated test than to write and execute test once, therefore the rule of thumb for his project was if the test is executed less than 4 times then it makes no sense to automate it. Basically it means that if in Waterfall model project has one release per year and feature will not survive more than 4 releases then it is not worth to automate it.

Such statements and heuristics are highly subjective. There are some test cases that will take 10 to 20 times longer to automate than to execute manually (example of it see below).
I completely agree with Markus about maintenance costs of the tests and also faulty failures, it's a very big problem that may also affect our decisions where automate and where not.

Also as Markus mentioned very right : "[test automation] turned into art of engineering ... we come up with best-practices" and if we apply principle of treating test code as production code then we decrease significance of the problems with automated testing hence increase the value of it.

I've played with test automation tools allot and for our most recent project we need to speedup the development process, therefore it was decided to create automated acceptance tests. Fortunately application we developed was a Web-based therefore we had a wide palette of tools at our hands (with ordinary GUI it's much more complex nowadays). Since we haven't used any AJAX and/or Javascript in our application we've chosen HttpUnit and derivatives of that (JWebUnit). After creation of the first tests we simply apply the practices we used for our production code to evolve it - refactor, refactor and refactor. After some two or more evolution steps we've got to the conclusion that:

• We have refactored common parts of the tests to the kind of testing framework.
• We might need to start writing unit tests for automated tests :)

The most interesting part is off course our testing framework, because it provide an abstraction layer over the application UI, and since "The behavior of the program should be internally and externally consistent" we essentially recreate application domain model in our automated testing framework. For example in our application we have a report tree, therefore in our testing framework we have a generic tree interface that represents a report tree in the application UI, we can inspect it via the methods of the "ui tree" that are essentially the same methods as tree that is used inside application, internally.

With the testing framework we've got some very nice advantages:

• Tests are more stable, since testing framework abstract the details of the UI that are likely to be changed. Which means that in case we change a tree representation we only need to change the framework and all tests will be unaffected.
• Tests have become much smaller and concise. Since tests are now operating on the very clean application domain (see discussion below about DSL) therefore even people with little test-automation experience can write them, and the most important understand and modify existing testcases which is the prerequisite for collective code ownership.
• Framework includes shared fixtures that enable us to create tests even simpler without looking into the details of the application page flow.

What was also very interesting to see, is that one essential aspect of the testing framework that it is application domain specific, automated testcases operates on the domain terms and domain objects the same as any other written test cases for manual execution. This fact off course make the framework not reusable but enable us to think about simple DSL to simplify test cases creation and modification.

At the end it was a big success, application we created need to work on 5 different platforms instead of planned 1, therefore by reducing regression testing efforts from 2 man/month to 30 minutes we benefit allot.

Now we are thinking about expanding it to the following directions:

• Try to create a external/internal DSL, something like JRuby or Groovy based
• So far we hadn't had big number of false failures , however if we will have them then could do a testing of the testing framework, i.e. before executing tests check that testing framework match the interface of the application.
  

ICQ - MUST DIE! DIE IN HELL!

Unfortunately my English is not good enough to express how I hate ICQ

For me it's one of the worst programms ever written by human. I hate it, I hate it!
It was a piece of shit not very good programm before, and fortunately I managed to avoid it, but recently it was installed on my PC by other person.

What can I say... it become even worse! It's amaizing what are those guys doing. How invasive they are.

After intallation together with the stupid browser toolbar this sh.tty tool made following changes:

Add it's toolbar, enabled by default, with the nasty and ugly icons they have (Icons are really UGLY!)

Changed default search engine to ICQ - why the h..ll they do it!! Why do I need this stupid search! It's amaizing!

Changed START PAGE to start.icq.com

Period.

You can imagine how long this ICQ was installed on my PC after that. Yes, 3 more seconds.

On it's last breath it was trying to open IE (my default browser is Firefox) and show me the feedback page, where I can express my feeling. I've done that.

I really hope this tool will die soon.

Design evolution

There are two significantly different approaches to the SW design (or SW architecture in small), evolution and revolution approach. Under evolution approach I understand creation of simplest possible solution that will work and satisfy requirements and then evolving it over time. Revolution approach will include planning phase which is much longer than in evolution case and therefore will bring some bigger architecture/design parts up front.

You can think about tree search algorithm, deep search and wide search, deep search is like quick prototyping or tracer bullets (copyright pragmatic programmers), wide search will solve one level of design at time.

So, in short, I really hate the design revolution, it is definitely needed sometime but evolution is much better.

I'm involved in the project where whole system is not even run, but we already have megabytes of the source code with 100 different features inside, but no end2end usecases are implemented yet.

It is always a trade off in some sense, evolving design is very hard, sometimes I'm thinking that I would better spend more time on this particular level (wide search) than going down or up (deep search). But most of the time it's bed temptation.

There are some clear prerequisites for the design evolution - aka refactoring, and it is:

GOOD UNIT TESTS

I can't really express how important it is. Without the unit test coverage system can't evolve, and to be honest sometimes we need to do a revolution to enable evolution.

Hm...

Evil Eclipse feature

Just found how nice Eclipse feature called Sort Members destroyed Hibernate mapping annotations

We had a model in our source code with annotations on it to declare a persistency options, something like:

/** List of all bets */
@OneToMany(fetch = FetchType.LAZY, cascade = { CascadeType.ALL }, mappedBy = "event")
private final List bets = new ArrayList();

Since I have another nice feature of Eclipse enabled all the time, it's Save Actions, every time I save file some actions are performed, such as Organize Imports, Formatting, Sort members.

So at the end I haven't really noticed that I've destroyed part of the mapping declaration, since Sort Members is somehow not working very well with annotations (I guess it sort annotations separately from the element they attached to :) ).

So, be aware about evil features.

Update:
Our mapping testcases found the problem and CruiseControl reported about it 1 minute after the commit. :) +1 to Unit testing and Continuous Integration

My first post in my new blog. Let's see how often I'll post here :)

Main topics I expect in my blog are:

1. SW Development
2. Agility
3. MDA (EMF?)

Hm.. some more staff...