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.
Tuesday, December 27, 2005
What's Your Favorite Design Pattern
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.
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.
Professional Portal Development Book Review
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.
Tags: book review
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:
- A presentation of Model 1 and 2(X) Architectures in relation with Portals. It could have been more detailed.
- Example use of some Design Patterns in a Portal although the example use is really just one sentence and some Patterns uses are too obvious and not related to Portal (Singleton, Template Method).
- Web Services for Remote Portlets.
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.
Tags: book review
Professional Portal Development Book Review
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.
Tags: book review
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:
- A presentation of Model 1 and 2(X) Architectures in relation with Portals. It could have been more detailed.
- Example use of some Design Patterns in a Portal although the example use is really just one sentence and some Patterns uses are too obvious and not related to Portal (Singleton, Template Method).
- Web Services for Remote Portlets.
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.
Tags: book review
Wednesday, December 07, 2005
IBM Websphere Portal Strategy
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.
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.
IBM Websphere Portal Strategy
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.
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.
Subscribe to:
Posts
(
Atom
)