June 17, 2004
Ok, it's not really Google: it's Gmail. And it is responding but it is not able to process my request... ;-)
GMail is still beta, so it should not surprise me but... I'm so used to have Google available 24/7 that I was shocked when I received the error messages!
IMHO, it shows the achievement of Google, it made me forget that I was accessing a remote site on Internet, I just knew that I could use their service everytime.
And it also reminded me to not completely trust Gmail while it's in beta and wait a little before switching to it as my webmail address.
June 16, 2004
Today, I've received an invitation for a Gmail account (thanks to my account on Blogger).
It's too early to tell if I'll switch to it to replace my other webmail but right now, I'm really impressed by it and it lives up to the hype it generated...
It's the first I use a web application like a desktop application.
Congrats to the google guys!
June 14, 2004
That's the joy to work for a service company: every new mission brings new surprises...
While my latest mission was in a brick and mortar company, I've started today to work for a young successful startup. What's surprised me is that the brick and mortar company was more up to date wrt web and Java technology than the startup!
But the problematic of that company is quite huge and they can't afford to play with latest technology: they have to keep their legacy code and make it work 24/7.
Part of my job'll be to update the technology they used without interfering on the production. The fun begins now!
June 11, 2004
I've been very slow and I've just realized today that the next version of Java 1.5 and MacOS X 10.4 share the same codename "tiger".
It's also quite funny that they will be officially presented at the same place (Moscone Center, San Francisco) at the same time (June 28) but at two different events (JavaOne for Java, WWDC for MacOS X).
I hope that in the keynotes on Tiger (MacOS X), Steve Jobs will announce the availability of Tiger (Java) soon. I've ordered a PowerBook recently and the only thing which annoys me as a Java developer is that I won't be able to play with Java 1.5 on my new toy...
Steve, if you hear me, don't wait too long before releasing Tiger 1.5 on Tiger 10.4? ;-)
June 11, 2004
I've just finished to read "Je Suis Legion" ("I Am Legion" in the US, will be published by DC), a graphic novel from Les Humanoides Associes written by Fabien Nury illustrated by John Cassaday (Planetary, Captain America, Astonishing X-Men) and colored by Laura Depuy (The Authority, Planetary).
The story seems quite similar to the Carrion Comfort from Dan Simmons (from what I've been told of that book).
The story takes place during the WWII and centers around psychic vampires.
John Cassaday is at the top of his form. His pacing is very cinematic (like in Planetary). His drawings look even better on a oversized format and it makes me looking forward to the Absolute edition of Planetary (and a future hardcover of his run on the X-Men!).
There's a lot of introduction in that first volume but the premise is interesting and there's enough mistery to keep me waiting eagerly for the next two volumes of "Je Suis Legion". And the art is top notch.
A recommended graphic novel.
June 11, 2004
I recently read two differents papers related to distributed communication which reminded me of the pitfalls of designing applications which treat remote components and local ones the same way.
The IBM paper discusses the use of some J2EE APIs outside a J2EE container.
This topic is very important to me. I tried to achieve that goal when I was working on JORAM and JOTM: to provide J2EE services to smaller applications so that they can use these services without a full J2EE server to take adavantage of only one or two features (have you ever tried to write an applications using JMS messages and Distributed Transactions outside a J2EE server?).
So I think the idea of Somnifugi is an interesting one.
However, what bothers me in the IBM paper is when the author writes that
Somnifugi also offers another significant benefit: It is now possible to develop components that use JMS interfaces, and then decide at application deployment time whether to use the fast, in-memory Somnifugi provider or a heavier but more reliable provider such as WebSphere MQ. The advantages of being able to defer this choice to deployment time are considerable -- especially because requirements can change over a project's lifecycle -- and provide an opportunity for code reuse that would not be practical with a homegrown messaging layer.
It's striking to read that just after reading the notes on Distributed Computing which states that
Programming a distributed application will require the use of different techniques than those used for non-distributed applications. Programming a distributed application will require thinking about the problem in a different way than before it was thought about when the solution was a nondistributed application. But that is only to be expected. Distributed objects are different from local objects, and keeping that difference visible will keep the programmer from forgetting the difference and making mistakes. Knowing that an object is outside of the local address space, and perhaps on a different machine, will remind the programmer that he or she needs to program in a way that reflects the kinds of failures, indeterminacy, and concurrency constraints inherent in the use of such objects. Making the difference visible will aid in making the difference part of the design of the system.
It seems wrong to me to believe that you can design your application with Somnifugi and switch later to WebSphere MQ as an afterthought.
There are fundamental differences between using a distributed entreprise messaging system and a thread notification library. Somnifugi is accessible through JMS interfaces but given its nature (inner-VM, thread notification), it's misleading to think of it as a JMS implementation.
For example, using Somnifugi at development time means that the JMS message endpoints must be in the same VM. Switching to WebSphere MQ later does not change that fact. And this can not be easily modified at deployment time. You'll have to redesign your components to take into account the remoteness of the endpoints (what about guaranteed delivery, persistence, acknowledgment and do not forget the Eight Fallacies of Distributed Computing ;-)
When I was working on JOTM, it was one of my main goals to provide "easy" transactions to JSP/Servlets developers. So that they could seamlessly integrate JTA transactions to their web applications. However experience showed me that you can't really replace DB transactions by distributed transactions as an afterthought. There are some differences which makes it dangerous and difficult to switch between two similar but different concepts.
The IBM paper reminded me of that. Somnifugi and WebSphere MQ shares the same interfaces (JMS) but there are some fundamental difference which makes switching between the two really hard.
This entry is in no way a critic of Somnifugi. I think there is a lot of potential for that project (especially for prototyping and unit testing JMS application) but I also think that developers have to be very careful about the context before using it. IMHO this is a good counter example of YAGNI! ;-)
[This reminds me of the EJB 1.1 specifications where you were able to access entity beans regardless of their locations. This mistake was corrected in EJB 2.0 where the access to entity beans were marked explicitely as accessible only locally]