So I am giving away an Expansys voucher because I don't need it.
£5 off any order over £20. Enter voucher code in 'How did you hear about us box' or quote the code to your sales advisor.Leave a comment with your email if you need it (expires 25th December 2004)
Every time I venture down town London I get reminded that I should do so more often. London is a breath taking city but this fact is easily forgotten during the every day working life.
This splendid view was from a Greek restaurant, just by the Shakespeare Globe Theatre.
PS Brownie point if you can guess what the light/item in the top left corner is...
The Griffin Technology iTrip for iPod is a very good gadget if you want to listen to your iPod via a car stereo or a friends sound system.
Older car stereos that take cassettes can use cassette adapters with good results but many newer car stereos only have CD slots and no auxiliary input. The iTrip sends the music on a custom FM radio channel and may be your only option in that case.
All you have to do is to tune in to this channel and you have a wireless connection. There are slight differences between the FM band used in USA, Europe and Japan but the iTrip supports all three formats.
Since the iTrip gets it's power from the iPod (see the little connector next to the micro jack) there is no need for extra batteries. iTrip turns it self on when you start streaming music and turns it self of after 30 second of silence.
The design of the iTrip is very good. It fits like a glove on the iPod and looks like it should have been there by default.
To tune your iTrip to different channels you play short sound files that command iTrip to use a different frequency. The installation CD comes with UK channels from ~88-108MHz in 0.1MHz steps.
The iTrip costs around £30..
This girl will make it to your radio stations in the future. She just has to be discovered first.
So here is one of her demo songs, feel free to pass it on. Especially to music agents :-)
I'm with you - (demo song) (right-click, Save As...)
We have watched Proms in the Park occasionally on TV and were always amazed by the amount of people that showed up and how much they seemed to enjoy them selves. This year we decided to have a look.
The 4pm opening of the gates was delayed to 5pm, most likely due to additional security checks.
Björn Again performance was as tacky as expected but people around us seemed to love it. The band was bellowing out crowd pleasers like Waterloo and Super trooper. Spontaneous group dance routines broke out in various places around us.
The classical parts of the concert were performed by Ramon Vargas, BBC Concert Orchestra, Denise Leigh and more. Ramon Vargas braved the windy conditions and sang well know pieces from Tosca. The strong winds distorted the various performances a bit but were very powerful nevertheless.
Some people were prepared; others were very well prepared. Most had their blankets and pick-nick baskets with them including plenty of booze. Others had in addition brought foldable tables, inflatable sofas and portable lanterns. Clearly, it wasn't their first time at the proms.
I suspect that most people in the park, certainly our party, had been waiting for The Corrs finale as a highlight of the evening. It was loud and captivating as The Corrs can be. It was the first time we had the chance to see them live and it was worth the (5.5 hours) wait.
We didn't want to leave our golden retriever Ginger at home alone all of the day. Especially since weekends are her quality time days. So she came along, and was the only dog on ground, and behaved extremely well, and made many new (drunken) friends, and was fed to the bursting point...
Ok, I never thought I'd be saying this but I am.
I have GMail invites to share in case you *still* aren't on GMail.
It's a very good service with 1GB of storage space. If the so called privacy issues do not scare you away, let me know.
Leave a comment with your email address and a reason why *you* need a GMail account :-)
Cool GMail hack: GMailFS - GMail file system
Another clever Gmail hack - Gallina, a blog engine based on Gmail
We have asked this question several times in our organisation and I have seen it being asked many times in various web forums.
I suspect that the reason why there is no correct answer is that it all depends on your environment.
Some people report very good results with one approach but the same approach may not be efficient or not even functional somewhere else; such as in a clustered environment.
1. A common basic approach is to store the reference to the remote interface in the http session. Once it has been stored, all clients can quickly access business methods of the stateful session bean. You should use business delegates to communicate with your EJBs.
According to the specification (EJB spec 2.1FR, section 7.8):
There is no fixed mapping between clients and stateless instances. The container simply delegates a client’s work to any available instance that is method-ready.
This means that even with a single remote interface, the container will delegate what bean instance should serve a client call.
With stateful beans the case is the contrary. A remote interface will always guarantee calls are delegated to the same stateful session bean. This of course is crucial to enable a dialog between a client and a stateful bean.
2. The JNDI lookup of a home interface is the costly part of locating an EJB. As such, storing a reference to the home interface is a second approach.
Because application servers may use the create() method as load balancing trigger this approach may behave better in a clustered environment. Consider using the service locator pattern to collect all your service lookups to a single point.
3. A handle to an EJB has the advantage of being serialisable and valid between multiple JVMs. It seems to be the superior way of storing a reference to an EJB.
It is only possible to acquire a handle to EJBs that implement remote interfaces. With EJB 2.0, you will see that many EJBs implement local interfaces only to improve performance. Only the session facades will be exposing both local and remote interfaces.
To be future proof, it is safest to assume as little as possible about the behaviour of your J2EE server and avoiding short cuts.
This will ensure that your application can move from a testing environment to a full clustered, load balanced production environment or a different j2ee application server.
JNDI lookups of the home interface is the expensive operation so implement a service locator that caches home interfaces. Make sure all of your code is using this single point of looking up EJBs. It will then be possible to change the lookup strategy in the future if needed.