Slashdot Mirror

Saeed al-Sahaf writes "According to the New York Times (login req, but you can google for it as well), the Bush administration is planning the government's first production of plutonium 238 since the cold war. Federal officials say the program would produce a total of 330 pounds over 30 years at the Idaho National Laboratory. Officials denied that any of the classified missions would involve nuclear arms, satellites or weapons in space, but rather would power 'secret espionage devices.' Plutonium 238 has no central role in nuclear arms. Instead, it is valued for its steady heat, which can be turned into electricity. Nuclear batteries made of it are best known for powering spacecraft that go where sunlight is too dim to energize solar cells. For instance, they now power the Cassini probe exploring Saturn and its moons."

Diridari asks: "The are some serious overheating problems with the Toshiba 5005-S504/S507 notebooks that Toshiba will not officially confirm. Many people been sending their boxes to the Toshiba depot more then once, but nothing was fixed. Since this notebook has a GeForce4go and is advertised as a desktop replacement, it should definitely be a nice gaming/multimedia notebook, but it isn't. The problem is that the CPU is a desktop CPU and during a Direct3D gaming session, or any CPU stressing application, it gets hot (Toshiba's cost reduction strategy by using the desktop CPU; I call it design flaw). I had a temperature of 65-73 Celsius during a test gaming session of DarkAgeOfCamelot with hmonitor. At 75 the box would shut down. The BIOS update from Toshiba throttles the CPU speed from 1.1G to 500MHz as a 'solution', which is not acceptable for a box that costs $2000. If I just wanted to read emails on this box, I would have spend $800 for a notebook." Has anyone had luck either getting Toshiba to properly handle this situation to their satisfaction, or via some form of workaround?

"If you want to read more about these problems, you can check Compuserve's Toshiba Forums [C: expect long load times] and search for "Still overheating" and Google for more information and user comments.

The Toshiba customer service is not helping at all. What can be done? How can I get the box that was actually advertised by Toshiba and not a very-expensive 500Mhz-for-email-only box? Do I have rights as a customer?"

rombouts noted that Salon has a good piece on the liability of programmers. From Napster, to Freenet, to DeCSS, on down. If you're scared by any of this, you should be. There are a lot of cases out there right now that are gonna change the world, and folks, it could go either way.

SEGV has returned and is continuing his excellent set of reviews. This time around, we're looking at Martin Fowler's (with Kent Beck, John Brant, William Opdyke, and Don Roberts) Refactoring: Improving the Design of Existing Code. Click below for more details. Refactoring: Improving the Design of Existing Code author Martin Fowler with Kent Beck, John Brant, William Opdyke, pages 431 publisher Addison-Wesley rating 9/10 reviewer SEGV ISBN summary Just what the working programmer ordered: a catalogue of practical refactorings with solid advice on when and how to apply them.

Overview

This book could very well do for refactoring what the "Gang of Four" book did for design patterns. In fact, with the number of contributing authors, this might well become known as the "Gang of Five" book. (They contributed content to chapters 3 and 12 through 15.)

Organization

Refactoring leaps in feet first with an extended example. I found this to be a surprisingly effective opener: it didn't overwhelm me, and left me hungry for more. The first chapter follows a sample program through several incremental refactorings, and the reader gets the idea via osmosis.

To illustrate the technique of refactoring, the first chapter presents the original code on the left page, and the resulting code on the right, with changes in bold. This presentation, coupled with explanatory text, makes it easy to see what's going on and focus on what's happening. It's as if you're looking over the author's shoulder as he edits, compiles, and tests code in his development environment.

What is Refactoring?

Now that you've done a refactoring, you might be curious to know more about what refactoring is. The next few chapters provide the relevant background.

Refactoring is what the book's subtitle suggests: changing code in in ways that preserve behaviour, but improve the way that behaviour is generated. This could be as trivial as renaming a method, or as tricky as separating domain and presentation classes.

Why go through this trouble? In the end, the code is different but it acts the same; there has been no new functionality added. Why? You do this to place yourself in a better position to add new functionality to the software. If you don't, you eventually end up with spaghetti code that is unmaintainable and will not support new functionality at all.

I think anyone who has worked on real code can appreciate the need for refactoring. In fact, most good programmers already do it, although perhaps only on a subconscious level. What this book aims to do is to raise that ad-hoc activity to a higher level of applied technique. Just as there are principles and practices in GUI design (as opposed to merely throwing widgets together randomly), there are principles and practices in refactoring activity: this book catalogues them.

Catalogue

Sandwiched between introductory and summary chapters is the meat of the book: a catalogue of over seventy refactorings. This catalogue follows in the footsteps of the highly successful Design Patterns format: Pattern Name and Classification, Intent, Also Known As, Motivation, Applicability, Structure, Participants, Collaborations, Implementation, Sample Code, Known Uses, and Related Patterns. Since the individual refactorings are less complex than patterns, this catalogue uses the format: Name, Summary, Motivation, Mechanics, and Examples.

The idea is the same. The name and summary provide a definitive vocabulary and a reference-card example. The motivation explains the relevance of the refactoring. The mechanics cover the step-by-step details of how the refactoring is executed. Then a series of examples demonstrate the variations.

Applicability

I like the catalogue. Although some refactorings seem deceptively trivial, it is useful to have them laid out in step-by-step detail. You never know when you will make a mistake, and when you absolutely positively must fix a bug or add a feature by the next day, and need to refactor to do it, slow and steady wins the race.

Further, other refactorings are not so trivial and familiar, and it is certainly useful to have their traps and pitfalls exposed. Frequently, they rely on the smaller refactorings themselves.

I can see this book becoming well-used in a shop with plenty of production code.

Supplementary Material

The non-catalogue chapters are informative as well. I especially appreciate the metaphor of bad smells in the code: the "if it stinks, change it" philosophy is the perfect counter-point to the oft-cited "if it ain't broke, don't fix it" mentality.

The chapter on refactoring tools discusses the possibility of automating much of the mechanical work of refactoring. Although there is a Refactoring Browser for Smalltalk, I suspect that Java and C++ versions are a little ways off. I'd wager that, as with the UML, tool support will lag industry practice for some time.

Style

As always, the author's writing style is down-to-earth and easy to read. Martin tells you straight up what he's found useful and what he hasn't. He tells you where he's made mistakes, and where the risk is less pronounced.

I like the way he goes through an example, then goes through it again under different conditions, thereby revealing the many-splendoured variations. Frequently he continues examples that were left off from other refactorings.

Plenty of further reading is suggested; I always like that.

Flaws

The book has a Java focus, and that is the language used for the examples. There is some mention of Smalltalk and C++, but not much; far less than Design Patterns, for example. Still, the book is quite understandable to anyone with object-oriented development experience.

The book references design patterns; some refactorings even apply and manipulate patterns. However, I wish there were more direct references to the Design Patterns book. That would especially help those new to both refactorings and design patterns.

There are a few minor typos (nothing major), so check the author's web site for errata and try to get a recent printing if you can.

Recommendation

It's no secret that I think this is a book whose time has come. I'm hoping it will codify my approach to refactoring, to help me be more efficient in my development.

I recommend this book as both a practical catalogue, and as a general work on the theory and practice of refactoring. I think that the refactoring community will grow much as the patterns community before it, and that we will see more published on the subject.

Until then, this book is a good start.

Purchase this at Amazon.

TABLE OF CONTENTS

Foreword
Preface
1. Refactoring, a First Example
2. Principles in Refactoring
3. Bad Smells in Code
4. Building Tests
5. Toward a Catalog of Refactorings
6. Composing Methods
7. Moving Features Between Objects
8. Organizing Data
9. Simplifying Conditional Expressions
10. Making Method Calls Simpler
11. Dealing with Generalization
12. Big Refactorings
13. Refactoring, Reuse, and Reality
14. Refactoring Tools
15. Putting It All Together
References
List of Soundbites
Index

SEGV has submitted a review of UML Distilled: Applying the Standard Object Modeling Language, the first book by Addison-Wesley that is UML Specific in their Object Technology Series. If you're interested in knowing more about the Uniform Modeling Language, click below. UML Distilled: Applying the Standard Object Modeling Language author Martin Fowler with Kendall Scott pages publisher Addison-Wesley rating 9/10 reviewer SEGV ISBN 0-201-32563-2 summary A short and to the point introduction to the standard object modeling language.

UML Distilled: Applying the Standard Object Modeling Language,
by Martin Fowler with Kendall Scott
[Addison-Wesley, ISBN 0-201-32563-2]

reviewed by SEGV

Nutshell
Review:

A short and to the point introduction to the standard object modeling language.

Rating: 9/10

What is the UML?

A modeling language is a (mainly graphical) notation for expressing software designs. Over the last decade, many object-oriented analysis and design gurus developed their own modeling languages and techniques for using them. The two most successful were the Booch method and OMT (Object Modeling Technique). Over the last few years, three of the top gurus (Grady Booch, Jim Rumbaugh, and Ivar Jacobson, now known as the "three amigos") joined forces and unified their methods; hence, the Unified Modeling Language.

The result of that union was the company Rational Software, which developed UML versions 1.0 and 1.1. Now, the OMG (Object Management Group, purveyors of CORBA) is in the process of adopting the UML as standard. Be warned: the OMG adopted version 1.1 as their version 1.0, so there is a lamentable discrepancy in the version numbers.

About the Book

UML Distilled is the first UML-specific book in Addison-Wesley's Object Technology Series (the three amigos are the series editors). The book's online site contains some sample chapters and supplementary information. Martin Fowler's home page also contains useful information.

I have the sixth printing, which is updated to cover UML version 1.0 (per OMG). If you get this book, be sure to get this printing or later.

100% Distilled

UML Distilled is one of the shortest computer books I own: the chapters themselves comprise only 166 pages. It is really only an introduction and overview of the UML and its application; three forthcoming books by the three amigos will go into greater depth. However, the book's brevity is its strength: it is very easily read, and can be consumed in a good afternoon.

Applying the UML

Fowler cuts straight to the chase. In the second chapter he outlines a bare bones development process suitable for use with the UML. In subsequent chapters he covers different parts of the UML, explaining notation, semantics, tips, and techniques. The final chapter is the piece de resistance: an extended example taking the reader from a UML design to Java code.

Throughout UML Distilled, Fowler is not afraid to tell you how he uses the modeling language himself. He will tell you which parts of it he finds extremely useful, and which parts he doesn't bother with. He'll even tell you where he is inclined to bend the rules slightly and do something that strictly speaking doesn't conform to the standard. That's okay, since the desired result is to have the modeling language be of use to you.

Diagrams

As the table of contents shows, most of the chapters cover a particular type of diagram in the UML. If you've never object modeling diagrams, you should check out the book's inside covers, which give a feel for their various elements (and serve as an excellent reference).

I find the class diagrams, interaction diagrams, and activity diagrams to be of most use to me. The first kind is absolutely essential for documenting the structure of your classes. The second kind is useful for documenting how the various classes interact with each other. The third kind is useful for documenting the steps in a task. The latter two kinds even allow for concurrency! And of course, they are all meant to be used during the design phase, and not merely for documentation after the implementation phase (often a sad reality).

Software

I typically do object modeling with a stack of large sheets of blank paper, or a whiteboard. But software tools do exist, whether they are more of a drawing tool or actually generate code. Rational Rose is one of the better known and most advanced tools. However, the software is typically quite expensive. I'm not aware of any freely available alternatives.

Design Patterns

It is worth noting that Fowler is also the author of Analysis Patterns (online site), a book of design patterns for business domain modeling. If you're a patterns fan, you'll be happy to note that there are several examples of their usage in UML Distilled.

Summary

UML Distilled is suitable for all levels. It is short and to the point, and offers an excellent introduction to the field of object modeling. Fowler offers good advice where he is qualified, and points the reader elsewhere (other books or web sites) where his knowledge or experience is lacking, or where further information is available. I recommend this book, at least until the "canon" UML books are available!

Buy this book over at Amazon.

TABLE OF CONTENTS

1. Introduction
2. An Outline Development Process
3. Use Cases
4. Class Diagrams: The Essentials
5. Class Diagrams: Advanced Concepts
6. Interaction Diagrams
7. Package Diagrams
8. State Diagrams
9. Activity Diagrams
10. Deployment Diagrams
11. UML and Programming

• Techniques and Their Uses
• Changes From UML 1.0 to 1.1
• Bibliography
• Index

Chris Howard writes "This site says they have a POSIX layer on top of the MacOS. I'll download it tonight and give it a try. Sounds interesting. "