The language should make it possible to equip a class and its features with assertions (preconditions, postconditions and invariants), relying on tools to produce documentation out of these assertions and, optionally, monitor them at run time.
It should be possible for the author of a class to specify that a feature is available to all clients, to no client, or to specified clients
A well-defined type system should, by enforcing a number of type declaration and compatibility rules, guarantee the run-time type safety of the systems it accepts.
It should be possible to write classes with formal generic parameters representing arbitrary types.
I wanted to reply to Diego Parilla post about scalability, but my reply ended up being too long not to post it over here. I don’t know if I am the only one here but I don’t fully understand his post and arguments.
Clustering the web server and clustering the model are just two parts of clustering, not exclusive.
In a LAMP application, clustering the model is traditionally done by clustering the DB (MySQL) which is a no brainer. Clustering the web server does not always implies sharing the “HTTP session”. For example you can limit yourself to use cookies. For many web apps this works well.
For more stateful web apps, there are strategies to avoid clustering the session, you can make one client attack one server only for his whole session duration. Another strategy is to use DB where you would use a session. This is actually reported to work quite well. If my memory is right, this is how Friendster rewrote its app (used to be Java and session based, moved to PHP+DB).
EJBs are not about clustering the model more than Spring, they are about clustering the business logic. And I don’t see how EJB3 is more scalable than Hibernate.
The latest well done (e.g. blind) listening test comparing Ogg, MPC, MP3, AAC at about 180kbps shows that Ogg is superior to all other compressing formats. It’s not that easy to find relevant tests. Many people claim to be able to notice huge differences between CD and MP3 and yet, but confronted to a blind listening test, they are very surprised how difficult it actually is. Hydrogenaudio has a good community of audiophiles.
Unfortunately Ogg is not supported officially in iTunes and not supported in the most popular hardware (iPod). It’s been a while now Ogg is out, and even if it is a superior format, unless Apple embraces it, I don’t see it succeeding. I wish Apple would make a tiny effort.
In Java it is possible to play ogg files using Jorbis but I did not find any useable Java player compared to Windows foobar2000 or Linux XMMS or Apple iTunes.
Once in a job interview, someone asked me
What’s your favorite design pattern?
I was first surprised at the question. Usually a design pattern is about solving a problem not about a personal preference. I wondered if it was a trick question of some sorts. I was hesitating with my answer and asked more about the meaning of the question. I just had to really give the pattern I liked the most! I really should not have but I ended up pleasing my interviewer and said “the decorator pattern”. At least its name is somehow related to arts.
Then he said his favorite one was “the template pattern”. He was really into it because he could use it anywhere. For him it was like the best thing since sliced bread.
Sheesh! just an abstract class. What kind of pattern is that!?! Design Patterns discussions can be really dull.
I just finished reading Professional Portal Development With Open Source Tools (Wiley).
The Good:
I enjoyed Chapter 1, it gives a good presentation of Portlets for someone who does not know much about it. It is a chapter one can use as a reference to verify some specific details of how Portlets are working. It is a bit similar to JSR 168 specifications, but I found it more detailed and well written.
Beside Chapter 1, there are here and there useful information:
The Bad And Ugly:
I was disappointed by the remaining of the book. While it is good to mention Lucene, Apache James, OJB, Jakarta Slide, as those can be useful in Portal development, the book does not provide any useful information on those products. It would be difficult to put all that in just one book. The author merely gives kind of hello world examples for each technology, which I find quite useless.
A quick presentation of software methodologies is again quite useless, and not what we expect from that kind of book. If I want to learn about software methodologies, I buy a book about it, I don’t buy a Portal Development book.
The rest of the book really looks like a list of disconnected subjects, the important ones are not given more attention to the non-relevant ones. Portal Navigation is a problem you will encounter in any Portal development, but you won’t find much in the book except a short example. The author also writes with way too many words for the content about CVS, Subversion, JUnit, AntHill, Scarab. And then he goes on about Java Web Start, woohoo! Yes, it almost reads as well as a resume full of keywords.
Summary:
Don’t buy this book.
I digged a bit deeper in a current project where they use IBM Websphere Portal Server (WPS) with IBM Web Content Management (WCM). I found out that both products collide and disintegrate.
WCM is like a regular content management system, quite flexible and performant on its own. It has a nice way to separate layout concern from content concern. It has a flexible cache. It has a user repository to set different permissions. Its architecture is even so well done (very modular) that you can tailor it to your needs to do things a content management system is not supposed to do. It could do most of what you would do with a Portal system. And that’s the problem.
WPS is a Porlet server, now compatible with JSR 168. You can again do the layout of your portlets, you have an administrative interface to handle them and one to handle user permissions. There is a caching system although it’s not very clear how that works. Standard administration Portlets seem awfully slow to use any cache. To be integrate WCM content in the Portal Server, they ship a WCM Portlet. While JSR 168 API is recommended by IBM, the WCM Portlet is not a JSR 168 one.
So you have 2 products where you can layout your pages, and have dynamic behaviour in them, locally as components, easily manageable. One can be embedded in the other, but it does not make much sense, because you would then just use a tiny part of its possibilities, and its flexibility will be more a burden (extra abstraction layer) than anything. The integration of the 2 products is very superficial. Although recently they can share a common user repository, the WCM portlet does not do any caching of WCM content, linking between content and portlets is a very cumbersome task. IBM provides tips to build a framework that does just that. All that for not using most of the WCM possibilities and always having difficulties in defining their roles and using them collaboratively.
Now, if you look at how JBoss Portal works, and what features they focused on, you will see a well designed solution whose aim is to build pragmatically a Portal using Portlets. They have a very simple content management system used to administrate HTML snippets. Content is put inside the Portal page using CMS Portlets, the layout is the one you specified in the Portal page. They provide automatic caching of CMS content and easy to use links. Integration with their CMS is already using JSR 170 standard. You can plugin other CMS systems easily. IBM strategy with their WPS+CMS does not look very good, and their version is currently 5.1, soon 6.