Many thanks to Dan that pointed out on our internal ML to Qi4J.
Quoting from the home page:
Principles
- Composite Oriented Programming builds on some principles that are not addressed by Object Oriented Programming at all.
- Behavior depends on Context
- Decoupling is a virtue
- Business Rules matters more.
- Classes are dead, long live interfaces.
Are you already worried that they’re using xml to do this?
Qi4j is trying to address the flaws of OOP and introduce Composite Oriented Programming to the world, without introducing new programming languages, or awkward constructs. Heck, we don’t even use any XML.
After at least two years of Hibernate and NHibernate experience I can say that I know what’s going on, I can’t still say that I know very well (N)Hibernate but I wanna share some learnings.
The logger is your best friend:
When sometimes goes wrong, the logger (or at least a profiler) will help you, it’s awesome to play with a database like we play with objects but I have the feeling that sometimes we forget that on a couple of layers below we are doing some good old SQL!
(N)Hibernate is not meant for:
Bulk data manipulations: use sqlBulkCopy in (.net) or upgrade to a version > 3.1.1 on Java Hibernate
Free developers from understanding the database: it’s nice to hide the DB structure but the DB is there, and it’s not OO!
Free developers from understanding (N)Hibernate. I sow many times in developers this approach: entusiasm followed by criticism followed by hate It’s very easy to do simple things and terrible then to fix bugs or understand some stack traces. It’s a great library and it’s not easy to use. A copy of hibernate in action or of nhibernate in action should be always present in a team playing with it.
Let you forget the profiler: as mentioned before it’s the best way to understand the complexity of your queries, it’s easy to end up with a cartesian product result from a query or execute unuseful queries, especially when playing with multiple joins and criteria queries.
Do not generate queries using dynamic strings: queries compilations are cached (similar to query plans), it’s a nice and useful feature, especially talking about performances. Use parameters to allow reuse of query plans.
Lazy loading: if you don’t use lazy loading (default now) you’ll end up having all the DB in Memory, if you use lazy loading you might have the select N+1 problem…
Usage patterns: session per request (good for webpages, opening the session on request start, dispose on request end) Vs the session per conversation, good for rich client application. I’ve the impression that in this second case you loose a lot of the hibernate power…
Bags, lists, sets… : choice is yours but keep in mind that especially in a domain driven design you could have some problems having methods playing with (lazy) collections in the POJO/POCO objects. And the cost of changing from one mapping strategy to a different one can be high.
Optimization: you’ll have performance problems, it’s sure, you’ll have it, I don’t believe in preemptive optimization but an eye on the profiler and one on the integration tests timings could help you to find earlier problems that you’ll see otherwise when it’s too late (i.e. in production!)
FRANKFURT/LONDON (Reuters) - British chip designer ARM (ARM.L: Quote, Profile, Research) will demonstrate a prototype of Google Inc’s (GOOG.O: Quote, Profile, Research) Android mobile phone platform in action next week at the world’s biggest wireless fair, a source close to the company said.
I’ve played a bit last week with Android, it’s a really promising technology.
It’s a full stack, based on Java, it’s open and it should be really a “write once run everywhere” technology (not like JavaME!).
It’s a big change: they first wrote the OS, the software and then finally they found an hardware to support it. It might really work.
I like to think that the Google team was so frustrated working with J2ME for their (very nice) JavaME apps like GMail and Maps that they suddenly decided to write a full OS to support their ideas.
I remember an old Cédric Beust post about his intense, crazy experience on writing the Gmail app.
Is it only a coincidence that he’s working on Android?
Android offers many things, missed for too many years by Sun on the JavaMe platform.
- Deep phone integration (ability to interoperate between apps, make calls and so on with the phone)
- Ready to use “widgets” like maps
- Pretty nice pattern to write an application: what was a MIDlet in the JavaME world is now and Activity.
- Easy to write apps from any platform (yes, also Mac!)
The battle begins now, I-Phone: closed source, basically only web apps, nice screen with nice features or G-Phone. I can’t predict who’s gonna win but I’m sure that there are some losers on this battle already: Sun Microsystem, Nokia, Microsoft: all the old good companies, unable to make any decent progress in the last years. (where is MIDP3?!!!)
I’ve been very frustrated with the JavaME technology, I hope that Google will change now how things works in the mobile world.
It will be an honor to speech after the key note of Tim Mackinnon at the AgileDay organized by Marco in Bologna, I’ll present how we went from amber to green in four weeks in our last project in London, presenting a speech that Pat and I were setting up for the Xpday in London, but we were fired off cos it was “just” a description of a perfectly aligned agile/XP project, they said(!).
It will be also cool to speech again about Domain Driven Design at the Javaday in Rome, with 700 expected attendees that’s now the biggest Java Gig in Italy, it will be the 3rd refactoring of the slides presented since this summer, more focus on mocking, testing and IOC as well, since in Turin I had a lot of questions about it.
Slides in English coming soon here, after the events.
It’s very easy to do simple things and terrible then to fix bugs or understand some stack traces. It’s a great library and it’s not easy to use. A copy of 
