<< 1 >>
Rating: 
Summary: Boy's Own Java
Review: It's out of date, but captures the spirit of early java, and is a good distraction from the textbooks.
Rating: 
Summary: Worst Java Book
Review: This is the worst Java book that I ever had. Even for technical managers this doesn't do any good.
I sold this book for $3.00 to a used book shop.
Rating:
Summary: Dated and fluffy...
Review: When I first started reading this book, I was impressed, until I got to Chapter 3. This is where the book trickles off to a generalized Java advertisement peppered with good management practices which can be applied to any given development language or integrated development environment (IDE) out there, such as C++, Powerbuilder, VB, Delphi, and newer IDEs such as Visual Interdev, C++ builder and JBuilder, none of which are adequately treated in this book.What bothered me in particular was that the copyright is 1999 but the authors elaborate on Java projects managed in 1995-1997. Thus, for the less technologically savvy companies out there giving Java a first look, this book may be useful, but for the rest of us who have, essentially, tackled or are preparing to tackle similar problems, this book serves as a general guide to good Anderson-ish management practice. From this book one may glean tidbits of useful development ideas, such as how to embark on the installation of 3-tier or n-tier Java systems, but there remains a curious, more likely intentional, omission of project management details that matter. I expect managers out there to have already addressed similar issues with respect to large-scale development initiatives, specifically, staffing requirements, cross-training of existing personnel, capacity planning (not mentioned), performance metrics (glossed over) and hardware considerations (again glossed over) which seriously determine the success or failure of a Java-based development initiative. None of these are discussed in detail enough to warrant a study of this book. The strongest case study found in this book is the largest, albeit dated, system which the authors seemed to have managed first-hand, and which you'll find in Chapter 2. Extensive treatment of Java deficiencies and tackling the learning curve are covered, but may be less applicable to the JDK 1.2 (now officially JDK 2) since many developers have since brought themselves up to speed in Java and have engaged in at least minimal cross-training. Pros: 1. Chapter 2 (the project on which the authors apparently worked, thus relevant) 2. Chapter 8 (a noble intro to conversion) 3. Chapter 9 (risk management, developing with an evolving standard - bad idea, but mentioned) 3. Chapter 14 (a good summary of Java performance problems encountered) 4. Good general management advice 5. One of the few books to tackle the subject 6. Specifically mentions Powerbuilder/C++ implementation (surprised to see it) 7. Useful project post-mortems 8. Treatment of cross-training. Cons: 1. The ...but-we-got-it-to-work tone of items 1, 2, 3 above 2. Chapter 3,4,5 (fluffy references to other Java projects lacking sufficient detail) 3. Chapter 6, 7 (Browser compatibility and "Java isn't a fad" pep talk) 4. PR-rich e.g. no pointers, easier than C++, portable, multiplatform, secure, robust 5. Copyright 1999, Case studies: 1995-1997 (using pre JDK 1.1), thus nearly making the book obsolete 6. Utter lack of useful detail or omission such as: a. Analysis of the competition e.g. Microsoft and their implementation of COM/DCOM architecture b. Transaction servers/hardware and scalability of three-tier systems c. Project performance metrics, concurrency testing, bandwidth d. Distributed implementations and related problems e. The reporing deficiencies of Java (after finding a third-party, success!) f. Casting Java's third-party vendor and widgets in such a favorable light g. The emerging CORBA dialects and "factions" which may dilute Java's strength as the preferred distributed language h. The muddling of language vs. and integrated development environment (IDE). VB and PB were meant to remove C++ complexity for developers, but Java, by itself, is still a low-level language NOT a 4GL, thus one might expect at least a brief discussion of vendor selections in this area such as Visual Cafe, Jbuilder, J++, Sun's IDE, but there are few except mention of Unix-based or proprietary, home-grown tools.
<< 1 >>
| 
