Well, with a flight and an hotel booking in my bag I think it’s enough official, I’m moving to China, Hong Kong more precisely (there’s Beijing planned in 3 months but that’s another story).
Playing for a while again (after a good year spent with (alt).Net) with old good Java Code and financial sfuff like Fix, Securities and Fidessa. I’ve the feeling that’s gonna be fun and I’ll meet few fellow Twers there aka AgileHongKong Crowd 
Going East has been an objective in my life since I’ve read a Fortune Teller Told me, will I ever come back to Europe? We’ll see.
12
Feb
Posted by toni as alt.net, TWBlog, C#, Java
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.
Source: Reuters
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.
10
Feb
Posted by toni as TWBlog, Mac
I had few troubles upgrading to Leopard.
Basically the Mac didn’t start anymore(*).
The problem was on the hard disk nodes, so I reckon a disk check before trying to upgrade. If there are problems, the Mac disk utility will not help you, better to try with DiskWarrior.
If you’re reading this post because it’s too late and you’re in troubles, I fixed the system installing Leopard to my firewire disk, installed there DiskWarrior and fixed the disk from there. (credits to Luca for the pragmatic solution).
(*) I was sweating blood since the Lacie Backup utility “forgot” to backup all my iTunes library! :’-( Now I feel much safer with the time machine, great app.
