Slashdot Mirror
Developing Applications with Java and UML
Each chapter begins with a brief summary and a list of the goals. After reading the book through, both should be useful. Each chapter also closes with a 'checkpoint' that summarizes what has been covered in the chapter and what is to come.
The first chapter sets up the entire book by outlining some of the project problems encountered in software development. Once the author gets into development models, the Unified Process from Rational Software, a huge and detailed software process, is introduced. The book focuses on only using the elements that provide the biggest 'bang for the buck'. The Unified Process is the focal process of the book, but the Synergy Process is a free alternative, only lacking some additional guidelines and how-to's. A short overview of UML is covered, along with its' place is in the software process. He notes that a project that just uses UML in a vacuum without a sound process and plan will fail.
The second chapter briefly discusses the Java language alongside the concept of Object Oriented Programming. Experienced Java programmers could skip this section if they wished. The section is worth skimming as a lead-in to the explanation of how Java and UML are a good fit.
Chapter three, Starting the Project is the first time the book delves into the meat of how to structure a project. The example scenario that is followed through the book is introduced, and throughout the book real-world examples are used that relate to the sample project. Every theory in the book that is translated into some kind of example the reader can pull apart and examine.
Through the next few chapters use-cases and class diagrams are covered, leading up to building a user interface (UI) prototype. Personally, I've never used UML for anything but sculpting class diagrams for export. This is the point in the book where I started to see how the rest of the project is able to use UML and tie it all together. Being able to model the classes and easily export them is very powerful, but even more so when combined with the rest of the ways you can employ UML in your project.
The following chapters are much like the first few that began to talk about the sample project. There is no Java code until chapter 9, halfway through the book. This is not the book to get if you are only interested in how to use UML as a base to dump out some code.
Throughout the book the content remained interesting, and relevant. Do not expect to sit down and read it from beginning to end. There is a great deal of material covered and no topic that was inadequately explored. Using the sample project consistently throughout the process was invaluable, along with the samples and source code provided. Alongside the process, the real life anecdotes and comments provided were a welcome addition instead of an intrusion. The author is someone who's seen the mistakes that could be avoided. For example, an application with 70,000 lines of Java code that only contained two classes.
Having talked about the depth and detail of the book, this was also one of the bad points as well simply since it takes so long to get through. People already well experienced in running a project with similar phases will find it much faster reading. The other issue is the expense of the tools and products involved. Rational Rose, the Rational Unified Process and WebLogic are rather expensive products. Thankfully there are alternatives that he mentions in the book, and others as well. Visio, the Synergy Process and Tomcat are all possible alternates. Surprisingly, Tomcat is used in his example setup.
I had left the rating at 8 throughout most of my reading while considering the positives and negatives. However, when I finished the book I bumped the rating up to 9 simply because of the wealth of information I learned. Anyone aspiring to run a team project with Java should read this book. In the corporate arena, most of the battle is not the code, but understanding what the users want and what will be created. Following any kind of process will improve the result, even if only a few key elements are used.
Chapters:
1. The Project Dilemma
2. Java, Object-Oriented Analysis and Design, and UML
3. Starting the Project
4. Use-Cases
5. Classes
6. Building a User Interface Prototype
7. Dynamic Elements of the Application
8. The Technology Landscape
9. Data Persistence: Storing the Objects
10. Infrastructure and Architecture Review
11. Constructing a Solution: Servlets, JSP and JavaBeans
12. Constructing a Solution: Servlets, JSP and Enterprise JavaBeans
Appendix:
A. The Unified Project Plans
B. The Synergy Process Project Plan
C. Estimating Projects on the Basis of Use-Cases
D. Sample Project Output
E. BEA WebLogic Application Server
You can purchase Developing Applications with Java and UML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It's truly a mode of thinking worth learning.
Good review. The book's topic is pertinent to those companies that are implementing system software, stuff that's going to be around for decades. For the rest of us working on consumer software, this kind of thing doesn't help much at all.
Sure everyone likes to say that architecture is the most important phase because from architecture comes all other activities. However, when the timelines are short and ship dates are measured in months instead of years, having a serious system in place hampers more than it helps.
And consumer software written in Java? Nope. This book is totally aimed at those banks and other large-scale business systems.
I have been pwned because my
Another coffee book to place on the shelf ... oh goody!
HallmarkOrnaments.Com
I like the concept of UML, it makes it easy to abstractly define an entire program and then quickly put it together in either C++ or Java.
Unfortunately though, there are a lot of programmers that that UML and instead of having the simple links between the methods and classes, they have these jumbled messes because... well actually I don't know why. I am thinking it is because they don't want to spend the time writing quality UML and instead program something that works. (I know the feeling, I hate designing before programming, but you need to do that if you want to make it easier to support in the future.)
The key reasons for UML and advances is exactly that though. You (and others) need to be able to easily support your code in the future. If it is a jumbled mess of spaghetti code, or even worse if it is a complex mess of command made solely to speed up the code that very few will comprehend. Then you end up with a large problem. When something needs to be changed, it becomes incredibly difficult to decide how to do it.
I agree Java is pretty slow (it has sped up a bit over the years, but it still isn't optimal), but these OOP concepts of UML and properly designing easy to understand code should be applied over a need for speed. Hell, if you want to speed up the code a bit more, use C++.
I think programmers need to stop worrying about speed so much, and start to realize that these programs need to be easily workable and last. UML provides just one more way to keep them easily managable.
~ kjrose
Surprisingly, Tomcat is used in his example setup.
Surprised? Most Java developers use Tomcat for a servlet app server (not a full blown app server, but you can have that if you tie-in JBoss). Tomcat is great for development if you aren't dealing with EJBs.
Most Java developers I know use Tomcat before an app server is chosen so they can get stuff working, and will stay with tomcat unless the customer has a license for an expensive appserver or they are using EJBs.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
What does User Mode Linux have to do with program design? I thought Java was supposed to be platform independent.
this book is incredible. It helped me create some interesting Java applicaitons....
Paul Read's book is one of the most applicable, thorough, and "practiceable" UML books to date (and I have read a lot of them). One of the concepts that was a real breakthrough for me was the event list/table. There always seemed to be a step missing in the transition from a client requirements document to use cases, and the notion of the event list was it. A number of projects I've worked on have suffered from the use cases being far to granular, resulting in a nearly unmanageable number of them. The event list serves as the perfect tool for eliminating this problem.
While the sample project is not unnecessarily complex, it provides the level of detail necessary to apply RUP and UML to just about any Java project. Furthermore, most UML books fail to move beyond the theoretical level and provide concrete examples. This is not the case with Java and UML. This book is written in a style that is easy to read and will have you familiar with the concepts and applying them to your own projects in a matter of days.
Do you even lift?
These aren't the 'roids you're looking for.
Yeah, like that's ever going to happen. How would we know how elite a programmer was if he didn't just hear a problem and then work like a maniac for a week and pull a rabbit out of a hat? We can just work out the problems as they appear in the code as it is being produced. Easy.
;P
Besides, a formal, methodical approach to software development is just so... arty! Nothing for the macho h4x0r to sink his yellowing teeth into. Real programmers just grab some wood and nails and start hammering. I mean, how many buildings can you name that were built on paper first?
I've got a bad attitude and karma to burn. Go ahead. Mod me down.
If you want to buy the book, go to the Bookpool site, much cheaper. Here is the link.
What I'd like to know is, did all these people who come up with all these new methodologies only decide to think these up after Java was created? In other words, why weren't these methods ... and all the toolkits and such that are also mentioned ... introduced earlier? Why now? I mean, was it the fact that the Java language came out, or did it just take them this long to figure out these things? Some of these methods could have been useful in 1982, or even 1972, for example. But if the people who thought it up weren't even in college by then, I guess that could explain it.
now we need to go OSS in diesel cars
Really, I thought it was just MS riding on IBM's coat tails. Like how MS dumped XLang for something IBM came up with.
Come on, it's like those fitness books written by the founders of "health" companies that peddle steroids. All they're doing is trying to sell Rational's (expensive!) modelling software.
From Amazon.com:
There's a saying in certain UML circles:
"Shit doesn't get smaller if you draw an UML diagram of the bowel that produced it."
UML gets a bad reputation because most people think that because they (spent a fortune and) got Rational Rose they suddenly know something about program design and software architecture.
For the experienced developer UML is just another addition to the toolbox. They understand when, but much more importantly, when NOT to use it.
Warning, the post above is copied verbatim from a comment on Amazon. There are other posts in this thread that are also copied verbatim, by other users. Somebody is trying to 'spike' this slashdot review...
You don't get it: Java/UML is a tool for managers to hire more people and delay timelines for real deliverables, as in "Let's see, I need 4 Rational Rose power users, they'll need a couple months for initial class hierarchy design, I'll need a submanager to supervise them, (you know, this system is going to be damn hard to actually make work, hopefully the requirements will change and we'll never have to finish this).."
http://www.cgisecurity.net/lib/J2EEandDotNetsecuri tyByGerMulcahy.pdf
As I was installing VS.NET the other night (flame me, whatever, some projects have to use it, part of my gig) I browsed throught the old EULA for shits and giggles. I came to a part about java as I was skimming, and it caught my eye, so I slowed down to read that entire section. It said something to the effect of "Java is not fault tollerant and should not be used to create applications for/including life support systems, weapons sys, Hazardous Materials systems, etc..."
Just thought that was a little funny. Shall we use VB instead for out nuclear tracking systems?
I've looked at UML, saw its array of different diagram types and wondered if there are better alternatives.
I'm not very knowledgable about it, but it seems there isn't a clear tracable path from the use cases right down to the source code. It seems that UML results in work that is thrown away when moving forward in a project. For example, if use cases really help in capturing requirements, why can't the work spent capturing requirements be directly applicable to the next stages of development (i.e., the requirements work drops right into the next stage without needing to manually recapture the requirements in the next stage)?
Is UML really more efficient than I think it is, or are there better notations out there that can further streamline the path from requirements to coding?
Healthcare article at Kuro5hin
On a related note, what do people think of EJBs?
EJBs (especially entity beans; session beans (especially stateless ones) are ok, though for 90% of uses regular java classes and static classes could do the same thing) seem to be the antiperl in some respects; it makes the easy jobs difficult and the difficult jobs impossible.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
Just want to mention ArgoUML, a Opensource UML tool. Then I wanted to ask, if anyone of you has already worked with UML in combination with PHP and MySQL. I've just started modelling my database along the UML profile for data modelling and like it so far. I hope to generate some code from it, but there are still quite a few sources to write...
Is it possible to use UML concepts with Fortran 77? Now that is a book I would buy.
This book has the advantage that it lays things out step by step. Even when there is not enough time to follow through a full design process, having the knowledge well laid out in your mind when you do your quick design is an immense help. With most books seeming to jump that "middle step" that everyone is expected to know, this one plants it right in the middle making it easy and clear to follow.
Speaking from experience, I can tell you that using UML and Java together can be a very rewarding (and timesaving) experience, so I applaud this book's direction. Whatever methodology you choose, I feel that software impelementation is only going to get better when companies realize that time spent doing discovery and design is as (or frequently more) important than the time spent coding. My current contract is just now learning this, the hard way...
They look pretty 'l33t to me
And me too. I was implying that truly elite programmers think about things deeply, then design, and THEN code. I have just noticed a tendency for geekdom to promote "seat of the pants" design. Which is right up there with improvisational interpretive dance with mimes.
I've got a bad attitude and karma to burn. Go ahead. Mod me down.
This book is for projects made in heaven - i.e. the defence and NASA contracts where there are tons of money. Most development simply does not have the money or time share - it is unfortunately called the real world. The book is okay if the reader likes to escape to a new world order of unreality.
RUP, IMHO comes short when it comes to developing software that is really valuable to end customer. Check out the demo here. RUP wants to divide the whole s/w development process into stages and proceed in a systematic fashion where progression into one stage completely disqualifies the previous stages. The problem is that most of the times the customer never really understands what is possible and what really is required to address a business and/or process need. Which really translates to improper requirements. This is also the cause of user dissatisfaction because by the time s/w arrives the business needs/environment may have changed or shows symptoms of the same. This is very disconcerting to the end customer for his time and expenditure.
This is why Extreme Programming is a bit more applicable to what we know about s/w development, how much can we communicate to the end user, how can we make it easier for developers to let users participate in all stages of development.
That said, I actually like UML a lot. The use cases work in larger contexts while class diagrams work in narrow contexts i.e. 2-4 people can really understand what you are trying to communicate. The sequence diagrams are priceless, because even managers can follow some of it. I like to combine class diagrams with a design pattern [GoF] applications.
Rational now has an extreme programming plug-in. That very statement makes me run in the opposite direction. XP is often compared to Open Source, where users really know what they want and the whole process is more conversational rather than a contract that's been handed off to a developer.
The article mentions Viso, and rational rose both of which are expensive windows programs. So does that mean cash strapped geeks are forced to use a windows box, download a crack and use that? No. There are good alternatives that are free and don't need windows. The first one that comes to mind is Gnome's DIA.
To quote Gnomes web site "DIA is a drawing program, designed to be much like the commercial Windows program 'Visio'. It can be used to draw various different kinds of diagrams. In this first version there is support for UML static structure diagrams (class diagrams), databases, circuit objects, flowcharts, network diagrams and more."
Another option is Argo UML which is also free and programmed in java Argo
(* Fortran is procedural not oo; so no UML *)
Although UML is not *purely* for OO, it is biased towards it.
Like I say in the PHP message, the industry is currently biased toward OOP dispite the fact that many shops reject many OO concepts and show no signs of changing that aspect.
Non-OO'ers are nose-thumbed. Well, I finger OO in return. Get some fricken real OO evidence instead of brochure babble and we might just change.
Table-ized A.I.
Any good Java engineer knows this stuff already.... Maybe not the specific UML diagramming language, but there should be nothing new here. I.e. if you want to learn uml, get a uml book. :)
Managers and designers read "Design Patterns" and
not "K&R". Hey, if they can't hack "K&R", okay,
at least read "Mythical Man Month". The problem
is managing complexity. You *can* do it with
coding and re-factoring as you go along. Of course,
design is important and good design can lead to
good programs. Unfortuneately, good design
can also lead to bad programs. Pretty pictures
do not a good implementation make.
(* This book is for projects made in heaven - i.e. the defence and NASA contracts where there are tons of money. *)
NASA has money to burn? (Rocket pun not intended.) I don't think so. Perhaps you really meant "good at wasting money". IOW, it is the output process and not the input process.
UML diagrams can certianly turn into a money pit if you are looking for ways to increase your staff and look big and busy.
Perhaps a project that fails that has tons of diagrams to show for it will not look as bad if it fails and all the walls are empty. IOW, it is a manifestation to the superficial types that "at least we gave it a good effort".
It is yet another technique in politics-heavy orgs to fail yet not look bad.
I am waiting for the book, "How to bullshit your way to the top in IT". There is one about contractor scams and trickery, but I don't remember the name of it right now.
Table-ized A.I.
Rational now has an extreme programming plug-in
Aren't they near bankruptcy? I keep hearing rumors. I never really liked them. They seemed to specialize in "bandwagon" tools.
The problems with UML tools is that they [sometimes] generate skeleton code out of your models, and then you go in and fill in the "meat". However, if you change the model then either you lose your changes (i.e.: the meat you put in after countless hours of effort) or you have to forget about changing the model with the tool and do changes yourself.
So what I think we need is some form of tool that always matches the model to what you're programming. More or less like what IDEs do when you're designing a GUI while the write code automatically to represent the GUI, while allowing you to change the GUI code and have those changes reflect in the GUI design itself.
With a tool like that, it could also be possible to generate a UML schema from your own spaguetti code, and then change the model visually, with the net efect that the tool would refactor your classes, method calls, variable names, and packages to match the model.
And of course, with a such a tool you could (and should for all new projects) start with the UML in visual mode, and then fill in the specific code.
Note that I've seen countless tools that claim to do this, but none of them really give you enough freedom to make changes on the code or in the model.
Why couldn't they fit it all into one class? It simplifies the UML, and you don't have to look in two different places for the code.
...more about. there are so many books, articles, whitepapers, tutorials, tips, sites, technologies, frameworks, etc.
:-)
:-)
I think it didnt add to my productivity a lot
Good luck with your java study
UML = Unified Modeling Language
The race isn't always to the swift... but that's the way to bet!
Well it looks like I'm going to be buying another book. I've been looking for a good way to document object-oriented programs for a LONG time. I've heard about UML and browsed a few web pages but just didn't really understand it well enough to see it's value. Maybe this book will get me through the learning curve.
Could someone who really understands UML tell me if it will handle documenting object-oriented programs that use third party objects? For example, if I code something using Borland's Kylix, I may not have the source code to some of the components that I'll be using. How does one effectively document in this situation?
The race isn't always to the swift... but that's the way to bet!
... after Linus Torvalds starts using it.
1. You must mean OS independent - platform is too general word and besides OS it may mean architecture (web 3-tier vs clent server), app-server (EJB vs CGI), framework (components vs templates) and so on.
2. Java will never be OS-independent. Compare the user management and permissions in *n*x vs NT. File system concepts, multi-thread model. There is no such thing as OS-independent language. And, by the way, there is no such thing as a platform independent language. Even English is used differently: "threads" in NT and Linux :)
3. Java suffers from its attempt of being OS-independent. Covering OS specific problems, Java doesn't use OS benefits either. As a result Java is good only for OS-independent domains: UI applets, simple servlets, XSL transformers. As for communications - it cannot be OS independent and thus it is not good domain for Java. EJB is closed architecture (only EJB to EJB), so is JMS. I hope SOAP eventually, spreading everywhere, will help to integrate Java into different platform environments. But it is not gonna happen anytime soon. At least untill all major operating systems will implement complete enough API based on SOAP. That is about Java as a "consumer of OS" By the way, as a "provider of OS" (like startup and configuration scripts, command line interface, various listeners and daemons), Java is even in worse shape (long startup time, big in memory, bad memory management).
4. There are other OS-independent domains, like AI and text processing, but Java is not good in such domains either. Java is a single-paradigm language - you have to use only OOP (no FP, no LP). And OOP in Java is one of the worst OOPs among other programming languages - no multiple inheritance, no meta-object protocol, no type inference, no parametric polimorphism. I don't think this will be ever improved and thus Java is really limited to applets, servlets and XSLT.
Less is more !
The last time I had access to rational rose (about 3 years ago), it handled this just fine.
It generated special comments, between which you but "the meat". When you changed the model, it kept the meat.
If you deleted a method, it gave you a warning and would keep the meat code for one cycle. If you ignored the warning twice, the code from the deleted method was gone.
But if you were carefull, it did not have the problem you describe.
I would have kept on maintaining the design/code this way if only it had been able to emit the DLLEXPORT between the keyword "class" and the name of the class (this was C++).
Since the code in question had to be packaged in the DLL, I had to quit using
the "forward engineering" code generation.
But if you were not doing a C++ DLL, you should not have this problem.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
Any? Try to apply this book to CLOS or OCaml or O'Haskell or Oz and see the limitations.
Less is more !
- Why Functional Programming Matters
- Haskell: The Craft of Functional Programming Second Edition
- FAD: A Functional Analysis and Design Methodology
- Structure and Interpretation of Computer Programs
- Concepts, Techniques, and Models of Computer Programming
- CLOS Meta Object Protocol
I've just been tired from java problems since the bigining of Java waiting when Java will be improved finally up-to the production quality and it's still not there.So, still keeping some Java projects, I've decided to try something else. First I've tried was Python, which I used for while in OS automation scripts, but now I've tried to use it for a bigger scope: "servlets", UI, JMS-like messaging, XSLT, text processing, RDF, and finally in some AI stuff using FP, which is poor in Python, but at least it is there. By the way, OOP in Python is also far away from being perfect. It is slow on massive calculations, although it is fast enough for script -based OS automation, UI, "servlets" and XML processing (but not on huge files). it is dynamically typed and it has lazy evaluation - both very important features for messaging. Python is less known, comparing to Java, but its community is not really tiny as Perl and other *n*x hackers usually know Python.
After Python I've tried Erlang, Oz, OCaml, Haskell. I think Erlnag is ready for distributed messaging and for OS automation. The others are not - the lack of libraries. Although, each of them, Oz, OCaml and Haskell, has a very great potential if some big corp will do support. Any of these three may need just 10% of Java marketing to collect a crical mass and become recognized.
Before Java I had an experience also in C, Perl, Scheme, Lisp and Tcl, in few projects each. C is very "crashy" in you hands if you don't use it every day. Tcl does not handle well big enough apps. Perl is a "write-only" self-obfuscated lang. The only choice left is Lisp and Scheme. Lisp is very power for big standalone apps, Scheme is convinient for being embedded somewhere.
So, in the finals I've got Python, Erlang, Scheme and Lisp. Not a bad choice.
Coming back to UML. It does same help for Python programming as for Java. As for Lisp/Scheme and Erlang, I think that things like UML are too primitive to fit. On serious languages you need a serious math, and usually diagram is just an iluustration in the math article, not a whole article.
So, if you tired from kid pictures get the math in your hands :)
Less is more !
You can build cocoa applications using the apple development tools that are native. Plus, the jvm on apple runs faster than any other platform I've tested on (linux, windows, solaris, os 9, os x).
Just my 2 cents.
Obvious Guy pointed out how there is the idea of good design first then implementation, but in reality it is much different. However, lets not accept that attitude and practice anymore than we would accept the regular practice of someone robbing your house when you leave during the day and saying it was simply 'a sad reality we must learn to live with.' I have sadly worked for some of the worst managers and development teams that you can get... these people make disorganized and pr0n addled teenagers hacking together a toy look like the giants in the industry as far as coordination, collaboration, actual planning and consistency are concerned. This problem of short time delays ends up forcing horrible hack jobs that we call proof of concepts, which predictably leads to being told to turn it into a formal prototype with only about a month, then told there that said prototype is now the system once we use the 2 months to harden it. Those time periods include the testing and documentation as well. Result? Most often a very hard coded, fragile, spit and bubblegum system that only causes massive heartache and money to maintain, extend and adapt not just a year later but often immediately following release. (most often because of adaptations to particular environments, platform settups, security requirements, etc of various end sights) When questioned on this, the pavlovian response of the decision makers is that the needs dictated this and they "could not" wait. Its been my experience that this is either an outright lie or is just extremely poor judgement. Consider how a project could be hurried up like this and end up a mess, yet when you look at the actual tasking orders that led to the project it clearly states (well clearly for bureacrats) that this is an advanced proof of concept to be fleshed out and refined before being adopted officially. Hmmm, does that mean that they want crap that takes 2.5 times the original development effort to turn into a useful and robust? (extensible, maintainable, efficient, buzz buzz buzz)
I put this under the category of 'never learns from mistakes' as this happens so regularly yet so many on both sides (especially on the user side) complain about the lack of interoperability, extendability, and integration worthiness of these projects. So, to make a long post short... (too late, I know) what kind of book, cbt, cute PowerPoint slide, or dancing furry vendor mascot will get the point across the program managment and self labled 'system engineers' that it is both cheaper and more productive in the mid to long term to really plan, design and implement an actual piece of engineering rather than these hack jobs held together by dirty bandaids and mucous. I know that as an integrator it would make my job easier :) As a customer of various products though, I would be extremely happy and of course its not like I never have to maintain, much less develop in an environment that while contains talented programmers is not held together by anyone (or any ideology) that will coordinate, motivate and lead everyone to a satisfying conclusion. Actually its been so long sense I have been able to say, "Yeah I worked my tail off but we did our best, produced some impressive results and can be proud of the work we produced" Hmmm, lets check Monster.com now :)
I seek not only to follow in the footsteps of the men of old, I seek the things they sought.
The instustry[sic] is lacking decent metrics right now, so disagreements are popping up all over the place.
y code=66:101&islowerlevel=1
Your ignorance is only out weighed by your ego.
Metrics for OO Software Engineering have been around for years. Just because you have never heard of them does not mean they do not exist. If you spent as much time reading as trolling perhaps you would already know this.
Here are a few links to be going on with: http://www.dacs.dtic.mil/databases/url/key.hts?ke
Software engineering is a dark-grey art (as apposed to a black art). As soon as one realizes this, things will start to look different.
The siren call of hacking and the fundamental difference between an amateur craft discipline and a professional engineering discipline. Let me guess; Self-Taught! The oxymoronic mantra of the incompetant.
Take your ignorant trolling elsewhere.
Compare this and this
This is copied from Amazon as well.
Someone else noticed that, but his comments got buried in level 2 of this thread. (so I'm aware, that my posting is redundant, but hopefully someone will mod this up and warn people).
Remember: Never take slashot or amazon ratings too serious.
-- "As a human being I claim the right to be widely inconsistent", John Peel